在 CENTOS 7 上使用 OpenLDAP (2.4.44)，并使用 userPassword 字段为某些用户配置了 {SASL} 直通到另一个远程 LDAP。出于各种原因，这可能会更改（覆盖）为使用本地密码 {CRYPT} - 而不是 SASL 直通。我们有一个脚本可以将其更改为管理员请求的操作，即从 {SASL}[电子邮件保护]到 {CRYPT}skfghdfghdhwsiy（另一种方式是从 {CRYPT} 到 {SASL}，没有问题）。但是，我注意到脚本总是导致 SASL 远程 LDAP 服务器上的“登录失败”。我们可以忍受那一次登录失败，但不幸的是，之后该用户的任何密码更改（Openldap 本地密码）也会尝试通过 SASL 登录（为什么？)，经过几次尝试后，远程 SASL 连接的 LDAP 服务器上的用户将被锁定。脚本中的“admin”用户是不是RootDN 而是一个特殊的“管理员”用户，具有 ACL 权限，可以更改相关用户的用户密码。我已经解决了以下问题：
- 这是 LDAP 问题（不是 SASL）。当 userPassword 中未设置 {SASL} 时，OpenLDAP 调用 SASL 才是问题所在。
- 如果 RootDN openLDAP 用户执行 {CRYPT} 用户密码输入，则不会出现任何问题 - 所以我假设 RootDN 具有一些特殊权力/在更新用户密码时不会触发某些操作？
- 如果具有用户密码管理权限的“管理员”用户进行了更改，则会出现问题，并且所有密码更改都会继续出现问题……直到
- 那里似乎某个点时，它会停止（错误地）转到 SASL。超时/缓存。尚未缩小范围或证明这一点。
有任何线索或解释表明这是如何运作的吗？
谢谢
答案1
仍然不确定原因，但发现移除（删除）用户密码字段（作为一个操作）然后由“admin”（非 RootDN）用户在第二个操作中设置它（根据需要设置为 {SASL} 或 {CRYPT}）不会（正确地）调用 SASL/其他 LDAP，因此远程 LDAP 上没有失败的密码。
这是导致该问题的单一操作，但尚不清楚为什么会这样，但至少有一个可行的解决方案。
发帖前花了几天时间研究这个问题！为什么你总是在发帖后才找到“答案”！谢谢