Identities are moved but not disabled in Active Directory

[rt111 (Ricardo Then)]

Hi everyone,

I have a support ticket with SailPoint regarding an issue that I am running into, but I figured I would post it here as well to see if anyone has run into the same or similar issue in the past.

In our SailPoint environment when an account status changes from active to inactive (the status is based on data obtained from a database), the account is moved to a given OU within our Active Directory (AD) tenant, and their AD account is disabled.

The issue that I am observing is that for some reason accounts that goes from active to inactive are moved to their new respective OU, but SailPoint is failing to disable it in AD. It appears to me that this is happening because SailPoint is referencing the old distinguishedname attribute value before being moved. So when attempting to disable it, it can’t find it in AD, failing with an error. For some reason, it is not retreiving the new distinguishedname fast enough to let SailPoint know where the account has been moved to so that it can disable it in AD.

I can’t find any sort of pattern as this is happening with different accounts types located in different OUs. They are also being placed into different OUs depending on the type of account SailPoint is dealing with. For example, on a given day, SailPoint was able to successfully moved AD accounts from one OU to another as well as disable the AD account for about 1,000+ accounts, but failed to carry out the same operation against ~15 accounts on the same day.

Has anyone run into this issue before? If so, were you able to fix it?

Thank you,
Ricardo T.

[Carlatto (Carl Nelson)]

How are you doing the account moves? Is it via Attribute Sync, or via a Before Provisioning Rule, or something else?

[anneragh (Raghunath Anne)]

@rt111

Before provisioning rule is a preferred approach if you not already using it. “AC_NewParent” is an attribute that needs to be set with a new OU, to move accounts in before provisioning cloud rule. Otherwise, the disable account(any action) will fail if IdentityNow tries to perform disable after the account move.

Best Practices: Active Directory Account Moves

[rt111 (Ricardo Then)]

Hello,

We are not using a before provisioning rule and instead, we are using a provisioning policy. The policy provisioning changes AC_NewParent based on a reference transform. The transform calculates the updated DN based on a lookup table and user type.

Thank you,
Ricardo Then

[Mahesh_Mukku]

Hi @rt111 ,
Good Day!

For AC_NewParent first calculate lifecycle state then it will work below is the reference code

{
“name”: “Account”,
“description”: null,
“usageType”: “UPDATE”,
“fields”: [
{
“name”: “AC_NewParent”,
“transform”: {
“attributes”: {
“lcs”: {
“attributes”: {
“name”: “cloudLifecycleState”
},
“type”: “identityAttribute”
},
“value”: “#if($lcs == ‘termination’) OU=Terminated,DC=test,DC=com #else#end”
},
“type”: “static”
},
“attributes”: {},
“isRequired”: false,
“type”: “string”,
“isMultiValued”: false
}

[Carlatto (Carl Nelson)]

I am going to make an assumption that your system is disabling the AD account via Identity Proflie Provisioning. Then secondarily it sounds like it is using a Provisioning Policy/Attribute Sync to update the OU.

If that is the case, then it sounds like you have a race conditioning occuring, where those 2 actions are trying to occur at the same time (or near same time) and it is causing the disable to fail.

In AD the account ID is the distinguished name (ex. CN=TestUser,OU=abc,DC=isc,DC=com). If both actions are occuring at the same time they will look something like:

1. Account: CN=TestUser,OU=abc,DC=isc,DC=com, Operation: Set “AC_NewParent” to OU=inactive,DC=isc,DC=com

2. Account: CN=TestUser,OU=abc,DC=isc,DC=com, Operation: Disable Account

When the first action occurs, the account’s distinguished name is changed to CN=TestUser,OU=inactive,DC=isc,DC=com, which then causes the second action to fail since it is looking for CN=TestUser,OU=abc,DC=isc,DC=com but that no longer exists as the account is now CN=TestUser,OU=inactive,DC=isc,DC=com

To resolve this you need to have both actions sent in the same process. That is where a BeforeProvisioningRule comes in. Create a rule that will look to see when AccountRequest.Operation.Disable is occuring. Then add an accountRequest for moving the OU.

Here is an example. I have not tested this script, and can’t guarantee that it will work, but it is based off similar Rules we have in our environment. If you don’t have experience with BeforeProvisioningRules, you might want to talk with Expert Services.

import sailpoint.object.Identity;
import sailpoint.object.ProvisioningPlan;
import sailpoint.object.ProvisioningPlan.AccountRequest;
import sailpoint.object.ProvisioningPlan.AttributeRequest;

List accountRequests = plan.getAccountRequests();
if (accountRequests != null) {
  for (AccountRequest accountRequest: accountRequests) {
    AccountRequest.Operation op = accountRequest.getOperation();
    if(op == null) continue;
    Identity identity = plan.getIdentity();
    newOU = identity.getAttribute("AD-OU"); //pulls new OU from the Identity Attribute "AD-OU" or whatever you want to use
    if(op.equals(AccountRequest.Operation.Disable)){
      accountRequest.add(new AttributeRequest("AC_NewParent", ProvisioningPlan.Operation.Set, newOU)); //moves the account to the new OU
    }
  }
}

[rt111 (Ricardo Then)]

Hello,

Thank you everyone for their suggestions. The reason as to why we didn’t go down the route of using before provisioning rules was to keep it simple and avoid having to go through expert services. But it sounds like this is the only option and will need to revisit this. We were not aware that using the current method would run into this issues. During our tests we also did not run into this issue, but to be fair we were testing with a smaller number of accounts, so the chances of running into this issue was lower.

Thank you