# $OpenLDAP$
-# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2008 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: The slapd Configuration File
{{slapd.conf}}(5) file, normally installed in the
{{EX:/usr/local/etc/openldap}} directory.
-An alternate configuration file can be specified via a
-command-line option to {{slapd}}(8) or {{slurpd}}(8). This chapter
-describes the general format of the config file, followed by a
-detailed description of commonly used config file directives.
+An alternate configuration file location can be specified via a command-line
+option to {{slapd}}(8). This chapter describes the general format
+of the {{slapd.conf}}(5) configuration file, followed by a detailed
+description of commonly used config file directives.
H2: Configuration File Format
Blank lines and comment lines beginning with a '{{EX:#}}' character
are ignored. If a line begins with white space, it is considered a
-continuation of the previous line. The general format of slapd.conf is
-as follows:
+continuation of the previous line (even if the previous line is a
+comment).
+
+The general format of slapd.conf is as follows:
> # global configuration directives
> <global config directives>
by actual text are shown in brackets {{EX:<>}}.
-H4: access to <what> [ by <who> <accesslevel> <control> ]+
+H4: access to <what> [ by <who> [<accesslevel>] [<control>] ]+
-This directive grants access (specified by <accesslevel>) to a
-set of entries and/or attributes (specified by <what>) by one or
-more requesters (specified by <who>).
-See the {{SECT:Access Control}} section of this chapter for a
-summary of basic usage.
+This directive grants access (specified by <accesslevel>) to a set
+of entries and/or attributes (specified by <what>) by one or more
+requestors (specified by <who>). See the {{SECT:The access
+Configuration Directive}} section of this chapter for a summary of
+basic usage.
!if 0
More details discussion of this directive can be found in the
both authenticated and anonymous users read access.
-H4: attributetype <{{REF:RFC2252}} Attribute Type Description>
+H4: attributetype <{{REF:RFC4512}} Attribute Type Description>
This directive defines an attribute type.
Please see the {{SECT:Schema Specification}} chapter
or consult the table below. The possible values for <integer> are:
!block table; colaligns="RL"; align=Center; \
- title="Table 5.1: Debugging Levels"
+ title="Table 6.1: Debugging Levels"
Level Description
-1 enable all debugging
0 no debugging
E: loglevel 256
-H4: objectclass <{{REF:RFC2252}} Object Class Description>
+H4: objectclass <{{REF:RFC4512}} Object Class Description>
This directive defines an object class.
Please see the {{SECT:Schema Specification}} chapter for
This directive marks the beginning of a backend declaration.
{{EX:<type>}} should be one of the
-supported backend types listed in Table 5.2.
+supported backend types listed in Table 6.2.
!block table; align=Center; coltags="EX,N"; \
title="Table 5.2: Database Backends"
Types Description
bdb Berkeley DB transactional backend
dnssrv DNS SRV backend
+hdb Hierarchical variant of bdb backend
ldap Lightweight Directory Access Protocol (Proxy) backend
-ldbm Lightweight DBM backend
meta Meta Directory backend
monitor Monitor backend
passwd Provides read-only access to {{passwd}}(5)
This directive marks the beginning of a database instance
declaration.
{{EX:<type>}} should be one of the
-supported backend types listed in Table 5.2.
+supported backend types listed in Table 6.2.
\Example:
> readonly off
-H4: replica
-
-> replica host=<hostname>[:<port>]
-> [bindmethod={ simple | kerberos | sasl }]
-> ["binddn=<DN>"]
-> [mech=<mech>]
-> [authcid=<identity>]
-> [authzid=<identity>]
-> [credentials=<password>]
-> [srvtab=<filename>]
-
-This directive specifies a replication site for this database. The
-{{EX:host=}} parameter specifies a host and optionally a port where
-the slave slapd instance can be found. Either a domain name
-or IP address may be used for <hostname>. If <port> is not
-given, the standard LDAP port number (389) is used.
-
-The {{EX:binddn=}} parameter gives the DN to bind as for updates to
-the slave slapd. It should be a DN which has read/write
-access to the slave slapd's database, typically given as a
-{{EX:rootdn}} in the slave's config file. It must also match the
-{{EX:updatedn}} directive in the slave slapd's config file. Since DNs are
-likely to contain embedded spaces, the entire {{EX:"binddn=<DN>"}}
-string should be enclosed in double quotes.
-
-The {{EX:bindmethod}} is {{EX:simple}} or {{EX:kerberos}} or {{EX:sasl}},
-depending on whether simple password-based authentication or Kerberos
-authentication or {{TERM:SASL}} authentication is to be used when connecting
-to the slave slapd.
-
-Simple authentication should not be used unless adequate integrity
-and privacy protections are in place (e.g. TLS or IPSEC). Simple
-authentication requires specification of {{EX:binddn}} and
-{{EX:credentials}} parameters.
-
-Kerberos authentication is deprecated in favor of SASL authentication
-mechanisms, in particular the {{EX:KERBEROS_V4}} and {{EX:GSSAPI}}
-mechanisms. Kerberos authentication requires {{EX:binddn}} and
-{{EX:srvtab}} parameters.
-
-SASL authentication is generally recommended. SASL authentication
-requires specification of a mechanism using the {{EX:mech}} parameter.
-Depending on the mechanism, an authentication identity and/or
-credentials can be specified using {{EX:authcid}} and {{EX:credentials}}
-respectively. The {{EX:authzid}} parameter may be used to specify
-an authorization identity.
-
-See the chapter entitled {{SECT:Replication with slurpd}} for more
-information on how to use this directive.
-
-H4: replogfile <filename>
-
-This directive specifies the name of the replication log file to
-which slapd will log changes. The replication log is typically
-written by slapd and read by slurpd. Normally, this directive is
-only used if slurpd is being used to replicate the database.
-However, you can also use it to generate a transaction log, if
-slurpd is not running. In this case, you will need to periodically
-truncate the file, since it will grow indefinitely otherwise.
-
-See the chapter entitled {{SECT:Replication with slurpd}} for more
-information on how to use this directive.
-
-
-H4: rootdn <dn>
+H4: rootdn <DN>
This directive specifies the DN that is not subject to
access control or administrative limit restrictions for
> rootpw secret
-It is also permissible to provide hash of the password in RFC 2307
+It is also permissible to provide hash of the password in {{REF:RFC2307}}
form. {{slappasswd}}(8) may be used to generate the password hash.
\Example:
order they appear in the file. Thus, if one database suffix is a
prefix of another, it must appear after it in the config file.
-H4: updatedn <dn>
-This directive is only applicable in a slave slapd. It specifies
-the DN allowed to make changes to the replica. This may be the DN
-{{slurpd}}(8) binds as when making changes to the replica or the DN
-associated with a SASL identity.
+H4: syncrepl
+
+> syncrepl rid=<replica ID>
+> provider=ldap[s]://<hostname>[:port]
+> [type=refreshOnly|refreshAndPersist]
+> [interval=dd:hh:mm:ss]
+> [retry=[<retry interval> <# of retries>]+]
+> searchbase=<base DN>
+> [filter=<filter str>]
+> [scope=sub|one|base]
+> [attrs=<attr list>]
+> [attrsonly]
+> [sizelimit=<limit>]
+> [timelimit=<limit>]
+> [schemachecking=on|off]
+> [bindmethod=simple|sasl]
+> [binddn=<DN>]
+> [saslmech=<mech>]
+> [authcid=<identity>]
+> [authzid=<identity>]
+> [credentials=<passwd>]
+> [realm=<realm>]
+> [secprops=<properties>]
+
+
+This directive specifies the current database as a replica of the
+master content by establishing the current {{slapd}}(8) as a
+replication consumer site running a syncrepl replication engine.
+The master database is located at the replication provider site
+specified by the {{EX:provider}} parameter. The replica database is
+kept up-to-date with the master content using the LDAP Content
+Synchronization protocol. See {{REF:RFC4533}}
+for more information on the protocol.
+
+The {{EX:rid}} parameter is used for identification of the current
+{{EX:syncrepl}} directive within the replication consumer server,
+where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
+described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
+is non-negative and is no more than three decimal digits in length.
+
+The {{EX:provider}} parameter specifies the replication provider site
+containing the master content as an LDAP URI. The {{EX:provider}}
+parameter specifies a scheme, a host and optionally a port where the
+provider slapd instance can be found. Either a domain name or IP
+address may be used for <hostname>. Examples are
+{{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
+If <port> is not given, the standard LDAP port number (389 or 636) is used.
+Note that the syncrepl uses a consumer-initiated protocol, and hence its
+specification is located at the consumer site, whereas the {{EX:replica}}
+specification is located at the provider site. {{EX:syncrepl}} and
+{{EX:replica}} directives define two independent replication
+mechanisms. They do not represent the replication peers of each other.
+
+The content of the syncrepl replica is defined using a search
+specification as its result set. The consumer slapd will
+send search requests to the provider slapd according to the search
+specification. The search specification includes {{EX:searchbase}},
+{{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}},
+{{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
+search specification. The {{EX:searchbase}} parameter has no
+default value and must always be specified. The {{EX:scope}} defaults
+to {{EX:sub}}, the {{EX:filter}} defaults to {{EX:(objectclass=*)}},
+{{EX:attrs}} defaults to {{EX:"*,+"}} to replicate all user and operational
+attributes, and {{EX:attrsonly}} is unset by default. Both {{EX:sizelimit}}
+and {{EX:timelimit}} default to "unlimited", and only integers
+or "unlimited" may be specified.
+
+The LDAP Content Synchronization protocol has two operation
+types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
+The operation type is specified by the {{EX:type}} parameter.
+In the {{EX:refreshOnly}} operation, the next synchronization search operation
+is periodically rescheduled at an interval time after each
+synchronization operation finishes. The interval is specified
+by the {{EX:interval}} parameter. It is set to one day by default.
+In the {{EX:refreshAndPersist}} operation, a synchronization search
+remains persistent in the provider slapd. Further updates to the
+master replica will generate {{EX:searchResultEntry}} to the consumer slapd
+as the search responses to the persistent synchronization search.
+
+If an error occurs during replication, the consumer will attempt to reconnect
+according to the retry parameter which is a list of the <retry interval>
+and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer
+retry every 60 seconds for the first 10 times and then retry every 300 seconds
+for the next three times before stop retrying. + in <# of retries> means
+indefinite number of retries until success.
+
+The schema checking can be enforced at the LDAP Sync consumer site
+by turning on the {{EX:schemachecking}} parameter.
+If it is turned on, every replicated entry will be checked for its
+schema as the entry is stored into the replica content.
+Every entry in the replica should contain those attributes
+required by the schema definition.
+If it is turned off, entries will be stored without checking
+schema conformance. The default is off.
+
+The {{EX:binddn}} parameter gives the DN to bind as for the
+syncrepl searches to the provider slapd. It should be a DN
+which has read access to the replication content in the
+master database.
+
+The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
+depending on whether simple password-based authentication or
+{{TERM:SASL}} authentication is to be used when connecting
+to the provider slapd.
+
+Simple authentication should not be used unless adequate data
+integrity and confidentiality protections are in place (e.g. TLS
+or IPsec). Simple authentication requires specification of {{EX:binddn}}
+and {{EX:credentials}} parameters.
-Entry-based Example:
+SASL authentication is generally recommended. SASL authentication
+requires specification of a mechanism using the {{EX:saslmech}} parameter.
+Depending on the mechanism, an authentication identity and/or
+credentials can be specified using {{EX:authcid}} and {{EX:credentials}},
+respectively. The {{EX:authzid}} parameter may be used to specify
+an authorization identity.
-> updatedn "cn=Update Daemon,dc=example,dc=com"
+The {{EX:realm}} parameter specifies a realm which a certain
+mechanisms authenticate the identity within. The {{EX:secprops}}
+parameter specifies Cyrus SASL security properties.
-SASL-based Example:
+The syncrepl replication mechanism is supported by the two primary
+database backends: back-bdb and back-hdb.
-> updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
+See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
+for more information on how to use this directive.
-See the {{SECT:Replication with slurpd}} chapter for more information
-on how to use this directive.
H4: updateref <URL>
-This directive is only applicable in a slave slapd. It
+This directive is only applicable in a {{slave}} (or {{shadow}})
+{{slapd}}(8) instance. It
specifies the URL to return to clients which submit update
requests upon the replica.
If specified multiple times, each {{TERM:URL}} is provided.
> updateref ldap://master.example.net
-H3: BDB Database Directives
+H3: BDB and HDB Database Directives
-Directives in this category only apply to a {{TERM:BDB}} database.
-That is, they must follow a "database bdb" line and come before any
+Directives in this category only apply to both the {{TERM:BDB}}
+and the {{TERM:HDB}} database.
+That is, they must follow a "database bdb" or "database hdb" line
+and come before any
subsequent "backend" or "database" line. For a complete reference
-of BDB configuration directives, see {{slapd-bdb}}(5).
-
-H4: directory <directory>
-
-This directive specifies the directory where the BDB files
-containing the database and associated indices live.
-
-\Default:
-
-> directory /usr/local/var/openldap-data
-
-
-H3: LDBM Database Directives
-
-Directives in this category only apply to a {{TERM:LDBM}} database.
-That is, they must follow a "database ldbm" line and come before
-any subsequent "backend" or "database" line. For a complete reference
-of LDBM configuration directives, see {{slapd-ldbm}}(5).
-
-H4: cachesize <integer>
-
-This directive specifies the size in entries of the in-memory
-cache maintained by the LDBM backend database instance.
-
-\Default:
-
-> cachesize 1000
-
-
-H4: dbcachesize <integer>
-
-This directive specifies the size in bytes of the in-memory cache
-associated with each open index file. If not supported by the
-underlying database method, this directive is ignored without
-comment. Increasing this number uses more memory but can
-cause a dramatic performance increase, especially during
-modifies or when building indices.
-
-\Default:
-
-> dbcachesize 100000
-
-
-H4: dbnolocking
-
-This option, if present, disables database locking.
-Enabling this option may improve performance at the expense
-of data security.
-
-
-H4: dbnosync
-
-This option causes on-disk database contents to not be immediately
-synchronized with in memory changes upon change. Enabling this option
-may improve performance at the expense of data integrity.
+of BDB/HDB configuration directives, see {{slapd-bdb}}(5).
H4: directory <directory>
-This directive specifies the directory where the LDBM files
+This directive specifies the directory where the BDB files
containing the database and associated indices live.
\Default:
> directory /usr/local/var/openldap-data
-H4: index {<attrlist> | default} [pres,eq,approx,sub,none]
-
-This directive specifies the indices to maintain for the given
-attribute. If only an {{EX:<attrlist>}} is given, the default
-indices are maintained.
-
-\Example:
-
-> index default pres,eq
-> index uid
-> index cn,sn pres,eq,sub
-> index objectClass eq
-
-The first line sets the default set of indices to maintain to
-present and equality. The second line causes the default (pres,eq)
-set of indices to be maintained for the {{EX:uid}} attribute type.
-The third line causes present, equality, and substring indices to
-be maintained for {{EX:cn}} and {{EX:sn}} attribute types. The
-fourth line causes an equality index for the {{EX:objectClass}}
-attribute type.
-
-By default, no indices are maintained. It is generally advised
-that minimally an equality index upon objectClass be maintained.
-
-> index objectClass eq
+H2: The access Configuration Directive
-
-
-H4: mode <integer>
-
-This directive specifies the file protection mode that newly
-created database index files should have.
-
-\Default:
-
-> mode 0600
-
-
-H2: Access Control
-
-Access to slapd entries and attributes is controlled by the
+Access to entries and attributes is controlled by the
access configuration file directive. The general form of an
access line is:
> <access directive> ::= access to <what>
-> [by <who> <access> <control>]+
+> [by <who> [<access>] [<control>] ]+
> <what> ::= * |
> [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
> [filter=<ldapfilter>] [attrs=<attrlist>]
> <basic-style> ::= regex | exact
> <scope-style> ::= base | one | subtree | children
-> <attrlist> ::= <attr> | <attr> , <attrlist>
+> <attrlist> ::= <attr>
[val[.<basic-style>]=<regex>] | <attr> , <attrlist>
> <attr> ::= <attrname> | entry | children
> <who> ::= * | [anonymous | users | self
> | dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
> [set=<setspec>]
> [aci=<attrname>]
> <access> ::= [self]{<level>|<priv>}
-> <level> ::= none | auth | compare | search | read | write
-> <priv> ::= {=|+|-}{w|r|s|c|x}+
+> <level> ::= none | disclose | auth | compare | search | read | write | manage
+> <priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
> <control> ::= [stop | continue | break]
where the <what> part selects the entries and/or attributes to which
The <what> part of an access specification determines the entries
and attributes to which the access control applies. Entries are
-commonly selected in two ways: by DN and by filter.
+commonly selected in two ways: by DN and by filter. The following
+qualifiers select entries by DN:
-> by *
-> by dn[.<basic-style>]=<regex>
-> by dn.<scope-style>=<DN>
+> to *
+> to dn[.<basic-style>]=<regex>
+> to dn.<scope-style>=<DN>
The first form is used to select all entries. The second form may
be used to select entries by matching a regular expression against
the target entry's {{normalized DN}}. (The second form is not
discussed further in this document.) The third form is used to
-select entries which are within the requested scope of DN.
+select entries which are within the requested scope of DN. The
+<DN> is a string representation of the Distinguished Name, as
+described in {{REF:RFC4514}}.
The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
or {{EX:children}}. Where {{EX:base}} matches only the entry with
Entries may also be selected using a filter:
-> by filter=<ldap filter>
+> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
-search filter, as described in {{REF:RFC2254}}. For example:
+search filter, as described in {{REF:RFC4515}}. For example:
-> by filter=(objectClass=person)
+> to filter=(objectClass=person)
-Note that entries by be select by both DN and filter by
-include both qualifiers in the <what> clause.
+Note that entries may be selected by both DN and filter by
+including both qualifiers in the <what> clause.
-> by dn.one="ou=people,o=suffix" filter=(objectClass=person)
+> to dn.one="ou=people,o=suffix" filter=(objectClass=person)
Attributes within an entry are selected by including a comma-separated
list of attribute names in the <what> selector:
> attrs=<attribute list>
-There are two special {{psuedo}} attributes {{EX:entry}} and
-{{EX:children}}. To read (and hence return) an target entry, the
+A specific value of an attribute is selected by using a single
+attribute name and also using a value selector:
+
+> attrs=<attribute> val[.<style>]=<regex>
+
+There are two special {{pseudo}} attributes {{EX:entry}} and
+{{EX:children}}. To read (and hence return) a target entry, the
subject must have {{EX:read}} access to the target's {{entry}}
attribute. To add or delete an entry, the subject must have
-{{EX:write}} access to the entry's parent's {{EX:children}} attribute.
-To rename an entry, the subject must have {{EX:write}} access to
-both the old parent's and new parent's {{EX:children}} attributes.
-The complete examples at the end of this section should help clear
-things up.
+{{EX:write}} access to the entry's {{EX:entry}} attribute AND must
+have {{EX:write}} access to the entry's parent's {{EX:children}}
+attribute. To rename an entry, the subject must have {{EX:write}}
+access to entry's {{EX:entry}} attribute AND have {{EX:write}}
+access to both the old parent's and new parent's {{EX:children}}
+attributes. The complete examples at the end of this section should
+help clear things up.
Lastly, there is a special entry selector {{EX:"*"}} that is used to
select any entry. It is used when no other {{EX:<what>}}
The following table summarizes entity specifiers:
!block table; align=Center; coltags="EX,N"; \
- title="Table 5.3: Access Entity Specifiers"
+ title="Table 6.3: Access Entity Specifiers"
Specifier|Entities
*|All, including anonymous and authenticated users
anonymous|Anonymous (non-authenticated) users
The DN specifier behaves much like <what> clause DN specifiers.
-Other control factors are also supported.
-For example, a {{EX:<who>}} can be restricted by a
-regular expression matching the client's domain name:
-
-> domain=<regular expression>
-
-or by an entry listed in a DN-valued attribute in the entry to
-which the access applies:
+Other control factors are also supported. For example, a {{EX:<who>}}
+can be restricted by an entry listed in a DN-valued attribute in
+the entry to which the access applies:
> dnattr=<dn-valued attribute name>
access to a group entry to whoever is listed as the owner of
the group entry).
+Some factors may not be appropriate in all environments (or any).
+For example, the domain factor relies on IP to domain name lookups.
+As these can easily be spoofed, the domain factor should be avoided.
-H3: The access to grant
+H3: The access to grant
The kind of <access> granted can be one of the following:
-
!block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
- title="Table 5.4: Access Levels"
-Level Privileges Description
-none no access
-auth =x needed to bind
-compare =cx needed to compare
-search =scx needed to apply search filters
-read =rscx needed to read search results
-write =wrscx needed to modify/rename
+ title="Table 6.4: Access Levels"
+Level Privileges Description
+none =0 no access
+disclose =d needed for information disclosure on error
+auth =dx needed to authenticate (bind)
+compare =cdx needed to compare
+search =scdx needed to apply search filters
+read =rscdx needed to read search results
+write =wrscdx needed to modify/rename
+manage =mwrscdx needed to manage
!endblock
-Each level implies all lower levels of access. So, for
-example, granting someone {{EX:write}} access to an entry also
-grants them {{EX:read}}, {{EX:search}}, {{EX:compare}}, and
-{{EX:auth}} access. However, one may use the privileges specifier
+Each level implies all lower levels of access. So, for example,
+granting someone {{EX:write}} access to an entry also grants them
+{{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
+{{EX:disclose}} access. However, one may use the privileges specifier
to grant specific permissions.
H3: Access Control Examples
-The access control facility described above is quite powerful.
-This section shows some examples of its use. First, some
-simple examples:
+The access control facility described above is quite powerful. This
+section shows some examples of its use for descriptive purposes.
+
+A simple example:
> access to * by * read
> by anonymous auth
> by * read
-This directive allows users to modify their own entries, allows
-authenticate, and allows all others to read. Note that only the
-first {{EX:by <who>}} clause which matches applies. Hence, the
-anonymous users are granted {{EX:auth}}, not {{EX:read}}. The last
-clause could just as well have been "{{EX:by users read}}".
+This directive allows the user to modify their entry, allows anonymous
+to authentication against these entries, and allows all others to
+read these entries. Note that only the first {{EX:by <who>}} clause
+which matches applies. Hence, the anonymous users are granted
+{{EX:auth}}, not {{EX:read}}. The last clause could just as well
+have been "{{EX:by users read}}".
It is often desirable to restrict operations based upon the level
of protection in place. The following shows how security strength
This directive allows users to modify their own entries if security
protections have of strength 128 or better have been established,
-allows simple authentication and read access when 64 or better
-security protections have been established.
+allows authentication access to anonymous users, and read access
+when 64 or better security protections have been established. If
+client has not establish sufficient security protections, the
+implicit {{EX:by * none}} clause would be applied.
-The following example shows the use of a regular expression
-to select the entries by DN in two access directives where
-ordering is significant.
+The following example shows the use of a style specifiers to select
+the entries by DN in two access directives where ordering is
+significant.
> access to dn.children="dc=example,dc=com"
> by * search
shows the use of an attribute selector to grant access to a specific
attribute and various {{EX:<who>}} selectors.
-> access to dn.subtree="dc=example,dc=com" attr=homePhone
+> access to dn.subtree="dc=example,dc=com" attrs=homePhone
> by self write
-> by dn.children=dc=example,dc=com" search
-> by domain=.*\.example\.com read
+> by dn.children="dc=example,dc=com" search
+> by peername.regex=IP:10\..+ read
> access to dn.subtree="dc=example,dc=com"
> by self write
> by dn.children="dc=example,dc=com" search
excepting for authentication/authorization (which is always done
anonymously). The {{EX:homePhone}} attribute is writable by the
entry, searchable by entries under {{EX:example.com}}, readable by
-clients connecting from somewhere in the {{EX:example.com}} domain,
-and otherwise not readable (implicit {{EX:by * none}}). All other
-access is denied by the implicit {{EX:access to * by * none}}.
+clients connecting from network 10, and otherwise not readable
+(implicit {{EX:by * none}}). All other access is denied by the
+implicit {{EX:access to * by * none}}.
Sometimes it is useful to permit a particular DN to add or
remove itself from an attribute. For example, if you would like to
their own DN from the member attribute, you could accomplish
it with an access directive like this:
-> access to attr=member,entry
+> access to attrs=member,entry
> by dnattr=member selfwrite
The dnattr {{EX:<who>}} selector says that the access applies to
E: 8. directory /usr/local/var/openldap-data
E: 9. rootdn "cn=Manager,dc=example,dc=com"
E: 10. rootpw secret
-E: 11. # replication directives
-E: 12. replogfile /usr/local/var/openldap/slapd.replog
-E: 13. replica host=slave1.example.com:389
-E: 14. binddn="cn=Replicator,dc=example,dc=com"
-E: 15. bindmethod=simple credentials=secret
-E: 16. replica host=slave2.example.com
-E: 17. binddn="cn=Replicator,dc=example,dc=com"
-E: 18. bindmethod=simple credentials=secret
-E: 19. # indexed attribute definitions
-E: 20. index uid pres,eq
-E: 21. index cn,sn,uid pres,eq,approx,sub
-E: 22. index objectClass eq
-E: 23. # database access control definitions
-E: 24. access to attr=userPassword
-E: 25. by self write
-E: 26. by anonymous auth
-E: 27. by dn.base="cn=Admin,dc=example,dc=com" write
-E: 28. by * none
-E: 29. access to *
-E: 30. by self write
-E: 31. by dn.base="cn=Admin,dc=example,dc=com" write
-E: 32. by * read
+E: 11. # indexed attribute definitions
+E: 12. index uid pres,eq
+E: 13. index cn,sn,uid pres,eq,approx,sub
+E: 14. index objectClass eq
+E: 15. # database access control definitions
+E: 16. access to attrs=userPassword
+E: 17. by self write
+E: 18. by anonymous auth
+E: 19. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 20. by * none
+E: 21. access to *
+E: 22. by self write
+E: 23. by dn.base="cn=Admin,dc=example,dc=com" write
+E: 24. by * read
Line 5 is a comment. The start of the database definition is marked
by the database keyword on line 6. Line 7 specifies the DN suffix
password. This entry is not subject to access control or size or
time limit restrictions.
-Lines 11 through 18 are for replication. Line 12 specifies the
-replication log file (where changes to the database are logged -
-this file is written by slapd and read by slurpd). Lines 13 through
-15 specify the hostname and port for a replicated host, the DN to
-bind as when performing updates, the bind method (simple) and the
-credentials (password) for the binddn. Lines 16 through 18 specify
-a second replication site. See the {{SECT:Replication with slurpd}}
-chapter for more information on these directives.
-
-Lines 20 through 22 indicate the indices to maintain for various
+Lines 12 through 14 indicate the indices to maintain for various
attributes.
-Lines 24 through 32 specify access control for entries in this
+Lines 16 through 24 specify access control for entries in this
database. As this is the first database, the controls also apply
to entries not held in any database (such as the Root DSE). For
all applicable entries, the {{EX:userPassword}} attribute is writable
projects / openldap / blobdiff