Handling Race Conditions in AD Provisioning for Same-Name Users Across/Same Domains

[ashwinVnair]

Hi Experts,

Need some help understanding and handling two different provisioning race condition scenarios related to Birthright role-based account creation.

Scenario 1 – Same Name Users Created in Different AD Domains

• We have two AD sources in two different domains.

• When two users with the same name are onboarded simultaneously, each gets an account in a different AD domain through Birthright role assignment.

• The unique email generator rule does not seem to detect uniqueness across both domains during provisioning.

• As a result, the same email/UPN value gets generated for both users in different AD domains.

Question:

• Has anyone handled global uniqueness for email/UPN across multiple AD domains?

• Is there a recommended approach to avoid this race condition during concurrent onboarding?

Scenario 2 – Same Name Users Created in the Same AD Domain

• When two users with the same name are onboarded simultaneously into the same AD domain through Birthright role assignment, I see the following error:
  “Account created but some attributes not populated correctly” along with “constraint violation occurred”.

• In this AD, CN is mapped to Employee Number and is unique, so the account itself gets created successfully.

• I suspect the failure occurs because both provisioning operations attempts to set the same generated email/UPN value at the same time.

Question:

• Is it possible to configure this as a retryable error so that the Email Attribute Generator Rule in the Create Account Provisioning Policy is triggered again to generate a new unique value?

• Has anyone implemented retries or another mechanism to handle simultaneous same-name onboarding into the same AD source?

[Abhinov7 (Abhinov Dhonthula)]

Hi,

In case of scenario 1 are both AD domains are onboarded to Sailpoint ISC? If yes you can configure searchable attributes for check in other sources while creation of account.

Using IdnRuleUtil as a wrapper for common Rule operations | SailPoint...

For scenario2 when you got this error what attributes are getting populated in AD? Did you check the account on AD directly?

-Abhinov

[Santhakumar (Shantha Kumar)]

Hey @ashwinVnair, for Scenario 1, I have created the rule that @Abhinov7 mentioned. Below is the snapshot of my rule, which I have used in one of the projects.

For scenario 2, can you search the user’s display name in Search and try to get the provisioning policy and see what attributes are giving the constraint error?

[ashwinVnair]

Hi @Santhakumar @Abhinov7 ,

Thanks for your response!!

Scenario 1:
I have been using a similar rule, and it works correctly when a user already exists and another user with the same first name and last name is onboarded later.

However, we have two AD sources: AD1 and AD2, with two Birthright roles: BR-AD1 and BR-AD2. When two users with the same first name and last name (for example, Test User and Test User) are onboarded simultaneously, where:

• one user satisfies the assignment criteria for BR-AD1, and

• the other satisfies the criteria for BR-AD2,

the rule fails due to a race condition.

During account creation on both ADs, the email ID test.user@xyz.com is generated and checked for uniqueness. Since neither account exists yet in ISC at that moment, the value is considered unique in both provisioning operations, resulting in the same email/UPN being assigned in both AD domains.

Scenario 2:
In this case, the error indicator is shown for all attributes in ISC except cn, dn, and sAMAccountName. I suspect the issue is again related to the UPN/email value being set. I have checked in AD other than cn, dn, sAMAccountName no other attributes seems to be populated.

Here, two users with the same first name and last name are onboarded simultaneously, and both satisfy the assignment criteria for BR-AD2. Two AD accounts get created successfully because cn is mapped to Employee Number, which is unique.

However:

• one user gets test.user@xyz.com assigned as mail and UPN,

• and the provisioning process then attempts to assign the same value to the second user, which fails because the UPN must be unique in AD.

I also tried manually creating users in AD with the same UPN, and AD correctly throws an error indicating that the UPN already exists.

I attempted to configure this as a retryable error using connectorAttributes, hoping it would trigger regeneration of the email/UPN value, but that approach does not seem to work.

Has anyone of you handled a similar race condition scenario or implemented a retry mechanism for this type of issues?

[rohit_wekhande]

@ashwinVnair

Instead of performing retries, you need to make sure that when you are generating the attributes through CLOUD RULE, you are performing the Uniqueness Checks on Both AD domain controllers.

Now, in ISC, you cannot perform an LDAP connection and directly check in AD, its not possible.

The best possible way to make sure that your respetcive attributes as SamAccountName, UPN, Email is unique in both domain controllers, you can use the approach of creating “SEARCH ATTRIBUTES” in SailPoint ISC and then, using that SEARCH ATTRIBUTE inside the cloud rule to perform the uniqueness check. Refer the below details.

Using IdnRuleUtil as a wrapper for common Rule operations | SailPoint Developer Community

[ashwinVnair]

Hi @rohit_wekhande ,

Yeah, I have been using the same rule and is failing to create unique email on race condition as mentioned above. Have you handled a similar race condition scenario as mentioned above or implemented a retry mechanism for this type of issues?

[rohit_wekhande]

@rohit_wekhande

Instead of performing retries, you need to make sure that when you are generating the attributes through CLOUD RULE, you are performing the Uniqueness Checks on Both AD domain controllers.

Now, in ISC, you cannot perform an LDAP connection and directly check in AD, its not possible.

The best possible way to make sure that your respetcive attributes as SamAccountName, UPN, Email is unique in both domain controllers, you can use the approach of creating “SEARCH ATTRIBUTES” in SailPoint ISC and then, using that SEARCH ATTRIBUTE inside the cloud rule to perform the uniqueness check. Refer the below details.

Using IdnRuleUtil as a wrapper for common Rule operations | SailPoint Developer Community

Hello,

You can use below approach.

1. In the before provisioning cloud rule/ or any cloud rule where you are doing this, Create a logic for generating a Unique Value by checking the uniqueness in both AD domain controllers using SEARCH ATTRIBUTES
2. Then, once the unique attribute value is created from STEP # 1, create another method which uses another sailpoint ISC API of attrSearchCountAccounts() to check whether there is already an AD account created with respective generated value, IF YES, then, increment it and go to next iteration to generate a new value

Refer the below flow diagram with high level approach.

[Cloud Rule Fires]
       │
       ▼
[Generate base candidate: firstname.lastname@corp.com]
       │
       ▼
[attrSearchCountAccounts across ALL source IDs] ← Scenario 1 fix
       │ count > 0?
       ├── YES → increment suffix, repeat
       │
       ▼ count == 0
[isUniqueLDAPValue against current provisioning target] ← Scenario 2 guard
       │ not unique?
       ├── YES → increment suffix, repeat
       │
       ▼ unique confirmed
[Return value to provisioning plan]

Note that above approach will not completely remove the RACE CONDITIONS but it will reduce it significantly.

[j_place (Jeremy Place)]

HI @ashwinVnair

Scenario 1: Can you confirm the forest/domain model? I’m going to assume they are in the same forest (as you are attempting similar UPN). If so, create 1 Source with multiple domains.

Scenario 2: This is a known constraint with ISC. Developing a solution would, IMHO, be over-engineering an exceptionally rare occurance.

[ashwinVnair]

Hi @j_place

Both ADs are in different domain, and I am not attempting same UPN, and which is not possible. But due to race condition, when users with same name getting onboarded the both ADs create account for both users in different domain and as user email is not present in ISC it assumes it to be unique and assign the same mail id to both users in Scenario1 and when both users are to be created in same AD domain which is AD2, it try to set same UPN for both in same AD domain in Scenario2.

[jolan (Joshua Lan)]

Hi @ashwinVnair ,

I believe your race condition issue can resolve by using this method, isUniqueLDAPValue in your BeforeProvisioning rule for final check before sending over to source.

Check if an LDAP attribute value is unique​ - Using IdnRuleUtil as a wrapper for...

[j_place (Jeremy Place)]

HI @ashwinVnair To clarify: you have 2 separate AD Forests and they both have the same email suffix?

[ashwinVnair]

Hi @rohit_wekhande ,

This worked for first scenario but still for the second scenario it creates account with mail for one and for other just account created with not all attributes populated as ISC is trying to set UPN same as the other user. Do we know if this could be configured as something that ISC could retry and trigger the mail generator rule again and try to set unique UPN by any chance.

[j_place (Jeremy Place)]

Hi @ashwinVnair Can you confirm the forest model here?