☰

OpenLDAP cn=config:没有这样的对象（32）？

tag-icon • tag-icon openldap
OpenLDAP cn=config:没有这样的对象（32）？

我正在尝试遵循几个关于设置 root LDAP 密码的教程（我们之前的系统管理员突然离开了），这些教程或多或少都说了同一件事：

...但第一步就卡住了。这看起来很糟糕：

# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b  cn=config
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
No such object (32)

到目前为止我已经尝试过：

我可以通过从 slapd-config 文件中挖掘出该查询想要检索的数据来找到它：

# find /etc/ldap/slapd.d -type f -exec grep Root {} +
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif:olcRootDN: cn=admin,cn=config
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif:olcRootPW: {SSHA}[xxxxxx hash redacted xxxxxx]
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcRootDN: cn=admin,dc=example,dc=com
/etc/ldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcRootPW: {SSHA}[xxxxxx hash redacted xxxxxx]

并确认 slapd 在理论上已设置为读取这些文件：

# ps -ef | grep slapd
openldap  2244     1  0 Oct26 ?        00:00:16 /usr/sbin/slapd -h ldap:/// ldapi:/// ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d

当我打开 ACL 日志记录（并从命令行运行；从 init.d 打开日志记录会使 slapd 在启动时挂起）时，我得到了以下信息：

5bdb2ef2 => access_allowed: search access to "cn=config" "entry" requested
5bdb2ef2 => acl_get: [1] attr entry
5bdb2ef2 => acl_mask: access to entry "cn=config", attr "entry" requested
5bdb2ef2 => acl_mask: to all values by "gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth", (=0)
5bdb2ef2 <= check a_dn_pat: *
5bdb2ef2 <= acl_mask: [1] applying none(=0) (stop)
5bdb2ef2 <= acl_mask: [1] mask: none(=0)
5bdb2ef2 => slap_access_allowed: search access denied by none(=0)
5bdb2ef2 => access_allowed: no more rules

有想法吗？

答案1

在许多现代 Linux 系统中，当安装了 openldap-server/slapd 时，由SASL/EXTERNALas标识的根目录gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth就是rootDN或具有权限。manager

对于您现有的安装，目前情况并非如此。
如果您知道各种 rootDN 的密码，请使用它们。否则，将您的 rootDN（或其密码）替换为您可以使用的内容。您必须在 LDAP 之外通过编辑/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif或等效程序并重新启动 slapd 来执行此操作。

答案2

我自己也曾遇到过这个问题，但对接受的答案并不满意，因为它指出了问题的原因，但在提供如何修复它的实际说明方面却非常有限。所以我继续搜索，然后偶然发现了这个问题。

前提

我喜欢使用这种 SASL/EXTERNAL 方法，当我尝试创建一个 docker 容器时，正确设置 slapd 是我的意图之一。问题是：如何设置访问权限。当使用选项选择的配置文件夹中不存在现有文件时，cn=config容器会在首次启动时将一些初始 slapd.conf 文件转换为。因此必须有某种方法可以根据需要设置权限。cn=configcn=config-Fcn=config

分析

使用rootDN似乎很奇怪，因为它是在不同的数据库范围内配置的，并且根据先前得到的cn=config配置仍然绑定到不同的数据库。

此外，还cn=config配置了授予none所有人访问数据库中任何内容的权限cn=config。检查文件/您的/配置/目录/cn = config / olcDatabase = {0} config.ldif：

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 e01f7658
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: a85462ad-0102-456d-a2d7-e6d082b7e613
creatorsName: cn=config
createTimestamp: 20190429143842Z
entryCSN: 20190429143842.339724Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20190429143842Z

它清楚地说明了这一点olcAccess: {0}to * by * none，所以我很确定使用rootDN也无济于事。

在现有的 LDAP 服务器中应用了不同的访问规则：

olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break

所以，这就是我所需要的！

解决方案

从 slapd.conf 转换为cn=configslapd 时，其工具接受结果数据库的部分配置。olcDatabase={0}config是名为 的数据库的结果 DN config。因此，请在文件中添加该数据库的配置。以下摘录附加到我的 slapd.conf 文件末尾，已被采用来自之前链接的问题：

database config
access to *
    by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
    by * read

不要忘记删除任何现有的配置文件夹cn=config因此更新后的 slapd.conf 文件将再次转换为。

相关内容