To set up the LDAP naming service, you must first plan the configuration of the LDAP client profile. The default values of the profile attributes suffice for most networks. However, based on the network topology, you might specify non-default values for some profile attributes. This section describes the different attributes that you might want to configure.
When planning the LDAP network model, you must determine the physical servers to be deployed for the LDAP naming service. To ensure availability and performance, each subnet of the network must have one LDAP server to service the LDAP clients in that subnet. When planning for this model, you should consider the following factors:
Number of systems to be deployed as LDAP servers
Which servers are designated master servers, and which servers are replicas that serve as backups?
The manner of access to the servers
Should all the LDAP servers have equal priority for access by LDAP client requests? Or, should the servers have different priorities and those with higher priorities be accessed first? If access to the servers is not equal, list the order in which these servers are accessed.
The information that you specify is managed by the defaultServerList and preferredServerList attributes. Note the following guidelines for the server list:
Use LDAP servers, not a concentrator, balancer, or pool.
Use multiple LDAP servers.
If you are using SSL/TLS, the host names must match the certificate names.
Host names must resolve to IP addresses.
Timeout factors
Determine the timeout values as follows:
bindTimeLimit attribute determines how long a TCP connect request continues before the request is dropped.
searchTimeLimit attribute determines how long an LDAP search operation continues before the search is cancelled.
profileTTL attribute determines how often an LDAP client downloads profiles from the servers.
For example, in a slow network, you might increase the length of time for searching and for allowing TCP connect requests. In a development environment, you might limit the frequency of downloading a profile by an LDAP client.
The LDAP naming service uses a default directory information tree (DIT) to store information. The DIT is based on an LDAP schema.
The DIT consists of containers of information that are hierarchically structured. The structure follows the standard LDAP schema described in RFC 2307 and RFC 4876.
The default structure of the DIT suffices for most network setups to implement LDAP. With the default structure, you only need to determine the following:
The base node distinguished name (DN) of the tree that naming service will search for information about a specific domain. The defaultSearchBase attribute manages the base node information.
The scope of search that a naming service lookup functionality should perform. The scope can cover either only one level below the DN, or the entire subtree below the DN. This information is managed by the attribute defaultSearchScope.
A DIT can also have a more complicated structure for storing data. For example, you can store the data about user accounts in different parts of the DIT. You should determine how to customize the behavior of the search operation such as the base DN, the scope, and the filters to use that overrides the default search sequence. The customized search sequence information is managed by the attributes serviceSearchDescriptor, attributeMap, and objectclassMap. For a detailed explanation about customizing the search sequence operation, see Service Search Descriptors and Schema Mapping.
Multiple servers can serve a single DIT. In this setup, the subtrees of a DIT might be distributed across multiple servers. Therefore, you must further configure LDAP servers to redirect LDAP client requests to the appropriate LDAP servers which can provide the requested information. The followReferrals attribute manages the information about how to redirect LDAP client requests to the correct server.
Having a single LDAP server providing all the naming data for a specific domain is the typical and recommended setup. Even in this scenario, however, you can still configure the followReferrals attribute to direct LDAP clients to read-only replica servers for most of the information requests. Access to a master server to perform read and write operations is not typically provided. With a referral configuration, you prevent the master server from overload.
For the security of LDAP operations that process requests for directory information, consider the following:
The manner by which LDAP clients identify themselves to access information, which is determined by the credential level that you specify for the clients. The credential level is managed by the credentialLevel attribute, to which you can assign one of the following values:
anonymous
proxy
proxy anonymous
self
For detailed descriptions of each of these values, see Client Credential Levels.
The method of authenticating the LDAP client, which is managed by the authenticationMethod attribute. You can specify the authentication method by assigning one of the following options:
none
simple
sasl/digest-MD5
sasl/cram-MD5
sasl/GSSAPI
tls:simple
tls:sasl/cram-MD5
tls:sasl/digest-MD5
For detailed descriptions of each of these values, see Authentication Methods for the LDAP Naming Service.
In addition to the credential level to assign to LDAP clients as well as the authentication method to use, you should also consider the following:
Whether to use Kerberos and per-user authentication
Value to specify for the servers' passwordStorageScheme attribute
Setup of access control information
For more information about ACIs, consult the administration guide for the version of ODSEE that you are using.
Whether to use the pam_unix_* or pam_ldap module to perform LDAP account management
This consideration is related to whether the LDAP naming service is compatible with NIS.