“Protected Users Group Not Used” means privileged Active Directory accounts are not members of the built-in Protected Users group, so their credentials can still be cached on hosts and used with NTLM, RC4 and Kerberos delegation. To fix it, pilot with one admin, then add human admin accounts to the group, leaving service accounts and one break-glass admin out.

The change itself is a single group membership. The planning is about what those admins currently do with NTLM, offline laptops and delegation, because once an account is in the group Microsoft gives you no per-account exception.

What the scanner is actually detecting

This is a directory configuration finding, not a host vulnerability. Two Active Directory assessment tools report it:

Scanner	Finding	What triggers it
Tenable Identity Exposure	Protected Users Group Not Used (indicator C-PROTECTED-USERS-GROUP-UNUSED, listed as High)	Privileged users, such as domain administrators, that are not members of Protected Users. Tenable maps it to MITRE ATT&CK T1003.001 (LSASS Memory) and T1003.005 (Cached Domain Credentials).
PingCastle	P-ProtectedUsers, “Check if all privileged accounts are in the special group Protected Users.”	Enabled members of the privileged groups shown in the report’s Admin Groups section that sit outside Protected Users. The rationale line gives the count of unprotected admins.

PingCastle’s rule source adds useful detail. It skips disabled accounts and external (foreign) members, it skips group or standalone managed service accounts whose password rotates within 45 days, and it deliberately does not trigger when only one privileged account is outside the group, so you can keep an emergency account. It maps the rule to DISA STIG V-243477. A separate rule, A-ProtectedUsers, fires when the group does not exist at all because the PDC emulator has never run Windows Server 2012 R2 or later.

Real-world risk, stated honestly

Membership changes what Windows keeps in memory and what domain controllers accept. According to Microsoft, for a signed-in member the host stops caching the NT one-way function (the NTLM hash), CredSSP and WDigest stop caching plaintext credentials, Kerberos stops creating DES or RC4 keys, and no cached logon verifier is written. At Windows Server 2012 R2 domain functional level or higher, DCs also refuse NTLM for the account, reject DES and RC4 in Kerberos pre-authentication, block constrained and unconstrained delegation, and cap the TGT at 240 minutes with no renewal.

In practice this makes a Domain Admin who signs in to a compromised server much less useful to the attacker: there is no NT hash to pass, no cached verifier to crack offline, and a hash obtained elsewhere cannot be used for NTLM or RC4 pre-authentication. What it does not do is stop an attacker who already controls the host from using the live Kerberos tickets during their lifetime, or help once a domain controller is compromised. It is a strong mitigation, not a substitute for admin tiering, separate admin workstations and LSASS protection with Credential Guard.

How to confirm it on the host

Run these from a machine with the RSAT Active Directory module, as a domain admin:

Import-Module ActiveDirectory

# DC-side protections need Windows2012R2Domain or higher
(Get-ADDomain).DomainMode
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem

# Current members of Protected Users
Get-ADGroupMember -Identity 'Protected Users' | Select-Object Name, objectClass

# Privileged user accounts that are NOT in Protected Users
$protected = Get-ADGroupMember -Identity 'Protected Users' -Recursive |
    Select-Object -ExpandProperty distinguishedName
'Domain Admins','Enterprise Admins','Schema Admins','Administrators' | ForEach-Object {
    Get-ADGroupMember -Identity $_ -Recursive -ErrorAction SilentlyContinue
} | Where-Object { $_.objectClass -eq 'user' -and $protected -notcontains $_.distinguishedName } |
    Sort-Object distinguishedName -Unique |
    Select-Object Name, SamAccountName

Enterprise Admins and Schema Admins only exist in the forest root domain, which is why errors are suppressed. Extend the group list to whatever your scanner treats as privileged. Any result that is a service account is a separate problem: it should not be in an admin group, and it must not go into Protected Users.

How to fix it

1. Check the prerequisites

Functional level: Microsoft lists Windows Server 2012 R2 domain functional level or later. Below that, only the client-side protections apply. Once every DC runs 2012 R2 or later, raise it with Active Directory Domains and Trusts or Set-ADDomainMode.
Hosts: client-side protections apply on Windows 10, Windows 11 and Windows Server 2012 R2 or later.
AES keys: members can only use Kerberos with AES. Microsoft warns that an account whose password was last set on a pre-2008 DC, a migrated account, or a built-in Administrator whose password was never changed on a 2008 or later DC can be locked out. Reset the password of each account before you add it.

2. Find what the admin accounts still do with NTLM

With Audit Credential Validation enabled on DCs, event 4776 in the Security log records NTLM validations. Check each candidate account on every DC:

Get-WinEvent -LogName Security -MaxEvents 500 -FilterXPath `
  "*[System[EventID=4776] and EventData[Data[@Name='TargetUserName']='adm-jsmith']]" |
  Select-Object TimeCreated, Message

Every hit is something that will fail after membership. The usual causes are connections by IP address, appliances and web consoles using integrated NTLM, and scripts. Our guide to disabling NTLM safely covers how to trace and replace these.

3. Enable the Protected Users logs

These operational logs are disabled by default. Enable the two DC logs on every domain controller and the client log on the pilot admin’s workstation:

wevtutil sl Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController /e:true
wevtutil sl Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController /e:true
wevtutil sl Microsoft-Windows-Authentication/ProtectedUser-Client /e:true

The same logs are under Applications and Services Logs > Microsoft > Windows > Authentication in Event Viewer.

4. Pilot with one account, then expand

Add-ADGroupMember -Identity 'Protected Users' -Members 'adm-jsmith'

In the GUI, open the Protected Users group (in the Users container by default) in Active Directory Administrative Center or Active Directory Users and Computers and add the account on the Members tab. The pilot admin must sign out and back in, because the protections take effect at sign-in. After a normal work cycle with no unexpected failures, add the remaining human admins in Domain Admins, Enterprise Admins, Schema Admins and similar groups.

Never add service accounts, gMSAs or computer accounts. Microsoft says membership gives them no local protection because their secret is always on the host. Use authentication policies and the Account is sensitive and cannot be delegated flag for those instead.
Keep one break-glass admin outside the group, with a long random password stored offline and alerting on every use.
Watch the group: Protected Users is not protected by AdminSDHolder, so alert on security-enabled global group membership changes (events 4728 and 4729) for it.

How to verify the fix and rescan

In a new session as the pilot account, run whoami /groups and confirm Protected Users is listed.
Run klist. The krbtgt ticket should show an AES-256 encryption type and an end time four hours after its start time.
On a DC, the ProtectedUserSuccesses-DomainController log should show event 303 for the account. Failures appear as event 100 (NTLM) or 104 (DES or RC4) in ProtectedUserFailures-DomainController.
Optional negative test: net use \10.0.0.10c$ by IP address. Windows does not attempt Kerberos for IP addresses by default, so this falls back to NTLM and should now fail.
Rescan. Run a fresh PingCastle health check (PingCastle.exe –healthcheck –server contoso.local) and confirm P-ProtectedUsers is gone or lists only your break-glass account. In Tenable Identity Exposure, confirm the accounts no longer appear under the indicator once the change has replicated.

What can break and how to roll back

Anything using NTLM for that account: IP-address connections, older appliances, NTLM-only web consoles and tools. There is no exception list.
Offline sign-in: no cached verifier is created, so an admin laptop cannot sign in with that account without reaching a DC.
Long sessions: the TGT cannot be renewed past four hours and is not re-acquired automatically, so expect credential prompts during long admin sessions.
Delegation and double hop: constrained and unconstrained delegation fail, and CredSSP does not delegate saved default credentials.
Accounts without AES keys are locked out of Kerberos entirely.

Rollback is removing the account from the group, then signing out and back in once the change has replicated:

Remove-ADGroupMember -Identity 'Protected Users' -Members 'adm-jsmith' -Confirm:$false
klist purge

If every admin is affected at once, this is exactly what the break-glass account is for.

Common false positive reasons

The break-glass account. PingCastle tolerates one unprotected admin; other tools may still list it. Record it as an accepted exception rather than adding it.
Service accounts in admin groups. The finding is real, but the fix is removing them from the privileged group, not adding them to Protected Users.
Stale data. The assessment ran before replication or before the group change.
Stale admin accounts. Unused admin accounts that are still enabled keep the count up. Disable or remove them instead.
A clean result that is not really protected. Below 2012 R2 domain functional level, membership clears the finding while the DC-side protections do not apply.

FAQ

Can I add service accounts or gMSAs to Protected Users?

No. Microsoft says accounts for services and computers should never be members. Protect them with authentication policies, delegation restrictions and gMSA password rotation.

Does it work below Windows Server 2012 R2 domain functional level?

Partly. Hosts running Windows 10, 11 or Server 2012 R2 and later still apply the credential caching protections, but the DC-side NTLM, RC4, delegation and four-hour TGT restrictions need 2012 R2 functional level or higher.

How quickly does a membership change take effect?

At the account’s next sign-in, after the change has replicated to the DC that handles it. Existing sessions keep their old tickets until then.

Does Protected Users replace Credential Guard?

No. It limits what gets cached and what DCs accept, while Credential Guard isolates secrets from LSASS. They complement each other.

Tracking this finding across many hosts

This finding lives in the directory, but teams usually handle it next to host findings from other scanners. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners into one queue and merges duplicates per scanner, not across scanners. Its AI triage can suggest a false positive, such as a documented break-glass account, with evidence, and a human makes the decision.

Discovery and visibility

Scanning and collection

The AI layer

Action and closure

Team and governance

Reporting

Protected Users Group Not Used: How to Add Admins Without Locking Them Out