1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
# $OpenLDAP$
# Copyright 1999-2022 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.
Subordinate knowledge information is held in {{EX:referral}}
objects ({{REF:RFC3296}}).
!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 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 {{TERM: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 {{TERM: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 a 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}}, {{b.example.net}} would be configured
as follows:
> referral ldap://a.example.net/
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.
For those familiar with {{TERM: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 ManageDsaIT control should not be specified when managing regular
entries.
The {{EX:-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.
Note: 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
{{chain}} 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 {{subordinate}} configurations to
provide a seamless view of the Distributed Directory.
Note: LDAP operations, even subtree searches, normally access only one
database. That can be changed by gluing databases together with the
{{B:subordinate}}/{{B:olcSubordinate}} keyword. Please see {{slapd.conf}}(5)
and {{slapd-config}}(5).
|
