Chapter 5. Designing the directory topology

Directory Server stores data in Lightning Memory-Mapped Databases (LMDB). Each database consists of a set of large files that contain all the data assigned to it.

You can store different portions of the directory trees in different databases. For example, your directory tree can appear in the following way:

Figure 5.1. Example directory tree

The directory in the example consist of following three sub-suffixes:

You can store the data of the three sub-suffixes in three separate databases in the following way:

Figure 5.2. Storing suffix data in separate databases

When you divide the directory tree among several databases, you can distribute these databases across multiple servers to reduce the workload on each server. For example, you can store three databases (DB1, DB2, and DB3) on two servers (Server A and Server B).

Figure 5.3. Dividing suffix databases between separate servers

Server A contains DB1 and DB2, and Server B contains DB3.

Directory Server supports adding databases dynamically, without stopping the entire directory service.

A database contains the data for a specific suffix (a portion of the directory tree). In Directory Server, you can create a root suffix or sub-suffix.

For example, ExampleCom creates suffixes to represent the distribution of its directory data in the following way:

Figure 5.4. Directory tree for ExampleCom

ExampleCom spreads its directory tree across four different databases in the following way:

Figure 5.5. Directory tree spread across multiple databases

The four databases contain the data for the following suffixes:

Figure 5.6. Directory tree with multiple root suffixes

The ISP creates the following root suffixes:

Directory Server returns all referrals in the format of an LDAP URL. The LDAP URL contains the following information:

For example, a client application searches though dc=example,dc=com branch for entries with the surname Jensen. However, a part of the directory tree is stored on the European server. A referral returns the following LDAP URL to the client application:

ldap://europe.example.com:389/ou=people,l=europe,dc=example,dc=com

This referral instructs the client application to contact the host europe.example.com on port 389 and submit a new search though the European branch ou=people,l=europe,dc=example,dc=com.

The LDAP client application you use determines how a referral is handled. Some client applications automatically retry the operation on the server to which they have been referred. Other client applications return the referral information to the user. Most LDAP client applications that Red Hat Directory Server provides, such as the command-line utilities, automatically follow the referral. Directory Server uses the same bind credentials supplied on the initial directory request to access the server.

Most client applications follow a limited number of referrals, or hops. The limit on the number of referrals reduces the time a client application spends trying to complete a directory lookup request and helps to eliminate hung processes caused by circular referral patterns.

Directory Server returns a default referral to clients when the server or database that was contacted does not contain the requested data.

For example, a client requests the following directory entry: uid=bjensen,ou=people,dc=example,dc=com.

However, the server only manages entries stored under the dc=europe,dc=example,dc=com suffix. The directory returns a referral to the client with information which server to contact for entries stored under the dc=example,dc=com suffix. The client then contacts the appropriate server and resubmits the original request.

You can configure default referrals at the server and suffix levels:

In addition to default referrals, Directory Server supports smart referrals that associate a directory entry or directory tree with a specific LDAP URL. Therefore, Directory Server can forward client requests to any of the following:

Unlike default referrals, Directory Server stores smart referrals within the directory, and not in the configuration file.

For example, the directory for the American office of the ExampleCom contains the ou=people,dc=example,dc=com directory branch point.

To redirect requests on this branch to the ou=people branch of the European office of ExampleCom you can specify a smart referral on the ou=people entry itself. The smart referral has the following value:

ldap://europe.example.com:389/ou=people,dc=example,dc=com

The requests to the ou=people branch of the American directory are redirected to the European directory in the following way:

Figure 5.7. Using smart referrals to redirect requests

You can use the same mechanism to redirect queries to a different server that uses a different namespace. For example, an employee working in the Italian office of ExampleCom makes a request to the European directory service for the phone number of an ExampleCom employee in America. Directory Server returns the following referral:

ldap://america.example.com:389/ou=people,dc=example,dc=com

The following diagram shows how a referral to a different namespace works:

Figure 5.8. Redirecting a query to a different server and namespace

Finally, when serving multiple suffixes on the same server, you can redirect queries from one namespace to another served on the same server. For example, to redirect all queries for o=example,c=us on the local server to dc=example,dc=com, set the smart referral ldap:///dc=example,dc=com on the o=example,c=us entry. The third slash in the LDAP URL indicates that the URL points to the same server.

Consider the following points before using smart referrals:

Figure 5.9. A circular referral pattern

Chaining evaluates access controls differently from referrals. With referrals, a client entry (bind DN) must exist on all of the target servers. With chaining, the client entry does not need to be on all of the target servers.

5.6.1.1. Performing search requests using referrals

The following diagram shows a client request to a server using referrals:

Figure 5.11. Sending a client request to a server using referrals

A search request occurs in the following way:

1. The client application first binds with Server A.
2. Server A contains an entry for the client that provides a user name and password, so it returns a bind acceptance message. In order for the referral to work, the client entry must be present on Server A.
3. The client application sends the operation request to Server A.
4. However, Server A does not contain the requested information. Instead, Server A returns a referral to the client application instructing it to contact Server B.
5. The client application then sends a bind request to Server B. To bind successfully, Server B must also contain an entry for the client application.
6. The bind is successful, and the client application can now resubmit its search operation to Server B.

This approach requires Server B to have a replicated copy of the client entry from Server A.

5.6.1.2. Performing search requests using chaining

You can resolve the problem of replicating client entries across servers through chaining.

Figure 5.12. Sending a client request to a server using chaining

A search request occurs in the following way:

1. The client application binds with Server A, and Server A tries to confirm that the user name and password are correct.
2. Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to Server B that contains the actual entry of the client. Server A sends a bind request to Server B.
3. Server B sends an acceptance response to Server A.
4. Server A then processes the client application request using the database link. The database link contacts a remote data store located on Server B to process the search operation.

In a chained system, the entry corresponding to the client application does not need to be located on the same server as the data the client requests. The following diagrams shoes how two chained servers can be used to complete a client search request.

Figure 5.13. Authenticating a client and retrieving data using two different servers

A search request occurs in the following way:

1. The client application binds with Server A, and Server A confirms that the user name and password are correct.
2. Server A does not contain an entry corresponding to the client application. Instead, it contains a database link to Server B that contains the actual entry of the client. Server A sends a bind request to Server B.
3. Server B sends an acceptance response to Server A.
4. Server A then processes the client request using another database link. The database link contacts a remote data store located on Server C to process the search operation.

Directory Server supports the following index types:

Consider the following points when using indexes to improve search performance: