Examples of Dump UP tool:

Novell has supported a number of different password types over the years. The original is still one of the nicer passwords, the RSA Key pair. What you see in eDirectory as Public Key, and cannot see (unless Novell Technical Services uses DSDump on your server) Private Key.

Alas, like all good things, nothing is perfect, and as time went on, Novell realized they needed to fix some of the issues with the traditional NDS (I like to call it RSA password personally) in order to allow for other interesting things to be supported.

First off, the RSA key pair is non reversible. This is of course by design. Additionally it is not case sensitive, and if I remember this correctly, effectively stores the entire password as upper case.

Aside from the lack of case sensitivity, non-reversible passwords are traditionally good things, wouldn't you say? Well from a pure security perspective, you betcha. That means access to the raw data is not as useful as you have to attempt to brute force the passwords. (That may not be much protection in these days were a 1U server (1.8 inches thick) can house 4 CPU sockets, with each CPU having 4 or more cores on them, all running at 3Ghz. Then in a full size rack you can have some craziness like 42 of these boxes... That is an astonishing amount of computing power (4 sockets * 4 cores per socket * 42 rack mount servers = 672 CPU's running at 3Ghz or so. Imagine how much space that would have taken up a decade ago! Wow! Sometimes you just have to stand back and say "Wow!". Then of course you say, "I'll take two of those please!").

With the release of NetWare 5 and the addition of the Native File Access Pack supporting CIFS (Common Internet File System, aka SMB (Server Message Block) protocol file access, like Samba on Linux) and AFP over TCP (Appleshare File Protocol file access for Macintosh computers) they had a problem they had to resolve.

Mac's use what is known as two way random number hashing on logins (by default, you can set it to use other things if needed), and that requires the clear text string of the password to be known by the client (Well you just typed it in, no big deal) and by the server (Oops! We may have a problem here!). Lets see if I can describe this one. The client encrypts a random number with the password you just typed it. The server receives it, decrypts it with the password it already knows, and then encrypts its random number it just generated (thus the two way random number part!) with the random number it figured out from what the client sent it. Then magic happens. Anyway, this proves both the server and client have the same password in mind.

Windows file sharing (CIFS, SMB, samba, whatever you want to call it) can use a couple of login methods now, but back in the original release it was pretty much LANMAN authentication, which took the password typed by the user, hashed it with MD5 (or is it MD4, whatever, it does not really matter) and sends that on to the server, which stores the hashed version, compares and good to go.

If you looked at the old NDS for NT product, you would see that the hashed password would get stored in attributes in eDirectory (then called NDS still to put the dates in perspective) called IWS:Extended Security with an A, B, C, or D at the end. (I never was sure why there were four attributes needed.)

Samba for Linux, basically still has this same issue, and you either store the hashed version of the password in a smbpasswd file, or in LDAP in attributes, or you use Open Enterprise Server from Novell which has a plugin to use the Universal password! Yay!

Then there is NFS which sometimes uses MD4 (or is it MD5, whatever, it is the other one from LANMAN). Yet another password potentially needing to be stored.

Well this kind of stinks if you like the notion of having one password and changing it but a single time.

Novell's solution at the time was to use Simple Password. This was a reversible version of your password, and they introduced a whole slew of bits and pieces needed to make this all work.

Simple Password did not last long, as it too had limitations, and work was underway to get to a better solution.

Thus we came to Universal Password. Universal Password (UP hence forth as it is quite a mouthful to type all the time) is encrypted in eDirectory with the tree's SDI (Security Domain Infrastructure) key. SDI is very similar to PKI, except it has one major feature, which is old keys can remain around, but revoked. If you ever have to update the SDI key in the tree, you always revoke the old one, and generate a new one. This is critical, as if you just got rid of the old, and made a new one, all your currently encrypted secrets would be lost, as you need the old key to read them. Thus the concept of revocation. The old key hangs around, and any time a secret is accessed, the new key is tried, if that fails, it works through the revoked keys until it finds one that will work, or else fails. Then if it finds a revoked key encrypted secret, it decrypts it with the revoked key, and re-encrypts it with the current SDI key, making it more up to date.

Thus the passwords are secure, but stored in a reversible fashion, when you have sufficient permissions, and the password policy allows it. Which it does not by default. You need to enable a password policy, that specifically enables Admin to retrieve passwords, and in the later versions of NMAS (Novell Modular Authentication Services, one of those bits and pieces that began to be introduced around the NetWare 5.x time frame to support NFAP and many other neat ideas) you can specify WHICH admins specifically.

With a reversible password, all sorts of interesting possibilities become available. With just that one password, CIFS, AFP, and NFS logins are a piece of cake. For CIFS, just hash the password stored, compare, good to go. Same for NFS. For AFP, a little more complex, but straight forward.

Novell Identity Manager heavily leverages this password, so that you can synchronize it between different systems, and a change anywhere that gets sent back to eDirectory can then be forwarded on at will to any of the connected systems.

Password policies and all their inherent goodness came along with this technology at around the same time. Things like requiring interestingly complex passwords to secure them, but also control over which passwords are stored (Simple, NS or UP).

The downside is that now we have three possible passwords stored for a user in three different ways, and we need to be able to troubleshoot them.

So what tools do we have? Well, you can use tools you know use different code paths. For example try a CIFS login to test UP. Try a Client32 bind with NMAS to test UP as well, then try on a client with NMAS installed. But these are not really definitive tests.

Novell has a tool called DiagPWD to try and help:
Universal Password Diagnostic Utility, Version 4

There is a nice wrapper to try and parse the results to report users with issues:
pwdcheck

But I really like the tool Jim Willeke wrote:
DumpEdirectoryPasswordInformationTool

I call it DumpUP since it is easier to type. This is a truly awesome tool, and I use it all the time.

There are some complexities to getting it going, like getting Java keystore set up, and getting the syntax correct. But once you are past those hurdles, it works very well.

I wanted to try and show some examples of what the output should look like in various cases, and explain some of the errors you might get, when using it.

First off, most error messages should be NMAS or eDirectory related. eDirectory you should know the error codes for already, so here is a link to a nice document from the Novell Knowledge Base on NMAS error codes. NMAS error codes

A side tip, if you are searching for error codes, you need to include the minus sign. Thus searching the Knowledge Base at http://support.novell.com on say "nmas error 1659" does not return much. But try "nmas error -1659" and you start getting results. This is just an annoyance really, once you understand it.

On with the examples:

First we have a non-error error case:

java -jar DumpPasswordInformation.jar -h 10.1.1.10 -Z SSL -p 636 -D cn=admin,ou=users,o=acme  -e MyKeyStore -w password -b "cn=jsmith,ou=users,o=acme"
# dn: cn=jsmith,ou=users,o=acme
# cn=jsmith,ou=users,o=acme-com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-1659)  - NMAS_E_ACCESS_NOT_ALLOWED - Indicates that the user does not have sufficient rights to perform the requested operation.
   Password: null
   Password Policy for Entry: cn=All Users Policy,cn=Password Policies,cn=Security
   Does Current password meet password policy assigned to user? true
   ===> Password Status <===
   ==> Universal Password <==
        Is UPwd Enabled:  true
        Is the UPwd history full:  false
        Does UPwd match NDSPwd:  true
        Does UPwd match SimplePwd:  true
        Is UPwd older than NDSPwd:  false
   ==> Simple Password <==
        Is Simple Password Set:  true
        Is Simple Password Clear Text:  true
        Does Simple Password match NDSPwd:  true
		
		

The error 1659 means what it says NMAS_E_ACCESS_NOT_ALLOWED, in other words password policy (The All User Policy.Password Polices.Security object that it reports) does not allow the user (admin.users.acme) to retrieve this password. But the tool is still able to verify if the UP matches the Simple or matches the NDS passwords. This is useful information. Knowing whether the UP is older than the NDS password is good to know as well, as that will tell you if someone changed their NDS password only, usually via Client32 without NMAS installed, or else using a Console1 build that has the file nmas.dll in the bin directory. (This overrides the clients NMAS client, and does not set UP correctly!! See TID3576410 at ConsoleOne - Universal Passwords not updating for exact instructions on fixing that one! Very common in the field and astonishingly annoying!)

Thus this was actually a successful run, with a correct and desired error message. I.e. Password policy is working and being enforced!

Lets try that again with a Password policy, which I called UPDiagnostic to allow this troubleshooting so that we do have rights to retreive the password itself.

java -jar DumpPasswordInformation.jar -h 10.1.1.10 -Z SSL -p 636 -D cn=admin,ou=users,o=acme  -e MyKeyStore -w password -b "cn=jsmith,ou=users,o=acme"
# dn: cn=jsmith,ou=users,o=acme
   Password: abcd1234
   Password Policy for Entry: cn=UPDiagnostic,cn=Password Policies,cn=Security
   Does Current password meet password policy assigned to user? true
   ===> Password Status <===
   ==> Universal Password <==
        Is UPwd Enabled:  true
        Is the UPwd history full:  false
        Does UPwd match NDSPwd:  true
        Does UPwd match SimplePwd:  true
        Is UPwd older than NDSPwd:  false
   ==> Simple Password <==
        Is Simple Password Set:  true
        Is Simple Password Clear Text:  true
        Does Simple Password match NDSPwd:  true
		
		

Great! We see that the user is in good shape password wise, with a kind of silly and weak password of abcd1234

Bad SDI keys (moved tree to tree poorly).

java -jar DumpPasswordInformation.jar -h 10.1.1.10 -Z SSL -p 636 -D cn=admin,ou=users,o=acme  -e MyKeyStore -w password -b "ou=users,o=acme" -A
# dn: cn=webadmin,ou=Users,o=acme
# cn=webadmin,ou=Users,o=acme-com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-1658)
   Password: null
   Password Policy for Entry: cn=All Users Policy,cn=Password Policies,cn=Security
Error: com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-1665)
Error: com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-1658)
   ===> Password Status <===
   ==> Universal Password <==
Unable to get status!java.lang.NullPointerException

This is a great example where you have SERIOUS issues in your tree. You NEVER ever want to be in this circumstance in real life!! In this case, I had backed up a tree from production, using Dsrepair's archive function, and restored it with the -$DU switch (Read more about this potentially astonishingly dangerous operation, if you make a mistake at: Restoring eDirectory with Dsrepair -rc and Dsrepair -$du and as Elmer Fudd says, Be werry werry caarful!! This can be VERY dangerous when used incorrectly!).

In my case, because I did not have the right NICI keys to restore this tree, I could not decode the SDI keys, which meant all passwords were lost. I was trying to copy a production environment into an isolated lab environment for testing so this was ok.

601 error, no such user:

java -jar DumpPasswordInformation.jar  -h 10.1.1.10 -Z SSL -p 636 -D cn=admin,ou=users,o=acme  -e MyKeyStore -w password -b "cn=tuser2,ou=users,o=acme"
# dn: cn=tuser2,ou=users,o=acme
# cn=tuser2,ou=users,o=acme-com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-601)
   Password: null
Error: com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-601)
Error: com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-601)
Error: com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-601)
   ===> Password Status <===
   ==> Universal Password <==
Unable to get status!java.lang.NullPointerException

Here we have a typical eDirectory error, that probably means I made a typo. 601 in eDirectory is object not found, and we are thus being told by the tool that the user tuser2.users.acme that we want to examine the password status for, does not exist in this tree. Easy enough to fix, get the object name correct. (Note it is in LDAP syntax, I just like typing in eDir syntax better!)

No UP set on user:

java -jar DumpPasswordInformation.jar -h 10.1.1.90 -Z SSL -p 636 -D cn=admin,ou=admins,o=acme  -e MyKeyStore -w password -b "cn=tuser2,ou=users,o=acme"
# dn: cn=tuser2,ou=users,o=acme
# cn=tuser2,ou=users,o=acme-com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-16049)  - NMAS_E_ENTRY_ATTRIBUTE_NOT_FOUND
# Entry has no Universal Password value
   Password: null
   Password Policy for Entry: cn=All Users Policy,cn=Password Policies,cn=Security
Error: com.novell.security.nmas.mgmt.NMASPwdExceptionNMAS Return Code (-16049)
   ===> Password Status <===
   ==> Universal Password <==
        Is UPwd Enabled:  true
        Is the UPwd history full:  false
        Does UPwd match NDSPwd:  false
        Does UPwd match SimplePwd:  false
        Is UPwd older than NDSPwd:  false
   ==> Simple Password <==
        Is Simple Password Set:  false
        Is Simple Password Clear Text:  false
        Does Simple Password match NDSPwd:  false
		
		

This is what a user without a UP set would look like. You get a 16049 error, which means no password was read. Often this is a chained error, perhaps there was a problem decoding it first, and then after all the other errors, you get a 16049 which is summing up the end result, which is no password to login with. Sometimes it means that literally, as in this case, where I was testing a problem I suspected was Simple password related.

What is nice is that you can see the tool even notes this case, with a message of:

# Entry has no Universal Password value

Universal Password does not match the Simple nor NDS, but Simple Password and NDS do match:

java -jar DumpPasswordInformation.jar -h 10.1.1.91 -Z SSL -p 636 -D cn=admin,ou=admins,o=acme  -e MyKeyStore -w password -b "cn=tuser,ou=Migrated,dc=acme,dc=corp"
# dn: cn=tuser,ou=Migrated,dc=acme,dc=corp
   Password: acme123
   Password Policy for Entry: cn=NoSimple,cn=Password Policies,cn=Security
   Does Current password meet password policy assigned to user? true
   ===> Password Status <===
   ==> Universal Password <==
        Is UPwd Enabled:  true
        Is the UPwd history full:  false
        Does UPwd match NDSPwd:  false
        Does UPwd match SimplePwd:  false
        Is UPwd older than NDSPwd:  false
   ==> Simple Password <==
        Is Simple Password Set:  true
        Is Simple Password Clear Text:  true
        Does Simple Password match NDSPwd:  true
		
		

In my troubleshooting that Simple Password issue I referred to above, I wanted to see if maybe I had two different known values, it would use one but not the other, so I had acme123 set for UP, but has changed Simple to acme1234,and as you can see, Simple and NDS do however match.

I suppose I could have contrived a case where I had a UP password, a different Simple Password, and a different NDS password. But that probably would have taken more work than I was willing to work through, and for troubleshooting this issue, I did not think it would matter.

User with no Simple Password at all:

java -jar DumpPasswordInformation.jar -h 10.1.1.91 -Z SSL -p 636 -D cn=admin,ou=admins,o=acme  -e MyKeyStore -w password -b "cn=tuser2,ou=Migrated,dc=acme,dc=corp"
# dn: cn=tuser2,ou=Migrated,dc=acme,dc=corp
   Password: acme1234
   Password Policy for Entry: cn=NoSimple,cn=Password Policies,cn=Security
   Does Current password meet password policy assigned to user? true
   ===> Password Status <===
   ==> Universal Password <==
        Is UPwd Enabled:  true
        Is the UPwd history full:  false
        Does UPwd match NDSPwd:  false
        Does UPwd match SimplePwd:  false
        Is UPwd older than NDSPwd:  false
   ==> Simple Password <==
        Is Simple Password Set:  false
        Is Simple Password Clear Text:  false
        Does Simple Password match NDSPwd:  false
		
		

In this case I was trying to make a user with a Universal Password, but no Simple Password, nor any NDS password.

I hope showing these examples of how the output of Jim Willeke's excellent tool varies depending on circumstances will help you, if you are trying to figure out what is going on with passwords in your tree!

You can really see how the power of this tool shines, and this is only scratching the surface of its abilities.

Some things to consider are setting up a script that checks the status of the user in say three tree being synchronized via Novell Identity Manager? You would quickly be able to see what the passwords are set to in all three trees. which very quickly answers whether password synchronization is working, and if not, between which points.

The tool can output the found passwords in proper format to an LDIF file, which can then be applied back. (Which is how I fixed the lab tree where the SDI keys got lost. I exported via LDIF all the passwords from production, then imported into the lab, then I burned the file!).