We have a requirement When Workday updates firstname/lastname for an existing identity, the Active Directory sAMAccountName must be recalculated and updated on the existing account.
Currently sAMAccountName is calculated for Create Account using cloud rule Unique sAMAccountName
Modify Account provisioning policy is not configured, attribute sync is enabled for givenName and sn.
Question: What is the cleanest production pattern to handle sAMAccountName rename when legal name changes for existing accounts in ISC SaaS?
Thanks,
Shireesha
Please consider addressing the following when creating your topic:
What have you tried?
What errors did you face (share screenshots)?
Share the details of your efforts (code / search query, workflow json etc.)?
What is the result you are getting and what were you expecting?
This can be achieved by the attribute sync from the AD with the Identity profile attribute and select that attribute in the Create profile of AD and then enable the sync for that identity attribute with sAMAccount AD attribute. Hope this will help to update the value whenever it changes.
The SailPoint’s Best Practices: Active Directory Account Moves” document, which deals with CN/DN renaming (AC_NewName/AC_NewParent) mechanics in case of that being relevant besides just the sAMAccountName.
@Deepak_Chaudhary , apologies, currently samAccountname is calculating using cloud rule, and have dependency on firstname and lastname, so how can we enable attribute sync for samaccount name as it is calculating via rule
@Shireesha5 - Can you just try this method from your lower environment.
Define an attribute Identity Attribute → custom attribute called calculatedSAM using a Rule or Transform Mapping that executes the same logic of firstname+lastname+uniqueness your existing cloud rule does. It gets automatically recalculated each time the identity is refreshed/aggregated when firstname/lastname fields get updated no provisioning trigger required for this step, it’s just identity cube calculation.
Update your AD source “Create Account” provisioning policy field of sAMAccountName attribute
Then Manage Attribute Sync and enable sync for this attribute
Hi @Shireesha5 Have to be honest, and I know it’s not answering your question (a provisioning policy of UPDATE type would do it), but ISC is not the best place to update the sAMAccountName.
AD should remain authoritative for the sAMAccountName attribute.
How would the User know what sAMAccountName had been generated following a name change? Are they aware of the uniqueness requirement and the 20 character limit? Do they know when it’s going to change? Is this a user originated preferred name change, or a legal name change (which would have an effective date)? If it gets changed at the 08:00 Identity refresh would they be able to log on in the morning?
You are storing up a lot of pain and help desk calls automating it via ISC.
I 100% agree with @j_place on this. The technical issues can be worked through, but once you get it working the customer will recognize that there are business process issues. Specifically, the user will not be able to log in when they get in in the morning, and they’ll call the helpdesk and that will take just as much time as scheduling a call with the customer and manually changing the account name when they’re available but not actively working on something. Then the customer will recognize that there are only 5 sAMAccountName changes per year and the challenges that come with automating sAMAccountName changes FAR outweigh any minimal benefit that would be gained.
This is the reason that I flat out refuse to work on a project that requires automating sAMAccountName updates.