Further Reading

Understanding and Deploying LDAP Directory Services > 9. Topology Design > Gluing the Directory Together: Knowledge References

<  BACK CONTINUE  >
153021169001182127177100019128036004029190136140232051053054012006220025159171193189181

Gluing the Directory Together: Knowledge References

So 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:

  • Immediate superior knowledge references.   This type of knowledge reference points upward in the DIT toward the root and ties the naming context to its ancestor. In effect, it provides the "hook" at the top of the directory partition that you use to hang a partition from its ancestor .

  • Subordinate references.   These knowledge references point downward in the DIT to other partitions. They are the hooks onto which you hang other naming contexts.

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 Directory

Now 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:

  • When locating the base object of an LDAP search or compare operation

  • When locating an entry to modify, delete, rename, or bind as

  • When locating the parent of an entry to be added to the directory

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.
  1. The directory client presents the purported name.

  2. Because Server 1 does not hold a naming context that could contain the entry, the immediate superior knowledge reference allows the name resolution process to walk up the tre e to Server 2.

  3. Server 2 contains a subordinate reference for the naming context ou=Engineering, dc=airius, dc=com , so the name resolution process walks down the tree to Server 3.

  4. Server 3 holds a subordinate reference for the naming context ou=PCB Design, ou=Engineering, dc=airius, dc=com , so the process walks down the tree again.

  5. Finally, Server 4 is consulted to check whether the entry actually exists.

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 Referrals

A 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:

  • Part 1: Resolve the name of the base object of the search.

    Step 1. The client submits the search request to Server 1.

    Step 2. Server 1 does not hold an appropriate naming context, so it examines the superior reference and returns to the client a referral to Server 2.

    Step 3. The client submits the search operation to Server 2.

    Step 4. Server 2 contains a subordinate reference to Server 3 for an appropriate naming context, so it returns to the client a referral to Server 3.

    Step 5. The client submits the search operation to Server 3.

  • Part 2: Service the search operation.

    Step 6. Server 3 searches its database and returns any matching entries to the client. Because it also contains a subordinate reference to server 4, it returns to the client a referral to Server 4.

    Step 7. The client submits the search operation to Server 4.

    Step 8. Server 4 returns any matching entries to the client.

    Step 9. The client combines the lists of entries returned from Server 3 and Server 4, and presents them to the user.

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 Referral

The 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:

  • The host name of the server to contact.

  • The port number of the server.

  • The base DN (if processing a search operation) or target DN (if processing an add , delete , compare , or moddn operation). This part is optional; if absent, the client should use the same base DN it used when performing the operation that resulted in the referral.

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 Chaining

Another 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:

  • Part 1: Resolve the name of the base object of the search

    Step 1. The client submits the search request to Server 1.

    Step 2. Server 1 does not hold an appropriate naming context, so it consults its immediate superior reference and chains the operation to Server 2.

    Step 3. Server 2 contains a subordinate reference to Server 3 for an appropriate naming context, so it chains the operation to Server 3.

    Step 4a. Server 3 verifies that the base object exists.

  • Part 2: Service the search operation.

    Step 4b. Server 3 searches its database for any matching entries. It also discovers that it holds a subordinate reference to Server 4, so it chains the operation to Server 4.

    Step 5. Server 4 searches its database and returns any matching entries to Server 3.

    Step 6. Server 3 combines the entries retrieved from its own database with those returned by Server 4 and sends the resulting set to Server 2.

    Step 7. Server 2 returns the set of entries to Server 1.

    Step 8. Server 1 returns the set of entries to the client.

    Step 9. The client presents the set of entries to the user.

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 Chaining

Each 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 Directory

The 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:

  • X.500.   X.500 servers based on the 1993 standard define a protocol for setting up and tearing down these relationships between servers. The actual protocol is known as the Hierarchical Operational Binding Protocol . As the name implies, it is used to establish a hierarchical relationship between two X.500 naming contexts and sets up the superior/subordinate references. Your software may not use this rather frightening terminology (in fact, one would hope not!); instead it may provide a more user-friendly interface for specifying partitions and how they relate to one another. Consult your server's documentation for specific procedures.

  • Novell Directory Services.   NDS, which is based on the X.500 standards, has a similar model, but it uses proprietary methods to establish new partitions and set up the hierarchical relationships between them. Novell's Partition Manager utility allows a manager to create new partitions and assign them to NDS servers.

  • Netscape Directory Server.   Netscape Directory Server requires that you manually configure the relationship of each server to other directory servers in your organization. As discussed previously, there are two types of knowledge information you can specify in the Netscape server. The default referral is given by the slapd.conf configuration file parameter named referral . You can configure the default referral through the Netscape Administration Server (in Netscape Directory Server 3.0) or the Netscape Console (in Netscape Directory Server 4.0). Smart referrals , also in the format of an LDAP URL, are stored within the directory itself. You manage smart referrals by using the ldapmodify command-line tool with the -M option (for manageDSAIT ) to add the auxiliary objectclass referral and ref attribute to a directory entry. This procedure is documented in the Netscape Directory Server Administration Guide .



Understanding and Deploying LDAP Directory Services,  2002 New Riders Publishing

<  BACK CONTINUE  >

Index terms contained in this section

chaining
          distributed 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.



Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 1997
Pages: 245

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net