Passwords in eDirectory are somewhat complicated things, and in fact sometimes it seems like there are too many.

The good news is that it is not that hard to understand them all, there is just a fair bit of detail involved, and once you get used to it, it all starts to make a lot of sense.

There is the original RSA key pairs (The actual attribute names in eDirectory are Public Key and Private Key. The latter is protected from most tools being able to see it for obvious reasons).

These are great for security, as a secret never crosses the wire, and so far no one has broken the RSA key pair algorithm as far as I know. (RSA tokens yes, key pairs no). However they have a weakness, which is their strength, that they are not reversible. As the concept of things like Identity Manager came up, the need for a reversible password became clear.

The first attempt was Simple Password which was provided to allow multiple encrypted passwords or at least retrievable passwords for allowing users to connect over AFP (Apples File Protocol). CIFS (The protocol Windows uses), or NFS (a protocol that Unix boxes use) where the password is encrypted differently in each case. (apples is amusing since it does actually require that the clear text password be available at the server end, whereas the CIFS and NFS suffice with storing an encrypted value at the server end.

Enhanced Password was an attempt via an NMAS authentication plugin module to require more password complexity, but that too did not last as this one required client side changes.

Universal Password is what we have settled on so far. This is the way forward for eDirectory and it has a lot of positives. It is retrievable by the server, user, or (if policy allows it) the admin. It allows all sorts of complexity models as you can see when you set up a password policy.

This actually can be very helpful, since there are tools to allow you to retrieve the password, if you have permission set in the policy. The best is by Jim Willeke, and is available at: http://ldapwiki.willeke.com/Wiki.jsp?page=DumpEdirectoryPasswordInformationTool

You can read the authors introduction to the tool here: Password Information Tool

I wrote up some common usage examples here: Examples of Jim Willeke's Dump UP Tool

Even without permission to retrieve the passwords, this tool is worth its weight in gold. When I have a client with more than one eDirectory tree, I write a batch file that connects to each tree, finds the user by some naming attribute, and outputs the password related information. You can specify what to search on, be that CN, uid, mail, etc (in LDAP attribute name space).

This will tell you by default the Password Policy that applies to the user. Also the full DN of the user which can be useful and save you a search for further investigation. Is the password complying with the policy? If it is too short (-216 error), too long (-16000 error), missing a mandatory character, not enough digits, not enough letters, etc. All this just by asking the question, without seeing the password.

Next up you get informed about its synchronization state with Simple and NDS passwords. Now you might not be syncing to the Simple password in the Password Policy which is fine, but if you are, its good to know. We have found in production something out there corrupting the Simple Password, and we get a NMAS -1658 error trying to change a password once that happens. We have not been able to figure out what is causing it yet, but we can now detect it. When we look at an object and see that Simple does not match the NDS or UP password, then we know that the problem is likely upon us. To fix it, we have been clearing the sasLoginConfiguration* set of attributes. These are where Simple Password is stored as an encrypted value, but also the Challenge Response and possibly Password Hint values. Its a bit of overkill, but it gets us working again.

With the extra information switch (-E) you get told the Password Expiration Time (if available), the Login Expiration time if the account expires. If the account is Intruder Locked, the lockout time. If the user is Password Expired the number of Grace Logins remaining is shown.

As you can imagine this tool is just priceless to a helpdesk person trying to troubleshoot a password sync issue. They get to see on one screen the current password related state from multiple trees. I can't live without it for troubleshooting these days.

Back to the nature of Universal Password, it turns out there is an even more interesting tidbit that it really is two passwords. Because one would just not be enough, why ever would you want to simplify the password landscape when you can make it more complex! There is the Universal Password itself, stored in a very hidden (much like how Private Key is hidden for the RSA key pairs) attribute called nspmPassword, and then there is the Distribution Password which is slightly more visible and stored in an attribute called nspmDistributionPassword.

In fact, although we often say that Identity Manager uses the Universal Password to synchronize passwords that is factually incorrect. It really uses the Distribution Password. You can see that very clearly when you watch a password change event in Identity Manager.

Coming from the application you will get a <modify-password> event, and that will get transformed in the Publisher Command Transform according to the settings for the driver. If you are syncing to the RSA key pairs passwords (Which is still allowed, called Password Sync 1.0) then the event continues as a <modify-password> event. If you are set to use Distribution Password then the event gets changed to a <modify> event for the attribute nspmDistributionPassword and the <modify-password> event is stripped out.

But note, we set the nspmDistributionPassword and not the nspmPassword attribute.

In fact, if you watch an Identity Manager driver try to synchronize a password from the Identity Vault (eDirectory) to any connected system, usually it sends a <modify> event for the attribute nspmDistributionPassword.

Here too the Command Transformation rules look at the Global Configuration Variables that are related to password synchronization (They are called the Password Synchronization setting option when you right click on a driver link line in Designer, and available on the Server Variables tab in iManager once you have clicked on a Driver icon in the Identity Manager Overview view). and follows the appropriate choices.

Usually this event gets converted to a <modify-password> which is a special case the driver shim is coded to handle.

You can read all the gory details in my two articles on how this actually happens in the Publisher and Subscriber channel's Command Transformation Policy set rules, here:

• Password Transformation Rule Sets

• Password Transformation Rules in the Publisher Channel

But note again, we read the nspmDistributionPassword and not the nspmPassword attribute.

Why is that?

Well I do not entirely know the exact reasoning or thinking and it always bugged me, primarily since it does not seem like it helps or matters if we read or write to nspmDistributionPassword vs the nspmPassword attribute, the password is made available and thus is potentially exposed.

Well turns out there is at least one use case where this double password model actually is quite handy. Now I cannot imagine it was designed this way just to support this case, but so far this is the only major use case for it I have seen.

This is called the Password Tunneling mode for Identity Manager. You can read about it in the docs here: Identity Manager 4.0.1 Password Management Guide

This is a pretty cool model. It allows you to basically have a hub and spoke system, of an Identity Vault at the center as the hub, and have the spoke be connected systems. The spokes can change passwords and synchronize them to other spokes but not affect the password in the Identity Vault.

That means in the Identity Vault the user object has a password that is not changed, when a connected system password is changed, yet that change event flows into the Identity Vault, and then syncs to all the other connected systems.

Its a little bit strange, and I thought so too, until we actually used it at a client and it worked pretty well.

This approach relies on the fact that Identity Manager does NOT sync the Universal Password directly, rather it synchronizes the Distribution Password. Well those are two separate attributes and thus in the Identity Vault the Distribution Password is what is changed, and synced in and out of the various connected systems, leaving the Universal Password all alone.

This seems contrary to what I had been saying earlier for a normal password synchronization model, where you want the real password to change on a password change event.

The key difference here is basically in the Password Policy definition. There is a setting there that I always wondered, why is this even an option? Of course I want it set all the time. That is, Synchronize Distribution Password to Universal Password. just like you can tell the Password Policy to keep the NDS and Simple password in sync, you can tell it to keep the Distribution and Universal Passwords in Sync.

In fact setting this model up is as simple as using a Password Policy where the Distribution Password is not synchronized to the Universal Password and then having all your Identity Manager drivers use the Distribution Password on the Publisher channel.

The consequence of this is that when a password change originates in a connected system, the driver shim will pick it up and forward an event into the Publisher shim and send it to the engine to be processed. It will come in as a <modify-password> event, and the Publisher Command Transformation policies will morph that into a <modify> for the attribute nspmDistributionPassword.

When the nspmDistributionPassword is modified in the Identity Vault, then the password policy will do nothing (normally it would then synchronize the Distribution Password to the Universal Password) and the user in the Identity Vault will have two passwords, that are not synchronized. Their unchanged (by this event) Universal Password and the Distribution Password just set by this event.

Now other drivers will detect the modify event of the nspmDistributionPassword and generate event documents based upon their filters (remember that nspmDistributionPassword needs to be in the filter as Subscriber Notify only, which seems odd, but as you can see since it is converted to a different event by the policies, we can just let the filter strip it out) and do what they are configured to do with it. If they are set to send it on to the connected system then it will update the password there.

Thus you can have a change is System A, pass through (or tunnel) the Identity Vault to System B, but not affect the password in the Identity Vault.

This is a pretty interesting approach as you can imagine. What is frustrating is that there are no good tools to see the lack of synchrony between Universal and Distribution Passwords. The password recovered by the Jim Willeke's tool he has confirmed to me is actually the Universal Password, and he is not yet able to get the Distribution Password nor to compare it to the Universal Password. I think that is the last step in terms of being able to make this a truly workable solution.

We implemented this for a case where we had an Identity Vault with a User Application that we wanted the IT guys to log in to retrieve a certificate, but never be able to actually log in to the application. This way we could give them the password to the Identity Vault but the actual Authentication tree had a different password.

It actually worked better than I expected, so I was pleasantly surprised. Most amusingly, it has been lurking there in the docs for quite some time and I had never noticed it before.