If you are logging into a Windows instance (server or workstation, hardware or virtual machine) that is not connected to a domain, then you are performing a local logon (using NTLM and authenticating against a local user database). Before we dive too deep into this, it’s important to remember that Windows Kerberos is Kerberos at the end of the day (with a couple of MS-specific pieces). When I was first researching this series and asked a peer of mine in Microsoft Consulting about it, he pointed me towards that article. The quintessential writeup on Kerberos on Windows is available here. This makes it easy to spin up Windows Domains, but can become a nightmare for the Windows Server administrator when things are not working - that job title doesn’t usually involve being an identity expert. Kerberos basics are covered in that post and won’t be revisited here. The following diagram provides a high-level summary of the messages exchanged between actors during the Kerberos message exchanges.įor more information, see here. Regardless, of where you start, this particular post is about the use of Kerberos with Microsoft Windows. Or, you could start at the beginning and read through the whole series. If you want to dive right into some examples with network traces, check out my posts on Windows Logins and SPNEGO. If you’re coming to this article directly from a search engine, then it may be helpful to look at my post on the generic Kerberos v5 Authentication Protocol first. I suppose I would as well if I were them, but what I’m describing below (including the Microsoft’s pieces) is very common.

To some extent, the ubiquitous nature of Windows deployments makes its implementation of Kerberos (plus extensions) a standard in its own right - the good people in the Kerberos (now Kitten) Working Group at the IETF would likely disagree with that assertion.

In general, I’m not much of a fan of proprietary protocols, especially for security some solace can be taken in Microsoft’s Open Specification Promise. Those proprietary extensions are limited to fields that the Kerberos spec set aside for such extensions so, this doesn’t necessarily break interoperability. At the end of the day, Kerberos with Windows is more-or-less the same as Kerberos anywhere else though, there are several proprietary extensions that Microsoft has implemented.

In this next post in my Kerberos and Windows Security Series, we are going to look at the use of Kerberos in Microsoft Windows ( Microsoft Kerberos). Ashley Van Haeften / Hercules and Cerberus LACMA 65.37.151

Kerberos windows