Local Client Attributes
The following table lists the client attributes that can be set locally using ldapclient.
Table 13-3 Local Client Attributes
Attribute | Description |
|---|---|
domainName | Specifies the client's domain name (which becomes the default domain for the client machine). This has no default value and must be specified. |
proxyDN | The proxy's distinguished name. If the client machine is configured with credentialLevel of proxy, the proxyDN must be specified. |
proxyPassword | The proxy's password. If the client machine is configured with credentialLevel of proxy, the proxyPassword must be defined. |
certificatePath | The directory on the local file system containing the certificate databases. If a client machine is configured with authenticationMethod or serviceAuthenticationMethod using TLS, then this attribute is used. The default value is /var/ldap. |
Note - If the BaseDN in an SSD contains a trailing comma, it is treated as a relative value of the defaultSearchBase. The values of the defaultSearchBase is appended to the BaseDN before a search is performed.
ldap_cachemgr Daemon
ldap_cachemgr(1M) is a daemon that runs on LDAP client machines. It performs the following key functions.
It refreshes the client configuration information stored in the profiles on the server and pulls this data from the clients
It maintains a sorted list of active LDAP servers to use
It improves lookup efficiency by caching some common look-up requests submitted by various clients
It improves the efficiency of host lookups
Note - The ldap_cachemgr must be running at all times in order for LDAP naming services to work.
Refer to ldap_cachemgr(1M) for detailed information.
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.
Note - 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.
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 - 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.
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.
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.
-
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.
-
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.
Caution - 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.