Novell Home

More about the Veto Command for Scoping Events

Novell Cool Solutions: Tip
By Geoffrey Carman

Digg This - Slashdot This

Posted: 13 Jun 2007
 

Problem

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!

Solution

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="3.0.10.20060630 ">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.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell