Setup
We have:
- a machine running Samba 4 on Debian Buster as AD DC.
- another Debian Buster machine running Samba 4 as file server, joined to the domain with
net joinand using winbind for authentication (let's call this FILE). - a third Debian Buster machine running Samba 4 just to test things, likewise joined to the domain (let's call this TEST).
- a fourth Debian Buster machine not running Samba and not joined with
net join, but there is a corresponding machine account with a random password, from which a couple of keytab files have been exported (let's call this PROD). This one has PostgreSQL configured for GSSAPI authentication. - A couple of Windows 10 Pro machines joined to the domain.
- A bunch of Windows 10 Home laptops. On the one I'm testing with, I have a local account with the same username and password as my domain account.
- Linux clients.
Let's say the primary domain is example.net (this is an internal domain only). The kerberos realm is SAMBA.EXAMPLE.NET and the old-style Windows domain is EXAMPLE.
The example.net zone resides on a DNS server because I don't want to manage all DNS data through Samba. It delegates samba.example.net to the DC. There's a _kerberos.example.net TXT record that contains "SAMBA.EXAMPLE.NET".
All Debian servers have GSSAPI authentication enabled in sshd_config.
What works
Logged on to a domain account on the Windows 10 Pro machines, browsing Samba shares, connecting with PuTTY to all Debian servers, and connecting to PostgreSQL on PROD (both with psql and PgAdmin4) works like a charm without having to enter the password again, as expected.
Likewise, it's possible from my Linux client to get tickets for all services involved and connect without entering a password.
What doesn't work
On my Windows Home laptop, browsing \TEST and \DC I have to enter my password, but that is at least successful.
GSSAPI authentication against TEST and PROD doesn't work.
What nevertheless works
You might say that it's no surprise that SSO from Windows 10 Home (or even Windows 10 Pro, if the machine isn't joined to the domain) doesn't work. The surprise, then, is that it does work with FILE (both browsing shares and connecting with PuTTY)!
Further investigation
I can run klist get host/file and klist get host/file.example.net and get tickets, but when I run klist get host/test I get error 0x56 (Kerberos preauthentication failed), and when I run klist get host/prod I get 0x520; Windows just complains that it has no credentials and doesn't even try to contact the DC.
At one point it seemed that the difference between the last two outcomes was whether an A record existed in the samba.example.net zone, but after deleting both records and rebooting the Windows 10 Home computer, the difference perists. It doesn't even seem like any DNS queries are being made (I've flushed the cache repeatedly, but perhaps there's a separate cache in the Workstation service or LSA?)
Actually, it seems that I managed to get \TEST working by adding the missing IPv6 rDNS record. However, connecting to the shares on \DC (netlogon and sysvol) involves a long delay during which Windows tries to resolve _ldap._tcp.dc._msdcs.dc in all domains in the search list, but that might be due to the DC being special, and then having to enter the password (Windows is obviously falling back to a different authentication mechanism), and klist get host/dc results in error 0x520, despite all the DNS records being in place.
I also modified the IPv6 PTR record for PROD to point at prod.example.net (it was pointing at the public domain name), but that didn't help. Also, the DNS server is joined to the AD domain and has DNS records set up correctly, but klist get results in error 0x520 for it too, as well as both Windows 10 Pro machines. I should mention that PROD resides on a different LAN; I was wondering if it might be possible that Windows Home only wants to recognize computers it's seen over NetBIOS and/or with shares, but surely that can't be the case in this day and age?
I've tried enabling Kerberos logging (https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging) but I'm not seeing anything in the Event Log.
Question
Why does Windows 10 Home sometimes use existing credentials to retrieve a Kerberos ticket and sometimes flatly refuse?
klistis for, and I traced the traffic with Wireshark. However, Windows will of course fall back to NTLM when you try to browse a share and Kerberos doesn't work, as I mentioned.