Almost two and half years ago, I wrote an article about the Password transformations rules that are common in most of the Identity Manager driver configurations.

The article:
Password Transformation Rule Sets was focused on the Subscriber channel, that is events coming out of eDirectory on its way into the application.

In that specific article I used the default configuration from the Lotus Notes (aka Domino) driver from Identity Manager 3.5.

It really does not matter which particular driver you look at, so long as it is capable of synchronizing passwords on either channel. The rules are basically the same in each driver. There have been minor tweaks, between versions, but for the most part the general ideas have not changed much at all.

At the time of that article, I was writing about the default configuration that shipped with version 3.5 of Novell Identity Manager, since that time, of course Identity Manager 3.5, 3.5.1, 3.6, and 3.6.1 have all been released, with 4.0 due to be announced at BrainShare this year.

Yet even through all those changes in versions, the rules look basically the same. Which is pretty neat, as it means they were written quite well, to have such long legs!

I only focused on the Subscriber channel at the time and left the Publisher channel as an exercise for the reader. Initially, I was a bit tired from writing such a long detailed article, and as time moved on, I considered writing the second half, for the Publisher channel.

As I looked back over the intervening time, I realized that in fact, for the most part, the Publisher channel rules, are much the converse of the Subscriber channel rules.

Simply put, on the Subscriber channel, you the event you usually see for a password change is a modify of nspmDistributionPassword, which depending on the configuration of Password Management settings, gets transformed into a modify-password event in the application. The rest is all details.

On the Publisher channel a modify-password event is received, and depending on the configuration of the Password Management settings, it can stay a modify-password, (which will set the NDS password, and have interesting side effects), or be transformed into a modify of the nspmDistributionAttribute.

As always, the devil is in the details, but basically it is that simple. It just looks really complicated. Thus I did not really feel a pressing urge to finish the second half of the article.

However, since I am trying to encourage people to write articles walking through some of the default driver configurations, as you can see at this Wiki page: http://wiki.novell.com/index.php/Detailed_driver_walk_through_collection I have been chastised for only doing half the job.

Well if I want other people to contribute, I guess I should do my part as well. Thus here you have the long awaited second half of the password transformation rules, that you find in the Publisher channel of most driver configurations.

One big change between versions of Identity Manager is the naming scheme for policy and style sheet objects. If you look at the policy objects discussed in the first article. they had names like:

Password(Sub)-Transform Distribution Password

Password(Sub)-Default Password Policy

Password(Sub)-Check Password GCV

Password(Sub)-Add Password Payload

Well the Publisher Channel has analogous rules named:

Password(Pub)-Default Password Policy

Password(Pub)-Check Password GCV

Password(Pub)-Publish Distribution Password

Password(Pub)-Transform NDS Password

Password(Pub)-Add Password Payload

With the release of Identity Manager 3.6 and higher, the default policies were somewhat reworked, and renamed to the new naming standard.

They became:

Subscriber channel:

sub-ctp-TransformDistributionPassword

sub-ctp-CheckPasswordGCV

sub-ctp-AddPasswordPayload

Publisher Channel:

pub-ctp-DefaultPassword

pub-ctp-CheckPasswordGCV

pub-ctp-PublishDistributionPassword

pub-ctp-PublishNDSPassword

pub-ctp-AddPasswordPaylod

You should be able to see the pattern for much of it. Pub or Sub to start with for the channel. Then ctp for Command Transform (ct) and P for policy, as compared to an S for style sheet.

There are etp (Event Transform Policy), ets (Event transform Style sheet), itp/its for Input transform policy/style sheet, otp/ots for Output Transform, mp, cp, and pp for Matching, Create, and Placement policies respectively.

The naming allows for better identification of the rules without knowing the linkage, which is nice, and at least is consistent.

For this example, I am working through the LDAP drivers Publisher channel configuration from the Identity Manager 3.6.1 distribution that comes with Designer 3.5. I cannot use the Notes Publisher channel, since the passwords do not come out of Notes, because of the way Notes works with passwords. (A 'password' change in Notes, is actually NOT a password change per se, rather you are changing the encryption password for the users Private Key stored in the Notes ID file in use. Thus you could have three copies of your ID file, with different passwords, and all work, since they all successfully decode the private key. There is also an httpPassword, which does change in the traditional sense, but only the web interface uses it, and so far the driver cannot catch changes to that password). Thus there are actually no such rules on the Publisher channel of the Notes driver.

pub-ctp-DefaultPassword:

Users created without passwords are a security hole, and many systems will not accept users without passwords. (Active Directory gets all pissy if you try to create a user without a password. It lets you, but will not let you enable the user). Thus this rule makes sure we get a default password set, if there is not one available.

At this point, the conditions are for Add event, User object, and "password" not available. That means there is no <password> node in the document. Coming out of an application, if the password is noticed, and handled properly, it should be sent as the contents of the <password> node, as a child of the <add> node.

Obviously, unless this is an eDirectory driver, it does not make any sense to look for nspmDistributionPassword in the document at this point.

If there is no password in the add document then set a default of Dirxml1. With an upper case, a lower case, a number, and 7 digits, it should meet most password requirements. (It meets Active Directory's 3 of 4 rule).

This may or may not be sufficient for you, and I usually replace this with a GCV (Global Configuration Value), so that when the client changes their mind (again) on what the default password should be, I can easily change it.

pub-ctp-CheckPasswordGCV:

This rule blocks passwords from flowing, if the enable-password-publish is set to false. This is one of the Password Synchronization GCV's.

In Designer, you can see it in two ways:

Click to view.

You can control this via the Password Synchronization option, you get by right clicking on the driver line in the Modeler view of Designer as shown in the first screen shot.

This is where you should really be managing the settings. However, for general interest, it is interesting to note, that although there is a pretty interface in Designer really we are still just manipulating GCV values.

If you look at the GCV page on the driver properties page,

Click to view.

you will see a Password Management section, which has a single setting of "Show password management policy" and is defaults to Hide.

Set it to "show" and the picture changes

Click to view.

and all the underlying settings show up. Note there are all greyed out and marked as Manage from the Password Synchronization page.

You CAN, if you force the issue, change the GCV's directly, but since there is a 'better' interface for it now, I recommend against doing it by hand, the hard way. I just like knowing how things are really working under the covers, rather than just using it, so this was of interest to me.

In any case, if you have not told the driver to synchronize on the Publisher channel, then your event stops here. Either by stripping the <password> node out (Strip by XPath expression) or by vetoing a <modify-password> event.

pub-ctp-PublishDistributionPassword:

This rule checks the GCV publish-password-to-dp to see if the driver is set to use the Distribution Password. If not, nothing is done. If it set to true, then here is where nspmDistributionPassword gets added to the event document.

In the case of an <add> event this is a simple as an add destination event action, with the value coming from the Password() token.

Then we add some payload, about enforce-password-policy to true or false, based on the GCV setting. This is used later to decide what to do, if the password change fails, because it does not meet complexity rules.

In the case of a <modify-password> event, same thing with the add destination attribute for nspmDistributionPassword, but the enforce-password-policy is added to the document with the modify attribute that was just added, with a pwd-publish value set on the <modify> node.

pub-ctp-PublishNDSPassword:

Well this is pretty funny. It turns out that the LDAP driver configuration actually named this policy object put-ctp-PublishNDSPassword. See it? "put" not "pub". Oops, typo that is basically nothing more than cosmetic.

Again, we see a GCV controlling the action, publish-password-to-nds, and if it is false, then strip out the <password> node on <add> events, and veto the whole event on <modify-password> events. (There is always just a password change in a <modify-password> event, so it is ok to veto the whole thing without consequences.

Now it is important to discuss the consequences of Publishing to the NDS password.

When a <modify> with a modify-attr of nspmDistributionPassword event comes through, that changes the Universal Password. I was going to say directly, but really it sets the Distribution Password, which sets the Universal Password. I admit to not understanding what the consequences of that extra step are, but thats what it is.

If your Password Policy says synchronize the UP to the NDS password, then this would update the NDS password as well. That is NMAS, behind the scenes, not caring where the change to the UP came from, it could have been Identity Manager, it could have been an LDAP bind, it could have been Console1 on a client machine with the NMAS client. A UP password change is a UP password change to NMAS.

Thus, you should NOT need Publish to NDS password in most cases.

However, if you are doing the older version 1.0 approach to password synchronization, which predates the concept of Universal Password and Distribution Password, then you need to use the Publish to NDS password. If you are still using this older approach, I have one word for you. Upgrade. Hehe.

There is a real downside to Publish to NDS password though that is important to know. If you let a <modify-password> event flow back to eDirectory on the Publisher channel, then sure, the password will get changed. You need to have also allowed the npsmDistributionPassword flow as well to set the UP to match, else you will be in a strange mismatch of passwords state.

But the downside is that the password change will count as an administrative password change, even if the user initiated it themselves in the connected system. This means the password will be expired as it is changed, which will annoy users. Imagine, you change your password because it is close to expired. Now you have just changed it, and it is still expired!

Watch out for this one. I ran into this at a client, where some password changes were expiring passwords, some were not. It was a 2 eDirectory, 2 Active Directory domains, GroupWise, and a few other utility drivers, and it was very inconsistent.

It turned out that ONE of the Active Directory drivers was publishing to the NDS password, so changes in that AD domain, were causing the issue, but not other password changes events.

pub-ctp-AddPasswordPaylod:

Last rule in the set does what its name suggests. Adds some payload to the event. This too is used by other rules if needed. Nothing really special here.

Thus as I said in the beginning. On an <add> event you get a <password> node. On a modify, you get a <modify-password> event, out of the driver shim.

Based on your GCV's the password event remains in the document (set NDS password), gets converted to a <modify-attr> of the nspmDistributionPassword or any combination of those two, or even none!