LDAP全称Lightweight Directory Access Protocol，中文叫做轻量级目录访问协议。名字读起来偏专业，实际作用不难理解，本质就是一套查询工具。它更适合读多写少的数据存储场景，用来存放组织架构、员工账号、设备信息这类改动频率低的数据。日常登录企业邮箱、接入VPN、访问内部Wiki，身份核验环节很多都依赖LDAP。
它的数据模型采用树形结构。最顶层是根节点，向下依次划分国家、组织、部门，再往下才是人员或者设备条目。树里每一条记录叫做entry，entry由各类属性和对应数值组成。拿用户条目举例，包含cn（通用名称）、uid（用户ID）、mail、userPassword等属性。DN（Distinguished Name）用来定位树上的节点，示例格式uid=zhangsan,ou=people,dc=example,dc=com。从左往右读，信息逐步细化，和电脑文件路径的顺序相反。
认证流程核心依靠bind操作。客户端要核验用户身份，就把该用户DN与密码发送给LDAP服务器，服务器在目录树找到对应entry，比对密码信息。匹配成功返回认证通过，失败则返回错误码。这里有个很常见误区：LDAP认证不会解密存储的密码比对，客户端传输明文密码，服务器使用相同加密算法处理后，再和库内保存的哈希值对比。LDAP原生传输不加密，密码在网络传输过程存在泄露风险，需要搭配TLS加密也就是LDAPS，端口由默认389改为636。
bind存在多种类型。匿名bind无需账号密码，服务器允许匿名身份读取公开信息，多数企业环境会关闭这个选项。简单bind就是上面提到的账号密码认证。SASL bind实现更加复杂，支持Kerberos、DIGEST-MD5等机制，多用于大型企业环境。还有代理bind，客户端先用固定管理账号连接服务器，再以其他用户身份查询数据，适合批量处理或者服务账号场景。
配置LDAP认证，有几个参数不能跳过。Base DN是搜索起始节点，示例dc=example,dc=com，相当于告诉服务器从这个节点向下检索。Bind DN是执行查询操作使用的账号，一般是单独创建的服务账号，如cn=admin,dc=example,dc=com。Bind Password是这个服务账号的密码。User Search Base存放用户条目所在子树，如ou=people,dc=example,dc=com。User Search Filter作为检索过滤条件，示例(uid={0})，{0}会替换成用户输入的用户名。参数一旦填写错误，认证直接失败，而且报错信息比较模糊，只会提示“invalid credentials”，没法直接区分是DN写错，还是密码出错。
正式配置前，可以先用ldapsearch命令行工具手动测试。示例ldapsearch -x -H ldap://server -D "cn=admin,dc=example,dc=com" -w password -b "ou=people,dc=example,dc=com" "(uid=zhangsan)"。能够查到用户entry，说明Base DN和检索条件没问题。接着用该用户DN和密码执行bind测试，命令ldapwhoami -x -H ldap://server -D "uid=zhangsan,ou=people,dc=example,dc=com" -w userpassword。返回dn:uid=zhangsan,...就代表认证成功。两步测试通过之后，再去配置应用对接LDAP，成功率会高很多。
配置过程里有不少常见陷阱。DN内的空格、逗号，多一个或少一个字符都会报错，最好直接复制ldapsearch输出内的原文。密码里的特殊符号，在配置文件中需要转义，像$、#这类字符，部分解析器会识别成变量或者注释标记。TLS证书方面，如果服务器使用自签名证书，客户端要么导入CA证书，要么临时关闭校验；关闭校验仅适用于测试环境，生产环境绝对不能这么操作。检索范围同样需要留意，User Search Base范围设置过大，从根节点检索，查询速度很慢，甚至触发服务器size limit限制；范围过小，则检索不到目标用户。
LDAP认证流程本身不算复杂，难点在于目录树结构和应用检索参数匹配。目录树结构由管理员设计，应用只会识别填写的参数。两边对不上的时候，优先用ldapsearch手动验证，确认DN、Base、Filter三项内容无误，剩下的工作只是表单填写。