LDAP配置

LDAP配置

本部分详细描述了经常使用的配置指令。要得到完整的列表，请参阅slapd.conf(5)的手册页。本部分将配置文件指令划分为全局的，特定后台的和特定数据的类别，描述了每一个指令和它的默认值，并且给出了使用示例。

本部分描述的指令应用于所有的后台和数据库，除非在后台或者数据库的定义中被明确覆盖。应该被实际文本替换的参数放在尖括号<>中。

1.1、 access to [ by ]+

此指令将访问一组由描述的条目或者属性，并且具有由指明的存取控制权限，赋予一个或者多个由描述的请求者。参考本章的“”部分获得基本的使用信息。

1.2、 attributetype < Attribute Type Description>

此指令定义了一个属性类型。请参考“”一章获取如何使用此指令的更详细的信息

1.3、 defaultaccess { none | compare | search | read | write }

此指令说明了当没有存取控制指令说明的时候，默认的存取权限。任何给定的存取级别隐含了更低的级别。比如，读权限隐含了搜索和比较的权限，但是，不包含写权限。

注意：推荐使用access指令来设置存取控制。有关access指令的详细信息，参阅本章的“”部分。

缺省值：

defaultaccess read

1.4、 idletimeout

此指令说明强制关闭一个非活动状态的客户连接之前等待的秒数。默认情况下，该时间等于0，禁止该特性。

1.5、 include

此指令说明slapd在继续当前文件的下一行之前，应该从指定的文件读取附加的配置信息。被包含的文件应该符合正常的slapd配置文件的格式。该文件通常被用来包含模式说明。

注意：在使用该指令的时候应该小心。因为对于嵌套的引入指令的最小数量没有限制，并且，没有循环引用的检测。

1.6、 loglevel

该指令说明了调试语句和操作统计的日志级别。（当前，日志记录到syslogd(8){EX:LOG_LOCAL4}）应用程序）。在此选项工作之前，必须使用—enable-debug选项配置了OpenLDAP。（除了两个统计级别，它们总是被使用）。日志级别是附加的。要显示那一个数字和什么级别的调试相关联，使用-?运行slapd或者参考下面的表格。可能的数值包括：

Table 5.1: Debugging Levels
Level	Description
-1	enable all debugging
0	no debugging
1	trace function calls
2	debug packet handling
4	heavy trace debugging
8	connection management
16	print out packets sent and received
32	search filter processing
64	configuration file processing
128	access control list processing
256	stats log connections/operations/results
512	stats log entries sent
1024	print communication with shell backends
2048	print entry parsing debugging

示例：

loglevel –1

将记录许多许多的调试信息。

缺省值：

loglevel 256

1.7、 objectclass < Object Class Description>

该指令定义了一个对象类。请参考“”一章获得如何使用该指令的更多信息。

1.8、 referral

该指令说明了当slapd处理请求时，如果不能在本地数据库中找到信息，将返回的引用。

示例：

referral ldap://root.openldap.org

这将引用一个非本地的请求到OpenLDAP项目的全局根LDAP服务器。具有智能的LDAP客户端可以向该服务器重新提交请求。但是请注意，大多数客户端只是知道如何处理简单的包含一个主机部分和一个DN（distinguished name）部分的LDAP URL。

1.9、 sizelimit

该指令说明了一个搜索操作所能返回的最大条目的数量。

缺省值：

sizelimit 500

1.10、 timelimit

该指令说明了slapd应答搜索请求的时候花费的最长秒数。如果一个请求在该时间内没有结束，会返回一个表示超时的结果。

缺省值：

timelimit 3600

本部分说明的指令只应用于定义它们的后端。它们被所有类型的后端所支持。后端指令应用于所有相同类型的数据库实例，并且，根据不同的指令，可以被数据库指令覆盖。

2.1、 backend

该指令表示一个后端声明的开始。应该是bdb或者是其他受支持的后端类型中的一种。这些类型在表5.2种列出：

Table 5.2: Database Backends
Types	Description
bdb	Berkeley DB transactional backend
dnssrv	DNS SRV backend
ldbm	Lightweight DBM backend
ldap	Lightweight Directory Access Protocol (Proxy) 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
tcp	TCP Programmable backend

示例：

database bdb

这说明了一个新的BDB后端声明的开始。

2.3、 通用数据库指令

本部分说明的指令只应用于定义它们的数据库。它们被每一种类型的数据库所支持。

2.3.1、 database

此指令表示一个数据库实例声明的开始。可以是bdb或者是其他受支持的后端类型中的一种。这些类型在表5.2种列出。

示例：

database bdb

这说明了一个新的数据库实例声明的开始。

2.3.2、 readonly { on | off }

此指令将数据库设置为“只读”状态。任何试图修改数据库的操作将返回“unwilling to perform”错误。

缺省值：

readonly off

2.3.3、 replica

replica host=[:]

                [bindmethod={ simple | kerberos | sasl }]

                ["binddn="]

                [mech=]

                [authcid=]

                [authzid=]

                [credentials=]

                [srvtab=]

此指令说明了一个该数据库的一个复制站点。host=参数说明了一个主机和一个可选的端口，此主机上运行了一个附属slapd实例。对于可以指定域名或者IP地址。如果没有指定，使用标准的LDAP端口（389）。

binddn=参数给出了更新附属slapd时绑定的DN。该DN应该具有对附属slapd数据库的读/写权限，通常给定一个在附属slapd的配置文件中指定的rootdn。它必须和附属slapd的配置文件中指出的updatedn相匹配。因为DN很可能会包含空格，因此，整个"binddn="字符串应该包含在双引号中。

bindmethod应该是simple或者kerberos或者sasl。取决于当连接到附属slapd时是使用了简单的口令认证，或者是Kerberos认证或SASL认证。

除非存在足够的安全性和秘密保护措施（比如，TLS或者IPSEC），否则，不应该使用简单口令认证。简单口令认证需要声明binddn和credentials参数。

Kerberos认证和SASL认证相比也是不推荐的。尤其是KERBEROS_V4和GSSAPI。Kerberos需要设置binddn和srvtab参数。

SASL认证是最推荐使用的。SASL认证需要使用mech参数指定一种认证机制。根据这种机制，需要分别使用authcid和credentials参数指定一个认证身份和认证证书。authzid参数也可以被用来指定一个认证身份。

请参阅“”一章来获得使用此指令的更多信息。

2.3.4、 replogfile

该指令说明了slapd用来记录改变的复制日志文件。复制日志文件通常被slapd写入，并且由slurpd读出。通常情况下，该指令只有在使用slurpd复制数据库的时候才会使用。但是，即使slurpd没有运行，您也可以使用它来产生一个事务记录。在这种情况下，您需要定时截断该文件，否则，它将会持续增长。

请参阅“”一章来获得使用此指令的更多信息。

2.3.5、 rootdn

该指令说明了对于该数据库的操作不受限于存取控制或者管理限制的DN。该DN不应该指向目录中的任何条目。该DN可以指向一个SLSL证书。

基于条目的示例：

rootdn "cn=Manager,dc=example,dc=com"

基于SASL的示例：

rootdn "uid=[e-mail]"

2.3.6、 rootpw

该指令说明了上面的指令中总是能够工作的DN的口令，无论指定的DN条目是否存在，或者，是否具有一个口令。该指令和基于SASL的认证相比是不推荐的。

示例：

rootpw secret

2.3.7、 suffix

该指令指明了一个传递给后台数据库的查询的DN后缀。可以给出多个后缀行，并且对于每一个数据库定义，至少需要一个。

示例：

suffix "dc=example,dc=com"

以指定后缀"dc=example,dc=com"结尾的查询将被传递给后台数据库。

注意：当选择了一个传递给后端的查询时，slapd在每一个数据库定义中，按照它们在文件中出现的顺序查找后缀行。因此，如果一个数据库后缀是另外一个的前缀，它在配置文件中，必须出现在另外一个的后面。

2.3.8、 updatedn

该指令只有在附属slapd中才会使用。它说明了允许对复本进行改变的DN的名称。这可能是slurpd(8)在对复本做改变的时候绑定的DN，或者是和一个SASL证书相关联的DN。

基于条目的示例：

updatedn "cn=Update Daemon,dc=example,dc=com"

基于SASL的示例：

updatedn "uid=[e-mail]"

请参阅“”一章来获得使用此指令的更多信息。

2.3.9、 updateref

该指令只有在附属slapd中才会使用。它说明了当客户端对复本提交更新请求时返回给客户端的URL。如果说明了多次，每一个URL都将被返回。

updateref   ldap://master.example.net

数据库指令

该类别的指令只是适用于一个BDB数据库。也就是说，它们必须出现在一个“database bdb”行之后，并且在任何后续的“backend”或者“database”行之前。

2.4.1、 directory

该指令说明了包含BDB数据库文件和相关联的索引的目录。

缺省值：

directory /usr/local/var/openldap-data

数据库指令

该类别的指令只是适用于一个LDBM数据库。也就是说，它们必须出现在一个“database LDBM”行之后，并且在任何后续的“backend”或者“database”行之前。

2.5.1、 cachesize

该指令说明了被LDBM后端数据库实例保持在内存缓存中的条目的数量。

缺省值：

cachesize 1000

2.5.2、 dbcachesize

该指令说明了和每一个打开的索引文件相关联的内存缓存的字节数。如果它不被底层的数据库方法支持。该指令被忽略。增加该数量将会使用更多的内存，但是，可以使得性能大幅度上升，尤其是在修改或者创建索引的时候。

缺省值：

dbcachesize 100000

2.5.3、 dbnolocking

如果该选项存在，禁止数据库锁定。允许该选项可以提高性能，但是将为数据安全性付出代价。

2.5.4、 dbnosync

该选项使得当发生改变时，磁盘上的数据库内容不会立即和内存中的内容进行同步。允许该选项将提高性能，但是，同样将损害数据安全性。

2.5.5、 directory

该指令说明了包含LDBM数据库文件和相关联的索引的目录。

缺省值：

directory /usr/local/var/openldap-data

2.5.6、 index { | default} [pres,eq,approx,sub,none]

该指令说明了对于指定属性维护的索引。如果只是指定一个，将维护缺省的索引。

示例：

index default pres,eq

index uid

index cn,sn pres,eq,sub

index objectClass eq

第1行设置缺省的索引集合维护为存在和相等，第2行使得对于uid属性类型维护缺省的索引集合（存在和相等）。第3行对于cn和sn属性类型维护存在，子串，和相等索引集合，第4行对于objectClass属性类型维护相等索引。

默认情况下，不维护任何索引。通常情况下，建议对于objectClass属性类型维护一个相等索引。

index objectClass eq

2.5.7、 mode

该指令说明了对于新创建的数据库索引文件应该具有的保护模式：

缺省值：

mode 0600

3、 存取控制

对于slapd和条目的访问受到存取配置文件指令的控制。一个存取控制行的通常的格式如下：

::= access to

    [by ]+

::= * | [ dn[.]=]

    [filter=] [attrs=]

::= regex | base | one | subtree | children

::= | ,

::= | entry | children

::= [* | anonymous | users | self |

    dn[.]=]

    [dnattr= ]

    [group[/[/][.]]= ]

    [peername[.]=]

    [sockname[.]=]

    [domain[.]=]

    [sockurl[.]=]

    [set=]

    [aci=]

::= regex | exact | base | one | subtree | children

::= regex | exact

::= [self]{|}

::= none | auth | compare | search | read | write

::= {=|+|-}{w|r|s|c|x}+

::= [stop | continue | break]

其中，部分选择了该存取控制应用的条目或者属性。部分说明了哪一个身份被赋予访问权限，部分说明了赋予什么样的访问权限。可以指定多个 3元组，以允许为相同的条目和属性赋予多个身份不同的访问权限。

的访问

一个存取控制说明的部分决定了存取控制规则应用的条目和属性。条目可以通过两种方式选择：通过匹配条目的DN的正则表达式：

dn=

注意：DN的模式说明应该规范到RFC2253中限制的DN格式。特别是，不应该出现用来分隔不同部分的空格或者逗号。一个规范化的DN的例子是："cn=Babs Jensen,dc=example,dc=com"。一个不规范的DN的例子是："cn=Babs Jensen; dc=example; dc=com"。

或者，可以通过匹配条目中的某些属性的过滤器来选择条目：

filter=

是一个表示一个LDAP搜索过滤的字符串，如中描述的那样。

通过在选择器中包含一个用逗号分隔的属性列表来选择条目中的属性：

attrs=

对于条目本身的访问控制必须使用特殊的属性名称“entry”来赋予或者拒绝。注意，给一个属性赋予权限是不够的，通过entry属性赋予条目本身访问权限也是需要的。在本部分最后的示例可以帮助您搞清楚这些问题。

最后，有一个特殊的条目选择器“*”，该选择器被用来选择任何条目。当没有提供其他的选择器时使用该选择器。它等同于“dn=.*”

访问权限

部分指明了被赋予访问权限的身份。注意，权限被赋予“身份”而不是“条目”。表5.3说明了身份说明选项：

Table 5.3: Access Entity Specifiers
Specifier	Entities
*	All, including anonymous and authenticated users
anonymous	Anonymous (non-authenticated) users
users	Authenticated users
self	User associated with target entry
dn=	Users matching regular expression

DN说明选项使用一个正则表达式来匹配当前身份的“规范”DN。

dn=

所谓的“规范化”，指的是从身份DN中删除多余的空格，并且删除RDN中用来分隔不同部分的逗号。

系统还支持其他的控制方式。比如，一个(By NTKO:此处应该是?)可以通过一个匹配限制客户端的域名：

domain=

或者通过一个条目，该条目出现在访问权限应用的条目的一个具有一个DN值的属性中：

dnattr=

dnattr指令被用来给予访问一个条目的权限，并且访问者的DN出现该条目的一个具有DN类型的值中。（比如，可以将访问一个组条目的权限给予所有那些列出在该组条目的owner属性中的人。）

权限

可以赋予的的类型可以是如下几种：

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

每一个级别隐含了更低的级别。因此，给予某人写一个条目的权限同时给了他读，搜索，比较和认证的权限。但是，也可以使用权限说明来赋予特定的权限。

当计算某个请求者是否应该被给予访问一个条目或者属性的权限的时候，slapd将条目或者属性和在配置文件中给出的条目或者属性相比较。对于每一个条目，包含该条目的数据库所提供的存取控制被首先应用，（或者如果没有包含在任何一个数据库中，应用第一个数据库的存取控制），然后是全局存取控制指令。在这种优先级的情况下，存取控制按照它们在配置文件中出现的顺序被检查。Slapd在找到第一个匹配该条目或者属性的选择器时停止搜索。相关的存取控制指令就是slapd将要用来计算存取控制的指令。

下一步，slapd将请求访问的身份和上面找到的存取控制指令的相比较，它在找到第一个匹配请求者身份的选择器之后停止。这决定了请求访问者对于条目或者属性所具有的访问权限。

最后，slapd将所选的指令中赋予的权限和客户端请求的权限相比较。如果超过或者等于客户端请求的权限，则赋予该用户权限，否则拒绝访问。

存取控制指令的计算顺序使得它们在配置文件中的顺序非常重要。如果一个存取控制指令在所选择的条目中比另外一个更加特定（选择的范围更小），它应该首先出现在配置文件中。同样，如果一个选择器比另外一个更加特定，它也应该首先出现在存取控制指令中。下面的存取控制示例可以让这个问题更加清楚。

上面描述的存取控制应用是非常强大的。下面的部分显示了它们的一些实用示例。首先，几个简单的例子：

access to * by * read

这个存取控制指令将读权限赋予每一个人。

access to *

      by self write

      by anonymous auth

      by * read

该指令允许用户修改自己的条目，允许认证，并且允许所有其他人读取。注意，只有第一个by 语句匹配应用。因此，匿名用户被赋予认证权限，而非读取权限。因此，最后一个语句和“by users read”效果相同。

下面的指令显示了一个使用通过两条存取控制指令中的DN，并且使用正则表达式来选择条目的示例。此示例中，顺序是非常重要的：

access to dn=".*,dc=example,dc=com"

        by * search

access to dn=".*,dc=com"

        by * read

dc=com子树下面的条目被赋予读权限，除了dc=example,dc=com的子树，它被赋予的是搜索权限。dc=com没有被赋予任何权限，因为没有任何存取控制指令匹配该DN。如果上面的存取控制指令被反过来，后面的存取控制指令将永远不会到达，因为所有dc=example，dc=com的条目同样也是dc=com的条目。

同时注意，如果没有任何access to指令匹配或者没有by 语句，访问将被拒绝。也就是说，所有的access to指令都以一个隐含的by * none语句结束，并且每一个存取控制列表以一个隐含的access to * by * none指令结束。只有没有指定存取控制的情况下，才会赋予defaultaccess权限。

下面的例子显示了顺序的重要性，对于存取控制指令和by 语句而言都是如此。它也显示了使用一个属性选择器来赋予对特定属性的访问权限，以及不同的选择器。

access to dn="(.*,)?dc=example,dc=com" attr=homePhone

       by self write

       by dn="(.*,)?dc=example,dc=com" search

       by domain=.*\.example\.com read

access to dn="(.*,)?dc=example,dc=com"

       by self write

       by dn=".*,dc=example,dc=com" search

       by anonymous auth

该示例适用于所有在“dc=example,dc=com”子树中的条目。对于所有除了homePhone以外的属性而言，该条目本身可写，其他example.com条目可以搜索，其他任何人除了认证/授权之外（总是被匿名操作），没有存取权限（由by * none隐含说明）。homePhone属性可以被该条目写，被其他的example.com中的条目搜索，可以被从example.com域中连接的客户读取，其他的将不能读（由by * none隐含说明）。其他的访问将被拒绝（由隐含的access to * by * none说明）。

有时，允许一个特定的DN来从一个属性中增加或者删除自己是很有用的。比如，如果您想创建一个组，并且允许人们想该组的member属性中增加或者删除自己的DN，应该使用如下的存取控制指令来完成这一点：

access to attr=member,entry

      by dnattr=member selfwrite

这个dnattr说明的选择器说明，该存取控制应用于member属性中列出的条目。selfwrite存取控制选择器说明那些成员只能从属性中增加或者删除自己，而不能增加或者删除其他值。附加的“entry”是必须的，因为要访问该条目的属性，能够访问该条目是必须的。

下面是一个配置文件的示例。该示例中有许多说明文字。它定义了两个数据库来处理X.500树中的不同部分；两个部分都是BDB数据库实例。示例中显示的行号只是为了参考，并没有包含在实际的文件中。首先，是全局配置部分：

  1.    # example config file - global configuration section

  2.    include /usr/local/etc/schema/core.schema

  3.    referral ldap://root.openldap.org

  4.    access to * by * read

第1行是注释。第2行包含了一个包含主要模式定义的配合文件。第3行的referral指令的意思是在后面的本地数据库定义中找不到的查询将被引用到一个运行在标准端口的LDAP服务器。该服务器是root.openldap.org。

第4行是一个全局的存取控制。它应用于所有的条目（在每一个单独的数据库指明的存取控制之后）。

配置文件的下一部分定义了一个BDB后端，它将负责处理“dc=example,dc=com”树中的查询。该数据库被复制到两个附属slapd，一个在truelies，另外一个在judgmentday。对于几个属性维护索引，并且，userPassword属性对于非授权访问被保护。

  5.    # BDB definition for the example.com

  6.    database bdb

  7.    suffix "dc=example,dc=com"

  8.    directory /usr/local/var/openldap-data

  9.    rootdn "cn=Manager,dc=example,dc=com"

 10.    rootpw secret

 11.    # replication directives

 12.    replogfile /usr/local/var/openldap/slapd.replog

 13.    replica host=slave1.example.com:389

 14.            binddn="cn=Replicator,dc=example,dc=com"

 15.            bindmethod=simple credentials=secret

 16.    replica host=slave2.example.com

 17.            binddn="cn=Replicator,dc=example,dc=com"

 18.            bindmethod=simple credentials=secret

 19.    # indexed attribute definitions

 20.    index uid pres,eq

 21.    index cn,sn,uid pres,eq,approx,sub

 22.    index objectClass eq

 23.    # database access control definitions

 24.    access to attr=userPassword

 25.            by self write

 26.            by anonymous auth

 27.            by dn="cn=Admin,dc=example,dc=com" write

 28.            by * none

 29.    access to *

 30.            by self write

 31.            by dn="cn=Admin,dc=example,dc=com" write

 32.            by * read

第5行是注释。第6行的database关键字表示开始数据库定义。第7行制定了传递给该数据库的查询的DN后缀。第8行说明了该数据库文件所处的位置。

第9行和第10行指明了数据库的“超级管理员”，以及他们的口令。该条目不会受限制于存取控制或者大小和时间限制。

第11行到第18行是说明复制的。第12行说明了复制日志文件的位置（该文件记录数据库的改变，被slapd写入，被slurpd读出）。第13行到第15行指明了副本数据库的主机名和端口，和执行改变操作相绑定的DN，以及绑定的方法和执行绑定操作的DN的口令。第16行到第18行说明了第2个复本站点。查看“”一章来获得有关这些指令的更多信息。

第20行到第22行指明了为哪些属性维护索引。

第24行到第32行说明了对本数据库中条目的存取控制。因为这是第一个数据库，存取控制同样适用于不在任何数据库中保存的条目（比如Root DSE）。对于所有适合的条目，userPassword属性只能被条目本身和“admin”条目写入。它可以被用来进行认证或者授权，但是其他情况时不能读取的。所有其他的条目可以被条目本身和“admin”条目写入，并且可以被其他任何用户读取（认证过或者没有认证过的用户）。

该示例配置文件的下一个部分定义了另外一个BDB数据库。该数据库查询包含在“dc=example,dn=net”子树中的查询。但是，被第一个数据库中相同的条目所管理。注意，如果没有第39行，由于第4行中的全局存取规则，将会允许读取权限。

 33.    # BDB definition for example.net

 34.    database bdb

 35.    suffix "dc=example,dc=net"

 36.    directory /usr/local/var/openldap-data-net

 37.    rootdn "cn=Manager,dc=example,dc=com"

 38.    index objectClass eq

 39.    access to * by users read