I had no idea what protocols I was going to cover when I picked the number of posts in this series. I’m glad I picked 7 or I would be at this for months. I find that when I look at captures I can turn vague concepts of how stuff works into a more thorough understanding of how stuff works.
As a speaker it can be a very awkward feeling walking off a cliff. The cliff is starting to explain something, and then not being able to finish the thought because you don’t actually know how it works. Now with wireshark skills, I can dive deep on purpose and avoid falling.
Kerberos is a good capture to wrap up this series. Kerberos is an authentication protocol. It is a complex protocol but I have found a great pdf that simplifies it… but not too much.
With all of those dotted lines we should be able to find something of interest in wireshark. I have a domain controller and another server setup that we’ll call a client. After setting up the domain, joining the client and creating a couple users, lots of kerberos is already happening but we are going to try to focus on those first few steps in the PDF.
The domain controller handles both the authentication service and ticket granting service. If we start a trace and add the filter “kerberos” we will get to see some traffic eventually.
First, to make it a clean run, at a command prompt type “klist”. This shows you the current tickets you have. Then type “klist purge” which will get rid of those tickets. If we have that capture started and lock our session (ctrl+alt+del lock) and re-login we will capture the first step AS-REQ. The second packet is selected in this screenshot and shows the details of the AS-REP. The “Client Name” and “Clients Realm” are self explanatory but the server name of KRBTGT may be a little misleading. There isn’t actually a server named that but it represents the place the client goes for the Ticket Granting Ticket.
Step 1 in the PDF is completed when we log in.
The next Kerberos action I see is a TGS-REQ and TGS-REP. After authentication we log onto the host(a.k.a. client) which gives us a host ticket.
This is all I will get unless I try to access network resources. Below I attempt to access a cifs share on my virtual host computer. Since it’s not joined to the same domain the authentication isn’t automatic. A popup window asks for credentials to connect to the computer “nujak” and I type in some junk. The domain controller correctly responds with “KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN”.
In these next packets I attempt to access a share on the domain contorller. Since I do have access to this share we get a successful SMB2 session start. If you dig into the security blob in the packet you can see the basic kerberos information.
The distributed platform forces computers to work together. If you want to have a deep understanding of why they do or don’t work together, Wireshark is the tool for the job.