Authentication

Authentication provides the doorway for access to network resources. Without a strong authentication mechanism, sensitive network resources are essentially laid bare for anyone to access. The primary authentication method currently used with eDirectory is the username/password combination. Novell Modular Authentication Service (NMAS) makes it possible to integrate more advanced authentication and authorization techniques into your NetWare environment. Furthermore, NMAS offers a feature new with NetWare 6.5 that improves the traditional password-based authentication method, which is known as universal password .

Novell Modular Authentication Service

NMAS is designed to help you protect information on your network. NMAS offers a more robust framework for protecting your NetWare 6.5 environment. If you're not familiar with the different pieces of NMAS, you should get to know the following concepts. More information about each of these is provided in the NetWare 6.5 online documentation.

Phases of Operation

There are specific times when NMAS can be useful in helping to secure your network environment:

• User identification occurs prior to the actual authentication process. It provides a way to automatically gather a user's authentication information and use it to populate the Novell Login dialog in the Novell Client.

• Authentication is the opportunity for users to prove they are who they claim to be. NMAS supports multiple authentication methods .

• Device removal detection is the capability to lock down a workstation after authentication when it becomes clear that the user is no longer present.

Each these phases of operation is completely independent. You can choose to use the same, or completely different, identification techniques for each phase. To provide this functionality, NMAS introduces a few additional concepts to NetWare authentication:

• Login factors

• Login methods and sequences

• Graded authentication

Login Factors

NMAS uses three approaches to logging in to the network, known as login factors . These login factors describe different items or qualities a user can use to authenticate to the network:

• Password authentication: Also referred to as "something you know," password authentication is the traditional network authentication method. It is still responsible for the lion's share of network authentication that goes on, including LDAP authentication, browser-based authentication, and most other directories.

• Device authentication: Also referred to as "something you have," device authentication uses third-party tokens or smart cards to deliver the secret with which you authenticate to the network.

• Biometric authentication: Also referred to as "something you are," biometric authentication uses some sort of scanning device that converts some physical characteristic into a digital pattern that can be stored in eDirectory. When users attempt to authenticate, their biometric patterns are compared against the stored version to see if they match. Common biometric authentication methods include fingerprint readers, facial recognition, and retinal scans .

NOTE

NMAS provides support for password authentication only. Device and biometric login factors are supported with NMAS Enterprise Edition .

Login Methods and Sequences

A login method is a specific implementation of a login factor. Novell has partnered with several third parties to create a variety of options for each of the login factors described earlier in this chapter. A post-login method is a security process that is executed after a user has authenticated to eDirectory. One such post-login method is the workstation access method, which requires the user to provide credentials in order to unlock the workstation after a period of inactivity.

Once you have decided upon and installed a method, you need to assign it to a login sequence in order for it to be used. A login sequence is an ordered set of one or more methods. Users log in to the network using these defined login sequences. If the sequence contains more than one method, the methods are presented to the user in the order specified. Login methods are presented first, followed by post-login methods.

Graded Authentication

Another important feature in NMAS is graded authentication , which allows you to grade, or control, access to the network based on the login methods used to authenticate to the network. Graded authentication operates in conjunction with standard eDirectory and file system rights to provide very robust control over data access in a NetWare 6.5 environment.

There are three main elements to graded authentication:

• Categories: NMAS categories represent different levels of sensitivity and trust. You use categories to define security labels. There are three secrecy categories and three integrity categories by default: biometric, token, and password.

• Security labels: Security labels are combinations of categories that assign access requirements to NetWare volumes and eDirectory objects and properties. NMAS Enterprise Edition comes with eight security labels:

  • Biometric and password and token

  • Biometric and password

  • Biometric and token

  • Password and token

  • Biometric

  • Password

  • Token

  • Logged in

• Clearances: Clearances are assigned to users to represent the amount of trust you have in them. In the clearance, a read label specifies what a user can read and a write label specifies locations to which a user can write. Clearances are compared to security labels to determine whether a user has access. If a user's read clearance is equal to or greater than the security label assigned to the requested data, the user will be able to view the data.

By configuring these elements of graded authentication, you can greatly increase the security of your network data, and apply different types of security to data of different levels of sensitivity.

Installing NMAS

NMAS requires both server- and client-side software in order to perform its authentication services. Installation of the NMAS client happens during the installation of the Novell Client, and is described in Chapter 2. On the server, NMAS is one of the default services, and will be installed automatically with any service that requires its services, such as Native File Access Protocols (NFAPs). However, if necessary, you can install NMAS manually from iManager or from the graphical server console.

To install NMAS from iManager, complete the following steps:

1. Launch iManager and open the Install and Upgrade link, and then select Install and Upgrade.

2. Click Remote Product Install in the right frame.

3. Browse to the location of the NetWare 6.5 Operating System CD-ROM and click OK.

4. Browse to and select the server to which you want to install NMAS and click Next . Authenticate as an Admin user to the server you selected.

5. At the Components screen, select only Novell Modular Authentication Service and click Next.

6. Select the NMAS Login Methods you want to install and click Next. Mouse over each method name to see a brief description of how the method is used.

7. At the Summary screen, select Copy Files to install NMAS. You will need to insert or specify the location of the NetWare 6.5 product's CD-ROM.

8. At the Installation Complete screen, click Close to complete the installation.

Once NMAS is installed, there are several configuration options, depending on your specific environment and needs. Server-side configuration is available through either iManager or ConsoleOne. Once the NMAS server options are configured, you can configure the NMAS client to leverage NMAS capabilities. Generally, the process involves the following:

• Create a login sequence: This process identifies the specific login methods that will be used for login and post-login operations, and the order in which they will be applied if multiple login methods are specified.

• Assign a login sequence to a user: Once created, a login sequence is available for use by a user. A default login sequence can be defined, and users can be forced to use a specific login sequence, if desired.

• Graded authentication: With the login environment configured, you can now define those network resources that are available with each login method. Graded authentication lets you label network resources and require certain levels of authentication in order to access those resources.

• Customize the user login: The Novell Client supports several customization options based on the type of authentication that is being used. For more information on the Novell Client, see Chapter 2. You can also review Appendix A for detailed information on the Novell Client property pages.

For more detailed information on each of these NMAS configuration steps, see the Novell online documentation.

Universal Password

In addition to its other authentication and authorization options, NMAS also provides a new way of dealing with the different password requirements of some of Novell's cross-platform services. The traditional Novell password, although quite effective for NetWare-based authentication, is limited by its weak capability to integrate with non-NetWare systems.

Universal password proposes to resolve this problem by simplifying the management of different password and authentication systems with your NetWare 6.5 environment.

Universal password resolves several deficiencies in the current password authentication model across the various NetWare 6.5 services, including:

• Native file access: Native file access protocols such as CIFS, AFP, and NFS cannot interoperate with the traditional NetWare password. Rather, they use a separately administered Simple Password, which is less secure than the NetWare password and must be managed separately. For more information on NFAP, see Chapter 2.

• LDAP: Similar to NFAP, LDAP binds are largely incompatible with the traditional NetWare password, and also run the risk of sending unencrypted passwords.

• LDAP user import: It is possible to import users from foreign directories via LDAP, but imported passwords conform to the rules of the native system and are encrypted in the native format. This makes them largely incompatible with the traditional NetWare password and forces them to be managed through the Simple Password mechanism.

• Password synchronization: With the availability of meta-directory tools such as DirXML and Account Management, you often end up with multiple passwords stored as different object attributes. These passwords can be synchronized as long as changes are performed using the proper interface, such as the Novell Client. Changes made in other ways can cause synchronization problems.

If these issues mentioned, and the use of international characters in passwords, are not problems for you, you might not need to enable universal password. However, as your network becomes increasing Web-integrated and managed, universal password will likely become more attractive.

Universal password leverages NICI for cryptographic services, and NICI now includes special cryptographic key that can be shared across multiple servers. Known as the SDI domain key, it removes the problems associated with encrypting data using server-specific keys. The SDI domain key can be shared across multiple servers so that any server in the domain can decrypt data.

Preparing for Universal Password

The universal password environment requires NetWare 6.5 on at least one of the servers in any replica ring that holds User objects that will leverage the universal password. To do this, identify the container(s) that holds the objects of those users who will be using universal password, and then locate the eDirectory partition in which that container resides and identify the server(s) that hold replicas of that partition. At least one of those servers will have to be a NetWare 6.5 server.

Because of this requirement, universal password is not enabled by default in NetWare 6.5. However, as you plan your NetWare 6.5 migration, plan to upgrade at least one server in each partition first, and then move to other replica servers. This strategy will help smooth the way for using universal password throughout your network.

NOTE

If you want to use NFAP with universal password, NFAP servers should be upgraded as described previously for SDI domain servers.

Configuring the SDI Domain

NetWare 6.5 includes SDIDIAG.NLM for configuring the SDI domain in preparation for enabling universal password. Prior to creating the SDI domain, you should check any non-NetWare 6.5 servers that you want in the SDI domain to see if they meet the minimum requirements:

1. From the server console, load SDIDIAG.NLM.

2. Authenticate as an Admin user in the tree and click OK.

3. Enter the following command. If any problems are noted, use the information in SYS:SYSTEM\SDINOTES.TXT to help you resolve them, and then continue with the configuration.

    CHECK -v >> sys:system\sdinotes.txt 

4. (Conditional) Verify that each SDI domain key server that is not running NetWare 6.5 is running NICI v2.4.2 or later. To do this, enter the following command at the server console of each server in the SDI domain:

    M NICISDI.NLM 

   The version must be 24212.98 or later. If not, you must either upgrade the server to NetWare 6.5 or update the NICI on this server to v2.4.2.

NOTE

NICI v2.4.2 requires eDirectory 8.5.1 or later, so if you are not running a fairly current environment, the preparation for universal password can be significant. You can download NICI v2.4.2 from Novell's support Web site at http://support.novell.com/filefinder/.

Based upon the results of the configuration tests, you can add or remove servers SDI domain key servers with SDIDIAG.NLM as well.

To add a server to the SDI domain, complete the following steps:

1. Load SDIDIAG at the server console.

2. Authenticate as an Admin user in the tree and click OK.

3. Enter the following command to add a server:

    AS -s <Full Server Name> 

   For example: AS s .prv-serv1.provo.quills.quills-tree

   To remove a server from the SDI domain, use the same process, but use the following command:

    RS -s <Server Name> 

   For example: RS s .prv-serv1.provo.quills.quills-tree

Once you have placed all the necessary servers in the SDI domain, use SDDIAG to check that each server has the cryptographic keys necessary to securely communicate with the other servers in the tree. To do this, complete the following steps:

1. Load SDIDIAG at the server console.

2. Authenticate as an Admin user in the tree and click OK.

3. Enter the following command to add a server:

    CHECK v >> sys:system\sdinotes.txt n <Container DN> 

For example, to check the container provo.quills in quills-tree , you would type the following:

 CHECK v >> sys:system\sdinotes.txt n provo.quills. quills-tree 

This operation will report any inconsistencies between the cryptographic keys on the various SDI domain servers. If any problems are noted, use the information in SYS:SYSTEM\SDINOTES.TXT to help you resolve them, and then continue with the configuration.

Enable Universal Password

Once all the pieces are in place, you are ready to enable universal password. To enable universal password, complete the following steps:

1. Launch iManager, open the NMAS Management link, and select Universal Password Configuration.

2. Specify the container for which you want to enable universal password, and click View.

3. Select the Enable radio button, and click Apply and OK.

Once enabled, the NetWare 6.5 Novell Client software will start using universal password automatically. When you reset a password, you will actually be resetting the universal password, which will transparently synchronize the traditional NetWare and Simple passwords for your users. They won't notice any difference in behavior. However, this transparent synchronization is fully operational only when running NetWare 6.5 with the latest Novell client software (version 4.9 or later for Windows 2000/XP clients and version 3.4 or later for Windows 95/98 clients ). For more information on the specific capabilities of universal password when used in different combinations of NetWare, Novell Client, and various client services, see the NetWare 6.5 online documentation.

eDirectory Login Controls

In addition to the actual login process, eDirectory provides a variety of login controls designed to help secure the network. Those controls are found in the properties of each User object. The various types of restrictions offered by eDirectory include

• Password restrictions

• Login restrictions

• Time restrictions

• Address restrictions

• Intruder lockout

NOTE

You will also see an Account Balance tab. This is a leftover from a server accounting feature that is no longer supported in NetWare 6.5.

You can manage the various login controls from iManager or ConsoleOne. Login controls can be set on individual User objects, or they can be defined at the container level, where they will be automatically applied to all users in that container. To get to the login restrictions pages available through eDirectory, complete the following steps:

1. Launch iManager and select the View Objects icon. Locate the object for which you want to set login controls.

2. Click the object and select Modify Object.

3. Select the Restrictions tab and you will see a subpage for each of the controls listed previously. Select the appropriate page.

4. Make your desired changes and click OK to save your changes.

Each of the login control pages is described in more detail in the following sections.

Password Restrictions

The Password Restrictions page allows you to set password characteristics for eDirectory users, as shown in Figure 6.2. By default, the only selected option is Allow User to Change Password. However, this will not provide any significant degree of security, so you will want to enable some of the other options.

• Allow User to Change Password: Checking this box permits the user to change the password associated with the User object.

• Require a Password: Checking this box forces the user to set an account password. It also enables all other password options. Associated with this option is a Minimum Password Length field, which can be used to require passwords of at least a given number of characters. The default is five, but the value can be set from 1 to 128 characters.

• Force Periodic Password Changes: This field allows you to require users to change their passwords regularly. Associated with this option is a Days Between Forced Changes field, which defines how often the password must be changed. The default is 40, but the value can be set between 1 and 365 days.

• Date Password Expires: With this option you can define specific password expiration. It also shows when the password will next expire. When the user resets a password, the system will automatically reset this date forward by the number of days specified in the days between forced changes field.

• Require Unique Passwords: Checking the Require Unique Passwords option allows eDirectory to track the last eight passwords used with this account and prevents the user from re-using these old passwords.

  NOTE

  eDirectory does not implement any pattern recognition algorithms that force users to change the password to a significantly different value. Users can change the value by a single character and eDirectory will not complain. Similarly, eDirectory does not have an option for requiring numeric or special characters as part of the password.

  
  

• Limit Grace Logins: This option limits the number of times a user is allowed to log in after his password has expired . Associated with it are two fields. The Grace Logins Allowed field allows the administrator to set how many grace logins are permitted. The default is six, but the value can be set between 1 and 200. The Remaining Grace Logins field tracks how many grace logins remain before the account is locked out. The administrator can also reset this value in order to give an expired account more time to reset the password, if necessary.

• Set Password (link): The Set Password link will open a Java utility to change the user's password. You must first supply the existing password, and then the new password.

Figure 6.2. Password Restrictions page in iManager.

Time Variables with ConsoleOne

Time values in ConsoleOne are interpreted as UTC time, or Greenwich Mean Time (GMT). This affects how you set any type of expiration parameter. For example, if you want a user's password to expire at a specific time, you need to take into account the time zone offset between your location and GMT. Mountain Standard Time (MST) is seven hours earlier than GMT, so if you want the password to expire at 1:00am in Utah you have to set the expiration time to 8:00am GMT (8:00 7:00 = 1:00).

It is possible to force ConsoleOne to use the local time rather than UTC by setting an environment variable on the workstation from which ConsoleOne is running. Consult the documentation for your particular workstation operating system to determine how this is done.

Because ConsoleOne is Java-based, and not a native Windows application, it does not recognize the Windows-based time zone information. In order to set system-level time zone information for Windows 95/98 or Windows NT/2000, add the TZ= environment variable to a login script or the AUTOEXEC.BAT file. For example, SET TZ=MST7MDT will instruct the system to use Mountain Standard Time instead of GMT when displaying time information. This information will be available to non-Windows applications such as ConsoleOne.

Login Restrictions

The Login Restrictions page allows you to control the capability of a user to log in to the network, as shown in Figure 6.3.

• Account Disabled: Checking this box disables the user account and prevents future login attempts. However, this will not affect a user who is currently logged in.

• Account Has Expiration Date: Checking this box allows you to set a date when the user account will be automatically disabled. This option might be used for contract employees or consultants who will be working for a predefined period of time.

• Limit Concurrent Connections: Check this box to define how many times the same account can be used to log in from different workstations simultaneously . If enabled, the default is 1, but any value between 1 and 32,000 can be selected.

Figure 6.3. Login Restrictions page in iManager.

Time Restrictions

The Time Restrictions page enables you to limit the time(s) of day when a user can access the network, as shown in Figure 6.4. By default, there are no restrictions.

Figure 6.4. Time Restrictions page in iManager.

To set a time restriction, click the box for which you want the restriction to occur, and then click Update to reflect the change. To select a range of time, hold down the Shift key while moving the mouse over the time range. Each block is 30 minutes. When finished, make sure to select OK to save the new restrictions out to eDirectory. If a user is logged in when her lockout period is reached, she will be issued a five-minute warning, after which she will be automatically logged out.

NOTE

One important caveat to time restrictions is that they are governed by the user's home time and not his current time. For example, if a user in New York, takes a trip to Los Angeles, and is going to dial in to his home network, the time in New York rather than the time in Los Angeles will determine the time restriction. A 6:00 p.m. EST time restriction would shut the user down at 3:00 p.m. PST. Although that might give your employee time to get in a round of golf, it might not be what you intended when configuring the time restriction in the first place.

Address Restrictions

The Address Restrictions page can be used to tie a user account to a specific workstation, as shown in Figure 6.5, thereby forcing users to log in from that hardware location only.

Figure 6.5. Address Restrictions page in iManager.

In today's world of dynamic addressing and roaming users, this option is not as useful as it once might have been, but in very security-conscious environments, it can still be necessary. However, TCP/IP functionality is severely limited by the fact that the utility assumes a Class B subnet mask (255.255.0.0) for all IP addressingnot very practical in today's overloaded IP world.

Intruder Lockout

The Intruder Lockout page is useful only after a user account has been disabled. Intruder lockout refers to the disabling of a user account after a certain number of unsuccessful login attempts have been made. To re-enable a locked-out account, the administrator unchecks the Account Locked box on this page. The other three entries simply provide information about the status of the locked account.

The actual intruder detection system is configured at the container level rather than at the user level. In order to configure your intruder detection environment, complete the following steps:

1. Launch iManager and select the View Objects icon. Locate the container for which you want to set intruder detection.

2. Click the object and select Modify Object.

3. Select the Intruder Detection link, as shown in Figure 6.6.

   Figure 6.6. Enabling intruder detection features in iManager.

   

4. Make your desired changes and click OK.

   • Detect Intruders: Check this box to enable the intruder detection system for this container. Associated with this check box are fields that allow you to set the number of incorrect login attempts before intruder lockout is activatedthe default is 7and the interval within which the unsuccessful attempts must occurthe default is 30 minutes.

   • Lock Account After Detection: Check this box to enable the account lockout feature. Associated with this check box are fields that allow you to specify the time period for which the account will remain lockedthe default is 15 minutes. At the end of this period, the account will be reactivated automatically.

Once configured, intruder lockout makes it much more difficult for would-be hackers to perform dictionary or other brute force attacks against one of your network accounts.