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), slapmodify(8), and slaptest(8).
17
18       The  slapd.conf  file  consists of a series of global configuration op‐
19       tions that apply to slapd as a whole (including all backends), followed
20       by  zero  or more database backend definitions that contain information
21       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., "ac‐
42       cess to * by * read").
43
44       When dealing with an access list, because the global access list is ef‐
45       fectively appended to each per-database list, if the resulting list  is
46       non-empty then the access list will end with an implicit access to * by
47       * 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 be‐
69       ing  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.
72
73
74       Access  control  checking  stops  at  the first match of the <what> and
75       <who> clause, unless otherwise dictated by the <control> clause.   Each
76       <who> clause list is implicitly terminated by a
77
78            by * none stop
79
80       <control> clause.  This implicit <control> stops access directive eval‐
81       uation with no more access privileges granted to anyone else.  To  stop
82       access  directive evaluation only when both <who> and <what> match, add
83       an explicit
84
85            by * break
86
87       to the end of the <who> clause list.
88
89
90       Each <what> clause list is implicitly terminated by a
91
92            access to *
93                 by * none
94
95       clause that results in granting no access privileges  to  an  otherwise
96       unspecified datum.
97

THE <WHAT> FIELD

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

THE <WHO> FIELD

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

THE <ACCESS> FIELD

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

THE <CONTROL> FIELD

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

OPERATION REQUIREMENTS

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

CAVEATS

578       It  is  strongly  recommended  to  explicitly  use the most appropriate
579       <dnstyle> in <what> and <who>  clauses,  to  avoid  possible  incorrect
580       specifications  of  the  access rules as well as for performance (avoid
581       unnecessary regex matching when an exact match suffices) reasons.
582
583       An administrator might create a rule of the form:
584
585            access to dn.regex="dc=example,dc=com"
586                 by ...
587
588       expecting it to match all entries in the  subtree  "dc=example,dc=com".
589       However,  this rule actually matches any DN which contains anywhere the
590       substring  "dc=example,dc=com".   That  is,  the  rule   matches   both
591       "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
592
593       To match the desired subtree, the rule would be more precisely written:
594
595            access to dn.regex="^(.+,)?dc=example,dc=com$"
596                 by ...
597
598       For performance reasons, it would be better to use the subtree style.
599
600            access to dn.subtree="dc=example,dc=com"
601                 by ...
602
603       When  writing submatch rules, it may be convenient to avoid unnecessary
604       regex <dnstyle> use; for instance, to allow access to  the  subtree  of
605       the user that matches the <what> clause, one could use
606
607            access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
608                 by dn.regex="^uid=$2,dc=example,dc=com$$" write
609                 by ...
610
611       However, since all that is required in the <by> clause is substring ex‐
612       pansion, a more efficient solution is
613
614            access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
615                 by dn.exact,expand="uid=$2,dc=example,dc=com" write
616                 by ...
617
618       In fact, while a <dnstyle> of regex implies substring expansion, exact,
619       as  well as all the other DN specific <dnstyle> values, does not, so it
620       must be explicitly requested.
621

FILES

623       /etc/openldap/slapd.conf
624              default slapd configuration file
625

SEE ALSO

627       slapd(8), slapd-*(5), slapacl(8), regex(7), re_format(7)
628
629       "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
630

ACKNOWLEDGEMENTS

632       OpenLDAP Software is developed and maintained by The  OpenLDAP  Project
633       <http://www.openldap.org/>.  OpenLDAP Software is derived from the Uni‐
634       versity of Michigan LDAP 3.3 Release.
635
636
637
638OpenLDAP 2.6.6                    2023/07/31                   SLAPD.ACCESS(5)
Impressum