【问题标题】:LDAP users trying to authenticate get error 50 Insufficient access (openldap)LDAP 用户尝试进行身份验证得到错误 50 访问不足 (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={1}bdb.ldif中有最后一个条目

olcAccess: {22}to *  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: {14}to 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 曾经允许简单身份验证,但在我恢复数据库时不知何故丢失了此配置。我什至不知道这是在哪里以及如何配置的?

【问题讨论】:

    标签: authentication ldap openldap


    【解决方案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。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-03-17
      • 1970-01-01
      • 2015-05-17
      • 1970-01-01
      • 1970-01-01
      • 2018-05-29
      • 2012-11-23
      • 1970-01-01
      相关资源
      最近更新 更多