When dealing with Windows Server 2012 R2 with enforced Network Level Authentication (NLA) and NTLMv2, a reboot after updates can trigger the notorious RDP error: "An authentication error has occurred. The function requested is not supported". This becomes critical when physical access isn't available.

• Occurs after system reboots with NLA+NTLMv2 combo
• Registry tweaks for SecurityPackages often fail
• Group Policy edits on client-side may not resolve
• Particularly affects Windows Server 2012 R2 to Windows 10 connections

Method 1: CredSSP Update (Recommended)

The root cause often lies in CredSSP protocol version mismatch. Apply this registry patch on the client machine:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
"AllowEncryptionOracle"=dword:00000002

Method 2: NLA Temporary Bypass

If you have alternative access (like Azure Serial Console), modify this setting:

# PowerShell command to disable NLA temporarily
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "UserAuthentication" -Value 0
Restart-Service TermService -Force

Method 3: NTLM Fallback Configuration

Create a custom RDP file with these parameters:

enablecredsspsupport:i:0
authentication level:i:2

1. Check Event Viewer for Schannel errors (Event ID 36871)
2. Run Test-NetConnection -ComputerName server -Port 3389
3. Verify TLS settings with Get-TlsCipherSuite | Format-Table Name

• Keep CredSSP updated on both ends
• Maintain consistent encryption policies across domain
• Document fallback procedures before major updates
• Consider implementing RD Gateway as contingency

This particular RDP authentication error typically surfaces when there's a mismatch between the client and server security protocols, especially after server reboots or Windows updates. The "function not supported" message specifically indicates that the client is attempting to use an authentication method that the server no longer accepts.

• Recent Windows updates modifying security defaults
• Group Policy changes enforcing stricter NLA requirements
• Server-side credential guard being enabled
• NTLM version conflicts between client and server

Option 1: Modify Client Registry Settings

On your Windows 10 client machine:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
"AllowEncryptionOracle"=dword:00000002

Option 2: Temporary NLA Bypass

If you have alternative access methods like PowerShell Remoting:

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name "UserAuthentication" -Value 0
Restart-Service TermService -Force

These commands can help diagnose server configuration when accessed via other management tools:

# Check NLA status
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp").UserAuthentication

# Verify security packages
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" | Select-Object -ExpandProperty Protocols

The most robust approach involves ensuring protocol compatibility:

1. Update both client and server to latest patches
2. Standardize on CredSSP version 6 or higher
3. Configure Group Policy to allow fallback to legacy protocols if absolutely necessary

When possible, check these server event logs for authentication failures:

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" | 
Where-Object {$_.LevelDisplayName -eq "Error"} | 
Select-Object -First 10