受保护的用户安全组到底防住了什么
受保护的用户（Protected Users）是微软从 Windows Server 2012 R2 域功能级别开始引入的一个全局安全组。它不是普通的权限组，而是一个触发身份验证行为变化的特殊标记：只要把账户加入这个组，域控在对该账户进行身份验证时会自动套用一组强制的保护策略，无论账户本身的属性如何设置。
它主要防住以下几类攻击场景。第一是哈希传递攻击，攻击者拿到 NTLM 哈希后不需要知道明文密码就能冒充用户，而受保护的用户组直接禁止 NTLM 单向认证，强制走 Kerberos。第二是 Kerberoasting 类攻击，因为该组强制 Kerberos 使用 AES 加密，拒绝较弱的 DES 和 RC4 加密类型，抓到的票据几乎无法离线破解。第三是 WDigest 和 CredSSP 场景下的明文密码缓存问题，加入该组后系统不会把凭据以明文形式保存在 LSASS 内存里，即使机器被攻破，攻击者也很难从内存中提取可用凭据。
具体来说，账户加入该组后会触发这些行为限制：
- 通过 NTLM 进行身份验证被完全拒绝
- Kerberos 预认证不再使用 DES 或 RC4 加密类型
- 无法通过委托进行不受约束或受约束的委派
- 凭据不会缓存在 NTDS 数据库中供脱机攻击使用
- WDigest 认证不会将明文密码存储在内存中
- Smart card 或 Windows Hello 登录之外，长期有效的 TGT 默认寿命限制在四小时以内
这些限制的核心逻辑是：即使攻击者已经在内网横向移动，拿到了hash或票据，也无法用它们完成后续的认证，从源头上切断了凭据重用的攻击链。
配置步骤与前提条件详解
在动手之前，需要先确认环境满足几个前提。首先域功能级别必须是 Windows Server 2012 R2 或以上，其次客户端和域控的操作系统也要足够新，否则某些保护项不会生效。比如四小时 TGT 限制需要域控运行 Windows Server 2012 R2 以上版本，而 NTLM 拒绝行为需要客户端也支持相应策略。
最简单的配置方式就是把用户账户加入内置的 Protected Users 组。可以通过图形界面操作，也可以用 PowerShell 一条命令完成：
# 将单个用户加入受保护的用户组 Add-ADGroupMember -Identity "Protected Users" -Members "zhangsan" # 批量加入多个用户 Add-ADGroupMember -Identity "Protected Users" -Members "zhangsan","lisi","wangwu" # 验证组成员列表 Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, SamAccountName
需要注意的是，这个组的设计对象是用户账户，而不是服务账户或计算机账户。把服务账户加进去可能导致依赖 NTLM 的老应用认证失败，这一点必须提前评估。如果环境中运行着只支持 NTLM 的遗留系统（比如某些老旧的 ERP 客户端、网络设备管理界面），相关账户加入后这些系统会立即无法登录。
除了直接加组之外，还可以通过身份验证策略（Authentication Policy）实现更细粒度的控制。这种方式借助动态访问控制和 Kerberos 域支持的策略，可以针对特定的账户集合配置 TGT 生存期、允许的设备声明等，比直接加组灵活得多。配置入口在活动目录管理中心，创建身份验证策略后关联到对应的用户对象即可。
# 查看当前域功能级别是否符合要求
(Get-ADDomain).DomainMode
# 检查是否还存在使用 RC4 弱加密的账户
Get-ADUser -Filter {Enabled -eq $true} -Properties msDS-SupportedEncryptionTypes |
Where-Object { $_.msDS-SupportedEncryptionTypes -eq $null }
执行完加组操作后，建议让用户重新登录一次，因为身份验证行为的变更要重新获取 TGT 之后才会完全生效。同时可以用 klist 命令查看当前的票据加密类型，确认已经从 RC4 切换到 AES。
落地过程中的常见坑与最佳实践
第一个常见的坑是服务账户误加入。有些管理员为了省事，把整个 OU 下的账户批量导入该组，结果第二天一堆计划任务和服务启动失败。正确的做法是先梳理账户用途，把服务账户迁移到独立的 gMSA（组托管服务账户）体系，或者使用账户属性中的委派和加密类型设置来单独加固，而不是依赖这个用户专属的保护组。
第二个坑是智能卡要求。受保护的用户组在旧版本客户端上可能触发智能卡登录的强制要求，导致没有发卡的账户直接无法登录。上线前务必在测试环境验证目标用户的登录方式，特别是还在用密码+远程桌面组合的运维人员。远程桌面场景下，如果 RDP 配置为允许凭据保存，也可能出现连接被拒绝的情况，需要配合网络级别身份验证和相应的 GPO 一起调整。
第三个坑是缓存凭据的副作用。受保护的账户无法通过缓存的域凭据在断网状态下登录笔记本，经常出差的员工可能反馈离线登录失败。这个问题可以通过合理配置缓存的域凭据数量、配合 Windows Hello 企业版来解决，而不是简单地撤销保护。
推荐的上线路径：先在测试 OU 中挑几名 IT 人员加入该组观察一到两周，确认日常办公、VPN、远程桌面、遗留应用全部正常后，再按部门分批推广。推广期间保留一份快速回退命令，遇到业务受阻可以立即将账户移出组恢复原有行为。
从长期治理角度看，受保护的用户组应当被视为高价值账户的强制基线：所有具备域管理员权限的账户、敏感数据的访问者、高管账户都应默认加入。普通员工则可以结合密码策略、账户属性和身份验证策略分层管理。微软官方也明确表示未来会基于这个组持续增强保护能力，比如进一步收紧 TGT 策略和与 Windows Hello 的深度整合，因此尽早把它纳入账户治理体系，是应对凭据窃取类攻击性价比最高的手段之一。
受保护的用户Active Directory安全组修改时间：2026-09-13 11:03:08