LDAP connector: duplicate account entry after account creation

[JustSalva]

Hi all, 

We are experiencing an unwanted behavior with our LDAP connector.

When we provision a new account and then we execute the reconciliation task, we obtain two accounts correlated to the user:

• one with Account ID equals to the user's CN, that gets created after the provisioning and suspended from import service after the reconciliation
• one that is reconciled and has the Account ID equals to the user DN, that is the one we actually created in the target system.

How can we avoid this duplication? is there a way to set the LDAP account ID (in the saviynt account table) in the CREATEACCOUNTJSON configuration? 

Here you can find both our reconciliation and provisioning configurations:

ACCOUNT_ATTRIBUTE

[ACCOUNTID::nameinnamespace#String,
NAME::uid#String,
DISPLAYNAME::fullname#String,
CUSTOMPROPERTY1::cn#String,
CUSTOMPROPERTY2::company#String,
CUSTOMPROPERTY3::givenName#String,
CUSTOMPROPERTY4::sn#String,
CUSTOMPROPERTY5::mail#String,
CUSTOMPROPERTY6::mobile#String,
CUSTOMPROPERTY7::telephoneNumber#String,
CUSTOMPROPERTY8::l#String,
CUSTOMPROPERTY14::loginDisabled#number,
CUSTOMPROPERTY43::objectClass#String,
CUSTOMPROPERTY44::securityEquals#String,
RECONCILATION_FIELD::ACCOUNTID]

CREATEACCOUNTJSON

{
"cn": "${user.username}",
"uid": "${user.username}",
"workforceID": "${user.username}",
"fullname": "${user.lastname} ${user.firstname}",
"company": "${user.companyname}",
"givenName": "${user.firstname}",
"sn": "${user.lastname}",
"mail": "${user.email}",
"mobile": "${user.phonenumber}",
"telephoneNumber": "${user.secondaryPhone}",
"l": "${user.location}",
"loginDisabled": "false",
"objectclass": [
"DirXML-ApplicationAttrs",
"DirXML-PasswordSyncStatusUser",
"inetOrgPerson",
"ndsLoginProperties",
"organizationalPerson",
"Top", 
"Person"
]
}

Kind regards,

Matteo

@nfraternali @FCaremoli 

[rushikeshvartak]

You can change ACCOUNT_ATTRIBUTE 

[ACCOUNTID::cn#String,
NAME::uid#String,
DISPLAYNAME::fullname#String,
CUSTOMPROPERTY1::nameinnamespace#String,
CUSTOMPROPERTY2::company#String,
CUSTOMPROPERTY3::givenName#String,
CUSTOMPROPERTY4::sn#String,
CUSTOMPROPERTY5::mail#String,
CUSTOMPROPERTY6::mobile#String,
CUSTOMPROPERTY7::telephoneNumber#String,
CUSTOMPROPERTY8::l#String,
CUSTOMPROPERTY14::loginDisabled#number,
CUSTOMPROPERTY43::objectClass#String,
CUSTOMPROPERTY44::securityEquals#String,
RECONCILATION_FIELD::ACCOUNTID]

[JustSalva]

Hi, 

that would not work for us, as the unique identifier of the account should be the DN. the CN is not guaranteed to be unique (reconciliation configuration set up as suggested here.

We need the accountID to be setup correctly in the provisioning configuration

[avinashchhetri · Accepted solution]

@JustSalva,

Even the DN would not guarantee the uniqueness. If someone's DN change's for some reason, for e.g if you have to move them to a new OU, or in name change scenarios, it would still end up creating a duplicate record. If your Directory Server has an immutable attribute, that should be used instead as the reconciliation field.

For this current issue of yours, try the following and see if it helps.

Create Two connections, one for Reconciliation and one for Provisioning.

In the reconciliation connection, just keep the reconciliation JSON and remove all provisioning related JSONs. 

In the Provisioning connection, move all your Provisoning related JSONs but also add the ACCOUNT_ATTRIBUTE details.

In the ACCOUNT_ATTRIBUTE parameter, Copy it as it is from your Reconciliation connection except one change as shown below. Map them appropriately in your Security System and try.

ACCOUNTID::dn#String

[JustSalva]

Yes, that's correct, but in this case the DN is the closest object we have to an unique identifier, we will provision and use an unique identifier after an in-depth clean up phase.

Your suggested solution worked seamlessly, thank you!