I have 2 physical hosts running Server 2008 R2, one working fine, the other has broken NLA. Identical hardware, same patch level, same OU (therefore, same GPO). Hosts are a Hyper-V high availability cluster, so they are as near identical to each other (except for name, IP, SID, GUID) as you can imagine. Both machines have signed certificates from our internal CA, both have GP's that specify the certificate to use for RD server authentication. Manually checking the RDS session host config shows the correct certificate is being used. One one box, everything works fine; on the other it started giving me errors verifying host identity when using RDP a few weeks ago. Doesn't matter which client I use (checked a number of Windows 7 and 8, all running up-to-date RDP clients, and showing NLA as supported), and even tried MS Remote Desktop App on a Mac.
On the broken host, with NLA disabled in the remote settings, I get the typical "The identity of the remote computer cannot be verified" error. If I enable/enforce NLA, I lose the ability to connect and get the error "The remote computer requires Network Level Authentication which your computer does not support." (This error is itself an error as the client computer I am using most definitely does support NLA, and does so with other hosts)
- I have tried rebuilding the Cryptographic Service Provider cache (C:\Windows\System32\catroot2)
- I have verified that the file C:\Windows\System32\credssp.dll is the right version and not corrupt (same hash thumprint as the same file on a working host),
- I have checked the registry at HLKM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp and verified that it matches all the settings of a working host
- I have checked HKLM\SYSTEM\CurrentControlSet\Control\Lsa > Security Packages and can see that it contains the tspkg value in the list
- I have checked HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders > SecurityProviders contains the value credssp.dll
- I have checked HKLM\SYSTEM\CurrentControlSet\Control\Lsa\SspiCache\credssp.dll contains the same values as a working machine
I've run out of ideas.