AD destination modify question

[morganginga]

I looked at the trace files from both the AD remote loader and the
Metadirectory Engine. After some trial and error I figured out what was
happening. There wasn't anything wrong with my policy as far as logically.
The problem was that when I was trying to "set destination attribute" on
member, the m at the beginning of Member was capitalized instead of
lowercase. This caused the driver to think that I was trying to set the
"Member" attribute on the eDirectory object (and thus was vetoing the
operation since the filter is set to ignore on the publisher channel for
that attribute) instead of on the AD object. I corrected this
capitalization error (so my policy was setting destination attribute
"member" for AD) and it worked as it is supposed to.

I just thought I would post what the issue/solution was in case anyone else
runs into this problem.

-Morgan

<ab@novell.com> wrote in message
news:37GDm.20224$7G7.7401@kovat.provo.novell.com.. .
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Two things...
>
> First, get the trace from the Remote Loader to see if it is even trying to
> apply this to MAD.
>
> Second, when tracing on the engine side ditch iMonitor and instead trace
> directly to a file from the driver (the field below where you set the
> trace level is the trace file, which accepts a (preferably absolute) path
> for the IDM engine server to which the trace is written. With that done
> start the driver and capture that part of the trace in case something in
> there is strange.
>
> Everything looks okay but I'm suspicious of the following lines, mostly
> because there are two of them (corresponding to the number of events that
> modify the group) and they could be an issue in some cases:
>
> [10/21/2009 9:45:53.223] Vault-2-EAD-AD EV: Filtered by class or attribute
> [10/21/2009 9:45:53.226] Vault-2-EAD-AD EV: Filtered by class or attribute
>
>
> Good luck.
>
>
>
>
>
> Morgan wrote:
>> Ok, I modified the rule to kick off on a modify (which it does) and got
>> it
>> the user's full dn. It's still not adding the user to the group though.
>> There are no errors in the trace and it seems like it should have added
>> the
>> user successfully but when I check, the user still isn't added to the
>> group.
>> If I can get the user add to the group working then I'll look at the
>> remove
>> logic so you can ignore the "else" portion for now. Ideas?
>>
>> Trace attached
>> Here is the modified rule:
>> <rule>
>> <description>Group-Employees</description>
>> <comment name="author" xml:space="preserve">Morgan</comment>
>> <conditions>
>> <and>
>> <if-class-name mode="nocase"
>> op="equal">User</if-class-name>
>> <if-operation mode="case"
>> op="equal">modify</if-operation>
>> </and>
>> </conditions>
>> <actions>
>> <do-if>
>> <arg-conditions>
>> <and>
>> <if-src-attr mode="src-dn" name="Group
>> Membership"
>> op="equal">utc\Groups\EMPLOYEES</if-src-attr>
>> </and>
>> </arg-conditions>
>> <arg-actions>
>> <do-add-dest-attr-value class-name="group"
>> name="Member">
>> <arg-dn>
>> <token-text
>> xml:space="preserve">CN=Employees,OU=Groups,DC=ead ,DC=utc,DC=edu</token-text>
>> </arg-dn>
>> <arg-value type="dn">
>> <token-text
>> xml:space="preserve">CN=</token-text>
>> <token-src-attr name="CN"/>
>> <token-text
>> xml:space="preserve">,OU=Active,OU=Persons,DC=ead, DC=utc,DC=edu</token-text>
>> </arg-value>
>> </do-add-dest-attr-value>
>> </arg-actions>
>> <arg-actions>
>> <do-remove-dest-attr-value class-name="group"
>> name="member">
>> <arg-dn>
>> <token-text
>> xml:space="preserve">CN=EMPLOYEES,OU=Groups,DC=ead ,DC=utc,DC=edu</token-text>
>> </arg-dn>
>> <arg-value type="dn">
>> <token-dest-dn/>
>> </arg-value>
>> </do-remove-dest-attr-value>
>> </arg-actions>
>> </do-if>
>> </actions>
>> </rule>
>>
>> <ab@novell.com> wrote in message
>> news:N0pDm.20005$7G7.13797@kovat.provo.novell.com. ..
>> - From your trace:
>>
>> <quote>
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST: (if-src-attr 'Group
>> Membership' equal "utc\Groups\EMPLOYEES") = TRUE.
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST: Performing if
>> actions.
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST: Action:
>> do-add-dest-attr-value("Member",class-name="group",arg-dn("CN=Employees,OU=Groups,DC=ead,DC=utc,DC=edu"), token-dest-dn()).
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST:
>> arg-dn("CN=Employees,OU=Groups,DC=ead,DC=utc,DC=edu")
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST:
>> token-text("CN=Employees,OU=Groups,DC=ead,DC=utc,DC=edu" )
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST: Arg Value:
>> "CN=Employees,OU=Groups,DC=ead,DC=utc,DC=edu".
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST:
>> arg-string(token-dest-dn())
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST: token-dest-dn()
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST: Token Value:
>> "".
>> [10/20/2009 15:37:16.260] Vault-2-EAD-AD ST: Arg Value: "".
>> </quote>
>>
>> Your dest-dn is being used to fill in the DN of the user into the Members
>> attribute on the Group object; however, as this is not an add, there is
>> no
>> dest-dn but instead there is an association. Duplicate your rule and
>> have
>> one fire on an add (existing rule) and one on a modify (new rule) and see
>> if the new one (modify) can work based on the DN of the user on the
>> destination side. How you get that is up to you... maybe
>> DirXML-ADContext
>> will have what you need in it. You could perhaps also add functionality
>> to your driver to properly store the MAD DN in an eDirectory attribute.
>>
>> Good luck.
>>
>>
>>
>>
>>
>> Morgan wrote:
>>>>> I have some strange behavior with an Active Directory driver. We do
>>>>> not
>>>>> directly synchronize groups from eDir to AD due to stale/dirty data
>>>>> (we
>>>>> don't want all the members in the equivalent eDir group coming into
>>>>> AD).
>>>>> I
>>>>> created a rule to manually add a user to the AD Employees group if
>>>>> they
>>>>> are
>>>>> a member of the eDir Employees group (I have attached an export of
>>>>> this
>>>>> policy).
>>>>>
>>>>> When I user is first created in AD the policy works wonderfully and
>>>>> the
>>>>> user
>>>>> is added to each group that they are currently in on the eDirectory
>>>>> equivalent. My problem comes when a user is added to a group after
>>>>> they
>>>>> already exist in AD. I do not directly map the Group Membership eDir
>>>>> attribute anywhere in AD, but I set the Subscriber channel to
>>>>> synchronize
>>>>> for that attribute so that it would register when the attribute is
>>>>> modified
>>>>> in eDirectory (at one point I even had my actions executing only if
>>>>> Operational Attribute Group Membership is changing). This allows the
>>>>> driver
>>>>> to register that a change has occured. The conditions are evaluated
>>>>> (the
>>>>> user is a member of the group in eDir) and it kicks off the same
>>>>> action
>>>>> as
>>>>> it did when a user is first created (add them to the AD group).
>>>>>
>>>>> The problem is that, based on what I'm seeing in the trace (attached),
>>>>> it's
>>>>> not seeing the destination side values of anything for the user in
>>>>> question.
>>>>> When it tries to add the destinationDN attribute to the AD group
>>>>> attribute
>>>>> member, it is empty. I changed it around several times to try to
>>>>> retrieve
>>>>> destination information (pull destination attribute CN for example)
>>>>> and
>>>>> everytime it comes back empty. I don't understand why it's not seeing
>>>>> the
>>>>> destination side of things (AD) for this change, but it can execute
>>>>> the
>>>>> same
>>>>> rule and get the values it needs when the user is first created.
>>>>>
>>>>> Any help is appreciated.
>>>>>
>>>>> -Morgan
>>>>>
>>>>>
>>>>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJK3y4/AAoJEF+XTK08PnB5TXcP/iyvFd0mRizSVKnQD48Aar4Y
> sKF32J+AnzysUMh+42/keQikQaObdyQnHE7KLM4jAw3wXbxu/Q7QneZ26ac1ZMO2
> AFAUbTIGh4mu/ygMM1sNMN0DF38Shi1Q843xpOwNJ3gbmVKr39YQj6UUiUlqgZl 2
> B4t0jpJ7/8B04JmeWCUV0I5SUsNxP0/GTlPePeKHMfdO6P8e1V6IIxwmDWBVPumR
> HrkADRNnfeZ93e7CxxzfEWaHZONUpxU1ED0hFcmXBYurRU1CXf coNfSObknnw8vz
> uIia49TDIKOfqxC3XhYi0qt2or55/otvc/MdCKf6ltLXVdiU4FCwOaLz9z6Q8I/Y
> 1AEai7Lui4H/t0fAG0d6TNLCmHC9w8fj1+F8uuW14MviT9T1YlFwmn5d7m3ZJj rU
> LoPILRMvwza3t1joWd56XQGO9PVg3aiMNe34Eso7PEoQsJ+oVQ Lk1AHPOrUDU+EL
> 9j3RTlCHfnhWKR0pI1WOIgAkJxuwwtTqtzXNLhQ6H1PZHyTm1V rgBB0li/tuyVp/
> lg5pE4p2UTvOVmlYyplaoQW7YM4Ll5d2sc7JZniWQVXLgI+wKn WBwse4HWLZLwXX
> m21ECCkhm1xuOUqEa/z3/G51WlGblZPG8ixEHjgXwc4w85iAdi8WKtbFytb1uFEk
> CJqKU0NeB/ZYxLsz8fQu
> =ZYPu
> -----END PGP SIGNATURE-----