Kerberos on non-domain Windows clients §
Apparently, non-domain Windows systems can use Kerberos authentication when connecting to Active Directory domain services, i.e. local accounts aren't limited to just NTLM. This works without any login screen nor
runas trickery (and somewhat explains the confusion I had in my earlier post back in 2011).
When prompted for credentials, it is necessary to enter a Kerberos principal name as the username, e.g. fred@AD.EXAMPLE.COM would cause it to acquire Kerberos tickets using the specified password (whereas EXAMPLE\fred results in NTLM).
It's important that the username needs to be the raw Kerberos principal name (with uppercase realm), not the UPN that's customary in AD, as the latter don't have any relationship to DNS and are impossible to resolve without already being in contact with the DC.
This works with software which explicitly prompts for credentials does the necessary calls to acquire tickets with a password – this includes the RDP remote desktop client and SMB file shares, and it seems that Google Chrome & Edge (but not Firefox) support the same for HTTP Negotiate. (Fortunately, RDP and SMB is exactly where Kerberos is most useful in my case.)
"Pure" Kerberos clients do also work, as long as the credentials for that specific host have already been stored in the Credential Manager (and SSPI doesn't seem to care about having a TGT already cached or not). If the host doesn't run SMB, then cmdkey can be used to manually store the credentials:
cmdkey /add:ember /user:grawity@NULLROUTE.EU.ORG /pass
(The target may be a FQDN, but then it only works with FQDNs everywhere. For SPNEGO clients – SMB and RDP – the target should be a short name, that way it'll work with both
(In other words, the reason I was able to SSH to 2 of my servers was only because I'd stored the Kerberos password for them for SMB earlier.)
Making this work with non-AD realms
By default Windows expects the realm to run Active Directory specific services, so it'll use the
dc._msdcs subdomain for SRV lookups and will issue CLDAP "DC pings" to each discovered KDC (and will assume the domain is unreachable if the CLDAP pings are unreplied).
However, it won't do this for explicitly configured realms, so it is also possible to use Kerberos authentication against services running plain MIT/Heimdal (such as my Samba fileserver with
kerberos method = dedicated keytab). The usual tool for adding custom realm configurations is
ksetup, and a MIT realm can be declared using:
ksetup /AddKdc NULLROUTE.EU.ORG
It isn't necessary to actually specify any KDC names or other configuration; the mere presence of a realm subkey in the Registry will cause Windows to treat this as a non-AD realm and it'll look up standard
_kerberos._udp SRV records. It might be desirable to enable TCP for the Kerberos requests though:
ksetup /AddRealmFlags NULLROUTE.EU.ORG TcpSupported
(There's no need to use
/AddKdc before setting the flags – all it does is create an empty Registry key, which
/AddRealmFlags can do on its own. The actual configuration is stored under
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos in the Registry, and as long as there's a realm subkey underneath the
Domains key, whether empty or not, it will be treated as a non-AD realm.)
Making this work automatically
One problem is that credentials need to be entered and saved for each service separately – it doesn't result in real Kerberos-style "single sign-on". As there is no standalone
kinit in Windows, you can't just acquire a TGT and be done with it.
Well, there sort of is a "kinit"; specifying a Kerberos principal actually works with runas /netonly, although RunAs creates a whole separate LSA session instead of putting the tickets in the main session (it's a bit like
setpag in Linux terms.) Regardless, it does make Kerberos work in all other apps (PuTTY, curl, Firefox) started via RunAs, with SSPI being able to acquire credentials without prompting.
(Yet, storing new TGTs in the existing session is something that MSTSC and Explorer are clearly capable of doing, so I hope to one day figure out the necessary SSPI magick to do the same.)