New "AC_NewName" & "AC_NewParent" not aggregating back to ISC

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

Hi all,

I am using a before provisioning rule to change the cn & dn of a AD account. I am not updating both at once. Its either CN or DN.

Adding the snippet:

accountRequest.add(new AttributeRequest("AC_NewParent", ProvisioningPlan.Operation.Add, newOU));

accountRequest.add(new AttributeRequest("AC_NewName", ProvisioningPlan.Operation.Set, escapedCN));

I can see the trigger is happening as i can see the Attribute Request from ISC Search passing the desired values.
I checked in AD directly, & i can confirm that indeed on the target the CN & DN both are changing properly.

But they are not getting updated in ISC automatically.
Here’s what’s happening:: (Before Prov Plan Triggers → Target AD gets Updated → ISC Sometimes gets updated sometimes does not).
Now when i say sometimes i am seeing this inconsistency as sometimes the New CN/DN is populated but most of the times it is not.

So the single account aggregation fails (as the DN/CN has changed on AD and ISC still has Old CN/DN)

In order to see the latest changes i have to do a full account aggregation which is quite resource intensive in our case. So doing a full aggregation is Out of picture for us.

Edit:
Here’s a screenshot from Search listing attribute requests which successfully passed:

image
image1023×411 18.3 KB

Here’s account on ISC:

image
image1918×530 25.7 KB

Here’s what happens when i try to aggregate (single account aggregation)
image

And i checked on AD the CN is updated properly along with other attributes..

Has anyone else faced this issue?

2

Hi @neeraj99 Any naming convention that matches the failed attribute updates? Wondering whether any special (to LDAP) characters in AC_NewParent or AD_NewName?

3

Thats the problem,
There are no errors/failures. It updated properly but its just not aggregating the updated information back to ISC. On target its updated with the new information.

4

Yeah, appreciate no errors, but the single aggregation that occurs after rename is not, I would guess, standard code so it may not be matching any special characters in DN. I was just wondering whether you had commas or anything like that in the one’s that are not immediately aggregated back.

5

Ah, I can see in your screenshot that you are replacing a ‘.’ with a ', '. I also see that you have an attribute of ‘escapedCN’. Are you using javax.naming.ldap.Rdn.escapeValue() to escape the value?
Single aggregation won’t work in this case, because the DN hasn’t been updated to new value.

1 Like
6

No i am using a regex to escape any special characters.
String escapedCn = generatedCn.replaceAll("([,\\\\#+<;>=])", "\\\\$1");

And, does it make any difference changing ‘.’ to ‘,’ ? because i am eventually changing the CN (which in turns automatically changes the DN).

7

Hi @neeraj99 From Active Directory Connector - FAQ and troubleshooting - Compass its recommended to use javax.naming.ldap.Rdn.escapeValue()

8

Oh i see, will make that change in next rule deployment… but for now; both are doing the same thing of escaping the characters like (, " \ etc) right?
And the reason why i am saying this is to rule out the possibilities of what may be messing this up sometimes…

as far as Target is concerned i can see AD getting updated with proper information.

9

I understand that target is getting updated. My point is that when you use NewName/NewParent there is additional code to trigger a single aggregation of the “assumed” new DN. The assumed new DN doesn’t appear to be matching the new DN so can’t aggregate. My guess is it is because of special characters and the recommended use of that specific library implies that there is something mandated in this area.

10

Ok @j_place, so letme make that change and see if that gets resolved.

& Just in case to check for the OU update as well. OU’s are like this: OU=Users,OU=Active,DC=sailpoint,Dc=com

So don’t need to do escaping for this OU right?

11

Hi Neeraj, agreed not needed for that OU. I, personally, would escape both for consistency and portability, but up to you.

1 Like
12

Hi @neeraj99 -

For AC_NewParent, you seem to be using Operation Add, which might be causing the issue. Can you change it to match your AC_NewName’s Operation Set instead?

If you need examples, refer to this article:

Hope this helps with the inconsistency. Additionally, try to deploy another rule without the CN change to see if the issues only occur when you do CN changes. I don’t suppose that should be the case, but consider this for future debugging.

13

Hello,

When you are AC_NewParent and AC_NewName in your Active Directory Implementations whenever there is Name Change or DN changes for your identity, I have observed that the updates takes place in the AD successfully but post updates in AD, when the connector gives the response back to ISC, there is a Lag due to which the operations throws an exception.

In short, the data in ISC is not in sync with AD as far as new CN and new DN is concerned though the updates are successfully done in MS AD.

I have observed during the next full aggregation or delta aggregation from AD, the details are synced back successfully to ISC.

There are following approaches through which we can achieve this.

Approach 1.

  1. When there is a CN or DN change we have to trigger, create an corresponding identity attribute in your identity profile, map it to AD create profile and enable the attribute sync.
  2. As soon as in the Modify Account Provisioning Plan, this attribute is included, in the before provisioning rule, you can add the logic of CN and DN change using AC_NewName and AC_NewParent attributes respectively.

Approach 2:

  1. Using Before Modify Connector Rules to do the same and add some sleep in your scripts before and after making the changes to CN and DN.
  2. Also, increase the AD provisioning timeout to 90 to 120 seconds depending upon your response and sleep period put in the PowerShell script.

Thank You,

Regards,
Rohit Wekhande.