I have a rule that catches a password change in AD to some magic
value... I am confident it used to work. But I can show it failing and
i know why. But I need a sanity check on an AD driver trace:

In comes a <modify-password> event, and Pub-Command password transform
rules changes that to a <modify> with a <modify-attr
attr-name='nspmDistributionPassword'> using the
add-dest-attr token.

But my trace is showing the event looks like this coming from AD:

<nds dtdversion="2.2">
<product version="">DirXML</product>
<contact>Novell, Inc.</contact>
<modify-password class-name="user" event-id="e##0"
src-dn="CN=Smith\, John,OU=Users,DC=acme,DC=corp">
<password><!-- content suppressed --></password>

Thats fine.

But it comes out, something like this:

<nds dtdversion="2.2">
<product version="">DirXML</product>
<contact>Novell, Inc.</contact>
<modify class-name="User" dest-dn="acme\Users\jsmith"
dest-entry-id="36746" event-id="pwd-publish" src-dn="CN=Smith\,
<modify-attr attr-name="nspmDistributionPassword"
enforce-password-policy="false"><!-- content suppressed -->

The key is that the <modify-attr> node does not have a <add-value>
child, nor a <value> grandchild!

Now it does appear that the engine honours this event and changes the
password. (I think). But the Op Attr tokens cannot handle it.

This is basically the standard Pub-Command password set of rules, and it
is the result of the Add Dest Attr, nspmDistributionPassword, using the
Password() token as the value.

Cannot quite simulate this in Designer, since the trace has the
<--content-supressed--> line in it, and I cannot quite simulate that

Basically that event trace looks like:

[10/07/11 09:56:47.028]:AD PT: Evaluating selection criteria for rule
'[Acme] Change modify-password operations to a modify'.
[10/07/11 09:56:47.029]:AD PT: (if-global-variable
'publish-password-to-dp' equal "true") = TRUE.
[10/07/11 09:56:47.029]:AD PT: (if-operation equal
"modify-password") = TRUE.
[10/07/11 09:56:47.030]:AD PT: (if-password match ".+") = TRUE.
[10/07/11 09:56:47.030]:AD PT: Rule selected.
[10/07/11 09:56:47.031]:AD PT: Applying rule '[Acme] Change
modify-password operations to a modify'.
[10/07/11 09:56:47.031]:AD PT: Action:
[10/07/11 09:56:47.032]:AD PT: arg-string(token-password())
[10/07/11 09:56:47.032]:AD PT: token-password()
[10/07/11 09:56:47.032]:AD PT: Token Value: "-- suppressed --".
[10/07/11 09:56:47.033]:AD PT: Arg Value: "-- suppressed --".

Its that do-add-dest-attr with nothing special that looks to be doing
something odd.

Odd in the sense of how it normally works. I suspect the Suppressed
stuff is the real issue.

But just want someone else with an AD driver to take a quick look for me
and see what their drivers look at.

So its 3.6.13 AD driver on the RL, talking to a SLES engine server with
IDM 3.6.1 (forget what patch level).