Implementing Strong Authentication

I l @ ve RuBoard

There have been many solutions and implementations for providing strong authentication. Some of these solutions replace daemons and are for specific systems, while others do not address all methods of access to a system, and others require that the user 's terminal be a PC. These restrictions and limited functionality have prevented them from becoming the next -generation authentication scheme.

A good authentication scheme has to be ubiquitious so it can be used everywhere. It has to be universal so that all access methods to a system are supported. It has to be flexible enough to support the specific needs of any system.

Modern implementations of UNIX systems are shipped with a unified authentication scheme called PAM.

PAM

The Pluggable Authentication Module (PAM) [OSF RFC 86] is an industry standard authentication framework. PAM gives system administrators the flexibility of choosing any authentication service available on the system to perform authentication. The PAM framework also allows new authentication service modules to be plugged in and made available without modifying the applications. Programs requiring user authentication pass their requests to PAM, which determines the correct verification method and returns the appropriate response. The programs do not need to know what authentication method is being used. Login authentication, account checking, and password modification use the PAM interface.

PAM defines four authentication module types: User Authentication (auth) which verifies the identity of a user and sets the user-specific credentials, Account Management (account) which retrieves the user's expiration information and verifies that the user's account and password have not expired , Session Management (session) which provides functions to initiate and terminate sessions, and Password Management (password) which provides a function to change passwords.

Control is available on both a system-wide service and an individual user basis. In the newest version of PAM, the system-wide configuration files are in the /etc/pam.d directory in files named for each service. Earlier versions use /etc/pam.conf to define system-wide and service-specific authentication methods. The /etc/pam_user.conf file is used to specify individual user methods.

The system-wide configuration file, /etc/pam.conf , defines the security mechanisms that are used to authenticate users. Its default values provide the customary operation of the system.

There is an entry in the file for each area of authentication for each service.

The entries in /etc/pam.conf have the following form:

 service-name module-type control module-path options  login    auth  required  /usr/lib/security/libpam_unix.1 

The peruser configuration file, /etc/pam_user.conf , allows individual users to be assigned different options. /etc/pam_user.conf is optional. It is needed only if PAM applications need to behave differently for various users. This can be used to isolate the administrative user accounts. For each login-name listed, the options listed replace any options specified for the module-type/module-path in /etc/pam.conf .

The entries in /etc/pam_user.conf have the following form:

 login-name module-type module-path options 

Multiple-authentication methods can be utilized simultaneously . The methods will be tried in the order in which they are listed. All "required" methods have to be successfully passed for the user to be authenticated. An authentication which successfully passes a method which is defined to be "sufficient" is considered authenticated at that point.

In combination, they can be used to allow for local users and global users. This would generally be used to have local administrative accounts and global user accounts. It is best to have no overlap between user identities between the password file and the LDAP. However, when there is an overlap, the first listed has priority.

This example indicates that the UNIX password file will have priority. Thereby, if a root user is added to the LDAP, that user will not have access to the system because there is a local root user.

 login auth sufficient /usr/lib/security/libpam_unix.1  login auth required   /usr/lib/security/libpam_ldap.1 use_first_pass 

The "use_first_pass" option uses the password entered for pam_unix for pam_ldap as well. Without this option, the user would be re-prompted if the pam_unix was unsuccessful .

In a more complex environment where multiple PAMs are utilized, there are specific ordering issues.

PAM modules can do more than just define new authentication methods. They can be used to restrict or enhance the other PAM authentication methods. Required modules can be added which limit access to the system based on resource quotas, or time of day, or any definable restriction. PAM modules can be added to password management to test the quality of the password selected. Stacking these modules can create any number of useful user controls.

• HP-UX supports PAM starting with HP-UX release 10.20 for authenticating CDE components and at 10.30 PAM was extended to provide authentication for system commands on standard HP-UX, Trusted Systems, and the Distributed Computing Environment (DCE) and to allow third-party modules. With Release 11i, PAM processing was extended. It now supports telnet, login, remsh, ftp, rexec, rlogin, dtlogin, and rcp.

  Table 10-2 lists the available HP-supplied PAM modules for 11i, which reside in /usr/lib/security .

  Table 10-2. HP-supplied PAM Modules

  libpam_unix	Standard HP-UX authentication
  libpam_dce	DCE authentication
  libpam_ntl	NT LanManager authentication
  libpam_ldap	LDAP authentication
  libpam_krb5	Kerberos V5 authentication, i.e., MIT Kerberos and Windows 2000
  libpam_updbe	Enable user specific PAM configurations

  In the System Administration Manager (SAM), you can use the Authenticated Commands subarea of Auditing and Security to manage the PAM configuration file, /etc/pam.conf . For each type of PAM authentication ” User Authentication (auth), Account Management (account), Session Management (session), and Password Management (password) ” you can add, modify, or remove service names from the PAM configuration file.

  SAM is not able to manage the peruser file, /etc/pam_user.conf , or the DCE interface; you must modify these by hand.

• Linux support for PAM is gaining rapid acceptance and support for most current Linux releases. The open source community has produced a number of PAM modules to incorporate additional authentication methods which are available in most Linux distributions. Table 10-3 shows common PAM modules found on most Linux systems.

  Table 10-3. Linux-supported PAM Modules

  pam_cracklib	This module performs strength-checking for new passwords by stacking it before other password modules. It requires the cracklib library, libcrack, to compile.
  pam_ftp	This module checks to see if the user is "ftp" or "anonymous." On finding this to be the case, it prompts for an e-mail address for a password, and proceeds to set the PAM_RUSER item with this value.
  pam_group	This module extends the /etc/group concept by granting group privileges based on who the user is and when or from where he is requesting a service, as well as, what he is trying to do.
  pam_limits	This module sets the resource limits for a service.
  pam_listfile	This module authenticates users based on the contents of a specified file.
  pam_nologin	This module always lets root in; it lets other users in only if the file /etc/nologin doesn't exist. In any case, if /etc/ nologin exists, its contents are displayed to the user.
  pam_passwd+	This module performs password strength-checking.
  pam_pwdb	This module is a plug-in replacement for pam_unix_* that uses the Password Database library.
  pam_radius	This module performs RADIUS authentication, using the Password Database library.
  pam_rootok	This module authenticates the user if his real UID is root (intended for use with the sufficient control flag).
  pam_securetty	This module implements /etc/securretty access controls.
  pam_shells	This module requires that the user's shell be listed in the /etc/ shells file.
  pam_tally	This module keeps track of the number of times an attempt is made to login.
  pam_time	This module authorizes users based on when the from where they log in.
  pam_unix_*	This module implements standard UNIX authentication.
  pam_wheel	This module enforces the wheel group privileges.

  These include some widely used authentication schemes, such as NDS, SecureID, Radius, IMAP, TACACS, S/KEY and SQL databases.

The following excerpts from the Red Hat Linux documentation illustrate and explain a default PAM configuration file:

 #%PAM-1.0  auth     required /lib/security/pam_securetty.so  auth     required /lib/security/pam_pwdb.so shadow nullok  auth     required /lib/security/pam_nologin.so  account  required /lib/security/pam_pwdb.so  password required /lib/security/pam_cracklib.so  password required /lib/security/pam_pwdb.so shadow nullok use_authtok  session  required /lib/security/pam_pwdb.so 

The first line is a comment. (Any line that starts with a # character is a comment.) Lines two through four stack up three modules to use for login authorization. Line two makes sure that if the user is trying to log in as root, the tty on which he or she is logging in is listed in the /etc/ securetty file if that file exists. Line three causes the user to be asked for a password and the password to be checked. Line four checks to see if the file /etc/nologin exists, and if it does, displays the contents of the file, and if the user is not root, does not let him or her login.

Note that all three modules are checked, even if the first module fails. This is a security decision ” it is designed to prevent the user from knowing why his or her authentication was disallowed, because knowing why it was disallowed might allow him or her to break the authentication more easily. You can change this behavior by changing required to requisite; if any requisite module returns failure, PAM fails immediately without calling any other modules.

The fifth line causes any necessary accounting to be done. For example, if shadow passwords have been enabled, the pam_pwdb.so module will check to see if the account has expired, or if the user has not changed his or her password and the grace period for changing the password has expired.

The sixth line subjects a newly changed password to a series of tests to ensure that it cannot, for example, be easily determined by a dictionary-based password cracking program.

The seventh line (which may be wrapped) specifies that if the login program changes the user's password, it should use the pam_pwdb.so module to do so. (It will do so only if an auth module has determined that the password needs to be changed, for example, if a shadow password has expired.)

The eighth and final line specifies that the pam_pwdb.so module should be used to manage the session. Currently, that module doesn't do anything; it could be replaced (or supplemented by stacking) by any necessary module.

Note that the order of the lines in the file matters especially when "sufficient" and "requisite" modules are used.

I l @ ve RuBoard