I noticed this the other day, that the engine on a query of an object,
for the Read Attribute of * returns all attributes. Interestingly
enough that driver returned nspmPassword, which is the actual Universal
Password. It also returned the nsmpDistributionPassword (the
Distribution Password) and the Private Key attribute (RSA key pair

Does that mean we could use UP directly instead of the DP in policy? It
does look like it. Which is quite interesting.

I always assumed we could not read it back, but it looks like we can.
Anyone ever relied on this? Any comments or thoughts?

I have an article not yet made public (They only release one article a
week, and I have a backlog of 15 or so articles) on the topic of
Password Tunneling mode, which is pretty much the only reason I have
ever seen for the existence of DP on top of UP:


Since it will be a month or three since that is published, here is the
body of the article in advance:

Password Tunneling Model in Identity Manager:

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:

You can read the authors introduction to the tool here:

I wrote up some common usage examples here:

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

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

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

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

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:

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:


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

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.