LDAP 用户尝试进行身份验证得到错误 50 访问不足 (openldap)

Posted 2023-02-19

【中文标题】LDAP 用户尝试进行身份验证得到错误 50 访问不足 (openldap)

【英文标题】：LDAP users trying to authenticate get error 50 Insufficient access (openldap)

【发布时间】：2022-01-16 23:30:10

【问题描述】：

在我们的 ldap 数据库突然无缘无故损坏后，我不得不恢复一个较旧的数据库。这似乎奏效了，我可以使用 LDAP 资源管理器客户端访问、浏览甚至更新 LDAP 中的条目。甚至可以匿名浏览条目。

但是，尝试根据 LDAP 对用户进行身份验证的应用程序现在失败并显示 LDAP: error code 50 - Insufficient Access Rights

我可以使用 ldapwhoami 重现该问题：

$ ldapwhoami -vvv -h ldap.localnet -D       
'uid=username,cn=users,dc=unimatrix1,dc=localnet' -x -W
ldap_initialize( ldap://ldap.localnet )
Enter LDAP Password: 
ldap_bind: Insufficient access (50)

对新添加的用户尝试此操作时，我得到了相同的结果。所以我假设 ACL 丢失或错误，但是，我没有对它们进行任何更改，并且 ldif 文件仍然可以追溯到 3 年前。

如何为 LDAP 中的所有用户重新建立身份验证？

它是 macOS Sierra (OpenLDAP-523.30.2) 上的开放目录，以防万一。

---

附录

/etc/openldap/slapd.d/cn=config/olcDatabase=1bdb.ldif中有最后一个条目

olcAccess: 22to *  by set.exact="user/uid & [cn=admin,cn=groups,dc=unimatrix
 1,dc=localnet]/memberUid" write  by dn.base="uid=_ldap_replicator,cn=users,dc
 =unimatrix1,dc=sssnet" write  by sockurl.exact="ldapi://%2Fvar%2Frun%2Fldapi" 
  write  by * read

我想我应该以某种方式在by * read 之前添加by anonymous auth？

还有这个条目我不确定是否会影响身份验证？

olcAccess: 14to dn.one="cn=computers,dc=unimatrix1,dc=localnet"  attrs=entry
 ,apple-realname,cn,description,macAddress,authAuthority,userPassword  by set.
 exact="user/uid & [cn=admin,cn=groups,dc=unimatrix1,dc=localnet]/memberUid" w
 rite  by sockurl.exact="ldapi://%2Fvar%2Frun%2Fldapi" write  by dnattr=creato
 rsName write  by * read

---

更新

我刚刚发现，使用 ApacheDirectoryStudio，我可以使用“CRAM-MD5 (SASL)”进行身份验证，但如果我选择“简单身份验证”，则会收到错误 50。我能够像这样使用 ldapwhoami 进行验证：

$ ldapwhoami -vvv -h ldap.localnet -U username -W
ldap_initialize( ldap://ldap.localnet )
Enter LDAP Password: 
SASL/SRP authentication started
SASL username: username
SASL SSF: 256
SASL data security layer installed.
dn:uid=username,cn=users,dc=unimatrix1,dc=localnet
Result: Success (0)

所以现在在我看来，LDAP 曾经允许简单身份验证，但在我恢复数据库时不知何故丢失了此配置。我什至不知道这是在哪里以及如何配置的？

【参考方案1】：

当恢复的 LDAP 数据中的 UniqueID 与系统使用的 uid 不同（无论出于何种原因）时，可能会出现此问题。

要验证这是否是问题所在，请检查 LDAP 中的用户条目以获取 UniqueID 属性中的值。

然后在服务器上打开一个shell并检查那里使用的uid：

$ id -u username
1003

如果适用，您还可以查看显示 uid 的用户主目录（选项-n）。例如（在 macOS 上，主目录位于 /Users）：

$ ls -aln /Users
drwxr-xr-x+  18 1003  20    612 Jun  5  2018 username

如果 id 不相同，则更改 LDAP 数据中的 UniqueID 以匹配用户的 uid。

或者，您可以尝试更改主目录的所有者

$ chown -R username /Users/username

但 uid 可能已在系统的其他区域使用过，因此首选方法是更改​​ LDAP 条目中的 UniqueID。