AD OU Movement Not Functioning

Hi, Good day. Just want to ask about the OU Movement for AD. We have before provisioning rule attached on the Target AD that checks if Business Area was changed then Attribute Sync will trigger in the rule. However, condition did not meet as the OU did not move to what is expected to be. Here is our code.

Before Provisioning Rule:

.
.
.
if (accountRequests != null) {
        for (AccountRequest accountRequest: accountRequests) {
            AccountRequest.Operation op = accountRequest.getOperation();
            if(op == null) continue;
.
.
.
boolean departmentChanged = false;
				if(op.equals(AccountRequest.Operation.Modify)){
					List dAttrReqs = accountRequest.getAttributeRequests("businessArea");
					if(dAttrReqs != null && !dAttrReqs.isEmpty()){
						departmentChanged = true;
					}
				}
.
.
.
else if(("active".equalsIgnoreCase(currentLCS)) && op.equals(AccountRequest.Operation.Modify) && departmentChanged){
				
					cn = getCN(pParam.toUpperCase());
					dn = "CN=" + sAMAccountName;
					
					addAttributeRequest(accountRequest, "AC_NewName", dn);
					addAttributeRequest(accountRequest, "AC_NewParent", cn);
				}

Identity Attribute: Business Area (businessArea)
Target AD: Company
AttributeSync: Identity Attribute (Business Area), Account Attribute (Company)

We also checked and followed this document: Best Practices: Attribute Sync - Compass (sailpoint.com)

Hope you can help us on how to move OU based once there is a change in the Authoritative Source.

Thank you very much.

Hi,

As per the code shared by you, the elseif block which moves the OU always sees departmentChanged as false and hence it never meets the condition and executes the code within the block.


if (accountRequests != null) {
for (AccountRequest accountRequest: accountRequests) {
AccountRequest.Operation op = accountRequest.getOperation();
if(op == null) continue;
.
.
.
boolean departmentChanged = false;
if(op.equals(AccountRequest.Operation.Modify)){
List dAttrReqs = accountRequest.getAttributeRequests(“businessArea”);
if(dAttrReqs != null && !dAttrReqs.isEmpty()){
departmentChanged = true;
}
}
else if((“active”.equalsIgnoreCase(currentLCS)) && op.equals(AccountRequest.Operation.Modify)){

				List dAttrReqs = accountRequest.getAttributeRequests(“businessArea”);
				if(dAttrReqs != null && !dAttrReqs.isEmpty()){
						departmentChanged = true;
				}
				
				if(departmentChanged)
				{
				cn = getCN(pParam.toUpperCase());
				dn = "CN=" + sAMAccountName;
				
				addAttributeRequest(accountRequest, "AC_NewName", dn);
				addAttributeRequest(accountRequest, "AC_NewParent", cn);
				}
}

Can you try this?

1 Like

Hi @mgambayan I am not sure of the requirement but what i observe from the code is that the DN updation code is in elseif block which will only evaluate if above if/elseif blocks evaluate to false.
I would suggest if you are using the flag departmentChanged, then rather than having the DN change code in elseif block change it to if This will mean that once you see attribute sync and department variable is changed to true, it will again goto this if condition and change the DN with your logic.
Also i see that when you are using AC_NewParent, you are only sending the CN=+SamaccountName. Whereas it should be full DN including OU value see the updated code below…

//
//
//
	if (accountRequests != null){
	  for (AccountRequest accountRequest:accountRequests){
			AccountRequest.Operation op = accountRequest.getOperation ();
			if (op == null)
			  continue;
//
//
//
			boolean departmentChanged = false;
			if (op.equals (AccountRequest.Operation.Modify)){
				List dAttrReqs = accountRequest.getAttributeRequests ("businessArea");
				if (dAttrReqs != null && !dAttrReqs.isEmpty ()){
					departmentChanged = true;
				  }
			  }
//
//
//
            //Changed it from else if to if
			if (("active".equalsIgnoreCase (currentLCS)) && op.equals (AccountRequest.Operation.Modify) && departmentChanged){
				cn = getCN (pParam.toUpperCase ());
				dn = "CN=" + sAMAccountName;
				String fullDN = "OU=People,OU=Active,DC=XYZ,DC=com"
                addAttributeRequest (accountRequest, "AC_NewName", dn); //this is done to rename the AD account if not renaming the CN would suggest don’t use this.
  		        addAttributeRequest (accountRequest, "AC_NewParent", fullDN); //Recommended to move the OU of the user and not renaming the AD account.
			  }

		  }

Hope this helps…

1 Like

When moving an OU, it is recommended to re-generate the CN since this is a unique field in Active Directory. If you move to an OU and the value is not unique, AD will generate an automated unique value that can get messy and may not follow the standards set by the organization. Here is a sample of how you can check for uniqueness:

// Max counter for unique CN.
int CN_UNIQUE_CHECK_MAX = 100;
public String generateCN(String applicationName, String currentCN, String OU, String nativeIdentity) {
    String newDN = "CN=" + currentCN + "," + OU;
    if (null != nativeIdentity && nativeIdentity.equalsIgnoreCase(newDN)) {
        return null;
    } 

    boolean accountExists = idn.accountExistsByNativeIdentity(applicationName, newDN);
    if (!accountExists) {
        return currentCN;
    }

    String newCN = null;
    // Iterations for unique values.
    for (int i = 1; i < CN_UNIQUE_CHECK_MAX; i++) {
        String tempCN = currentCN + " " + i;
        newDN = "CN=" + tempCN + "," + OU;
        accountExists = idn.accountExistsByNativeIdentity(applicationName, newDN);
        if (!accountExists) {
            newCN = tempCN;
            break;
        }
    }
    
    return newCN;
}  

The AC_NewParent should be the OU alone, not including the CN.

Check out this documentation on Best Practices for AD Moves.

1 Like

Hi Shailee,

Good day. We will try this approach. Thank you for your inputs.

Thank you very much.

Hi Neeraj,

Good day. Thank you for your suggestions.

Thank you very much.

Hi Braden,

Good day. Thank you for your inputs and the link you have provided. We will also check on this.

Thank you very much.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.