AC_NewName being updated many times

We have AC_NewName in the Update profile as “CN=$sAMAccountName” because a user’s sAMAccountName may change based on their type and we want those changes to be reflected in Active Directory.

The changes are going through as expected but we are seeing a Modify request being sent each day from attribute sync even when the value has not changed.

{
    "name": "Account",
    "description": null,
    "usageType": "UPDATE",
    "fields": [
      {
        "name": "AC_NewName",
        "transform": {
          "type": "concat",
          "attributes": {
            "values": [
              "CN=",
              {
                "type": "identityAttribute",
                "attributes": {
                  "name": "samaccountname"
                }
              }
            ]
          }
        },
        "attributes": {},
        "isRequired": false,
        "type": "string",
        "isMultiValued": false
      },
      {
        "name": "sAMAccountName",
        "transform": {
          "type": "identityAttribute",
          "attributes": {
            "name": "samaccountname"
          }
        },
        "attributes": {
          "cloudRequired": "true"
        },
        "isRequired": false,
        "type": "string",
        "isMultiValued": false
      }
    ]
  }

Hey Edward,

It is to my understanding that the usageType of “UPDATE” and all others that are not “CREATE” are not currently supported for Active Directory (you can reference my topic about Provisioning Policies (link)).

To me, it looks like you’re trying to sync the “samaccountname” Identity Attribute with the AC_NewName field, but with some modifications. In order to do this, you will have to create an Identity Attribute for the AC_NewName field that already has its modifications, and this logic will have to be performed on the Identity level, like below:

Identity Attribute Transform

{
    "name": "acNewName",
    "type": "concat",
    "attributes": {
        "values": [
            "CN=",
            {
                "attributes": {
                    "values": [
                        {
                            "attributes": {
                                "attributeName": "sAMAccountName",
                                "sourceName": "Active Directory"
                            },
                            "type": "accountAttribute"
                        },
                        "null"
                    ]
                },
                "type": "firstValid"
            }
        ]
    }
}

Once that has been defined, simply define a value for the AC_NewName attribute in your CREATE profile by setting it to the newly created Identity Attribute value (note that you will have to add the attribute into the Provisioning Policy via the API first):

AD Create Profile (“CREATE” Provisioning Policy)

{
    "name": "Account",
    "description": null,
    "usageType": "CREATE",
    "fields": [
        {
            "name": "AC_NewName",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "acNewName"
                }
            }
        },
        {
            "name": "sAMAccountName",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "samaccountname"
                }
            },
            "attributes": {
                "cloudRequired": "true"
            },
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}

Create Profile UI


Then, proceed to the Attribute Sync tab and check the “Sync with Identity” box for this attribute:

Attribute Sync Configuration

I believe this will accomplish what you’re looking to do. Please let me know if you learn anything else that may also be of use to me! I would love to use the UPDATE provisioning policy if it were to become available.

I have used AC_NewParent to move users to a new OU for several clients and all are working as expected. The only caveat being that the Account Attribute is not updated until the next AD aggregation.

So that being said, the UPDATE profile still works but it seems AC_NewName is having issues which may be for the reasons you mentioned. I am not sure I want to add AC_NewName as an AD attribute as it would most likely show an warning during creation if it does not exist in Active Directory.

See this post for a different use case where adding cloudLifecycleState showed an error: Failed to Update Attribute

Hey @ethompson, I misunderstood the situation when I wrote my first reply. I didn’t realize the AC_NewParent and AC_NewName were different components of IDN functionality for distinguishedName modifications. This was a great discovery for me, and I am able to use it as a better method for appropriate OU placement.

I have built this functionality into my clients’ functionality, and it’s working well. Through this implementation, I found that the method described in this thread is outside best practices. The article that explains what can be done vs. should be done is here: Article Link.

It looks like the reason you are having these errors and the updates taking place is because the AC_NewName and AC_NewParent attributes aren’t actually attributes that can be verified, but when they are updated through the UPDATE provisioning policy, an automatic check for the updated value is executed, which returns as a failure, since the value doesn’t actually exist in AD, nor is it verifiable.

This can be implemented into a Before Provisioning rule. I modified the example to fit the needs that my client has, but Rules have to be vetted, approved, and created by Expert Services, which is a billable service. I may be wrong about this process, but that’s my current understanding.

Below is the script for the rule, which has 3 “use cases”: Enable (previously disabled), Move, Disable.

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;
        String nativeIdentity = accountRequest.getNativeIdentity();
        Identity identity = plan.getIdentity();
        String currentLCS = null;
        String activeOU = null;
        String disabledOU = null;
        if(identity != null){
            currentLCS = identity.getAttribute("cloudLifecycleState");
            activeOU = identity.getAttribute("parentOu");
            disabledOU = "OU=Disabled Users,DC=xxx,DC=com";
        }
        
        boolean departmentChanged = false;
        if(op.equals(AccountRequest.Operation.Modify)){
            List dAttrReqs = accountRequest.getAttributeRequests("department");
            if(dAttrReqs != null && !dAttrReqs.isEmpty()){
                departmentChanged = true;
            }
        }

        String newOU = null;
        if ("active".equals(currentLCS) && op.equals(AccountRequest.Operation.Enable)
            && disabledOU != null && activeOU != null && nativeIdentity.endsWith(disabledOU)){
            //Account is disabled and needs to be re-enabled.
            newOU = activeOU;
        }
        else if ("active".equals(currentLCS) && departmentChanged && activeOU != null){
            //Department has changed--move user to appropriate OU.
            newOU = activeOU;
        }
        else if("terminated".equals(currentLCS) && op.equals(AccountRequest.Operation.Disable)){
            //User has been terminated, move to disabled OU.
            newOU = disabledOU;
        }
        if(newOU != null && !nativeIdentity.endsWith(newOU)){
            //If changes have been identified, adjust OU for the user.
            accountRequest.add(new AttributeRequest("AC_NewParent", ProvisioningPlan.Operation.Set, newOU));
        }
    }
}

Hope this helps. This discussion with you has absolutely helped me.

@brennenscott This is correct. We actually deployed a rule similar to this earlier this week and I can confirm it is working. We are setting AC_NewName during the Modify Operation and if we see sAMAccountName is in the Attribute Requests.

@ethompson that’s awesome to hear that it’s working for you. Would you say the deployment of the rule was worth the time, and was it something that was a difficult process to go through? I’m curious if that’s the direction in which I should move as well.

Hi Brennen,

Could you please check the below link I have similar issue.

Regards,
Yamini

We are seeing that IDN is not able to move accounts to the disabledUsers OU for some users when they are terminated. The majority of the cases are due to a DN conflict with another account already in the disabledUsers OU. More specifically a conflict with the CN portion of the DN.

Some of those cases are caused by accounts created before IDN went live, so they might have been created with a non-unique DN, but some others were created by IDN, so it is no clear why IDN generated the same CN as another account already in AD.