LDAP Naming Services Security Model

Introduction

Solaris LDAP naming services use the LDAP repository as a source of both a naming service and as an authentication service. This section discusses the concepts of client identity, authentication methods, pam_ldap(5) and pam_unix(5)modules, and password management.

To access the information stored in the LDAP repository, clients can first establish identity with the directory server. This identity can be either anonymous or as an object recognized by the LDAP server. Based on the client's identity and the server's Access Control Information (ACI), the LDAP server will allow the client to read or write directory information. For more information on ACIs, consult the Sun ONE Directory Server 5.1 Administrator's Guide.

If the client is connecting as anything other than anonymous for any given request, the client must prove its identity to the server using an authentication method supported by both the client and server. Once the client has established its identity, it can then make the various LDAP requests.

Keep in mind that there is a distinction between how the naming service and the authentication service (pam_ldap) authenticate to the directory. The naming service will read various entries and their attributes from the directory based on predefined identity. The authentication service (pam_ldap(5)) establishes whether the user has entered the correct password by using that user's name and password to authenticate to the LDAP server.

Transport Layer Security (TLS)

TLS can be used to secure communication between an LDAP client and the directory server, providing both privacy and data integrity. The TLS protocol is a super set of the Secure Sockets Layer (SSL) protocol. Solaris LDAP naming services support TLS connections. Be aware that using SSL will add load to the directory server and the client.

You will need to set up your directory server for SSL. See the Sun ONE Directory Server 5.1 Administrator's Guide for more information on setting up Sun ONE Directory Server 5.1 for SSL. You will also need to set up your LDAP client for SSL.

In order to use TLS for Solaris LDAP naming services, the directory server must use the default ports, 389 and 636, for LDAP and SSL, respectively. If your directory server does not use these ports, you cannot use TLS at this time.

See Setting Up TLS Security for more information.

Assigning Client Credential Levels

LDAP naming services clients authenticate to the LDAP server according to a credential level. LDAP clients can be assigned three possible credential levels with which to authenticate to a directory server.

• anonymous

• proxy

• proxy anonymous

Anonymous

If you use anonymous access, you only have access to data that is available to everyone. Also, you should consider the security implications. Allowing anonymous access for certain parts of the directory implies that anyone with access to the directory will be able to perform those operations. If you are using an anonymous credential level, you will need to allow read access to all the LDAP naming entries and attributes.

Allowing anonymous write to a directory should never be done, as anyone could change information in the DIT to which they have write access, including another user's password, or their own identity.

Sun ONE Directory Server 5.1 allows you to restrict access based on IP addresses, DNS name, authentication method, and time-of-day. You might want to limit access with further restrictions. See “Managing Access Control” in the Sun ONE Directory Server 5.1 Administrator's Guide for more information.

Proxy

The client authenticates or binds to the directory using a proxy account. This proxy account can be any entry that is allowed to bind to the directory. This proxy account needs sufficient access to perform the naming service functions on the LDAP server. You will need to configure the proxyDN and proxyPassword on every client using the proxy credential level. The encrypted proxyPassword will be stored locally on the client. You can set up different proxies for different groups of clients. For example, you can configure a proxy for all the sales clients to access both the company-wide-accessible and sales directories, while preventing sales clients from accessing human resource directories with payroll information. Or, in the most extreme cases, you can either assign different proxies to each client or assign just one proxy to all clients. A typical LDAP deployment would probably lie between the two extremes. Consider the choices carefully. Too few proxy agents might limit your ability to control user access to resources. However, having too many proxies complicates the setup and maintenance of the system. You need to grant the appropriate rights to the proxy user. This will vary depending on your environment. See Credential Storage for information on how to determine which authentication method makes the most sense for your configuration.

If the password changes for a proxy user, you need to update it on every client that uses that proxy user. If you use password aging on LDAP accounts, be sure to turn it off for proxy users.

Be aware that the proxy credential level applies to all users and processes on any given machine. If two users need to use different naming policies, they must use different machines.

In addition, if clients are using a proxy credential to authenticate, the proxyDN must have the same proxyPassword on all of the servers.

proxy anonymous

proxy anonymous is a multi-valued entry, in that more than one credential level is defined. A client assigned the proxy anonymous level will first attempt to authenticate with its proxy identity. If the client is unable to authenticate as the proxy user for whatever reason (user lockout, password expired, for example), then the client will use anonymous access. This might lead to a different level of service, depending on how the directory is configured.

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 (Task) 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. 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 5.1, 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.

• 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, which is supported by some, but not all directory servers. For instance, Sun ONE Directory Server 5.1 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.

Sun ONE Directory Server 5.1 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 careful that the userPassword attribute has the proper ACIs if it is stored in the clear, so that it is not readable.

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 bypasswd(1) to change the login password and password attributes.

• keyserv

  This service is used by thechkey(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).

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 and support of stronger authentication methods, the use of pam_ldap is recommended.

pam_unix(5)

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

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 if the user should be authenticated or not.

• 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.

pam_unix(5) is not compatible with sasl authentication method digest-MD5, since Sun ONE Directory Server 5.1 requires passwords to be stored in the clear in order to use digest-MD5, but pam_unix requires the password be stored in crypt format.

pam_ldap(5)

When usingpam_ldap(5), the user binds to the LDAP server. The authentication method is defined in pam_ldap's serviceAuthenticationMethod parameter if one exists. Otherwise, the authenticationMethod is used by default.

If pam_ldap(5) is able to bind to the server with the user's identity and supplied password, it authenticates the user.

pam_ldap(5) does not read the userPassword attribute. Therefore, there is no need to grant access to read the userPassword attribute unless there are other clients using pam_unix(5). pam_ldap(5) does not support the none authentication method. Thus, you must define the serviceAuthenticationMethod or the authenticationMethod attributes in order for clients to use pam_ldap(5).

If the simple authentication method is used, the userPassword attribute can be read on the wire by third parties.

See Example pam.conf File for pam_ldap.

PAM and Changing Passwords

Use passwd(1) to change a password. In order to change the password, the userPassword attribute must be writeable by the user. Remember that the serviceAuthenticationMethod for passwd-cmd will override the authenticationMethod for this operation. Depending on the authentication used, the current password might be un-encrypted on the wire.

In the case of pam_unix(5) the new userPassword attribute is encrypted using UNIX crypt and tagged before being written to LDAP. Therefore, the new password is encrypted on the wire, regardless of the authentication method used to bind to the server.

For pam_ldap, when a password is changed, the new password is un-encrypted. Therefore, to insure privacy, you need to use TLS. If TLS is not used, the new userPassword will be subject to snooping.

When setting the password with pam_ldap(5) with Sun ONE Directory Server 5.1, the password is encrypted using the serverStrorageScheme (as it is untagged). See “User Account Management” in the Sun ONE Directory Server 5.1 Administrator's Guide for additional information about the passwordStorageScheme attribute.

You need to consider the following when setting the passwordStorageScheme attribute. If a NIS, NIS+, or another client using pam_unix is using LDAP as a repository, then passwordStorageScheme needs to be crypt. Also, if using pam_ldap with sasl/digest-MD5 with Sun ONE Directory Server 5.1, passwrodStorageScheme must be set to clear.

Password Management

LDAP naming services take advantage of the password and account lockout policy support bin Sun ONE Directory Server 5.1. You can configurepam_ldap(5) to support user account management. passwd(1) enforces password syntax rules set by the Sun ONE Directory Server password policy, when used with the proper PAM configuration.

The following password management features are supported through pam_ldap(5). These features depend on Sun ONE Directory Server 5.1's password and account lockout policy configuration. You can enable as many or as few of the features as you want.

• Password aging and expiration notification

  Users must change their passwords according to a schedule. A password expires if it is not changed within the time configured. An expired password causes user authentication to fail.

  Users see a warning message whenever they log in within the expiration warning period. The message specifies the number of hours or days until the password expires.

• Password syntax checking

  New passwords must meet the minimum password length requirements. In addition, a password cannot match the value of the uid, cn, sn, or mail attributes in the user's directory entry.

• Password in history checking

  Users cannot reuse passwords. If a user attempts to change the password to one that was previously used, passwd(1) fails. LDAP administrators can configure the number of passwords kept in the server's history list.

• User account lockout

  A user account can be locked out after a given number of repeated authentication failures. A user can also be locked out if his account is inactivated by an administrator. Authentication will continue to fail until the account lockout time is passed or the administrator reactivates the account.

The preceding password management features only work with Sun ONE Directory Server 5.1 bundled with Solaris 9. For information about configuring the password and account lockout policy on the server, see the “User Account Management” chapter in the Sun ONE Directory Server 5.1 Administrator's Guide. Also see Example pam_conf file for pam_ldap Configured for Password Management.

Before configuring the password and account lockout policy on Sun ONE Directory Server 5.1, make sure all hosts use the “newest” LDAP client with pam_ldap password management. The “newest” version of the LDAP client is part of Solaris 9, update 2.

In addition, make sure the clients have a properly configured pam.conf(4) file. Otherwise, LDAP naming services will not work when proxy or user passwords expire.