Linux 安装并配置 OpenLDAP 新编（4）配置详解

在开始了解 OpenLDAP 的详细配置之前，再次重温一下配置文件的铁律：

  • OpenLDAP 2.3 以及之后 的版本，已经使用动态运行时配置引擎，不要再使用旧的 CONF 格式；
  • 虽然 OpenLDAP 的配置文件被存储为文本格式的 LDIF 文件，但是永远不要直接修改任何 LDIF 配置文件。配置的改变通过 LDAP 操作工具来进行。

本章依旧用于测试，不要用于生产环境！！！

实验准备

我们依旧使用之前 QuickStart 章节所安装的编译版本，创建一个全新的配置文件 init.ldif ，通过添加逐个配置块后导入配置存储目录，来观察配置项是如何生效的。

实验技巧

导入后，只需要删除配置存储目录中的文件即可初始化目录来重新导入，默认情况下这个目录通常是： /usr/local/etc/slapd.d/ ，导入的命令如下：

# 离线添加配置文件
/usr/local/openldap/sbin/slapadd -n 0 -F /usr/local/openldap/etc/slapd.d -l init.ldif
#  返回如下信息，表示添加成功
Closing DB...

slapadd 的导入，是逐行执行的，也就是说配置文件的内容，是从上到下执行，遇到错误的位置会停止，但是前面执行过的操作也不会回退。这里可以使用 -u 参数在执行前做一下检测，以免麻烦：

# 离线添加配置文件
/usr/local/openldap/sbin/slapadd -n 0 -F /usr/local/openldap/etc/slapd.d -l init.ldif -u
#  返回如下信息，表示添加成功
Closing DB...

当然，哪怕在导入成功后想进行重置再次实验，也只需要删除上面的配置存储文件，同时再删除数据库存储目录即可。在前面的配置中，这个目录为： /usr/local/var/openldap-data/ 。

配置层级

SLAPD 配置树拥有非常特殊的结构。树的根名为 cn=config ，包含全局配置设置。其他设置均包含在单独的子条目中：

  • 动态模块加载： 只有在使用了 –enable-modules 选项配置软件时，才能使用这些选项；
  • 架构定义：cn=schema,cn=config 条目包含了系统架构；
  • 后端特定配置
  • 数据库特定配置

配置规范

特别注意！特别注意！特别注意！

LDIF 文件的通用规则适用于所有的配置文件：以 # 字符开头的注释行将被忽略。如果一行以单个空格开头，则视为前一行的延续（即使前一行是注释），并删除单个前导空格。条目之间以空行分隔。多行的配置，最后一行之前的行位需要增加一个空格。最后这一句，务必小心理解！

很多时候对 ldif 文件的添加、修改发生错误，都是由于格式错误引起的，请务必注意！

全局配置

全局配置是指顶级的 config 、schema 以及 module ，模块在后面的章节再行解析。

基础配置
# example config file - global configuration entry
dn: cn=config
objectClass: olcGlobal
cn: config
olcLogLevel: Stats

olcArgsFile: /usr/local/openldap/var/run/slapd.args
olcPidFile: /usr/local/openldap/var/run/slapd.pid

如果只添加了这些基础配置，导入后只会在存储目录中添加一个名为： cn=config.ldif 的文件。

架构配置

Schema决定了在在LDAP中可以添加什么样的条目类型，以及条目类型包含哪些属性，这可以对应理解为编程语言中的 类 ，在 LDAP 中这称之为 objectclass 。而具体条目，可以理解为编程语言中的 实例化对象 。

# internal schema
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema

# include the core schema
include: file:///usr/local/openldap/etc/openldap/schema/core.ldif

虽然架构可以在后期需要时再行导入，但是为了省事以及避免出现问题时不知所措，可以把常用的架构先导入进来，官方提供的架构位于安装目录的 schema 子目录中，理论上可以满足绝大多数情况下的需求：

# 常用架构
include: file:///usr/local/etc/openldap/schema/cosine.ldif
include: file:///usr/local/etc/openldap/schema/inetorgperson.ldif
include: file:///usr/local/etc/openldap/schema/nis.ldif

在官方文档中，还描述了 misc 和 openldap 这两个所谓实验性质的架构；collective, corba, duaconf, dyngroup, java 这几个架构目前不知道有什么具体作用；dsee, msuser, namedobject, pmi 应该是有什么依赖需求，直接导入会报错。

在定义了上面的配置信息并导入配置存储目录之后，会被复制到配置存储目录中的 cn=config/cn=schema 目录内。此时查看 /usr/local/etc/slapd.d 目录，可以看到如下的结构：

/usr/local/openldap/etc/slapd.d/
├── cn=config
│   ├── cn=schema
│   │   ├── cn={0}core.ldif
│   │   ├── cn={1}cosine.ldif
│   │   ├── cn={2}inetorgperson.ldif
│   │   └── cn={3}nis.ldif
│   └── cn=schema.ldif
└── cn=config.ldif

特定的数据库指令

接下来的配置，都是针对于不同的数据库类型，但是每种类型的数据库基本都支持下面的指令，同时数据库项必须具有 olcDatabaseConfig 对象类。

olcDatabase 指令

olcDatabase 的典型用法为：

olcDatabase: [{<index>}]<type>

该指令指定了一个数据库实例，同时可以提供一个数字索引来区分类型相同的数据库。但是该参数也可以省略，由 slapd 统一生成管理。

其中，type 有两个独特的类型：config 和 frontend 。config 用于保存一些系统级别的配置信息； frontend 用于保存可应用于所有其他数据库的数据库级选项。当然后续数据库定义也可以覆盖指定的 frontend 设置。同时，这两个数据库总是隐式创建的，而且他们会在其他任何数据库之前创建。而且， frontend 的索引一定是 -1 ， config 的索引一般是 0， 是否可以添加多个 config ，并无实际测试过。

切记！切记！切记！ 对于 编译安装 一定要显式配置 config 数据库，否则会无法进行管理操作！

frontend 数据库
# global database parameters
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: frontend
olcReadOnly: FALSE
olcAccess: to * by * read

olcAccess 指令用于设置该数据库的 Access Control（访问控制） ，访问控制的大概语句范式为：

olcAccess: to <what> [by <who> [<access>] [<control>] ] +

正如字面意思，即授权某项资源（what），可以由何人（who），执行什么（access）。针对于配置数据库，仅允许系统超级用户管理，并禁止其他人操作。关于访问控制的详细内容，会在下章，专门再次。

在 frontend 中定义的 olcAccess 指令，默认适用于其他所有数据库中的条目。

config 数据库
# set a rootpw for the config database so we can bind.
# deny access to everyone else.
dn: olcDatabase=config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: config
# SASL 机制身份认证
olcAccess: to * 
 by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage 
 by * none
# 定义该数据库超级用户密码。（DN默认为 cn=config ）
olcRootPW: {SSHA}5/k+kuMcbt3/30yHLdmyupPeC+kz8/e3

对于 config 后端数据库来说，默认的 olcRootDN 即为 cn=config ，无需显式指定。olcRootPW 为该 DN 所绑定的超级密码，可以用下面的命令提前生成：

slappasswd -s 123456
{SSHA}pJqiuqP0RsTtZ/4LOmN9ZMN8ZVH+Lxtr
通用数据库配置
# MDB definition for example.com
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcSuffix: dc=example,dc=com
# 数据库存储目录必须存在，并且权限配置为 700
olcDbDirectory: /usr/local/var/openldap-data
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
olcDbIndex: uid pres,eq
olcDbIndex: cn,sn pres,eq,approx,sub
olcDbIndex: objectClass eq
olcAccess: to attrs=userPassword
 by self write
 by anonymous auth
 by dn.base="cn=Admin,dc=example,dc=com" write
 by * none
olcAccess: to *
 by self write
 by dn.base="cn=Admin,dc=example,dc=com" write
 by * read

其他配置属性的描述：

  • olcSuffix : 后缀配置，可以理解为该数据目录的根节点；
  • olcDbDirectory ： 改数据库的存储目录；
  • olcRootDN ：官网对这个属性的解释有点绕，可以简单粗暴的理解为这就是该数据库的超级ID，可以用于管理该数据库的超级ID。该值还可以使SASL标识；
  • olcRootPW ： DN标识对应的密码。
  • olcDbIndex ：索引方式

总结

通过分块测试，应该可以逐步看到每一块配置项，所能影响的结果。此时对比之前YUM安装后的结构，就会发现配置存储目录中的配置文件前缀，为什么会是 olcDatabase={-1} 、 olcDatabase={0} 等序列编号，以及对应名字的含义了。

接下来的两章，会进一步解析访问控制以及动态模块加载的相关配置。