New AD Account Created during AD Aggregation

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi Folks,

When we manually change “CN” value of user in Active Directory, during aggregation a new AD account got created for user. BUT when we change the samAccountname & UPN it didn’t created another AD account.

How we can ensure another AD account should not get created when we do such changes & aggregation.

Thanks in advance.

2

ISC uses the fully qualified DN as unique identifier when creating AD accounts. If you change the DN, on the next aggregation the original AD account will become uncorrelated from the identity. Aggregation also triggers an identity refresh which reviews all assigned access and makes sure that it is properly provisioned. My guess is that the refresh occurred prior to the account with the updated DN correlating.

The best practice is to set the DN to a value that is unique across the organization and does not need to change. The DN displayed in any user facing contexts.

See the document below for additional information:

Best Practices: Active Directory Account Moves - Compass (sailpoint.com)

1 Like
3

If you cannot handle the DN /CN changes from SailPoint, here is a workaround that I’ve implemented elsewhere:

  • Enable native change detection for attribute changes on the DN
  • Develop a workflow that identifies that native change event, and if it does, fires off the ‘child workflow’ from this link: Workflow to remove ALL leavers' standing access so that SailPoint won’t continuously attempt to re-apply the entitlements to the old DN. This will only strip access from the old DN - any entitlements, access profiles, and roles will still be detected on the AD account and won’t be removed from the account that has had the DN updated.
  • Add in a BeforeCreate connector rule, a check on a unique attribute for the organization (e.g., employee number). Pass the unique attribute through using the Services Standard Before Provisioning rule and check if the account already exists, if so, remove all attribute requests from the provisioning plan.

Ideally it would be possible to just change the unique identifier to something that doesn’t change, like the objectGUID, but this has other impacts on Roles and Entitlements needing to be reset.
Hope this helps!

1 Like
4

@margocbain

SailPoint has attempted to change the unique identifier to the ObjectGUID but backed out the change due to other complications. It would not be recommended to reset the unique identifier.

1 Like
5

Thanks folks for the input. I understand the challenge but its still a requirement for us to get it changed.

  • Either will create new Identity for users and delete old one OR
  • Change samaccountname & UPN but keep the CN value to old name. Not sure how this will impact any downstream systems

I tried on two different users, for one it worked fine, but for other it created another identity.

Must be a way to make this happen. This is an adhoc request which we need to do manually.

6

I understand the challenge. This one is just a little tricky because of the issues that you are encountering. If I had to think from SailPoint best practices, I would choose your second option, set the DN to something that would not change and then focus on the samaccount, UPN, displayName, attributes that the user is able to see.

However, if you need to change the DN, I am just wondering since you are doing this manually, could you:

  1. Go to the Identity in the ISC UI. Remove the account (This only removes data about the account from the tenant. It does not delete the account in the source system)
  2. Go to AD. Make the changes to the DN, UPN, SamAccountName
  3. Go back to the ISC UI and run an AD aggregation.

This should prevent ISC from processing both the “deletion” of the old account and the creation of the new account at the same time.

When you try this, I would make sure that your authoritative source aggregation is not running, your Active Directory source aggregation is not running, and it is not time for a scheduled identity refresh.

7

Hi,
This is a solution for if you have Entra ID as well as AD.
Assuming that you have some criteria for provisioning an AD account just add that the user account cannot have an Entra ID account either.
This will allow for normally provisioning, but when you aggregate AD after manually changing the CN, the original AD account will disappear then recorrelate without triggering a new AD account to be created in its absence.

We implemented this earlier in the year