Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules: Part I
- Traditional Solaris OE Authentication
- PAM Components
- PAM LDAP Module
- Acknowledgments
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Pluggable Authentication Modules (PAM) are an integral part of the authentication mechanism for the Solaris™ 9 Operating Environment (Solaris OE). PAM provides system administrators with the ability and flexibility to choose any authentication service available on a system to perform end-user authentication. Other PAM implementations are Linux-PAM and OpenPAM.
By using PAM, applications can perform authentication regardless of what authentication method is defined by the system administrator for the given client.
PAM enables system administrators to deploy the appropriate authentication mechanism for each service throughout the network. System administrators can also select one or multiple authentication technologies without modifying applications or utilities. PAM insulates application developers from evolutionary improvements to authentication technologies, while at the same time allowing deployed applications to use those improvements.
PAM employs run-time pluggable modules to provide authentication for system entry services. PAM offers a number of benefits, including:
-
Flexible configuration policy by enabling each application or service to use its own authentication policy. PAM provides the ability for system administrators to choose a default authentication mechanism. By using the PAM mechanism to require multiple passwords, protection can be enhanced on high security systems. For example, a system administrator might want users to get authenticated by both Kerberos and Digest-MD5.
-
Ease of use for the end user. Password usage can be made easier by using PAM. If users have the same passwords for different mechanisms, they do not need to retype the password. Configured and implemented properly, PAM offers a way to n prompt the user for passwords for multiple authentication methods without having the user enter multiple commands. For example, a site may require certificate-based password authentication for telnet access, while allowing console login sessions with just a UNIX password.
-
Enhances security and provides ease of use of the Solaris 9 OE in an extensible way. The security mechanisms accessible through PAM are implemented as dynamically loadable, shared software modules that can be installed by system administrators in a manner that is transparent to applications. By increasing overall security, users enjoy greater service levels and lower cost of ownership.
This article is part one of a two-part series that offers a technical overview of how the Solaris 9 OE implementation of PAM works, and demonstrates the straightforward way in which it can be configured to accommodate site-specific security policy requirements. This article examines the PAM architecture and the components that make up PAM.
Extending Authentication in the Solaris 9 OE Using PAM: Part II due in the October issue of Sun BluePrintsTM Online details the PAM application programming interface (API) and the PAM service provider interface (SPI). It also details how to write your first PAM module, including annotated examples of how to write pluggable authentication modules.
Part one of this article contains the following information:
-
Traditional Solaris OE authentication
-
PAM components
-
How to add a PAM module
-
PAM LDAP module
Traditional Solaris OE Authentication
Traditional Solaris OE authentication is based on the method developed for early UNIX implementations. This method employs an one-way encryption hashing algorithm called crypt(3c). The encrypted password is stored either in a file or in a Solaris OE naming service, from which it is retrieved during the user login process. The traditional UNIX method of the Solaris OE authentication, using crypt(3c), is very popular and has been enhanced to use an LDAP directory as its data store.
Before proceeding with the details on authentication, you must have a good understanding of what crypt(3c) is. There is some confusion because of a naming conflict with an application named crypt; the latter is a standard tool that ships with the Solaris OE and is a program for encrypting and decrypting the contents of a file. (This program can be found in /usr/bin/crypt.)
However, when the term "crypt" is referred to in authentication, it is normally cited as crypt(3c) and refers to the standard UNIX password hashing algorithm crypt(3c), available to C programmers in the libc.so library.
A more sophisticated authentication method based on public key technology was introduced with the Network Information System (NIS+) naming service (now rebranded as the Sun OSTM 5.0 Network Information Service). The NIS+ naming service method does not replace crypt(3c), but rather provides an additional security layer by introducing the concept of a network password. When users access network services through the secure remote procedure call (RPC) mechanism, the network password is required.
Originally developed by Sun Microsystems, Inc. and adopted by the Open Software Foundation (OSF) for inclusion in Common Desktop Environment (CDE)/Motif, pluggable authentication modules (PAM) provide a mechanism for dynamic system authentication and related services such as password, account, and session management. Realizing that new authentication models continue to be developed, Sun Microsystems, Inc. created the PAM architecture that allows additional methods to be added without disturbing existing ones. PAM was introduced in the Solaris 2.6 OE to overcome having to recode system entry services such as, login, passwd, dtlogin, telnet, and rlogin when a new authentication mechanism was developed and introduced.
The PAM architecture and alternatives to traditional Solaris OE authentication are presented in the Section , "Solaris 9 OE PAM Framework," on page 6.
UNIX Passwords
Passwords are created with the Solaris OE passwd command. This command prompts the user for a (new) password, which the user enters as a text string. In the Solaris OE, this text string is then hashed—or one-way encrypted—using the crypt(3c) algorithm. The result is stored either in /etc/shadow, or in the passwd.byname and passwd.byuid NIS maps. If the NIS+ naming service is used, the results are stored in the Passwd and Cred table type. The crypt(3c) algorithm is provided with a random seed, known technically as a salt string, so that the result is different each time the passwd command is run, even if the same text string is used.
When a user logs in, the Solaris OE login program challenges the user to provide a password. This password is hashed in the same manner as the passwd command. If the output from this process matches the output that is stored in the password database, the user is authenticated.
FIGURE 1 illustrates how the UNIX password process works.
)
FIGURE 1
Login Program Text String Converting to a Hashed String
Benefits and Drawbacks of crypt(3c)
The major benefit of crypt(3c) is that it is easy to implement in a closed environment. Authentication takes place on the host that the user logs in to, so an authentication server is not required. In the case of local logins, the clear text passwords are never stored or sent over the network, so there is no reason to be concerned about eavesdroppers intercepting the password. However, when authenticating over a network using telnet or rlogin, passwords are sent in the clear text.
Because crypt(3c) uses a one-way encryption algorithm, it is difficult to decrypt passwords stored on the server. Only the user knows what the actual password is. This means that there is no way to convert passwords stored in crypt to another format required by a different authentication method.
When the crypt(3c) function is called, it takes the first eight characters and returns its computation. This computation is then injected with a randomly generated value called the salt. In conventional crypt, the salt is stored as the first two characters. This salt value is then added, resulting in a sequence of 13 characters. The result is that the salt is actually an important part of the password string that is stored in the specific naming service.
NOTE
In the future, Sun plans to update the crypt(3c) API in the Solaris 9 OE to allow different algorithms, such as MD5 and Blowfish to be used for encrypting the user's login password.
As CPUs and storage capabilities increase, the crypt(3c) algorithm becomes vulnerable to attack. The crypt(3c) mechanism shipping with the Solaris 9 OE, along with PAM authentication, is exactly the same implementation that has been in the Solaris OE for many years now, and is due to change in a subsequent update release of the Solaris 9 OE.
The Solaris OE crypt(3c) mechanisms work well for authenticating local Solaris OE clients, but they are not the only methods used by applications and services running in the Solaris OE. This can make it difficult for system developers and system administrators, who must work with multiple password systems, and for users who must remember multiple passwords.
The PAM interface in the Solaris 9 OE makes it easier for system administrators to deploy different authentication technologies without modifying administrative commands such as login, telnet, and other administrative commands. Administrators are able to select one or multiple authentication technologies, without modifying applications or utilities. PAM can also be an integral part of a single sign-on system. The PAM APIs provide a flexible mechanism that increases overall system security. The PAM APIs are detailed in Extending Authentication in the Solaris 9 OE Using PAM: Part II due in the October issue of Sun BluePrints Online.