LDAP Naming Services Security Model

The 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. This section discusses the concepts of client identity, authentication methods, The pam_ldap 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 Oracle Solaris 11.1 Administration: Security Services) and pam_krb5(5) modules.

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

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 a host or user that is 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 directory information. For more information on ACIs, consult the Administration Guide for the version of Oracle Directory Server Enterprise Edition that you are using.

If the identity is based on the host that the request is coming from, then you are using proxy authentication. Once the host has been authenticated, all users on that host get access. If the identity is based on the user, then you are using per-user authentication. Each user on a host must be authenticated to get access.

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 log into a system, the PAM service may use information from the local machine, from the LDAP service, from a Kerberos server or some combination of the three to decide if the log in attempt will be successful. When the pam_kerb module is used, the decision to allow access is decided by the Kerberos server. When the pam_ldap module is used, half of the decision must come from the LDAP server and the other half comes from the local host. Information from the local host, using the pam_unix_* modules, the decision is made locally.

When you use pam_ldap to login using the LDAP service, 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 that is used to authenticate to the system is also used to authenticate to the directory for lookups and updates. Administrators can use access control information (ACI) in the directory to limit the results out of the naming service if desired.

Transport Layer Security

Transport layer security (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. 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 Oracle Directory Server Enterprise Edition for SSL, see the Administration Guide for the version of Oracle Directory Server Enterprise Edition 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 several levels with which to authenticate to a directory server.

• anonymous

• proxy

• proxy anonymous

• self (called per-user in this document)

LDAP anonymous Credential Level

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 allowed, as anyone could change information in the DIT to which they have write access, including another user's password, or their own identity.

---

LDAP proxy Credential Level

The client authenticates or binds to a single shared set of LDAP bind credentials, otherwise known as 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. The proxy account is a shared-per-system resource. That is, each user logged in to a system using proxy access, including the root user, sees the same results as all other users on that system. 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 LDAP Clients 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.

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

LDAP proxy anonymous Credential Level

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.

LDAP per-user Authentication

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.

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. The nscd daemon is not an optional component in this configuration.

enableShadowUpdate Switch

If the enableShadowUpdate switch is set to true on the client, the admin credentials will be used to update the shadow data. Shadow data is stored in the shadowAccount object class on the directory server. Admin credentials are defined by the values of the adminDN and adminPassword attributes, as described in Local LDAP Client Attributes. These admin credentials are not used for any other purpose.

Admin credentials have properties similar to Proxy credentials. The exception is that for admin credentials, the user must have all privileges for the zone or have an effective UID of root to read or update the shadow data. Admin credentials can be assigned to any entry that is allowed to bind to the directory. However, do not use the same directory manager identity (cn=Directory Manager) of the LDAP server.

This entry with admin credentials must have sufficient access to read and write the shadow data in the directory. Because the entry is a shared-per-system resource, the adminDN and adminPassword attributes must be configured on every client. The encrypted adminPassword is stored locally on the client. The password uses the same authentication methods that are configured for the client. The admin credentials are used by all users and processes on a given system to read and update the shadow data.

Credential Storage for LDAP Clients

If you configure a client to use a proxy identity, the client saves proxy information in the svc:/network/ldap/client service. The current LDAP implementation does not store proxy credentials in a client's profile. Any proxy credentials that are set by using ldapclient during initialization are stored in the SMF repository. 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.

Similarly, if you configure a client to enable shadow data updates, and the client credential level is not self, the client saves its information in the svc:/network/ldap/client service.

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. Therefore, for this type of configuration, you do not need to specify the adminDN and adminPassword attributes when the client is initialized with the ldapclient command.

Choosing Authentication Methods for the LDAP Naming Service

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 system 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. 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 Oracle Directory Server Enterprise Edition, 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 Oracle Directory Server Enterprise Edition, 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. This authentication method is obsolete and should not be used.

• 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 - Oracle Directory Server Enterprise Edition 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

Specifying Authentication Methods for Specific Services in LDAP

The authentication method can be specified for a given service in the serviceAuthenticationMethod attribute. The following services allow for the authentication method to be selected:

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

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 the pam_unix_*, pam_krb5, and pam_ldap_* modules.

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 Oracle Solaris 11.1 Administration: 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 the pam_ldap module is recommended over the use of the pam_unix_* modules when anonymous or proxy authentication methods are used.

pam_unix_* Service Modules

If you have not changed the /etc/pam.conf file, UNIX authentication is enabled by default.

Following is a list of the modules that provide the equivalent to the original pam_unix module.

The pam_unix_* modules follows the traditional model of UNIX authentication, as described in the following list.

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

2. The user is prompted for the user's 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 the pam_unix_* modules.

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

Kerberos Service Module

Refer to the pam_krb5(5) man page and Oracle Solaris 11.1 Administration: Security Services.

LDAP Service Module

When implementing LDAP authentication, 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.

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 UNIX authentication. 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.

---

The following table summarizes the main differences between authentication mechanisms.

Table 9-5 Authentication Behavior in LDAP

PAM and Changing Passwords

Use the passwd command to change a password. If the enableShadowUpdate switch is not set to true, the userPassword attribute must be writable by the user. If the enableShadowUpdate switch is set to true, the admin credentials must be able to update the userPassword attribute. Remember that the serviceAuthenticationMethod for passwd-cmd overrides the authenticationMethod for this operation. Depending on the authentication method that is used, the current password might be unencrypted on the wire.

In the case of UNIX authentication, 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.

If the enableShadowUpdate switch is set to true, the pam_unix_* modules also update the related shadow information when the user password is changed. The pam_unix_* modules update the same shadow fields in the local shadow files that the modules update when the local user password is changed.

The pam_ldap no longer supports password update. The 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 Oracle Directory Server Enterprise Edition, 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 Oracle Directory Server Enterprise Edition that you are using.

LDAP 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 Oracle Solaris 11.1 Administration: 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 Oracle Directory Server Enterprise Edition. You can configure pam_ldap(5) to support user account management. passwd(1) enforces password syntax rules set by the Oracle Directory Server Enterprise Edition password policy, when used with the proper PAM configuration.

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

Before configuring the password and account lockout policy on Oracle Directory Server Enterprise Edition, 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.

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

LDAP Account Management With the pam_unix_* Modules

If the enableShadowUpdate switch is set to true on the client, account management functionality that is available to local accounts is also available to LDAP accounts. Functionality includes password aging, account expiry and notification, failed login account locking, and so on. Also, the -dluNfnwx options to the passwd command are now supported in LDAP. Thus, the full functionality of the passwd command and the pam_unix_* modules in the files naming service is supported in the LDAP naming service. The enableShadowUpdate switch provides a way to implement consistent account management for users who are defined in both the files and the LDAP scope.

To prevent users from modifying their own account management data and thereby circumventing password policy, the LDAP server is configured to prevent user write access to the user's own shadow data on the server. An administrator with admin credentials performs the shadow data updates for a client system. Such a configuration, however, conflicts with the pam_ldap module, which requires that passwords be modifiable by users. Therefore, account management by the pam_ldap and the pam_unix_* modules are incompatible.

---

Caution - Do not use both the pam_ldap module and the pam_unix_* modules in the same LDAP naming domain. Either all clients use the pam_ldap module or all clients use the pam_unix_* modules. This limitation might indicate that you need a dedicated LDAP server. For example, a web or email application might expect users to change their own password on the LDAP server.

---

The implementation of enableShadowUpdate also requires that the admin credential (adminDN plus adminPassword) be stored locally on every client. This information is stored in the svc:/network/ldap/client service.

Unlike using pam_ldap for account management, using the pam_unix_* modules for account management does not require a change to the /etc/pam.conf file. The default /etc/pam.conf file is sufficient.