The Protected Users Group: Windows' Built-In Defense Against Credential Theft

Most Active Directory hardening advice tells you to turn things off: disable WDigest, kill NTLM, remove unconstrained delegation. Each is a separate registry key, GPO, or delegation setting you have to audit and maintain across the domain. Microsoft shipped a single group that flips most of those switches at once — but only for the accounts you place in it. It's called Protected Users, it's been in every domain since the Server 2012 R2 schema, and in most environments it's completely empty.

If an attacker who lands on a workstation can dump credentials from LSASS, the highest-value prize is a domain admin's cached hash or Kerberos ticket. Protected Users is the built-in control that makes those prizes far harder to steal. It is not a silver bullet, and it will break things if you deploy it blindly — so let's cover exactly what it changes.

What Protected Users actually enforces

Membership applies protections in two places: on the client where the account authenticates, and on the domain controller that authenticates it. On a supported OS, members of Protected Users get the following, non-configurable, restrictions:

• No NTLM authentication. The account can only use Kerberos. This alone neutralizes pass-the-hash and NTLM relay for that identity.
• No WDigest or CredSSP plaintext caching. The cleartext password is never stored in LSASS, closing the classic mimikatz sekurlsa::wdigest path.
• No long-term credential caching. Cached (offline) domain logon is disabled, so the account cannot log on when a DC is unreachable.
• No DES or RC4 in Kerberos pre-authentication. Only AES is used, shrinking Kerberoasting and downgrade opportunities.
• No unconstrained or constrained delegation. The account cannot be delegated, so a compromised delegating service can't impersonate it.
• Short Kerberos ticket lifetime. TGTs are issued with a 4-hour maximum, capping how long a stolen ticket stays useful.

What it breaks — plan before you add anyone

The same protections that stop attackers also stop legitimate workflows that depend on the disabled behavior. Before you add an account, confirm it does not rely on:

• NTLM-only services. Anything reached by IP address instead of a Kerberos SPN, legacy appliances, or scheduled tasks that authenticate over NTLM will fail.
• Offline logon. Laptops that log on away from the network will lock out members. Never add end-user accounts that roam without VPN.
• Delegation. Service accounts that are trusted for delegation must not be members — the delegation simply stops working.
• Old operating systems. Protections require the DC to be Server 2012 R2 functional level and the client to be Windows 8.1 / Server 2012 R2 or later. On older clients the account is unprotected but the delegation and ticket-lifetime restrictions still apply DC-side.

Rule of thumb: Protected Users is for interactive admin identities (Tier 0 accounts), not service accounts and not roaming users. Put your domain admins there; use gMSA and constrained delegation for services.

Rolling it out safely

Treat it as a staged change, not a bulk operation. Start with one test admin account, exercise every admin workflow that account performs, then expand.

# Add a single test admin, verify, then widen
Add-ADGroupMember -Identity "Protected Users" -Members "adm-test"

# Confirm current membership before a wider rollout
Get-ADGroupMember -Identity "Protected Users" | Select-Object name, objectClass

# On the client, prove NTLM is no longer usable for the account:
#   Event ID 4776 on the DC should stop appearing for it,
#   and Kerberos-only 4768/4769 events should remain.

Pair the group with the companion Authentication Policies and Silos feature to restrict where those accounts can log on at all — for example, only to designated privileged access workstations. Protected Users hardens the credential; silos constrain where it can be used.

Verifying and monitoring posture with WinSentinel

The failure mode here is silent: the group exists, everyone assumes their admins are in it, and nobody notices it's empty until an incident review. WinSentinel audits this directly. On any machine, the free agent runs the full set of 33 modules with no limits — including credential-hardening checks that flag WDigest caching, NTLM exposure, and whether privileged local accounts are configured for the protections Protected Users provides. You get a scored finding and a concrete remediation step, not just a green checkmark.

For organizations running WinSentinel Pro, the central node rolls these findings up across the fleet: you can see at a glance which domain-joined machines still allow NTLM for privileged identities, get a drift alert the moment a previously-hardened account regresses, and map the result to CIS and other compliance baselines for reporting. That fleet-wide view is what turns "we think our admins are protected" into "we can prove it across every endpoint."

The takeaway

Protected Users is one of the highest-leverage, zero-cost hardening steps available in Active Directory, and it ships turned off. Add your Tier 0 admin accounts deliberately, test for the NTLM/offline/delegation breakage first, combine it with authentication silos, and then keep verifying that the configuration hasn't drifted. Credential theft remains the most common pivot in real intrusions — this is a built-in control that takes the crown jewels off the table.