Authentication
3 October 2020

Who let the dog(s) out?

By admin@labtinker.net

Kerberos is a venerable and widely used authentication mechanism developed by MIT that underpins Active Directory. A lot of people have posted detailed explanations on how it works like this one:

https://www.tarlogic.com/en/blog/how-kerberos-works/

But the labtinker philosophy is to lift this off the page and into a lab so let’s set the stage. There are three actors treading the LAN today:

Figure 1: The lab

WIN10 is the client, a Windows 10 machine that will browse to our webserver.

WIN15 is a Windows 2012 server running the website ‘web.labtinker.net’.

WIN12 is another Windows 2012 server, the domain  PDC, DNS server and most importantly for this exercise the  KDC – Key Distribution Centre.

The KDC will distribute two types of Kerberos tickets: a ticket granting ticket which is like a passport verifying your identity and a service ticket which is like a visa for specific Kerberos-aware services.

The three hosts are all joined to the domain ‘labtinker.net’. When the client browses to web.labtinker.net the website has been configured to demand authentication credentials. The client’s browser has also been configured to provide these automatically after it has got them from the KDC. We’ll worry about how this has been achieved in a later post.

A useful windows command is ‘klist’ which shows you if you have any Kerberos tickets and also what they’re for. So after logging in with our domain user, Bob, we see Bob has the following tickets:

Figure 2: Bob’s tickets.

The top ticket is the ticket granting ticket (TGT) and the other, a service ticket is for LDAP. We’ve got these by dint of logging into an Active Directory domain. So let’s browse to our default website running the IIS splash page.

Figure 3: Bob browses to the website.

And now klist shows us an extra ticket.

Figure 3: Ticket to the website.

How did this appear? Taking excerpts from a Wirehshark trace I was running on the client machine…

The website challenges for authentication by sending a http code 401

Figure 4: Who goes there?

Now, I’m going to borrow an extract from the website referenced above which shows the Kerberos messages

Figure 5: Kerberos messages courtesy of tarlogic.com

And after the client went to the website it exchanged these messages with the KDC to get the necessary tickets:

Figure 5: Getting the tickets from the KDC

The TGS-REP was apparently malformed because ‘length of contained item exceeds length of containing item’ possibly something to do with this which shows a length longer than the tcp segment itself..

Figure 6: 1469 does not go into 1460

We got our tickets anyway and presented the service ticket to the website in this packet:

Figure 7: Packet with ticket

This packet contains…

Figure 8: Here’s my ticket

…which the website was happy with.

In my next post I’ll show how I set this lab was set up. Kerberos can be a bit fiddly to get working but is rock-steady thereafter.