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 replication
Floating-master replication
Multi-master replication

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.

What credential level and authentication methods will LDAP clients use?
Will you use TLS?
Do you need to be backwards compatible with NIS or NIS+? In other words, will clients use pam_unix or pam_ldap?
What will the servers' passwordStorageScheme attribute settings be?
How will you set up the Access Control Information? For more information on ACIs, consult the iPlanet Directory Server 5.1 Administrator's Guide.


	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" "Planning the Network Model" "Planning the Directory Information Tree (DIT)" "Replica Servers" "Planning the Security Model" "Planning Client Profiles and Default Attribute Values" "Planning the Data Population" 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 replication Floating-master replication Multi-master replication 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. What credential level and authentication methods will LDAP clients use? Will you use TLS? Do you need to be backwards compatible with NIS or NIS+? In other words, will clients use `pam_unix` or `pam_ldap`? What will the servers' `passwordStorageScheme` attribute settings be? How will you set up the Access Control Information? For more information on ACIs, consult the iPlanet Directory Server 5.1 Administrator's Guide.