OpenLDAP常见疑问

2019-04-03 本文已影响0人 yuhan_sining

疑惑1：细心的人会发现有的教程说要配置主机DNS，添加与LDAP相关的域名，而大部分教程都没有提及这个，那么到底要不要配置呢？

解答：当然需要配置。安装好OpenLDAP后首先需要配置slapd.conf这个文件，其中里面有

suffix        "dc=example, dc=com"

这样一句需要自己配置，这两个dc代表什么意思呢？其实dc就是“domainComponent”，也就是域名的组成部分，准确的说是主机域名的后缀组成部分，如果这里的配置与你的主机域名不对应的话，服务一般是启动不了的。那么怎么配置域名呢？Linux和Windows下的配置文件如下：
Linux下：/etc/hosts
Windows下：C:\Windows\System32\drivers\etc\hosts
需要在hosts文件里添加一条域名（如果没配置的话），格式如下：

127.0.1.1       hostname.example.com    hostname

比如我的主机名是min，并添加的域名配置是：

127.0.1.1       min.alexia.cn    min

那么相应的我就需要在slapd.conf里这样配置suffix：

suffix        "dc=alexia, dc=cn"

当然这里域名后缀不一定只有两级，也可以是hostname.example.com.cn，然后suffix就应该是“dc=example, dc=com, dc=cn”，这随便你怎么设置了，只要对应就行。

疑惑2：很多版本的slapd.conf里默认都配置了下面两个变量，这是什么意思？需要改动吗？

modulepath /usr/lib/ldap
moduleload back_@BACKEND@
解答：这是数据库database的backend，一般slapd.conf里配置的database都是 bdb，也就是Berkeley DB，有的也许是hdb，其实也是Berkeley DB，只是两个不同的存储引擎（就像Mysql有MyISAM和InnoDB两个不同的存储引擎一样）。而modulepath和moduleload指定了动态模块路径及动态装载的后端模块，因为OpenLDAP默认是用Berkeley DB存储数据的，如果你有动态的数据需要装载，那么就需要配置这两个参数，对于一般用户将这两个注释掉即可。

疑惑3：OpenLDAP默认采用Berkeley DB存储数据，那么可以换用其它的关系数据库吗？具体如何配置呢？

解答：当然可以。首先需要明确ldap数据模型来自RDBMS（关系数据库模型），而并没有指定一定是哪个 DB，只要是关系数据库都可以作为LDAP的后台，那么你为什么会想用其它的数据库代替自带的Berkeley DB呢？我想可能是性能相关了，对于少量数据你用哪个都可以，但若涉及到稍大点的数据，比如成千上万的用户查询，那么Berkeley DB的性能就不可观了，而且Berkeley DB管理起来也不太方便，毕竟对这个数据库熟悉的人不多，如果能换作我们经常使用的数据库，不仅性能得到提升，管理起来也十分容易，岂不是一举多得。
具体怎么配置了，请参考这篇文章：用postgresql作后台的openldap，以PostgreSQL作为例子进行讲解。

疑惑4：新旧版本的OpenLDAP到底有什么差异呢？

解答：简单一句话就是：旧版本的OpenLDAP配置文件一般是slapd.conf（路径可能是/etc/openldap，也可能是/usr/local/openldap，甚至可能是/usr/share/slapd/，不同版本不同安装不同系统都可能不同，可使用locate slapd.conf进行查找正确的路径），而新版本（我测试的新版本是2.4.31）的OpenLDAP服务运行时并不会读取该配置文件，而是从slapd.d目录（一般与slapd.conf在同一目录下）中读取相关信息，我们需要把该目录下的数据删掉，然后利用我们在slapd.conf里配置的信息重新生成配置数据。这也可能是你启动服务后运行ldap相关命令却出现“ldap_bind: Invalid credentials (49)”错误的主要原因。具体怎么重新生成配置数据请看参考资料。

疑惑5：自定义的ldif数据文件中的objectclass后的domain、top、organizationalUnit、inetOrgPerson等等都是什么意思，可以随便写吗？

解答：存储LDAP配置信息及目录内容的标准文本文件格式是LDIF(LDAP Interchange Format)，使用文本文件来格式来存储这些信息是为了方便读取和修改，这也是其它大多数服务配置文件所采取的格式。LDIF文件常用来向目录导入或更改记录信息，这些信息需要按照LDAP中schema的格式进行组织，并会接受schema 的检查，如果不符合其要求的格式将会出现报错信息。因此，ldif文件中的属性都定义在各大schema中，其中objectclass是对象的类属性，不能随便填写，而应与schema中一致。一般slapd.conf文件的头部都包含了这些schema：

include         ../etc/openldap/schema/core.schema
include         ../etc/openldap/schema/cosine.schema
include         ../etc/openldap/schema/inetorgperson.schema
include         ../etc/openldap/schema/nis.schema
include         ../etc/openldap/schema/krb5-kdc.schema
include         ../etc/openldap/schema/RADIUS-LDAPv3.schema
include         ../etc/openldap/schema/samba.schema

其中前三个是比较重要的schema，定义了我们所需要的各个类，比如ldif中一般先定义一个根节点，其相应的objectclass一般是 domain和top，而根节点下的ou属性即定义组节点（group）的objectclass一般是 organizationalUnit，group下可以是group也可以是用户节点，用户节点的objectclass一般是 inetOrgPerson。而各个节点的一系列属性如用户节点的uid、mail、userPassword、sn等等都定义在schema中相关的 objectclass里，可以自己查找看看。

疑惑6：OpenLDAP认证用户uid时默认是不区分大小写的，也就是“alexia”与“AleXia”是同一个用户，在有些情况下这并不合理，能配置使得认证时能区分大小写吗？

解答：以我目前的经验来看，旧版本的OpenLDAP是可以配置区分大小写的，而新版本的OpenLDAP却配置不了。为什么这么说呢？
这里就涉及到“matching rules”这个概念了，即匹配规则，就是各个属性按什么样的规则进行匹配，比如是否区分大小写、是否进行数字匹配等等，这里有详细的官方匹配规则描述。比如旧版本的core.schema里有下面这样一段：

attributetype ( 0.9.2342.19200300.100.1.1
   NAME ( 'uid' 'userid' ) 
   DESC 'RFC1274: user identifier'
   EQUALITY caseIgnoreMatch 
   SUBSTR caseIgnoreSubstringsMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

从字面上也可以看出，其中caseIgnoreMatch和caseIgnoreSubstringsMatch就定义了uid或userid属性匹配时不区分大小写，如果我们将其改为caseExactMatch和caseExactSubstringsMatch就表示用户uid认证时需要区分大小写，也就是“alexia”与“AleXia”是不同的用户，这很简单，在旧版本的OpenLDAP也行得通。
可是在新版本的OpenLDAP中却不行，新版本的core.schema文件中也包含这样一段：

#attributetype (  2.16.840.1.113730.3.1.217
#    NAME ( 'uid' 'userid' )
#    DESC 'RFC1274: user identifier'
#    EQUALITY caseIgnoreMatch
#    SUBSTR caseIgnoreSubstringsMatch
#    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

可惜是注释掉的，那我们取消注释然后改属性行不行呢？答案是不行，会报错：Duplicate attributeType: "2.16.840.1.113730.3.1.217”，也就是说该属性已经被定义了，然后我就去包含的所有schema中搜索uid属性的定义，结果却找不到定义，那么为什么还会报这个错误呢？后来一阵搜索，终于在这个帖子“slapd: built-in schema for uidNumber/gidNumber does not have ordering directive”知道了答案，原来新版本的OpenLDAP已经把uid属性定义schema硬编码到了slapd程序中，也就是无法在配置文件中修改了，真是坑！
针对这个问题，我给出两个不太好的解决方案：
下载OpenLDAP源码，找到定义uid属性匹配规则的地方，修改它然后重新编译。这个工作量不轻松，热爱研究源码的人可以尝试。
不要用uid属性进行认证，我们可以自定义一个与用户一一对应的属性如user-id（不要与已有的属性重复就行），其配置与uid一模一样（即模仿 uid），然后用该属性作为认证的因子，建议重新建一个schema，然后配置好后include进slapd.conf中重启服务即可。具体怎么定义和配置可以参考这篇文章。