LDAP Naming Services Security Model

Introduction

Solaris LDAP naming services can use the LDAP repository in two different ways. One is as a source of both a naming service and an authentication service. The other is strictly as the source of naming data, using Kerberos as the enterprise-wide authentication system. This section discusses the concepts of client identity, authentication methods, pam_ldap(5) and pam_unix modules, and account management when the LDAP repository is used as both a naming service and authentication service. This section also discusses the use of LDAP naming services in conjunction with the Kerberos environment (Part VI, Kerberos Service, in System Administration Guide: Security Services) and pam_krb5(5) modules.

Note - Previously, if you enabled pam_ldap account management, all users needed to provide a login password for authentication any time they logged in to the system. Therefore, nonpassword-based logins using tools such as rsh, rlogin, or ssh would fail.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

pam_ldap(5) is now modified to do account management and retrieve the account status of users without authenticating to Directory Server as the user logging in. The new control to this on Directory Server is 1.3.6.1.4.1.42.2.27.9.5.8, which is enabled by default.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

Note - If you use Kerberos as your authentication system and integrate it with the LDAP naming system, you will be able to support a single sign on (SSO) environment in your enterprise through Kerberos. You will also be able to use that same identity system when querying LDAP naming data on a per-user or per-host basis.

To access the information 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 Administration Guide for the version of Sun Java System Directory Server that you are using.

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 the server. Once the client has established its identity, it can then make the various LDAP requests.

When you use pam_ldap there is a distinction between how the naming service and the authentication service (pam_ldap) access the directory. The naming service reads various entries and their attributes from the directory based on predefined identity. The authentication service establishes whether the user has entered the correct password by using that user's name and password to authenticate to the LDAP server. See the pam_ldap(5) man page for more information about the authentication service.

When Kerberos is used to perform authentication, and when authentication in LDAP naming services is also enabled (as is required for per-user mode), Kerberos can provide dual functions. Kerberos authenticates to the server and the Kerberos identity for the principal (user or host) is used to authenticate to the directory. In this way, the same user identity used to authenticate to the system is also used to authenticate to the directory for lookups. Administrators can use access control information (ACI) in the directory to limit the results out of the naming service if desired.

Transport Layer Security (TLS)

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

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 superset of the Secure Sockets Layer (SSL) protocol. Solaris LDAP naming services support TLS connections. Be aware that using SSL adds load to the directory server and the client.

You will need to set up your directory server for SSL. For more information about setting up Sun Java System Directory Server for SSL, see the Administration Guide for the version of Sun Java System Directory Server that you are using. You will also need to set up your LDAP client for SSL.

If using TLS, the necessary security databases must be installed. In particular, the certificate and key database files are needed. For example, if you adopt an older database format from Netscape Communicator, two files, cert7.db and key3.db, are required. Or if you use a new database format from Mozilla, three files, cert8.db, key3.db, and secmod.db are needed. The cert7.db or cert8.dbfile contains trusted certificates. The key3.dbfile contains the client's keys. Even if the LDAP naming service client does not use client keys, this file must be present. The secmod.db file contains the security modules such as the PKCS#11 module. This file is not required if the older format is used.

See Setting Up TLS Security for more information.

Assigning Client Credential Levels

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

anonymous
proxy
proxy anonymous
self (called per user in this document)

Anonymous

If you use anonymous access, you can access only the data that is available to everyone. In anonymous mode, an LDAP BIND operation does not take place. Also, you should consider the security implications. Allowing anonymous access for certain parts of the directory implies that anyone with access to the directory has read access. If you use an anonymous credential level, you need to allow read access to all the LDAP naming entries and attributes.

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

Note - Sun Java System Directory Server 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. For more information, see “Managing Access Control” in the Administration Guide for the version of Sun Java System Directory Server that you are using.

Proxy

The client authenticates or binds to the directory using a single 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. The proxy account is a shared-per-machine resource. That is, each user logged into a machine using proxy access, including the root user, sees the same results as all other users on that machine. You need to configure the proxyDN and proxyPassword on every client using the proxy credential level. The encrypted proxyPassword is 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, 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.

Note - 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, or they must use the per-user authentication model.

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.

Per User

Per-user (self) authentication uses the Kerberos identity (principal) to perform a lookup for each user or each system when authenticating to the directory server. With per-user authentication, the system administrator can use access control instructions (ACI's), access control lists (ACL's), roles, groups or other directory access control mechanisms to grant or deny access to specific naming service data for specific users or systems.

Note - When configuring per-user mode, the configuration value to enable this mode is “self,” which denotes per-user mode.

To use the per-user authentication model, the Kerberos single sign-on service must be deployed. In addition, the one or more directory servers used in the deployment must support SASL and the SASL/GSSAPI authentication mechanism. Because Kerberos expects to use files and DNS for host name lookups, instead of LDAP, DNS should be deployed in this environment. Also, to use per-user authentication, nscd must be enabled. Nscd is not an optional component in this configuration.

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 12, Setting Up LDAP Clients (Tasks) for more information on setting up client profiles.

If you configure a client to use per-user authentication, the Kerberos identity and Kerberos ticket information for each principal (each user or host) are used during authentication. In this environment the directory server maps the Kerberos principal to a DN and the Kerberos credentials are used to authenticate to that DN. The directory server can then use its access control instruction (ACI) mechanisms to allow or deny access to naming service data as necessary. In this situation, Kerberos ticket information is used to authenticate to the directory server and the system does not store authentication DNs or passwords on the system.

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 multivalued. 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 Java System 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 Java System 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 by 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 Java System Directory Server does not support cram-MD5.
sasl/GSSAPI
This authentication method is used in conjunction with the self credential mode to enable per-user lookups. A per-user nscd assigned to use the client's credentials binds to the directory server using the sasl/GSSAPI method and the client's Kerberos credentials. Access can be controlled in the directory server on a per-user basis.
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 Java System 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 9-4 Authentication Methods

	Bind	Password on wire	Password on Sun Java System Directory Server	Session
`none`	No	N/A	N/A	No encryption
`simple`	Yes	Clear	Any	No encryption
`sasl/digest-MD5`	Yes	Encryption	Clear	No encryption
`sasl/cram-MD5`	Yes	Encryption	N/A	No encryption
`sasl/GSSAPI`	Yes	Kerberos	Kerberos	Encryption
`tls:simple`	Yes	Encryption	Any	Encryption
`tls:sasl/cram-MD5`	Yes	Encryption	N/A	Encryption
`tls:sasl/digest-MD5`	Yes	Encryption	Clear	Encryption

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.

Note - In per-user mode, pam_krb5 (pam Kerberos) is used as the authentication service. ServiceAuthenticationMethod is not needed in this mode of operation.

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, including pam_unix, pam_krb5, and pam_ldap.

If the per-user authentication method is used, pam_krb5, the strongest authentication service of the three methods listed above, must be enabled. See pam_krb5(5) and the System Administration Guide: Security Services.

The pam_krb5 authentication system may be used even if per-user authentication is not enabled. If proxy or anonymous credential levels are used to access directory server data then restricting access to directory data on a per-user basis is not possible.

Because of its increased flexibility, support of stronger authentication methods, and ability to use account management, the use of pam_ldap is recommended over the use of pam_unix when anonymous or proxy authentication methods are used.

`pam_unix`

If you have not changed the pam.conf(4) file, pam_unix functionality is enabled by default.

Note - The pam_unix module has been removed and is no longer supported with Solaris. A set of other service modules provides equivalent or greater functionality. Therefore, in this guide, pam_unix refers to the equivalent functionality, not to the pam_unix module itself.

Following is a list of the modules that provide the equivalent pam_unix functionality.

pam_authtok_check(5)

pam_authtok_get(5)

pam_authtok_store(5)

pam_dhkeys(5)

pam_passwd_auth(5)

pam_unix_account(5)

pam_unix_auth(5)

pam_unix_cred(5)

pam_unix_session(5)

pam_unix follows the traditional model of UNIX authentication, as described in the following list.

The client retrieves the user's encrypted password from the name service.
The user is prompted for his password.
The user's password is encrypted.
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.

Note - pam_unix is not compatible with the sasl authentication method digest-MD5, since Sun Java System Directory Server requires passwords to be stored in the clear in order to use digest-MD5. pam_unix requires the password be stored in crypt format.

`pam_krb5`

Refer to pam_krb5(5) and the System Administration Guide: Security Services.

`pam_ldap`

When implementing pam_ldap, the user binds to the LDAP server by using the authentication method defined in pam_ldap's serviceAuthenticationMethod parameter, if one exists. Otherwise, authenticationMethod is used.

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

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config

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. Also, pam_ldap does not support the none authentication method. Thus, you must define the serviceAuthenticationMethod or the authenticationMethod attributes so clients can use pam_ldap. See the pam_ldap(5) man page for more information.

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

The following table summarizes the main differences between pam_unix, pam_ldap, and pam_krb5.

Table 9-5 `pam_unix` versus `pam_ldap` versus `pam_krb5`

	`pam_unix`	`pam_ldap`	`pam_krb5`
Password Sent	Uses `passwd` service authentication method	Uses `passwd` service authentication method	Uses Kerberos single sign on technology, not passwords
New Password Sent	Encrypted	No encryption (unless TLS is used)	Uses Kerberos, no passwords are sent over the wire
New Password Stored	`crypt` format	Password storage scheme defined on Sun Java System Directory Server	Passwords are managed via Kerberos
Requires password read?	Yes	No	No
`sasl/digest-MD5` compatibility after changing password	No. Password is not stored in `clear`. User cannot authenticate.	Yes. As long as default storage scheme is set to `clear`, user can authenticate.	No. sasl/GSSAPI is used. There are no passwords over the wire and there are no passwords to be stored in the directory server, except when using a Kerberos kdc that manages its password database in the LDAP directory server.

PAM and Changing Passwords

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

In the case of pam_unix, the new userPassword attribute is encrypted using UNIX crypt format 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. See the pam_authtok_store(5) man page for more information.

As of the Solaris 10 software release, pam_ldap no longer supports password update. The previously recommended use of pam_authtok_store with the server_policy option now replaces the pam_ldap password update capability. When you use pam_authtok_store, the new password is sent to the LDAP server in the clear. Therefore, to ensure privacy, use TLS. If TLS is not used, the new userPassword is subject to snooping. If you set an untagged password with Sun Java System Directory Server, the software encrypts the password by using the passwordStorageScheme attribute. For more information about the passwordStorageScheme, see the section on user account management in the Administration Guide for the version of Sun Java System Directory Server that you are using.

Note - You need to consider the following configuration issues 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 Java System Directory Server, passwordStorageScheme must be set to clear.

Account Management

If you select pam_krb5 as your account and password management system, the Kerberos environment will manage all your account, password, account lockout, and other account management details. Refer to pam_krb5(5) and the System Administration Guide: Security Services.

If you do not use pam_krb5, then LDAP naming services can be configured to take advantage of the password and account lockout policy support in Sun Java System Directory Server. You can configure pam_ldap(5) to support user account management. passwd(1) enforces password syntax rules set by the Sun Java System Directory Server password policy, when used with the proper PAM configuration.

The following account management features are supported through pam_ldap(5). These features depend on Sun Java System Directory Server'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.

Note - The preceding account management features only work with the Sun Java System Directory Server. For information about configuring the password and account lockout policy on the server, see the “User Account Management” chapter in the Administration Guide for the version of Sun Java System Directory Server that you are using. Also see Example pam_conf file for pam_ldap Configured for Account Management. Do not enable account management for proxy accounts.

Before configuring the password and account lockout policy on Sun Java System Directory Server, make sure all hosts use the “newest” LDAP client with pam_ldap account management.

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.

Now, however, pam_ldap(5), when used with Sun Java System Directory Servers DS5.2p4 and newer releases, enables users to log in with rsh, rlogin, rcp and ssh without giving a password.

To modify this control for other than default, add Access Control Instructions (ACI) on Directory Server:

dn: oid=1.3.6.1.4.1.42.2.27.9.5.8,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid:1.3.6.1.4.1.42.2.27.9.5.8
cn:Password Policy Account Usable Request Control
aci: (targetattr != "aci")(version 3.0; acl "Account Usable"; 
     allow (read, search, compare, proxy)
     (groupdn = "ldap:///cn=Administrators,cn=config");)
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=server,cn=plugins,cn=config