Universal Password

From MicroFocusInternationalWiki
Revision as of 16:23, 26 January 2007 by Marcuswilliamson (Talk | contribs) (Login methods)

Jump to: navigation, search


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 actually a new feature on the NMAS server side that determines how the NMAS server has to handle passwords on the backend. This is not linked to a particular login method but rather influences all login methods that use a password based authentication. 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 this is 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. However there is no need for them to be in the security container. They work in any container. Their location in the security container is just hard-coded in the current password management plugins for iManager. Novell thought they are doing customers a favour that way by avoiding multiple policies in many places. In practise however, this is a very bad limitation for people with huge networks and many WAN links. The good news however is that this will probably change soon enough. Identity Manager 3.5 which currently in beta testing is supposed to include password management plugins that allow you to control where you place your password policies.

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 what 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 doesn’t have a local copy. In case of eDirectory 8.8.x, eDirectory actually caches the security container locally and the NMAS server can take advantage if 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 reply to. 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 different container local to the user.

Issues and tips

NDS design considerations

Based on the previous example of typical login, this leads to some interesting NDS design considerations when using Universal Password:

  • The login method is not really an issue if you stick with the default "NDS login" method. As 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 alternately 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 directory 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 lter client. If you want to use the forgotten password feature, make sure you either have a local replica of the security container, or you move your password policy object to a local container. This recommendation is independent on whether you use eDirectory 8.7.3 x or 8.8.x.
  • Once Identity Management 3.5 gets released, tree design issues will be less important as it is planned that IDM 3.5 will allow you to contral were to place password policy objects in your tree.

Software recommendations

Novell first introduced Universal Password with NetWare 6.5. However a lot of functionality has 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 recommended software to use:


  • OES SP2 or later (NetWare or Linux) or any other platform supporting eDirectory 8.7.3 or later.
  • eDirectory or eDirectory 8.8.1
  • NMAS 3.1.2 and associated components (this is included in NW65SP6, or in the Security Services 2.0.3 update for all other platforms)


  • Novell client 4.91 SP2 plus PKC patch or later with the NMAS client installed. The feature to be able to fully turn off 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!


  • iManager 2.5 or 2.6
  • Identity Management 2.1 or 3.0 plug-ins. Only the identity management plug-ins contain up to date password management functionality. The old "Password Management 2.02" plug-in should no longer be used.

Password self service web application

  • Use Virtual Office 1.6 or later or if you have IDM, use the IDM user application. Don’t use the obsolete password self service application for iManager 2.0.2

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 don’t use obsolete ways of doing things:

NetWare 6.5: If you have NetWare 6.5 SP3 or later, you should no longer use the NetWare 6.5 documentation, but you have to use the Open Enterprise Server documentation found here: http://www.novell.com/documentation/oes/index.html

NMAS: Use the NMAS 3.1.1 documentation found here: http://www.novell.com/documentation/nmas311/index.html

Universal Password: Use the Password Management 3.1 documentation found here: http://www.novell.com/documentation/password_management31/index.html

Useful links