微软定义的核心受保护组包括domain admins、enterprise admins、schema admins、administrators；protected users是防凭据窃取的客户端强制安全组，禁用ntlm、限制kerberos加密与票据策略。
ad 域中“受保护组”（protected groups）不是单一功能，而是指一类具有高权限、需重点防护的内置特权组（如 domain admins、enterprise admins、schema admins、administrators），以及微软引入的受保护用户组（protected users）——后者虽名含“用户”，实为一种主动防御型安全组，专为阻断凭据窃取而设。二者防护逻辑不同：前者靠防止意外修改与横向渗透，后者靠客户端强制执行不可绕过的认证限制。维护关键在于分层加固、最小化暴露、持续验证。
哪些组属于必须保护的核心受保护组？
微软官方定义的受保护组（Protected Groups）特指以下内置高权限组，其成员身份一旦被滥用，可直接导致域控沦陷：
- Domain Admins：对整个域拥有完全控制权
- Enterprise Admins：跨林管理权限，影响所有域
- Schema Admins：可修改活动目录架构，属最高危操作权限
- Administrators（本地管理员组，在域控制器上等同于域管理员级权限）
- Account Operators 和 Server Operators：虽非默认受保护，但因具备账号创建/重置、服务启停等能力，常被纳入强化管控范围
注意：这些组本身不自动启用防护机制，需配合组策略、委派控制、登录限制等手段人工加固。
Protected Users 组不是“特权组”，而是“防窃取组”
Protected Users 是一个全局安全组，设计目标明确——阻止 Pass-the-Hash、Overpass-the-Hash、Kerberoasting 等常见凭据攻击。它不提升权限，只收紧认证行为：
- 成员登录时禁用 NTLM 认证（在 Windows Server 2012 R2+ 域控制器上完全拒绝）
- 禁用 Kerberos 的 DES/RC4 加密套件，仅允许 AES
- TGT 票据默认生存期缩短至 4 小时，且不可续订
- 禁止使用约束/非约束委派，禁止 CredSSP 缓存明文凭据
- 登录设备上不缓存任何类型凭据（NTOWF、Kerberos 密钥、摘要等）
该组生效前提是：用户从Windows 8.1 / Windows Server 2012 R2 或更高版本终端登录，且域功能级别 ≥ Windows Server 2012 R2。
安全维护实操要点
维护不是一次性配置，而是持续闭环：
- 严格控制成员资格：仅将确需高权限的账户加入 Protected Groups；Protected Users 组应覆盖所有特权账户（如域管、备份操作员）、敏感岗位账户（如HR、财务系统管理员），但避免加入服务账户或计算机账户
-
禁用内置 Administrator 账户：该账户 SID 为 S-1-5-
-500，始终豁免于 Protected Users 策略和身份验证策略，是攻击者首选目标，必须禁用并启用带强密码的替代管理员账户 - 启用 LAPS（本地管理员密码解决方案）：防止攻击者利用一台终端的本地管理员权限横向移动至其他工作站
- 部署认证策略（Authentication Policies）：配合 Protected Users 使用，可进一步限定 TGT 生存期（最长 600 分钟）、指定允许登录的设备 OU 或设备条件（如是否启用 BitLocker、是否为已知安全基线）
- 定期审计与告警：通过事件 ID 4732（添加到安全组）、4728（添加到启用组策略的组）监控 Protected Groups 成员变更；启用高级审核策略，捕获 Kerberos 预认证失败、NTLM 回退等异常行为
常见误区与规避建议
实践中容易忽略的关键细节：
- Protected Users 对域控制器本身无效：该组策略在客户端设备生效，DC 上的登录行为不受其限制。若需保护 DC 登录，须单独配置登录限制策略或使用 JIT 管理方案
- 加入 Protected Users 后无法脱机登录：依赖域控制器实时验证，网络中断时将无法登录 —— 需提前评估业务连续性影响，必要时为关键运维人员保留备用通道（如本地管理员 + LAPS）
- 旧系统兼容性风险：若组织仍存在 Windows 7 或 Server 2008 R2 终端，Protected Users 组成员在其上登录将完全失去保护效果，应优先淘汰或隔离此类设备
- 不要把域管理员直接加进 Protected Users 后就认为万事大吉：仍需同步实施 SMB 签名强制、LDAP 签名/通道绑定、禁用 WDigest 等配套措施，否则攻击链仍可能成立
