Capture Delete Account events in Active Directory -Terminate User

Capture Delete Account events in Active Directory -Terminate User

I want to terminate (LOGIN_DISABLED = TRUE) a user who was DELETED in Active Directory. I am able to make user terminated (LOGIN_DISABLED = TRUE) when an account in AD was disabled. I want to have the same capability on the DELETE event as well. 

Can you please guide me on how to accomplish this?

  • You only get one shot at this... When the Pub channel sends you a delete, you have to catch that event.  (if operation equals delete) then set dest attr Login Disabled to true.

    I cannot recall, but the class name may not be there in a delete of a user, so you have to ignore the class when you do this.

  • Yes, you can.

    I used "custom" logic in one of the AD drivers that 

    1. Capture AD delete operation

    2. "Convert" deleted object name to "human-friendly" format for future use.

    You can use "similar" techniques.

    Geoffrey absolutely right: ObjectClass information already "disappear" during delete operation.

    But we still have a number of methods for users identifications: object association (GUID) and "reconstructed" SAMAccountname.

    Example of the Delete operation event (some business sensitive information in the trace masked) 

    [08/12/21 09:08:22.821]:AD-XXX2LS :Remote Interface Driver: Received.
    [08/12/21 09:08:22.822]:AD-XXX2LS :
    <nds dtdversion="2.2">
    <product build="20140409_120000" instance="\XXX-TREE\XXX\Services\Dr-DriverSet\AD-XXX2LS" version="">AD</product>
    <contact>NetIQ Corporation</contact>
    <delete event-id="AD-XXX2LS##17b3a7a5cb0##0" src-dn="CN=skumawa\0ADEL:b168b82a-ae93-4cf6-b134-bf3989aa8d8a,CN=Deleted Objects,DC=XXX,DC=net">

     <nds dtdversion="2.2">
    <product build="20140409_120000" instance="\XXX-TREE\XXX\Services\Dr-DriverSet\AD-XXX2LS" version="">AD</product>
    <contact>NetIQ Corporation</contact>
    <delete event-id="AD-XXX2LS##17b3a7a5cb0##0" src-dn="CN=skumawa\0ADEL:b168b82a-ae93-4cf6-b134-bf3989aa8d8a,CN=Deleted Objects,DC=XXX,DC=net">
    [08/12/21 09:08:23.073]:AD-XXX2LS PT:Applying policy: %+C%14C15 msDS-PrincipalName%-C.
    [08/12/21 09:08:23.115]:AD-XXX2LS PT: Evaluating selection criteria for rule '62 itp-generate msDS-PrincipalName during Delete operation'.
    [08/12/21 09:08:23.120]:AD-XXX2LS PT: (if-operation equal "delete") = TRUE.
    [08/12/21 09:08:23.124]:AD-XXX2LS PT: (if-op-property 'op-msDS-PrincipalName' not-available) = TRUE.
    [08/12/21 09:08:23.127]:AD-XXX2LS PT: (if-src-dn available) = TRUE.
    [08/12/21 09:08:23.133]:AD-XXX2LS PT: Rule selected.
    [08/12/21 09:08:23.135]:AD-XXX2LS PT: Applying rule '62 itp-generate msDS-PrincipalName during Delete operation'.
    [08/12/21 09:08:23.140]:AD-XXX2LS PT: Action: do-set-local-variable("lvSrcDN",scope="policy",token-src-dn()).
    [08/12/21 09:08:23.145]:AD-XXX2LS PT: arg-string(token-src-dn())
    [08/12/21 09:08:23.148]:AD-XXX2LS PT: token-src-dn()
    [08/12/21 09:08:23.150]:AD-XXX2LS PT: Token Value: "CN=skumawa\0ADEL:b168b82a-ae93-4cf6-b134-bf3989aa8d8a,CN=Deleted Objects,DC=XXX,DC=net".
    [08/12/21 09:08:23.154]:AD-XXX2LS PT: Arg Value: "CN=skumawa\0ADEL:b168b82a-ae93-4cf6-b134-bf3989aa8d8a,CN=Deleted Objects,DC=XXX,DC=net".
    [08/12/21 09:08:23.158]:AD-XXX2LS PT: Action: do-set-local-variable("lvmsDS-PrincipalName",scope="policy",token-xpath("substring-before($lvSrcDN,'\0ADEL:')")).
    [08/12/21 09:08:23.164]:AD-XXX2LS PT: arg-string(token-xpath("substring-before($lvSrcDN,'\0ADEL:')"))
    [08/12/21 09:08:23.167]:AD-XXX2LS PT: token-xpath("substring-before($lvSrcDN,'\0ADEL:')")
    [08/12/21 09:08:23.170]:AD-XXX2LS PT: Token Value: "CN=skumawa".
    [08/12/21 09:08:23.174]:AD-XXX2LS PT: Arg Value: "CN=skumawa".
    [08/12/21 09:08:23.175]:AD-XXX2LS PT: Action: do-if().
    [08/12/21 09:08:23.177]:AD-XXX2LS PT: Evaluating conditions.
    [08/12/21 09:08:23.180]:AD-XXX2LS PT: (if-xpath true "starts-with($lvmsDS-PrincipalName,"CN=")") = TRUE.
    [08/12/21 09:08:23.185]:AD-XXX2LS PT: Performing if actions.
    [08/12/21 09:08:23.187]:AD-XXX2LS PT: Action: do-set-local-variable("lvmsDS-PrincipalName",scope="policy",token-xpath("substring-after($lvmsDS-PrincipalName,'CN=')")).
    [08/12/21 09:08:23.194]:AD-XXX2LS PT: arg-string(token-xpath("substring-after($lvmsDS-PrincipalName,'CN=')"))
    [08/12/21 09:08:23.198]:AD-XXX2LS PT: token-xpath("substring-after($lvmsDS-PrincipalName,'CN=')")
    [08/12/21 09:08:23.202]:AD-XXX2LS PT: Token Value: "skumawa".
    [08/12/21 09:08:23.204]:AD-XXX2LS PT: Arg Value: "skumawa".

  • Thank you for your replies. One question about the place that the policy place to be put. Should I add the newly defined policy in Input Transformation Policy tab?

  • I usually add my own "new policy", that includes custom logic.

    I'm trying to separate my policies from "default" NetIQ drivers' policies.

  • Placement of your Customer policies can technically be anywhere. That said, the best practice would normally have something like this policy placed int the Publisher Event Transform Policy Set.

    The Input and Output Transform Policy Set should be used for all policies handling conversions between the connected system schema and the ID Vault schema, policies. The Schema Map policy set handles the actual name conversions, but any formatting changes or more in-depth changes should be handed during the Input or Output processing. As the policies in these three areas (Input, Output and Schema) are duplicated on both the Publisher and Subscriber channels (threads) you should not normally place policies there that only need to be processed in only one channel.

    A great reference article, IDM Proven Practices: Efficient IDM Input/Output Transformation Value Mappings written by covers a lot more details and is well worth reading.

    My recommendation is that you place your policy to handle this in the Pub Event Transform policy set, as you are effectively transforming the Delete Event into a Modify of the "Login Disabled" attribute.

    A further tip in handling the Delete event. The target Association value is provided in the delete event. Using the Resolve Noun, you can use the association to resolve the target DN in the vault. With the target DN you can then easily set the Login Disabled attribute, remove the association on the target object and then veto the delete event.



  • And my colleague also grabbed the GUID, stored it somewhere (on an object) so that if they chose to recover the AD account from the AD Trash can, he modified the Match policy to check for that GUID so it can relink to the proper IDV object.

    Very clever.

  • Hello,

    I did not get the idea behind Target Association, Resolve Noun and the DN values. Later, how can I use DN value to make Login Disabled attr to TRUE. I am new to NetIQ, so I can ask simple questions like this:)

  • Additionally, I am able to detect the Delete event, then get the Association value of a deleted user. But, now, I can not make the link between Association and Login Disabled? Can you please guide me on how to arrange this?


  • One more update. I am able to get the DN value in IDVault. Now, dont know how to use this DN value to set Login Disabled attribute to TRUE.

  • Resolve is a cute token, that takes EITHER a DN, or an Association value in the IDV, and returns the other.  In your case, you have caught the Operation=delete, and can get the current objects association.  The src-dn is in AD and is now of an object in the Deleted objects container or whereever.

    So you want to know the DN in the IDV of the deleted object.

    You could set local variable DEL-USER to Resolve, Associatoon to DN, and pass in the association value (With the Association token, or XPATH of simply the word association )

    But you want to write login disabled to that proper user.  When doing a set|add destination attribute into eDir you can specify the target object with either the DN, Association or Current Object.  Really current object should just work.  But you can pass in the association and it should work, Or you could Resolve the Assoc to a DN and it should work. 

    The current event, the <delete> with the <association> with a value is referring to th eobject.  So current object in IDV is the object you want to change its login disabled value.  A <modify-attr> cannot be a child of a <delete> operation, so to change the value, the engine will make a second event after the <delete> with the <modify> and <modify-attr> if you 'add destination attribute'.

    Since you are processing the <delete> operation/event at that moment, if you did a Veto, onlyt the <delete> is cancelled, the <modify> conitinues on its way.