Skip to Content
avatar image
Former Member

De-provisioning identities when LDAP is leading datasource

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.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Apr 26 at 11:07 AM

    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

    Add comment
    10|10000 characters needed characters exceeded

    • 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.

  • Apr 25 at 01:02 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • May 02 at 03:03 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded