Every time I talk to someone about Kerberos I need to take a few minutes to go through the concepts. This post is intended to just write down what I usually say and draw with a white board.
If you want to know more about Kerberos there's a metric ton of info out there on the internet. I'll leave it to you to go read up. For those of you that are experts on Kerberos please note that I'm going to simplify some stuff and gloss over a few important things; don't judge me for that - I'm just trying to make this all easy to understand!
A
Kerberos Domain can be thought of as an island of single sign-on. Anything in the domain can authenticate securely to anything else in the domain without ever transmitting a clear text password over the network.
Everything in Kerberos is a
Principal - machines, services and even users. A Principal is identified by a simple string called a
Service Principal Name or
SPN in one of two forms - either PROTOCOL/hostname for services (e.g. HTTP/www.mydomain.com for a web server) or username@DOMAIN for users (e.g. cjohnson@ATEAMDEMO.COM). The case of the string is important; the Protocol and domain name are always in
CAPITAL LETTERS and the hostname and username are always in
lower case.
There's a service on the network called a
Key Distribution Center, abbreviated to
KDC. The KDC has a list of every user and every service on the network and has a secret keys for each and every one of those Principals.
When a
Service enrolls with the KDS the KDC generates a secret key for the service. That secret key is stored in two places - on the KDC and by the service (usually in a file).
When a user first logs in they use their password to the KDC prove their identity and get something called a
Ticket Granting Ticket, abbreviated to
TGT. Note that the password is
never actually sent over the wire.
When a user wants to authenticate to a Service they go to the KDC and use their TGT to ask for a
Service Ticket (ST) to talk to that service. The user asks for a ST for a particular service identified by the service's Service Principal Name (PROTOCOL/hostname). Note that, as usual, the user doesn't actually send the TGT to the KDC. Instead the client uses the TGT to prove its identity to the KDC, just as it did with the password.
In order to construct a
Service Ticket the KDC takes the username, the service's SPN, a timestamp and a couple of other bits of information, puts them all together in a particular way and then encrypts that data with the Service's secret key and adds on some unencrypted data describing the ticket. Remember that only two things know that secret key - the KDC and the Service itself.
The KDC then securely returns the ST to the user.
Finally, the user sends their service ticket to the
Service. To verify the Service Ticket the Service takes the encrypted ticket and tries to decrypt it using the secret key it got when it enrolled with the KDC. If the the ST decrypts correctly with that key then the service knows that the user was authenticated by the KDC; all the that remains is to check the timestamp and other information to make sure that the ticket isn't expired. If all of that checks out then the user is considered authenticated.
You'll note that the Service does not need to go to the KDC to verify the Service Ticket - all it needs is its Secret Key which it already has.
Here's a sequence diagram for you.
Remember when I said I was glossing over or simplifying a few things?
One of those things is how the Service gets its secret key. In my text above I said it gets that key when it "enrolls", but in the diagram I used the word "start" instead. That's one of those hand wavey places.
Another one is the TGT. A TGT is just a ST for the KDC itself. So if you look at a TGT you'll see that it's a special Service Ticket for krbtgt/DOMAIN.COM@DOMAIN.COM. For example here's mine:
Ticket cache: FILE:cjohnson.cache
Default principal: cjohnson@ATEAMDEMO.COM
Valid starting Expires Service principal
07/18/11 07:51:14 07/18/11 17:51:19 krbtgt/ATEAMDEMO.COM@ATEAMDEMO.COM
renew until 07/19/11 07:51:14, Flags: RIA
Most of our posts here are pretty long and can take a while to digest. This one is intended to be read in 5 minutes or less. If you'd like to see more "5 minutes or less" posts please let us know in the comments below. If you DON'T want to see more of them please let us know that too.
Note: we may not publish the comments, but we promise to read them all.
Posts
