git.sur5r.net Git - openldap/blob - doc/guide/admin/referrals.sdf

   1 # $OpenLDAP$
   2 # Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
   3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
   4
   5 H1: Constructing a Distributed Directory Service
   6
   7 For many sites, running one or more {{slapd}}(8) that hold an
   8 entire subtree of data is sufficient. But often it is desirable
   9 to have one {{slapd}}} refer to other directory services for a
  10 certain part of the tree (which may or may not be running {{slapd}}).
  11
  12 !if 0
  13 {{slapd}} supports {{subordinate}}, {{immediate superior}},
  14 and {{superior}} knowledge information.
  15 !else
  16 {{slapd}} supports {{subordinate}} and {{superior}} knowledge information.
  17 !endif
  18
  19
  20 H2: Subordinate Knowledge Information
  21
  22 Subordinate knowledge information may be provided to delegate
  23 a subtree.
  24 Subordinate knowledge information is maintained in the directory
  25 as a special {{referral}} object at the delegate point.
  26 The referral object acts as a delegation point, gluing two services
  27 together.
  28 This mechanism allows for hierarchical directory services to to be
  29 constructed.
  30
  31 A referral object has an structural object class of
  32 {{EX:referral}} and has the same {{TERM[expand]DN}} as the
  33 delegated subtree.  Generally, the referral object will also
  34 provide the auxiliary object class {{EX:extensibleObject}}.
  35 This allows the entry to contain appropriate {{TERM[expand]RDN}}
  36 values.  This is best demonstrated by example.
  37
  38 If the server {{EX:a.example.net}} holds {{EX:dc=example,dc=net}}
  39 and wished to delegate the subtree {{EX:ou=subtree,dc=example,dc=net}}
  40 to another server {{EX:b.example.net}}, the following named referral
  41 object would be added to {{a.example.net}}:
  42
  43 >       dn: dc=subtree, dc=example, dc=net
  44 >       objectClass: referral
  45 >       objectClass: extensibleObject
  46 >       dc: subtree
  47 >       ref: ldap://b.example.net/dc=subtree,dc=example,dc=net/
  48
  49 The server uses this information to generate referrals and
  50 search continuations to subordinate servers.
  51
  52 For those familiar with X.500, a {{named referral}} object is
  53 similar to an X.500 knowledge reference held in a {{subr}}
  54 {{TERM:DSE}}.
  55
  56 !if 0
  57 H2: Immediate Superior Knowledge Information
  58
  59 Immediate superior knowledge information may be provided in the
  60 entry at the root of a delegated subtree.  The knowledge information
  61 is contained with {{ref}} operational attribute.
  62
  63 Extending the example above, a {{ref}} attribute can be added
  64 to the entry {{EX:dc=subtree,dc=example,dc=net}} in server B indicating
  65 that A holds the immediate superior naming context.
  66
  67 >       dn: dc=subtree, dc=example, dc=net
  68 >       changetype: modify
  69 >       add: ref
  70 >       ref: ldap://a.example.net/
  71
  72 The server uses this information to generate referrals to
  73 management operations.
  74
  75 For those familiar with X.500, this use of the {{ref}} attribute
  76 is similar to an X.500 knowledge reference held in a
  77 {{immSupr}} {{TERM:DSE}}.
  78 !endif
  79
  80
  81 H2: Superior Knowledge Information
  82
  83 Superior knowledge information may be specified using the
  84 {{EX:referral}} directive.  The value is a list of {{TERM:URI}}s
  85 referring to superior directory services.  For servers without
  86 immediate superiors, such as for {{EX:a.example.net}} in the example
  87 above, the server can be configured to use directory service with
  88 {{global knowledge}}, such as the {{OpenLDAP Root Service}}
  89 (http://www.openldap.org/faq/index.cgi?file=393).
  90
  91 >       referral        ldap://root.openldap.org/
  92
  93 However, as {{EX:a.example.net}} is the {{immediate superior}}
  94 to {{EX:b.example.net}}, {{a.example.net}} would be configured
  95 as follows:
  96
  97 >       referral        ldap://a.example.net/
  98
  99 The server uses this information to generate referrals to
 100 operations acting upon operations not within or subordinate
 101 to any of the naming contexts held by the server.
 102
 103 For those familiar with X.500, this use of the {{ref}} attribute
 104 is similar to an X.500 knowledge reference held in a
 105 {{Supr}} {{TERM:DSE}}.
 106
 107 H2: ManageDSAit
 108
 109 Adding, modify, and deleting referral objects is generally done
 110 using {{ldapmodify}}(1) or similar tools which support the
 111 ManageDsaIT control.  The ManageDsaIT control informs the server
 112 that you intend to manage the referral object as a regular
 113 entry.  This keeps the server from sending a referral result
 114 for requests which interrogate or update referral objects.
 115 The -M option of {{ldapmodify}}(1) (and other tools) enables
 116 ManageDsaIT.  For example:
 117
 118 >       ldapmodify -M -f referral.ldif -x -D "cn=Manager,dc=example,dc=net" -W
 119
 120 or with {{ldapsearch}}(1):
 121
 122 >       ldapsearch -M -b "dc=example,dc=net" -x "(objectclass=referral)" '*' ref
 123
 124 Note: the {{EX:ref}} attribute is operational and must be explicitly
 125 requested when desired in search results.
 126