I have a scenario where our laptops, which are connected to AzureAD, need to access some servers on an on-prem Active Directory that isn't synced or related to the Azure AD. This setup has been functioning well; however, I've been informed that we need to disable NTLM. Currently, RDP connections made via VPN from these laptops to some servers work using Kerberos, while others do not. When I enable the Group Policy to deny NTLM, I can connect to some servers, but with others, I get an error saying, 'The function requested is not supported ... This could be due to NTLM authentication being blocked.' I've checked that Kerberos works on the servers that allow connections and that there's no rogue Group Policy causing issues. Interestingly, RDP from a domain-joined server to those problematic servers works fine. I've compared the SPN records for both working and non-working servers, and except for the hostnames, the records are identical. DNS entries and port accessibility between devices seem fine as well. I'm looking for any insights or ideas on what might be causing this behavior.
1 Answer
It sounds like the SPN might be set correctly, but it's crucial to ensure that those SPNs are actually published in Active Directory. Try using the 'setspn' command to remove existing SPNs and re-add them, running it right on the problem server. Sometimes that can resolve weird authentication issues.
I thought if 'setspn -l' returns results from either the DC or affected host, the SPNs were published in AD. I've run 'setspn -D' to clear them and 'setspn -A' to re-add, yet no changes for NTLM despite it not trying Kerberos, so something client-side might still be limiting it.