Problem
How to Handle End to End “Name Change“ flow in Active Directory which could lead to CN Change, Mail Change, UPN Change, CN Change? Due to Multiple Complexities involved its not straight forward.
Diagnosis
In order to perform the Name Change Flow, we need to use combination of components in SailPoint ISC in order to perform it successfully. The high level details are.
- We need to create an identity attribute such as “Display Name History“ which will store the value of OLD Display Name prior to change and NEW Display Name post changes. The example is “Rohit Wekhande<>Rohit Wekh“
- The attribute sync b/w SailPoint ISC - Display Name Identity Attribute and AD - DisplayName account attribute is Enabled
- The Before Provisioning Cloud Rule is developed which handles the uniqueness calculation for CN, MailID, UPN and SamAccountName.
- The Before Provisioning Rule is also attached to AD source
Without the above steps, just through
Solution
Introduction
In the world of Identity Governance, a “simple” name change is rarely simple. When a user has a legal name change in your HR system, the ripple effect across Active Directory—affecting Distinguished Names (DN), UPNs, and Common Names—can often lead to broken profiles or orphaned accounts if not handled with precision.
I’ve put together a technical walkthrough of a design approach I use to ensure identity integrity. This algorithm bridges the gap between the HRMS Source and Active Directory, utilizing Identity Security Cloud (ISC) and a targeted Before-Provisioning Rule to ensure that every attribute is updated accurately and in the correct sequence.
Whether you are dealing with complex OU structures or just trying to automate the update of the sAMAccountName, this logic provides a roadmap for a hands-off, “zero-touch” renaming process.
Flow Diagram
Algorithm Steps
This algorithm outlines the logic for detecting a legal name change in a source HR system and ensuring all downstream Active Directory (AD) attributes are updated consistently without manual intervention.
Phase 1: Data Source & Identity Refresh
-
Step 1: HRMS Detection The process triggers when a change is detected in the HRMS Source (e.g., Workday, SAP SuccessFactors). The system identifies a mismatch between the current HR record and the existing Identity Cube.
-
Step 2: Identity Attribute Recalculation SailPoint Identity Security Cloud (ISC) aggregates the new First Name and Last Name. The Identity Profile logic automatically updates the Display Name and Full Name attributes on the user’s Identity Cube.
Phase 2: Transformation Logic (The “Before Provisioning” Rule)
-
Step 3: Trigger Account Update Once the Identity Cube reflects the new name, ISC triggers an “Update” operation for the linked Active Directory Account. This Update Account/Modify Account operation is triggered for “DisplayName“ attribute in AD.
-
Step 4: Execute “Before Provisioning” Rule Before the request is sent to AD, a cloud rule intercepts the plan to handle complex renaming logic:
-
It captures the Old Display Name and compares it against the New Display Name through “Display Name History“ attribute in identity profile
-
It calculates the new Distinguished Name (DN) if the name change requires moving the object or renaming the RDN (Relative Distinguished Name). This has to be done through AC_NewParent attribute in MS AD.
-
Phase 3: Attribute Construction
-
Step 5: Attribute Mapping The system prepares the final payload for the AD Connector. This includes:
-
CN (Common Name): Formatted as FirstName LastName. The new CN will be sent through AC_NewName attribute in the provisioning plan of AD.
-
sAMAccountName: (Optional) Updated based on corporate policy. The new SamAccountName will be sent through “sAMAccountName“ OOTB attribute of AD through provisioning plan.
-
UserPrincipalName (UPN): Updated to match the new legal name/email structure. The new userPrincipleName will be sent through “userPrincipleName “ OOTB attribute of AD through provisioning plan.
-
Display Name: The finalized string generated in Step 2.
-
Phase 4: Downstream Execution & Verification
-
Step 6: IQ Service Communication The update request is sent to the Active IQ Service (the gateway to the Windows environment).
-
Step 7: AD Domain Controller Update The IQ Service executes the LDAP modify commands on the AD Domain Controller. This updates the physical account attributes in the directory.
-
Step 8: Confirmation & Re-Aggregation AD sends a Success Response back to ISC. On the next scheduled aggregation, ISC pulls the updated account data to confirm that the “Account Attribute” in SailPoint matches the “Identity Attribute.”
Key Technical Considerations for your Article
1. Attribute Sync: Ensure that Attribute Sync is Enabled for respective attribute in this case “Display Name“ against which Name Change Transformation flow will be triggered through Before Provisioning Rule.
2. Impact on Login: Remind readers that changing the sAMAccountName or UPN will impact the user’s login experience and may require a desktop re-logon.
3. Downstream Apps: Mention that once AD is updated, other integrated apps (like O365 or Zoom) will typically inherit the change via their own sync with AD.