AD deprovisioning and infinite retries

[Former Member]

Hi, we are running idm 7.2 sp5 and facing troubles when it comes to AD deprovisioning.

For some users, deprovisioning works fine but for some others it just tries and tries again. The trouble is when i go into the AD to see the state of deprovisioning, the user already lost the privilege (I'm guessing through IDM so that the first deprovisioning was a success). But then it starts again and fails on the unassignUserFromADGroup pass. and it just goes on and on until i clean the provisioning queue (doable in a development system but not so much on a production system).

Here i put the configuration of the task, where the number of retries is set to 1.

Does anyone know where this behavior come from, or did anyone already had it and figured out how to avoid it?

Also is there a way to change the unassignuserFromADSGroup and assignUserToADSGroup passes so that it won't fail if the user already has been deprovisioned/provisioned?

Thanks a lot for your help,

Clotilde

[Former Member]

Hi Clotilde,

I have the same problem, but in SAP IdM 8.0.

You could solve the problem?

Tks,

Gustavo

[former_member190695]

Hi Gustavo,

A workaround is described above.

Just skip the processed entry uSkip(1,1);

Please provide more information such as how the assignment is done and also check the provisioning queue.

Regards,

Ridouan

[former_member2987]

Clothilde,

Are all of the subtasks in the deprovisioning workflow working correctly?

I think you've pretty much pinned it down that the problem is in your group memberships.  I thought the framework scripts already do a check to see if you're still part of the group.  I've got some code somewhere on this, I'll see if I can find it.

Matt

[Former Member]

Hi Matt,

the other tasks of the deprovisioning framework go well. in the unassignUser job, I only have one standard script the sap_core_checkAccountAttributeValueExist that checks if the user still have an accountAD attribute since if it sends something empty to the AD, it deletes all member of the group.

My main problem is that it is trying to do it again and again and again. On the screenshots i put, it had been going on from midnight Yesterday until this morning when i finally cleaned my provisioning queue.

And i don't know what's the difference between the accounts that idm doesn't retry (or just once like it's supposed to be) and those that are retried a thousand times or more. And as you can also see, the retry is not just on the unassign job but on the whole deprovisioning workflow since it begins from the top everytime.

Clotilde

[former_member192766]

Hello Clotilde,

You can prevent this behavior by creating a script to Skip the processing of an Identity If it's already processed. You can use the DN of any other unique attribute or a combination with MSKEY to skip the processing. Use uSkip correctly, mark the entry succeeded to avoid other issues.

Regards,

Ridouan

[Former Member]

Thanks Ridouan,

i will try this, but do you know where the trouble comes from? Since it doesn't do it everytime it fails I'm wondering why it happens. Is it a SAP idm problem or a configuration one?

Regards,

Clotilde

[former_member192766]

Hi Clotide,

I think the link is still active between the user and the de-assignment event. It happens in case of errors during the initial processing and the pending on group or change number is not applied correctly. Please check the idmv_link_ext view and check the assignment status.

What errors are you getting in the unassignuserFromADSGroup?

Honestly, the default scripts and jobs are not sufficient, you need at least to have a process that checks If the user is assigned to the group in AD. As you see It's just checking for the Account attribute.

I didn't try this but I think when a user is not assigned to the group, AD is returning errors to IdM and IdM marks the entry as failed.

Regards,

Ridouan

[Former Member]

Hi Ridouan,

so i got the problem again this morning and here's what i found :

the error i get in the pass is :

putNextEntry failed storingCN=DGU_CtxAP-A001_ICA-RemDesk,OU=OU_GRP_Users,OU=OU_GRP,OU=OU_UAT,DC=WPAD-T,DC=BCV,DC=CH

Exception from Modify operation:javax.naming.OperationNotSupportedException: [LDAP: error code 53 - 00000561: SvcErr: DSID-031A120C, problem 5003 (WILL_NOT_PERFORM), data 0]; remaining name 'CN=DGU_CtxAP-A001_ICA-RemDesk,OU=OU_GRP_Users,OU=OU_GRP,OU=OU_UAT,DC=WPAD-T,DC=BCV,DC=CH'

It means that the user is not a member of this group anymore so it can't deprovision it.

In the idmv_link_ext table, the link status is mclinkstate=0 and mcexecstate = 1537 (currently deprovisioning)

in the idmv_linkaudit_simple, we can see that the task has been started several times in a short timeframe who knows why.

And actually I kind of have the same trouble with provisioning AD privileges. Yesterday i created a user from scratch in idm (so it didn't exist in my AD system). Gave him around 10 AD privileges. During the provisioning  I got an error saying that this user already had one of the privilege. I went to check directly in the AD and indeed it had.

But no log about it in IDM as if the privilege were given with another one and then retried. Luckily it doesn't try for hours when it comes to provisioning but still stays in a Failed state which is also a problem...

Any other ideas? Going into developing a workaround to ckeck if the user already has/has lost a group seems to be kind of heavy since it's the basic use of idm to do prov/deprov tasks...

Thanks a lot,

Clotilde

[Former Member]

I found a way to stop it using the provisioning framework. There is a task called Pending Operation Failed and i trigger it on Failed Result on the AssignADUser and UnassignADUser tasks. This way at least it doesn't keep on trying.

I'll write an OSS message to find out what the cause is and let you know.

Br,

Clotilde

[Former Member]

Hi Ridouan,

I thought that by using the standard task Pending Operation Failed that it stopped the process but i had the problem once again.

The trouble is that the job does skip the entry and applies the pending but the dispatcher must go back and check the link again since 10 seconds after it creates a new pending.

The only thing i can do to stop it is to kill part of my provisioning queue which is a pretty bad move i think. I didn't write the OSS message yet but i will today.

BR,

Clotilde