Disable NTLM but keep NLA Enabled (Cross-Domain RDP)

Question

Hi,

Are Microsoft under the impression that RDP (cross-domain) should still work after NTLM is disabled but with NLA still enabled?

Disabling NTLM in relation to KB5005413

Disabling NTLM breaks cross-domain RDP, unless NLA is disabled. We'd rather not disable NLA!

I’ve scoured many forums, articles, blogs, etc

Some say that having NTLM disabled but with NLA enabled is not currently possible.

Some say that it can be done, but the authentication is done with a server-side SSL/TLS certificate and the encryption is done over TLS 1.0 (seems to be the most recent TLS protocol in the RDP security group policy). Sadly, setting all this up, with NLA still enabled, doesn’t even show the certificate warning dialog that one sees when connecting to a host for the first time.

This works within the domain, but not outside it.

Basically, we always see this CredSSP error when NTLM is disabled and NLA is enabled and going cross-domain, no matter which encryption method is utilised:

Also tried with IP-only – same result. But of course, we don’t want to use the IP as the cert validation would fail anyway.

An authentication error has occurred. The function requested is not supported. This could be due to a CredSSP encryption oracle remediation.  

I can see on both the client and server side that the RDP connection succeeds to a certain point.

RDPClient_SSL: An error was encountered when transitioning from TsSslStateHandshakeInProgress to TsSslStateDisconnecting in response to TsSslEventHandshakeContinueFailed (error code 0x80004005).  

Searching for this error doesn’t really point me to any rabbit holes.

Both client and server are up to date regarding Windows Updates.

The client definitely does trust the server’s certificate chain, but I guess this is moot until we’re past the CredSSP error anyway.

Using the newer UWP remote desktop client app gives the same result.

According to this Reddit thread here, not only is SSL/TLS with NTLM disabled and NLA enabled possible, but also Kerberos via cross-domain is possible, but I can’t see how. (Not sure how one can provide more detail in the credential when literally providing the domain.local\username or username@keyman .local in the username field!)

Some GPO's that are currently set on the test server I'm trying to RDP are below:

Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options\Network security: Restrict NTLM: Incoming NTLM traffic: Deny all accounts  

Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\Certificate Services Client - Auto-Enrollment Settings:      
 - Automatic certificate management: Enabled  
 - Option: Enroll new certificates, renew expired certificates, process pending certificate requests and remove revoked certificates: Enabled  
 - Option: Update and manage certificates that use certificate templates from Active Directory: Enabled  

Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Host\Security      
 - Require use of specific security layer for remote (RDP) connections: Enabled (SSL) <--- TLS 1.0  
 - Server authentication certificate template: Enabled (RDS)  

Using Wireshark, it was observed my RDP client was trying to negotiate with TLS1.2 - so far so good. However....

The GPO that determines the server to Require use of specific security layer for remote (RDP) connections is set to SSL which means “use TLS 1.0”:

I downgraded (to test of course) to TLS 1.0 hoping it would match what the RDP service would want, unfortunately the CredSSP result was the same as when it was using TLS1.2.

Do you know if I’ve missed anything (quite possible anything glaringly obvious too!)?

Thanks

Answer 1

Can the client connecting communicate with the relevant DC where teh RDP server verifies the logon?

I've been playing with this myself, and had no success connecting RDP from one domain computer (client) to a server in a subdomain, until I opened our firewall rules (clientPC -> siteDC any ports for test purposes). Then it connects as long as I use FQDN. I can see Kerberos traffic tcp/88 in my connections log.