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: In early versions of back-ldap it was recommended to always 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.
66 The current implementation automatically sets ldapmod to off, so its use
67 is redundant and can be safely omitted.
70 LDAP server to use. Multiple URIs can be set in in a single
72 argument, resulting in the underlying library automatically
73 call the first server of the list that responds, e.g.
75 \fBuri "ldap://host/ ldap://backup-host"\fP
77 The URI list is space- or comma-separated.
79 .\".B server <hostport>
80 .\"Obsolete option; same as `uri ldap://<hostport>/'.
82 .B acl-authcDN "<administrative DN for access control purposes>"
83 DN which is used to query the target server for acl checking; it
84 is supposed to have read access on the target server to attributes used
85 on the proxy for acl checking.
86 There is no risk of giving away such values; they are only used to
88 .B The acl-authcDN identity is by no means implicitly used by the proxy
89 .B when the client connects anonymously.
94 .B acl-passwd <password>
95 Password used with the
100 .B idassert-authcdn "<administrative DN for proxyAuthz purposes>"
101 DN which is used to propagate the client's identity to the target
102 by means of the proxyAuthz control when the client does not
103 belong to the DIT fragment that is being proxyied by back-ldap.
104 This is useful when operations performed by users bound to another
105 backend are propagated through back-ldap.
106 This requires the entry with
108 identity on the remote server to have
110 privileges on a wide set of DNs, e.g.
111 .BR authzTo=dn.subtree:"" ,
112 and the remote server to have
120 for details on these statements and for remarks and drawbacks about
123 .B idassert-passwd <password>
124 Password used with the
128 .B idassert-mode <mode> [<flags>]
130 .I identity assertion
132 The supported modes are:
134 \fB<mode> := {legacy|anonymous|none|<id>|self}\fP
136 \fB<flags> := {override}\fP
138 \fB<id> := {u:<ID>|[dn:]<DN>}\fP
142 which implies that the proxy will bind as
144 and assert the client's identity when it is not anonymous.
145 Direct binds are always proxied.
146 The other modes imply that the proxy will always bind as
147 .IR idassert-authcdn ,
149 .BR idassert-authzFrom
150 rules (see below), in which case the operation will fail;
151 eventually, it will assert some other identity according to
153 Other identity assertion modes are
157 which respectively mean that the
164 which means that no proxyAuthz control will be used, so the
166 identity will be asserted.
167 Moreover, if a string prefixed with
173 that identity will be asserted.
174 Ths string is also treated as a DN if it is not prefixed
175 by any recognized type indicator. Whether or not the
177 prefix is present, the string must pass DN validation and normalization.
178 For all modes that require the use of the
180 control, on the remote server the proxy identity must have appropriate
182 permissions, or the asserted identities must have appropriate
184 permissions. Note, however, that the ID assertion feature is mostly
185 useful when the asserted identities do not exist on the remote server.
188 flag is used, identity assertion takes place even when the database
189 is authorizing for the identity of the client, i.e. after binding
190 with the provided identity, and thus authenticating it, the proxy
191 performs the identity assertion using the configured identity and
192 authentication method.
195 .B idassert-authzFrom <authz-regexp>
196 if defined, selects what
198 identities are authorized to exploit the identity assertion feature.
201 follows the rules defined for the
208 for details on the syntax of this field.
210 .B idassert-method <method> [<saslargs>]
211 where valid method values are
213 \fB<method> := {none|simple|sasl}\fP
215 \fB<saslargs> := [mech=<mech>] [realm=<realm>] [authcid=<authcid>] [cred=<cred>] [authz={native|proxyauthz}]\fP
219 extra parameters can be given as described above.
223 inhibits proxy authorization;
225 uses a SASL bind with the above parameters; if required,
227 is performed by means of native SASL mechanism, and no proxyAuthz
228 is used for subsequent operations.
232 Turns on proxying of the WhoAmI extended operation. If this option is
233 given, back-ldap will replace slapd's original WhoAmI routine with its
234 own. On slapd sessions that were authenticated by back-ldap, the WhoAmI
235 request will be forwarded to the remote LDAP server. Other sessions will
236 be handled by the local slapd, as before. This option is mainly useful
237 in conjunction with Proxy Authorization.
240 If this option is given, the client's bind credentials are remembered
241 for rebinds when chasing referrals. Useful in conjunction with
242 \fBchase-referrals\fP, useless if \fBdont-chase-referrals\fP is set.
246 .B dont-chase-referrals
248 enable/disable automatic referral chasing, which is delegated to the
249 underlying libldap, with rebinding eventually performed if the
250 \fBrebind-as-user\fP directive is used. The default is to chase referrals.
262 execute the start TLS extended operation when the connection is initialized;
263 only works if the URI directive protocol scheme is not \fBldaps://\fP.
264 The \fBtls-propagate\fP version issues the Start TLS exop only if the original
266 \fBtry-start-tls\fP and \fBtry-propagate-tls\fP continue operations
271 .B suffixmassage, map, rewrite*
272 These directives are no longer supported by back-ldap; their
273 functionality is now delegated to the
278 However, to ease update from existing configurations, back-ldap still
279 recognizes them and automatically instantiates the
281 overlay if available and not instantiated yet.
282 This behavior may change in the future.
287 backend does not honor all ACL semantics as described in
288 .BR slapd.access (5).
289 In general, access checking is delegated to the remote server(s).
294 pseudo-attribute and to the other attribute values of the entries
297 operation is honored, which is performed by the frontend.
299 .SH PROXY CACHE OVERLAY
300 The proxy cache overlay
301 allows caching of LDAP search requests (queries) in a local database.
308 default slapd configuration file
312 .BR slapo\-pcache (5),
317 Howard Chu, with enhancements by Pierangelo Masarati
projects / openldap / blob