4. AD安全基线设计与落地
在Active Directory安全治理中，基线不是“建议清单”，而是域控与成员服务器必须达到的最低安全状态。问题在于，企业往往同时面对三套要求：微软安全基线（Microsoft Security Baseline）、CIS Benchmark，以及等保2.0与行业监管条款。它们关注点不同、粒度不同、检查方式也不同。如果分别落地，会出现同一台域控被三份清单反复整改、策略互相覆盖、审计时无法说明“这条对应哪项合规”的局面。因此，本节的核心任务是：把三类要求映射到同一套可执行的加固清单上，并明确每条基线的检查点与判定依据。
三类基线的关系与差异
微软安全基线以Windows安全指南（Security Compliance Toolkit）为载体，提供GPO备份、Policy Analyzer规则和Excel对照表，特点是“与操作系统版本强绑定”，例如Windows Server 2022域控基线中，Domain controller: LDAP server signing requirements要求为“Require signing”，Network security: LAN Manager authentication level要求为“Send NTLMv2 response only. Refuse LM & NTLM”。CIS Benchmark则更细，分为Level 1（基础）与Level 2（严格），并区分“Scored”与“Not Scored”，适合作为逐项审计的检查表。等保2.0与行业合规（如金融、医疗）通常以控制项形式出现，例如“身份鉴别”“访问控制”“安全审计”“入侵防范”，不直接给出注册表路径，需要工程人员自行映射到具体配置。
三者的映射逻辑可以概括为：微软基线提供“怎么配”，CIS提供“逐项怎么查”，等保与行业合规提供“为什么必须配”。落地时以微软基线为技术底稿，用CIS补齐审计项，用等保条款建立追溯关系。
从基线到加固清单：关键配置项与判定依据
以域控为例，最容易被忽略但审计必查的三项是LDAP签名、SMB签名和NTLM级别。LDAP签名对应CIS的“Ensure LDAP server signing requirements is set to Require Signing”，在等保中对应“身份鉴别”与“通信完整性”。检查方式为在域控上执行reg query HKLM\System\CurrentControlSet\Services\NTDS\Parameters /v LDAPServerIntegrity，期望值为0x2。若为0x1（Negotiate signing），则属于部分满足，需在清单中标记为“待整改”。
SMB签名在域控上应同时启用“Microsoft network server: Digitally sign communications (always)”和“Microsoft network client: Digitally sign communications (always)”。检查命令为Get-SmbServerConfiguration | Select RequireSecuritySignature，期望返回True。NTLM级别则通过reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel检查，期望值为5（仅发送NTLMv2响应，拒绝LM和NTLM）。这三项一旦缺失，域内横向移动与中继攻击的风险会显著上升。
成员服务器的加固重点与域控不同。域控关注“认证协议与目录服务”，成员服务器更关注“本地权限与远程入口”。例如本地Administrators组成员应控制在3人以内，且不得包含普通域用户；远程桌面必须启用网络级别身份验证（NLA），对应注册表HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication，期望值为1。审核策略方面，至少应启用“审核登录事件”“审核对象访问”“审核特权使用”，对应等保“安全审计”条款。
映射表与加固清单示例
下面给出一份可直接参考的映射与加固清单片段。字段包括：基线项、微软基线要求、CIS编号、等保控制项、检查方式、期望值与当前状态。实际使用时，将“当前状态”列替换为环境实测结果即可形成整改台账。
| 基线项 | 微软基线要求 | CIS编号 | 等保控制项 | 检查方式 | 期望值 |
|---|---|---|---|---|---|
| LDAP签名 | Require signing | 2.3.11.1 | 身份鉴别 / 通信完整性 | reg query NTDS\Parameters | LDAPServerIntegrity=2 |
| SMB签名（服务端） | Digitally sign (always) | 2.3.9.1 | 访问控制 / 数据完整性 | Get-SmbServerConfiguration | RequireSecuritySignature=True |
| NTLM级别 | Send NTLMv2 only, refuse LM & NTLM | 2.3.11.7 | 身份鉴别 | reg query Lsa\LmCompatibilityLevel | 5 |
| 匿名枚举 | Do not allow anonymous enumeration | 2.3.10.3 | 访问控制 | reg query Lsa\RestrictAnonymous | 1 |
| RDP NLA | Require NLA | 2.3.7.4 | 入侵防范 / 身份鉴别 | reg query RDP-Tcp\UserAuthentication | 1 |
| 审核策略 | Audit logon / object access / privilege use | 17.1.1–17.1.3 | 安全审计 | auditpol /get /category:* | Success and Failure |
加固清单的版本管理与验证闭环
基线不是一次性任务。操作系统补丁、CIS版本更新、等保测评整改都会导致清单变化。建议为加固清单建立版本号，例如AD-Baseline-v1.3-2025Q1，并在每次变更时记录变更项、变更原因和影响范围。验证环节至少包含两步：一是用gpresult /h确认策略已下发到目标OU；二是用PowerShell脚本批量采集关键注册表值，与清单期望值比对，输出差异报告。只有“配置已下发”和“实际值符合期望”同时成立，才能判定该项加固完成。
最终，域控与成员服务器的加固清单应成为AD安全治理的“单一事实来源”：安全团队用它做审计，运维团队用它做整改，合规团队用它做条款追溯。三类基线不再是三份互相打架的文档，而是同一张清单上的三个视角。