In a previous Cool Solutions article (http://www.novell.com/coolsolutions/tip/19039.html) I strongly recommended that when using a Veto command to scope events, you need to limit it to the class of the object you are watching for.
Of course, there are always exceptions, and here is one that came to mind soon after.
Imagine an Identity Vault linked to Active Directory. When a delete in AD occurs, you probably do not want to always delete the user in the IDV, but maybe you want to disable them in the IDV just in case.
The rule below seems to make sense for handling this problem:
<rule> <description>Convert Deletes in AD to remove association in IDV</description> <comment xml:space="preserve">Delete in AD means remove association in IDV and disable the user in IDV.</comment> <conditions> <and> <if-class-name mode="nocase" op="equal">User</if-class-name> <if-operation op="equal">delete</if-operation> </and> </conditions> <actions> <do-add-dest-attr-value direct="true" name="Login Disabled"> <arg-value type="string"> <token-text xml:space="preserve">true</token-text> </arg-value> </do-add-dest-attr-value> <do-remove-association direct="true"> <arg-association> <token-association/> </arg-association> </do-remove-association> <do-veto/> </actions> </rule>
Basically, this rule checks if it is a User, and then if it is a Delete event. So I would probably put it in the Publisher Event Transform rule. And I would expect it to just work. But then, do it, and the User gets deleted in the IDV, gosh-darn it!
As usual in cases like this, we head off to our handy Dstrace. Man, where would we be without Dstrace?
Looking at the event that gets generated on an AD delete we see this:
<nds dtdversion="2.2"> <source> <product version="220.127.116.1160630 ">DirXML</product> <contact>Novell, Inc.</contact> </source> <input> <delete event-id="ADLink##112e8db8074##0" src-dn="CN=AAA Test\0ADEL:38dff046-ccde-40b1-b9d8-afe9f02c908f,CN=Deleted Objects,DC=acme,DC=com"> <association>46f0df38deccb140b9d8afe9f02c908f</association> </delete> </input> </nds>
So we see an event that is a Delete. Good so far, but when we watch the trace processing the rule, we will see that the condition “if object class is User” will not be true.
This makes sense; if you look at the document you get from the AD driver, it is not talking about a user. Deleted users get moved to a hidden container off the root of the domain, called Deleted Objects.
So the fix is pretty easy: remove the test for User class, and the deletes will be caught. You should consider how you want to handle Group or other object class deletes, since a Disable login will not make much sense against a group or OU in the IDV.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.