I’m facing an issue in ISC while onboarding two identities that have the same first name and last name (e.g., Test User).
We have a birthright role configured using role assignment criteria, which provisions accounts in Active Directory. The CN/DN naming convention is defined as: $(firstname)$(lastname)$(uniqueCounter)
For the first identity, the account gets created successfully (e.g., testuser)
For the second identity:
Provisioning fails with an “object already exists” error as it tries to create account with same CN (e.g., testuser for both)
The system does not retry with an incremented uniqueCounter
No alternate CN (like testuser1) is attempted by System on failing even though Role is still assigned to failed identity.
What i was expecting was that both identities should be provisioned successfully with unique CNs, such as:
testuser
testuser1
It seems that even though $(uniqueCounter) is part of the naming logic, ISC is not handling CN conflicts dynamically or retrying with an incremented value when a duplicate is detected in AD.
Has anyone encountered this behavior before?
Is there a way to enable retry or auto-increment logic for uniqueCounter?
Do we need to implement a before-provisioning rule to handle CN uniqueness manually?
Are there any best practices for handling duplicate names in AD provisioning via ISC?
@ashwinVnair by default ISC work with multithread and things are doing in parralel, so if he try to check uniqueness as accounts are not created, the existence of the unique CN will not detected that’s why may be he try to create those accounts with the same CN.
This doesn’t seem to be working as expected. It shows the event as passed, but the account is not being created. Additionally, the same DN is being used for two users simultaneously, which would also prevent account creation in AD. What I want is: if the creation fails, it should retry using the next counter value. For example, if it fails with “testuser”, it should then try “testuser1” instead of retrying with the same value.
No its failing on trying manual identity process as its trying with same value. This occurs when 2 users with same first name last name is getting onboarded on same time.
Will it handle cases where two users with the same name are onboarded at the same time? My understanding is that it only performs the check after a user is created, so it wouldn’t account for race conditions—is that correct?
Then I would recommend checking the CREATE profile so see where the $unique counter is being applied, and to make sure that it is replicated across ALL entries that require uniqueness. eg sAMAccountName; UPN; email; etc
Can you just confirm that you are using the Create Unique Account ID generator for the DN and also that you are not populating CN in the provisioning policy? Also, that you are using DN as the Account ID. This is the best practice approach.
ISC will multi-thread account creations, so it is possible to hit a race condition when testing, but it is exceedingly unlikely to be hit during normal running.
There is no functionality for retries including an increment as retries use the same provisioning plan.
Yes. But cheking in a target system will increase considerably the chance to found unique DN even you create two Identity at the same time they will not be created extactly in Active Directory in the same time.
