IDM sync to AD fails

[richard_pietsch]

Hi experts,

I noticed several errors in create/modify AD users tasks, such as "failed storing CN=xxx,OU=Accounts,DC=t,DC=xxxxx,DC=intern" with LDAP: error code 32 - 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT). However, according to the AD guys the ID is existing in AD. In a blog I read that IDM will set status "Failed" if it tries to create/assign access to users if the user/assignment already exists in AD. Is that correct?

Second issue is that the assignment of PRIV:ADS:ONLY for above user is in state "failed" in the UI. In the job logs I see that IDM is trying to create a new AD user, however, it already exists and the task fails with above error message. When I check some tables/views I see different information, e.g. in idmv_vallink_basic there's an entry PRIV:ADS:ONLY for this mskey. In contrast, idmv_vallink_ext2 shows only the successful assignments. So, how do I correct this? A new initial load?

Regards, Richard

[Former Member · Accepted solution]

Hello Richard,

I think there are some mixups so I will try to clarify a few things:

"I noticed several errors in create/modify AD users tasks, such as "failed storing CN=xxx,OU=Accounts,DC=t,DC=xxxxx,DC=intern" with LDAP: error code 32 - 0000208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT). However, according to the AD guys the ID is existing in AD. In a blog I read that IDM will set status "Failed" if it tries to create/assign access to users if the user/assignment already exists in AD. Is that correct?"

Yes this is correct but it will lead to a different error message. usually it is error code 68 (entry exists), so it is not the problem you have here.

"Second issue is that the assignment of PRIV:ADS:ONLY for above user is in state "failed" in the UI"

It should actually not be possible to provision anything for this user if the priv:%:only is failed, so I am wondering a little bit how you can encounter this problem? For any group provisioning to be happening the user needs to have this priv assigned correctly and the corresponding ACCOUNT%repname% which stores the DN. The ACCOUNT%repname% attribute however will only be created when user creation was succesful.

The same goes for masterdata provisioning. Without the PRIV:SYSTEM:%repname% masterdata changes will not be transported to the system. Again, this priv will only be assigned after the user was created successfully and (again) you need the ACCOUNT%repname% attribute.

So apparently there a few more problems in your system?

On the error message itself unfortunately there can be various reasons. Two of them Aydin already described but I have seen this error in other systems as well. For some users of the AD branch it throws this error, for others it does not (strangely). The information I received from IDM guys was that their AD team did things directly on AD for some of them but there has never been a followup so I cannot really give you a hand there. Have you checked though, if the user DN (stored in the ACCOUNT%repname% attribute) is matchting the user in AD? Maybe the AD team shuffled some of these guys around.

To fix the erroneous PRIV:%:ONLY assignments a new initial will not help, since the priv is already in failed status. The system will not assign it again in that case. You will have to remove those entries first, then preferably through an update job (but a new initial load should work as well) you can set these to correct status. If the PRIV:%:ONLY is assigned directly this should be rather easy, if they are assigned through bussines roles that hold privileges for more than one repository this will probably become a problem though, because fixing those entries will impact other systems. So another option is to identify all cases and fix them directly in the IDM DB but I strongly recommend to contact SAP support before so they give you the correct guidelines on the procedure. If you do things at a wrong spot you will basically corrupt your database with no correction options other than going with a former DB backup.

[richard_pietsch · Accepted solution]

Hello guys,

thanks for your feedback!

"The information I received from IDM guys was that their AD team did things directly on AD for some of them but there has never been a followup" That's what happened here also... the guys moved several IDs and/or deleted them. So, there is a mismatch between DN in AD and IDM - I've cross-checked the DNs yesterday. So, I build a job to fix the ACCOUNTADS attribut, which is still running. Afterwards I will go ahead with the PRIV:ADS:ONLY issue.

Thanks again for your thoughts!

Regards, Richard

[former_member187331]

Hello Richard,

I experienced this error message many times. There are 2 possible causes (i experienced):
- The OU you want to write is not correct (e.g. misspellings)

- Your communication-user does not have write permissions to the OU

For the second issue: revoke the privilege and retry assigning it after you fixed the first issue.

Greetings, Aydin