核心是强制启用LDAPS或StartTLS加密通道，禁用明文LDAP；服务端启用双向证书校验与TLS 1.2+强加密套件；禁用匿名绑定及弱认证机制；限制服务账号权限与属性可见性；结合AD签名策略、ACL控制和SIEM日志审计实现全链路防护。
加固ldap认证过程防止敏感信息被抓包泄露，核心是切断明文传输路径，让凭证和目录数据在传输中不可读、不可篡改。
强制启用LDAPS或StartTLS加密通道
LDAP默认走389端口且不加密，所有绑定凭据（DN+密码）、查询过滤器（filter）、返回属性（如mail、displayName）都是明文。攻击者只需在同网段抓包就能直接看到管理员账号和密码哈希。
- 生产环境必须关闭纯LDAP（389未加密）服务，只允许LDAPS（636端口）或强制StartTLS（389端口上协商升级TLS）
- 服务端配置需启用双向证书校验：客户端验证服务器证书是否由可信CA签发；服务端可设
TLSVerifyClient demand要求客户端也提供证书（适用于高安全场景） - 禁用SSLv2/v3、TLS 1.0/1.1，仅启用TLS 1.2+，并优先选择ECDHE密钥交换+AES-GCM加密套件（如
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384）
禁用匿名绑定与弱认证方式
匿名绑定（anonymous bind）相当于把整个AD树当公开黄页用，攻击者无需任何凭据就能执行ldapsearch -x -H ldap://dc -b "dc=corp,dc=local"，拖出全部OU、用户、甚至组策略链接。
- 域控制器组策略中启用“Network security: LDAP client signing requirements”，设为Require signing
- 注册表设置
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity = 2，强制签名+加密 - 禁用DIGEST-MD5、CRAM-MD5等过时SASL机制，统一使用GSSAPI（Kerberos）或EXTERNAL（客户端证书）
限制认证主体权限与属性可见性
即使传输加密了，如果应用账号权限过大，攻击者一旦拿下该账号，仍可通过合法请求批量读取敏感字段，比如userPassword（若启用了旧式NTDS存储）、msDS-AllowedToDelegateTo、unicodePwd等。
- 为每个LDAP调用方创建专用服务账号，加入Protected Users组（禁用NTLM、不缓存凭据、强制AES加密）
- 在ADUC中右键该账号→Security→Advanced，显式拒绝其对
userPassword、unicodePwd、msDS-KeyVersionNumber等属性的读取权限 - ACL中限定其仅能访问必要OU（如
OU=Employees,DC=corp,DC=local），禁止遍历CN=Users或DC=corp,DC=local根节点
审计与实时阻断异常行为
加密解决的是“传输中”风险，但无法防御已获凭证后的横向探测。必须结合日志识别可疑模式，例如高频空密码绑定、大量(objectClass=user)全量扫描、非工作时间来自陌生IP的baseDN查询。
- 开启Windows事件日志中的“Directory Service Access”审核策略，记录
4662（对象访问）、4738（用户账户更改）等关键事件 - 将LDAP日志接入SIEM（如Splunk、ELK），配置规则：单IP 5分钟内超50次失败绑定 → 自动封禁；查询filter含
*且baseDN为根域 → 触发告警 - 对Archer、JumpServer、NextCloud等集成LDAP的业务系统，启用其内置LDAP日志（如
LDAP_LOGS = '/var/log/archer/ldap.log'），检查是否记录完整bind DN与操作类型
