I have a requirement to update the sAMAccountName in Active Directory whenever a user submits a form requesting a change to it.
Currently, the sAMAccountName is being generated using an Attribute Generator Rule during account creation. However, in this scenario, I need the form submission to act as a trigger, recalculate the sAMAccountName based on the updated values, and then provision the new value back to the AD account.
Has anyone implemented a similar use case in SailPoint ISC? What would be the recommended approach?
Thanks,
Shireesha C
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?
Hello Shireesha. Since sAMAccountName is currently produced by an Attribute Generator Rule, I would not move that uniqueness logic into an Identity Attribute Rule to support this. SailPoint strongly discourages uniqueness checks in an Identity Attribute Rule, because the calculation is multi-threaded so uniqueness is not guaranteed, and recommends keeping that check at account generation.
I also do not see a documented native workflow action that reruns the generator or sets an arbitrary AD attribute on an existing account. Manage Accounts only supports Enable, Disable, Unlock and Delete, and the Accounts API can modify account attributes only for flat-file sources, not a directly connected AD source.
Attribute Sync would work only if sAMAccountName were mapped directly from an identity attribute in the AD Create Account definition. With your current Generator mapping, you would have to replace that mapping, along with its generation-time uniqueness, to go that route.
For your exact requirement, I would keep the workflow for intake and hand the write-back to an external step:
Form Submitted → approval if required → HTTP Request to an external automation/service → calculate the unique sAMAccountName → update AD via PowerShell or LDAP → aggregate the account back into ISC
The Form Submitted trigger passes the submitted values into the workflow, so you can send them to that service.
One AD note: changing sAMAccountName changes the logon name only; it does not rename the account CN/RDN. If the CN also needs to change, that is a separate rename operation (AC_NewName).
Thanks for this approach, can you please explain what do you mean HTTP Request to an external automation/service → calculate the unique sAMAccountName in this approcah?
Hello Shireesha. Sure, by external automation/service, I mean an HTTPS API endpoint outside ISC that the workflow can call using the HTTP Request action.
For example: Form Submitted → HTTP Request → external service → Active Directory
The workflow sends the submitted values to that service. The service would then:
Calculate the new sAMAccountName.
Check AD and apply the required uniqueness logic.
Update the existing AD account using PowerShell or LDAP.
Return the result to the workflow.
So the HTTP Request action itself does not calculate or update sAMAccountName. It only calls the external service that performs that logic. If you want to keep the same naming algorithm currently used in your Attribute Generator Rule, reproduce that logic in the external service.
For on-prem AD, the service must also have connectivity to the domain controllers, and the endpoint must be reachable from ISC. The HTTP Request action times out after 90 seconds, so the service should return within that window and use a separate status-check step if the AD update runs longer.
This Forms and Workflow example may also help with the ISC-side setup. It shows a Form Submitted workflow passing form values to an API using HTTP Request. The target in that example is different, but the workflow pattern is similar.
@Shireesha5 if you have access to Privileged Task Automation / Privileged Action Gateway workflow actions (PAG) then you can perform the uniqueness calculation in the workflow and then use the PAG Active Directory action Get User by SAM Account Name. If the action returns a user from your calculation you know it is not unique and you can increment by 1 and try again. If nothing returns then it should be unique.
Then you can use PAG execute powershell to update the sAMAccountName.
Hi @kyle_knox Could you let me know all the prerequisite details to use the Privileged Task Automation / Privileged Action Gateway workflow actions (PAG) in ISC workflows.
