Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SLAPD.ACCESS(5)		      File Formats Manual	       SLAPD.ACCESS(5)

       slapd.access  -	access	configuration  for slapd, the stand-alone LDAP


       The slapd.conf(5)  file	contains  configuration	 information  for  the
       slapd(8)	 daemon.  This	configuration  file  is	also used by the SLAPD
       tools  slapacl(8),  slapadd(8),	slapauth(8),  slapcat(8),   slapdn(8),
       slapindex(8), and slaptest(8).

       The  slapd.conf	file  consists of a series of global configuration op-
       tions that apply	to slapd as a whole (including all backends), followed
       by  zero	 or more database backend definitions that contain information
       specific	to a backend instance.

       The general format of slapd.conf	is as follows:

	   # comment - these options apply to every database
	   <global configuration options>
	   # first database definition & configuration options
	   database    <backend	1 type>
	   <configuration options specific to backend 1>
	   # subsequent	database definitions & configuration options

       Both the	global configuration and  each	backend-specific  section  can
       contain access information.  Backend-specific access control directives
       are used	for those entries that belong to  the  backend,	 according  to
       their naming context.  In case no access	control	directives are defined
       for a backend or	those which are	defined	are not	applicable, the	direc-
       tives from the global configuration section are then used.

       If no access controls are present, the default policy allows anyone and
       everyone	to read	anything but restricts updates to rootdn.  (e.g., "ac-
       cess to * by * read").

       When dealing with an access list, because the global access list	is ef-
       fectively appended to each per-database list, if	the resulting list  is
       non-empty then the access list will end with an implicit	access to * by
       * none directive. If there are no access	 directives  applicable	 to  a
       backend,	then a default read is used.

       Be warned: the rootdn can always	read and write EVERYTHING!

       For  entries  not  held in any backend (such as a root DSE), the	global
       directives are used.

       Arguments that should be	replaced by actual text	are shown in  brackets

       The structure of	the access control directives is

       access to <what>	[ by <who> [ <access> ]	[ <control> ] ]+
	      Grant  access (specified by <access>) to a set of	entries	and/or
	      attributes (specified by	<what>)	 by  one  or  more  requestors
	      (specified by <who>).

       Lists  of  access  directives are evaluated in the order	they appear in
       slapd.conf.  When a <what> clause matches the datum whose access	is be-
       ing  evaluated,	its <who> clause list is checked.  When	a <who>	clause
       matches the accessor's properties, its <access> and  <control>  clauses
       are evaluated.  Access control checking stops at	the first match	of the
       <what> and <who>	clause,	unless otherwise  dictated  by	the  <control>
       clause.	Each <who> clause list is implicitly terminated	by a

	    by * none stop

       clause that results in stopping the access control with no access priv-
       ileges granted.	Each <what> clause list	is implicitly terminated by a

	    access to *
		 by * none

       clause that results in granting no access privileges  to	 an  otherwise
       unspecified datum.

       The  field <what> specifies the entity the access control directive ap-
       plies to.  It can have the forms

	    attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]



       The statement dn=<dnpattern> selects the	entries	based on their	naming
       context.	 The <dnpattern> is a string representation of the entry's DN.
       The wildcard * stands for all the entries, and it is implied if	no  dn
       form is given.

       The  <dnstyle> is optional; however, it is recommended to specify it to
       avoid ambiguities.  Base	(synonym of baseObject), the default, or exact
       (an alias of base) indicates the	entry whose DN is equal	to the <dnpat-
       tern>; one (synonym of onelevel)	indicates all the entries  immediately
       below  the  <dnpattern>,	sub (synonym of	subtree) indicates all entries
       in the subtree at the <dnpattern>, children indicates all  the  entries
       below (subordinate to) the <dnpattern>.

       If the <dnstyle>	qualifier is regex, then <dnpattern> is	a POSIX	(''ex-
       tended'') regular expression pattern, as	detailed  in  regex(7)	and/or
       re_format(7),  matching	a  normalized string representation of the en-
       try's DN.  The regex form of the	pattern	does not (yet) support UTF-8.

       The statement filter=<ldapfilter> selects the entries based on a	 valid
       LDAP  filter  as	described in RFC 4515.	A filter of (objectClass=*) is
       implied if no filter form is given.

       The statement attrs=<attrlist> selects the attributes the  access  con-
       trol rule applies to.  It is a comma-separated list of attribute	types,
       plus the	special	names entry, indicating	access to  the	entry  itself,
       and  children,  indicating  access to the entry's children. ObjectClass
       names may also be specified in this list, which will affect all the at-
       tributes	 that  are required and/or allowed by that objectClass.	 Actu-
       ally, names in <attrlist> that are prefixed by @	are  directly  treated
       as  objectClass names.  A name prefixed by !  is	also treated as	an ob-
       jectClass, but in this case the access rule affects the attributes that
       are  not	required nor allowed by	that objectClass.  If no attrs form is
       given, attrs=@extensibleObject is implied, i.e. all attributes are  ad-

       Using  the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval>
       specifies access	to a particular	value of a single attribute.  In  this
       case,  only a single attribute type may be given. The <attrstyle> exact
       (the default) uses the attribute's equality matching  rule  to  compare
       the  value, unless a different (and compatible) matching	rule is	speci-
       fied. If	the <attrstyle>	is regex, the provided	value  is  used	 as  a
       POSIX  (''extended'') regular expression	pattern.  If the attribute has
       DN syntax, the <attrstyle> can be any of	 base,	onelevel,  subtree  or
       children,  resulting  in	base, onelevel,	subtree	or children match, re-

       The dn, filter, and attrs statements are	additive; they can be used  in
       sequence	 to select entities the	access rule applies to based on	naming
       context,	value and attribute type simultaneously.  Submatches resulting
       from  regex  matching  can be dereferenced in the <who> field using the
       syntax ${v_n_}, where _n_ is the	submatch number.  The default  syntax,
       $_n_, is	actually an alias for ${d_n_}, that corresponds	to dereferenc-
       ing submatches from the dnpattern portion of the	<what> field.

       The field <who> indicates whom the access  rules	 apply	to.   Multiple
       <who>  statements can appear in an access control statement, indicating
       the different access privileges to the same resource that apply to dif-
       ferent accessee.	 It can	have the forms









	    <name>=aci		<pattern>=<attrname>]

       They may	be specified in	combination.

       The wildcard * refers to	everybody.

       The keywords prefixed by	real act as their counterparts without prefix;
       the checking respectively occurs	with the authentication	DN and the au-
       thorization DN.

       The  keyword  anonymous	means  access  is  granted  to unauthenticated
       clients;	it is mostly used to limit access to authentication  resources
       (e.g.  the  userPassword	 attribute) to unauthenticated clients for au-
       thentication purposes.

       The keyword users means access is granted to authenticated clients.

       The keyword self	means access to	an entry is allowed to the  entry  it-
       self  (e.g.  the	 entry being accessed and the requesting entry must be
       the same).  It allows the level{<n>} style, where  _n_  indicates  what
       ancestor	 of  the  DN is	to be used in matches.	A positive value indi-
       cates that the <n>-th ancestor of the user's DN is to be	considered;  a
       negative	 value	indicates that the <n>-th ancestor of the target is to
       be considered.  For example, a  "by  self.level{1}  ..."	 clause	 would
       match	when   the   object   "dc=example,dc=com"   is	 accessed   by
       "cn=User,dc=example,dc=com".  A "by self.level{-1}  ..."	 clause	 would
       match   when   the   same   user	  accesses   the   object  "ou=Address

       The statement dn=<DN> means that	access is granted to the matching  DN.
       The  optional style qualifier dnstyle allows the	same choices of	the dn
       form of the <what> field.  In addition, the  regex  style  can  exploit
       substring  substitution	of submatches in the <what> dn.regex clause by
       using the form $<digit>,	with digit  ranging  from  0  to  9  (where  0
       matches	the  entire  string),  or the form ${<digit>+},	for submatches
       higher than 9.  Substring substitution from attribute value can be done
       in  using the form ${v<digit>+}.	 Since the dollar character is used to
       indicate	a substring replacement, the dollar character that is used  to
       indicate	 match up to the end of	the string must	be escaped by a	second
       dollar character, e.g.

	   access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
	       by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write

       The style qualifier allows an optional modifier.	 At present, the  only
       type  allowed  is  expand,  which causes	substring substitution of sub-
       matches to take place even if dnstyle is	 not  regex.   Note  that  the
       regex  dnstyle  in  the	above  example	may be of use only if the <by>
       clause needs to be a regex; otherwise, if the value of the second (from
       the  right)  dc=	portion	of the DN in the above example were fixed, the

	   access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
	       by dn.exact,expand="uid=$2,dc=example,dc=com" write

       could be	used; if it had	to match the value in the <what>  clause,  the

	   access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
	       by dn.exact,expand="uid=$2,dc=$3,dc=com"	write

       could be	used.

       Forms  of  the <what> clause other than regex may provide submatches as
       well.  The base(object),	the sub(tree), the one(level), and  the	 chil-
       dren  forms  provide  $0	 as  the  match	 of  the  entire  string.  The
       sub(tree), the one(level), and the children forms also  provide	$1  as
       the  match  of  the  rightmost  part of the DN as defined in the	<what>
       clause.	This may be useful, for	instance, to provide access to all the
       ancestors of a user by defining

	   access to dn.subtree="dc=com"
	       by dn.subtree,expand="$1" read

       which  means  that  only	access to entries that appear in the DN	of the
       <by> clause is allowed.

       The level{<n>} form  is	an  extension  and  a  generalization  of  the
       onelevel	 form, which matches all DNs whose <n>-th ancestor is the pat-
       tern.  So, level{1} is equivalent to onelevel, and level{0} is  equiva-
       lent to base.

       It  is perfectly	useless	to give	any access privileges to a DN that ex-
       actly matches the rootdn	of the database	the ACLs apply to, because  it
       implicitly possesses write privileges for the entire tree of that data-
       base.  Actually,	access control is bypassed for the  rootdn,  to	 solve
       the intrinsic chicken-and-egg problem.

       The  statement  dnattr=<attrname>  means	 that access is	granted	to re-
       quests whose DN is listed in the	entry being accessed under the	<attr-
       name> attribute.

       The  statement  group=<group>  means that access	is granted to requests
       whose DN	is listed in the group entry whose DN  is  given  by  <group>.
       The optional parameters <objectclass> and <attrname> define the object-
       Class and the member attributeType of the group	entry.	 The  defaults
       are  groupOfNames  and member, respectively.  The optional style	quali-
       fier <style> can	be expand, which means that <group> will  be  expanded
       as  a replacement string	(but not as a regular expression) according to
       regex(7)	and/or re_format(7), and exact,	which means that  exact	 match
       will  be	 used.	If the style of	the DN portion of the <what> clause is
       regex, the submatches are made available	according to  regex(7)	and/or
       re_format(7);  other  styles  provide  limited  submatches as discussed
       above about the DN form of the <by> clause.

       For static groups, the specified	attributeType must have	Distinguished-
       Name or NameAndOptionalUID syntax. For dynamic groups the attributeType
       must be a subtype of the	labeledURI attributeType. Only	LDAP  URIs  of
       the  form  ldap:///<base>??<scope>?<filter>  will be evaluated in a dy-
       namic group, by searching the local server only.

       The statements  peername=<peername>,  sockname=<sockname>,  domain=<do-
       main>,  and  sockurl=<sockurl> mean that	the contacting host IP (in the
       form IP=<ip>:<port> for IPv4, or	IP=[<ipv6>]:<port> for	IPv6)  or  the
       contacting  host	 named pipe file name (in the form PATH=<path> if con-
       necting through a named pipe) for peername, the named  pipe  file  name
       for  sockname,  the contacting host name	for domain, and	the contacting
       URL for sockurl are compared against pattern to determine access.   The
       same  style rules for pattern match described for the group case	apply,
       plus the	regex style, which implies submatch expand and regex match  of
       the corresponding connection parameters.	 The exact style of the	<peer-
       name> clause (the default) implies a case-exact match on	 the  client's
       IP,  including the IP= prefix and the trailing :<port>, or the client's
       path, including the PATH= prefix	if connecting through  a  named	 pipe.
       The    special	 ip   style   interprets   the	 pattern   as	<peer-
       name>=<ip>[%<mask>][{<n>}], where <ip> and <mask> are dotted digit rep-
       resentations  of	 the  IP  and  the mask, while <n>, delimited by curly
       brackets, is an optional	port.  The same	applies	to IPv6	addresses when
       the  special  ipv6 style	is used.  When checking	access privileges, the
       IP portion of the peername is extracted,	eliminating the	IP= prefix and
       the  :<port>  part,  and	it is compared against the <ip>	portion	of the
       pattern after masking with <mask>: ((peername _ _mask_) ==  _ip_).   As
       an  example,  peername.ip= and peername.ipv6=::1 allow connec-
       tions only from localhost, peername.ip=	allows
       connections  from  any  IP  in  the 192.168.1 class C domain, and peer-
       name.ip={9009} allows connections from  any
       IP in the 192.168.1.[16-31] range of the	same domain, only if port 9009
       is used.	 The special path style	eliminates the PATH= prefix  from  the
       peername	 when  connecting  through a named pipe, and performs an exact
       match on	the given pattern.  The	<domain> clause	also allows  the  sub-
       tree  style, which succeeds when	a fully	qualified name exactly matches
       the domain pattern, or its trailing part, after a dot, exactly  matches
       the  domain  pattern.   The  expand style is allowed, implying an exact
       match with submatch expansion; the use of expand	as a style modifier is
       considered more appropriate.  As	an example,
       will match, but will not	match
       The domain of the contacting host is determined by performing a DNS re-
       verse lookup.  As this lookup can easily	be spoofed, use	of the	domain
       statement  is  strongly	discouraged.   By default, reverse lookups are
       disabled.  The optional domainstyle qualifier of	 the  <domain>	clause
       allows a	modifier option; the only value	currently supported is expand,
       which causes substring substitution of submatches to take place even if
       the  domainstyle	 is  not  regex, much like the analogous usage in <dn>

       The statement set=<pattern> is undocumented yet.

       The statement dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]	 means
       that access checking is delegated to the	admin-defined method indicated
       by <name>, which	can be registered at run-time by  means	 of  the  mod-
       uleload	statement.  The	fields <options>, <dynstyle> and <pattern> are
       optional, and are directly passed to the	 registered  parsing  routine.
       Dynacl is experimental; it must be enabled at compile time.

       The  statement dynacl/aci[=<attrname>] means that the access control is
       determined by the values	in the attrname	of the entry itself.  The  op-
       tional  <attrname>  indicates what attributeType	holds the ACI informa-
       tion in the entry.  By default, the OpenLDAPaci	operational  attribute
       is used.	 ACIs are experimental;	they must be enabled at	compile	time.

       The    statements    ssf=<n>,   transport_ssf=<n>,   tls_ssf=<n>,   and
       sasl_ssf=<n> set	the minimum required Security  Strength	 Factor	 (ssf)
       needed to grant access.	The value should be positive integer.

       The optional field <access> ::= [[real]self]{<level>|<priv>} determines
       the access level	or the specific	access privileges the who  field  will
       have.  Its component are	defined	as

	    <level> ::=	none|disclose|auth|compare|search|read|{write|add|delete}|manage
	    <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+

       The  modifier  self allows special operations like having a certain ac-
       cess level or privilege only in case the	operation involves the name of
       the  user  that's  requesting the access.  It implies the user that re-
       quests access is	authorized.  The modifier realself refers to  the  au-
       thenticated  DN	as  opposed to the authorized DN of the	self modifier.
       An example is the selfwrite access to the member	attribute of a	group,
       which  allows  one  to  add/delete its own DN from the member list of a
       group, while being not allowed to affect	other members.

       The level access	model relies on	an incremental interpretation  of  the
       access  privileges.  The	possible levels	are none, disclose, auth, com-
       pare, search, read, write, and manage.  Each access level  implies  all
       the preceding ones, thus	manage grants all access including administra-
       tive access.  The write access is actually the combination of  add  and
       delete,	which  respectively  restrict  the  write  privilege to	add or
       delete the specified <what>.

       The none	access level disallows all access including disclosure on  er-

       The disclose access level allows	disclosure of information on error.

       The  auth access	level means that one is	allowed	access to an attribute
       to perform authentication/authorization operations (e.g.	 bind) with no
       other  access.	This  is  useful  to grant unauthenticated clients the
       least possible access level to critical resources, like passwords.

       The priv	access model relies on the explicit setting of	access	privi-
       leges  for each clause.	The = sign resets previously defined accesses;
       as a consequence, the final access privileges will be  only  those  de-
       fined by	the clause.  The + and - signs add/remove access privileges to
       the existing ones.  The privileges are m	for manage, w for write, a for
       add,  z	for delete, r for read,	s for search, c	for compare, x for au-
       thentication, and d for disclose.  More than one	of  the	 above	privi-
       leges  can be added in one statement.  0	indicates no privileges	and is
       used only by itself (e.g., +0).	Note that +az is equivalent to +w.

       If no access is given, it defaults to +0.

       The optional field <control> controls the flow of access	rule  applica-
       tion.  It can have the forms


       where  stop, the	default, means access checking stops in	case of	match.
       The other two forms are used to keep on processing access clauses.   In
       detail,	the  continue  form allows for other <who> clauses in the same
       <access>	clause to be considered, so that they may result in  incremen-
       tally  altering	the  privileges, while the break form allows for other
       <access>	clauses	that match the same target to be processed.   Consider
       the (silly) example

	    access to dn.subtree="dc=example,dc=com" attrs=cn
		 by * =cs break

	    access to dn.subtree="ou=People,dc=example,dc=com"
		 by * +r

       which  allows  search  and  compare  privileges	to everybody under the
       "dc=example,dc=com" tree, with the second rule allowing	also  read  in
       the "ou=People" subtree,	or the (even more silly) example

	    access to dn.subtree="dc=example,dc=com" attrs=cn
		 by * =cs continue
		 by users +r

       which  grants  everybody	 search	 and compare privileges, and adds read
       privileges to authenticated clients.

       One useful application is to easily grant write privileges to an	updat-
       edn  that is different from the rootdn.	In this	case, since the	updat-
       edn needs write access to (almost) all data, one	can use

	    access to *
		 by dn.exact="cn=The Update DN,dc=example,dc=com" write
		 by * break

       as the first access rule.  As a consequence, unless  the	 operation  is
       performed with the updatedn identity, control is	passed straight	to the
       subsequent rules.

       Operations require different privileges on different  portions  of  en-
       tries.	The  following summary applies to primary MDB database backend
       and the deprecated BDB and HDB backends.	  Requirements for other back-
       ends may	(and often do) differ.

       The  add	operation requires add (=a) privileges on the pseudo-attribute
       entry of	the entry being	added, and add (=a) privileges on the  pseudo-
       attribute children of the entry's parent.  When adding the suffix entry
       of a database, add access to children of	the empty DN ("") is required.
       Also  if	 Add  content ACL checking has been configured on the database
       (see the	slapd.conf(5) or slapd-config(5) manual	page), add  (=a)  will
       be required on all of the attributes being added.

       The  bind  operation, when credentials are stored in the	directory, re-
       quires auth (=x)	privileges on the attribute the	credentials are	stored
       in (usually userPassword).

       The compare operation requires compare (=c) privileges on the attribute
       that is being compared.

       The delete operation requires delete (=z) privileges on the  pseudo-at-
       tribute entry of	the entry being	deleted, and delete (=d) privileges on
       the children pseudo-attribute of	the entry's parent.

       The modify operation requires write (=w)	privileges on  the  attributes
       being  modified.	  In  detail,  add (=a)	is required to add new values,
       delete (=z) is required to delete existing values, and both delete  and
       add (=az), or write (=w), are required to replace existing values.

       The  modrdn  operation requires write (=w) privileges on	the pseudo-at-
       tribute entry of	the entry whose	relative DN is being modified,	delete
       (=z)  privileges	 on  the  pseudo-attribute children of the old entry's
       parents,	add (=a) privileges on the pseudo-attribute  children  of  the
       new entry's parents, and	add (=a) privileges on the attributes that are
       present in the new relative DN.	Delete (=z) privileges	are  also  re-
       quired  on  the	attributes  that are present in	the old	relative DN if
       deleteoldrdn is set to 1.

       The search operation, requires search  (=s)  privileges	on  the	 entry
       pseudo-attribute	 of  the  searchBase  (NOTE:  this was introduced with
       OpenLDAP	2.4).  Then, for each entry, it	requires  search  (=s)	privi-
       leges  on the attributes	that are defined in the	filter.	 The resulting
       entries are finally tested for read (=r)	privileges on  the  pseudo-at-
       tribute	entry  (for read access	to the entry itself) and for read (=r)
       access on each value of each attribute that is  requested.   Also,  for
       each  referral  object  used in generating continuation references, the
       operation requires read (=r) access on the pseudo-attribute entry  (for
       read access to the referral object itself), as well as read (=r)	access
       to the attribute	holding	the referral information  (generally  the  ref

       Some  internal  operations  and	some  controls require specific	access
       privileges.  The	authzID	mapping	and  the  proxyAuthz  control  require
       auth  (=x)  privileges  on  all	the attributes that are	present	in the
       search filter of	the URI	regexp maps (the right-hand side of the	authz-
       regexp  directives).  Auth (=x) privileges are also required on the au-
       thzTo attribute of the authorizing identity and/or on the authzFrom at-
       tribute	of  the	 authorized  identity.	 In  general, when an internal
       lookup is  performed  for  authentication  or  authorization  purposes,
       search-specific	privileges (see	the access requirements	for the	search
       operation illustrated above) are	relaxed	to auth.

       Access control to search	entries	is checked by the frontend, so	it  is
       fully  honored  by  all	backends; for all other	operations and for the
       discovery phase of the search operation,	full  ACL  semantics  is  only
       supported by the	primary	backends, i.e.	back-bdb(5), and back-hdb(5).

       Some  other  backend,  like back-sql(5),	may fully support them;	others
       may only	support	a portion of the described semantics, or  even	differ
       in  some	 aspects.   The	relevant details are described in the backend-
       specific	man pages.

       It is strongly recommended  to  explicitly  use	the  most  appropriate
       <dnstyle>  in  <what>  and  <who>  clauses, to avoid possible incorrect
       specifications of the access rules as well as  for  performance	(avoid
       unnecessary regex matching when an exact	match suffices)	reasons.

       An administrator	might create a rule of the form:

	    access to dn.regex="dc=example,dc=com"
		 by ...

       expecting  it  to match all entries in the subtree "dc=example,dc=com".
       However,	this rule actually matches any DN which	contains anywhere  the
       substring   "dc=example,dc=com".	   That	 is,  the  rule	 matches  both
       "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".

       To match	the desired subtree, the rule would be more precisely written:

	    access to dn.regex="^(.+,)?dc=example,dc=com$"
		 by ...

       For performance reasons,	it would be better to use the subtree style.

	    access to dn.subtree="dc=example,dc=com"
		 by ...

       When writing submatch rules, it may be convenient to avoid  unnecessary
       regex  <dnstyle>	 use;  for instance, to	allow access to	the subtree of
       the user	that matches the <what>	clause,	one could use

	    access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
		 by dn.regex="^uid=$2,dc=example,dc=com$$" write
		 by ...

       However,	since all that is required in the <by> clause is substring ex-
       pansion,	a more efficient solution is

	    access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
		 by dn.exact,expand="uid=$2,dc=example,dc=com" write
		 by ...

       In fact,	while a	<dnstyle> of regex implies substring expansion,	exact,
       as well as all the other	DN specific <dnstyle> values, does not,	so  it
       must be explicitly requested.

	      default slapd configuration file

       slapd(8), slapd-*(5), slapacl(8), regex(7), re_format(7)

       "OpenLDAP Administrator's Guide"	(

       OpenLDAP	 Software  is developed	and maintained by The OpenLDAP Project
       <>.  OpenLDAP Software is derived from the Uni-
       versity of Michigan LDAP	3.3 Release.

OpenLDAP 2.4.57			  2021/01/18		       SLAPD.ACCESS(5)


Want to link to this manual page? Use this URL:

home | help