Microsoftafter disabling NTLM, we now get a CredSSP error when trying to RDP from a non-domain-joined PC to a domain-joined VM that has Network Level Authentications (NLA) turned on. I don't see any Microsoft documentation about this error when NTLM is off and NLA is on. How can we still RDP in such a scenario?
I really recommend against disabling NLA. NLA is an important security feature to RDP which has a history of security problems. You really have 2 good options to keep using RDP in a secure manner:
Here's a blog about RDP post-NTLM. I recommend reading the rest of the blog series about NTLM. https://willssysadmintechblog.wordpress.com/2023/09/05/disabling-ntlm-authentication-guide-part-6-rdp/
crazyadm1n we get a CredSSP error even when we have line of sight to the Domain Controller - I have a VPN client connecting my non-domain joined machine to the network with the DC and when RDP'ing to the server VM that is domain-joined, we get a CredSSP error. Is that not supposed to happen?
A non domain-joined client doesn't know everything already that a domain joined client would know, like what domain to auth to and where the Kerberos servers (DCs) are. Here's some things to make sure are configured so your client knows where to go for authentication.
DNS name of RDP Target Server
Specify the AD domain-based FQDN of the RDP target server when connecting via RDP. For example, specify "hostname.domain.com", where "domain.com" is the FQDN of the AD domain.
Username
You must specify the FQDN of the AD domain when specifying your username. You can do that with either of these methods: "username<AT symbol>domain.com" or "domain.com\username".
Network Ports
Make sure your client can reach your DCs on port 88 for Kerberos authentication.
DNS Records
Once your client knows what domain to contact, which it learns through the username field, it will attempt a DNS lookup to find that domain's Kerberos servers. It may consult the following DNS records:
Those SRV DNS records should point to the DNS names of your DCs and port 88. Here's example output from nslookup:
PS> nslookup -type=SRV _kerberos._tcp.domain.com
Server: dns.domain.com
Address: 10.0.0.2
_kerberos._tcp.domain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = dc3.domain.com
_kerberos._tcp.domain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = dc4.domain.com
_kerberos._tcp.domain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = dc1.domain.com
_kerberos._tcp.domain.com SRV service location:
priority = 0
weight = 100
port = 88
svr hostname = dc2.domain.com
dc3.domain.com internet address = 10.0.0.4
dc4.domain.com internet address = 10.1.0.4
dc1.domain.com internet address = 10.2.0.4
dc2.domain.com internet address = 10.3.0.4https://willssysadmintechblog.wordpress.com/2023/08/29/disabling-ntlm-authentication-guide-part-3-migrating-to-kerberos/
Disable NLA then; there are outstanding accessibility bugs in require NLA anyway.
Microsoft recommends to turn on NLA. Is there a Microsoft KB that says that it's ok to turn off NLA if I turned off NTLM in my environment?
What are these other accessibility bugs?
I am one of the ones affected; I had to patch in an accessibility bug fix into a third party RDP client in order to use Windows at all. This results in NLA not working; as far as I can tell the Microsoft client is allowed to do something that third party clients can't.
https://github.com/joshudson/rdesktop/tree/surge
