Deciding Between Referrals and Chaining

Both methods of linking the directory partitions have advantages and disadvantages. The method, or combination of methods, to use depends upon the specific needs of the directory service.

knows how to locate the distributed information. In a chained system, the intelligence is implemented in the servers. In a system that uses referrals, the intelligence is implemented in the client application. While chaining reduces client complexity, it does so at the cost of increased server complexity. Chained servers must work with remote servers and send the results to directory clients.

With referrals, the client must handle locating the referral and collating search results. However, referrals offer more flexibility for the writers of client applications and allow developers to provide better feedback to users about the progress of a distributed directory operation.

The following sections describe some of the more specific differences between referrals and chaining in greater detail.

6.3.3.1. Usage Differences

Some client applications do not support referrals. Chaining allows client applications to communicate with a single server and still access the data stored on many servers. Sometimes referrals do not work when a company's network uses proxies. For example, a client application may have permissions to

communicate with only one server inside a firewall. If that application is referred to a different server, it is not able to contact it successfully.

A client must also be able to authenticate correctly when using referrals, which means that the servers to which clients are being referred need to contain the client's credentials. With chaining, client

authentication takes place only once. Clients do not need to authenticate again on the servers to which their requests are chained.

6.3.3.2. Evaluating Access Controls

Chaining evaluates access controls differently from referrals. With referrals, an entry for the client must exist on all of the target servers. With chaining, the client entry does not need to be on all of the target servers.

Performing Search Requests Using Referrals

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

Figure 6.11. Sending a Client Request to a Server Using Referrals

In the illustration above, the client application performs the following steps: 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's entry from Server A. Performing Search Requests Using Chaining

The problem of replicating client entries across servers is resolved using chaining. On a chained system, the search request is forwarded multiple times until there is a response.

Figure 6.12. Sending a Client Request to a Server Using Chaining

In the illustration above, the following steps are performed:

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, which 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's 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.

Figure 6.13. Authenticating a Client and Retrieving Data Using Different Servers

In this illustration, the following steps are performed:

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, which 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's request using another database link. The database link contacts a remote data store located on Server C to process the search operation. Unsupported Access Controls

Database links do not support the following access controls:

Controls that must access the content of the user entry are not supported when the user entry is located on a different server. This includes access controls based on groups, filters, and roles. Controls based on client IP addresses or DNS domains may be denied. This is because the database link impersonates the client when it contacts remote servers. If the remote database contains IP-based access controls, it evaluates them using the database link's domain rather than the original client domain.