How to Configure User Account Control on Windows Server 2012 R2

How to Configure User Account Control on Windows Server 2012 R2

User Account Control (UAC) is a security feature in Windows Server 2012 R2 that limits the impact of malware and unauthorized changes by running applications with standard user privileges by default. When an application requires elevated privileges, UAC prompts for confirmation or credentials depending on the configured policy level. On servers, UAC behavior differs from workstations because most administrators log on interactively with accounts that have administrative rights. Properly configuring UAC — rather than disabling it — reduces risk from accidental or malicious changes while maintaining administrative functionality. This guide covers UAC configuration via Group Policy, registry settings, and secure administrative practices.

Prerequisites

UAC configuration requires Domain Admin or local Administrator rights. Changes to UAC settings take effect after the next logon or system restart (for some settings). In domain environments, UAC settings should be configured via Group Policy and applied to all servers in a consistent manner. Before making changes, document the current UAC configuration and test in a non-production environment. UAC interacts closely with the built-in Administrator account, Run As functionality, and Remote Desktop sessions.

Understanding UAC Configuration Settings

UAC is governed by several Group Policy and registry settings under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The key settings are:

• Admin Approval Mode — Whether the built-in Administrator runs in full-token mode or filtered-token mode
• Elevation prompt behavior for administrators — What happens when admin accounts need elevation
• Elevation prompt behavior for standard users — Whether standard users can enter admin credentials
• Detect application installations and prompt for elevation — Application installer detection
• Run all administrators in Admin Approval Mode — Master switch for UAC

Viewing Current UAC Registry Settings

UAC settings are stored in the registry at HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem:

# View all UAC registry values
Get-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" |
    Select-Object EnableLUA, ConsentPromptBehaviorAdmin, ConsentPromptBehaviorUser,
    EnableInstallerDetection, EnableSecureUIAPaths, EnableVirtualization,
    PromptOnSecureDesktop, ValidateAdminCodeSignatures | Format-List

Key registry values and their meanings:

# EnableLUA = 1          : UAC is enabled (master switch)
# ConsentPromptBehaviorAdmin values:
#   0 = Elevate without prompting (dangerous)
#   1 = Prompt for credentials on secure desktop
#   2 = Prompt for consent on secure desktop
#   3 = Prompt for credentials
#   4 = Prompt for consent
#   5 = Prompt for consent for non-Windows binaries (default)
# ConsentPromptBehaviorUser values:
#   0 = Automatically deny elevation requests
#   1 = Prompt for credentials on secure desktop
#   3 = Prompt for credentials (default)

Recommended UAC Configuration for Servers

For production servers, the recommended configuration requires administrators to consent or provide credentials for all elevation requests and runs everything on the secure desktop to prevent UI injection attacks:

# Enable UAC (master switch)
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "EnableLUA" -Value 1 -Type DWord

# Prompt for credentials (not just consent) on secure desktop for admin accounts
# Value 1 = Prompt for credentials on secure desktop
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "ConsentPromptBehaviorAdmin" -Value 1 -Type DWord

# Automatically deny elevation requests from standard users
# (Forces use of RunAs with admin account rather than prompting)
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "ConsentPromptBehaviorUser" -Value 0 -Type DWord

# Enable secure desktop for elevation prompts (prevents spoofing)
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "PromptOnSecureDesktop" -Value 1 -Type DWord

# Enable Admin Approval Mode for the built-in Administrator account
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "FilterAdministratorToken" -Value 1 -Type DWord

# Require signed and validated path for UIAccess applications
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "EnableSecureUIAPaths" -Value 1 -Type DWord

# Enable file and registry write failure virtualization for legacy applications
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "EnableVirtualization" -Value 1 -Type DWord

Configuring UAC via Group Policy

Group Policy is the recommended method for domain environments. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options:

# Key GPO security option names and recommended settings:
# 
# "User Account Control: Admin Approval Mode for the Built-in Administrator account"
#   = Enabled
#
# "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode"
#   = Prompt for credentials on the secure desktop
#
# "User Account Control: Behavior of the elevation prompt for standard users"
#   = Automatically deny elevation requests
#
# "User Account Control: Detect application installations and prompt for elevation"
#   = Enabled
#
# "User Account Control: Only elevate executables that are signed and validated"
#   = Enabled (for high-security environments)
#
# "User Account Control: Only elevate UIAccess applications that are installed in secure locations"
#   = Enabled
#
# "User Account Control: Run all administrators in Admin Approval Mode"
#   = Enabled
#
# "User Account Control: Switch to the secure desktop when prompting for elevation"
#   = Enabled
#
# "User Account Control: Virtualize file and registry write failures to per-user locations"
#   = Enabled

Managing the Built-in Administrator Account

The built-in Administrator account (RID 500) by default runs without UAC restrictions in Admin Approval Mode. This is a significant security risk on servers. Ensure it is either disabled or has UAC enforcement enabled:

# Check status of the built-in Administrator account
$AdminAccount = [ADSI]"WinNT://./Administrator,user"
$AdminAccount | Select-Object @{N="Name";E={$_.Name}}, @{N="Disabled";E={$_.UserFlags}}

# Disable the built-in Administrator if a named admin account is in use
Disable-LocalUser -Name "Administrator"

# Rename the built-in Administrator for security through obscurity
Rename-LocalUser -Name "Administrator" -NewName "LocalAdmin_Retired"

Using Run As for Elevation Without Full Admin Sessions

A best practice is to log on as a standard user account and use runas or right-click Run As Administrator only when needed. This limits the exposure window of elevated tokens:

# Run a specific command with admin credentials
runas /user:DOMAINAdminAccount "powershell.exe -NoProfile"

# Run MMC snap-ins as admin
runas /user:DOMAINAdminAccount "mmc.exe diskmgmt.msc"

# Run PowerShell ISE with elevated credentials
runas /user:DOMAINAdminAccount "powershell_ise.exe"

Configuring UAC for Remote Administration

When administering servers remotely, UAC token filtering may block network logon attempts to administrative shares. The LocalAccountTokenFilterPolicy registry value controls this for local accounts:

# For domain accounts, UAC does not filter the token for remote admin by default
# For LOCAL accounts only, enable this if needed for remote management with local accounts
# (Note: enabling this reduces security - prefer domain accounts for remote admin)
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "LocalAccountTokenFilterPolicy" -Value 1 -Type DWord

# Verify current setting
Get-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem" `
    -Name "LocalAccountTokenFilterPolicy" -ErrorAction SilentlyContinue

Monitoring UAC Events

UAC elevation events are logged in the Security event log when audit policy is configured. Key event IDs to monitor:

# Event 4688: Process created (shows elevation when combined with 4703)
# Event 4703: A privilege was adjusted for a token (elevation granted)
# Event 4697: A service was installed (common with malicious elevation abuse)

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=@(4688,4703,4697)} -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message | Format-List

# Check for denied elevation attempts in Application log
Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-Security-SPP'} `
    -MaxEvents 20 -ErrorAction SilentlyContinue

Verification

Verify UAC is properly configured:

# Verify all key UAC settings
$UACPath = "HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem"
$Settings = Get-ItemProperty -Path $UACPath

Write-Host "UAC Enabled (EnableLUA): $($Settings.EnableLUA)"
Write-Host "Admin Prompt Behavior: $($Settings.ConsentPromptBehaviorAdmin)"
Write-Host "User Prompt Behavior: $($Settings.ConsentPromptBehaviorUser)"
Write-Host "Secure Desktop: $($Settings.PromptOnSecureDesktop)"
Write-Host "Built-in Admin Filter: $($Settings.FilterAdministratorToken)"

Summary

UAC on Windows Server 2012 R2 should be enabled and configured to require credentials (not just consent) on the secure desktop. Disable or rename the built-in Administrator account and enforce Admin Approval Mode. Configure UAC via Group Policy for consistency across all domain servers. The principle of least privilege — logging on as a standard user and elevating only when necessary — combined with UAC creates a meaningful defense layer against malware that attempts to gain administrative access through the current user’s token.