We have a workflow in SailPoint that identifies stale accounts and disables the corresponding AD accounts. I’m wondering if there’s a way to update the Description field in AD when disabling an account, for example, setting it to something like “Disabled due to stale account”.
Is it possible to update the description attribute in AD directly from a workflow?
If not, are there alternative approaches to achieve the same outcome, such as using an intermediate task or script?
Any guidance or examples on how to implement this would be greatly appreciated.
I’ve done something similar, but for updating the managed by (owner) field in AD. I ended up using a PowerShell script which was called by the “Windows Server” action in a workflow. This approach requires a PTA VA, but is very versatile and allows you to do many things that aren’t easily done inside workflows natively.
Let me know if you have any questions on the approach.
Hi @thoomukb - If your requirement common when handling stale accounts. While Workflows do not have a native “Update AD Attribute” action out of the box, there are reliable ways to achieve this, depending on your environments complexity.
One which Tyler mentioned. However, my suggestion and recommended approach and the most SailPoint native way is to using a “Before Provisioning Rule”. If you just need the description update, go with the Before Provisioning Rule. It is the cleanest architectural approach for Identity Security Cloud.
Would the corresponding identities be in a disabled lifecycle state?
If the identity is still in an active LCS but the AD account is being disabled due to inactivity, the disable provisioning policy could have a static transform to determine whether or not the identity is still active and return “Disabled due to inactivity” as the value for the description field. This assumes the only time there is an active identity with an AD account that’s disabled is due to inactivity. That make sense?
If the identity is going to be in an inactive state and you are licensed for PTA, then what @trettkowski mentioned should work.
Yes, this is usually done with a Before Provisioning Rule on the Microsoft AD source in SailPoint ISC. When the Disable operation is detected, add a Modify operation for the description attribute before the account is disabled.
Example:
accountRequest.add(new AttributeRequest(
"description",
ProvisioningPlan.Operation.Set,
"Disabled due to stale account"
));
You cannot directly make an attribute update through WORKFLOW in AD using LDAP Call.
But, you can do it using following
Option 1
During Account Disablement, create a before provisioning cloud rule and add the required field named as description in provisioning plan and provide the required value of that field inside the cloud rule code.
This approach requires SailPoint involvement as its a cloud rule change
Option 2
Create a Disable Account Policy for AD source
Add field named as 'Description" and provide a static or dyanmic value as per your requirement.
This policy will be triggered everytime, AD disablement account operation will be called wither through workflows or LCS change, etc.
@mcheek Thanks, Mark. That makes sense. In our case, disabled AD accounts are typically due to inactivity, so using a static transform for the description field sounds like a practical approach. I’ll look into it.
And, yes LCS will be active, only AD will be disabled after 45 days of no login.
Thanks, I agree this approach could work. Let me think through it a bit more. My concern is that the Disable operation would also be triggered for terminated users, and in those cases the description would typically need to be something like “Disabled due to termination” rather than “Disabled due to stale account.”
Since my requirement is specifically to identify stale/inactive account disables, I may need additional logic to distinguish between stale account disablements and termination-driven disablements. Appreciate the help.
Thanks, I agree with your suggestions. Option 2 seems like the simplest approach to start with.
One question though: is there a way to distinguish whether the disablement was triggered by an LCS change (for example, termination) versus a stale/inactive account process? Ideally, I’d like to update the Description attribute differently based on the reason, for example, “Disabled due to termination” for LCS-driven disables and “Disabled due to stale account” for inactivity-based disables. Have you seen this implemented before?
Thanks, Kannan. I agree that the Before Provisioning Rule seems like the cleanest and most native approach for ISC.
One question: would the rule be able to distinguish the reason for the disablement? For example, can it identify whether the disable action is coming from a Lifecycle State change (termination) versus a stale/inactive account process and update the Description accordingly? Or would it apply the same Description value for all disable operations unless we add additional logic?
Thanks, Mark. This is actually what I’m thinking as well.
In our case, the identity would remain Active while only the AD account is disabled due to inactivity. So I’m wondering if we can leverage a static/dynamic transform in the Disable Provisioning Policy to check the identity’s lifecycle state and set the Description accordingly.
Do you happen to have an example of the transform JSON for this scenario?
The reason I’m being cautious is that today all disable operations update the Description to “Disabled due to termination,” and I don’t want to accidentally impact that existing process. I’d like to only set “Disabled due to inactivity” when the identity is still Active and the disablement is specifically related to stale account handling.
