X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=doc%2Fguide%2Fadmin%2Fslapdconfig.sdf;h=7b6bf2464c9e85849190237aca9b42dcf7620428;hb=14745b74d29fe80f2988908b3f3fa3a4532937d9;hp=5f58324bb44286853fe1032e90843795296be94c;hpb=bdd0c38571bf81dc245f49e2b6615ea77771d52e;p=openldap diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf index 5f58324bb4..7b6bf2464c 100644 --- a/doc/guide/admin/slapdconfig.sdf +++ b/doc/guide/admin/slapdconfig.sdf @@ -1,5 +1,5 @@ # $OpenLDAP$ -# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved. +# Copyright 1999-2003, The OpenLDAP Foundation, All Rights Reserved. # COPYING RESTRICTIONS APPLY, see COPYRIGHT. H1: The slapd Configuration File @@ -92,11 +92,16 @@ set of entries and/or attributes (specified by ) by one or more requesters (specified by ). See the {{SECT:Access Control}} section of this chapter for a summary of basic usage. + !if 0 More details discussion of this directive can be found in the {{SECT:Advanced Access Control}} chapter. !endif +Note: If no {{EX:access}} directives are specified, the default +access control policy, {{EX:access to * by * read}}, allows all +both authenticated and anonymous users read access. + H4: attributetype <{{REF:RFC2252}} Attribute Type Description> @@ -104,23 +109,6 @@ This directive defines an attribute type. Please see the {{SECT:Schema Specification}} chapter for information regarding how to use this directive. -H4: defaultaccess { none | compare | search | read | write } - -This directive specifies the default access to grant requesters -when no {{EX:access}} directives have been specified. Any given -access level implies all lesser access levels (e.g., read access -implies search and compare but not write). - -Note: It is recommend that the {{EX:access}} directive be used -to specify access control. See the {{SECT:Access Control}} -section of this chapter for information regarding the {{EX:access}} -directive. - -\Default: - -E: defaultaccess read - - H4: idletimeout Specify the number of seconds to wait before forcibly closing @@ -246,15 +234,14 @@ supported backend types listed in Table 5.2. Types Description bdb Berkeley DB transactional backend dnssrv DNS SRV backend -ldbm Lightweight DBM 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) perl Perl Programmable backend shell Shell (extern program) backend sql SQL Programmable backend -tcl TCL Programmable backend !endblock \Example: @@ -298,9 +285,9 @@ perform" error. H4: replica > replica host=[:] -> [bindmethod={ simple | kerberos | sasl }] +> [bindmethod={simple|kerberos|sasl}] > ["binddn="] -> [mech=] +> [saslmech=] > [authcid=] > [authzid=] > [credentials=] @@ -336,7 +323,7 @@ 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. +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 @@ -365,8 +352,8 @@ H4: rootdn This directive specifies the DN that is not subject to access control or administrative limit restrictions for operations on this database. The DN need not refer to -an entry in the directory. The DN may refer to a SASL -identity. +an entry in this database or even in the directory. The +DN may refer to a SASL identity. Entry-based Example: @@ -376,18 +363,28 @@ SASL-based Example: > rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth" +See the {{SECT:SASL Authentication}} section for information on +SASL authentication identities. + H4: rootpw -This directive specifies a password for the DN given above that -will always work, regardless of whether an entry with the given -DN exists or has a password. -This directive is deprecated in favor of SASL based authentication. +This directive can be used to specifies a password for the DN for +the rootdn (when the rootdn is set to a DN within the database). \Example: > rootpw secret +It is also permissible to provide hash of the password in RFC 2307 +form. {{slappasswd}}(8) may be used to generate the password hash. + +\Example: + +> rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN + +The hash was generated using the command {{EX:slappasswd -s secret}}. + H4: suffix @@ -408,6 +405,79 @@ looks at the suffix line(s) in each database definition in the 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: syncrepl + +> syncrepl id= +> provider=ldap[s]://[:port] +> [updatedn=] +> [binddn=] +> [bindmethod=simple|sasl] +> [binddn=] +> [credentials=] +> [saslmech=] +> [secprops=] +> [realm=] +> [authcId=] +> [authzId=] +> [searchbase=] +> [filter=] +> [attrs=] +> [scope=sub|one|base] +> [schemachecking=on|off] +> [type=refreshOnly|refreshAndPersist] +> [interval=dd:hh:mm] + +This directive specifies an LDAP Sync replication between this +database and the specified replication provider site. The id= +parameter identifies the LDAP Sync specification in the database. +The {{EX:provider=}} parameter specifies a replication provider site as +an LDAP URI. + +The LDAP Sync replication specification is based on the search +specification which defines the content of the replica. The replica +consists of the entries matching the search specification. As with +the normal searches, the search specification consists of +{{EX:searchbase}}, {{EX:scope}}, {{EX:filter}}, and EX:attrs}} +parameters. + +The LDAP Sync replication has two types of operating modes. In the +{{EX:refreshOnly}} mode, the next synchronization session is +rescheduled at the interval time after the current session finishes. +The default interval is set to one day. In the {{EX:refreshAndPersist}} +mode, the LDAP Sync search remains persistent in the provider LDAP +server. Further updates to the provider replica will generate +searchResultEntry to the consumer. + +The schema checking can be enforced at the LDAP Sync consumer site +by turning on the {{EX:schemachecking}} parameter. The default is off. + +The {{EX:binddn=}} parameter gives the DN for the LDAP Sync search +to bind as to the provider slapd. The content of the replica will +be subject to the access control privileges of the DN. + +The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}}, depending +on whether simple password-based authentication or SASL authentication +is to be used when connecting to the provider slapd. + +Simple authentication should not be used unless adequate integrity +and data confidential protections are in place (e.g. TLS or IPSEC). +Simple authentication requires specification of {{EX:binddn}} and +{{EX:credentials}} 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 +a proxy authorization identity. + +The LDAP Sync replication is supported in three native backends: +back-bdb, back-hdb, and back-ldbm. + +See the {{SECT:LDAP Sync Replication}} chapter for more information +on how to use this directive. + + H4: updatedn This directive is only applicable in a slave slapd. It specifies @@ -440,9 +510,10 @@ If specified multiple times, each {{TERM:URL}} is provided. H3: BDB Database Directives -Directives in this category only apply to a BDB database. That is, -they must follow a "database bdb" line and come before any -subsequent "backend" or "database" line. +Directives in this category only apply to a {{TERM:BDB}} database. +That is, they must follow a "database bdb" line and come before any +subsequent "backend" or "database" line. For a complete reference +of BDB configuration directives, see {{slapd-bdb}}(5). H4: directory @@ -456,9 +527,10 @@ containing the database and associated indices live. H3: LDBM Database Directives -Directives in this category only apply to a LDBM database. That is, -they must follow a "database ldbm" line and come before any -subsequent "backend" or "database" line. +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 @@ -554,72 +626,115 @@ access line is: > ::= access to > [by ]+ -> ::= * | [ dn[.]=] +> ::= * | +> [dn[.]= | dn.=] > [filter=] [attrs=] -> ::= regex | exact | base | one | subtree | children -> ::= | , +> ::= regex | exact +> ::= base | one | subtree | children +> ::= [val[.]=] | , > ::= | entry | children -> ::= [* | anonymous | users | self | -> dn[.]=] -> [dnattr= ] -> [group[/[/][.]]= ] -> [peername[.]=] -> [sockname[.]=] -> [domain[.]=] -> [sockurl[.]=] +> ::= * | [anonymous | users | self +> | dn[.]= | dn.=] +> [dnattr=] +> [group[/[/][.]]=] +> [peername[.]=] +> [sockname[.]=] +> [domain[.]=] +> [sockurl[.]=] > [set=] > [aci=] -> ::= regex | exact > ::= [self]{|} > ::= none | auth | compare | search | read | write > ::= {=|+|-}{w|r|s|c|x}+ > ::= [stop | continue | break] -where the part selects the entries and/or attributes to -which the access applies, the {{EX:}} part specifies which -entities are granted access, and the {{EX:}} part specifies -the access granted. Multiple {{EX: }} triplets -are supported, allowing many entities to be granted different -access to the same set of entries and attributes. Not all of these -access control options are described here; for more details see -the {{slapd.access}}(5) man page. +where the part selects the entries and/or attributes to which +the access applies, the {{EX:}} part specifies which entities +are granted access, and the {{EX:}} part specifies the +access granted. Multiple {{EX: }} triplets +are supported, allowing many entities to be granted different access +to the same set of entries and attributes. Not all of these access +control options are described here; for more details see the +{{slapd.access}}(5) man page. H3: What to control access to -The part of an access specification determines the -entries and attributes to which the access control applies. -Entries can be selected in two ways: by a regular expression -matching the entry's distinguished name: +The 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. The following +qualifiers select entries by DN: + +> by * +> by dn[.]= +> by dn.= -> 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. The + is a string representation of the Distinguished Name, as +described in {{REF:RFC2253}}. -Note: The DN pattern specified should be "normalized" to the RFC2253 -restricted DN form. In particular, there should be no extra spaces -and commas should be used to separate components. An example -normalized DN is "{{EX:cn=Babs Jensen,dc=example,dc=com}}". An -example of a non-normalized DN is "{{EX:cn=Babs Jensen; dc=example; -dc=com}}". +The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}}, +or {{EX:children}}. Where {{EX:base}} matches only the entry with +provided DN, {{EX:one}} matches the entries whose parent is the +provided DN, {{EX:subtree}} matches all entries in the subtree whose +root is the provided DN, and {{EX:children}} matches all entries +under the DN (but not the entry named by the DN). -Or, entries may be selected by a filter matching some -attribute(s) in the entry: +For example, if the directory contained entries named: -> filter= +> 0: o=suffix +> 1: cn=Manager,o=suffix +> 2: ou=people,o=suffix +> 3: uid=kdz,ou=people,o=suffix +> 4: cn=addresses,uid=kdz,ou=people,o=suffix +> 5: uid=hyc,ou=people,o=suffix + +\Then: +. {{EX:dn.base="ou=people,o=suffix"}} match 2; +. {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5; +. {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and +. {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5. + + +Entries may also be selected using a filter: + +> by filter= where is a string representation of an LDAP -search filter, as described in {{REF:RFC2254}}. +search filter, as described in {{REF:RFC2254}}. For example: + +> by filter=(objectClass=person) + +Note that entries may be selected by both DN and filter by +including both qualifiers in the clause. -Attributes within an entry are selected by including a -comma-separated list of attribute names in the -selector: +> by 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 selector: > attrs= -Access to the entry itself must be granted or denied using the -special attribute name "{{EX:entry}}". Note that giving access to an -attribute is not enough; access to the entry itself through the -{{EX:entry}} attribute is also required. The complete examples at -the end of this section should help clear things up. +A specific value of an attribute is selected by using a single +attribute name and also using a value selector: + +> attrs= val[.