More about the Veto Command for Scoping Events

geoffc

By: geoffc

June 13, 2007 4:39 am

Reads: 217

Comments:0

Rating:0

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.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Tags: , ,
Categories: Identity Manager, Technical Solutions

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.

Comment