Understanding and Deploying LDAP Directory Services > 9. Topology Design > Gluing the Directory Together: Knowledge References |
Gluing the Directory Together: Knowledge ReferencesSo far, we've described the directory partition in terms of the entries it contains. However, we still need some way to describe the relationships between directory partitions. The LDAP and X.500 standards define these relationships in terms of knowledge references ”pointers to directory information held in another partition. There are two types of knowledge references:
Figure 9.6 illustrates how directory partitions fit together into a larger DIT. In this example, the partition root ou=London, dc=airius, dc=com denotes the top of the partition. The partition contains the partition root and all the entries underneath it, except for those entries held in partitions pointed to by the two subordinate references, ou=Accounting, ou=London, dc=airius, dc=com and ou=Engineering, ou=London, dc=airius, dc=com . An immediate superior knowledge reference also points upward in the DIT, connecting this partition to its parent partition. Knowledge references always come in pairs; although not shown, the parent partition would thus have a subordinate reference pointing to the partition in the figure. Figure 9.6 A naming context in a DIT.Note Directory servers based on the LDAPv3 standard advertise the partitions they hold in a special entry called the root DSE (DSA-specific entry; DSA stands for Directory System Agent and is the X.500 term for a directory server). The root DSE is a special entry that contains information about the directory server, including its capabilities and configuration. To discover the partitions held by a given server, you can perform a search for the entry with a zero-length name , with a scope of base and a search filter of (objectclass=*) . The attribute namingContexts contained in the returned entry gives the partition roots of all partitions held by the server. Your directory server software may use these same terms, or it may have some alternative way of talking about how partitions are named and related . But in virtually all cases, this model is a good basis for understanding how your server software can be used to construct real-world directories. Dividing a directory in this fashion isn't useful all by itself. If we were to just leave the partitions as a series of isolated islands, locating an entry or searching across a series of partitions would be tedious . The user of the directory would need to know which servers to contact to perform an operation that spans multiple partitions. Clearly, directory partitions need to know about each other to work together as a single, cohesive unit. Name Resolution in the Distributed DirectoryNow that we understand partitions and knowledge references, the basic building blocks of a distributed directory, let's examine an important concept: name resolution . This is the process by which a directory maps a distinguished name (DN) provided by a client to an actual object in the directory. This process is used in the following circumstances:
A DN presented in this fashion is called a purported name . The client purports that it exists, and it is up to the directory system to check whether this is true. In the simplest case ”a client contacts a directory server and presents the DN of an entry contained in that server ”the name resolution process is quite simple: The server simply checks whether the entry exists and takes the appropriate action. For example, if a directory client attempts to read an entry via LDAP, the server checks whether the DN of the entry is within one of the naming contexts it holds; if it is, it checks its database for the entry. If the entry exists, any requested attributes are returned. Otherwise, a "no such object" error is returned to the client. If the client presents a purported name whose DN is not within any of the naming contexts held by a server, the server must use any available knowledge references either to resolve the name itself or aid the client in locating the server that can resolve the name. Conceptually, the name is resolved by "walking up" or "walking down" the directory tree until the appropriate server is located. The knowledge references fully describe how a given naming context fits into the DIT, so a server always knows whether the next step in the name resolution process involves walking up or walking down the DIT. For example, suppose that the directory client depicted in Figure 9.7 contacts Server 1 and presents the purported name cn=Barbara Jensen, ou=PCB Design, ou=Engineering, dc=airius, dc=com . Name resolution would proceed as follows : Figure 9.7 Name resolution in a distributed directory.
Up to this point, we've been discussing knowledge references and name resolution in an abstract sense, and you may be curious about the software in the directory system that actually performs this tree walking operation. To answer that, we'll discuss the specifics of how this knowledge reference "glue" works as we discuss the two methods directory servers use to carry out distributed operations: referrals and chaining. Gluing Together a Directory with ReferralsA referral is a piece of information returned by an LDAP server that indicates to the client that other servers need to be contacted to fulfill the request. The client then typically contacts the other servers, resubmits the original request, and presents the results to the user. Let's illustrate this with an example (see Figure 9.8). Suppose that an LDAP client issues a search operation to Server 1 with a search base of ou=Engineering, dc=airius, dc=com , a scope of subtree , and a filter of (& (objectclass=person)(sn=smith)) . In other words, the client wishes to find all persons within ou=Engineering dc=airius, dc=com whose surname is smith . Figure 9.8 Distributed searching with referrals.To service this search request, the distributed directory first uses name resolution to find the base object of the search. It then uses any knowledge references to refer the client to all the servers it needs to contact to obtain the entire set of matching entries. The following sequence describes this search procedure in greater detail:
This example shows how the directory, through the use of knowledge references, can direct a client to the correct servers ”even if the client happens to ask the wrong server. The Structure of an LDAP ReferralThe information in an LDAP referral is in the format of an LDAP uniform resource locator (URL), as defined in RFC 2255. A referral gives the following information:
This information is all that is required for the client to chase the referral. For example, if a client searches the subtree dc=airius, dc=com for all entries with a surname smith (as in the preceding example), the referral would be returned as the following LDAP URL: ldap://server1.airius.com:389/ou=Engineering, dc=airius, dc=com This LDAP URL indicates that the client should contact the host server1.airius.com on port 389 and submit a search rooted at ou=Engineering, dc=airius, dc=com to collect the rest of the search results. Notice that the base DN in the referral is different from the one originally supplied by the client. When a server issues a referral in this manner, it is indicating to the client that, in addition to contacting a different server, it must also search another part of the DIT to complete the search processing. By contrast, referrals issued in response to update operations normally contain either the same target DN specified in the original operation or no target DN at all, which have the same effect. The method for configuring referrals depends on your particular directory server software. For Netscape Directory Server, there are two places you configure referrals. The default referral is returned when an operation submitted by a client is based at a DN that is not contained within any of the server's naming contexts. For example, if a server holds only the naming context dc=airius, dc=com , and a client performs a search rooted at the DN dc=acme, dc=com , the server will return the default referral. Generally you configure the default referral to point to a directory server that has more knowledge about the directory partitioning arrangement at your site. The default referral functions like an immediate superior knowledge reference. The other type of referral supported by the Netscape Directory Server, a smart referral , is essentially a subordinate reference. The smart referral is stored in the ref attribute of a directory entry and gives the LDAP URLs of other directory servers that have knowledge of the subtree whose DN is the same as the DN of the entry containing the smart referral. Note that the entry must have an auxiliary objectclass of referral in order to permit storage of the ref attribute. Smart referrals are being standardized as part of the LDAPv3 extensions process. In Figure 9.9, a client that performs a search rooted at dc=airius, dc=com is returned any matching entries held within Server 1, along with a referral to Server 2. The client then automatically follows this referral and presents the complete list of matching entries to its user. In this way, smart referrals can be used to glue together a set of cooperating servers into a single, logical directory tree. Figure 9.9 Placement of a smart referral in a directory entry.Tip Support for LDAP referrals is standardized as part of the LDAPv3 specification. Servers and clients based on the older U-M LDAPv2 source code distribution support an experimental implementation of referrals that is incompatible with the LDAPv3 standard. The Netscape Directory Server operates with both v2 or v3 clients by sending LDAPv3-format referrals to LDAPv3 clients and LDAPv2-format referrals to LDAPv2 clients . Note If you are developing an application using either the Netscape C LDAP software development kit (SDK) or the Netscape Java LDAP SDK, you can either instruct SDK to automatically follow, or "chase," referrals (the default), or you can tell it to pass referral information back to your program for action. One reason you might not want to automatically chase referrals is if you want to provide feedback to the user indicating that a referral is being followed. Or, you might want to warn the user if a referral outside your corporate firewall is returned. As a developer, you have total control over how your application handles referrals. Good directory client software even allows the end user to configure whether referrals should be automatically followed and how to handle authentication when following referrals. Because these smart referrals are stored as attributes in directory entries, you might ask how it's possible to manage these attributes. Won't the directory just return a referral when you attempt to manipulate them? To manage the ref attribute, your client needs to include the manageDSAIT LDAP control along with the operation. This control is an extra piece of information sent by the client to the server informing it that the operation intends to manipulate these types of attributes. With the Netscape command-line LDAP tools, include the -M command-line flag to cause the manageDSAIT control to be included with the request. You must, of course, have sufficient access to perform this operation. Note Where does the term manageDSAIT come from? In X.500 terminology, the DSA information tree, or DSAIT, is the set of entries held by a particular X.500 server. This set of entries includes the actual directory entries that users can retrieve, but it also includes additional entries needed to attach the server's tree to the global directory namespace and additional attributes within entries that control the behavior of the directory. These entries and attributes are not normally visible to users. When an administrator manipulates these entries and attributes, he is managing the DSA Information Tree ”hence, the name manageDSAIT . Gluing Together a Directory with ChainingAnother way to glue together directory partitions is through the use of chaining . When this approach is used, the client starts by submitting an operation to a server in the usual way. If the server is unable to completely process the request because it does not hold all the required data, it contacts other servers on behalf of the client. It then returns the combined results to the client when the other servers have completed the operation. Figure 9.10 shows how a directory distributed using chaining would respond to the same query shown in Figure 9.8. Figure 9.10 Distributed searching with chaining.When using chaining, servers perform the following steps to service a search operation:
As you can see, the same number of steps is involved when chaining and referrals are used. In both cases, the knowledge information is stored in the directory itself. The major difference is the location of the intelligence that knows how to locate the distributed information. In a chained system, this intelligence is implemented in the servers; in a system that uses referrals, this intelligence is implemented in the clients. Deciding Between Referrals and ChainingEach method of linking distributed directory servers has advantages and disadvantages. Chaining generally reduces client complexity, but at the cost of increased server complexity. Servers that support chaining must be able to collect search results from remote servers and send the resulting set to directory clients. Referrals, on the other hand, require more client complexity to handle the chasing of referrals and collation of search results. Referrals do, however, offer more flexibility for client applications writers and allow a developer to provide the user of the application more feedback about the progress of a distributed directory operation. You may not have a choice about which method you use if your directory server supports only one method. Typically, standalone directory servers, such as the Netscape Directory Server, support only referrals. In fact, servers based on the LDAPv3 protocol specification must support referrals. However, there is nothing in the LDAP protocol specification that precludes chaining. Servers based on X.500 standards usually support chaining and may also support referrals. The X.500 specification does not actually mandate that servers support chaining, so the type of distribution method (chaining or referrals) again depends on the software in use. Consult your server software documentation to determine which methods are supported and recommended. Putting Knowledge Information into Your DirectoryThe procedure by which you get this knowledge information into your directory depends on the type of directory server software you are using. The following are the three most common types of directory service software:
|
Index terms contained in this sectionchainingdistributed directory name resolution 2nd 3rd 4th vs. referrals 2nd chasing referrals (SDK) default referrals 2nd design topologies directory service software 2nd 3rd knowledge references 2nd 3rd 4th 5th 6th name resolution 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th directories topologies directory service software 2nd 3rd knowledge references 2nd 3rd 4th 5th 6th name resolution 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th distibuted directories topologies directory service software 2nd 3rd knowledge references 2nd 3rd 4th 5th 6th name resolution 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th DNs resolving topolgoies 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th Hierarchical Operational Binding Protocol (X.500) host names referrals immediate superior knowledge references knowledge references topologies 2nd immediate superior root DSE entry subordinate 2nd LDAPv3 referral support manageDSAIT LDAP control 2nd name resolution topologies 2nd 3rd 4th 5th chaining 2nd 3rd 4th referrals 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th referrals vs. chaining 2nd NDS (Novell Directory Services) 2nd Netscape Directory Server default referrals smart referrals 2nd 3rd manageDSAIT LDAP control 2nd Novell Directory Services, see NDS port numbers servers referrals purported names, see name resolution referrals distributed directory name resolution 2nd 3rd 4th 5th 6th 7th defaults LDAPv3 support SDK chases smart referrals 2nd 3rd 4th 5th vs. chaining 2nd root DSE entry topology knowledge preferences SDKs chasing referrals servers host names referrals NDS (Novell Directory Services) Netscape Directory Server port numbers referrals X.500 2nd smart referrals 2nd 3rd 4th manageDSAIT LDAP control 2nd software directory service 2nd 3rd NDS (Novell Directory Services Netscape Directory Server X.500 2nd subordinate knowledge references 2nd topologies directory service software 2nd 3rd NDS (Novell Directory Services) Netscape Directory Server X.500 2nd knowledge references 2nd immediate superior 2nd 3rd root DSE entry name resolution 2nd 3rd 4th 5th chaining 2nd 3rd 4th referrals 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th referrals vs. chaining 2nd X.500 2nd name resolution chaining |
2002, O'Reilly & Associates, Inc. |