Novell started with Netware with a user database called the Bindery. The password then as now was based on RSA Private/Public key pairs.
With NDS in Netware 4.0 they kept the same basic password method, and it is reasonably secure.
With eDirectory (what NDS got renamed to, around version 8.x of eDirectory, which was around the Netware 6.x timeframe) they needed to support reversible passwords, which an RSA key pair is definitly not.
They needed this for NFS, SMB, and AFP support. Because SMB uses MD4 or MD5 hashing, NFS uses MD5 or MD4 (I can never keep those two straight and it basically doesn't matter either). Mac's use two way random number to auth, and requires a clear text password to compare against.
The first attempt was something called Simple Password, which was a good first try, but did not solve all the issues.
The second attempt is Universal Password that seems to have worked quite well. UP is stored in a hidden attribute (it is protected much the same way the Private key is protected in eDir and fairly hard to get access too).
Where your confusion has arisen, is that UP is NOT implemented via a Login Method, or the like, it is built into eDirectory as part of the basic password functionality, much as RSA Key pairs are not a login method but rather are built in.
There was an Enhanced Password login method before Simple/UP came around to try and implement some of the needed functionality but that was not the best approach either.
Anyway, to enable Universal Password, (not eenabled by default), you need to create a password policy (using iManager as TheDave1022 notes), and assign it.
There are some subtleties in how it inherits. You can assign a policy to the Login Policy object in the Security container (at the Root of the tree) and that applies to every object with a password in the tree. Nice and easy.
You can apply it to most any container object (well not Country objects as I recall, though I think I know how to work around that now. O, OU, the most common types work perfectly well) and it will apply to all the direct children.
In order for it to inherit down more than one level, the OU/O has to be an eDirectory partition boundary.
The lowest level of assignment overrides any higher assignments. So Assign strictest to the Login Policy.Security object for the entire tree, then a more sane policy for the people you like in the Friends.users.acme container to make their lives easier.
Then you have the bozo who makes your life hell in Accounting, so assign a new policy to Bozo.Accounting.people.acme and make him require 92 character password, with 6 non-ASCII characters.
Or whatever.
Once you have it enabled, any password changes done through an NMAS enabled client will set UP (and Simple, and NDS, if your policy says to sync to all those passwords. Easy options to change as needed).
An NMAS enabled client is a user with Client 32 with the NMAS (Novell Modular Authentication Services, a default part of the client install, unless you specifically chose not too), iManager, all LDAP applications that do password changes since Novell's LDAP service is NMAS enabled. CIFS/AFP clients against OES (Netware or Linux kernel) CIFS/AFP service. (OES 1 used Samba, which I think was NOT NMAS enabled, but OES2 uses a port of the Netware CIFS service, which is more scalable than Samba).
So basically the only case of a Non-NMAS enabled client is Client 32 that you specifically did not install NMAS on it.
There is one further known error case, which is an older ConsoleOne install, where there is an NMAS.DLL file in the C1 directory structure. That is a leftover and needs to be removed.
One option in the password policy is "Allow Administrator to retrieve passwords" and then specify a specific user who is allowed. Then you can use Jim Willeke's truly excellent Universal Password diagnostic tool that will show you what the password is set too (If allowed by the policy), if it matches the NDS password, and the Simple password and lots more diagnostic stuff. Hard to work without it!
Best Answer
Let's do a quick calculation (and forget best practices for a moment):
Assume a timeframe of six months for an attacker to hack your system. Let's also assume, that passwords are randomly chosen from a character set of size 62.
Scenario 1: You use a 9 character password for the entire six months.
Scenario 2: You use a 9 character password for the first three months, and a different 9 character password for the remaining three monts.
Scenario 3: You use a 10 character password for the entire six months.
In Scenario 1, a brute force attacker hacks your account with 100% certainty, if he can do 62^9 attempts in that time.
In Scenario 2, if he can do only (62^9)/2 attemps in half the time (three months), he'll hack the account with 50% certainty. In the second half, he'll get another chance with 50% certainty. So statistically, he'll hack the account with 75% certainty.
In Scenario 3, he'll have 62^9 attempts for the entire six months. But there are 62^10 possibilities. So he'll hack the account only with 1/62 certainty, that's about 1.6%.
So if we leave all other factors out (like stolen passwords and other kinds of attacks), the recommendation would be to rather choose longer passwords than using shorter (or simpler) passwords, even if they're changed more often. Especially, because in Scenario 3, there are only 10 characters to remember, while in Scenario 2, it's 18 characters.