NMAS adds strength to your security policy by letting you incorporate an additional array of authentication methods to supplement or replace static passwords. Requiring your users to supply additional authentication materials, like smartcards or a biometric, gives you an additional layer of protection to sensitive information. It's no longer just what they know (password), but what they have (certificate, token or smartcard) and what they are (biometric) that determines whether they gain access to that corporate salary spreadsheet.

Once A Hassle, Always A Hassle

Security is a pain in the butt, and implementing a graded authentication strategy via NMAS is no exception. If you're just starting to explore this technology, we recommend that you implement a pilot project using a small, targeted population of end users and administrators. During the pilot, keep an eye on scalability. Based on our experience in our Real-World Labs® at Syracuse University, we think deploying this technology is a resource-intensive exercise.

A multitude of software must be installed to provide graded authentication for NDS. Prior to starting any software installation that extends your directory schema, it is important to ensure that your directory is fully synchronized and healthy; time is synchronized; and all servers participating in directory services are running and healthy. The time you spend now ensuring the health of your NDS infrastructure will pay for itself during the installation phase.

On the server side, NMAS requires NetWare 5.0 with SP3 or higher, Novell Certificate Server, and eDirectory 8 or Windows NT/2000 with eDirectory 8.5 and NICI (Novell International Cryptography Infrastructure) 1.5 or higher. The prerequisites of each authentication device must be addressed as well, especially as they relate to integration with ConsoleOne, the NMAS administration interface. Each device vendor provides ConsoleOne snap-ins to manage the characteristics of its device.

Some plug-ins may work well with the latest and greatest version of ConsoleOne, and others may need an earlier version. You've heard of DLL hell? Novell has created plug-in hell, and it's every bit as frustrating. We like to run ConsoleOne on a workstation with the files delivered from the server. Server-based file storage gives us a central point for snap-in management and ensures that snap-ins are available when we run ConsoleOne from any workstation in the lab. After spending an hour trying to initialize a smartcard from ActivCard (one of the top-notch third parties associated with NMAS) without success, we moved the ConsoleOne files to the workstation -- we were ready to try anything -- and behold, the card initialized without complaint.

On the client side, you need Client 32 version 3.2 or higher for Windows 95/98 and version 4.7 or higher for Windows NT/2000. You'll also need the NMAS client, which installs on top of Client 32 and any device drivers and control software for the authentication devices you implement.

Once you get all of the software installed, you can begin the process of installing and configuring the login methods provided by the device vendor. Login methods are installed by creating new SAS:NMAS Login Method objects in the Authorized Login Method container under your tree's Security container. Pointing the object-creation wizard at the configuration file provided by the device vendor configures the login method.

The wizard also will prompt you to create a Login Sequence. Unless you're adding additional methods, you might as well create the sequence when prompted. Login Sequences can be added later by opening the properties of the Login Policy object in the Security container and selecting the Login Sequence tab. Login Sequences are the heart of the Login Policy objects, which translate your corporate security policy into actual authentication procedures. The policies you define control the methods included in a sequence, as well as the order in which those methods execute during the authentication process.

Depending on the vendor and technology you are implementing, you may need to create a device container and create and initialize device objects into your tree at this time as well. The ActivCard One token-based device we tested shipped with a floppy disk that contained the information needed to create and initialize the device in NDS. Users are assigned to devices at this point as well. Other vendors will have different schemes, so our best advice is to read your vendor's documentation carefully. This process has many steps and is not intuitive.

Now it's time to assign login sequence clearances to users by going to the security tab of the users' property. This is where your corporate security policies are transformed into required authentication procedures. Users can use any of the clearances assigned to them for authentication but can only access resources if the sequence of methods they use to log in match or exceed the sequence of methods required by the resource they are attempting to access.

Finally, you need to set the Volume Security Label to control access to the files and directories on the volume, based on the type of clearance assigned to your users' sessions. If the Security Label is set to biometric & token & password, a user session based only on token & password will fail to gain access to the volume until that user reauthenticates with all the required methods, and then only if his or her rights permit access. NMAS also will prevent a properly authenticated user from moving or copying files stored in a high-security volume to a less secure volume.

You Won't Find It

What's missing? Neither the current NMAS version, 1.0, nor the future version, 2.0 (due May 31, according to Novell), lets you control access down to the individual directory or file. The finest level of granularity is the volume, which is about as granular as a boulder. This lack of granularity limits your flexibility when deciding where files reside, so careful planning and additional user training are required. Version 1.0 doesn't block administrative access to directory objects or their attributes, which means that directory administration doesn't benefit from the enhanced security afforded by NMAS. This feature will be added in the next version, along with a reauthentication API that will let users add additional methods to their existing login without needing to do a complete re-login.

The reauthentication API addresses half of one of our wish-list items for any graded authentication scheme. We think that users and administrators should be able to add and remove various grades of authentication, as needed, during a session. An administrator should be able to log in first thing in the morning with credentials that provide basic user access. When the administrator needs to administer the tree or access a resource that requires additional methods, he or she should be prompted for the smartcard or thumbprint that is required for that level of access. When finished, the administrator should be able to go back to a reduced grade by subtracting the additional grades without needing to re-login. In the long run this scheme is more secure, since users aren't logged-in with a higher grade than needed for any particular operation, and it's more convenient for your users, which is normally the antithesis of security.