System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

Chapter 14 Planning for the LDAP Naming Service

This chapter discusses the high-level planning you should do before beginning the server and client setup and installation process.

This chapter covers the following topics.

Overview

The LDAP client profile is a collection of configuration information an LDAP client uses to access the LDAP naming service information on the supporting LDAP server to provide LDAP naming services. In this chapter, we will use this center piece of the LDAP configuration to discuss the planning of the various aspects of the LDAP naming services. These include the network model, the Directory Information Tree, the security model, the default values of the various profile attributes, and finally, the preparation for data population.

Planning the Network Model

For availability and performance considerations, it would be best if each subnet of the company wide network has its own LDAP server to service all the LDAP clients in the subnet. Only one of them needs to be a master LDAP server. The rest could all be replicas of the master server.

To plan for the network configuration, consider how many servers are available, how would a client be able to get to the servers, and in what order should the servers be accessed. If there is one per subnet, we could use the defaultServerList attribute to list all the servers and have the LDAP client sort and manipulate the access order. If the servers need to be accessed in certain order due to speed or data management reasons, then we should use the preferredServerList attribute to define the fixed order of accessing the servers. Note that you might not want to put the master server on either of these lists to reduce the load on the master server.

In addition, you may find three more attributes worth consideration when planning for the server and network configuration. The bindTimeLimit attribute can be used to set the time-out value for a TCP connect request, the searchTimeLimit attribute can be used to set the time-out value for an LDAP search operation, and the profileTTL attribute is for controlling how often the LDAP client should download its profile from the servers. For a slow or unstable network, the bindTimeLimit and searchTimeLimit attribute may need a larger value than the defaults. For early stage testing of the deployment, you may want to reduce the value of the profileTTL attribute to have the clients pick up the frequent changes made to the profile stored in the LDAP servers.

Planning the Directory Information Tree (DIT)

As mentioned in the previous chapter, the LDAP naming services has a default Directory Information Tree (DIT) and the associated default schema. For example, the ou=people container contains the user account, password, and shadow information. The ou=hosts container contains information about systems in the network. Each entry in the ou=people container would be of objectclass posixAccount and shadowAccount. The default DIT is a well designed directory structure and is based on open standards. It should be sufficient for most of the naming service needs, and is recommended to be used without changes. If you choose to use the default DIT, the only thing you need to decide is from which node (base DN) on in the directory tree the naming service information will be searched for a given domain. This node is specified with the defaultSearchBase attribute. Additionally, you might want to set the defaultSearchScope attribute to tell the clients the scope of search a naming service lookup should perform. Is it just searching one level under the DN (one), or the entire subtree under the DN (sub)?

There are times, however, that more flexibility is needed for the LDAP naming service to either work with an existing DIT or handle a more complicated DIT with naming service data scattered around the directory tree. For example, user account entries may exist in different part of the tree. The serviceSearchDescriptor, attributeMap, and objectclassMap attributes in the client profile are designed to handle these situations.

A service search descriptor can be used to override the default search base, search scope, and search filter for a particular service. See Service Search Descriptors (SSDs) and Schema Mapping.

AttributeMap and ObjectclassMap attributes provide a way for schema mapping. They make it possible for the LDAP naming services to work with an existing DIT. You can map the posixAccount objectclass to an existing objectclass, myAccount, for example and attributes in the posixAccount objectclass to attributes in the myAccount objectclass.

Multiple Directory Servers

Multiple LDAP servers can serve one DIT. For example, some subtrees of the DIT reside on other LDAP servers. In this case, an LDAP server may refer the LDAP client to a different server for the naming data it knows about but is not in its own database. If you plan such a DIT configuration, you should set the clients' profile attribute followReferrals to indicate to the LDAP naming service to follow server referrals to continue naming service lookups. However, it is best to have all naming data for a given domain reside on a single directory server, if at all possible.

Referrals can be useful if you want to have clients access read-only replicas most of the time and follow referrals to a read/write master server only when necessary. In this way, the master server does not get overloaded with requests that could be handled by replicas.

Data Sharing With Other Applications

To make best use of LDAP, you should have a single LDAP entry for each logical entry. For example, for a user you can have not only company white page information, but also Solaris account information, and possibly application specific data. Since the posixAccount and shadowAccount are auxiliary object classes, they can be added to any entry in the directory. This will require careful planning, setup and administration.

Choosing the Directory Suffix

See the iPlanet Directory Server 5.1 Configuration chapter for information on how to chose an appropriate directory suffix.

Replica Servers

There are three different strategies to employ when setting up your replica servers.

Single-master

With single-master replication, only one master server for any given partition or non-partitioned network holds writable copies of directory entries. Any replica servers have read-only copies of the directory entries. While both replicas and masters can perform searches, compares and bind operations, only the master server can perform write operations.

The potential disadvantage to the single-master replication strategy is that master server is a single point of failure. If the master server goes down, none of the replicas can process write operations.

Floating-master

The floating master strategy is similar to the single master strategy in that there is only one master server with write capabilities at any given time for a given partition or non-partitioned network. However, when implementing the floating-master strategy, when the master server goes down, a replica is automatically transformed into a master server by way of an algorithm.

One potential disadvantage to the floating-master replication strategy is that if your network becomes partitioned and replicas on either side of the partition become masters, the process of reconciling the new masters can be very complicated if the network is rejoined.

Multi-master

With multi-master replication, there are multiple master servers with their own read-write copies of the directory entry data. While the multi-master strategy eliminates the problem of having a single point of failure, update conflicts can occur between servers. In other words, if an entry's attribute is modified around the same time on two masters, an update conflict resolution policy, such as “last writer wins” must be in place.

Refer to the iPlanet Directory Server 5.1 Administrator's Guide for information on how to set up replica servers.

Planning the Security Model

To plan for the security model, you should first consider what identity the LDAP client should be using to talk to the LDAP server, and if you want strong authentication to protect the user password flow across the wire, and/or if it is needed to encrypt the session between the LDAP client and the LDAP server to protect the LDAP data transmitted.

The credentialLevel and authenticationMethod attributes in the profile are used for this. There are three possible credential levels for credentialLevel: anonymous, proxy, and proxy anonymous. See LDAP Naming Service Security Model for a detailed discussion of LDAP naming service security concepts.

The main decisions you need to make when planning your security model are the following.

Planning Client Profiles and Default Attribute Values

By going through the previous planning steps (network model, DIT, and security model), you should have some ideas of what the values for the following profile attributes.

Out of the above attributes, only the cn, the defaultServerList and defaultSearchBase are required attributes. They have no default values. The rest are optional, and some have default values.

See Chapter 16, Client Setup (Task) for more information on setting up LDAP clients.

Planning the Data Population

To populate the LDAP server with the LDAP naming service data, after the LDAP server has been configured with the proper DIT and schema, it is best to use the new ldapaddent tool. This tool will create entries in LDAP containers from their corresponding /etc files. It can be used to populate data into the containers for the following type of data: aliases, auto_*, bootparams, ethers, group, hosts (including IPv6 addresses), netgroup, netmasks, networks, passwd, shadow, protocols, publickey, rpc, and services.

By default, ldapaddent reads from the standard input and adds this data to the LDAP container associated with the database specified on the command line. But an input file from which data should be read can be specified using the -f option.

The entries are stored in the directory based on the client's configuration, thus the client must be configured to use the LDAP naming service.

For better performance, the recommended order in which the databases should be loaded is as follows.

  1. passwd database followed by shadow database

  2. networks database followed by netmasks database

  3. bootparams database followed by ethers database

Note that when adding automounter entries, the database name is in the form of auto_* (for example, auto_home).

If you have /etc files from different hosts to be added to the LDAP server, you can either merge all of them into the same /etc file and then use ldapaddent on one host to add, or perform ldapaddent on the different hosts one by one, with the expectation that all these hosts are already configured as a LDAP client.

If your naming service data is already in a NIS server, and you want to move the data to the LDAP server for LDAP naming services, use the ypcat (or niscat) command to dump the NIS map into files and run ldapaddent against these files to add the data to the LDAP server.

For example, to add hosts information to the LDAP server do the following.


Example 14–1 How to add NIS information to an LDAP server

  1. Become superuser.

  2. Run ldapaddent.

    # ldapaddent -h ldap_server_name -D directory manager -f hosts.data \ hosts


In the above example, the directory_manager password would be stored in the clear when using simple authentication.

You can also populate your directory server with NIS+ data using the proper settings in rpc.nisd. See the Appendix, “Transitioning from NIS+ to LDAP” in System Administration Guide: Naming and Directory Services (FNS and NIS+).