0

I am trying to access resources inside an Active Directory domain from a non-domain joined Windows 10 machine. The domain is ad.example.com, but there is also the alternative UPN suffix example.com.

When I access, for example, a file share using a user with the default UPN suffix (e.g. firstuser@ad.example.com), Kerberos authentication works, as it automatically guesses the correct realm (ad.example.com), does the DNS resolution to figure out the the DC, does the LDAP ping, and then gets first the TGT and then the TGS.

When I try the same thing with a user using the non-default UPN suffix (e.g. seconduser@example.com), it tries to guess the realm as example.com, which of course does not resolve in DNS. I fixed this by creating a DNAME record for _msdcs.example.com to _msdcs.ad.example.com and got the DNS part to work that way. The problem is that now the LDAP ping does still not work, as it, of course, queries for the Netlogon attribute of example.com (which gives zero results) instead of ad.example.com (which would give one result). This causes the authentication to fall back to NTLM, which I absolutely do not want, as I plan to disable NTLM entirely in the near future.

Is there any way to get Kerberos to work from non-domain joined machines when you are using non-default UPN suffixes?

St0rmi
  • 1
  • 3

1 Answers1

0

Is there any way to get Kerberos to work from non-domain joined machines when you are using non-default UPN suffixes?

Unfortunately no. While this is common in Linux implementations, the complexities of Windows directory architectures and add-on system integrated products usually prevent this from being practical. For more information, refer to this detailed post that describes the steps during the resolution and locator process.

https://serverfault.com/a/1025351/20701
Kerberos Authentication for workstations not on domain

Note that in large, complex directory topologies, the UPN is typically not the FQDN of the AD domain. This is to make logons friendlier and easier (jsmith@company.com vs jsmith@childomainname.company.com or CHILDDOMAINNAME\jsmith). This also makes it transparent to move principals between domains, so the logon username does not change.

However, the fallback to NTLM will work if the principal name and password is the same on AD as the client logon session.

Greg Askew
  • 39,132