We have a use case where a single AD connector is connecting to multiple child domains and for “mover” cases, we need to move users from one child domain to another.
To achieve the movement between child domains, AD account from old child domain needs to be disabled, the AD account from old child domain needs to be uncorrelated from the identity and new AD account in the new child domain has to be created. We want to achieve this on a single “mover” event from Authoritative source.
Wanted to check if any suggestions/ideas to handle this.
Where there is an AD account existing already, ISC will not be able to trigger new AD account creation. We need to handle it from powershell script.
We need to create a powershell script for all the scenarios (disabling AD, creating new AD account) and in after operation rule we can invoke the powershell script.
We should add a correlation logic such that the newly created account correlates to Identity after aggregation.
Yes, old account should be left as disabled in the old domain. Shouldn’t rename the old account ADID.
Hi @KRM7 , we cannot rename the attributes of the old account that are used for correlation, so cannot rely on uncorrelation in this way. Is there any other way to uncorrelate
You cannot update the uncorrelated attribute of the account.
We can only update “manually correlated” attribute but it would not suffice our requirement here.
One thing you can do is update the identityId of the account. This will un-correlate the account from current identity and correlate the account to new Identity.
Have you tried setting the ‘OU=Disabled’ to an root that is not brought in via the aggregation?
That will uncorrelate it from the cube. The downside is that if you need to re-enable it at a later date, it will have to be a manual process, as Sailpoint won’t be able to see it.
I do agree with Krishna that it would be an easier solution just to rename the existing DN
Use the afterModify Connector Rule to create a new account via Powershell.
I can’t think of another way for Sailpoint to create an account if one already exists on the cube
You will have to update all transforms that reference to that source to check if the sub-account is enabled/disabled or when.created otherwise Sailpoint won’t know which of the two accounts it needs to update
Option 1 - Do not uncorrelate old account:
1. Disable the old account using disable PP
2. Using AfterModify Connector Rule and powershell scripts, create the new account in the new domain
3. Update references to the source to ensure new account is updated for any modifications
Option 2 - Uncorrelate old account:
1. Disable the old account using disable PP
2. Uncorrelate the old account from the Identity -
a. either change the correlation attribute value
OR
b. use API to update identityId value
3. Using AfterModify Connector Rule and powershell scripts, create the new account in the new domain
I believe there is no other possible way for Option2: 2
We usually maintain an obsolete Identity to correlate Service Accounts and for some other purposes. You can correlate these account as well to that Identity.
But please note that max of 100 accounts you can correlate to an identity.