SLAPD.ACCESS(5) SLAPD.ACCESS(5)<\/p>\n
NAME
\nslapd.access – access configuration for slapd, the stand-alone LDAP daemon<\/p>\n
SYNOPSIS
\n\/etc\/openldap\/slapd.conf<\/p>\n
DESCRIPTION
\nThe slapd.conf(5) file contains configuration information for the slapd(8) daemon. This configuration file is
\nalso used by the SLAPD tools slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8), slapindex(8), and
\nslaptest(8).<\/p>\n
The slapd.conf file consists of a series of global configuration options that apply to slapd as a whole
\n(including all backends), followed by zero or more database backend definitions that contain information spe-
\ncific to a backend instance.<\/p>\n
The general format of slapd.conf is as follows:<\/p>\n
<global configuration options><\/p>\n
database <backend 1 type>
\n<configuration options specific to backend 1><\/p>\n
…<\/p>\n
Both the global configuration and each backend-specific section can contain access information. Backend-spe-
\ncific access control directives are used for those entries that belong to the backend, according to their nam-
\ning context. In case no access control directives are defined for a backend or those which are defined are not
\napplicable, the directives from the global configuration section are then used.<\/p>\n
If no access controls are present, the default policy allows anyone and everyone to read anything but restricts
\nupdates to rootdn. (e.g., “access to * by * read”).<\/p>\n
When dealing with an access list, because the global access list is effectively appended to each per-database
\nlist, if the resulting list is non-empty then the access list will end with an implicit access to * by * none
\ndirective. If there are no access directives applicable to a backend, then a default read is used.<\/p>\n
Be warned: the rootdn can always read and write EVERYTHING!<\/p>\n
For entries not held in any backend (such as a root DSE), the global directives are used.<\/p>\n
Arguments that should be replaced by actual text are shown in brackets <>.<\/p>\n
THE ACCESS DIRECTIVE
\nThe structure of the access control directives is<\/p>\n
access to <what> [ by <who> [ <access> ] [ <control> ] ]+
\nGrant access (specified by <access>) to a set of entries and\/or attributes (specified by <what>) by one
\nor more requestors (specified by <who>).<\/p>\n
Lists of access directives are evaluated in the order they appear in slapd.conf. When a <what> clause matches
\nthe datum whose access is being evaluated, its <who> clause list is checked. When a <who> clause matches the
\naccessor\u2019s properties, its <access> and <control> clauses are evaluated. Access control checking stops at the
\nfirst match of the <what> and <who> clause, unless otherwise dictated by the <control> clause. Each <who>
\nclause list is implicitly terminated by a<\/p>\n
by * none stop<\/p>\n
clause that results in stopping the access control with no access privileges granted. Each <what> clause list
\nis implicitly terminated by a<\/p>\n
access to *
\nby * none<\/p>\n
clause that results in granting no access privileges to an otherwise unspecified datum.<\/p>\n
THE <WHAT> FIELD
\nThe field <what> specifies the entity the access control directive applies to. It can have the forms<\/p>\n
dn[.<dnstyle>]=<dnpattern>
\nfilter=<ldapfilter>
\nattrs=<attrlist>[ val[\/matchingRule][.<attrstyle>]=<attrval>]<\/p>\n
with<\/p>\n
<dnstyle>={{exact|base(object)}|regex
\n|one(level)|sub(tree)|children}
\n<attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
\n<attrstyle>={{exact|base(object)}|regex
\n|one(level)|sub(tree)|children}<\/p>\n
The statement dn=<dnpattern> selects the entries based on their naming context. The <dnpattern> is a string
\nrepresentation of the entry\u2019s DN. The wildcard * stands for all the entries, and it is implied if no dn form
\nis given.<\/p>\n
The <dnstyle> is optional; however, it is recommended to specify it to avoid ambiguities. Base (synonym of
\nbaseObject), the default, or exact (an alias of base) indicates the entry whose DN is equal to the <dnpattern>;
\none (synonym of onelevel) indicates all the entries immediately below the <dnpattern>, sub (synonym of subtree)
\nindicates all entries in the subtree at the <dnpattern>, children indicates all the entries below (subordinate
\nto) the <dnpattern>.<\/p>\n
If the <dnstyle> qualifier is regex, then <dnpattern> is a POSIX (\u2019\u2019extended\u2019\u2019) regular expression pattern, as
\ndetailed in regex(7) and\/or re_format(7), matching a normalized string representation of the entry\u2019s DN. The
\nregex form of the pattern does not (yet) support UTF-8.<\/p>\n
The statement filter=<ldapfilter> selects the entries based on a valid LDAP filter as described in RFC 4515. A
\nfilter of (objectClass=*) is implied if no filter form is given.<\/p>\n
The statement attrs=<attrlist> selects the attributes the access control rule applies to. It is a comma-sepa-
\nrated list of attribute types, plus the special names entry, indicating access to the entry itself, and chil-
\ndren, indicating access to the entry\u2019s children. ObjectClass names may also be specified in this list, which
\nwill affect all the attributes that are required and\/or allowed by that objectClass. Actually, names in
\n<attrlist> that are prefixed by @ are directly treated as objectClass names. A name prefixed by ! is also
\ntreated as an objectClass, but in this case the access rule affects the attributes that are not required nor
\nallowed by that objectClass. If no attrs form is given, attrs=@extensibleObject is implied, i.e. all
\nattributes are addressed.<\/p>\n
Using the form attrs=<attr> val[\/matchingRule][.<attrstyle>]=<attrval> specifies access to a particular value
\nof a single attribute. In this case, only a single attribute type may be given. The <attrstyle> exact (the
\ndefault) uses the attribute\u2019s equality matching rule to compare the value, unless a different (and compatible)
\nmatching rule is specified. If the <attrstyle> is regex, the provided value is used as a POSIX (\u2019\u2019extended\u2019\u2019)
\nregular expression pattern. If the attribute has DN syntax, the <attrstyle> can be any of base, onelevel, sub-
\ntree or children, resulting in base, onelevel, subtree or children match, respectively.<\/p>\n
The dn, filter, and attrs statements are additive; they can be used in sequence to select entities the access
\nrule applies to based on naming context, value and attribute type simultaneously. Submatches resulting from
\nregex matching can be dereferenced in the <who> field using the syntax ${v<n>}, where <n> is the submatch num-
\nber. The default syntax, $<n>, is actually an alias for ${d<n>}, that corresponds to dereferencing submatches
\nfrom the dnpattern portion of the <what> field.<\/p>\n
THE <WHO> FIELD
\nThe field <who> indicates whom the access rules apply to. Multiple <who> statements can appear in an access
\ncontrol statement, indicating the different access privileges to the same resource that apply to different
\naccessee. It can have the forms<\/p>\n
*
\nanonymous
\nusers
\nself[.<selfstyle>]<\/p>\n
dn[.<dnstyle>[,<modifier>]]=<DN>
\ndnattr=<attrname><\/p>\n
realanonymous
\nrealusers
\nrealself[.<selfstyle>]<\/p>\n
realdn[.<dnstyle>[,<modifier>]]=<DN>
\nrealdnattr=<attrname><\/p>\n
group[\/<objectclass>[\/<attrname>]]
\n[.<groupstyle>]=<group>
\npeername[.<peernamestyle>]=<peername>
\nsockname[.<style>]=<sockname>
\ndomain[.<domainstyle>[,<modifier>]]=<domain>
\nsockurl[.<style>]=<sockurl>
\nset[.<setstyle>]=<pattern><\/p>\n
ssf=<n>
\ntransport_ssf=<n>
\ntls_ssf=<n>
\nsasl_ssf=<n><\/p>\n
dynacl\/<name>[\/<options>][.<dynstyle>][=<pattern>]<\/p>\n
with<\/p>\n
<style>={exact|regex|expand}
\n<selfstyle>={level{<n>}}
\n<dnstyle>={{exact|base(object)}|regex
\n|one(level)|sub(tree)|children|level{<n>}}
\n<groupstyle>={exact|expand}
\n<peernamestyle>={<style>|ip|ipv6|path}
\n<domainstyle>={exact|regex|sub(tree)}
\n<setstyle>={exact|expand}
\n<modifier>={expand}
\n<name>=aci <pattern>=<attrname>]<\/p>\n
They may be specified in combination.<\/p>\n
The wildcard * refers to everybody.<\/p>\n
The keywords prefixed by real act as their counterparts without prefix; the checking respectively occurs with
\nthe authentication DN and the authorization DN.<\/p>\n
The keyword anonymous means access is granted to unauthenticated clients; it is mostly used to limit access to
\nauthentication resources (e.g. the userPassword attribute) to unauthenticated clients for authentication pur-
\nposes.<\/p>\n
The keyword users means access is granted to authenticated clients.<\/p>\n
The keyword self means access to an entry is allowed to the entry itself (e.g. the entry being accessed and the
\nrequesting entry must be the same). It allows the level{<n>} style, where <n> indicates what ancestor of the
\nDN is to be used in matches. A positive value indicates that the <n>-th ancestor of the user\u2019s DN is to be
\nconsidered; a negative value indicates that the <n>-th ancestor of the target is to be considered. For exam-
\nple, a “by self.level{1} …” clause would match when the object “dc=example,dc=com” is accessed by
\n“cn=User,dc=example,dc=com”. A “by self.level{-1} …” clause would match when the same user accesses the
\nobject “ou=Address Book,cn=User,dc=example,dc=com”.<\/p>\n
The statement dn=<DN> means that access is granted to the matching DN. The optional style qualifier dnstyle
\nallows the same choices of the dn form of the <what> field. In addition, the regex style can exploit substring
\nsubstitution of submatches in the <what> dn.regex clause by using the form $<digit>, with digit ranging from 0
\nto 9 (where 0 matches the entire string), or the form ${<digit>+}, for submatches higher than 9. Substring
\nsubstitution from attribute value can be done in using the form ${v<digit>+}. Since the dollar character is
\nused to indicate a substring replacement, the dollar character that is used to indicate match up to the end of
\nthe string must be escaped by a second dollar character, e.g.<\/p>\n
access to dn.regex=”^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$”
\nby dn.regex=”^uid=$2,dc=[^,]+,dc=com$$” write<\/p>\n
The style qualifier allows an optional modifier. At present, the only type allowed is expand, which causes
\nsubstring substitution of submatches to take place even if dnstyle is not regex. Note that the regex dnstyle
\nin the above example may be of use only if the <by> clause needs to be a regex; otherwise, if the value of the
\nsecond (from the right) dc= portion of the DN in the above example were fixed, the form<\/p>\n
access to dn.regex=”^(.+,)?uid=([^,]+),dc=example,dc=com$”
\nby dn.exact,expand=”uid=$2,dc=example,dc=com” write<\/p>\n
could be used; if it had to match the value in the <what> clause, the form<\/p>\n
access to dn.regex=”^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$”
\nby dn.exact,expand=”uid=$2,dc=$3,dc=com” write<\/p>\n
could be used.<\/p>\n
Forms of the <what> clause other than regex may provide submatches as well. The base(object), the sub(tree),
\nthe one(level), and the children forms provide $0 as the match of the entire string. The sub(tree), the
\none(level), and the children forms also provide $1 as the match of the rightmost part of the DN as defined in
\nthe <what> clause. This may be useful, for instance, to provide access to all the ancestors of a user by
\ndefining<\/p>\n
access to dn.subtree=”dc=com”
\nby dn.subtree,expand=”$1″ read<\/p>\n
which means that only access to entries that appear in the DN of the <by> clause is allowed.<\/p>\n
The level{<n>} form is an extension and a generalization of the onelevel form, which matches all DNs whose
\n<n>-th ancestor is the pattern. So, level{1} is equivalent to onelevel, and level{0} is equivalent to base.<\/p>\n
It is perfectly useless to give any access privileges to a DN that exactly matches the rootdn of the database
\nthe ACLs apply to, because it implicitly possesses write privileges for the entire tree of that database.
\nActually, access control is bypassed for the rootdn, to solve the intrinsic chicken-and-egg problem.<\/p>\n
The statement dnattr=<attrname> means that access is granted to requests whose DN is listed in the entry being
\naccessed under the <attrname> attribute.<\/p>\n
The statement group=<group> means that access is granted to requests whose DN is listed in the group entry
\nwhose DN is given by <group>. The optional parameters <objectclass> and <attrname> define the objectClass and
\nthe member attributeType of the group entry. The defaults are groupOfNames and member, respectively. The
\noptional style qualifier <style> can be expand, which means that <group> will be expanded as a replacement
\nstring (but not as a regular expression) according to regex(7) and\/or re_format(7), and exact, which means that
\nexact match will be used. If the style of the DN portion of the <what> clause is regex, the submatches are
\nmade available according to regex(7) and\/or re_format(7); other styles provide limited submatches as discussed
\nabove about the DN form of the <by> clause.<\/p>\n
For static groups, the specified attributeType must have DistinguishedName or NameAndOptionalUID syntax. For
\ndynamic groups the attributeType must be a subtype of the labeledURI attributeType. Only LDAP URIs of the form
\nldap:\/\/\/<base>??<scope>?<filter> will be evaluated in a dynamic group, by searching the local server only.<\/p>\n
The statements peername=<peername>, sockname=<sockname>, domain=<domain>, and sockurl=<sockurl> mean that the
\ncontacting host IP (in the form IP=<ip>:<port> for IPv4, or IP=[<ipv6>]:<port> for IPv6) or the contacting host
\nnamed pipe file name (in the form PATH=<path> if connecting through a named pipe) for peername, the named pipe
\nfile name for sockname, the contacting host name for domain, and the contacting URL for sockurl are compared
\nagainst pattern to determine access. The same style rules for pattern match described for the group case
\napply, plus the regex style, which implies submatch expand and regex match of the corresponding connection
\nparameters. The exact style of the <peername> clause (the default) implies a case-exact match on the client\u2019s
\nIP, including the IP= prefix and the trailing :<port>, or the client\u2019s path, including the PATH= prefix if con-
\nnecting through a named pipe. The special ip style interprets the pattern as <peername>=<ip>[%<mask>][{<n>}],
\nwhere <ip> and <mask> are dotted digit representations of the IP and the mask, while <n>, delimited by curly
\nbrackets, is an optional port. The same applies to IPv6 addresses when the special ipv6 style is used. When
\nchecking access privileges, the IP portion of the peername is extracted, eliminating the IP= prefix and the
\n:<port> part, and it is compared against the <ip> portion of the pattern after masking with <mask>: ((peername
\n& <mask>) == <ip>). As an example, peername.ip=127.0.0.1 and peername.ipv6=::1 allow connections only from
\nlocalhost, peername.ip=192.168.1.0%255.255.255.0 allows connections from any IP in the 192.168.1 class C
\ndomain, and peername.ip=192.168.1.16%255.255.255.240{9009} allows connections from any IP in the
\n192.168.1.[16-31] range of the same domain, only if port 9009 is used. The special path style eliminates the
\nPATH= prefix from the peername when connecting through a named pipe, and performs an exact match on the given
\npattern. The <domain> clause also allows the subtree style, which succeeds when a fully qualified name exactly
\nmatches the domain pattern, or its trailing part, after a dot, exactly matches the domain pattern. The expand
\nstyle is allowed, implying an exact match with submatch expansion; the use of expand as a style modifier is
\nconsidered more appropriate. As an example, domain.subtree=example.com will match www.example.com, but will
\nnot match www.anotherexample.com. The domain of the contacting host is determined by performing a DNS reverse
\nlookup. As this lookup can easily be spoofed, use of the domain statement is strongly discouraged. By
\ndefault, reverse lookups are disabled. The optional domainstyle qualifier of the <domain> clause allows a mod-
\nifier option; the only value currently supported is expand, which causes substring substitution of submatches
\nto take place even if the domainstyle is not regex, much like the analogous usage in <dn> clause.<\/p>\n
The statement set=<pattern> is undocumented yet.<\/p>\n
The statement dynacl\/<name>[\/<options>][.<dynstyle>][=<pattern>] means that access checking is delegated to the
\nadmin-defined method indicated by <name>, which can be registered at run-time by means of the moduleload state-
\nment. The fields <options>, <dynstyle> and <pattern> are optional, and are directly passed to the registered
\nparsing routine. Dynacl is experimental; it must be enabled at compile time.<\/p>\n
The statement dynacl\/aci[=<attrname>] means that the access control is determined by the values in the attrname
\nof the entry itself. The optional <attrname> indicates what attributeType holds the ACI information in the
\nentry. By default, the OpenLDAPaci operational attribute is used. ACIs are experimental; they must be enabled
\nat compile time.<\/p>\n
The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and sasl_ssf=<n> set the minimum required Security
\nStrength Factor (ssf) needed to grant access. The value should be positive integer.<\/p>\n
THE <ACCESS> FIELD
\nThe optional field <access> ::= [[real]self]{<level>|<priv>} determines the access level or the specific access
\nprivileges the who field will have. Its component are defined as<\/p>\n
<level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
\n<priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+<\/p>\n
The modifier self allows special operations like having a certain access level or privilege only in case the
\noperation involves the name of the user that\u2019s requesting the access. It implies the user that requests access
\nis authorized. The modifier realself refers to the authenticated DN as opposed to the authorized DN of the
\nself modifier. An example is the selfwrite access to the member attribute of a group, which allows one to
\nadd\/delete its own DN from the member list of a group, while being not allowed to affect other members.<\/p>\n
The level access model relies on an incremental interpretation of the access privileges. The possible levels
\nare none, disclose, auth, compare, search, read, write, and manage. Each access level implies all the preced-
\ning ones, thus manage grants all access including administrative access. The write access is actually the com-
\nbination of add and delete, which respectively restrict the write privilege to add or delete the specified
\n<what>.<\/p>\n
The none access level disallows all access including disclosure on error.<\/p>\n
The disclose access level allows disclosure of information on error.<\/p>\n
The auth access level means that one is allowed access to an attribute to perform authentication\/authorization
\noperations (e.g. bind) with no other access. This is useful to grant unauthenticated clients the least possi-
\nble access level to critical resources, like passwords.<\/p>\n
The priv access model relies on the explicit setting of access privileges for each clause. The = sign resets
\npreviously defined accesses; as a consequence, the final access privileges will be only those defined by the
\nclause. The + and – signs add\/remove access privileges to the existing ones. The privileges are m for manage,
\nw for write, a for add, z for delete, r for read, s for search, c for compare, x for authentication, and d for
\ndisclose. More than one of the above privileges can be added in one statement. 0 indicates no privileges and
\nis used only by itself (e.g., +0). Note that +az is equivalent to +w.<\/p>\n
If no access is given, it defaults to +0.<\/p>\n
THE <CONTROL> FIELD
\nThe optional field <control> controls the flow of access rule application. It can have the forms<\/p>\n
stop
\ncontinue
\nbreak<\/p>\n
where stop, the default, means access checking stops in case of match. The other two forms are used to keep on
\nprocessing access clauses. In detail, the continue form allows for other <who> clauses in the same <access>
\nclause to be considered, so that they may result in incrementally altering the privileges, while the break form
\nallows for other <access> clauses that match the same target to be processed. Consider the (silly) example<\/p>\n
access to dn.subtree=”dc=example,dc=com” attrs=cn
\nby * =cs break<\/p>\n
access to dn.subtree=”ou=People,dc=example,dc=com”
\nby * +r<\/p>\n
which allows search and compare privileges to everybody under the “dc=example,dc=com” tree, with the second
\nrule allowing also read in the “ou=People” subtree, or the (even more silly) example<\/p>\n
access to dn.subtree=”dc=example,dc=com” attrs=cn
\nby * =cs continue
\nby users +r<\/p>\n
which grants everybody search and compare privileges, and adds read privileges to authenticated clients.<\/p>\n
One useful application is to easily grant write privileges to an updatedn that is different from the rootdn.
\nIn this case, since the updatedn needs write access to (almost) all data, one can use<\/p>\n
access to *
\nby dn.exact=”cn=The Update DN,dc=example,dc=com” write
\nby * break<\/p>\n
as the first access rule. As a consequence, unless the operation is performed with the updatedn identity, con-
\ntrol is passed straight to the subsequent rules.<\/p>\n
OPERATION REQUIREMENTS
\nOperations require different privileges on different portions of entries. The following summary applies to
\nprimary database backends such as the BDB and HDB backends. Requirements for other backends may (and often
\ndo) differ.<\/p>\n
The add operation requires add (=a) privileges on the pseudo-attribute entry of the entry being added, and add
\n(=a) privileges on the pseudo-attribute children of the entry\u2019s parent. When adding the suffix entry of a
\ndatabase, add access to children of the empty DN (“”) is required. Also if Add content ACL checking has been
\nconfigured on the database (see the slapd.conf(5) or slapd-config(5) manual page), add (=a) will be required on
\nall of the attributes being added.<\/p>\n
The bind operation, when credentials are stored in the directory, requires auth (=x) privileges on the
\nattribute the credentials are stored in (usually userPassword).<\/p>\n
The compare operation requires compare (=c) privileges on the attribute that is being compared.<\/p>\n
The delete operation requires delete (=z) privileges on the pseudo-attribute entry of the entry being deleted,
\nand delete (=d) privileges on the children pseudo-attribute of the entry\u2019s parent.<\/p>\n
The modify operation requires write (=w) privileges on the attributes being modified. In detail, add (=a) is
\nrequired to add new values, delete (=z) is required to delete existing values, and both delete and add (=az),
\nor write (=w), are required to replace existing values.<\/p>\n
The modrdn operation requires write (=w) privileges on the pseudo-attribute entry of the entry whose relative
\nDN is being modified, delete (=z) privileges on the pseudo-attribute children of the old entry\u2019s parents, add
\n(=a) privileges on the pseudo-attribute children of the new entry\u2019s parents, and add (=a) privileges on the
\nattributes that are present in the new relative DN. Delete (=z) privileges are also required on the attributes
\nthat are present in the old relative DN if deleteoldrdn is set to 1.<\/p>\n
The search operation, requires search (=s) privileges on the entry pseudo-attribute of the searchBase (NOTE:
\nthis was introduced with OpenLDAP 2.4). Then, for each entry, it requires search (=s) privileges on the
\nattributes that are defined in the filter. The resulting entries are finally tested for read (=r) privileges
\non the pseudo-attribute entry (for read access to the entry itself) and for read (=r) access on each value of
\neach attribute that is requested. Also, for each referral object used in generating continuation references,
\nthe operation requires read (=r) access on the pseudo-attribute entry (for read access to the referral object
\nitself), as well as read (=r) access to the attribute holding the referral information (generally the ref
\nattribute).<\/p>\n
Some internal operations and some controls require specific access privileges. The authzID mapping and the
\nproxyAuthz control require auth (=x) privileges on all the attributes that are present in the search filter of
\nthe URI regexp maps (the right-hand side of the authz-regexp directives). Auth (=x) privileges are also
\nrequired on the authzTo attribute of the authorizing identity and\/or on the authzFrom attribute of the autho-
\nrized identity. In general, when an internal lookup is performed for authentication or authorization purposes,
\nsearch-specific privileges (see the access requirements for the search operation illustrated above) are relaxed
\nto auth.<\/p>\n
Access control to search entries is checked by the frontend, so it is fully honored by all backends; for all
\nother operations and for the discovery phase of the search operation, full ACL semantics is only supported by
\nthe primary backends, i.e. back-bdb(5), and back-hdb(5).<\/p>\n
Some other backend, like back-sql(5), may fully support them; others may only support a portion of the
\ndescribed semantics, or even differ in some aspects. The relevant details are described in the backend-spe-
\ncific man pages.<\/p>\n
CAVEATS
\nIt is strongly recommended to explicitly use the most appropriate <dnstyle> in <what> and <who> clauses, to
\navoid possible incorrect specifications of the access rules as well as for performance (avoid unnecessary regex
\nmatching when an exact match suffices) reasons.<\/p>\n
An administrator might create a rule of the form:<\/p>\n
access to dn.regex=”dc=example,dc=com”
\nby …<\/p>\n
expecting it to match all entries in the subtree “dc=example,dc=com”. However, this rule actually matches any
\nDN which contains anywhere the substring “dc=example,dc=com”. That is, the rule matches both “uid=joe,dc=exam-
\nple,dc=com” and “dc=example,dc=com,uid=joe”.<\/p>\n
To match the desired subtree, the rule would be more precisely written:<\/p>\n
access to dn.regex=”^(.+,)?dc=example,dc=com$”
\nby …<\/p>\n
For performance reasons, it would be better to use the subtree style.<\/p>\n
access to dn.subtree=”dc=example,dc=com”
\nby …<\/p>\n
When writing submatch rules, it may be convenient to avoid unnecessary regex <dnstyle> use; for instance, to
\nallow access to the subtree of the user that matches the <what> clause, one could use<\/p>\n
access to dn.regex=”^(.+,)?uid=([^,]+),dc=example,dc=com$”
\nby dn.regex=”^uid=$2,dc=example,dc=com$$” write
\nby …<\/p>\n
However, since all that is required in the <by> clause is substring expansion, a more efficient solution is<\/p>\n
access to dn.regex=”^(.+,)?uid=([^,]+),dc=example,dc=com$”
\nby dn.exact,expand=”uid=$2,dc=example,dc=com” write
\nby …<\/p>\n
In fact, while a <dnstyle> of regex implies substring expansion, exact, as well as all the other DN specific
\n<dnstyle> values, does not, so it must be explicitly requested.<\/p>\n
FILES
\n\/etc\/openldap\/slapd.conf
\ndefault slapd configuration file<\/p>\n
SEE ALSO
\nslapd(8), slapd-*(5), slapacl(8), regex(7), re_format(7)<\/p>\n
“OpenLDAP Administrator\u2019s Guide” (http:\/\/www.OpenLDAP.org\/doc\/admin\/)<\/p>\n
ACKNOWLEDGEMENTS
\nOpenLDAP Software is developed and maintained by The OpenLDAP Project <http:\/\/www.openldap.org\/>. OpenLDAP
\nSoftware is derived from University of Michigan LDAP 3.3 Release.<\/p>\n
OpenLDAP 2.4.23 2010\/06\/30 SLAPD.ACCESS(5)<\/p>\n","protected":false},"excerpt":{"rendered":"
SLAPD.ACCESS(5) SLAPD.ACCESS(5)<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[68],"tags":[],"class_list":["post-431","post","type-post","status-publish","format-standard","hentry","category-openldap"],"_links":{"self":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts\/431","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=431"}],"version-history":[{"count":1,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts\/431\/revisions"}],"predecessor-version":[{"id":2145,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=\/wp\/v2\/posts\/431\/revisions\/2145"}],"wp:attachment":[{"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=431"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=431"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cowmanchiang.me\/wp\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=431"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}