Bug - Create Account Provisioning Policy

What problem are you observing?

Following the migration of the Create Policy page to the Source Configuration page, an issue has emerged affecting attribute references throughout the policy. When any minor modification is made to the policy from the Source Configuration → Create Account page (e.g., altering an identity attribute for a field), previously declared attribute references in all fields are automatically removed. This issue is not limited to specific fields like distinguishedName but affects all fields where attribute references are utilized.

What is the correct behavior?

The expected behavior is that all declared attribute references in any transforms for any field should remain intact when unrelated modifications are made to the policy. For instance, the “ouDetails” reference should persist in the distinguishedName field even when modifying other attributes, such as changing the value for physicalDeliveryOfficeName from “Department” to “Title”.

What product feature is this related to?

This bug is related to the Create Account provisioning policy. The issue specifically arose after the recent migration of the “Create Account” page to the Source Configurations page. This migration has impacted the behavior of attribute references within the policy settings.

What are the steps to reproduce the issue?

Step 1: Deploy a create provisioning policy for Active Directory Source.
Step 2: In the distinguishedName field, use a static transform with the value “$cn,$ouDetails”.
Step 3: Declare “ouDetails” as a reference to identity attribute under the attributes section for the distinguishedName, above the value.

Step 4: Navigate to the new Source Config → Create Account page.
Step 5: Make a small modification to the policy, such as changing the identity attribute for a field (e.g., changing the value for physicalDeliveryOfficeName from “Department” to “Title”).

Step 6: Save the changes.
Step 7: Observe that the “ouDetails” reference previously declared under attributes for distinguishedName has been automatically removed.

Do you have any other information about your environment that may help?

This issue was initially identified on a sandbox tenant. Subsequent testing on a partner-demo tenant reproduced the same behavior. Further investigation on a devrel-demo tenant, which has not been updated to the new configurations page (where “Correlation” and “Create Account” still reside on the source page), did not exhibit this issue.

11 Likes

I too faced the same issue. Thanks you @poornasai .

2 Likes

Nice find! @poornasai

1 Like

@poornasai We appreciate the detailed writeup on this bug report. This particular bug will need to go through our support triage team so they can verify and route it to the right engineering team. Can you please open a support ticket and include all of the details in this message in the ticket? Feel free to link your support case number back to this post so I can help provide updates to the community based on the progress.

2 Likes

@colin_mckibben Sure, I will open a support ticket and post the update.

2 Likes

This happened to me too for transforms: “name”: “userPrincipalName” & “name”: “proxyAddresses”. Both are static transforms. with value that has a function within it

1 Like

Nice Find @poornasai

1 Like

Your post helped me to resolve my issue .Thanks @poornasai

2 Likes

Hello Colin, thanks for your reply, When is it going to be solved this issue? It is impacting production environments

Hey @pablonovoa

I have opened up a ticket. They are working on it.

4 Likes

@poornasai If they provided an internal ticket number that they are tracking it under, can you add it here so we can have our CSMs follow up on the issue for those of us it is affecting?

Thanks

1 Like

Has anyone received any updates or an internal ticket number from support on this issue?

The fix for this issue (UISOURCE-5721) was released last month and was included in the SaaS Release Notes on Compass.

4 Likes