and more in a single search tool across platforms. Read the announcement here. |
01/03/2023 03:37 AM
Hi All,
I am getting the below error when I am updating Location value in Active Directory -
Error while Update operation for account-TEST1649 in AD - [LDAP: error code 53 - 00002077: SvcErr: DSID-031903CA, problem 5003 (WILL_NOT_PERFORM), data 0 ]
Our use case is when we are updating the location value of user it is changing the OU in AD.Previously I am using the below JSON for Update account that time OU movement is working fine recently I am getting the LDAP error when I am updating the location.
${if(((user?.customproperty57!=null)&((user?.customproperty20.equals('A'))||(user?.customproperty20==null)))&((user?.employeeType== 'NON') || (user?.employeeType=='NONGT')))'\"moveUsertoOU\":\"OU=Non-Employees,'+ user.customproperty55+'\"'
else if(((user?.customproperty57!=null)&(user?.customproperty20.equals('L')))&((user?.employeeType!= 'NON') || (user?.employeeType!='NONGT')))'\"moveUsertoOU\":\"OU=LOA,'+ user.customproperty55+'\"' else{ '\"moveUsertoOU\":\"OU=Employees,'+ user.customproperty55+'\"'}
Please help me out and let me know how this issue can be fixed.
With Regards,
Siraj Molla
01/03/2023 04:43 AM
what does customproperty holds
01/03/2023 04:56 AM
Customproperty 55 holds the OU.
Like Below
OU=Users,OU=GBL,OU=USA,OU=NA,OU=xx,OU=Ti,OU=ABC,DC=abc,DC=net
When user belongs to non employee type and users location change as example AP then OU move to OU=NONemployee,OU=Users,OU=JPN,OU=AP,OU=xx,OU=Ti,OU=ABC,DC=abc,DC=net
If it is employee then it moves to-
OU=employee,OU=Users,OU=JPN,OU=AP,OU=xx,OU=Ti,OU=ABC,DC=abc,DC=net
If users employeestatuscode is L then its moves to -
OU=LOA,OU=Users,OU=JPN,OU=AP,OU=xx,OU=Ti,OU=ABC,DC=abc,DC=net
like that ou movement is happening and at the time of movement of OU it is taking Customproperty55 value that's holds the OU value as per the location.
03/31/2023 01:35 PM - edited 03/31/2023 01:36 PM
Based on the error, it looks like that the value that is being passed in the UPDATEACCOUNTJSON is not a valid value that your AD is willing to accept. Prior to the error, there should also be a string a values that should be printed for each of the attributes mentioned in the UPDATEACCOUNTJSON. The other way to identify the problematic attribute value is by process of elimination
1. Remove all other attributes and just add an attribute in the UPDATEACCOUNTJSON that you suspect could be possibly causing an error.
2. If the updates are successful, keep adding other attributes one at a time and validate until you identify the problematic attribute and its value.