Using Kerberos for RDP

Question

We are in the process of turning off NTLM in our environment for both inbound and outbound traffic via GPO. In our lab testing we have encountered the following when blocking inbound NTLM on a remote host:

1. RDP'ing to the remote host with inbound NTLM blocked via cross-forest generated a CredSSP error message.
2. Setting Encryption Oracle Remediation to either Mitigated or Vulnerable as a workaround did not work.
3. Turning off NLA on the remote host as a workaround will allow cross-forest RDP
4. I have tried applying "Allow delegating fresh credentials" via policy on the remote host but it is still getting the CredSSP error
5. I have also tried setting the policy on the remote host to use SSL for "Require use of specific security layer for remote (RDP) connections", and I still got the same CredSSP error.
6. What did work is if I try to RDP from the same forest to the remote host, it will allow the connection and I can confirm it is using Kerberos for RDP instead of NTLM.
7. Another observation is once the same forest RDP worked on the remote host, cross-forest RDP connection on the remote host with the blocked inbound NTLM will now work.

Has anyone encountered something similar like this before? If so, has anyone found a solution for cross-forest RDP to work on a remote host with blocked inbound NTLM without the need to pre-auth on the remote host in the same forest?

Answer 1

The Encryption Oracle Remediation error is a red herring because it uses the same error code as the NTLM is not available error. Unless you haven't patched in 3 years it'll likely never be the Encryption Oracle Remediation issue. It's really just that it tried to fallback to NTLM and policy said no.

In all likelihood the issue is that the client can't find or communicate with a domain controller to do NLA.

The client must find the user's domain first (domain A). From there it authenticates their password. It then asks to get a ticket to the machine. The machine isn't in the user's domain so it creates a referral ticket to where it thinks the machine is (domain B).

The referral is handed back to the client and the client tries to find a DC to where the referral is supposed to go (domain B). The client sends the referral to domain B and asks for a ticket to the machine. The domain controller either finds the machine and issues a ticket for it, or says it doesn't know and offers a referral to another domain (domain C) and you try again, or it just fails saying no machine can be found.

All of this occurs from the client's perspective, not the target machine's perspective. This happens before the client even pings the target machine (ish). This is why disabling NLA appears to resolve the issue.

So there are a handful of reasons why this happens:

1. You used an IP address -- this is a straight-to-NTLM scenario. Kerberos doens't do IP addresses by default. You can turn it on, but it won't scale.
2. Client can't communicate with a DC in user's domain (domain A). Networking issue, client needs line of sight to domain controller, plus DNS.
3. Client can't communicate a with DC in the target machine's domain (domain B). Still a networking issue, client needs line of sight to domain controller, plus DNS.
4. You're not providing a proper fully qualified name and the user's DC can't figure out what forest it should refer to. You can enable Forest Search Order and it'll maybe help, or you can type in the fully qualified machine name.

This isn't an exhaustive list but these are the most common causes.

References:

https://syfuhs.net/windows-and-domain-trusts

https://syfuhs.net/how-authentication-works-when-you-use-remote-desktop

Answer 2

I also had a similar issue when using the DOMAIN\username login ; using the UPN ([email protected]) worked for me. My understanding is using the UPN allows the client to know the DNS domain name, which then allows it to discover the DC of the remote domain through DNS resolution.

NB : my setup was from a workgroup server so not exactly the same as yours; YMMV.