We recently attempted to process an employee name change. This was for a user mapping to our “full time employee” identity profile, which uses our HR platform, Workday, as its authoritative source. Workday accounts use a FILENUMBER attribute as account name AND account ID, which will NOT change if an employee’s name changes.
In trying to support this change, our HR and IAM Ops team schedule a day to make the required changes in Workday and AD respectively, with the intent to make the changes in the same time window between aggregations/identity syncs. In Workday our HR team updates the USERID attribute (mapped to identity attribute “Sailpoint UID/uid”) and EMAIL_ADDRESS_WORK (“Email”), while in AD our IAM Ops team updates attributes related to First/Last name, username (sAMAccountName), and email (to same value as Workday team). Our Workday aggregation occurs every 12 hours at 5AM/5PM CT; our AD aggregation occurs every 12 hours at 7AM/7PM CT.
In doing this, we had an issue come up where the identity in question “cycled”, as in, the original identity was deleted, quickly followed by a new identity being established linked to the same Workday account. In deleting the “original” identity, all of its roles were revoked, which then resulted in essentially all AD group memberships being revoked. Then, as the “new” identity was created, it FAILED to correlate to the existing AD account (even though we are positive our correlation logic should have remained well-formed, as in, previously mentioned FILENUMBER in Workday == Identity Attribute “EmployeeNumber” == AD account attribute “employeeNumber”). Because this correlation failed, and our identity profile for Employees has an Active Lifecycle State trigger set to provision an AD account for an identity, IDN then provisioned a redundant AD account for this user. It then proceeded to attempt to give a number of AD group memberships related to roles, and then failed. This left our Ops team scrambling to link the original AD account back to the identity, and then to make sure all roles/entitlements were in order the following day.
I have 3 main questions at this point.
1. Why was the "original" identity "cycled", as in, why was it deleted and then re-created? This seems to risk triggering unnecessary lifecycle state processing, as we learned here.
a. My current hypothesis is that because the Identity Attribute "uid" changed, IDN just happens to handle such a case by recreating a UID because it is "immutable". HOWEVER, I attempted to test this with a flat file source in our lower environment (changing account attribute mapped to "uid") and DID NOT notice the same outcome.) We also wonder if the timing of aggregations played a role.
b. Our current "clues" that this happened:
i. "Access History" shows multiple entries for the same user (deleted identity with yellow triangle, re-created identity showing normally)
ii. The following events/account activities:
□ After Workday/auth source aggregation:
- 2024-02-22 05:05:22 PM GMT-06:00: an Active Lifecycle State change event against the "re-created" user identity, followed by a number of events related to role assignment/modify entitlements that failed for the most part.
- 2024-02-22 05:05:26 PM GMT-06:00: Account Activity of type "Identity Refresh" showing the role revocations and related AD revocations against "deleted" identity.
□ After AD aggregation:
- 2024-02-22 07:08 PM GMT-6:00 and after: about 2 hours after these initial events, we see barebones redundant AD account provisioning activities.
2. Related to 1a, is it kosher to update the "UID" of an identity after it's been created? Would we always expect this "identity cycling" behavior to occur in doing so? (We're attempting to test, and as mentioned in 1a, were not able to replicate with a flat file source.
3. Why did the re-created identity FAIL to correlate to the original AD account? We have a couple of hypotheses, one being that because these events occurred so close together, that the original AD account was already considered "correlated" and thus was missed by the re-created identity; the other thought is that because scheduled aggregations are optimized, the original AD account was considered "unchanged" at that time and thus missed the correlation. In either event, my knee jerk reaction is that it would be best to head off the need to re-correlate accounts in the first place by preventing the identity "cycling" behavior.
I realize this is a lot but any guidance/prior experience would be helpful. Only related post I found was this one: Modify Identity Profile and Uid. Apologies for formatting