Introduction

The purpose of this document is not to repeat the Universal Password documentation, but rather to point out some interesting details or some issues you might miss by just reading the documentation. Especially the tree design issues in big environments with slow WAN links are not understood to their full extend by many people. For instance, the security container caching introduced by eDirectory 8.8.x is not the solution for all tree walking issues, but more about that later. This document concentrates most on Universal Password and the Novell Client for Windows as that is the most complex scenario. The information of this document is partly based on information from various Novell sources, but also from information I found out myself. I cannot guarantee that the information is 100% correct, but I know from my reasearch on Universal Password that the Novell knoweldgebase isn't always correct either. In some cases (like the description of NMAS), I simplified things to only point out what is important for Universal Password.

Universal Password and NMAS

What is NMAS?

General architecture

NMAS (Novell Modular Authentication Services) is an architecture introduced by Novell a number of years ago in order to support alternate ways of authenticating to eDirectory. This includes, for example, support for certificates, smart cards, token cards or biometric devices as means of authentication. NMAS used to be a product sold separately but starting with NetWare 6.0, a limited version of NMAS was included with NetWare. Starting with eDirectory 8.7.x, almost the full NMAS is included with eDirectory (but the NMAS based RADIUS is not included).

NMAS typically has a server component and a client component. The server component interfaces directly with eDirectory and possibly also with third party software in cases where third party hardware devices are used for authentication. The client part resides on the workstation interfacing on one side with the application that receives the user authentication (for example the Novell client) and on the other hand establishes an encrypted connection to the NMAS server to pass on the credentials to the server so that the server can verify them.

Login methods

The different types of authentication are handled through so-called login methods. Each login method is defined once per eDirectory tree and the definition is stored in the security container. Users and other objects can be assigned various login methods and these then define how that user can authenticate to eDirectory. The simplest login method is the one called "NDS password". This login method just sends the password as the user typed it to the NMAS server using an encrypted channel. The NMAS server then does the password verification and if the password is OK, it accepts the user login. Note that the password verification on the server side is not necessarily done with the NDS password. Other passwords that exist for the user could be used as well. Therefore, the "NDS password" login method could better have been simply called "Password".
This behaviour is slightly different from an NDS login without NMAS. In fact, without NMAS, the password is hashed by the client before being sent to the server. So the server does not know what password the client used. It can only verify if it was the correct one. This distinction is very important when it comes to Universal Password.

How does Universal Password relate to NMAS?

While most people know that Universal Password relies on NMAS, a lot of people have wrong ideas as to how this happens. The most common misconception is that Universal Password is just another NMAS login method. There are even Novell TIDs that get this wrong. In reality, Universal Password is handled by the NMAS server itself and can be used in conjunction with different NMAS login methods that are password based. In the particular case of the Novell client, it is actually the "NDS password" login method that is used (as I already mentioned earlier).

Working with Universal Password

Password policies

When Universal Password is used, the actual password rules are defined in a password policy. I will not elaborate on the rules you can define in a password policy as these are well described in the documentation. The important thing to know about password policies is that they are NDS objects and they are stored by default in the security container. In older versions of the password management plugins, that was the only place were you could create them. However as Novell realized that this could cause performance problems in big WAN environments, they lifted this restriction, and the latest password management plugins when IDM 3.5 was released.

A typical client login

To understand possible login slowness and NDS design issues associated with Universal Password, letÃ¢â‚¬â„¢s see what happens during the login of a Novell Client 4.91 SP3 during a login. We assume that the NMAS client is enabled, that a password policy is defined and that the "forgotten password" feature is enabled at the client. Here is a typical sequence of events:

The user enters userid and password and clicks on OK

The NMAS client tries to find a server with NMAS installed in the replica ring of the partition holding the user object. Because of this, it is important that where possible, all servers should have an up to date version of NMAS installed.

(In case no NMAS server is found, the client falls back to a normal NDS login)

After an NMAS server is found, the client does the initial negotiation with the NMAS server. This means exchanging keys for the encrypted connection and determining the login method to be used (NDS password in this case). For the "NDS password" login method, the NMAS server actually caches this method in memory and so avoids unnecessary access to the security container.

Now the NMAS client sends the user's login credentials to the server. The server determines the password policy to be used for this user and reads the password policy to determine if the rules are verified. This means that the server potentially does tree walking to the security container if it does not have a local copy. In the case of eDirectory 8.8.x, eDirectory actually caches the security container locally and the NMAS server can take advantage of this caching to avoid unnecessary tree walking.

Assuming correct credentials, the server will give its OK to the client and the client is authenticated.

Now the "forgotten password" module of the client kicks in. If the forgotten password module is enabled, the client never knows if there are still questions that remain to be answered. So the forgotten password module, using normal NDS access, will try to locate the policy associated with the user, then goes to read the policy object and checks the forgotten password questions of the policy to see if there are any left for the user to answer. This tree walking done by the Novell client can be a login performance killer in WAN environments. In fact, because it is the client here that does the NDS access to the security container, it will not take advantage of the eDirectory 8.8.x security container caching. The client will still need direct access to a server holding a replica of the security container. The only way to avoid this is to move the password policy object to a container that is in the same NDS partition as the user.

Issues and tips

NDS design considerations

The previous example of a typical login brings up some interesting NDS design considerations when using Universal Password:

The login method is not really an issue if you only use the default "NDS login" method. As the NMAS server caches the "NDS login" method in memory, it will only do the security container access once in a while and not for every login.

The login policy needs to be read by the NMAS server upon user login. On eDirectory 8.7.3.x, there is no caching for this. So, to avoid slow logins due to the NMAS server checking, ensure that every site has a local replica of the security container, or alternatively move the password policy object to a local container. On eDirectory 8.8.x, the security container is cached and the NMAS server takes advantage of this. So there should be no slow WAN connection related issue.

The "forgotten password" feature of the client causes the client to directly access the password policy object. The client cannot take advantage of eDirectory 8.8.x security container caching. This means that you should always disable the "forgotten password" feature of the client if you are not using it. Disabling it in the clientÃ¢â‚¬â„¢s advanced login properties is enough provided you have a 4.91SP2 client with PKC installed or a later client. If you want to use the forgotten password feature, make sure you either have a local replica of the security container or move your password policy object to a local container. This recommendation is independent of whether you use eDirectory 8.7.3 x or 8.8.x.

With the Security Services 2.04 update and the Identity Management 3.5 plugins, it is now possible to place the password policy and related objects in containers other than the security container and the tree design issues become less important.

Software recommendations

Novell first introduced Universal Password with NetWare 6.5. However, a lot of functionality has since been added, bugs have been fixed and odd behaviour has been improved. Therefore, you *really* want to implement Universal Password with up-to-date software. Here is a list of the recommended software to use:

Server:

NetWare 6.5 SP5 or later or OES SP2 or later or OES2 (NetWare or Linux) or any other platform supporting eDirectory 8.7.3 or later.

Security Services 2.0.5 update which includes NMAS 3.2.0. Unfortunately, the Security Services 2.0.5 installation script omits updating the schema. You should follow the schema update instructions from TID3701028. Note most of Security Services 2.0.5 is already included in NetWare 6.5 SP7, eDirectory 8.8SP2 or OES2 except for 2 additional bugfixes included only in ss205.

Client:

Novell client 4.91 SP4 with the NMAS client installed. The feature for fully disabling the "forgotten password" feature was only introduced in the file loginw32.dll dated 5 June 2006.

DonÃ¢â‚¬â„¢t forget to disable the "forgotten password" feature if you donÃ¢â‚¬â„¢t use it!

Novell client for Windows Vista with the NMAS client installed.

Management:

iManager 2.5 or later (iManager 2.7.2 is the currently-supported version)

Use Virtual Office 1.6 or later or if you have IDM, use the IDM User Application (UserApp). DonÃ¢â‚¬â„¢t use the obsolete password self-service application for iManager 2.0.2.

What to do about NetWare 5.1 and 6.0 servers in your tree

Officially, Universal password requires NetWare 6.5 or OES. However if you still have NetWare 5.1 or 6.0 servers in your tree and you want to enable universal password anyway, you can minimize the number of issues due to outdated versions NMAS and related products by installing the following updates to your 5.1 / 6.0 servers:

This contains eDirectory 8.7.3.7, but more importantly, it also contains secupd9, the last "security update" that could be installed on NetWare 5.1/6.0. This gives you the latest 5.1/6.0 compatible versions of the Certificate server (2.7.8), NTLS (1.8.4) and NMAS (2.3.9.0).
This patch is no longer available on Novell's web site, but you can find alternate download locations through Google:
http://www.google.com/search?q=edir8737.exe
Note that this patch file actually contains 3 separate install directories for NetWare. One for the Edirectory patch, one for PKI and NTLS and one for NMAS.

possibly the edir8739.exe patch

This patch is not officially supported on NetWare 5.1/6.0 but has been reported to work fine. It has also been pulled from Novell's web site but can still be found through Google. Note that even if you use use this version, you still need the edir8737.exe update for the additional PKI, NTLS and NMAS updates that are not included in edir8739.exe. Also note that the eDirectory 8.7.3.10(a/b) updates are not installable on NetWare 5.1 or 6.0 servers.
http://www.google.com/search?q=edir8739.exe

Important note:

Just like with eDirectory, Novell created a bit of a version mess with NMAS.NLM. The version number of the module NMAS.NLM does in fact not correspond to the version number of NMAS as a product. In newer versions (I think starting with 2.3.5), the NLM version number is actually a big number so that confusion is not possible. However for older versions, there is a huge potential of confusion because the NLM version of NMAS.NLM is higher than the product version. For instance NMAS.NLM version 2.65 is actually a very outdated version corresponding to NMAS product version 2.30. A complete list of NMAS versions can be found at http://www.novell.com/support/viewContent.do?externalId=3358020

Documentation issues

Unfortunately, Novell has so many different documentation versions for some components that people are often tricked into using old documentation which no longer corresponds to the functionality offered by the current versions or current support packs. Here are a number of components where it is important to use the correct documentation in order to see all the functionality and not use obsolete ways of doing things:

Case sensitive and case insensitive passwords

NDS passwords are case insensitive and have always been so. Universal passwords are case sensitive by default but in the password policy, you can specify that the password should be case insensitive. You should however be aware of the cases where the password case (in)sensitiveness does not work as expected. Here are the most common cases of unexpected behaviour:

NDS logins remain case insensitive

Even with Universal Password enabled, applications that just use NDS authentication will continue to follow the limitations imposed by NDS password, and most noticeably, the password will still be case insensitive. The most common cases where you will see this are:

Login using an older Novell client (before 4.90) or a Novell client installed without NMAS support or with NMAS login disabled.

Passwords can only be case insensitive for login methods that do not hash the password

When you set your password policy to allow the passwords to be case insensitive, you should be aware that not all environments with honour the case insensitiveness of your passwords. This happens in cases where the password is hashed by the client application and the server never sees the real password but can only apply the same hash algorithm to the universal password stored in eDirectory. You will see this behaviour for instance with CIFS as well as with AFP when not using the CLEARTEXT option. This issue is discussed in TID3662858: 'Can the AFP password be made case insensitive?'.

An exception to this rule is the NDS password where the client already transforms the password to uppercase before applying the hash. In this case, it is the client tat actually makes the password case insensitive.

Things you may not know

The following items may be documented, but nevertheless a number of people don't know them,

If in your password policy you select the option to remove the NDS password, the NDS password will not actually be removed, but will be replaced by a randomly generated password. The NDS password is in fact not stored as an attribute, but it is used to generate the public/private key pair for the object. Any object that wants to log in needs a key pair.

Password restrictions and expiration times for Universal Password are stored separately from NDS restrictions. With earlier versions of NMAS, this created confusion because when using tools like NWADMN32 or ConsoleOne to view a user's restrictions or expiration times, those were different from the restrictions or expiration times actually applied. In NMAS 3.1 or later, NMAS now automatically updates the NDS restrictions to match the Universal Password restrictions at login time. This synchronization avoids a lot of confusion for administrators. For this reason alone, it is worthwhile upgrading to upgrade to NMAS 3.1 or later.

If no password policy is found at user, container or partition level, a tree wide default policy is used. That policy is defined by the "Login Policy" object in the security container.