我整晚都在研究这个问题，但遇到了障碍。我们的防火墙最近恢复到了 11 月的备份，重新配置后 LDAP 身份验证就失效了。我研究了问题的潜在来源，包括 Nate 的出色回答这里是关于服务器故障。
问题概述如下：Server 2012 环境，一个 DC 运行所有服务，只有一个简单的 CIFS 盒、共享打印机和 ADDS。防火墙是具有 VPN 许可的 TZ205W。
使用以下设置：
LDAP Name : Server.MYCOMPANY.local
Port: 636
Give bind distinguished name: [email protected]
Protocol: LDAP v3
Use TLS: Y
Send LDAP Start TLS: Y
我收到 LDAP 通信错误。我尝试了各种端口设置和 TLS，但得到的提示最接近“用户未获得 LDAP 服务器授权”，但从未出现其他错误。防火墙和服务器之间的端口和路由都很干净。
此 DC 是环境中唯一的服务器，其端没有任何变化。我们看到了一些小的 DNS 错误，但没有什么会完全破坏 636 或 389 上的标准 LDAP。我甚至违背了最佳实践，在域控制器上安装了 AD LDS，看看是否可以强制连接，但到目前为止也没有成功。
关于这一点最不寻常的部分是，如果我转到 Schema 或 Directory 选项卡，我会得到返回的错误，unrecognized schema尽管选择了 AD，或者在尝试拉取组 OU 时返回了错误no user groups were found on the LDAP server. Check the LDAP directory configuration。
我不知所措。我们尝试了 IP、FQDN、UPN 等各种组合来让这个东西工作，但它拒绝了。
以前有人见过类似的问题吗？
答案1
因此，我们花了几个小时与 Dell-Sonicwall 一起对此进行故障排除，问题似乎是 SAMaccountname 或我们测试帐户的其他属性中存在一些隐藏的损坏；我们只是为测试目的创建了一个新的 AD 用户，关闭了 TLS 并通过端口 389 运行连接，问题就解决了。
这似乎是 Sonicwall 处理 LDAP 到 AD 连接方式的一个错误。使用包含大写字母或空格的显示名称存在已知问题，因此这可能是 TZ205 的另一个怪癖，应该添加到一般知识库中。