The Protected Users group: strong protections for privileged accounts, deployed with care
Introduced with Windows Server 2012 R2, the Protected Users group automatically applies a set of restrictions to its members. It is one of the most cost-effective measures for protecting administrative accounts, yet we find it empty in most of the directories we audit. A rushed rollout can lock administrators out, so method matters.
What the group provides
Protections apply at two levels: on devices where the member signs in (from Windows 8.1 and Windows Server 2012 R2), and on domain controllers when the domain functional level is at least Windows Server 2012 R2.
| Protection | Effect |
|---|---|
| No NTLM authentication | The account can only authenticate with Kerberos; its NT hash can no longer be used for NTLM authentication. |
| No DES or RC4 in Kerberos pre-authentication | Only AES is used, which makes offline attacks harder. |
| No delegation | The account cannot be delegated, whether through unconstrained or constrained delegation. |
| Short-lived TGTs | TGTs last four hours and cannot be renewed beyond that, unless a specific authentication policy says otherwise. |
| No client-side caching | No cached logon verifier, no default credential delegation through CredSSP, no clear-text password kept by WDigest. |
These protections cannot be tuned individually: group membership turns them all on.
Who belongs in the group
The natural candidates are named high-level administrative accounts: members of Domain Admins, Enterprise Admins, Schema Admins, Administrators, and more broadly every Tier 0 account. Server administration accounts can follow once you have gained experience.
Conversely, never put in it:
- computer accounts and service accounts, including gMSAs: services often depend on delegation or NTLM and would stop working;
- accounts that must sign in offline, such as on a laptop, since the cached verifier goes away;
- all of your emergency accounts: keep at least one break-glass account outside the group, strongly protected by other means, so you do not lose access if Kerberos fails.
Common pitfalls
Applications that require NTLM. Some consoles, appliances, or connections made by IP address rather than name fall back to NTLM. For a Protected Users member they fail. Inventory these uses before adding accounts, for example with NTLM auditing on domain controllers.
Session length. With a four-hour TGT, administrators sometimes need to re-authenticate during the day. That is by design, but it needs explaining.
Insufficient functional level. If the domain is still below the 2012 R2 functional level, only client-side protections apply. The absence of errors therefore does not prove effectiveness.
RC4-only accounts. Accounts whose AES keys were never generated, because their password has not changed since the move to a 2008 or later functional level, will no longer be able to authenticate. Reset their password before adding them.
Roll out in waves. Start with one or two volunteer administrators, observe a week of real use, then expand. Watch the dedicated authentication failure logs on domain controllers during each wave.
Complement, not replacement
Protected Users replaces neither tiering nor privileged access workstations. An administrator who signs in on a compromised device remains exposed: their TGT can be stolen while it is valid. The group combines well with the "Account is sensitive and cannot be delegated" flag, with authentication policies and with Credential Guard.
What an audit checks
- whether named privileged accounts are members of Protected Users;
- that no service or computer accounts are in the group;
- the domain functional level, a prerequisite for DC-side protections;
- the existence of a documented and monitored emergency account;
- any remaining dependency of privileged accounts on NTLM or RC4.