ADSI -Attributes not setting on AD side

[sab2]

Hi,
We are working on our ADSI connector - the create account json.
The provisioning into the AD domains is working. We can map most attributes successfully, but one attribute, 'attribute123' from Saviynt to AD is not setting correctly. It does not cause the provisioning to fail but we are seeing this in the server logs:

DEBUG ADSI.xxx.CreateUpdateOperations Additional object classes updated for - Test User
ERROR ADSI.xxx.ResponseHelper Please check the data sent to attribute123.

Has anyone seen this before or know if we are mapping incorrectly? We have tried using CP22 and CP23 to map from the Saviynt side.

The attribute seeing the error is 1 byte. We are trying to map just the letter 'N'. It's also a string attribute on the AD side.

Also below is a shortened version of our json.

{
"objects": [{
"objectClasses": ["user", "top", "Person", "OrganizationalPerson"],
"attributes": {
"sn": "${user.lastname}",
"cn": "${user.username}",
"sAMAccountName": "${user.username}",
"employeeID": "${user.employeeid}",
"employeeType": "${user.employeeType}",
"givenName": "${user.firstname}",
"initials": "${user.middlename}",
"attribute123": "${user.customproperty23}",
"mail": "${user.email}"
},
"baseDn": "OU=TESTOU123",
"password": "${password}",
"pwdLastSet": "0"
}]
}

Thank you in advance!

[nimitdave]

Please try what type of data is stored in atribute123, then try to pass a hardcoded values in the json for attribute123 and see if that works first.

[sab2]

Thank you for a reply!

What do you mean 'what type of data is stored?' Also, I had tried passing a hard coded value previously and we saw the same error I posted in the original post.

[sab2]

We tried hard coding a value based on the attribute type in AD. This still caused the same error. 

[rushikeshvartak]

attribute123 - can you show screenshot from ADSI that this is correct attribute name & what type data it accept number/string etc

[sab2]

Thank you for the reply! I attached a screenshot of the attribute. It's actually named 'ESPP'.

In our json we have "ESPP": "${user.customproperty23}",

the value stored in CP23 for our test user is 'N'.

[rushikeshvartak]

It seem attribute also start with some other letter too

[sab2]

Yes, we have those letters in addition at the beginning of the espp attribute. Just needed to block it out for confidentiality. so it looks like 'xxespp' on ad and in the json it would be 'xxespp'. The attributes between the two are exact same. 

But looking at the error, it seems attribute is being found / mapped but the data being passed is not valid or we do not have access to edit it

[rushikeshvartak]

Did you tried directly changing in adsi with service acocunt ? To check access issue 

hardcode value as 1 / true to send bit to target and test

[sab2]

We will try setting it directly from adsi with the service account and see if that works. But we did confirm the service account does have all permissions. 

Also, we had tried previously hard coding the value as true and false and it still did not map.

[sab2]

No solution found for this issue. We decided to drop this attribute. Thank you for the help.