Take the 2-minute tour ×

I'm looking for some clarification on how I should go about making a "universal" password on Novell. In consoleone under my eDirectory tree, I click properties, and under Login Methods there are several passwords: NDS, Enhanced and Simple. There are also passwords under Unix, Groupwise and Restrictions.

Restrictions Page

Out of force of habit, we've been changing our passwords under Restrictions but we don't know what password this actually is changing. People can use that password to log into Netware/eDirectory and their Groupwise email accounts.

Recently we discovered that changing the Simple Password allows both, the Simple Password and the password changed under Restrictions to work. If we select all users and change the Simple Password, we can essentially create an administrator password for ourselves. Is this the best path for this?

share|improve this question
By universal what do you mean? Do you want to create a password that allows you to login as any user? –  Josh Budde Oct 1 '09 at 18:20
Yes essentially, this allows us to work on locked workstations without logging users off and other such things. –  Xphacter Oct 1 '09 at 21:11
add comment

3 Answers

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!

share|improve this answer
Thanks geoffc, but what if a company doesn't have iManager? Would it be okay to use Simple Password for the Administrator? Seems less secure. –  Xphacter Oct 2 '09 at 18:04
@Xphacter: If you do not enable UP, and set a password, then you are just setting the NDS password (aka RSA Key pairs). Which will work for authenticating against eDirectory for NCP applications. To make a CIFS/AFP connection to an OES server, will require you to have a UP to use them. Also, iManager is a mangement tool, and there is a standalone version, called either iManager mobile or iManager Workstation, and you unzip and run, and you can log in to the eDirectory tree, (any tree you can get at over IP) and look at Password polices, in the Password section. –  geoffc Oct 2 '09 at 19:53
add comment

Universal password is setup through iManager. If you dont have it installed, go to novell website and download the latest version and install. Once you login to iManager, you will need to go to Passwords, then Password Policies. Create a new password policy and assign it to a user or container.

On the next password change, the user should now have the new password policy associated. You will see in console one, in the restricted tab your settings. (Might be a good thing to set the new policy to have a slightly different setting for testing).

I believe you need to have NMAS installed as part of novell client in order to password resets to work properly through ConsoleOne.

share|improve this answer
add comment

If your site does not have UP enabled yet (i.e. you have a longstanding Novell installation), then you will want to make sure that your environment is clean--relatively newer versions of eDir-- or 8.8.5, server certificates are good and not expired, server OS is patched, DNS and SLP are configured correctly and every server has a DNS address, eDirectory tree is healthy, etc. etc--before you turn it on. You will want to give users password policies as well, and to set UP for the first time, users may have to change their passwords so that they get written to the UP store and not just the NDS password store.

You can use ConsoleOne with UP (instead of iManager) but you will need to patch it to the latest version to make it fully UP-aware.

Get patches via Novell Patchfinder: http://download.novell.com/patch/finder/

Universal Password documentation is at: http://www.novell.com/documentation/password_management33/ (I strongly suggest reading it. UP is a must for modern Novell networks, but first implementation does take some planning.)

share|improve this answer
add comment

Your Answer


