LDAP Naming Service Security Model

Introduction

The Solaris LDAP naming service uses 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 and pam_unix 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 iPlanet 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) which 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. The Solaris LDAP naming service supports TLS connections. Be aware that using SSL will add load to the directory server and the client.

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

In order to use TLS for the Solaris LDAP naming service, 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 TLS Security Setup for more information.

Assigning Client Credential Levels

LDAP naming service 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.

The iPlanet 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 iPlanet 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 setup 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 and 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 the 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 the following section 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 will 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 lock out, 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, the Solaris 9 LDAP does 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, Client Setup (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.

The LDAP naming service supports 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 advantage of using the simple authentication method is 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 the iPlanet 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, the iPlanet Directory Server 5.1 does not supportcram-MD5.

• tls:simple

  The client binds using 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.

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

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 or pam_ldap in conjunction with LDAP.

Because of its increased flexibility and support of stronger authentication methods, 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 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 is not compatible with sasl authentication method digest-MD5, since the iPlanet 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

When using pam_ldap, 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 is able to bind to the server with the user's identity and supplied password, it authenticates the user.

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

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

See An example pam.conf file for pam_ldap.

PAM and Changing Passwords

Use the 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 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 with the iPlanet Directory Server 5.1, the password is encrypted using the serverStrorageScheme (as it is untagged). See “User Account Management” in the iPlanet 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 the iPlanet Directory Server 5.1, passwrodStorageScheme must be set to clear.

Password Management

Solaris LDAP naming services does not currently support the password management features in iPlanet Directory Server 5.1.