A Forum reader asked this question:
"We are using IDM3 eDir-to-eDir w/distribution passwords. Accounts exist in both directories before the first sync. I discovered the following pattern at the receiving directory.
1) Driver receives "synthetic" add message from IDVault with password.
2) Driver processes matching rule and finds a match.
3) Driver performs a merge - password is lost.
4) Driver sends message back indicating status=success, with new association.
On the first sync of the account, the password is not changed in the receiving directory, but the association is created. Subsequent password changes are synchronized properly, since they are sent through as a modify operation.
What sort of rule could I use (preferably at the IDVault side) to ensure the remote account's password is set on the first sync? I tried triggering at the publisher input transformation policy on the returned add-association operation, with a do-set-src-password(token-dest-attr(nspmDistributionPassword)), but that got me "Unable to determine target object for action".
The returned message does not move past the publisher schema map, so I cannot catch it later. I'm stumped."
And here's a suggestion from Father Ramon ...
For the eDir driver, there is no way to set up the filter to automatically set the password on a match unless you throw away all of the policies that deal with passwords and synchronize nspmDistributionPassword directly (which I don't really recommend).
What I would do is add an additional rule to the end of the publisher matching policy - something like this:
<description>set password if match found</description>
<if-xpath op="true">string-length(@dest-dn) > 1</if-xpath>
<if-password op="available" />
Note: For most drivers it isn't a problem with 3.0.1, just set the merge authority for nspmDistributionPassword to eDir. For the eDir driver it isn't as straightforward, because a) the matching always happens on the publisher channel, and b) policies on the subscriber channel remove
nspmDistributionPassword from the add and change it into a password element. This password element doesn't participate in the merge (though I believe there is an open enhancement request to change that).