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
  • 2
  • Is it a requirement to be able to use the alternative UPN suffix in this case, or would it be enough to just get Kerberos authentication working in general? (Does AD disallow the original UPN suffix from being used for accounts that have had it changed?) – user1686 Mar 08 '23 at 13:22
  • Using the default suffix for a user that is configured to use a custom one does not appear to work in my environment. Also, I would really like to be able to use the alternative UPN suffix as this is what people will actually be used to using everywhere. The best I've found so far is prefixing the UPN with the fully-qualified realm name, e.g. something like this: AD.EXAMPLE.COM\user@example.com This is, of course, not great either, but at least Kerberos works that way. – St0rmi Mar 09 '23 at 07:56
  • Does `user@AD.EXAMPLE.COM` (the actual Kerberos principal name format) work for such users? It is generally supposed to work regardless of UPN suffix. (I don't actually know how to make the UPN suffixes work.) – user1686 Mar 09 '23 at 08:53
  • I can only use the default AD.EXAMPLE.COM suffix if it is actually assigned to the user, which is not the case for most of the users. – St0rmi Mar 10 '23 at 14:57
  • Hmm, it should still work, because Windows also accepts the _Kerberos realm name_ that way, and the realm name always remains AD.EXAMPLE.COM regardless of the UPN suffix. (That is, after failing UPN lookup, the domain controller should normally fall back to samaccountname@realm lookup.) I guess this might fail to work if your UPN prefixes differ from the "legacy" account names? – user1686 Mar 10 '23 at 15:54

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
  • 35,880
  • 5
  • 54
  • 82