Situation: Using a Windows 10 workstation, that's in the domain OFFICE, I initiate a RDP connection using smart card logon and certificates to a RDS gateway in a foreign domain REMOTE. The foreign domain accepts certificates from CA OFFICE-CA that issued certs on the smart card used, which is in the same domain that contains the workstation. RDP authentication results in an error 0xc000006d/0xc000006a (unknown user name). Server's event logs report that authentication was attempted with explicit credentials that used source domain OFFICE instead of destination domain REMOTE. If I test logging in locally on a PC that's joined to REMOTE domain using the same smart card, the DC grants access with the user user@office.com which is equal to REMOTE\user. So, the certificate-based authorization is set up properly.
I went a little forward and enabled "Allow user hints" in the OFFICE domain policy, allowing Windows 10's RDP client to supply the expected domain\username to the remote RDS server, initiated the RDP session and supplied the expected string REMOTE\user as user hint to help authorize the connection. This time RDP succeeds with authorization based on server logs, however, the RDP client throws "user unknown" error and forcibly closes the RDP connection from local side. Digging into the problem, I have come across this article explaining NLA that, among other stuff, contains the following:
When you type your credentials into this dialog box, even if you don’t choose to save them, they go to CredSSP. This then passes the credentials to the RD Session Host server via a secure channel.
Therefore, the validation should succeed either way, user hint or not. Apparently, Windows 10 RDP client mstsc.exe tries validating the credentials (the certificate) on the local side first, determines the domain\username and sends THAT to the remote side, which obviously has different domain\username and does not authorize the connection. If I enable and provide the user hint, the hint is apparently validated at local side as well, and obviously fails, while remote side does correctly validate the certificate-based credentials.
The question is as follows:
- When did the initial behavior of NLA get changed?
- How can I control whether client-side credentials validation will be used prior to validating them on the remote side, and disable it?
- Do I need to configure something extra on the remote side to both maintain NLA and allow RDP connection from a RDP client located anywhere that supplied a smart card certificate as credentials, provided the certificate is valid?
