Acegi对接Active Directory认证报用户名令牌验证失败问题

对依赖acegi-security-1.0.3.jar的Acegi安全框架、基于Spring-WS开发的应用做认证源迁移，将原有eDirectory认证切换为Active Directory认证。

• 原有eDirectory适配配置：

ldap.locations=ldap://test_edir_server:389/o=XYZ
ldap.userDnPatterns=cn={0},ou=test,ou=Internal

• 新编写的AD适配配置：

ldap.locations=ldap://test_ad_server:389/dc=XYZ
ldap.userDnPatterns=cn={0},ou=ABC,ou=Internal,ou=DEF,dc=test,dc=xyz

使用新配置测试认证时，抛出如下SOAP错误：

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP-ENV:Header/>
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
         <faultcode>SOAP-ENV:Client</faultcode>
         <faultstring xml:lang="en">com.sun.xml.wss.impl.WssSoapFaultException: Authentication of Username Password Token Failed; nested exception is com.sun.xml.wss.XWSSecurityException: com.sun.xml.wss.impl.WssSoapFaultException: Authentication of Username Password Token Failed</faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

已通过Apache Directory Studio验证，上述LDAP配置可正常连接AD服务端，以下是具体排查方向。

1. 校验用户DN匹配逻辑 #

Acegi的userDnPatterns是直接拼接传入用户名生成用户DN，再做绑定认证，这部分是AD和eDirectory适配差异最高发的问题点：

• 先在Apache Directory Studio中查询测试账号的全量DN，确认用户的cn属性值是否和传入的登录用户名完全一致。AD默认的登录标识是sAMAccountName，cn属性通常存储用户显示名，和实际登录账号不一致的情况非常普遍，如果是这种情况，userDnPatterns配置方式完全不适用，需要替换为用户搜索模式：配置用户搜索基准DN，设置userSearchFilter为(sAMAccountName={0})，通过搜索拿到用户真实DN后再做绑定认证。
• 核对OU层级顺序：AD的DN路径从最内层OU向根域书写，要确认ou=ABC,ou=Internal,ou=DEF的层级顺序和AD实际结构完全一致，顺序写反会直接找不到用户。
• 检查DN特殊字符转义：如果用户CN中包含逗号、加号、引号等特殊字符，直接拼接DN会导致解析错误。

2. 核对AD绑定认证的限制规则 #

AD和eDirectory的默认安全策略差异较大，重点检查以下配置：

• 确认389端口的绑定权限：部分AD默认关闭非加密端口的简单密码认证，要求LDAPS连接或者LDAP签名，未满足要求时绑定请求会被直接拒绝，可以抓包查看LDAP bind响应的具体错误码，49代表账号密码错误，53代表账号限制，其他错误码对应不同的策略拦截。
• 确认测试账号状态：账号未被锁定、未设置登录时间限制、未限制仅可从指定终端登录，以上限制都会导致绑定失败。

3. 开调试日志拿根因 #

当前SOAP返回的是上层通用报错，看不到LDAP层的具体错误：

• 调整日志配置，开启org.acegisecurity包的DEBUG级别日志，重点看LdapAuthenticationProvider的输出，能直接看到实际拼接的用户DN、LDAP绑定返回的具体错误码，确认是用户查找失败还是密码校验失败。
• 开启com.sun.xml.wss包的DEBUG级别日志，确认SOAP层解析出的UsernameToken用户名、密码和预期一致，没有多余的域名前缀、空格等脏数据。

4. 校验连接配置兼容性 #

• 如果配置了用于用户搜索的管理员绑定账号，确认该账号对目标用户OU拥有读取权限，AD默认禁止匿名查询用户数据，匿名绑定会导致用户搜索失败。
• 清理原有eDirectory专属的LDAP配置项，比如eDirectory特有的对象类映射、属性转换器配置，这类配置在AD环境下不生效，会触发查询异常。

快速验证技巧：从DEBUG日志中拿到Acegi实际拼接生成的用户DN，直接复制到Apache Directory Studio中用该DN和测试密码做绑定认证，可1分钟内确认是DN配置错误、密码错误还是AD策略拦截问题。

内容的提问来源于stack exchange，提问作者user2117851