Chapter 8 Planning Referrals

Referrals are an important mechanism that allow you to scale your directory service to extremely large proportions. Not every directory service will use referrals, but you should at least consider them when designing your directory service.

In this chapter you will learn about referrals. This chapter includes:

Referral Overview—This section introduces referrals and describes how and when the mechanism is used to redirect directory client requests.

Smart Referrals—This section introduces smart referrals, how they can be used, and when you should use them. This section also provides some brief advice and tips on how you should use smart referrals.

LDAP Client Referral Handling—This section describes how LDAP clients behave when a referral is returned to them in response to a directory query.

For example, if a directory client requests the directory entry uid=bjensen, ou=people, o=airius.com and the local machine is configured to manage only entries stored under the o=netscape.com tree, then a referral is returned to the client.

Referrals are not returned if:

• The client attempts to read an entry that could exist in the directory tree (the requested entry's DN suffix matches the directory DN suffix), but which simply does not exist or cannot be returned because of insufficient authority.
• The client attempts to modify (change or delete) an entry in the directory tree that does not exist or cannot be accessed because of insufficient authority.

Essentially, smart referrals allow you to map a directory entry or directory tree to a specific LDAP URL. This allows you to refer LDAP requests to:

• The same name space contained on a different server
• Different name spaces on the local server
• Different name spaces on the same server

ldap://europe.directory.airius.com:389/ou=people, o=airius.com

ldap://europe.directory.airius.com:389/ou=american employees, o=airius corporation

ldap:///o=airius.com

For information on LDAP URLS and on how to include smart URLs on Netscape Directory Server entries, see the Netscape Directory Server Administrator's Guide.

Smart Referral Usages

Because of their extreme flexibility, smart referrals allow you to scale your directory across multiple servers without physically containing those directory entries on each server in your enterprise. All that is needed is a referral from one entry in your local directory tree to an entry on some other server in your enterprise.

This referral mechanism is particularly useful for the following conditions:

• Enabling extranets—Smart referrals allow you to redirect directory lookup requests for your trading partners to your partner's public LDAP directory service. Of course, this has to be coordinated with your trading partners, but the potential still exists to allow users of your directory to easily find members of your partner's enterprise. A common usage of this is to allow people involved in joint, corporate ventures to find one another without having to replicate directory entries from one enterprise to another.
• Scaling—For extremely large enterprises, such as some national ISPs, referrals allow you to scale your directory service beyond the millions of directory entries that can be stored on a single Directory Server.
• Load balancing—In some situations, you may feel that replicating some directory entries to a specific Directory Server is inappropriate due to bandwidth or security constraints. However, you may also find that users of that remote directory service have an infrequent, but legitimate, need to access these same directory entries. Smart referrals allow those remote employees to locate the non-replicated entries simply by performing searches on their own local server.

Smart referrals are easy to use, but there are a few things to consider when using them:

• As always, keep it simple. Deploying your directory service in such a way that you have a tangled web of referrals will cause you administrative headaches. Also, over usage of smart referrals can lead to circular referral patterns. A circular referral is a situation in which a referral points to an LDAP URL, which in turn points to another LDAP URL, and so on until a referral somewhere in the chain points back to the original server:



• Limit your referral usage to handle redirection at a suffix level of a directory tree, or at least at a major branching point of your directory tree. One of the interesting aspects of smart referrals is that you can redirect lookup requests for leaf (non-branch) entries to other machines and completely different DNs entirely. As a result, you may be tempted to use smart referrals as an aliasing mechanism. However, this can quickly lead to a directory structure that is hard to manage and difficult to control, especially with regard to your security policy. By limiting referrals to the suffix or major branch points of your directory tree, you can limit the number of referrals that you have to manage, which in turn will significantly reduce your directory's administrative overhead.
• Access control does not cross referral boundaries. That is, if a type of access is allowed by one server, that same access is not automatically allowed by the referral server. Even if the server on which the request originated allows access to an entry, if the client is sent to another server using a smart referral then the server that actually contains the data must allow the directory access or the client's request cannot be fulfilled.

One limitation that is built into most clients that can follow referrals is the number of referrals, or hops, that the client will perform. Most clients are coded to limit the number of hops that they will perform to reduce the amount of time spent trying to serve a directory lookup request. This also helps to eliminate hung processes caused by circular referral patterns.

Netscape Client Referral Handling

When a Netscape LDAP client is returned a referral, by default the client automatically reformats the original LDAP request to fit the boundaries set by the referral, and then the client reissues the request. Thus, if you search for an entry starting at the search base of o=airius.com, and on that server, the branch ou=people, o=airius.com is a smart referral to:

ldap://directory.europe.airius.com/ou=people, l=europe, o=airius.com

then the client will automatically attempt to search the directory and tree represented by that URL. In this case, the search base is modified to fit the referral DN. The new search base will therefore become ou=people, l=europe, o=airius.com because that is the value included on the LDAP URL.

The success of this operation will depend on the permissions set at the remote directory, as well as the availability of the remote directory.

In similar fashion, if you attempt to modify an entry and you are referred to another LDAP URL, then the client will attempt to reformat the modification request to fit the boundaries set by the referral. For example, suppose you attempt the entry uid=bjensen, ou=people, o=airius.com. Further suppose that ou=people, o=airius.com contains a smart referral to:

ldap://directory.europe.airius.com/ou=people, o=airius corporation

Both the server and the name space have changed (o=airius.com is now o=airius corporation). In this case, the server reformats the original modification request to fit the new name space and reissues the request on the new server. Assuming that the client has sufficient privileges to perform the modification, the operation is performed without the user ever knowing that the activity occurred on a remote server.

This reformatting operation has its limitations. For example, suppose you were issuing the modification request for uid=bjensen, and the smart referral pointed to an LDAP URL such as:

ldap://directory.europe.airius.com/o=airius corporation

Notice that not only have the server and the name space changed, but that the referral is no longer pointing at the ou=people subtree. If uid=bjensen entry is contained at the root point of the remote server, then the request will be handled without any complications. However, if the entry is contained in some subtree on the remote server (such as ou=people) then the server will not be able to manage the request because it will not be able to find the uid=bjensen entry.

Therefore, to support directory modifications with smart referrals, make sure that at least one of the following two conditions are true:

• All the relevant servers maintain parallel directory structures from the suffix down.
• A smart referral from a subtree in one server, points to the appropriate branch point in a remote server. That is, if you have a smart referral from the ou=people tree on one server, and the remote server stores people entries in the ou=full time employees tree, then the smart referral should be (for example):

ldap://directory.europe.airius.com/ou=US employees, o=airius corporation