Windows Server 的 LDAP 签名与通道绑定并非可有可无的附加配置,而是抵御凭证窃取和中间人攻击的核心防线。默认情况下,许多早期或未加固的域控制器允许不签名的 LDAP 查询,这直接导致攻击者一旦获得网络立足点,就能通过 NTLM 中继轻松提升权限。要解决这个问题,必须从理解 LDAP 签名的协商机制入手,然后通过组策略强制启用,同时结合目录级安全审计,彻底封堵这条高危路径。

LDAP 签名的本质与安全威胁

LDAP 签名是一种基于 Kerberos 或 NTLM 的会话完整性校验机制。当客户端向域控制器发起 LDAP 请求时,签名选项决定了会话是否对数据包进行加密哈希校验。如果不强制签名,攻击者可以实施经典的 NTLM 中继攻击:诱导一台高权限服务器或管理员工作站向攻击者控制的恶意主机发起认证,攻击者将截获的 NTLM 凭据实时中继到域控制器的 LDAP 服务,从而创建后门账户或修改 ACL。更隐蔽的是基于 Web 的分布式作者和版本控制协议与强制策略回退攻击,攻击者可以利用无签名的 LDAP 连接篡改域复制流量或注入恶意组策略。因此,微软在安全基线中明确要求所有域控制器启用 LDAP 签名,并在功能性更新中逐步将默认值从“无”调整为“需要签名”。

LDAP 通道绑定的进阶防护

签名解决的是数据完整性,而通道绑定解决的是会话绑定唯一性。LDAP 通道绑定令牌将 LDAP 会话与外层 TLS 隧道强关联,即使攻击者拥有合法证书,也无法在中间人场景下重用截获的认证令牌。启用通道绑定后,域控制器会验证客户端提供的 CBT 是否与当前 TLS 通道匹配。这对于防护高级持续威胁中的令牌重放尤为关键。在 Windows Server 2019 及更高版本中,通道绑定默认处于宽松模式,管理员应通过注册表将其调整为强制模式。需要注意的是,启用强制通道绑定前,必须确保环境中所有第三方 LDAP 客户端均支持该特性,否则会导致认证失败。

通过组策略强制启用 LDAP 签名

具体配置路径位于域控制器的组策略对象中。打开组策略管理控制台,定位到“计算机配置”下的“策略”>“Windows 设置”>“安全设置”>“本地策略”>“安全选项”。找到“网络安全: LDAP 客户端签名要求”,将其设置为“需要签名”。同时配置“域控制器: LDAP 服务器签名要求”,同样设为“需要签名”。这两个策略必须配对设置,缺一不可。客户端策略确保所有出站 LDAP 请求强制签名,服务器策略确保域控制器拒绝任何未签名的入站连接。配置完成后,在域控制器上执行 gpupdate /force,并重启相关服务使策略立即生效。

验证签名状态与发现违规客户端

策略部署后,必须通过审计手段确认生效情况。在域控制器上开启 LDAP 接口事件日志,具体操作是在注册表路径 HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics 下,将“15 Field Engineering”值设为 5。重启 Active Directory 域服务后,系统日志中会出现事件 ID 2889,记录所有未签名或未加密的 LDAP 连接。通过分析这些日志,可以精准定位仍在发起不安全请求的遗留应用或未加固的服务器。对于无法立即升级的旧系统,可临时使用白名单机制,但必须制定明确的修复时间表。

# 在域控制器上启用 LDAP 签名审计
$RegPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics"
Set-ItemProperty -Path $RegPath -Name "15 Field Engineering" -Value 5 -Type DWord
Restart-Service NTDS -Force
目录级安全加固的纵深策略

LDAP 签名只是目录安全的一个维度。完整的目录安全体系需要覆盖权限最小化、管理边界隔离和实时监控。首先,应严格审查 Active Directory 中所有特权组,包括 Domain Admins、Enterprise Admins 和 Schema Admins,确保成员数量可控且使用独立管理账户。其次,实施分层管理模型:Tier 0 层仅包含域控制器和关键身份服务,Tier 1 层承载服务器和业务应用,Tier 2 层放置终端用户工作站,通过身份认证策略禁止高层级账户登录低层级系统。再次,部署高级审计策略,对目录服务变更、账户管理、登录事件进行全量记录,并将日志实时转发至安全信息与事件管理平台。

管理员读卡器安全组与受保护用户组

Windows Server 提供两个极易被忽视但极为有效的内置安全组。受保护用户组强制其成员仅使用 Kerberos 认证,禁用 NTLM、摘要式认证和 CredSSP,同时要求 AES 加密类型,从根本上切断 NTLM 中继的攻击面。管理员读卡器安全组则用于授予只读访问目录服务信息的权限,避免因监控或审计需求而过度分配高权限。将日常运维账户加入受保护用户组,将监控服务账户加入管理员读卡器组,是成本最低但收益最高的加固手段之一。

LDAP 查询策略与匿名访问控制

默认情况下,经过身份验证的用户可以查询大多数目录对象属性,这为攻击者进行信息收集提供了便利。应通过修改默认域控制器的 LDAP 管理策略,限制匿名绑定和未认证查询。在 ADSI 编辑器中,连接到配置命名上下文,导航至“CN=Default Query Policy,CN=Query-Policies,CN=Directory Service,CN=Windows NT,CN=Services”,修改属性以限制单次查询返回的最大对象数和超时时间。同时,在目录分区安全描述符中,移除匿名登录和 Everyone 组的读取权限,仅保留经过认证用户的必要访问。这些措施能显著增加攻击者在侦查阶段的难度和耗时。

补丁管理与 SMB 签名联动

LDAP 安全与 SMB 协议安全紧密相关,因为许多 LDAP 操作依赖 SMB 传输命名管道。必须同步启用 SMB 签名,防止攻击者通过 SMB 中继间接操控 LDAP 会话。在组策略的“Microsoft 网络服务器: 对通信进行数字签名(始终)”和“Microsoft 网络客户端: 对通信进行数字签名(始终)”中均设置为启用。此外,持续跟踪微软安全更新,特别是针对 Active Directory 域控制器和 LDAP 协议栈的漏洞修复。建立月度补丁评估机制,优先部署影响目录服务的安全更新。

第三方应用兼容性处理

强制 LDAP 签名最常见的阻力来自遗留应用和网络设备。许多旧版邮件系统、负载均衡器、NAS 设备或 Linux 主机配置的 LDAP 客户端默认不启用签名。在全面强制前,需建立完整的资产清单,逐项测试兼容性。对于支持但未启用签名的应用,修改其配置文件或注册表项;对于完全不支持签名的设备,需制定替换或隔离计划。临时过渡方案是将这些设备迁移至专用 VLAN,通过网络访问控制列表限制其仅能访问特定域控制器,并在该域控制器上配置例外策略,但必须设置严格的访问控制列表和监控告警。

持续监控与自动化合规检查

安全配置会因系统更新、人员变动或配置漂移而退化。必须建立自动化合规扫描机制,定期检查所有域控制器的 LDAP 签名配置、通道绑定状态和目录权限。可使用 PowerShell 脚本结合计划任务,每日检测关键注册表项和组策略对象状态,发现偏离基线时自动生成告警工单。同时,利用安全信息和事件管理平台关联分析 LDAP 相关事件,重点关注异常时段的目录查询、大量对象枚举和权限变更操作。将 LDAP 签名状态纳入安全评分卡,作为月度安全审查的固定指标。

从 NTLM 中继到 LDAP 签名的攻击链还原

理解攻击链有助于加深对签名必要性的认识。典型攻击路径为:攻击者通过钓鱼或漏洞利用获得内网一台工作站权限,在此工作站上运行响应器或类似工具进行名称服务欺骗,诱导其他服务器或管理员账户向攻击机发起 SMB 或 HTTP 认证。攻击机截获 NTLMv2 哈希后,立即将其中继到域控制器的 LDAP 端口 389。由于未启用签名,域控制器接受该认证,攻击者即可在目录中创建新用户或将自己添加到高权限组。整个过程无需破解密码,仅靠中继即可完成权限提升。强制 LDAP 签名后,中继请求因无法提供有效签名而被域控制器拒绝,攻击链在关键环节断裂。

未来演进与零信任对齐

随着 Windows Server 2025 和云原生架构的推进,微软正在将 LDAP 安全策略与零信任模型深度融合。建议企业从现在开始,将所有目录访问视为潜在威胁,实施持续验证和最小权限。逐步淘汰 NTLM 认证,全面迁移至 Kerberos 并启用 AES 加密。对于混合云环境,确保 Azure AD Connect 同步账户同样遵循签名和通道绑定要求。将本地目录安全策略与云身份保护策略对齐,形成统一的身份安全基线。