1 .TH SLAPD-LDAP 5 "RELEASEDATE" "OpenLDAP LDVERSION"
2 .\" Copyright 1998-2005 The OpenLDAP Foundation All Rights Reserved.
3 .\" Copying restrictions apply. See COPYRIGHT/LICENSE.
6 slapd-ldap \- LDAP backend to slapd
12 is not an actual database; instead it acts as a proxy to forward incoming
13 requests to another LDAP server. While processing requests it will also
14 chase referrals, so that referrals are fully processed instead of being
15 returned to the slapd client.
17 Sessions that explicitly Bind to the back-ldap database always create their
18 own private connection to the remote LDAP server. Anonymous sessions will
19 share a single anonymous connection to the remote server. For sessions bound
20 through other mechanisms, all sessions with the same DN will share the
21 same connection. This connection pooling strategy can enhance the proxy's
22 efficiency by reducing the overhead of repeatedly making/breaking multiple
25 The ldap database can also act as an information service, i.e. the identity
26 of locally authenticated clients is asserted to the remote server, possibly
27 in some modified form.
28 For this purpose, the proxy binds to the remote server with some
29 administrative identity, and, if required, authorizes the asserted identity.
33 The administrative identity of the proxy, on the remote server, must be
34 allowed to authorize by means of appropriate
43 options apply to the LDAP backend database.
44 That is, they must follow a "database ldap" line and come before any
45 subsequent "backend" or "database" lines.
46 Other database options are described in the
50 Note: It is strongly recommended to set
63 This is because operational attributes related to entry creation and
64 modification should not be used, as they could be passed to the target
65 servers, generating an error.
68 LDAP server to use. Multiple URIs can be set in in a single
70 argument, resulting in the underlying library automatically
71 call the first server of the list that responds, e.g.
73 \fBuri "ldap://host/ ldap://backup-host"\fP
75 The URI list is space- or comma-separated.
77 .\".B server <hostport>
78 .\"Obsolete option; same as `uri ldap://<hostport>/'.
80 .B acl-authcDN "<administrative DN for access control purposes>"
81 DN which is used to query the target server for acl checking; it
82 should have read access on the target server to attributes used on the
83 proxy for acl checking.
84 There is no risk of giving away such values; they are only used to
86 .B The acl-authcDN identity is by no means implicitly used by the proxy
87 .B when the client connects anonymously.
92 .B acl-passwd <password>
93 Password used with the bind DN above.
95 .B idassert-authcdn "<administrative DN for proxyAuthz purposes>"
96 DN which is used to propagate the client's identity to the target
97 by means of the proxyAuthz control when the client does not
98 belong to the DIT fragment that is being proxyied by back-ldap.
99 This is useful when operations performed by users bound to another
100 backend are propagated through back-ldap.
101 This requires the entry with
103 identity on the remote server to have
105 privileges on a wide set of DNs, e.g.
106 .BR authzTo=dn.subtree:"" ,
107 and the remote server to have
115 for details on these statements and for remarks and drawbacks about
118 .B idassert-passwd <password>
119 Password used with the proxy authzDN above.
121 .B idassert-mode <mode> [<flags>]
123 .I identity assertion
125 The supported modes are:
127 \fB<mode> := {legacy|anonymous|none|<id>|self}\fP
129 \fB<flags> := {override}\fP
131 \fB<id> := {u:<ID>|[dn:]<DN>}\fP
135 which implies that the proxy will bind as
137 and assert the client's identity when it is not anonymous.
138 Direct binds are always proxied.
139 The other modes imply that the proxy will always bind as
140 .IR idassert-authcdn ,
142 .BR idassert-authzFrom
143 rules (see below), in which case the operation will fail;
144 eventually, it will assert some other identity according to
146 Other identity assertion modes are
150 which respectively mean that the
157 which means that no proxyAuthz control will be used, so the
159 identity will be asserted.
160 Moreover, if a string prefixed with
166 that identity will be asserted.
167 Ths string is also treated as a DN if it is not prefixed
168 by any recognized type indicator. Whether or not the
170 prefix is present, the string must pass DN validation and normalization.
171 For all modes that require the use of the
173 control, on the remote server the proxy identity must have appropriate
175 permissions, or the asserted identities must have appropriate
177 permissions. Note, however, that the ID assertion feature is mostly
178 useful when the asserted identities do not exist on the remote server.
181 flag is used, identity assertion takes place even when the database
182 is authorizing for the identity of the client, i.e. after binding
183 with the provided identity, and thus authenticating it, the proxy
184 performs the identity assertion using the configured identity and
185 authentication method.
188 .B idassert-authzFrom <authz-regexp>
189 if defined, selects what
191 identities are authorized to exploit the identity assertion feature.
194 follows the rules defined for the
201 for details on the syntax of this field.
203 .B idassert-method <method> [<saslargs>]
204 where valid method values are
206 \fB<method> := {none|simple|sasl}\fP
208 \fB<saslargs> := [mech=<mech>] [realm=<realm>] [authcid=<authcid>] [cred=<cred>] [authz={native|proxyauthz}]\fP
212 extra parameters can be given as described above.
216 inhibits proxy authorization;
218 uses a SASL bind with the above parameters; if required,
220 is performed by means of native SASL mechanism, and no proxyAuthz
221 is used for subsequent operations.
225 Turns on proxying of the WhoAmI extended operation. If this option is
226 given, back-ldap will replace slapd's original WhoAmI routine with its
227 own. On slapd sessions that were authenticated by back-ldap, the WhoAmI
228 request will be forwarded to the remote LDAP server. Other sessions will
229 be handled by the local slapd, as before. This option is mainly useful
230 in conjunction with Proxy Authorization.
233 If this option is given, the client's bind credentials are remembered
234 for rebinds when chasing referrals.
236 .\".B suffixmassage <suffix> <massaged (remote) suffix>
237 .\"DNs ending with <suffix> in a request are changed to end with <remote
238 .\"suffix> before sending the request to the remote server, and <remote
239 .\"suffix> in the results are changed back to <suffix> before returning
240 .\"them to the client.
241 .\"The <suffix> field must be defined as a valid suffix
242 .\"for the current database.
244 .\".B map "{attribute | objectclass} [<local name> | *] {<foreign name> | *}"
245 .\"Map attribute names and object classes from the foreign server to
246 .\"different values on the local slapd.
247 .\"The reason is that some attributes might not be part of the local
248 .\"slapd's schema, some attribute names might be different but serve the
249 .\"same purpose, etc.
250 .\"If local or foreign name is `*', the name is preserved.
251 .\"If local name is omitted, the foreign name is removed.
252 .\"Unmapped names are preseved if both local and foreign name are `*',
253 .\"and removed if local name is omitted and foreign name is `*'.
256 .\"The rewrite options are described in the "REWRITING" section of the
257 .\".BR slapd-meta (5)
260 .B suffixmassage, map, rewrite*
261 These directives are no longer supported by back-ldap; their
262 functionality is now delegated to the
267 However, to ease update from existing configurations, back-ldap still
268 recognizes them and automatically instantiates the
270 overlay if available and not instantiated yet.
271 This behavior may change in the future.
273 .\"The following directives map the object class `groupOfNames' to
274 .\"the object class `groupOfUniqueNames' and the attribute type
275 .\"`member' to the attribute type `uniqueMember':
279 .\"map objectclass groupOfNames groupOfUniqueNames
280 .\"map attribute uniqueMember member
284 .\"This presents a limited attribute set from the foreign
289 .\"map attribute cn *
290 .\"map attribute sn *
291 .\"map attribute manager *
292 .\"map attribute description *
297 .\"These lines map cn, sn, manager, and description to themselves, and
298 .\"any other attribute gets "removed" from the object before it is sent
299 .\"to the client (or sent up to the LDAP server). This is obviously a
300 .\"simplistic example, but you get the point.
301 .SH PROXY CACHE OVERLAY
302 The proxy cache overlay
303 allows caching of LDAP search requests (queries) in a local database.
310 default slapd configuration file
314 .BR slapo\-pcache (5),
319 Howard Chu, with enhancements by Pierangelo Masarati