- 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
PAM LDAP Module
The PAM LDAP module (pam_ldap) was introduced in the Solaris 8 OE for use in conjunction with pam_unix for authentication and password management with an LDAP server. This module was written to support stronger authentication methods such as CRAM-MD5, in addition to the other UNIX authentication capabilities provided by pam_unix.
NOTE
The pam_ldap module must be used in conjunction with the modules supporting the UNIX authentication, password and account management, as pam_ldap is designed to be stacked directly below these modules.
Currently, pam_ldap provides support only for authentication and password management. Support for account management is expected to be provided in the Solaris 9 12/02 OE.
The pam_ldap module should be stacked directly below the pam_unix module in the configuration file /etc/pam.conf. If there are other modules that are designed to be stacked in this manner, they could be stacked under the pam_ldap module. This design must be followed in order for authentication and password management to work when pam_ldap is used. The following is a sample of /etc/pam.conf file with pam_ldap stacked under pam_unix:
# Authentication management for login service is stacked. # If pam_unix succeeds, pam_ldap is not invoked. login auth sufficient /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_ldap.so.1 # Password management other password sufficient /usr/lib/security/pam_unix.so.1 other password required /usr/lib/security/pam_ldap.so.1
It is important to note that the control flag for pam_unix is sufficient. This flag means that if authentication through pam_unix succeeds, then pam_ldap is not invoked. Also, other service types, such as dtlogin, su, telnet, and so forth can substitute for login. See FIGURE 4.
)
FIGURE 4
pam_ldap Structure
The options supported by the pam_ldap are:
-
debug: If this option is used with pam_ldap, then debugging information is output to the syslog(3C) files.
-
nowarn: This option turns off warning messages.
How PAM and LDAP Work
Before discussing the details of how PAM and LDAP work, it is important to provide a quick overview to understand and distinguish between how the password is stored and how the authentication mechanism is used to authenticate to the LDAP server. The password can be stored in a variety of formats in the Sun ONE Directory Server, such as, salted secure hash algorithm (SSHA) secure hash algorithm (SHA), CRYPT, and so forth.
The authentication mechanisms currently used and supported in the Solaris 8 OE LDAP Client, are NONE, SIMPLE, and CRAM-MD5 authentication. SIMPLE authentication requires the client to pass a distinguished name (DN) and password to the server in clear text. Currently, the Sun ONE Directory Server 5.x does not support the authentication mechanism CRAM-MD5, which sends only the digest over the wire. CRAM-MD5 is implemented as a simple authentication and security layer (SASL) mechanism and both the client and server must use it. What happens is the client request authentication is based on SASL/CRAM-MD5 and the server must support this to complete the authentication. In general, very few clients use CRAM-MD5, now that RFC 2831 mandates the use of Digest-MD5, which is intended to be an improvement over CRAM-MD5. With the introduction of the Solaris 8 OE and the LDAP Client, a usable security model is not provided.
With the introduction of the Sun ONE Directory Server 5.x; SASL External and Digest-MD5 are now supported for authentication. With Digest-MD5, a digest is created and sent across the wire to authenticate to the directory server. The directory server then compares the digest that was sent with the digest created by itself with the stored password and returns success if it matches. In this case, the password is not sent in clear text. To address the absence of a security model in the Solaris 8 OE LDAP Client, the Solaris 9 OE now incorporates the Sun ONE Directory Server 5.1 and Solaris 9 OE Secured LDAP Client, addressing the security issues found in the LDAP Client.
There are two LDAP Client libraries available. Currently, the Solaris 8 OE LDAP Client library version provides no support for Secure Socket Layer/Transport Layer Security 1.0 (SSL/TLS 1.0). To address this, a new LDAP library (libldap (v5)) for the Solaris 9 OE has been developed and it supports both SSL and TLSv1.
NOTE
In the current release of the Solaris 9 OE, the extended startTLS operation is not supported.
The LDAP Client library continues to provide support for the simple page control and the SASL CRAM-MD5 authentication mechanism.
Authentication With pam_unix
In authentication with pam_unix, the client retrieves the password that is stored in the server by making a call to the getspnam function. This function binds to the LDAP server with the proxy agent account (the reason the proxy passwd is sent across the wire in clear text). The proxy agent password is stored in the userPassword attribute in the directory server. This proxy agent account can reside anywhere in the directory server, but must contain the userPassword attribute.
Note that the access control instructions (ACIs) of the proxy agent allow this account to have read access to all user passwords. ACIs are instructions that are stored in the directory server itself. Every entry can have a set of rules that define an ACI for that entry. An ACI appears as an attribute in the entry so it can be retrieved by using LDAP search, or it can be added, updated, or deleted with an LDAP modify operation.
An entry may have one ACI, many ACIs, or none. ACIs allow or deny permissions to entries. When the directory server processes an incoming request for that entry, the server uses the ACIs specific to that entry to determine whether or not the LDAP client has permission to perform the requested operation.
NOTE
LDAP stores data as entries. An entry has a distinguished name (DN) to uniquely identify it within the directory server
The encrypted password is sent to the client side and compared with the crypted password supplied by the user at the password prompt. If there is a match, pam_unix returns success. The following tables illustrate the authentication mechanisms currently used.
TABLE 3 lists the PAM abbreviations used in this section.
TABLE 3 PAM Abbreviations
|
Abbreviation |
Description |
| UP | User password |
| PP | Proxy agent password |
| NP | New password |
| NO* | Not applicable (at present) |
TABLE 4 illustrates if the user password and proxy password are transmitted in the clear during PAM authentications.
TABLE 4 PAM Authentication
|
Authentication Mechanisms |
pam_unix |
pam_ldap |
| SIMPLE | UP-No PP-Yes | UP-Yes PP-Yes |
| DIGEST-MD5 | UP-NO* PP-No | UP-No PP-No |
| TLS: SIMPLE | UP-No PP-No | UP-No PP-No |
| TLS: DIGEST-MD5 | UP-No PP-No | UP-No PP-No |
NOTE
In Tables 4 and 5 the reason for "NO*" as the value of the Digest-MD5 UP column is because the Sun ONE Directory Server version 5.1 requires the passwords be stored in the server in clear text for Digest-MD5 to work.
For updating passwords in pam_unix, the same comparison as for authentication takes place (since the user has to bind as the dn); then, the new password is encrypted and not passed over the wire in clear text (see TABLE 5).
TABLE 5 PAM Update of Password
|
Authentication Mechanisms |
pam_unix |
pam_ldap |
| SIMPLE | UP-No PP-Yes NP-No | UP-Yes PP-Yes NP-Yes |
| Digest-MD5 | UP-NO* PP-No NP-NO* | UP-No PP-No NP-Yes |
| TLS: SIMPLE | UP-No PP-No NP-No | UP-No PP-No NP-No |
| TLS: Digest-MD5 | UP-No PP-No NP-No | UP-No PP-No NP-No |
The matrices are easier to understand when you distinguish between how the password is stored and how the authentication mechanism is used to authenticate to the LDAP server. The password can be stored in a variety of formats, such as SSHA, SHA, crypt, clear text, and so forth. The authentication mechanisms that are currently supported are NONE, SIMPLE, SASL/CRAM-MD5, SASL/Digest-MD5, TLS:NONE, TLS:SIMPLE, TLS:SASL/CRAM-MD5, and TLS:SASL/Digest-MD5.
pam_ldap Authentication
In authentication that uses pam_ldap, the user password is passed to the server in an auth structure in clear text, since authentication is being attempted with the user dn and password. If SIMPLE authentication is used and the password matches, then success is returned. Using pam_ldap in the Solaris 9 Secure LDAP client now provides SASL/Digest-MD5 authentication, privacy, and data integrity with SSL/TLS. If you require stronger authentication mechanisms such as Digest-MD5; then you must use pam_ldap. In addition, pam_ldap is designed to be extended for future authentication mechanisms that will be supported in future Solaris OE releases. One of the benefits of using pam_ldap, is it does not require passwords to be stored in any specific format, so you can store passwords using SSHA, SHA, or CRYPT formats.
For additional information, see the pam_ldap man page for the correct way to stack the authentication management for login service, and password management modules in the /etc/pam.conf configuration file.
NOTE
CRAM-MD5 is supported by the Secure LDAP client, but not by the Sun ONE Directory Server. However, Digest-MD5 is supported by both.