openldap/doc/guide/admin/referrals.sdf
Kurt Zeilenga 54248d8cbc ITS#708: Admin Guide -- more editing
More spelling, grammar, and stylistic fixups.
Submitted by Cedric Tefft <cedric@earthling.net>
2000-09-04 22:51:48 +00:00

127 lines
4.5 KiB
Plaintext

# $OpenLDAP$
# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Constructing a Distributed Directory Service
For many sites, running one or more {{slapd}}(8) that hold an
entire subtree of data is sufficient. But often it is desirable
to have one {{slapd}} refer to other directory services for a
certain part of the tree (which may or may not be running {{slapd}}).
!if 0
{{slapd}} supports {{subordinate}}, {{immediate superior}},
and {{superior}} knowledge information.
!else
{{slapd}} supports {{subordinate}} and {{superior}} knowledge information.
!endif
H2: Subordinate Knowledge Information
Subordinate knowledge information may be provided to delegate
a subtree.
Subordinate knowledge information is maintained in the directory
as a special {{referral}} 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 to be
constructed.
A referral object has a structural object class of
{{EX:referral}} and has the same {{TERM[expand]DN}} as the
delegated subtree. Generally, the referral object will also
provide the auxiliary object class {{EX:extensibleObject}}.
This allows the entry to contain appropriate {{TERM[expand]RDN}}
values. This is best demonstrated by example.
If the server {{EX:a.example.net}} holds {{EX:dc=example,dc=net}}
and wished to delegate the subtree {{EX:ou=subtree,dc=example,dc=net}}
to another server {{EX:b.example.net}}, the following named referral
object would be added to {{EX:a.example.net}}:
> dn: dc=subtree, dc=example, dc=net
> objectClass: referral
> objectClass: extensibleObject
> dc: subtree
> ref: ldap://b.example.net/dc=subtree,dc=example,dc=net/
The server uses this information to generate referrals and
search continuations to subordinate servers.
For those familiar with X.500, a {{named referral}} object is
similar to an X.500 knowledge reference held in a {{subr}}
{{TERM:DSE}}.
!if 0
H2: Immediate Superior Knowledge Information
Immediate superior knowledge information may be provided in the
entry at the root of a delegated subtree. The knowledge information
is contained with {{EX:ref}} operational attribute.
Extending the example above, a {{ref}} attribute can be added
to the entry {{EX:dc=subtree,dc=example,dc=net}} in server B indicating
that A holds the immediate superior naming context.
> dn: dc=subtree, dc=example, dc=net
> changetype: modify
> add: ref
> ref: ldap://a.example.net/
The server uses this information to generate referrals to
management operations.
For those familiar with X.500, this use of the {{EX:ref}} attribute
is similar to an X.500 knowledge reference held in a
{{immSupr}} {{TERM:DSE}}.
!endif
H2: Superior Knowledge Information
Superior knowledge information may be specified using the
{{EX:referral}} directive. The value is a list of {{TERM:URI}}s
referring to superior directory services. For servers without
immediate superiors, such as for {{EX:a.example.net}} in the example
above, the server can be configured to use directory service with
{{global knowledge}}, such as the {{OpenLDAP Root Service}}
({{URL:http://www.openldap.org/faq/index.cgi?file=393}}).
> referral ldap://root.openldap.org/
However, as {{EX:a.example.net}} is the {{immediate superior}}
to {{EX:b.example.net}}, {{a.example.net}} would be configured
as follows:
> referral ldap://a.example.net/
The server uses this information to generate referrals to
operations acting upon operations not within or subordinate
to any of the naming contexts held by the server.
For those familiar with X.500, this use of the {{EX:ref}} attribute
is similar to an X.500 knowledge reference held in a
{{Supr}} {{TERM:DSE}}.
H2: The ManageDsaIT Control
Adding, modifying, and deleting referral objects is generally done
using {{ldapmodify}}(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.
The -M option of {{ldapmodify}}(1) (and other tools) enables
ManageDsaIT. For example:
> ldapmodify -M -f referral.ldif -x -D "cn=Manager,dc=example,dc=net" -W
or with {{ldapsearch}}(1):
> ldapsearch -M -b "dc=example,dc=net" -x "(objectclass=referral)" '*' ref
Note: the {{EX:ref}} attribute is operational and must be explicitly
requested when desired in search results.