If you are having trouble following, please see this post.

Likewise, I skip most of the introductory material in this post and jump straight to what is needed in order to understand the network traces.

See this post for more information about the processing done by each Kerberos actor.

I skip most of the details of what each actor is doing and instead focus on the messages exchanged by the protocol here.

See this for a detailed description of Windows user login. Here we are only interested in the pure-Kerberos details. Some of it involves proprietary details beyond the scope of the Kerberos 5 protocol that we do not care about in this post. There is a lot going on with Kerberos in a Windows Domains.AssumptionsĪs always, we’ll start with a bunch of assumptions to make sure we are in the same chapter (mostly given up trying to be on the same page). The traces were captured on the Windows Domain Controller that handled the Kerberos requests. In this post, we will be using Wireshark v2.6.0. Of course, many of the other identity protocols are built on top of HTTP(S) and tools like Chrome Developer Tools or similar can be used in the browser. This makes it easier to capture network traces (with Wireshark or similar tools) of Kerberos than some of the other identity protocols. Luckily, the Kerberos protocol is mostly unencrypted (except for the tickets, authenticators, and some other sensative details) that rely upon message and field level encryption.

If you are new to the Kerberos protocol, a good starting place would be my Kerberos and Windows Security: Kerberos v5 Protocol post. This post will help solidify our understanding of the Kerberos v5 protocol with a real world example.

It describes the Kerberos network traffic captured during the sign on of a domain user to a domain-joined Windows Server 2016 instance. This blog post is the next in my Kerberos and Windows Security series.

Wireshark search for string