Tools · Active Directory defense · 09 / 23
The Protected Users group: what it does and who belongs in it
Add privileged accounts to Protected Users to block NTLM, RC4, delegation, and credential caching for them, and avoid the accounts that should never be added.
What membership changes
Protected Users is a global security group introduced with Windows Server 2012 R2. For members, devices will not cache plaintext credentials or NTLM hashes for single sign-on, NTLM authentication is refused, Kerberos will not use DES or RC4, accounts cannot be delegated, and TGTs have a non-renewable four-hour lifetime by default.
Those limits remove whole categories of credential theft and reuse for the accounts that matter most.
Who should and should not be members
Add human administrator accounts: domain admins, enterprise admins, server admins. Test with one account first, because anything relying on NTLM or cached logons for that user will break. Do not add service accounts, computer accounts, or gMSAs; they would lose authentication methods they depend on.
Keep at least one break-glass account outside the group, stored securely, in case Kerberos itself has a problem.
Lab: add an admin and observe
Add your lab admin account to Protected Users. Log off and on. Run klist and note the four-hour TGT. Try to access a share by IP address, which forces NTLM, and observe the failure, then access by name and succeed with Kerberos. On the DC, check for 4776 failures or the Microsoft-Windows-Authentication/ProtectedUser-Client and ProtectedUserFailures-DomainController logs.
This exercise also shows why admins should use names, not IP addresses.
Add-ADGroupMember -Identity 'Protected Users' -Members admin-me klist purge; klist dir \\192.168.56.11\share # fails: NTLM blocked dir \\srv01.lab.internal\share # works: Kerberos Get-WinEvent -LogName 'Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController' -MaxEvents 10 -ErrorAction SilentlyContinue
Authentication policies and silos
Authentication policies and silos go further by restricting where an account may log on, for example only from Tier 0 admin workstations. They require Kerberos armoring and careful planning but enforce tiering technically rather than by policy document.
Start with Protected Users, then consider silos for the smallest, most privileged set of accounts.
Diagram
An admin account outside and inside Protected Users
What a compromised workstation could obtain.
Cached. NTLM hash and possibly credentials in memory.
Protocols. NTLM and RC4 allowed.
Delegation. Can be delegated.
Cached. No NTLM hash or plaintext cached.
Protocols. Kerberos with AES only.
Delegation. Never delegated; 4-hour TGT.
Check yourself
1. Which happens for Protected Users members?
2. Which accounts should not be added?
3. What is the default TGT lifetime for members?