De-provisioning identities when LDAP is leading datasource

[Former Member]

Hi,

We have a scenario where Java AS installations primary datasource is Active Directory (LDAP connector). This is also the leading datasource for our IDM installation.

Occasionally users are removed from the AD. When this happens were are unable to terminate the Java AS user from IdM because the account no longer exists in the backend Java AS and therefore the SPML call in the standard "SetJavaGroupForUser" pass fails.

I have tried adding a version of "Apply Pending" to the result handling actions (for failed result) on the task but this doesn't work.

If the Identity has already been removed from the AD, it no longer exists in the AS Java either, and therefore all I am looking for is to remove the privileges and account privilege from the Identity in IdM to reconcile everything.

Any ideas?

Thanks in advance,

Craig.

[former_member201064]

I would do it like this as this doesn't trigger anything after updating Ad into IdM.

In the AD updating (nightly, hourly?) I would not only remove the AD sys-priv/only-priv/other stuff like ACCOUNT, but also anything AS Java repository related. All privileges should be prefixed with {D}{DIRECT_REFERENCE=1!!LINKID=123456} which I usually do in the Source tab

Query:

select s.mcthismskeyvalue as mskeyvalue, '{D}{DIRECT_REFERENCE=1!!LINKID=' +  convert(nvarchar(max), s.mcUniqueID) + '}' +  convert(nvarchar(max), mcOtherMSKEY) privRef
from idmv_link_ext s with (nolock)
where ... -- Detect your users and systems here

This removes one priv per Source/Destination tab combination. 50 privs per user, 50 entries in modify in the log.

If you have Oracle there's a better function for "grouping" all privs at once in the Source tab. But I forgot about that already

[Former Member]

This is a very nice solution.

As I replied to Matt above, that is more or less what I did. Only I did it using javaScript rather than using SQL in the source tab. Never thought of doing it that way before (using SQL) and may give that a go in the future to help reduce the endless hours of javaScript.

Thanks,

Craig.

[Steffi_Warnecke]

Hello Craig,

you already have some answers, but I thought I would chime in, too. We have also use AD as the data source for the AS Java, so I know your issue.

I just added a script as entry script to "SetJavaGroupForUser" and "SetJavaRoleForUser" that checks, if the currently provisioned user still has an AD account and if not, skip the whole provisioning to AS Java. This way the privileges in IDM are removed etc. and everything is shiney and neat.

Works fine in our system. ^^

.

Regards,

Steffi.

[former_member2987]

Hi Craig,

The short answer is, make sure people don't do this! Now for the realistic answer.

I suppose it all depends on how the system is set up. You could try forcing a reconciliation of dirty entries. The other thing would possibly be a more brute force approach where you examine the idmv_link_ext view for MSKEYs of MX_PERSONs that don't exist and then remove the assignments. This would really be an aggressive form of removing the dirty entries.

If what I'm saying isn't making sense or doesn't seem to apply, please provide some more information, screenshots, dumps from idmv_link_ext with an example, etc.

Thanks,

Matt

[Former Member]

Hi Matt,

Thanks for your reply. Very much appreciated.

I don't think reconciling dirty entries will fix this as the entries aren't stuck in the provisioning queue. The problem here is that the account has been removed from AD, the same AD used to authenticate the AS Java. The removal of the record in the AD was picked up by the delta for loading identity records from the AD (AD is our leading datasource) and so this marks the identity for deletion. When we try to remove the privileges from that identity the SPML connector tries to connect to the AS Java to verify the ID but cannot because it no longer exists in the AS Java (because it is removed in the AD). Instead we get this:

I have managed to find a workaround by creating a second "To Identity Store" task which uses the DIRECT_REFERENCE=1 operator to remove the privileges. Which essentially just suppresses the call of the event tasks, removes the assignments from the IDS and doesn't try to do anything in the backend AS Java.

https://help.sap.com/http.svc/rc/a640e87c07284708928e3091950b0e6e/7.2/en-US/ICSkin/managing_passes/t...

Around this I added a condition to check if the identity is marked for deletion (if so then it means the record is removed from the AD and has been picked up by the AD load delta) and if so then use my new task, otherwise use the existing standard task and try to deprovision properly.

Now I have some cleaning to do 🙂

Thanks for your help.

Craig.

[former_member2987]

Sounds like you're on the right track based on dominik.trui's comment. Good luck!