How to Configure the Protected Users Security Group on Windows Server 2012 R2

How to Configure the Protected Users Security Group on Windows Server 2012 R2

The Protected Users security group is a new security principal introduced in Windows Server 2012 R2 that provides automatic, non-configurable credential protections for its members. Unlike standard security groups, membership in Protected Users triggers behavioral changes in both the client (Windows 8.1+) and the domain controller (Windows Server 2012 R2+). These protections directly address the most common credential theft and lateral movement techniques including Pass-the-Hash, Pass-the-Ticket, and NTLM relay attacks. This guide covers exactly what protections are applied, how to safely add accounts, and how to verify the group is functioning correctly.

Prerequisites

• Active Directory domain with at least one Windows Server 2012 R2 domain controller that holds the PDC Emulator FSMO role
• Domain functional level does not need to be raised—the group works at any domain functional level as long as a WS2012R2 PDC Emulator exists
• Accounts being added to Protected Users must not rely on NTLM authentication, Kerberos unconstrained or constrained delegation, or DES/RC4 Kerberos encryption

Step 1: Understand Protected Users Protections

When a user account is a member of Protected Users, the following non-configurable protections are enforced:

On Windows 8.1 / Windows Server 2012 R2 devices:

• Credentials are not cached in the LSASS process—prevents credential harvesting by Mimikatz and similar tools
• WDigest authentication is disabled—prevents cleartext credential storage
• CredSSP (Credential Security Support Provider) is disabled—prevents credential delegation via RDP in CredSSP mode
• NTLM is disabled—the account cannot authenticate via NTLM at all
• DES and RC4 encryption is disabled for Kerberos—requires AES
• Kerberos TGT lifetime is limited to 4 hours and is non-renewable

On Windows Server 2012 R2 domain controllers:

• NTLM authentication is blocked for Protected Users accounts
• DES and RC4 Kerberos pre-authentication is blocked
• Kerberos TGT tickets are not cached on the DC for delegation
• Short TGT validity enforced (4 hours, 4-hour renewable)

Step 2: Audit Accounts Before Adding Them

Before adding any account to Protected Users, verify that the account does not have dependencies that would break with these protections applied:

Import-Module ActiveDirectory

# Check for accounts with constrained delegation (will break if added to Protected Users)
Get-ADUser -Filter { TrustedToAuthForDelegation -eq $true -or msDS-AllowedToDelegateTo -like "*" } `
    -Properties TrustedToAuthForDelegation, "msDS-AllowedToDelegateTo" |
    Select-Object Name, SamAccountName, TrustedToAuthForDelegation, "msDS-AllowedToDelegateTo"

# Check for service accounts using Kerberos DES encryption (will break)
Get-ADUser -Filter { UseDESKeyOnly -eq $true } -Properties UseDESKeyOnly |
    Select-Object Name, SamAccountName

# Check for accounts using RC4 Kerberos
# In most domains all modern accounts support AES, but verify:
Get-ADUser -Filter * -Properties kerberosEncryptionType |
    Where-Object { $_.kerberosEncryptionType -notmatch "AES" } |
    Select-Object Name, kerberosEncryptionType

Step 3: Add Accounts to Protected Users

Start with the highest-privilege accounts that pose the greatest risk if compromised—Domain Admins, Schema Admins, Enterprise Admins:

# Add individual privileged user accounts to Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "AdminUser1","AdminUser2"

# Add all members of Domain Admins to Protected Users
$domainAdmins = Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Where-Object { $_.objectClass -eq "user" }

foreach ($admin in $domainAdmins) {
    Add-ADGroupMember -Identity "Protected Users" -Members $admin.SamAccountName
    Write-Host "Added to Protected Users: $($admin.Name)"
}

# Verify current membership
Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, SamAccountName, objectClass

Step 4: Verify Protections Are Active

After adding an account, verify that the protections are active on the PDC Emulator. The PDC Emulator enforces the group’s protections for domain-wide authentication:

# Identify the PDC Emulator
Get-ADDomainController -Filter { OperationMasterRoles -eq "PDCEmulator" } |
    Select-Object Name, IPV4Address, OperatingSystem

# Check Windows Server 2012 R2 PDC Emulator is handling Kerberos authentication
# Protected Users protections require a WS2012R2 PDC Emulator
$pdc = (Get-ADDomain).PDCEmulator
$pdcVersion = (Get-ADComputer $pdc.Split('.')[0] -Properties OperatingSystem).OperatingSystem
Write-Host "PDC Emulator: $pdc - OS: $pdcVersion"

Step 5: Test Authentication After Adding to Protected Users

After adding an account to Protected Users, test that it can still authenticate normally (via Kerberos AES) and that NTLM authentication is correctly blocked:

# Test that the account can still log on interactively (Kerberos)
# On a Windows 8.1+ workstation, log on as the Protected User - should work normally

# Verify Kerberos ticket was issued (should be AES256-CTS)
klist tickets

# On a domain controller, check that NTLM authentication is rejected for Protected Users
# Event ID 4624 with AuthenticationPackageName NTLM should fail for Protected Users
# Event ID 4625 should appear if NTLM was attempted

Get-WinEvent -LogName Security -FilterXPath `
    "*[System[EventID=4625] and EventData[Data[@Name='AuthenticationPackageName']='NTLM']]" `
    -MaxEvents 20 | Select-Object TimeCreated, Message

Step 6: Monitor for Protected Users Authentication Events

Domain controllers generate specific events when Protected Users authentication protections are applied:

# Enable logging of Protected Users-related events
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

# Event IDs relevant to Protected Users:
# 4624 - Successful logon (check for Kerberos AES vs. NTLM)
# 4625 - Failed logon (NTLM attempt by Protected User will appear here)
# 4769 - Kerberos service ticket request
# 4771 - Kerberos pre-authentication failed (check for RC4 attempt)

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4771]]" -MaxEvents 20 |
    Select-Object TimeCreated, Message | Format-List

Step 7: Handle Service Accounts

Do not add service accounts to Protected Users without extensive testing. Most service accounts require NTLM fallback or have Kerberos delegation configured. Instead, use alternative protections for service accounts:

# For service accounts, use Managed Service Accounts or Group Managed Service Accounts
# instead of adding to Protected Users

# Create a Group Managed Service Account (gMSA) - these are inherently more secure
New-ADServiceAccount -Name "gMSA-WebApp" `
    -DNSHostName "webapp.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "WebServers-Group" `
    -Description "Group Managed Service Account for Web Application"

# Install gMSA on the target server
Install-ADServiceAccount -Identity "gMSA-WebApp"

# Test the gMSA
Test-ADServiceAccount -Identity "gMSA-WebApp"

Step 8: Remove Accounts If Issues Arise

If an account added to Protected Users experiences authentication problems (common causes: legacy application using NTLM, delegation-based service, old Kerberos encryption), remove it immediately:

# Remove a specific account from Protected Users
Remove-ADGroupMember -Identity "Protected Users" -Members "ProblematicUser" -Confirm:$false

# Note: Changes take effect at next logon - the user may need to log off and back on
Write-Host "Removed from Protected Users. User must log off and log back on for changes to take effect."

Summary

The Protected Users security group on Windows Server 2012 R2 is one of the most impactful single controls you can implement to protect privileged accounts from credential theft attacks. By understanding the non-configurable protections it applies, auditing accounts for NTLM and Kerberos delegation dependencies before adding them, starting with Domain Admins and other highest-privilege accounts, and monitoring for authentication failures after group membership changes, you have significantly raised the bar for attackers attempting Pass-the-Hash, Pass-the-Ticket, or NTLM relay attacks against your most critical accounts. Combine Protected Users with LAPS, Restricted Admin Mode, and a tiered administration model for comprehensive credential defense-in-depth.