We are having issue with duplicate account creation in AD.
Our provisioning process is like when an user gets terminated in the first phase the account will get disable and stay in standard OU without any access removal and in ‘Phase 2’ account will move into disable OU and SailPoint is removing all access/groups inside the account.
And we have script where in when the user completed the competency we used to receive a file that these users has to be associated with these groups and sailpoint provisioning those groups by reading that file.
after account moves into disable OU sailpoint again creating the account for the same user in active OU and that account is getting associated with script groups not birthrgt groups of sailpoint also account which is in disable ou getting added with those group.
So is there anyway in sailpoint set the logic or make it understand that no account should create for the same empid in AD.
@schattopadhy thanks for the reply in our current env setup only empid is common in AD for duplicate accounts, samaccount,email address are creating unique.
If new AD Accounts are being created for users that are in a disabled state then it suggests that one of your Active Directory Roles are still applied to the user, or IDN wouldn’t still be trying to create a duplicate account for the user. Have you checked the Identity to see if any roles are still applied?
How are you moving accounts to the disabled OU? Have you run a new aggregation (and is the user still correlated) prior to the groups being added? ISC uses the fully qualified DN as the name of the account, if the account is not correlated, a new account would be created if the user has additional provisioning activities like role changes as Ryan mentioned?
I agree with @Mccarney here that it sounds like you have a role that grants accounts on AD via Birthright criteria that does NOT respect/check the Termination status of the user.
If the Terminated accounts OU is not being aggregated in, or there is a delay where the account is not present on the identity, and the Role does not check the state of the user, then the system likely thinks that they do not have an account, and then tries to create a new account for them.
@ts_fpatterson thanks for the reply we have set up username = samaccount and empid = ad empid and for schema account is id dn & account name is sam account
roles are not applied in the dup accounts but sailpoint is enabling the account in disable ou and when it tried to move into active ou its not happening because of cn value is same for both of them
where the account is in disable state more than 30 days sailpoint is moving them into disable ou after that workflow is triggering for group removal for that account
If the duplicate AD account is being created it suggests that IDN is trying to apply AD access somewhere within the system, otherwise IDN wouldn’t create the second account.
Have you checked if any access is being applied on the lifecycle state rather than a role?
@Mccarney I have found the issue and yes there is a access profile which is a birthright group and we have set the criteria in ROLE but not in ACP not sure why sailpoint is adding that ACP in user account even though we didn’t set the criteria in ACP.
When you are moving accounts in AD, there should only be one action completed in that request as the account will become temporarily uncorrelated during the move. We have seen this occur when there is a move and a group change at the same time. You might check the events for the user around the time of the move. Open up each one and see if there was another change such as the group being removed with the OU change.