1SLAPD.ACCESS(5)               File Formats Manual              SLAPD.ACCESS(5)
2
3
4

NAME

6       slapd.access  -  access  configuration  for slapd, the stand-alone LDAP
7       daemon
8

SYNOPSIS

10       /etc/openldap/slapd.conf
11

DESCRIPTION

13       The slapd.conf(5)  file  contains  configuration  information  for  the
14       slapd(8)  daemon.  This  configuration  file  is also used by the SLAPD
15       tools  slapacl(8),  slapadd(8),  slapauth(8),  slapcat(8),   slapdn(8),
16       slapindex(8), and slaptest(8).
17
18       The  slapd.conf  file  consists  of  a  series  of global configuration
19       options that apply to slapd as a whole (including all  backends),  fol‐
20       lowed  by zero or more database backend definitions that contain infor‐
21       mation specific to a backend instance.
22
23       The general format of slapd.conf is as follows:
24
25           # comment - these options apply to every database
26           <global configuration options>
27           # first database definition & configuration options
28           database    <backend 1 type>
29           <configuration options specific to backend 1>
30           # subsequent database definitions & configuration options
31           ...
32
33       Both the global configuration and  each  backend-specific  section  can
34       contain access information.  Backend-specific access control directives
35       are used for those entries that belong to  the  backend,  according  to
36       their naming context.  In case no access control directives are defined
37       for a backend or those which are defined are not applicable, the direc‐
38       tives from the global configuration section are then used.
39
40       If no access controls are present, the default policy allows anyone and
41       everyone to read anything but  restricts  updates  to  rootdn.   (e.g.,
42       "access to * by * read").
43
44       When  dealing  with  an  access list, because the global access list is
45       effectively appended to each per-database list, if the  resulting  list
46       is non-empty then the access list will end with an implicit access to *
47       by * none directive. If there are no access directives applicable to  a
48       backend, then a default read is used.
49
50       Be warned: the rootdn can always read and write EVERYTHING!
51
52       For  entries  not  held in any backend (such as a root DSE), the global
53       directives are used.
54
55       Arguments that should be replaced by actual text are shown in  brackets
56       <>.
57

THE ACCESS DIRECTIVE

59       The structure of the access control directives is
60
61       access to <what> [ by <who> [ <access> ] [ <control> ] ]+
62              Grant  access (specified by <access>) to a set of entries and/or
63              attributes (specified by  <what>)  by  one  or  more  requestors
64              (specified by <who>).
65
66
67       Lists  of  access  directives are evaluated in the order they appear in
68       slapd.conf.  When a <what> clause matches the  datum  whose  access  is
69       being evaluated, its <who> clause list is checked.  When a <who> clause
70       matches the accessor's properties, its <access> and  <control>  clauses
71       are evaluated.  Access control checking stops at the first match of the
72       <what> and <who> clause, unless otherwise  dictated  by  the  <control>
73       clause.  Each <who> clause list is implicitly terminated by a
74
75            by * none stop
76
77       clause that results in stopping the access control with no access priv‐
78       ileges granted.  Each <what> clause list is implicitly terminated by a
79
80            access to *
81                 by * none
82
83       clause that results in granting no access privileges  to  an  otherwise
84       unspecified datum.
85

THE <WHAT> FIELD

87       The  field  <what>  specifies  the  entity the access control directive
88       applies to.  It can have the forms
89
90            dn[.<dnstyle>]=<dnpattern>
91            filter=<ldapfilter>
92            attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
93
94       with
95
96            <dnstyle>={{exact|base(object)}|regex
97                 |one(level)|sub(tree)|children}
98            <attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
99            <attrstyle>={{exact|base(object)}|regex
100                 |one(level)|sub(tree)|children}
101
102       The statement dn=<dnpattern> selects the entries based on their  naming
103       context.  The <dnpattern> is a string representation of the entry's DN.
104       The wildcard * stands for all the entries, and it is implied if  no  dn
105       form is given.
106
107       The  <dnstyle> is optional; however, it is recommended to specify it to
108       avoid ambiguities.  Base (synonym of baseObject), the default, or exact
109       (an alias of base) indicates the entry whose DN is equal to the <dnpat‐
110       tern>; one (synonym of onelevel) indicates all the entries  immediately
111       below  the  <dnpattern>, sub (synonym of subtree) indicates all entries
112       in the subtree at the <dnpattern>, children indicates all  the  entries
113       below (subordinate to) the <dnpattern>.
114
115       If  the  <dnstyle>  qualifier  is  regex,  then  <dnpattern> is a POSIX
116       (''extended'') regular expression  pattern,  as  detailed  in  regex(7)
117       and/or re_format(7), matching a normalized string representation of the
118       entry's DN.  The regex form of  the  pattern  does  not  (yet)  support
119       UTF-8.
120
121       The  statement filter=<ldapfilter> selects the entries based on a valid
122       LDAP filter as described in RFC 4515.  A filter of  (objectClass=*)  is
123       implied if no filter form is given.
124
125       The  statement  attrs=<attrlist> selects the attributes the access con‐
126       trol rule applies to.  It is a comma-separated list of attribute types,
127       plus  the  special  names entry, indicating access to the entry itself,
128       and children, indicating access to the  entry's  children.  ObjectClass
129       names  may  also  be  specified in this list, which will affect all the
130       attributes that are required and/or allowed by that objectClass.  Actu‐
131       ally,  names  in <attrlist> that are prefixed by @ are directly treated
132       as objectClass names.  A name prefixed by !   is  also  treated  as  an
133       objectClass,  but  in  this case the access rule affects the attributes
134       that are not required nor allowed by that  objectClass.   If  no  attrs
135       form  is given, attrs=@extensibleObject is implied, i.e. all attributes
136       are addressed.
137
138       Using the form attrs=<attr>  val[/matchingRule][.<attrstyle>]=<attrval>
139       specifies  access to a particular value of a single attribute.  In this
140       case, only a single attribute type may be given. The <attrstyle>  exact
141       (the  default)  uses  the attribute's equality matching rule to compare
142       the value, unless a different (and compatible) matching rule is  speci‐
143       fied.  If  the  <attrstyle>  is  regex, the provided value is used as a
144       POSIX (''extended'') regular expression pattern.  If the attribute  has
145       DN  syntax,  the  <attrstyle>  can be any of base, onelevel, subtree or
146       children, resulting in  base,  onelevel,  subtree  or  children  match,
147       respectively.
148
149       The  dn, filter, and attrs statements are additive; they can be used in
150       sequence to select entities the access rule applies to based on  naming
151       context, value and attribute type simultaneously.  Submatches resulting
152       from regex matching can be dereferenced in the <who>  field  using  the
153       syntax  ${v<n>}, where <n> is the submatch number.  The default syntax,
154       $<n>, is actually an alias for ${d<n>}, that corresponds to dereferenc‐
155       ing submatches from the dnpattern portion of the <what> field.
156

THE <WHO> FIELD

158       The  field  <who>  indicates  whom the access rules apply to.  Multiple
159       <who> statements can appear in an access control statement,  indicating
160       the different access privileges to the same resource that apply to dif‐
161       ferent accessee.  It can have the forms
162
163            *
164            anonymous
165            users
166            self[.<selfstyle>]
167
168            dn[.<dnstyle>[,<modifier>]]=<DN>
169            dnattr=<attrname>
170
171            realanonymous
172            realusers
173            realself[.<selfstyle>]
174
175            realdn[.<dnstyle>[,<modifier>]]=<DN>
176            realdnattr=<attrname>
177
178            group[/<objectclass>[/<attrname>]]
179                 [.<groupstyle>]=<group>
180            peername[.<peernamestyle>]=<peername>
181            sockname[.<style>]=<sockname>
182            domain[.<domainstyle>[,<modifier>]]=<domain>
183            sockurl[.<style>]=<sockurl>
184            set[.<setstyle>]=<pattern>
185
186            ssf=<n>
187            transport_ssf=<n>
188            tls_ssf=<n>
189            sasl_ssf=<n>
190
191            dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
192
193       with
194
195            <style>={exact|regex|expand}
196            <selfstyle>={level{<n>}}
197            <dnstyle>={{exact|base(object)}|regex
198                 |one(level)|sub(tree)|children|level{<n>}}
199            <groupstyle>={exact|expand}
200            <peernamestyle>={<style>|ip|ipv6|path}
201            <domainstyle>={exact|regex|sub(tree)}
202            <setstyle>={exact|expand}
203            <modifier>={expand}
204            <name>=aci          <pattern>=<attrname>]
205
206       They may be specified in combination.
207
208       The wildcard * refers to everybody.
209
210       The keywords prefixed by real act as their counterparts without prefix;
211       the  checking  respectively  occurs  with the authentication DN and the
212       authorization DN.
213
214       The keyword  anonymous  means  access  is  granted  to  unauthenticated
215       clients;  it is mostly used to limit access to authentication resources
216       (e.g.  the  userPassword  attribute)  to  unauthenticated  clients  for
217       authentication purposes.
218
219       The keyword users means access is granted to authenticated clients.
220
221       The  keyword  self  means  access  to  an entry is allowed to the entry
222       itself (e.g. the entry being accessed and the requesting entry must  be
223       the  same).   It  allows the level{<n>} style, where <n> indicates what
224       ancestor of the DN is to be used in matches.  A  positive  value  indi‐
225       cates  that the <n>-th ancestor of the user's DN is to be considered; a
226       negative value indicates that the <n>-th ancestor of the target  is  to
227       be  considered.   For  example,  a  "by self.level{1} ..." clause would
228       match   when   the   object   "dc=example,dc=com"   is   accessed    by
229       "cn=User,dc=example,dc=com".   A  "by  self.level{-1} ..." clause would
230       match  when   the   same   user   accesses   the   object   "ou=Address
231       Book,cn=User,dc=example,dc=com".
232
233       The  statement dn=<DN> means that access is granted to the matching DN.
234       The optional style qualifier dnstyle allows the same choices of the  dn
235       form  of  the  <what>  field.  In addition, the regex style can exploit
236       substring substitution of submatches in the <what> dn.regex  clause  by
237       using  the  form  $<digit>,  with  digit  ranging  from 0 to 9 (where 0
238       matches the entire string), or the  form  ${<digit>+},  for  submatches
239       higher than 9.  Substring substitution from attribute value can be done
240       in using the form ${v<digit>+}.  Since the dollar character is used  to
241       indicate  a substring replacement, the dollar character that is used to
242       indicate match up to the end of the string must be escaped by a  second
243       dollar character, e.g.
244
245           access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
246               by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
247
248       The  style qualifier allows an optional modifier.  At present, the only
249       type allowed is expand, which causes  substring  substitution  of  sub‐
250       matches  to  take  place  even  if dnstyle is not regex.  Note that the
251       regex dnstyle in the above example may be  of  use  only  if  the  <by>
252       clause needs to be a regex; otherwise, if the value of the second (from
253       the right) dc= portion of the DN in the above example were  fixed,  the
254       form
255
256           access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
257               by dn.exact,expand="uid=$2,dc=example,dc=com" write
258
259       could  be  used; if it had to match the value in the <what> clause, the
260       form
261
262           access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
263               by dn.exact,expand="uid=$2,dc=$3,dc=com" write
264
265       could be used.
266
267       Forms of the <what> clause other than regex may provide  submatches  as
268       well.   The  base(object), the sub(tree), the one(level), and the chil‐
269       dren forms  provide  $0  as  the  match  of  the  entire  string.   The
270       sub(tree),  the  one(level),  and the children forms also provide $1 as
271       the match of the rightmost part of the DN  as  defined  in  the  <what>
272       clause.  This may be useful, for instance, to provide access to all the
273       ancestors of a user by defining
274
275           access to dn.subtree="dc=com"
276               by dn.subtree,expand="$1" read
277
278       which means that only access to entries that appear in the  DN  of  the
279       <by> clause is allowed.
280
281       The  level{<n>}  form  is  an  extension  and  a  generalization of the
282       onelevel form, which matches all DNs whose <n>-th ancestor is the  pat‐
283       tern.   So, level{1} is equivalent to onelevel, and level{0} is equiva‐
284       lent to base.
285
286       It is perfectly useless to give any access  privileges  to  a  DN  that
287       exactly  matches  the rootdn of the database the ACLs apply to, because
288       it implicitly possesses write privileges for the entire  tree  of  that
289       database.   Actually,  access  control  is  bypassed for the rootdn, to
290       solve the intrinsic chicken-and-egg problem.
291
292       The  statement  dnattr=<attrname>  means  that  access  is  granted  to
293       requests  whose  DN  is  listed  in  the entry being accessed under the
294       <attrname> attribute.
295
296       The statement group=<group> means that access is  granted  to  requests
297       whose  DN  is  listed  in the group entry whose DN is given by <group>.
298       The optional parameters <objectclass> and <attrname> define the object‐
299       Class  and  the  member attributeType of the group entry.  The defaults
300       are groupOfNames and member, respectively.  The optional  style  quali‐
301       fier  <style>  can be expand, which means that <group> will be expanded
302       as a replacement string (but not as a regular expression) according  to
303       regex(7)  and/or  re_format(7), and exact, which means that exact match
304       will be used.  If the style of the DN portion of the <what>  clause  is
305       regex,  the  submatches are made available according to regex(7) and/or
306       re_format(7); other styles  provide  limited  submatches  as  discussed
307       above about the DN form of the <by> clause.
308
309       For static groups, the specified attributeType must have Distinguished‐
310       Name or NameAndOptionalUID syntax. For dynamic groups the attributeType
311       must  be  a  subtype of the labeledURI attributeType. Only LDAP URIs of
312       the  form  ldap:///<base>??<scope>?<filter>  will  be  evaluated  in  a
313       dynamic group, by searching the local server only.
314
315       The      statements      peername=<peername>,      sockname=<sockname>,
316       domain=<domain>, and sockurl=<sockurl> mean that the contacting host IP
317       (in  the  form IP=<ip>:<port> for IPv4, or IP=[<ipv6>]:<port> for IPv6)
318       or the contacting host named pipe file name (in the form PATH=<path> if
319       connecting through a named pipe) for peername, the named pipe file name
320       for sockname, the contacting host name for domain, and  the  contacting
321       URL  for sockurl are compared against pattern to determine access.  The
322       same style rules for pattern match described for the group case  apply,
323       plus  the regex style, which implies submatch expand and regex match of
324       the corresponding connection parameters.  The exact style of the <peer‐
325       name>  clause  (the default) implies a case-exact match on the client's
326       IP, including the IP= prefix and the trailing :<port>, or the  client's
327       path,  including  the  PATH= prefix if connecting through a named pipe.
328       The   special   ip   style   interprets   the   pattern    as    <peer‐
329       name>=<ip>[%<mask>][{<n>}], where <ip> and <mask> are dotted digit rep‐
330       resentations of the IP and the mask,  while  <n>,  delimited  by  curly
331       brackets, is an optional port.  The same applies to IPv6 addresses when
332       the special ipv6 style is used.  When checking access  privileges,  the
333       IP portion of the peername is extracted, eliminating the IP= prefix and
334       the :<port> part, and it is compared against the <ip>  portion  of  the
335       pattern  after  masking with <mask>: ((peername & <mask>) == <ip>).  As
336       an example, peername.ip=127.0.0.1 and peername.ipv6=::1  allow  connec‐
337       tions only from localhost, peername.ip=192.168.1.0%255.255.255.0 allows
338       connections from any IP in the 192.168.1  class  C  domain,  and  peer‐
339       name.ip=192.168.1.16%255.255.255.240{9009}  allows connections from any
340       IP in the 192.168.1.[16-31] range of the same domain, only if port 9009
341       is  used.   The special path style eliminates the PATH= prefix from the
342       peername when connecting through a named pipe, and  performs  an  exact
343       match  on  the given pattern.  The <domain> clause also allows the sub‐
344       tree style, which succeeds when a fully qualified name exactly  matches
345       the  domain pattern, or its trailing part, after a dot, exactly matches
346       the domain pattern.  The expand style is  allowed,  implying  an  exact
347       match with submatch expansion; the use of expand as a style modifier is
348       considered more appropriate.  As an example, domain.subtree=example.com
349       will  match www.example.com, but will not match www.anotherexample.com.
350       The domain of the contacting host is determined  by  performing  a  DNS
351       reverse  lookup.   As  this  lookup  can  easily be spoofed, use of the
352       domain statement is strongly discouraged.  By default, reverse  lookups
353       are  disabled.   The  optional  domainstyle  qualifier  of the <domain>
354       clause allows a modifier option; the only value currently supported  is
355       expand, which causes substring substitution of submatches to take place
356       even if the domainstyle is not regex, much like the analogous usage  in
357       <dn> clause.
358
359       The statement set=<pattern> is undocumented yet.
360
361       The  statement dynacl/<name>[/<options>][.<dynstyle>][=<pattern>] means
362       that access checking is delegated to the admin-defined method indicated
363       by  <name>,  which  can  be registered at run-time by means of the mod‐
364       uleload statement.  The fields <options>, <dynstyle> and <pattern>  are
365       optional,  and  are  directly passed to the registered parsing routine.
366       Dynacl is experimental; it must be enabled at compile time.
367
368       The statement dynacl/aci[=<attrname>] means that the access control  is
369       determined  by  the  values  in  the attrname of the entry itself.  The
370       optional <attrname> indicates what attributeType holds the ACI informa‐
371       tion  in  the entry.  By default, the OpenLDAPaci operational attribute
372       is used.  ACIs are experimental; they must be enabled at compile time.
373
374       The   statements   ssf=<n>,   transport_ssf=<n>,    tls_ssf=<n>,    and
375       sasl_ssf=<n>  set  the  minimum required Security Strength Factor (ssf)
376       needed to grant access.  The value should be positive integer.
377

THE <ACCESS> FIELD

379       The optional field <access> ::= [[real]self]{<level>|<priv>} determines
380       the  access  level or the specific access privileges the who field will
381       have.  Its component are defined as
382
383            <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
384            <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
385
386       The modifier self allows  special  operations  like  having  a  certain
387       access  level or privilege only in case the operation involves the name
388       of the user that's requesting the access.  It  implies  the  user  that
389       requests  access  is  authorized.   The modifier realself refers to the
390       authenticated DN as opposed to the authorized DN of the self  modifier.
391       An  example is the selfwrite access to the member attribute of a group,
392       which allows one to add/delete its own DN from the  member  list  of  a
393       group, while being not allowed to affect other members.
394
395       The  level  access model relies on an incremental interpretation of the
396       access privileges.  The possible levels are none, disclose, auth,  com‐
397       pare,  search,  read, write, and manage.  Each access level implies all
398       the preceding ones, thus manage grants all access including administra‐
399       tive  access.   The write access is actually the combination of add and
400       delete, which respectively restrict  the  write  privilege  to  add  or
401       delete the specified <what>.
402
403
404       The  none  access  level  disallows  all access including disclosure on
405       error.
406
407       The disclose access level allows disclosure of information on error.
408
409       The auth access level means that one is allowed access to an  attribute
410       to perform authentication/authorization operations (e.g.  bind) with no
411       other access.  This is useful  to  grant  unauthenticated  clients  the
412       least possible access level to critical resources, like passwords.
413
414       The  priv  access model relies on the explicit setting of access privi‐
415       leges for each clause.  The = sign resets previously defined  accesses;
416       as  a  consequence,  the  final  access  privileges  will be only those
417       defined by the clause.  The + and - signs add/remove access  privileges
418       to  the existing ones.  The privileges are m for manage, w for write, a
419       for add, z for delete, r for read, s for search, c for compare,  x  for
420       authentication,  and d for disclose.  More than one of the above privi‐
421       leges can be added in one statement.  0 indicates no privileges and  is
422       used only by itself (e.g., +0).  Note that +az is equivalent to +w.
423
424       If no access is given, it defaults to +0.
425

THE <CONTROL> FIELD

427       The  optional field <control> controls the flow of access rule applica‐
428       tion.  It can have the forms
429
430            stop
431            continue
432            break
433
434       where stop, the default, means access checking stops in case of  match.
435       The  other two forms are used to keep on processing access clauses.  In
436       detail, the continue form allows for other <who> clauses  in  the  same
437       <access>  clause to be considered, so that they may result in incremen‐
438       tally altering the privileges, while the break form  allows  for  other
439       <access>  clauses that match the same target to be processed.  Consider
440       the (silly) example
441
442            access to dn.subtree="dc=example,dc=com" attrs=cn
443                 by * =cs break
444
445            access to dn.subtree="ou=People,dc=example,dc=com"
446                 by * +r
447
448       which allows search and  compare  privileges  to  everybody  under  the
449       "dc=example,dc=com"  tree,  with  the second rule allowing also read in
450       the "ou=People" subtree, or the (even more silly) example
451
452            access to dn.subtree="dc=example,dc=com" attrs=cn
453                 by * =cs continue
454                 by users +r
455
456       which grants everybody search and compare  privileges,  and  adds  read
457       privileges to authenticated clients.
458
459       One useful application is to easily grant write privileges to an updat‐
460       edn that is different from the rootdn.  In this case, since the  updat‐
461       edn needs write access to (almost) all data, one can use
462
463            access to *
464                 by dn.exact="cn=The Update DN,dc=example,dc=com" write
465                 by * break
466
467       as  the  first  access rule.  As a consequence, unless the operation is
468       performed with the updatedn identity, control is passed straight to the
469       subsequent rules.
470
471

OPERATION REQUIREMENTS

473       Operations  require  different  privileges  on  different  portions  of
474       entries.  The following summary applies to  primary  database  backends
475       such as the BDB and HDB backends.   Requirements for other backends may
476       (and often do) differ.
477
478
479       The add operation requires add (=a) privileges on the  pseudo-attribute
480       entry  of the entry being added, and add (=a) privileges on the pseudo-
481       attribute children of the entry's parent.  When adding the suffix entry
482       of a database, add access to children of the empty DN ("") is required.
483       Also if Add content ACL checking has been configured  on  the  database
484       (see  the  slapd.conf(5) or slapd-config(5) manual page), add (=a) will
485       be required on all of the attributes being added.
486
487
488       The bind operation, when  credentials  are  stored  in  the  directory,
489       requires  auth  (=x)  privileges  on  the attribute the credentials are
490       stored in (usually userPassword).
491
492
493       The compare operation requires compare (=c) privileges on the attribute
494       that is being compared.
495
496
497       The  delete  operation  requires  delete (=z) privileges on the pseudo-
498       attribute entry of the entry being deleted, and delete (=d)  privileges
499       on the children pseudo-attribute of the entry's parent.
500
501
502       The  modify  operation requires write (=w) privileges on the attributes
503       being modified.  In detail, add (=a) is required  to  add  new  values,
504       delete  (=z) is required to delete existing values, and both delete and
505       add (=az), or write (=w), are required to replace existing values.
506
507
508       The modrdn operation requires write  (=w)  privileges  on  the  pseudo-
509       attribute  entry  of  the  entry  whose  relative DN is being modified,
510       delete (=z) privileges on the  pseudo-attribute  children  of  the  old
511       entry's  parents,  add (=a) privileges on the pseudo-attribute children
512       of the new entry's parents, and add (=a) privileges on  the  attributes
513       that  are  present  in the new relative DN.  Delete (=z) privileges are
514       also required on the attributes that are present in the old relative DN
515       if deleteoldrdn is set to 1.
516
517
518       The  search  operation,  requires  search  (=s) privileges on the entry
519       pseudo-attribute of the searchBase  (NOTE:  this  was  introduced  with
520       OpenLDAP  2.4).   Then,  for each entry, it requires search (=s) privi‐
521       leges on the attributes that are defined in the filter.  The  resulting
522       entries  are  finally  tested  for  read (=r) privileges on the pseudo-
523       attribute entry (for read access to the entry itself) and for read (=r)
524       access  on  each  value of each attribute that is requested.  Also, for
525       each referral object used in generating  continuation  references,  the
526       operation  requires read (=r) access on the pseudo-attribute entry (for
527       read access to the referral object itself), as well as read (=r) access
528       to  the  attribute  holding the referral information (generally the ref
529       attribute).
530
531
532       Some internal operations and  some  controls  require  specific  access
533       privileges.   The  authzID  mapping  and the proxyAuthz control require
534       auth (=x) privileges on all the attributes  that  are  present  in  the
535       search filter of the URI regexp maps (the right-hand side of the authz-
536       regexp directives).  Auth (=x) privileges  are  also  required  on  the
537       authzTo  attribute  of the authorizing identity and/or on the authzFrom
538       attribute of the authorized identity.  In  general,  when  an  internal
539       lookup  is  performed  for  authentication  or  authorization purposes,
540       search-specific privileges (see the access requirements for the  search
541       operation illustrated above) are relaxed to auth.
542
543
544       Access  control  to search entries is checked by the frontend, so it is
545       fully honored by all backends; for all other  operations  and  for  the
546       discovery  phase  of  the  search operation, full ACL semantics is only
547       supported by the primary backends, i.e.  back-bdb(5), and back-hdb(5).
548
549       Some other backend, like back-sql(5), may fully  support  them;  others
550       may  only  support a portion of the described semantics, or even differ
551       in some aspects.  The relevant details are described  in  the  backend-
552       specific man pages.
553
554

CAVEATS

556       It  is  strongly  recommended  to  explicitly  use the most appropriate
557       <dnstyle> in <what> and <who>  clauses,  to  avoid  possible  incorrect
558       specifications  of  the  access rules as well as for performance (avoid
559       unnecessary regex matching when an exact match suffices) reasons.
560
561       An administrator might create a rule of the form:
562
563            access to dn.regex="dc=example,dc=com"
564                 by ...
565
566       expecting it to match all entries in the  subtree  "dc=example,dc=com".
567       However,  this rule actually matches any DN which contains anywhere the
568       substring  "dc=example,dc=com".   That  is,  the  rule   matches   both
569       "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
570
571       To match the desired subtree, the rule would be more precisely written:
572
573            access to dn.regex="^(.+,)?dc=example,dc=com$"
574                 by ...
575
576       For performance reasons, it would be better to use the subtree style.
577
578            access to dn.subtree="dc=example,dc=com"
579                 by ...
580
581       When  writing submatch rules, it may be convenient to avoid unnecessary
582       regex <dnstyle> use; for instance, to allow access to  the  subtree  of
583       the user that matches the <what> clause, one could use
584
585            access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
586                 by dn.regex="^uid=$2,dc=example,dc=com$$" write
587                 by ...
588
589       However,  since  all  that  is required in the <by> clause is substring
590       expansion, a more efficient solution is
591
592            access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
593                 by dn.exact,expand="uid=$2,dc=example,dc=com" write
594                 by ...
595
596       In fact, while a <dnstyle> of regex implies substring expansion, exact,
597       as  well as all the other DN specific <dnstyle> values, does not, so it
598       must be explicitly requested.
599

FILES

601       /etc/openldap/slapd.conf
602              default slapd configuration file
603

SEE ALSO

605       slapd(8), slapd-*(5), slapacl(8), regex(7), re_format(7)
606
607       "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
608

ACKNOWLEDGEMENTS

610       OpenLDAP Software is developed and maintained by The  OpenLDAP  Project
611       <http://www.openldap.org/>.  OpenLDAP Software is derived from the Uni‐
612       versity of Michigan LDAP 3.3 Release.
613
614
615
616OpenLDAP 2.4.47                   2018/12/19                   SLAPD.ACCESS(5)
Impressum