How to Harden Credential Protection on Windows Server 2012 R2

Protecting credentials from theft is one of the most critical security objectives for any Windows Server environment. Credential Guard, which uses virtualization-based security to isolate credential material from the OS kernel, is a Windows Server 2016 and later feature and is not available on Windows Server 2012 R2. However, Server 2012 R2 introduced several powerful credential protection mechanisms: the Protected Users security group, Authentication Policy Silos, and Kerberos armoring (FAST). These features, combined with disabling legacy authentication protocols and configuring LSA protection, significantly raise the bar against credential theft attacks such as Pass-the-Hash and Pass-the-Ticket. This guide covers all available credential hardening techniques for Server 2012 R2.

Prerequisites

The domain must be at Windows Server 2012 R2 functional level for Protected Users group and Authentication Policy Silos to be available. The forest functional level should be at least Windows Server 2003. You need Domain Admin rights to create and manage Protected Users membership and Authentication Policies. All Domain Controllers must be running Windows Server 2012 R2 to enforce these policies. Test all changes in a non-production environment first, as adding accounts to Protected Users removes several authentication protocol fallbacks that some applications depend on.

Enabling LSA Protection

Local Security Authority (LSA) protection prevents non-protected processes from injecting code into the LSASS process, which stores credential hashes. Enable it via registry:

# Enable LSA Protected Process Light (PPL) mode
# This prevents tools like Mimikatz from dumping credentials directly from LSASS
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "RunAsPPL" -Value 1 -Type DWord

# Verify the setting
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" -Name "RunAsPPL"

This requires a restart to take effect. After restart, verify the protection is active by checking the System event log:

# Event 12 from WinInit = LSASS started as protected process
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WininInit'} |
    Where-Object {$_.Id -eq 12}

Disabling WDigest Credential Caching

By default on older systems, WDigest authentication stores cleartext credentials in memory that can be retrieved by attackers. Disable this on Server 2012 R2:

# Disable WDigest cleartext credential storage in LSASS memory
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecurityProvidersWDigest" `
    -Name "UseLogonCredential" -Value 0 -Type DWord

# Verify
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecurityProvidersWDigest" `
    -Name "UseLogonCredential"

Apply this setting to all servers and workstations via Group Policy: Computer Configuration > Preferences > Windows Settings > Registry. Add a registry preference for HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigestUseLogonCredential set to DWORD value 0.

Adding Accounts to the Protected Users Group

The Protected Users security group, introduced in Windows Server 2012 R2, applies automatic credential protection to member accounts without requiring individual configuration. Accounts in this group:

Cannot authenticate using NTLM, Digest, or CredSSP — Kerberos only
Kerberos tickets are not cached; user must re-authenticate when connectivity is lost
Kerberos TGT lifetime is limited to 4 hours (not renewable)
DES and RC4 encryption types are not used in Kerberos pre-authentication

# Add Domain Admins members to Protected Users group
Add-ADGroupMember -Identity "Protected Users" -Members "jsmith.admin", "ldoe.admin"

# Add all accounts in a specific admin OU to Protected Users
Get-ADUser -Filter * -SearchBase "OU=AdminAccounts,DC=domain,DC=com" |
    ForEach-Object { Add-ADGroupMember -Identity "Protected Users" -Members $_ }

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

Important: Do NOT add service accounts to Protected Users, as their inability to use NTLM will break many services. Domain Controllers and accounts used for RADIUS authentication should also be excluded.

Configuring Authentication Policy Silos

Authentication Policy Silos allow you to restrict which computers a privileged account can authenticate to and from, limiting lateral movement even if credentials are compromised. This requires a Windows Server 2012 R2 functional level domain:

# Create an Authentication Policy for admin accounts
# Limit TGT lifetime to 60 minutes for user accounts
New-ADAuthenticationPolicy -Name "AdminAccountPolicy" `
    -Description "Restrict admin credentials to PAWs" `
    -UserTGTLifetimeMins 60 `
    -ProtectedRequired $true

# Create an Authentication Policy Silo
New-ADAuthenticationPolicySilo -Name "AdminSilo" `
    -Description "Isolate admin credentials to designated workstations" `
    -UserAuthenticationPolicy "AdminAccountPolicy" `
    -ServiceAuthenticationPolicy "AdminAccountPolicy" `
    -ComputerAuthenticationPolicy "AdminAccountPolicy"

# Assign admin users to the silo
Grant-ADAuthenticationPolicySiloAccess -Identity "AdminSilo" `
    -Account "jsmith.admin"

Set-ADUser -Identity "jsmith.admin" `
    -AuthenticationPolicySilo "AdminSilo"

# Assign Privileged Access Workstations (PAWs) to the silo
Grant-ADAuthenticationPolicySiloAccess -Identity "AdminSilo" `
    -Account "PAW01$"

Set-ADComputer -Identity "PAW01" `
    -AuthenticationPolicySilo "AdminSilo"

Enabling Kerberos Armoring (FAST)

Kerberos Flexible Authentication Secure Tunneling (FAST) protects Kerberos exchanges against offline dictionary attacks by wrapping them in a tunnel. Configure via Group Policy:

# Configure via GPO:
# Computer Configuration > Administrative Templates > System > KDC
# "KDC support for claims, compound authentication, and Kerberos armoring"
# Set to: Supported OR Required

# Also configure clients:
# Computer Configuration > Administrative Templates > System > Kerberos
# "Kerberos client support for claims, compound authentication and Kerberos armoring"
# Set to: Enabled

# Verify Kerberos armoring on a KDC via registry check
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesKdc" -Name "ClaimsEncryptionEnabled" -ErrorAction SilentlyContinue

Restricting NTLM Authentication

NTLM is a legacy protocol vulnerable to Pass-the-Hash attacks. Progressively restrict NTLM across the environment:

# Step 1: Audit NTLM usage before restricting (prevents service outages)
# Enable NTLM auditing via Group Policy:
# Computer Configuration > Windows Settings > Security Settings > 
# Local Policies > Security Options
# "Network security: Restrict NTLM: Audit NTLM authentication in this domain" = Enable all

# Step 2: After reviewing audit logs, restrict outbound NTLM
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "RestrictSendingNTLMTraffic" -Value 2 -Type DWord
# Values: 0=Allow, 1=Audit, 2=Deny

# Step 3: Add exceptions for servers that legitimately need NTLM
# Via GPO: "Network security: Restrict NTLM: Add server exceptions in this domain"
# List servers that still require NTLM (e.g., legacy applications, NAS devices)

Removing Cached Domain Credentials

By default, Windows caches the last 10 domain credential hashes locally (for offline logon). On servers, this is generally unnecessary and provides attackers an additional credential source:

# Set cached credential count to 0 on servers
# (Do NOT do this on laptops that need offline logon capability)
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon" `
    -Name "CachedLogonsCount" -Value "0"

# Apply via Group Policy:
# Computer Configuration > Windows Settings > Security Settings >
# Local Policies > Security Options
# "Interactive logon: Number of previous logons to cache" = 0

Verification

Verify the credential protection configuration:

# Check LSA protection
(Get-ItemProperty "HKLM:SYSTEMCurrentControlSetControlLsa").RunAsPPL

# Check WDigest
(Get-ItemProperty "HKLM:SYSTEMCurrentControlSetControlSecurityProvidersWDigest").UseLogonCredential

# Check Protected Users group membership
Get-ADGroupMember "Protected Users" | Select-Object Name

# Check Authentication Policies
Get-ADAuthenticationPolicy | Select-Object Name, UserTGTLifetimeMins

# Check Authentication Policy Silos
Get-ADAuthenticationPolicySilo | Select-Object Name, Description

Summary

While Credential Guard requires Windows Server 2016 or later, Windows Server 2012 R2 provides substantial credential protection through LSA Protected Process mode, disabling WDigest caching, the Protected Users security group, Authentication Policy Silos, and NTLM restriction. The most impactful quick wins are: enabling LSA PPL mode, disabling WDigest, and adding all privileged admin accounts to the Protected Users group. These changes close the most common credential theft attack vectors and are foundational to a defense-in-depth security strategy.

How to Enable Credential Guard on Windows Server 2012 R2