In the course of my job as a consultant I find myself explaining what the different passwords in eDirectory are used for. This is an extract of such an explanation.
Novell has a history of different passwords, as shown below.
Figure 1 - Diagram of eDirectory password types
The NDS password consists of a Public and Private key combination. The password cannot be reversed under any circumstances, as the password itself is not actually stored in eDirectory/NDS.
NDS passwords, and even passwords as far back as Netware 3.12, have always allowed password expiry and history lists for policy based password management.
When Novell first introduced Native File Access, they did not want to allow plain text passwords to be sent and compared against the NDS password - so they introduced the Simple password. When this was first introduced it was set manually, and there was no easy way for a user to change this. The simple password does not have any policies and does not follow the NDS-based policies. Simple passwords were only used by Netware 6 CIFS and NFS services. Netware 6.5 and beyond uses Universal Password.
This is rarely seen but can be thought of as simple password with some policies added.
Universal Password was introduced to wrap up all the passwords into one place. It is reversible and can be used with IDM. It has very powerful centrally configured policy support and integration with NMAS, including the Challenge Response. Universal Password can be configured to set both the Simple Password for backwards compatibility and Distribution Password for IDM.
Universal Password requires NMAS-aware clients and servers in order to function correctly. Currently, NMAS/Universal Password-aware applications will actually try both the Universal Passwords to authenticate.
Universal Password Example
User A has not set a Universal Password and attempts to log in. NMAS checks for a Universal Password and the login fails; it then drops down to NDS password and the user logs in.
User B has set a Universal Password that is the same as the NDS password. This has been synced by the policy. The user attempts to log in with an NMAS-aware client. NMAS checks for a Universal Password, and the login succeeds.
User C has set a Universal Password that is the same as the NDS password. This has been synced by the policy. The user fisrt logs in to an old Novell client and changes the password. Then he or she attempts to log in with an NMAS-aware client, and the login fails, because the non-NMAS client has only changed the NDS password. However, the Novell Client then tries the NDS password and the login is successful. The NMAS client updates the Universal Password on a successful login.
Password Expiry with Universal Password
Password expiry works differently with Universal Password and does not use the traditional NDS Password Restriction fields. However, for backwards compatibility it does change the values when a user changes an expired password. Universal Password expiry works by comparing the current time with the number of days configured in the user?s password policy against the timestamp of the Universal Password.
Again, like password checks, most NMAS-aware services (Novell Client, LDAP) will check both the Universal Password expiry and the NDS-based fields.
If an administrator changes a Universal Password it is considered an administrative change and the password is automatically expired. If a user changes a Universal Password it is considered a normal change and the password expiry is effectively "moved on" by the number of days in the policy. This causes an issue when using IDM, because if you directly synchronise into the Universal Password it would be expired.
The Distribution password is only used with IDM. It is a reversible version of the user's password, which can be synced out to other systems.
Setting the distribution password (via IDM) automatically sets the Universal Password but is seen as a user change.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.