Introduction

A personal peeve of mine is this: although there are a stack of policies in the default IDM driver sets that do really important stuff, as far as I can tell, there is no documentation of what exactly, rule by rule, they are doing.

In most cases this is kind of annoying but harmless, since they just plain work. But the password transformation rules are complicated and non-obvious.

Solution

I think I finally have a basic understanding of the typical Subscriber Channel Command Transform rule set as it relates to passwords. I have yet to attempt the Publisher rule set; I hope some one will try to figure them out and post the results.

Note: This is for IDM 3.5, with the Enginefp patch, using the Notes 3.5 driver, with the 3.5 driver import. This is important, because password changes in the Notes driver will not work for changing the Notes ID file unless you use the new rules in the Subscriber Command
Transform.

There are two basic ways a password change shows up in the Subscriber channel: an add event, or a modify event. Usually the add is caused by a synthetic add, since most adds have requirements that veto until they are met.

Sample Add Document

Here is a sample add document from the Notes driver Subscriber channel. All the stuff in the <add> element is added in a create rule called AddAccountOptions in the default driver set. This is sort of immaterial, but it's interesting to see all the things the Notes driver needs to know to create an account!

This came via a synthetic add; for this Notes driver we wanted Given Name, Surname, and Full Name populated before we created it. So it got vetoed a couple of times before being created.

<nds dtdversion="3.5" ndsversion="8.x">
<source>
  <product version="3.5.1.20070411 ">DirXML</product>
  <contact>Novell, Inc.</contact>
</source>
<input>
  <add allow-adminp-support="true" certify-user="true" class-name="User"
create-mail="true" event-id="TESTACME1#20070628194836#1#2"
expire-term="2" internet-password-force-change="false"
mail-acl-manager-name="CN=IDMUSR SYSTEM/O=adtest"
mail-file-inherit-flag="true" no-id-file="false"
notes-password-change-interval="0"
notes-password-check-setting="PWD_CHK_CHECKPASSWORD"
notes-password-grace-period="0" notes-policy-name="/ADTEST"
qualified-src-dn="C=US\O=ACMEC\OU=idmusers\CN=UKane"
roaming-cleanup-period="90"
roaming-cleanup-setting="REG_ROAMING_CLEANUP_EVERY_NDAYS"
roaming-server="CN=testnl.adtest.com/O=adtest"
roaming-subdir="Roaming\UmKane" roaming-user="false"
src-dn="\TIDM\US\ACMEC\idmusers\UKane" src-entry-id="33552"
store-useridfile-in-ab="true" sync-internet-password="true"
tell-adminp-process="tell adminp process all" user-id-file="UKane.id">
    <add-attr attr-name="CN">
      <value naming="true" timestamp="1183060114#27" type="string">UKane</value>
    </add-attr>
    <add-attr attr-name="Given Name">
      <value timestamp="1183060114#5" type="string">Um</value>
    </add-attr>
    <add-attr attr-name="nspmDistributionPassword"><!-- content suppressed -->
    </add-attr>
    <add-attr attr-name="Surname">
      <value timestamp="1183060114#7" type="string">Kane</value>
    </add-attr>
    <add-attr attr-name="uniqueID">
      <value type="string">UKane</value>
    </add-attr>
    <add-attr attr-name="MailFile">
     <value>UKane.nsf</value>
    </add-attr>
    <add-attr attr-name="Internet EMail Address">
      <value>UKane@adtest.com</value>
    </add-attr>
  </add>
</input>
</nds>

The key line to note is this:

<add-attr attr-name="nspmDistributionPassword"><!-- content suppressed -->

Here we have the nspmDistributionPassword coming in as a regular attribute. Note that IDM is smart enough to NOT show the value to the trace (which is a good thing!)

Next, we have the trace as we hit the Subscriber Command Transform:

15:48:46 920F9320 Drvrs: Notes ST:Applying policy: 'Transform NMAS
attribute to password elements'.
15:48:46 920F9320 Drvrs: Notes ST: Applying to add #1.
15:48:46 920F9320 Drvrs: Notes ST: Evaluating selection criteria for
rule 'Convert adds of the nspmDistributionPassword attribute to
password element'.
15:48:46 920F9320 Drvrs: Notes ST: (if-operation equal "add") = TRUE.
15:48:46 920F9320 Drvrs: Notes ST: (if-op-attr
'nspmDistributionPassword' available) = TRUE.
15:48:46 920F9320 Drvrs: Notes ST: Rule selected.
15:48:46 920F9320 Drvrs: Notes ST: Applying rule 'Convert adds of the
nspmDistributionPassword attribute to password element'.
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-set-dest-password(token-op-attr("nspmDistributionPassword")).
15:48:46 920F9320 Drvrs: Notes ST:
arg-string(token-op-attr("nspmDistributionPassword"))
15:48:46 920F9320 Drvrs: Notes ST: token-op-attr("nspmDistributionPassword")
15:48:46 920F9320 Drvrs: Notes ST: Token Value: "-- suppressed --".
15:48:46 920F9320 Drvrs: Notes ST: Arg Value: "-- suppressed --".
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-strip-op-attr("nspmDistributionPassword").

Here we test to see if there is an actual nspmDistributionPassword still in the document. There is, on an add, so we fire the rule. It sets a <password> element with the value of the
nspmDistributionPassword. Then it removes the add attribute for nspmDistributionPassword from the document.

Basically it does what the name says: it converts the add attribute element to a password element.

15:48:46 920F9320 Drvrs: Notes ST: Evaluating selection criteria for rule 'Convert modifies of a nspmDistributionPassword attribute to a modify password operation'.
15:48:46 920F9320 Drvrs: Notes ST: (if-operation equal "modify") = FALSE.
15:48:46 920F9320 Drvrs: Notes ST: Rule rejected.

This is not a modify operation document, so the rule does not fire. But basically it does the same thing: it removes the add attribute of nspmDistributionPassword and changes it to a <password> element.

15:48:46 920F9320 Drvrs: Notes ST: Evaluating selection criteria for
rule 'Block empty modify operations'.
15:48:46 920F9320 Drvrs: Notes ST: (if-operation equal "modify") = FALSE.
15:48:46 920F9320 Drvrs: Notes ST: Rule rejected.

This last rule matters more in a modify. Usually a password change comes across as a modify of a single attribute, of course our favorite nspmDistributionPassword. In which case the document gets the password modify in a new event, and there is a modify, with the modify removed, so this last rule vetos the empty modify.

15:48:46 920F9320 Drvrs: Notes ST:Policy returned:
15:48:46 920F9320 Drvrs: Notes ST:

So at the end of the policies we have the following document:

<nds dtdversion="3.5" ndsversion="8.x">
<source>
  <product version="3.5.1.20070411 ">DirXML</product>
  <contact>Novell, Inc.</contact>
</source>
<input>
  <add allow-adminp-support="true" certify-user="true" class-name="User"
create-mail="true" dest-dn="CN=UKane/O=adtest"
event-id="TESTACME1#20070628194836#1#2" expire-term="2"
internet-password-force-change="false"
mail-acl-manager-name="CN=IDMUSR SYSTEM/O=adtest"
mail-file-inherit-flag="true" no-id-file="false"
notes-password-change-interval="0"
notes-password-check-setting="PWD_CHK_CHECKPASSWORD"
notes-password-grace-period="0" notes-policy-name="/ADTEST"
qualified-src-dn="C=US\O=ACMEC\OU=idmusers\CN=UKane"
roaming-cleanup-period="90"
roaming-cleanup-setting="REG_ROAMING_CLEANUP_EVERY_NDAYS"
roaming-server="CN=testnl.adtest.com/O=adtest"
roaming-subdir="Roaming\UmKane" roaming-user="false"
src-dn="\TIDM\US\ACMEC\idmusers\UKane" src-entry-id="33552"
store-useridfile-in-ab="true" sync-internet-password="true"
tell-adminp-process="tell adminp process all" user-id-file="UKane.id">
    <add-attr attr-name="CN">
      <value naming="true" timestamp="1183060114#27" type="string">UKane</value>
    </add-attr>
    <add-attr attr-name="Given Name">
      <value timestamp="1183060114#5" type="string">Um</value>
    </add-attr>
    <add-attr attr-name="Surname">
      <value timestamp="1183060114#7" type="string">Kane</value>
    </add-attr>
    <add-attr attr-name="uniqueID">
      <value timestamp="1183060114#8" type="string">UKane</value>
    </add-attr>
    <add-attr attr-name="MailFile">
15:48:46 920F9320 Drvrs: <value>UKane.nsf</value>
    </add-attr>
    <add-attr attr-name="Internet EMail Address">
      <value>UKane@adtest.com</value>
    </add-attr>
    <password><!-- content suppressed --></password>
  </add>
</input>
</nds>

Note that the for nspmDistributionPassword is gone, and <password> is there in its place.

Password(Sub)-Default Password Policy

Now for the next rule in the chain: the Password (Sub)-Default Password Policy. Basically, if an add gets through without a password in the add, let's create a default one. I usually set it to a GCV that defines the default password. This also catches a case where the previous policy does not properly fire, and it adds a <password> element with a default password.

15:48:46 920F9320 Drvrs: Notes ST:Applying policy:
Password(Sub)-Default Password Policy.
15:48:46 920F9320 Drvrs: Notes ST: Applying to add #1.
15:48:46 920F9320 Drvrs: Notes ST: Evaluating selection criteria for
rule 'On User add, provide default password of Dirxml1 if none
exists'.
15:48:46 920F9320 Drvrs: Notes ST: (if-operation equal "add") = TRUE.
15:48:46 920F9320 Drvrs: Notes ST: (if-class-name equal "User") = TRUE.
15:48:46 920F9320 Drvrs: Notes ST: (if-password not-available) = FALSE.
15:48:46 920F9320 Drvrs: Notes ST: Rule rejected.

In our case we have a password in our document, so not much change:

15:48:46 920F9320 Drvrs: Notes ST:Policy returned:
15:48:46 920F9320 Drvrs: Notes ST:

<nds dtdversion="3.5" ndsversion="8.x">
<source>
  <product version="3.5.1.20070411 ">DirXML</product>
  <contact>Novell, Inc.</contact>
</source>
<input>
  <add allow-adminp-support="true" certify-user="true" class-name="User"
create-mail="true" dest-dn="CN=UKane/O=adtest"
event-id="TESTACME1#20070628194836#1#2" expire-term="2"
internet-password-force-change="false"
mail-acl-manager-name="CN=IDMUSR SYSTEM/O=adtest"
mail-file-inherit-flag="true" no-id-file="false"
notes-password-change-interval="0"
notes-password-check-setting="PWD_CHK_CHECKPASSWORD"
notes-password-grace-period="0" notes-policy-name="/ADTEST"
qualified-src-dn="C=US\O=ACMEC\OU=idmusers\CN=UKane"
roaming-cleanup-period="90"
roaming-cleanup-setting="REG_ROAMING_CLEANUP_EVERY_NDAYS"
roaming-server="CN=testnl.adtest.com/O=adtest"
roaming-subdir="Roaming\UmKane" roaming-user="false"
src-dn="\TIDM\US\ACMEC\idmusers\UKane" src-entry-id="33552"
store-useridfile-in-ab="true" sync-internet-password="true"
tell-adminp-process="tell adminp process all" user-id-file="UKane.id">
    <add-attr attr-name="CN">
      <value naming="true" timestamp="1183060114#27" type="string">UKane</value>
    </add-attr>
    <add-attr attr-name="Given Name">
      <value timestamp="1183060114#5" type="string">Um</value>
    </add-attr>
    <add-attr attr-name="Surname">
      <value timestamp="1183060114#7" type="string">Kane</value>
    </add-attr>
    <add-attr attr-name="uniqueID">
      <value timestamp="1183060114#8" type="string">UKane</value>
    </add-attr>
    <add-attr attr-name="MailFile">
15:48:46 920F9320 Drvrs: <value>UKane.nsf</value>
    </add-attr>
    <add-attr attr-name="Internet EMail Address">
      <value>UKane@adtest.com</value>
    </add-attr>
    <password><!-- content suppressed --></password>
  </add>
</input>
</nds>

15:48:46 920F9320 Drvrs: Notes ST:Applying policy: 'Subscribe to
password changes'.
15:48:46 920F9320 Drvrs: Notes ST: Applying to add #1.

This next rule did not do much since I disabled it. There are some GCV's that control whether you allow passwords to flow. This rule checks to see if you have turned off password flow on the subscriber channel, in which case it removes the password element. If you are doing IDM, usually the value add is the password synchronization. So, I do not see why you would ever want this rule to fire. But there is probably a use case that makes sense for someone (but not for me). That said. it's best to disable them to save a little bit of processing time. Of course, if I ever wanted to turn it back on, it is a lot more work than just flipping the GCV, as it used to be.

15:48:46 920F9320 Drvrs: Notes ST:Policy returned:
15:48:46 920F9320 Drvrs: Notes ST:

Adding Payloads to the Document

On to our next rule - adding some payloads to the document. Now, here I am not so clear. I think this is all for the return of a success notice.

This rule:

• Adds a new element called <operation-data> and puts some info into it.

• Adds an element <password-subscribe-status>, tries to add the association value (I.e. what the object unique identifier in the target system is), which is not there, probably because this is an add, so the object does not yet exist.

• Adds the src-dn, which tells us which user the password change event happened on.

15:48:46 920F9320 Drvrs: Notes ST:Applying policy: 'Payloads for
subscribe to password changes'.
15:48:46 920F9320 Drvrs: Notes ST: Applying to add #1.
15:48:46 920F9320 Drvrs: Notes ST: Evaluating selection criteria for
rule 'Add payload data to password subscribe operations'.
15:48:46 920F9320 Drvrs: Notes ST: (if-operation equal "add") = TRUE.
15:48:46 920F9320 Drvrs: Notes ST: (if-password available) = TRUE.
15:48:46 920F9320 Drvrs: Notes ST: Rule selected.
15:48:46 920F9320 Drvrs: Notes ST: Applying rule 'Add payload data to
password subscribe operations'.
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("operation-data",".").
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("password-subscribe-status","./operation-data").
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("association","./operation-data/password-subscribe-status").
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-append-xml-text("./operation-data/password-subscribe-status/association",token-association()).
15:48:46 920F9320 Drvrs: Notes ST: arg-string(token-association())
15:48:46 920F9320 Drvrs: Notes ST: token-association()
15:48:46 920F9320 Drvrs: Notes ST: Token Value: "".
15:48:46 920F9320 Drvrs: Notes ST: Arg Value: "".
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("src-dn","./operation-data/password-subscribe-status").
15:48:46 920F9320 Drvrs: Notes ST: Action:
do-append-xml-text("./operation-data/password-subscribe-status/src-dn",token-src-dn()).
15:48:46 920F9320 Drvrs: Notes ST: arg-string(token-src-dn())
15:48:46 920F9320 Drvrs: Notes ST: token-src-dn()
15:48:46 920F9320 Drvrs: Notes ST: Token Value: "\TIDM\US\ACMEC\idmusers\UKane".
15:48:46 920F9320 Drvrs: Notes ST: Arg Value: "\TIDM\US\ACMEC\idmusers\UKane".
15:48:46 920F9320 Drvrs: Notes ST:Policy returned:
15:48:46 920F9320 Drvrs: Notes ST:

The new document is pretty much at the end of the document, since we are appending.

<nds dtdversion="3.5" ndsversion="8.x">
<source>
  <product version="3.5.1.20070411 ">DirXML</product>
  <contact>Novell, Inc.</contact>
</source>
<input>
  <add allow-adminp-support="true" certify-user="true" class-name="User"
create-mail="true" dest-dn="CN=UKane/O=adtest"
event-id="TESTACME1#20070628194836#1#2" expire-term="2"
internet-password-force-change="false"
mail-acl-manager-name="CN=IDMUSR SYSTEM/O=adtest"
mail-file-inherit-flag="true" no-id-file="false"
notes-password-change-interval="0"
notes-password-check-setting="PWD_CHK_CHECKPASSWORD"
notes-password-grace-period="0" notes-policy-name="/ADTEST"
qualified-src-dn="C=US\O=ACMEC\OU=idmusers\CN=UKane"
roaming-cleanup-period="90"
roaming-cleanup-setting="REG_ROAMING_CLEANUP_EVERY_NDAYS"
roaming-server="CN=testnl.adtest.com/O=adtest"
roaming-subdir="Roaming\UmKane" roaming-user="false"
src-dn="\TIDM\US\ACMEC\idmusers\UKane" src-entry-id="33552"
store-useridfile-in-ab="true" sync-internet-password="true"
tell-adminp-process="tell adminp process all" user-id-file="UKane.id">
    <add-attr attr-name="CN">
      <value naming="true" timestamp="1183060114#27" type="string">UKane</value>
    </add-attr>
    <add-attr attr-name="Given Name">
      <value timestamp="1183060114#5" type="string">Um</value>
    </add-attr>
    <add-attr attr-name="Surname">
      <value timestamp="1183060114#7" type="string">Kane</value>
    </add-attr>
    <add-attr attr-name="uniqueID">
      <value timestamp="1183060114#8" type="string">UKane</value>
    </add-attr>
<add-attr attr-name="MailFile">
15:48:46 920F9320 Drvrs: <value>UKane.nsf</value>
    </add-attr>
    <add-attr attr-name="Internet EMail Address">
      <value>UKane@adtest.com</value>
    </add-attr>
  <password><!-- content suppressed --></password>

So far, it's our regular add document.

<operation-data>
<password-subscribe-status>
<association/>
<src-dn>\TIDM\US\ACMEC\idmusers\UKane</src-dn>
</password-subscribe-status>
</operation-data>

So as described above, we added a bunch of info that helps us track what happens to the document when it returns from the shim.

</add>
</input>
</nds>

Now I think this is useful, because in the return document from the driver shim we see this document asking to add an association value. From Notes, this is the UNID (Universal ID), like a GUID in AD or eDir. Note that it has the operation-data info, which includes the src-dn so, we know for sure whom it is talking about.

<nds dtdversion="2.0" ndsversion="8.x">
<source>
  <product build="20070301_0629 " instance="Notes"
version="3.5.0">Identity Manager Driver for Lotus Notes</product>
  <contact>Novell, Inc.</contact>
</source>
<output>
  <status event-id="TESTACME1#20070628194836#1#2" level="success">
    <operation-data>
      <password-subscribe-status>
        <association/>
        <src-dn>\TIDM\US\ACMEC\idmusers\UKane</src-dn>
      </password-subscribe-status>
    </operation-data>
  </status>
    <add-association dest-dn="\TIDM\US\ACMEC\idmusers\UKane"
event-id="TESTACME1#20070628194836#1#2">C8AA493133D2DB5D85257308006C64B3<operation-data>
      <password-subscribe-status>
        <association/>
        <src-dn>\TIDM\US\ACMEC\idmusers\UKane</src-dn>
      </password-subscribe-status>
    </operation-data>
    </add-association>
  <status event-id="TESTACME1#20070628194836#1#2" level="success"
type="app-general">
    <mailfile-creation filename="mail\UKane.nsf"
server="CN=testnl.adtest.com/O=adtest">success</mailfile-creation>
    <operation-data>
      <password-subscribe-status>
        <association/>
        <src-dn>\TIDM\US\ACMEC\idmusers\UKane</src-dn>
      </password-subscribe-status>
    </operation-data>
  </status>
</output>
</nds>

Here is what a modify of a password by itself looks like:

<nds dtdversion="3.5" ndsversion="8.x">
<source>
  <product version="3.5.1.20070411 ">DirXML</product>
  <contact>Novell, Inc.</contact>
</source>
<input>
  <modify class-name="User" event-id="adlink##11373dc969e##0"
qualified-src-dn="C=US\O=ACMEC\OU=idmusers\CN=UKane"
src-dn="\TIDM\US\ACMEC\idmusers\UKane" src-entry-id="33552"
timestamp="1183060133#7">
    <association state="associated">C8AA493133D2DB5D85257308006C64B3</association>
    <modify-attr attr-name="nspmDistributionPassword"><!-- content
suppressed --><!-- content suppressed -->
    </modify-attr>
  </modify>
</input>
</nds>

So again, we start with a modify of the nspmDistributionPassword, and we need to convert that to a <password> element. So the earlier rule that failed to fire because it was an add, not a modify, will fire on this one. I will skip all the other rules here and just show the
interesting ones. Here we are again in the second rule:

15:48:55 920F9320 Drvrs: Notes ST: Evaluating selection criteria for
rule 'Convert modifies of a nspmDistributionPassword attribute to a
modify password operation'.
15:48:55 920F9320 Drvrs: Notes ST: (if-operation equal "modify") = TRUE.
15:48:55 920F9320 Drvrs: Notes ST: (if-class-name equal "User") = TRUE.
15:48:55 920F9320 Drvrs: Notes ST: (if-op-attr
'nspmDistributionPassword' available) = TRUE.
15:48:55 920F9320 Drvrs: Notes ST: (if-xpath true
"modify-attr[@attr-name='nspmDistributionPassword']/remove-value/value")
= TRUE.

This is a modify on a User. It has the nspmDistributionPassword attribute in it, and there are two values. That last XPATH checks to be sure that if you remove the last value of
nspmDistributionPassword, there is still a value. That means there are two values sent - interesting!

This is needed for the Notes driver, as one is the old password, and one is the new password. There is a ECV (Engine Control Value) in the Notes driver configuration that needs to be enabled for this to work. See http://www.novell.com/coolsolutions/feature/19091.html for more details, but in summary, it is the ECV called 'Use password event values' (ecnm_pevvl).

So, we go into our action set:

15:48:55 920F9320 Drvrs: Notes ST: Rule selected.
15:48:55 920F9320 Drvrs: Notes ST: Applying rule 'Convert modifies of
a nspmDistributionPassword attribute to a modify password operation'.
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-set-dest-password(token-op-attr("nspmDistributionPassword")).

We set the destination password with the value of nspmDistributionPassword, which basically means adding the <password> attribute, just like in the add rule.

15:48:55 920F9320 Drvrs: Notes ST:
arg-string(token-op-attr("nspmDistributionPassword"))
15:48:55 920F9320 Drvrs: Notes ST: token-op-attr("nspmDistributionPassword")
15:48:55 920F9320 Drvrs: Notes ST: Token Value: "-- suppressed --".
15:48:55 920F9320 Drvrs: Notes ST: Arg Value: "-- suppressed --".
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-set-xml-attr("allow-userid-password-set","../modify-password","true").
15:48:55 920F9320 Drvrs: Notes ST: arg-string("true")
15:48:55 920F9320 Drvrs: Notes ST: token-text("true")
15:48:55 920F9320 Drvrs: Notes ST: Arg Value: "true".

This allow-userid-password-set is required to tell the Notes shim to try and set the Notes ID password (a really cool new feature in IDM 3.5). In principle this is overkill, since there is a driver configuration value that sets this for the entire driver, but what the heck, I am pretty sure the developer knows something I don't. Actually, I KNOW he knows a lot that I don't!

15:48:55 920F9320 Drvrs: Notes ST: Action:
do-set-xml-attr("allow-http-password-set","../modify-password","true").
15:48:55 920F9320 Drvrs: Notes ST: arg-string("true")
15:48:55 920F9320 Drvrs: Notes ST: token-text("true")
15:48:55 920F9320 Drvrs: Notes ST: Arg Value: "true".
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-set-xml-attr("allow-adminp-support","../modify-password","true").
15:48:55 920F9320 Drvrs: Notes ST: arg-string("true")
15:48:55 920F9320 Drvrs: Notes ST: token-text("true")
15:48:55 920F9320 Drvrs: Notes ST: Arg Value: "true".

These are similar to the previous one, just telling the shim what is allowed to do.

15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("old-password","../modify-password").

So now we add an <old-password> element with the old password in it.

15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-text("../modify-password/old-password",token-xpath("../modify/modify-attr[@attr-name='nspmDistributionPassword']/remove-value/value/text()")).
15:48:55 920F9320 Drvrs: Notes ST:
arg-string(token-xpath("../modify/modify-attr[@attr-name='nspmDistributionPassword']/remove-value/value/text()"))
15:48:55 920F9320 Drvrs: Notes ST:
token-xpath("../modify/modify-attr[@attr-name='nspmDistributionPassword']/remove-value/value/text()")
15:48:55 920F9320 Drvrs: Notes ST: Token Value: "KaneDirxml1".
15:48:55 920F9320 Drvrs: Notes ST: Arg Value: "KaneDirxml1".

This action is set as "Do not trace", and normally you would not see this trace segment, which is a new feature in IDM 3.5. This is very useful, since we do not normally want to show the password. In this case, I do, so I turned off the "do not trace" flag. This helped me realize that my problem was a password event flowing back from another driver, since I recognized the patter of Surname then Dirxml1 as one of the default password rules.

I then exported the driver set (4 drivers in it) and did a global search for Dirxml1. I found the rule it was coming from (only one place, since to track it I changed all the defaults to be
fromDriverName, but I clearly missed one. Oops!). But that is my problem, should be yours.

15:48:55 920F9320 Drvrs: Notes ST: Action:
do-set-xml-attr("event-id","../modify-password","subscriber-password-set-1").
15:48:55 920F9320 Drvrs: Notes ST: arg-string("subscriber-password-set-1")
15:48:55 920F9320 Drvrs: Notes ST: token-text("subscriber-password-set-1")
15:48:55 920F9320 Drvrs: Notes ST: Arg Value: "subscriber-password-set-1".

Now we add an <event-id> element that calls itself subscriber-password-set-1. I am not sure of the reason for this one - it seems arbitrary, unless there is something looking for it. If there is, I have not found it yet.

15:48:55 920F9320 Drvrs: Notes ST: Action:
do-strip-op-attr("nspmDistributionPassword").

Then we take out the modify attribute for nspmDistributionPassword. Now we have a basically empty document, since it contained only a modify attribute, and now it does not.

That is why we have the next rule, Block empty modify operations. Thus, it gets vetoed.

15:48:55 920F9320 Drvrs: Notes ST: Evaluating selection criteria for
rule 'Block empty modify operations'.
15:48:55 920F9320 Drvrs: Notes ST: (if-operation equal "modify") = TRUE.
15:48:55 920F9320 Drvrs: Notes ST: (if-xpath not-true "modify-attr") = TRUE.
15:48:55 920F9320 Drvrs: Notes ST: Rule selected.
15:48:55 920F9320 Drvrs: Notes ST: Applying rule 'Block empty modify
operations'.
15:48:55 920F9320 Drvrs: Notes ST: Action: do-veto().

Remember that our document at one time was a <modify> operation; now it is a <modify-password> operation. We added some setting values for the driver shim (such as allow-userid-password-set, etc.).

<nds dtdversion="3.5" ndsversion="8.x">
<source>
  <product version="3.5.1.20070411 ">DirXML</product>
  <contact>Novell, Inc.</contact>
</source>
<input>
  <modify-password allow-adminp-support="true"
allow-http-password-set="true" allow-userid-password-set="true"
class-name="User" event-id="subscriber-password-set-1"
src-dn="\TIDM\US\ACMEC\idmusers\UKane" src-entry-id="33552">
    <association>C8AA493133D2DB5D85257308006C64B3</association>
    <password><!-- content suppressed --></password>
    <old-password><!-- content suppressed --></old-password>
  </modify-password>
</input>
</nds>

Then we add the payload, like we did on the add operation. Now it looks more useful, as we have an association value to show in it.

15:48:55 920F9320 Drvrs: Notes ST:Applying policy: 'Payloads for
subscribe to password changes'.
15:48:55 920F9320 Drvrs: Notes ST: Applying to modify-password #1.
15:48:55 920F9320 Drvrs: Notes ST: Evaluating selection criteria for
rule 'Add payload data to password subscribe operations'.
15:48:55 920F9320 Drvrs: Notes ST: (if-operation equal "add") = FALSE.
15:48:55 920F9320 Drvrs: Notes ST: (if-operation equal
"modify-password") = TRUE.
15:48:55 920F9320 Drvrs: Notes ST: Rule selected.
15:48:55 920F9320 Drvrs: Notes ST: Applying rule 'Add payload data to
password subscribe operations'.
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("operation-data",".").
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("password-subscribe-status","./operation-data").
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("association","./operation-data/password-subscribe-status").
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-text("./operation-data/password-subscribe-status/association",token-association()).
15:48:55 920F9320 Drvrs: Notes ST: arg-string(token-association())
15:48:55 920F9320 Drvrs: Notes ST: token-association()
15:48:55 920F9320 Drvrs: Notes ST: Token Value:
"C8AA493133D2DB5D85257308006C64B3".
15:48:55 920F9320 Drvrs: Notes ST: Arg Value:
"C8AA493133D2DB5D85257308006C64B3".
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-element("src-dn","./operation-data/password-subscribe-status").
15:48:55 920F9320 Drvrs: Notes ST: Action:
do-append-xml-text("./operation-data/password-subscribe-status/src-dn",token-src-dn()).
15:48:55 920F9320 Drvrs: Notes ST: arg-string(token-src-dn())
15:48:55 920F9320 Drvrs: Notes ST: token-src-dn()
15:48:55 920F9320 Drvrs: Notes ST: Token Value: "\TIDM\US\ACMEC\idmusers\UKane".
15:48:55 920F9320 Drvrs: Notes ST: Arg Value: "\TIDM\US\ACMEC\idmusers\UKane".
15:48:55 920F9320 Drvrs: Notes ST:Policy returned:
15:48:55 920F9320 Drvrs: Notes ST:

This looks more interesting than in the add, with the src-dn and association value, which is useful for tracking.

<nds dtdversion="3.5" ndsversion="8.x">
<source>
  <product version="3.5.1.20070411 ">DirXML</product>
  <contact>Novell, Inc.</contact>
</source>
<input>
  <modify-password allow-adminp-support="true"
allow-http-password-set="true" allow-userid-password-set="true"
class-name="User" event-id="subscriber-password-set-1"
src-dn="\TIDM\US\ACMEC\idmusers\UKane" src-entry-id="33552">
    <association>C8AA493133D2DB5D85257308006C64B3</association>
    <password><!-- content suppre class="code"ssed --></password>
    <old-password><!-- content suppressed --></old-password>
    <operation-data>
    <password-subscribe-status>
    <association>C8AA493133D2DB5D85257308006C64B3</association>
      <src-dn>\TIDM\US\ACMEC\idmusers\UKane</src-dn>
    </password-subscribe-status>
    </operation-data>
  </modify-password>
</input>
</nds>

Conclusion

For now, that is about it. There are a couple of consequences to note.

I like using the Event Transform to react to certain events. Sometimes you might want to do something to a modify-password operation. If you followed me this far, you should realize that the modify-password gets created WAY after the Event Transform, in the Command Transform, and therefore there is no way point in trying to deal with it that early. You should probably use the Output transform if you really need to.

I am sure there is more to be said about this topic, and I would love to hear about it!