Active Directoty Before Provisioning Rule

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hello everyone,

Need help on one issue I am getting for Action Directory deprovisioning.

In my before provisioning rule, on the disable operation, I am setting Description and removing all groups from users and then moving the user to Disable OU using AC_NewParent way.

On this disable operation, I am getting the error as below:

sailpoint.connector.ObjectNotFoundException: [ ObjectNotFoundException ] [ Possible suggestions ] Ensure that account - CN=PIMAdmin3,OU=xyz,OU=Dead Accounts,DC=aaaa,DC=com exists. [ Error details ] ObjectNotFound [LDAP: error code 32 - 0000208D: NameErr: DSID-0310028D, problem 2001 (NO_OBJECT), data 0, best match of: ‘OU=xyz,OU=Dead Accounts,DC=aaaa,DC=com’ ]

When I checked at AD source, Account moved to disabled OU, disabled, and removed groups, and updated description. It is just showing error in events.

At sailpoint side account is showing disabled after next aggregation only.

What should be the reason for this one?

2

Hello @singlde , The issue is that after AC_NewParent moves the account to the new OU, ISC still holds the original DN in the plan — so subsequent operations (disable, group removal, attribute update) are fired against the old DN, which no longer exists there, causing the ObjectNotFoundException.

Instead of handling AC_NewParent in the BeforeProvisioning rule, consider setting it directly in the Disable Lifecycle Policy. This way, ISC carries the new parent forward naturally across all subsequent operations without the DN mismatch.

If you must keep it in the rule, explicitly update the nativeIdentity after setting AC_NewParent: extract the CN from the old DN, append the new OU, and call accountRequest.setNativeIdentity(newDN).

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

for (AccountRequest accountRequest : plan.getAccountRequests()) {
    if (ProvisioningPlan.ObjectOperation.Disable.equals(accountRequest.getOp())) {

        // Set the new parent OU
        String newOU = "OU=Dead Accounts,DC=aaaa,DC=com";
        accountRequest.add(new AttributeRequest(
            "AC_NewParent",
            ProvisioningPlan.Operation.Set,
            newOU
        ));

        // Update nativeIdentity to new DN so subsequent operations use correct location
        String oldDN = accountRequest.getNativeIdentity();
        String cn = oldDN.substring(0, oldDN.indexOf(","));  // Extract CN=PIMAdmin3
        String newDN = cn + "," + newOU;
        accountRequest.setNativeIdentity(newDN);
    }
}

This tells ISC the account’s new location and resolves the error immediately without waiting for the next aggregation.

Thanks,

@SivaLankapalli

3

Hi @singlde ,

Kindly set the the new dn as native identity in the account request in before provisioning plan. It will works

Thank you

Harikrishna.

4

Hi,

Instead of Rule you can achieve the same using Disable Provisioning Policy

5

Thanks, Could you please let me know where and how I can define Disable Provisioning Policy?

6

You can do using API or using Visual Studio Code.

Visual Studio Code → Source → Active Directory → Provisioning Policy → Disable Provisioning Policy → Add Name → Add AC_NewParent as attribute and then add the OU in which you need to move.

Let me know if you need the complete configuration for the same

7

Thanks, I can follow the same, however it would be great if you can provide more insight or full config. Sorry I am new to ISC.

8

Not Sure, but there is same error, I removed the before provisioning rule just to check the Disable policy and there seems to be same error, using disable policy I am moving in the same ou

9

This happens because after your rule moves the account to the Disabled OU using AC_NewParent, Microsoft AD connector still tries to continue operations on the old DN during the same transaction. That causes LDAP error 32 (NO_OBJECT) since the original path no longer exists.

Usually fix is:

  • perform the move operation last

  • or split move/disable into separate provisioning steps

  • or refresh/rebind the DN after move in the rule.

10

@singlde

I have come across this issue whenever I do the AD move using AC_NewParent approach which is the only way to do it.

There are 2 ways to fix it.

Option 1

  1. Use a Single Domain Controller for AD so that each request goes to only 1 DC. This also happens sometimes due to Load Balancer’s in front of DC
  2. It’s always recommended to use load balancer though for better performance.
  3. This has to be thoroughly tested with multiple load tests involved before you finalize the solution

Option 2

  1. The AC_NewParent operation should be Moved Last deliberately so that all prior modifications are done prior to OU movement
  2. Use an AD After Modify Connector Rule to perform this operation.
11

Thanks Rohit, I figured it out the same thing and it was not Before Provisioning Rule or disable provisoining policy issue. We were using the Load Balancer and for now we have removed from source config and using the single DC which resolved the issue.

Working with another team for load balancer issue.

12

Thanks! Glad to know that.

Regards,

Rohit