Monthly Archives: January 2014

Wireshark Skills Series 7 of 7

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.

Leave a comment

Posted by on January 21, 2014 in Network Admin



Wireshark Skills Series 6 of 7

I’ve yet to hop into Wireshark with a database connection problem and figured it out because of the network capture. It is not the first place I stop. It has never come to that, I’ve never needed to go that deep. I have always used the other, more topical tools to diagnose a connection problem.

I have had an occasion where I wanted to go deeper. I wanted to find out for sure if the login information in a SQL connection was encrypted if you didn’t specifically setup TLS. The answer was it depends.. on the client. Most all implementations are encrypted. I happened to come across an old implementation that was not. It was a good answer to find out for sure and going deep with a network trace was the only way.

Today I set out to look at some packet captures of MSSQL connections and see if anything interesting showed itself. Turns out I found something very interesting. Have you ever connected to an instance of SQL server with SSMS and had it take for ever to load the list of folders? Lets take a look at a normal start to a SQL connection. I filtered out the IP and default SQL port.


This all happens in short order. In about 3 milliseconds, the client and server have completed their TCP handshake and negotiated on the TDS protocol in order to send the secured SQL username and login.

Now we have the jankity trace. The connection I attempted directly after installing SQL was much slower.


And no wonder it was slower. Look at all those re-transmissions. If an ACK is not received by the client affirming the packet was received and undamaged, the client will send the packet again.

In this particular case, I was reminded that the default amount of memory for a Hyper-V VM is 512MB. This was not quite enough to run through an install and have all the things open that I did. I shut the VM down added some RAM and my connections were running much more smoothly after that.

Leave a comment

Posted by on January 5, 2014 in Network Admin


Tags: ,