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:

srv-host records for dnsmasq

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:

Ksetup


With the mapuser command, the principal "abob@LAN" maps to the Windows local user "abob".

References:

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" ...
runas works

After first login, there are no tickets in klist:

empty 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:

Putty Kerberos configuration
Putty logging in with Kerberos authentication

SMB (fileshare) client

Even samba works:

SMB client using Kerberos

For how to configure samba with Kerberos and without AD, see:

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:

smbclient list shares with Kerberos

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:

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)

Other references:
https://medium.com/@robert.broeckelmann/kerberos-wireshark-captures-a-windows-login-example-151fabf3375a
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/kerberos-protocol-registry-kdc-configuration-keys