Kerberos for Windows, without AD
Continuing from the previous post, let's see what Windows can do with a MIT Kerberos based realm.
Windows normally uses Kerberos as part of Active Directory, but it does have some basic support for a non-AD version of Kerberos. I'll explore what works and how to configure things.
Kerberos Server Setup
You'll need to make sure that your Kerberos setup:
- supports AES-256-CTS-HMAC-SHA1-96/AES-128-CTS-HMAC-SHA1-96
- does not require preauth
- a host principal for the Windows client
- SRV records for
_kerberos._udp.[REALM]
For the SRV records, I'm using dnsmasq, so I set the srv records in /etc/dnsmasq.conf:
For the windows client, I used kadmin to create a principal for my windows client. I chose a random password so I could give the credential to Windows. I don't think I actually need this for how I'm using Kerberos.
Windows Client Setup
In an admin powershell session, I ran:
ksetup /setrealm LAN
ksetup /MapUser * *
ksetup /addkpasswd LAN sandfish.lan
ksetup /SetComputerPassword [pw used in kadmin above]
ksetup /setdomain LAN
ksetup /AddKdc LAN
ksetup /AddKdc DROWN.ORG
ksetup /addhosttorealmmap .drown.org DROWN.ORG
This ended up looking like:
With the mapuser command, the principal "abob@LAN" maps to the Windows local user "abob".
References:
- http://sc-ap.sourceforge.net/
- https://www.freeipa.org/page/Windows_authentication_against_FreeIPA
- Ignore the RC4 restrictions on those pages, Windows 10 supports Kerberos AES
First tests
In a command shell, using runas to start another command shell as the Kerberos user:
runas /USER:abob@LAN cmd
Enter the password for abob@LAN:
Attempting to start cmd as user "abob@LAN" ...
After first login, there are no tickets in klist:
Logging in
Logging out and then choosing "Other user" on the login screen brings up the option to login to the Kerberos realm. Giving the username without the realm fails, but user@realm (ex: abob@LAN) works.
Windows openssh client
Windows's OpenSSH client supports Kerberos authentication, you just have to enable it in %USERPROFILE%\.ssh\config
Putty
Putty also supports windows Kerberos ("Microsoft SSPI SECUR32.DLL") and has it enabled by default:
SMB (fileshare) client
Even samba works:
For how to configure samba with Kerberos and without AD, see:
- https://help.ubuntu.com/community/Samba/Kerberos
- https://serverfault.com/questions/659017/possible-to-authenticate-samba-via-kerberos-but-without-domain-join
- "net -s /dev/null groupmap add sid=S-1-5-32-546 unixgroup=nobody type=builtin" https://bugzilla.redhat.com/show_bug.cgi?id=1740986
Samba with Kerberos and without AD is an unsupported way of configuring it, and it complains about winbindd not running. I'm not using dynamic users, so it can complain all it likes.
smbclient
This isn't a Windows client, but I figured I should mention that Samba when built with Heimdal instead of MIT Kerberos currently only supports the AES+SHA1 crypto algorithms.
If your session token is using AES+SHA2, you'll get a cryptic error message that includes "encryption type 20 not supported"
$ smbclient -k -L sandfish.lan
Unable to initialize messaging context
gse_get_client_auth_token: gss_init_sec_context failed with [ Miscellaneous failure (see text): encryption type 20 not supported](2529639062)
gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for cifs/sandfish.lan failed (next[(null)]): NT_STATUS_LOGON_FAILURE
session setup failed: NT_STATUS_LOGON_FAILURE
"encryption type 20" is aes256-cts-hmac-sha384-192
Downgrading /etc/krb5.conf fixes that problem and brings up the next one.
$ grep enctype /etc/krb5.conf | cat
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
$ smbclient -k -L sandfish.lan
gensec_spnego_client_negTokenInit_step: gse_krb5: creating NEG_TOKEN_INIT for cifs/sandfish.lan failed (next[(null)]): NT_STATUS_NO_LOGON_SERVERS
session setup failed: NT_STATUS_NO_LOGON_SERVERS
Heimdal must not be using SRV record lookups to find the KDCs, so putting them back in krb5.conf finally makes smbclient happy:
Cross-realm
Cross realm authentication works as long as you give ksetup "/addhosttorealmmap". I don't see a way to get the host+realm map out of ksetup, but it's in the registry at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm\[realm]\SpnMappings
Example cross-realm ticket granting ticket:
Logging in while on the road
I don't have my KDCs exposed to the internet, so I needed a way to login. I have a local user that I can use to start a wireguard VPN. Then when I switch users, the wireguard connection stays up and my laptop can reach my KDCs over the VPN.
Limitations
- Windows version of openssh server doesn't support krb5 auth https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_server_configuration
- putty doesn't always work with cross-realm tickets - this might be the order of the Kerberos plugins?
- This is probably not very well tested (or supported) code on the Windows side
- You can't use a windows hello enabled user, it has to be a user without a link to a Microsoft account
Other info
Windows 10 clients currently support the following Kerberos crypto:
- aes256-cts-hmac-sha1-96(18)
- aes128-cts-hmac-sha1-96(17)
- DEPRECATED:arcfour-hmac(23)
- DEPRECATED:arcfour-hmac-exp(24)
- UNSUPPORTED:ms-rc4-hmac-old-exp(-135)
- UNSUPPORTED:des-cbc-md5(3)