We are exploring the capability to update the ‘account expiration’ attribute on Active Directory (AD) for a user based on input collected through SailPoint Forms. However, we’ve encountered a challenge: there doesn’t appear to be a direct method to modify AD account attributes via workflows.
As a potential workaround, we considered updating an identity attribute and leveraging attribute synchronization to push the change to AD. Unfortunately, SailPoint currently does not support direct identity attribute updates via workflows either.
Given these limitations, we would like to understand:
Is there a supported method to update account-level attributes in AD through workflows?
Alternatively, is it feasible to update an identity attribute in a way that allows it to be synchronized to the corresponding AD account attribute?
If anyone has encountered a similar use case or has suggestions or alternative approaches to achieve this in SailPoint Identity Security Cloud, we would greatly appreciate your input.
Hi @UjjwalJain Attribute synchronization is the closest feature we currently have. But unless the data is aggregated in from another system and it changes a specific identity attribute which forces the synch to AD, then this is not going to accomplish the task for you.
Although transformations can be created and executed to create new or calculate identity attributes, we generally do NOT have the capability to modify data in the cloud tenant. This applies to all applications and systems, not just AD. From Identity Security Cloud, we can manually change a user’s lifecycle state, but not the other account or identity attributes. It is not the solution’s purpose to edit, in the cloud tenant, aggregated data.
Further, the provisioning polices (like the Create Account) are also NOT the place to create new account attributes; rather, use those for MAPPING cloud data or calculating data from the cloud into new user accounts for a set of EXISTING account attributes on that downstream system. We can calculate the values to populate them, but not necessarily create new account attributes that simply do not exist on the other side.
If we talk about cloud rules, we are not allowed to make call-outs from the cloud tenant to any other system, so that’s an important consideration as well.
In summary, the fact that we cannot Directly create new account attributes or directly and easily update them in the context of a workflow mirrors standard functionality of Identity Security Cloud.
That said, we have to ask:
Why do you need to update this account attribute from Identity Security Cloud?
How is this accomplished typically (without ISC)?
I wonder if a cloud-executed Before Provisioning Rule could be leveraged, to update the outgoing provisioning plan with an updated value? (I have not personally done this.)
Can you achieve this with a PowerShell script?
And if so, could you leverage a Before Modify AD rule, to launch a PowerShell script to go do that for you, assuming you are not attempting to do something restricted, as per the rule code restrictions OR doing something outside what’s considered a “managed connection” (as per the first paragraph of the connector rule guidelines)?
Could your workflow leverage the HTTP Request action and launch a MS API call to update the account attribute as part of the workflow?
This question was also asked in the Developer Community. One suggestion was also to NOT use a workflow. Check out the thread here:
I hope this is helpful information, even if not a final solution for you. I am interested if others have thoughts around this or have implemented this or another solution!
Before I answer your questions, let me first explain the scenario we’re dealing with:
We have a use case where a user’s Active Directory (AD) account is set to expire in the next 10 days. In such cases, we notify the user’s manager and provide them with a form to select a new expiration date for the account. The requirement is to take the date selected by the manager and update the accountExpires attribute in AD accordingly.
Now, responding to your points:
Why do we need to update this account attribute from ISC?
Since the updated expiration date is collected as part of a workflow, the ideal approach would be to update the AD account directly from ISC—keeping the process streamlined and automated, without relying on external tools or manual updates.
How is this typically accomplished without ISC?
We’re currently migrating from IdentityIQ (IIQ) to Identity Security Cloud (ISC). In IIQ, we handled this using custom rules that pushed the updated expiration date to AD. We’re now looking to replicate that functionality using native ISC capabilities wherever possible.
Before Provisioning Rule & PowerShell script option –
These two approaches could potentially be combined: a Before Provisioning Rule can be used to modify the provisioning plan, and a PowerShell script can be executed (via a Before Modify AD rule) to update the accountExpires attribute in AD. However, for either of these to work, we would need to trigger provisioning from the workflow—which means the form submission should initiate a modify operation on the AD account and also pass the newly chosen date to the provisioning plan so it can be acted upon during provisioning.
HTTP Request action – This is another option we’re considering. If AD can be updated via an API (e.g., Microsoft Graph), we could potentially call it directly from the workflow using the HTTP Request action, assuming proper permissions and connectivity are in place.
Thanks again for the guidance and for pointing me to the Developer Community thread. If others have implemented something similar in ISC, I’d love to hear about your approach.
so, what I would do is have the form update a time into an attribute which is used as an input on the transform (or just directly setting the attribute) then let it sync to the accountExpires attribute in AD
Thanks for the detailed breakdown. We had a similar idea, but ran into a bit of a snag, to update the account attribute, we’d need to bring in a separate source (delimited), and then use that account attribute in a transform to set the identity attribute, which would eventually sync to the target system.
It does work, but maintaining that delimited source could get a bit cumbersome. Just wanted to check if there’s a cleaner alternative you’ve come across that avoids having to rely on that extra source?
Currently, it is not possible, trigger SNOW ticket to update it manually in AD.
Alternatively, as you have mentioned, you could create CSV source, map to new identity profile with higher priority and use ISC API to update CSV source for identities that requires an update.
But ideally, end date should come from the trusted source so curious to know if you allow change in AD expire date which will be different to end date in trusted source, won’t that create issue? If the trusted source is API based, then you could ask them to create custom attribute which can then be used by ISC to update end date specific to AD assuming that this end date is different from actual exit date of user.
In the future, Sailpoint might add modify AD user or calling bash / ps script method in PTA.
I’m using NELM for the contractors. and we have a process setup to notify managers of the expiring AD accounts (outside of the IdN notices which are also running) which has them raise a ticket to extend the user. The Operations team then processes it in IdN.
end date is updated,
transforms run and converts it,
it syncs down to AD.
we can also put it on the manager to submit it in IdN, have someone approve it and then it applies.
looks like you can use “set attribute values” within a workflow to set the value directly.