那个 LDAP 密码错误也许根本不是用户的密码

当日志只说一次 bind 被拒绝时，重置用户密码就是错误的第一步。使用目录插件时，一次登录里有不止一个 bind，而拒绝可能属于执行搜索的服务账号。在这种情况下重置用户凭据不会改变任何东西。它还会把从未成为问题的人锁在外面。

一次登录，多次 bind

带有专用目录账号的配置通常按顺序执行四个步骤，其中任何一步都可能终止登录。

connect to the directory and establish the configured TLS protection
bind as the configured service account
search for the user entry using the search base and filter
open a second connection and bind as that user, then evaluate groups

插件通过处理第一个连接的同一个辅助程序来建立用户认证连接，因此该辅助程序可能在连接时、协商 TLS 时或以服务账号身份 bind 时失败。关于密码的高层消息是后来生成的，并不携带是哪个身份参与其中。所以仅凭错误文本无法判断被拒绝的是用户还是服务账号。

阅读消息之前的日志行，并记录失败发生的时刻。启动时、还没有任何用户到来之前的拒绝，指向配置的账号或端点。只有在某一个人身上、且发生在成功搜索之后的拒绝，则指向那个人的条目或账号状态。

把错误与身份配对

实用的规则是把三件事一起记录下来：何时失败、当时在执行什么操作、以及出示的是哪个身份。没有这三项，在只保留最后一句的日志里，两个完全不同的故障看起来会一模一样。

如果配置的账号失败，先检查该账号和连接，再动任何用户记录。如果搜索成功后用户的 bind 失败，检查搜索返回的条目，而不是你以为它会返回的条目。两条路径只共享一条消息，别的什么都没有。写下你排除了哪一个，因为下一个人问的正是这个。

可分辨名称是数据，不是猜测

因为名字的某个组成部分看起来陌生就改动它，是破坏可用配置的常见做法。Active Directory 中用户对象的默认位置是名为 Users 的容器，而容器与名称相似的组织单位并不是同一类对象。

向目录管理员询问账号真正的可分辨名称，或直接从对象本身读取。下面两种在各自的目录里都可能是正确的，所以都不应该凭记忆输入。

CN=VPN Bind,CN=Users,DC=corp,DC=example
CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example

移动或重命名会在账号和密码仍然有效的情况下改变该值，因此上个季度还正常的配置，本季度可能就在无人触碰凭据的情况下失败。任何重组之后，都要把配置的字符串与目录当前的属性做比较。安静的迁移之后也要做，不要只在报告故障之后才做。

搜索基准不是服务账号

bind 身份和搜索基准回答的是不同的问题：插件以谁的身份认证，以及它在哪里找人。bind 成功却找不到匹配的用户，是范围、过滤器或读取权限的问题，而用用户基准替换账号的可分辨名称对此毫无改变。

确认服务已加载你编辑过的配置，并且其 端点、TLS 信任和认证模式 与可用的管理测试一致。用另一个账号、或针对另一个域控制器做手动查询，并不是等价的实验。

检查存储的密钥，并检查账号是启用、过期还是锁定，且不要在任何地方打印密码。过期很容易被忽略，因为账号会一直工作到它不再工作的那一天。从无关服务继承来的锁定同样安静。这两种情况都不会产生指出服务账号的消息。

组规则放在最后

授权在 bind 成功之后才运行，因此组检查不可能是 bind 失败的原因，去掉组要求也无法修复它。如果登录现在能走到组阶段，剩下的问题是成员资格，而不是凭据。

为了让错误消失而给服务账号授予广泛的目录权限，会改变整个部署的访问策略。请把它当作一项需要单独评审的安全决策，而不是对一条尚未归因到具体身份的消息的修补。