LDAP Account Move during provisioning (LDAP Connector)

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

Hi,

Using the Create Account policy and the “Attribute Sync” assistant, the following attributes were defined to be synchronized with the account as an attempt to move the LDAP entry to another OU (executed separately):

  • DN
  • distinguishedName
  • (newrdn,newsuperior,deleteoldrdn)

However, the account is not moved but the attributes are included as plain account attributes, similar to the case of sn, givenName, etc.

Is there a known method to achieve this process or a certain parameter that needs to be configured that is probably missing?

Thanks in advance.

2

Hi @OS111 ,

I believe you can achieve this using a Before provisioning Rule. Same as what is described here for AD moves - Best Practices: Active Directory Account Moves - Compass (sailpoint.com)

Thanks,
Shailee

3

Hi @shaileeM ,

The post uses the following code to update the provisioning plan:

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

However, I understand that the attribute AC_NewParent is used specifically for the AD connector. Can the attribute be used for the alternate LDAP connector that supports other managed systems? (Linked below)

Supported Managed Systems (sailpoint.com)

4

Hi @OS111 ,

Regarding moving the accounts to a different container in LDAP, you should be able to achieve this by updating the distinguished name of the account. You should be able to update the DN attribute of the user instead of “AC_newParent” which is used for ADs.

Thanks

5

Hi @shaileeM,

I executed some tests using the “not recommended” method (without a rule) using the attribute synchronization feature with an identity attribute. The “dn” attribute is included in the account creation policy and in the “Attribute Sync” assistant. However, the following happens:

  1. The account is created successfully based on the mapping.
  2. When the identity attribute changes, the synchronization is triggered but creates an additional attribute in the LDAP entry named “dn” and the account location is not changed.

Any suggestions to synchronize the “true” distinguished name and prevent the creation of the additional attribute?

Thanks.

6

Hi @OS111 , okay understand.

I believe since you are using the attribute sync way, the LDAP OU move for the user is not happening in real-time.

So in order to move the user and prevent the duplicate “dn” to be created, you can immediately aggregate the account after the attribute sync and see if you are able to see the expected result/move. Alternately you can try using Before provisioning Rule for the “dn” update to move the user to the new OU.

Please let me know how it goes.

Thanks,
Shailee

7

Hi @shaileeM,

Both methods were tested, but the additional attribute is still created and remains in the account after account aggregation. I am using the default schema that defines the “dn” attribute as the account ID and “uid” as the account name.

The rule snippet used to update the DN is the following:

accountRequest.add(new AttributeRequest("dn", ProvisioningPlan.Operation.Set, newDN));

Is there a configuration probably missing or a better way to approach the change through the rule?

Thanks for the help so far.

Best,

8

Hi @OS111 ,

Is it possible to share the logic snippet of the rule? Is it remove “dn” attribute followed by add “dn” attribute? OR Is it only add of “dn” attribute?

Thanks

9

Hi Octavio,
I don’t think OU moves are support for LDAP connector.

Thanks
Rakesh Bhati

10

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