Sophie: openldap-doc-2.4.45-2.1.mga6 x86

openldap-doc-2.4.45-2.1.mga6.x86_64.rpm

<!doctype html public "-//W30//DTD W3 HTML 2.0//EN">

<HTML>

<!-- This file was generated using SDF 2.001 by
     Ian Clatworthy (ianc@mincom.com). SDF is freely
     available from http://www.mincom.com/mtr/sdf. -->

<HEAD>
<TITLE>OpenLDAP Software 2.4 Administrator's Guide: Constructing a Distributed Directory Service</TITLE>
</HEAD>
<BODY>

<DIV CLASS="header">
<A HREF="http://www.OpenLDAP.org/">
<P><IMG SRC="../images/LDAPlogo.gif" ALIGN="Left" BORDER=0></P>
</A>
<DIV CLASS="navigate">
<P ALIGN="Center"><A HREF="index.html">Contents</A> | <A HREF="index.html">Parent Topic</A> | <A HREF="tls.html">Previous Topic</A> | <A HREF="replication.html">Next Topic</A> <BR><A HREF="http://www.openldap.org/">Home</A> | <A HREF="../index.html">Catalog</A></P>
</DIV>
<BR CLEAR="Left">
</DIV>
<DIV CLASS="main">
<H1>17. Constructing a Distributed Directory Service</H1>
<P>For many sites, running one or more <EM>slapd</EM>(8) that hold an entire subtree of data is sufficient. But often it is desirable to have one <EM>slapd</EM> refer to other directory services for a certain part of the tree (which may or may not be running <EM>slapd</EM>).</P>
<P><EM>slapd</EM> supports <EM>subordinate</EM> and <EM>superior</EM> knowledge information. Subordinate knowledge information is held in <TT>referral</TT> objects (<A HREF="http://www.rfc-editor.org/rfc/rfc3296.txt">RFC3296</A>).</P>
<HR>
<H2><A NAME="Subordinate Knowledge Information">17.1. Subordinate Knowledge Information</A></H2>
<P>Subordinate knowledge information may be provided to delegate a subtree. Subordinate knowledge information is maintained in the directory as a special <EM>referral</EM> object at the delegate point. The referral object acts as a delegation point, gluing two services together. This mechanism allows for hierarchical directory services to be constructed.</P>
<P>A referral object has a structural object class of <TT>referral</TT> and has the same <TERM>Distinguished Name</TERM> as the delegated subtree.  Generally, the referral object will also provide the auxiliary object class <TT>extensibleObject</TT>. This allows the entry to contain appropriate <TERM>Relative Distinguished Name</TERM> values.  This is best demonstrated by example.</P>
<P>If the server <TT>a.example.net</TT> holds <TT>dc=example,dc=net</TT> and wished to delegate the subtree <TT>ou=subtree,dc=example,dc=net</TT> to another server <TT>b.example.net</TT>, the following named referral object would be added to <TT>a.example.net</TT>:</P>
<PRE>
        dn: dc=subtree,dc=example,dc=net
        objectClass: referral
        objectClass: extensibleObject
        dc: subtree
        ref: ldap://b.example.net/dc=subtree,dc=example,dc=net
</PRE>
<P>The server uses this information to generate referrals and search continuations to subordinate servers.</P>
<P>For those familiar with <TERM>X.500</TERM>, a <EM>named referral</EM> object is similar to an X.500 knowledge reference held in a <EM>subr</EM> <TERM>DSE</TERM>.</P>
<HR>
<H2><A NAME="Superior Knowledge Information">17.2. Superior Knowledge Information</A></H2>
<P>Superior knowledge information may be specified using the <TT>referral</TT> directive.  The value is a list of <TERM>URI</TERM>s referring to superior directory services.  For servers without immediate superiors, such as for <TT>a.example.net</TT> in the example above, the server can be configured to use a directory service with <EM>global knowledge</EM>, such as the <EM>OpenLDAP Root Service</EM> (<A HREF="http://www.openldap.org/faq/index.cgi?file=393">http://www.openldap.org/faq/index.cgi?file=393</A>).</P>
<PRE>
        referral        ldap://root.openldap.org/
</PRE>
<P>However, as <TT>a.example.net</TT> is the <EM>immediate superior</EM> to <TT>b.example.net</TT>, <EM>b.example.net</EM> would be configured as follows:</P>
<PRE>
        referral        ldap://a.example.net/
</PRE>
<P>The server uses this information to generate referrals for operations acting upon entries not within or subordinate to any of the naming contexts held by the server.</P>
<P>For those familiar with <TERM>X.500</TERM>, this use of the <TT>ref</TT> attribute is similar to an X.500 knowledge reference held in a <EM>Supr</EM> <TERM>DSE</TERM>.</P>
<HR>
<H2><A NAME="The ManageDsaIT Control">17.3. The ManageDsaIT Control</A></H2>
<P>Adding, modifying, and deleting referral objects is generally done using <EM>ldapmodify</EM>(1) or similar tools which support the ManageDsaIT control.  The ManageDsaIT control informs the server that you intend to manage the referral object as a regular entry.  This keeps the server from sending a referral result for requests which interrogate or update referral objects.</P>
<P>The ManageDsaIT control should not be specified when managing regular entries.</P>
<P>The <TT>-M</TT> option of <EM>ldapmodify</EM>(1) (and other tools) enables ManageDsaIT.  For example:</P>
<PRE>
        ldapmodify -M -f referral.ldif -x -D &quot;cn=Manager,dc=example,dc=net&quot; -W
</PRE>
<P>or with <EM>ldapsearch</EM>(1):</P>
<PRE>
        ldapsearch -M -b &quot;dc=example,dc=net&quot; -x &quot;(objectclass=referral)&quot; '*' ref
</PRE>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>the <TT>ref</TT> attribute is operational and must be explicitly requested when desired in search results.
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>the use of referrals to construct a Distributed Directory Service is extremely clumsy and not well supported by common clients. If an existing installation has already been built using referrals, the use of the <EM>chain</EM> overlay to hide the referrals will greatly improve the usability of the Directory system. A better approach would be to use explicitly defined local and proxy databases in <EM>subordinate</EM> configurations to provide a seamless view of the Distributed Directory.
<HR WIDTH="80%" ALIGN="Left"></P>
<P><HR WIDTH="80%" ALIGN="Left">
<STRONG>Note: </STRONG>LDAP operations, even subtree searches, normally access only one database. That can be changed by gluing databases together with the <B>subordinate</B>/<B>olcSubordinate</B> keyword. Please see <EM>slapd.conf</EM>(5) and <EM>slapd-config</EM>(5).
<HR WIDTH="80%" ALIGN="Left"></P>
<P></P>
</DIV>
<DIV CLASS="footer">
<HR>
<DIV CLASS="navigate">
<P ALIGN="Center"><A HREF="index.html">Contents</A> | <A HREF="index.html">Parent Topic</A> | <A HREF="tls.html">Previous Topic</A> | <A HREF="replication.html">Next Topic</A> <BR><A HREF="http://www.openldap.org/">Home</A> | <A HREF="../index.html">Catalog</A></P>
</DIV>
<P>
<FONT COLOR="#808080" FACE="Arial,Verdana,Helvetica" SIZE="1"><B>
________________<BR>
<SMALL>&copy; Copyright 2011, <A HREF="http://www.OpenLDAP.org/foundation/">OpenLDAP Foundation</A>, <A HREF="mailto:info@OpenLDAP.org">info@OpenLDAP.org</A></SMALL></B></FONT>

</DIV>

</BODY>
</HTML>