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
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".
- Ignore the RC4 restrictions on those pages, Windows 10 supports Kerberos AES
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 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
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:
- "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.
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
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 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
Example cross-realm ticket granting ticket:
- 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
Windows 10 clients currently support the following Kerberos crypto: