Kerberos auth from non-domain joined machines using custom UPN suffix

St0rmi

3/8/24, 12:54 PM

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. [email protected]), 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. [email protected]), 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?

387

1 + 5

windows

active-directory

ldap

kerberos

user1686

3/8/24, 1:22 PM

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?)

St0rmi

3/9/24, 7:56 AM

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\[email protected] This is, of course, not great either, but at least Kerberos works that way.

user1686

3/9/24, 8:53 AM

Does `[email protected]` (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.)

St0rmi

3/10/24, 2:57 PM

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.

user1686

3/10/24, 3:54 PM

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?

Score:0

Server

Greg Askew

3/8/24, 6:31 PM

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 ([email protected] vs [email protected] 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.

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Kerberos auth from non-domain joined machines using custom UPN suffix

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.