Credential Storage

If you configure a client to use a proxy identity, the client saves its proxyDN and proxyPassword in /var/ldap/ldap_client_cred. For the sake of increased security, this file is restricted to root access only, and the value of proxyPassword is encrypted. While past LDAP implementations have stored proxy credentials in a client's profile, Solaris 9 LDAP naming services do not. Any proxy credentials set using ldapclient during initialization are stored locally. This results in improved security surrounding a proxy's DN and password information. See Chapter 16, Setting Up Clients (Tasks) for more information on setting up client profiles.

Choosing Authentication Methods

When you assign the proxy or proxy-anonymous credential level to a client, you also need to select a method by which the proxy authenticates to the directory server. By default, the authentication method is none, which implies anonymous access. The authentication method may also have a transport security option associated with it.

The authentication method, like the credential level, may be multi-valued. For example, in the client profile you could specify that the client first tries to bind using the simple method secured by TLS. If unsuccessful, the client would try to bind with the sasl/digest-MD5 method. The authenticationMethod would then be tls:simple;sasl/digest-MD5.

LDAP naming services support some Simple Authentication and Security Layer (SASL) mechanisms. These mechanisms allow for a secure password exchange without requiring TLS. However, these mechanisms do not provide data integrity or privacy. See RFC 2222 for information on SASL.

The following authentication mechanisms are supported.

• none

  The client does not authenticate to the directory. This is equivalent to the anonymous credential level.

• simple

  If the client machine uses the simple authentication method, it binds to the server by sending the user's password in the clear. The password is thus subject to snooping unless the session is protected by ipsec(7). The primary advantages of using the simple authentication method are that all directory servers support it and that it is easy to set up.

• sasl/digest-MD5

  The client's password is protected during authentication, but the session is not encrypted. Some directory servers, including Sun ONE Directory Server, also support the sasl/digest-MD5 authentication method. The primary advantage of digest-MD5 is that the password does not go over the wire in the clear during authentication and therefore is more secure than the simple authentication method. See RFC 2831 for information on digest-MD5. digest-MD5 is considered an improvement over cram-MD5 for its improved security.

  When using sasl/digest-MD5, the authentication is secure, but the session is not protected.

  ---

  Note - If you are using Sun ONE Directory Server, the password must be stored in the clear in the directory.

  ---

• sasl/cram-MD5

  In this case, the LDAP session is not encrypted, but the client's password is protected during authentication, as authentication is performed using sasl/cram-MD5.

  See RFC 2195 for information on the cram-MD5 authentication method. cram-MD5 is only supported by some directory servers. For instance, Sun ONE Directory Server does not support cram-MD5.

• tls:simple

  The client binds using the simple method and the session is encrypted. The password is protected.

• tls:sasl/cram-MD5

  The LDAP session is encrypted and the client authenticates to the directory server using sasl/cram-MD5.

• tls:sasl/digest-MD5

  The LDAP session is encrypted and the client authenticates to the directory server using sasl/digest-MD5.

Caution - Sun ONE Directory Server requires passwords to be stored in the clear in order to use digest-MD5. If the authentication method is set to sasl/digest-MD5 or tls:sasl/digest-MD5, then the passwords for the proxy user will need to be stored in the clear. Be especially careful that the userPassword attribute has the proper ACIs if it is stored in the clear, so that it is not readable.

The following table summarizes the various authentication methods and their respective characteristics.

Table 13-4 Authentication Methods

Authentication and Services

The authentication method can be specified for a given service in the serviceAuthenticationMethod attribute. The following services currently support this.

• passwd-cmd

  This service is used by passwd(1) to change the login password and password attributes.

• keyserv

  This service is used by the chkey(1) and newkey(1M) utilities to create and change a user's Diffie-Hellman key pair.

• pam_ldap

  This service is used for authenticating users with pam_ldap(5).

  pam_ldap supports account management.

Note - If the service does not have a serviceAuthenticationMethod set, it will default to the value of the authenticationMethod attribute.

The following example shows a section of a client profile in which the users will use sasl/digest-MD5 to authenticate to the directory server, but will use an SSL session to change their password.

serviceAuthenticationMethod=pam_ldap:sasl/digest-MD5 serviceAuthenticationMethod=passwd-cmd:tls:simple

Pluggable Authentication Methods

By using the PAM framework, you can choose among several authentication services. You can use either pam_unix(5) or pam_ldap(5) in conjunction with LDAP.

Because of its increased flexibility, support of stronger authentication methods, and ability to use account management, the use of pam_ldap is recommended.

pam_unix

If you have not changed the pam.conf(4) file, pam_unix is enabled by default. pam_unix follows the traditional model of UNIX authentication, which means the following:

1. The client retrieves the user's encrypted password from the name service.

2. The user is prompted for his password.

3. The user's password is encrypted.

4. The client compares the two encrypted passwords to determine whether the user should be authenticated.

Additionally, there are two restrictions when using pam_unix.

• The password must be stored in UNIX crypt format and not in any other encryption methods, including clear.

• The userPassword attribute must be readable by the name service.

  For example, if you set the credential level to anonymous, then anyone must be able to read the userPassword attribute. Similarly, If you set the credential level to proxy, then the proxy user must be able to read the userPassword attribute.