When identity is aggregated from auth source, created AD accounts through RBAC process.
When User is terminated from HR, we are disabling AD account and moving account to Disabled OU. After this when we run full AD Account aggregation, AD account gets unliked from identity. But if we run AD full aggregation again, then it’s get relinked to the identity. We have only one domain controller.
I have noticed that when account is disabled, role and entitlement gets removed from the identity and also if run single account aggregation we don’t see the issue.
@Rajesh_Thota1 If I understand your issue, you do not want to link users under disabled OU, if yes - then please check the users search scope and use filter accordingly.
Is there any time difference in the AD disable account moving to disabled OU, if it is then, perform full aggregation after 10 to 15 min later, after disabling account in IDN.
After identity LCS is updated from Active to terminated, We have disabled AD and moved to disabled OU immediately. We have run full aggregation after 30 mints, I do see the same issue, account get’s unliked from identity. It will be linked again after you run one more AD full aggregation.
As long as your users search scope and correlation logic are fine you should not have this issue.
I would recommend you to validate it properly.
If the attributes used for correlation are changing on the AD side between aggregations, that could cause the account to be unlinked and re-linked.
Common attributes used for correlation are employeeID, email, userName. Make sure these are stable while you disable / aggregate accounts.
The key is to identify exactly which accounts this is happening to, examine their attributes closely in IdentityNow and AD at each step, and align the correlation/transform/aggregation configuration to avoid unlinking and relinking unnecessarily. Consistent, unique attributes for correlation are important.
As mentioned above, you should use a beforeProvisioning rule (I recommend the Services Standard BP rule) to do the account moves because that way SailPoint can track the account in the new OU and no unlinking will take place. I have seen some do this with an After rule and PS, but a BP rule is the way to go.
During the OU movement, the DN was calculated dynamically at the identity level and passing in the before provisioning rule, so calculated DC value is in upper case and actual DC value at the AD is in lower case and also in source we have configured all DN’s in lower case and now updated as per AD DN’s.
