Note: The article here requires features that don’t appear to come with the Home edition of Windows 10, such as the Group Policy Editor.  These steps may well work on previous versions of Windows, but I haven’t tried it out on them.  This article assumes you’re familiar with setting up and administrating an MIT Kerberos KDC and password server.

Most people who have ever dealt with Windows domains will know that the Active Directory system uses Kerberos as its authentication mechanism, but did you know it was possible to configure a standalone Windows 10 to log on to an MIT Kerberos server running on (e.g.) Linux?

Although I knew of the ksetup.exe program that used to come with the Windows Resource Kit and latterly with Windows itself, I had never figured out how to use it.  However, whilst Googling for ksetup, I came across a few blog postings which showed me how to get this working.

In the following examples, I am going to be using a DNS domain name of example.com and a Kerberos realm name of EXAMPLE.COM (as is the convention, that you use capital letters).

There are a number of commands you need.  You need to run these as administrator.

ksetup /setrealm EXAMPLE.COM – sets the default Kerberos realm to EXAMPLE.COM

ksetup /addkdc EXAMPLE.COM kdc.example.com – sets the name of the Kerberos KDC server.  If you miss out the name of the server, it will try to find it using the special Kerberos SRV DNS records.  You can use this more than once to add multiple servers if you have them.
ksetup /addkpasswd EXAMPLE.COM kpasswd.example.com – sets the name of the Kerberos password server, which may or may not be the same machine as the KDC.

ksetup /setcomputerpassword <password> – this sets the password for the ‘machine account’ (in reality it’s (a) host/* principal(s) on the server).  The password you set here you will need to keep for later as you will need to set the same password on the host principals.  Make it secure!

ksetup /mapuser * * – this configures a 1:1 mapping of Kerberos user names to local accounts, so if you log in as jsmith@EXAMPLE.COM this would correspond to a local account of jsmith.  If you don’t want a 1:1 mapping, you can map specific principals (the first parameter) to specific user accounts (the second parameter) instead.

There are other options (do ksetup /? to list them all) but these are the base ones you’ll need.  Some of these require a reboot to make them take effect.

Once you have configured the Windows side of things, you’ll need to use kadmin on the MIT Kerberos server to create a couple of host principals per machine.  I found that you have to create one host principal for the FQDN of the machine, and another with just the host name, so in the example above you’d need to create

host/mywindowsbox.example.com@EXAMPLE.COM
host/mywindowsbox@EXAMPLE.COM

Both of these host principals must have the password set to the password you set in the ksetup /setcomputerpassword command, otherwise Windows will give you an error along the lines of there not being a computer account when you try to log on.

There are a few extra things you can do with the Group Policy Editor to make things a little easier here.  First of all, you can set the default logon domain name.  By default Windows appears to get this one wrong (for some reason it sets it to everything to the left of the first dot as far as I can tell, so you’d get EXAMPLE and not EXAMPLE.COM). Setting it directly in the Group Policy Editor fixes this problem.  The setting is at Local Computer Policy -> Administrative Templates -> System -> Logon -> Assign a default domain for logon.  Set this to Enabled and supply the name of your Kerberos realm (case-sensitive, so if your realm name is in capitals, so should this parameter)

One more thing that I set were the Do Not Display Last User Name setting to enabled, so that it always asks for a username at the logon box, otherwise it may auto-select the non-Kerberos account.

Once this is done, it’s still possible to log into your local account directly by prefixing your user name with the name of your machine, e.g. MYWINDOWSBOX\jsmith just as you would if you want to log into a local account whilst joined to a domain.

Once you’re logged in using your Kerberos credentials, you can use the klist utility at the command line to check you’ve been issued a ticket.  You can then use any applications supporting SSPI (e.g. Firefox, Thunderbird, PuTTY, etc.)  to use that ticket to log on to other services, just like you would in a normal AD domain.  In theory, it should be possible to use a cifs/ ticket to connect to Samba, but I haven’t made this work yet.

Should you wish to undo all this and return to normal, you can use the ksetup /removerealm EXAMPLE.COM command to remove the settings from the registry and go back to user accounts.

Update: If you want delegation to work (say, for example, if you want an automatically-issued ticket to appear in an SSH session you logged into via Kerberos), you also need to set the Delegate flag using the ksetup utility.  Just run something along the lines of ksetup /addrealmflags EXAMPLE.COM Delegate to enable this feature if you need it.