mismatch with the data in LDAP integration

[Roua]

Hello,
We are experiencing a mismatch with the data in our LDAP integration, particularly related to differences in capitalization(marked with red) and spacing (marked with underline _).
we tried all debugging method and data comparison.
Below is the detailed information of the issue:

LDAP Browser (targeted system) Data:

cn=business & yzx services yxzt   999x ermw99966655

cn: Business & YZX Services YXZT 999X ermw99966655

displayName: Business & YZX Services

entryDN: cn=business & yzx services yxzt 999x ermw99966655,ou=org,ou=groups,o=xxxx

uniqueMember: uid=YX0000965,ou=ff,ou=www,o=xxxxx .

screenshots: 

click on CN and a new one would open like the following Business & YZX Services YXZT 999X ermw99966655:

Saviynt Entitlements: we have two entitlement mapped:

First Entitlement:

cn: Business & YZX Services YXZT 999X ermw99966655,ou=org,ou=groups,o=xxxx

No entitlement attributes data mapped

Entitlement Value:
cn: Business & YZX Services YXZT   999X ermw99966655,ou=org,ou=groups,o=xxxx

Mapped User:

orclSourceObjectDN: uid=er554477,ou=oiff,ou=users,o=xxxx  

cn: u554477

uid: er00554477

(there weren't any of the accounts in LDAP browser )

Second Entitlement:

• cn: business & yzx services yxzt 999x ermw99966655,ou=org,ou=groups,o=xxxx
• Entitlement Value:
  cn=business & yzx services yxzt 999x ermw99966655,ou=org,ou=groups,o=xxxx
• Attributes Data Mapped:

(CP1) CN: Business & YZX Services YXZT   999X ermw99966655

 Connection configuration: 
ACCOUNT_ATTRIBUTE:

Spoiler

[ACCOUNTID::entryDN#String,NAME::cn#String, DISPLAYNAME::displayName#String, CUSTOMPROPERTY1::employeeNumber#String, CUSTOMPROPERTY2::givenName#String, CUSTOMPROPERTY3::sn#String, CUSTOMPROPERTY4::mobile#String, CUSTOMPROPERTY5::mail#String, CUSTOMPROPERTY6::employeeType#String,CUSTOMPROPERTY7::c#String,CUSTOMPROPERTY8::uid#String,CUSTOMPROPERTY9::entryUUID#String, CUSTOMPROPERTY10::ou#String,
customproperty13::title#String,customproperty15::middleName#String, customproperty16::telephoneNumber#String, customproperty17::personalTitle#String, customproperty18::physicalDeliveryOfficeName#String,
customproperty40::fullWinLogin#String,
customproperty25::departmentNumber#String,customproperty26::personalTitle2#String, customproperty29::title2#String,customproperty31::objectCategory#String,customproperty32::activeEntry#String,customproperty34::st#String,status::activeEntry#String, RECONCILATION_FIELD::CUSTOMPROPERTY9]

ENTITLEMENT_ATTRIBUTE:

isMemberOf

UPDATEACCOUNTJSON;

Spoiler

{
"cn": "${user.customproperty3}",
"c": "${user.country}",
"displayName": "${user.displayname}",
"l": "${user.city}",
"employeeNumber": "${user.employeeid}",
"employeeType": "${if (user.employeeType == 'I') {'Internal'} else {if (user.employeeType == 'E') {'External'} else {''}}}",
"givenName": "${user.firstname}",
"ou": "${user.departmentname}",
"personalTitle": "${user.title}",
"name": "${user.username}",
"title": "${user.customproperty1}",
"telephoneNumber": "${user.phonenumber}",

"uid": "${user.customproperty3}",
"sn": "${user.lastname}",
"title2": "${user.jobDescription}",

}

ENABLEACCOUNTJSON:

Spoiler

{
"USEDNFROMACCOUNT": "YES",
"MOVEDN": "YES",
"REMOVEGROUPS": "NO",
"ENABLEACCOUNTOU": "${'OU=' + user.country + ',OU=users,o=xxxx}",
"AFTERMOVEACTIONS": {
"activeEntry": 1,
"HCMStatus": "${user.customproperty12}",
"msExchExtensionCustomAttribute1": ""
}
}

BASE 

OU=users,O=XXXX

CHECKFORUNIQUE:

Spoiler

{
"cn": "${user.customproperty3}###${user.customproperty3}",
"samaccountname": "${user.username}###${user.customproperty3}",
"userPrincipalName": "${user.username}@saviynt.com###${user.customproperty3}@saviynt.com"
}

REMOVEACCOUNTACTION

Spoiler

{
"msExchExtensionCustomAttribute1": "${Calendar.getInstance().getTime().format('MM/dd/yyyy')}",
"HCMStatus": "${user.customproperty5}",
"deleteAllGroups": "No",
"activeEntry": "0",
"moveUsertoOU": "${if(user.customproperty5 == 'P'){'OU=TemporaryLeave,OU=Usr,OU=DisabledObjects,DC=xxx,DC=local,DC=at'}else {'OU=Exited OutOfOffice,OU=Usr,OU=DisabledObjects,DC=xxxx,DC=local,DC=at'}}"
}

groupImportMapping

Spoiler

{
"entitlementTypeName": "isMemberOf",
"performGroupAccountLinking": "true",
"importnestedmembershipoutofscope": "true",
"incrementalTimeField": "modifyTimestamp",
"groupObjectClass": "(|(objectclass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=groupOfURLs))",

"importGroupHierarchy": "true",
"mapping": "memberHash:uniquemember_char,displayName:cn_char,entitlement_value:entryDN_char,customproperty1:cn_char, customproperty3:gid_char,description:cn_char,customproperty2:entryUUID_char,lastscandate:modifyTimestamp_customDate--yyyyMMddHHmmss,updatedate:modifyTimestamp_customDate--yyyyMMddHHmmss,createdate:createTimestamp_customDate--yyyyMMddHHmmss,description:description_char,entitlement_glossary:description_char,RECONCILATION_FIELD:entitlement_value",
"tableFieldAttribute": "accountID",
"entitlementOwnerAttribute": "owner"
}

groupSearchBaseDN

ou=groups,o=XXXX

• There is a noticeable difference in capitalization and spacing between the entitlements.
• It appears that the entitlements are being mapped twice, possibly due to these differences and potentially based on accounts as well as the entitlement itself. (getting mapped through accounts as well as the entitlement mapping)
• The accounts shown in the LDAP browser were mapped, but not assigned to the entitlement. Instead, a completely different account, not shown in the LDAP browser, was mapped under a different DN: uid=er00554477,ou=oiff,ou=users,o=xxxx.

Actions Considered:

• We considered using a transformation code in the LDAP connection’s groupImportMapping to standardize the case (e.g., mapping everything to lowercase) to prevent these differences from being treated as separate entitlements. However, after further research, it seems that this may not be possible in Saviynt and might require an additional JavaScript code. any ideas reagrding that ? is there a way to do it?  
  
  
• What could be causing this mismatch in the entitlement mapping?
• How can we resolve the issue ? since it is not clear with all the debugging how the data is being imported.
• Is there a recommended approach for standardizing the case and formatting of entitlements during the import process in Saviynt?
  
  Thank you!

[rushikeshvartak]

Possible Causes of the Mismatch:

1. Case Sensitivity: LDAP is generally case-insensitive, but the integration with Saviynt might be treating these attributes differently based on case, leading to separate entitlements being created or mapped incorrectly.

2. Whitespace and Formatting: Differences in spaces or formatting (e.g., underscores or extra spaces) can cause mismatches, especially if the system is treating these differences as significant.

3. Duplicate Mapping: If entitlements are being mapped twice (once through the account and once directly through the entitlement), this could create inconsistencies, especially if the data is slightly different in each source.

 

[Roua]

Thank you for your answer @rushikeshvartak ,
there are no underscores in our data, but the SPACES and CAPS are being mapped in a really strange way therefore i attached all the data and how it looks on both sides can you please take a look? 

also regarding the "Duplicate Mapping" i attached the full connector mapping code, can you please take a look and give me any recommendations or if you know where is the issue with the duplicate mapping?
Thank you for your insights and help!