An Introduction to Kerberos and Single Signon
Volume Number: 21 (2005)
Issue Number: 2
Column Tag: Programming
by John C. Welch
An Introduction to Kerberos and Single Signon
How to Get All Your Work Done With Only One Password
One of the single biggest problems that any sysadmin (or user for that matter) has is authentication
management. We have lists of passwords that get used for everything. The login password. The email password.
The file server password. The SSH password. Dealing with this is beyond painful, especially when you are
managing hundreds, or even thousands of machines. As a result, one of the holy grails of network systems
everywhere is the Single Signon, (SSO). SSO means you log into your Mac, and that's it. You're done with
passwords. You don't have to enter anything again, because the SSO mechanism handles your authentication for
One Login To Rule Them All
Fortunately, not only is there an outstanding SSO architecture out there, in the form of MIT's Kerberos,
(http://web.mit.edu/kerberos/www/) but that mechanism is integrated into two network architectures that Mac
users on a corporate LAN are going to use a lot: Apple's Open Directory and Microsoft's Active Directory. In
this article, we'll take a look at the basics of Kerberos, and how Apple uses it to make your networked life a
little simpler. Please note that while we'll talk about basic Kerberos principles, this isn't a detailed
analysis of Kerberos, so if you're looking for a howto on complex Kerberos implementations, this article isn't
it. Also note that we're using a very simple simulated Kerberos setup for clarity. They can be as complex as
you want them to be. Finally, since Apple bases its Kerberos implementation around Kerberos version 5, that's
what we're assuming you have. If you're using Kerberos version 4, some things are going to work differently.
Authentication, Not Authorization
Since Apple's SSO architecture is based around Kerberos, we need to be very clear on the one misconception
that will trip up sysadmins new to Kerberos more than anything: Kerberos is an authentication mechanism, not
an authorization mechanism. Kerberos' entire purpose is to provide a safe, secure, reasonably convenient way
to say that the person logging into the network is who they say they are. It authenticates users. Kerberos
does not say what you are allowed to use. That's authorization and while authorization mechanisms can use
Kerberos, the actual decision of what you can use once authorized is not a part of Kerberos. It can be hard to
wrap your head around this at first, since the two concepts go hand in hand, but the distinction is important.
One way to think of this is via the example of gaining access to a secure network room. There are two
parts, authentication and authorization. First, you have to establish your identity to the security system.
This is what things like biometrics, mag-stripe cards, prox cards, etc., are for. You use these to establish
your identity, or authenticate yourself. Once that's done, that authentication is used by the authorization
mechanism to see if you're allowed access. If you are, the door unlocks, and into the server room you go, aka:
1. "Let me in"
2. "Who are you"
3. "I'm Bob"
4. "Prove it"
5. "Here's my proof, now let me in"
6. "Hold on Bob, let me make sure you can go in."
7. "Okay, you're authorized to get into the server room, I'll unlock the door"
Step 5 is the authentication, step 7 is the authorization. If Bob wasn't allowed access to that room, then
step 7 would read as "Yep, you're Bob. But you can't get in, you aren't authorized, sorry about that."
Kerberos is the way that Apple has chosen for that all-important step 5. Now that we know what Kerberos,
(or "Kerb" for short) is used for, let's take a look at Kerberos as a thing.
Kerberos, Three Heads, No Waiting
Kerberos is, according to MIT:
"Kerberos is a network authentication protocol. It is designed to provide strong authentication for
client/server applications by using secret-key cryptography."
While that's a technically accurate description, it's not terribly helpful. A much more useful definition
comes from AFP548's (http://www.afp548.com/) series of articles on Kerberos :
"Kerberos does one thing, and only one thing. Lucky for us it happens to do it very well. Kerberos is a
method of authentication and only authentication. That means it only validates username password combos. After
that it's up to the service using the username and password to do the rest of the work. Kerberos doesn't not
authorize a valid user to use a service, and it doesn't provide any services itself. It only authenticates.
Alright, Kerberos authenticates, big deal. There are a lot of authentication methods out there. APOP,
Apple's SASL Password Server, PAM and a host of others all do this already. What Kerberos brings to the party
is that it allows the authentication of a user without ever having to have that user's password go across the
network. Every other popular service either just transmits the password to the server in plain text, or has a
convoluted method for encrypting the password and then sending it across the network."
That line about your password never going across the network is critical. It means there's no way for
anyone to sniff your password on the network, because it never goes on to the network. If it's not there, it's
rather hard to steal it. When I worked for MIT IS, they couldn't use firewalls, since so much of the computing
MIT does not only has to remain open, but is too experimental to work well with firewalls, so outside of a
very small number of sites, they don't use them. They use Kerberos, and it works very well. (It had better,
since if you kick a tree at MIT, twenty hackers fall out, and they're all good.)
This lack of a password means however, that Kerberos never works the way you think it does at first. The
way most non-Kerberized, (Note: when a service uses Kerberos for authentication, it's said to be "Kerberized".
After all, why have a cool technology if you can't create new words for it?) authentication schemes work is
something like this:
1. "I want to access <resource>"
2. "Who are you?"
4. "Prove it"
5. "Here's my <incrediblyconvolutedencrypted> password"
6. "Okay, you're Bob"
While this method works, if your password goes out over a network, especially the public Internet,
eventually, someone's going to grab it. Moore's law says it will eventually happen.
Kerberos does things differently, and as a result, your password never leaves your machine. So now, let's
follow our buddy Bob through a Kerberos login.
First, Bob sits down at his Mac running a current version of Panther, Mac OS X 10.3. (Yes, you can use
Kerberos with 10.2.x, but it's kludgy, so if you decide to use Kerb, upgrade to 10.3, you'll be much happier
in the long run.) He enters his userID ("admin", since that's what he is) and his password (doesn't matter).
Once this happens, Kerberos starts its authentication jive. First, Kerb takes that user id and matches it to
the Mac's Kerb realm. A realm, in Kerbspeak is analogous to a DNS domain, and in fact, looks like an all caps
version of a domain. So, if MacTech was using Kerb internally, their realm would probably look like:
MACTECH.COM. Realms are pretty simple, they're just the basic organizational unit for Kerberos, and are how
you keep track of what resources are part of what group. You can have multiple realms working together, either
cross-linked, in what's called a cross-realm trust, (i.e. MACTECH.COM and XPLAIN.COM agree to trust each other
to authenticate users on the other's realm) or hierarchally, (i.e. you have XPLAIN.COM, and MACTECH.XPLAIN.COM
as a subrealm of XPLAIN.COM.) In our case, Bob's user id is joined up with his realm to produce his Kerberos
Principle, (aka Kerberos user id), and looks rather like a funky email address: admin@REALM.COM.
Kerberos takes this principle and sends it as plain text across the network to the Kerberos Domain
Controller, or KDC. Since this is just a user id, and is not sensitive information, there's no need to encrypt
it. The KDC is the center of any given Kerberos realm, (Yes, it probably should be called a KRC, or Kerberos
Realm Controller, but it's not.), and contains the database with all the user information for its realm. Along
with Bob's principle, his Mac also sends the current time as it knows it, and the principle for the KDC, aka
the Ticket Granting Server (TGS, part of the KDC). (We'll explain tickets in just a tick, so hang tight) The
TGS principle is always the same, krbtgt/realm name@realm name, so for Bob, his TGS principle is
The TGS gets this information, and looks up Bob's principle. It finds admin, and admin's password. However,
Bob didn't send this password with his principle, so the KDC doesn't really know that it's the person it knows
as admin@REALM.COM. All it knows is that someone claiming to be admin is trying to authenticate to REALM.COM.
So, Kerberos does something that's pretty slick. It takes the password that it has for admin@REALM.COM, and
uses it to create an encrypted session key. The only thing that can decrypt this is admin@REALM.COM's
password. Within this session key is a bit of information called the Ticket Granting Ticket, or TGT.
The TGT is what the authorization system will use to ensure that a properly authenticated admin@REALM.COM
is allowed to access various resources. The TGT itself is encrypted with a key known only to the TGS. This is
fine, since it's the only thing that cares about the contents of the TGT. This encrypted TGT is then encrypted
again within the session key that only admin@REALM.COM's key can decrypt. So basically, you need an
unencrypted encrypted TGT to do anything. It's a little hard to explain, but it's like this: You ask for a
TGT. You get back a little black box with a thumbprint scanner. The TGT is a USB key that has all the info on
you. But to use it, you have to unlock the little black box that contains this USB key. What's on the key is
not important to you. What's important is that you have the right thumbprint. If you do, groovy, you can now
use the TGT. If not, then you can't.
So, the TGS sends this little black box back to Bob's Mac. The Kerb system on the Mac takes the password
that Bob typed in, (or however he got it. You can use Kerberos with biometrics, RSA smart cards, USB keys,
whatever you feel comfortable with. "Password" is not always a human - typed string), and decrypts the session
key. If the passwords are the same, Bob now has a valid TGT, and a nice krbtgt ticket, which will allow him to
get other tickets and access to other services. Note that at no time did admin's password travel across the
network. It never will either. From now on, the TGT, which can only be decrypted by the KDC/TGS does all the
work. If Bob were to open up the Kerberos application in /System/Library/CoreServices right now, he'd see the
Figure 1. Kerberos setup after initial authentication
So while this is cool, it's kind of a so what. I mean, great, Bob's authenticated as admin, has his initial
tickets. What good does this do him? Well, if that was all Kerb did, not much. Logging into a Mac is nothing
new; logging into a Mac with a centralized authentication system isn't new. The cool part of Kerberos comes
from the Single Signon abilities it gives you. So, now that Bob's got all his tickets, he needs to mount an
Apple File Protocol, (AFP) share to get some files for a project he's working on. He finds the server in the
Finder, or the connect to server dialog, and gets a list of shares, picks the one he wants, and mounts it.
Wait, how did Bob do that when he didn't have to enter a password or log in at all? Are they allowing guest
access? No, they're taking advantage of Mac OS X Server's Kerberized AFP services. After Bob mounts that AFP
share, if you looked at the Kerberos application, you'd see something new: an AFP ticket.
Figure 2. Kerberos showing AFP server tickets
So now what happened here? Well, when Bob accessed the Kerberized AFP server, Kerberos on his Mac took his
TGT, and added a request to access that AFP server and sent it off to the KDC. Remember, passwords never
travel across the network with Kerberos, and the KDC controls all for the domain, so rather than the AFP
server handling the authentication part of this request, the KDC does. The KDC knows that it sent out the same
TGT it's now getting to admin@REALM.COM, so when it gets the TGT and the AFP access request from Bob, it
decrypts the TGT and can validate it locally. Again, no password on the wire, but it's all secure. Along with
the access request and the TGT, Bob's machine packs an authenticator, which is a timestamp that's been
encrypted with Bob's session key. The authenticator is there to ensure that every access request is unique.
Without this, an attacker could just look for TGTs, copy them, and then use them to fake access.
This brings up another point that can cause problem for sysadmins new to Kerberos: Time Synchronization.
Since the authenticator is a timestamp, all the machines in a Kerb realm have to have their clocks
synchronized (usually to within five minutes of each other). Otherwise, there's no way the KDC can use the
timestamp, since, if there was no synchronization requirement, you could use any timestamp you want, or just
capture an earlier session key and use that forever. The other reason for time synchronization is that Kerb
tickets have a time limit, usually ten hours. If you look at the earlier screen shots of the Kerberos
application, you can see a "Time Remaining" column. This is the time left on the validity of the tickets.
There's a very good reason for this. It ensures that even if you don't log out, you have to periodically
reauthenticate. (One way to handle the time synchronization issue is the make the KDC machine the time server
for your network, and have everything synch off of it. It's not the only way by a long shot, time
synchronization is a well - solved problem.)
Face it, we aren't perfect about logging out. Especially if you have jobs that are going to take a long
time to run, you don't want to log out. Well, if you had valid access for...well, forever then an attacker could
more easily subvert your nice Kerb system. So, tickets expire. Now, you can renew tickets any number of ways.
In Panther, any time you log in, whether new, via Fast User Switching, or even from the screen saver, that's
Kerberized, so you're reauthenticating yourself. If you haven't reauthenticated in a period of time decided by
the KDC, you'll be asked to reauthenticate by Kerberos while you're logged in, as shown in the picture below.
Figure 3. Kerberos Authenication while logged in
Now, getting back to Bob's desire to get onto his AFP server, the KDC gets this request, the TGT and the
authenticator. The TGT and the authenticator work to show it's still admin@REALM.COM, and that the TGT is
still valid. The request itself is the service principle for the AFP server in REALM.COM that Bob wants access
to. (Within Kerberos, everything uses a principle to identify itself. Users, services, and KDCs, they all have
principles.) For AFP, this looks like: afpserver/server@realm. The KDC gets this information, and uses the
session key to validate the user. It takes the TGT, which contains the user principle, and uses that to create
a service ticket. The service ticket has two parts, the service principle, and the session key. This session
key is created by the KDC and used to validate the user again. Both of these items are now encrypted again by
the KDC with a password known only by the KDC and the service, in this case, the AFP server Bob wants access
to. The KDC also includes a copy of this session key that is encrypted with the session key that was first
created when Bob logged in. This way, Bob has a copy of the session key, which he'll need, even though he
can't read the data in the session key. That's fine, since he doesn't need to.
Bob's Mac gets all this, ((session key & service principle) and a second session key) and sends the first
session key and service principle (the ones encrypted by the KDC with the password that only the KDC and the
service know), and sends this, unchanged to the server, along with an authenticator, which is a timestamp like
the one it sent to the KDC earlier when Bob started this whole process of getting on to the AFP server. It
encrypts this with the second session key that it got from the KDC. The service gets all this, and does a
couple things. First, it decrypts the session key & service principle that is encrypted with the password that
only it and the KDC know about. If this works, then the service gets access to that session key, which it then
uses to decrypt the second session key that has encrypted the authenticator that Bob's Mac sent too. If both
of these operations work, then there is an extremely high probability that this is in fact, a legitimate
request from admin@REALM.COM, and that this admin is indeed who it claims it is. If all this checks out, the
AFP server is happy that this is a legitimate user. It can then see what admin@REALM.COM, is authorized to use
as far as shares go. If admin@REALM.COM, is authorized to use shares on that server, then Bob gets his list of
shares, mounts the one(s) he wants and voila! He's working on files on his AFP server.
While this seems incredibly complicated, and is kind of is, what Bob sees is:
1. Pick the server he has access to
2. Pick the share he wants to mount
3. Do work
With Kerberos' SSO implementation, all the complexity is handled below the user level, as it should be, so
that user can do what they need to do, and it just works.
SSO Does Not Suck
That's the real beauty of Kerberos and SSO. As long as the service you're trying to use is Kerberized, you
don't have to constantly log in and log out. With Mac OS X Server, almost every service is Kerberized,
including things like ssh, FTP, IMAP, POP, AFP, and SMTP. (No, Windows services like SMB aren't Kerberized in
Panther, but hopefully in Tiger they will be.) So you can get email, transfer files, run applications on
remote servers, even ssh into a remote server, and never have to enter a password once you get past the
initial login. How cool is that? Very, especially if you're a sysadmin with users that can only handle one
password. When it comes time to change a password, you only have to do it one time, and you change it for
every Kerberized service. Another cool feature is that since Microsoft's Active Directory uses Kerberos, you
can integrate your Macs into an Active Directory environment, and still get all the benefits that SSO has to
offer. A final nice benefit is that with Kerb, you can get tickets as any user you have login information
for. So, you can log in as one level of user, but only get access to certain items as another level of user,
by logging into Kerberos as that second user. It sounds funny, but it's a handy trick if you need it.
Now, SSO and Kerberos are not magic. While the services may be Kerberized, that's only half the picture.
The clients you use to get to the services also have to be Kerberized. So the AFP client in the Finder is
Kerberized, as is ssh on Panther. However, if you want a fully Kerberized FTP client, Fetch is the major name
you'll see. For email, you have to use a Kerberized email application, like Mail, Eudora, or others. (No,
Microsoft Entourage is not Kerberized, even though Exchange, and Outlook are, a point of no small annoyance to
those of us wanting to move to an SSO world as much as possible, and no, the Keychain doesn't count.)
As well, while Kerberos keeps passwords from crossing the wire, it doesn't magically make them secure.
Using a password of "password" is still going to leave you wide open to attack. There's no way around it; even
with Kerberos, password quality is critical.
Finally, even though Apple has made it really easy to get started with Kerberos on your network, there's a
ton more to it than you'll find in Apple's documentation. I really, really recommend that you spend a lot of
time on the sites in this article, (also listed at the end of the article) and with the O'Reilly book on
Kerberos. It's easy to make a silly mistake with Kerb that will cause you many problems down the road, so a
little planning on the front end will save you a ton of agony on the back end. You aren't going to get full
integration with other Kerb realms or Active Directory by winging it. If you're going to be running an Open
Directory Realm, I cannot recommend strongly enough that you spend the money on the Apple server courses,
taught by Schoun Regan, Mike Bartosh, Joel Rennich, and others. They will save you more pain than you thought
could exist in the world of being a sysadmin, and will save you the course cost in time spent not undoing
mistakes within a year of taking them, heck, probably within months.
I hope this (very) simplistic look at Kerberos and Single Signon helps you out, whatever your network setup
is. While the setup can be a bear, and wrapping your head around Kerberos can be daunting, once you get it,
you'll wonder why more things aren't Kerberized, because it's just so silly to not be Kerberized.
- Garman, Jason "Kerberos: The Definitive Guide". (August 2003), O'Reilly & Associates.
Web sites with pertinent articles:
- http://www.afp548.com/ (Not just for Kerberos. If you're a Mac administrator, you need this site.)
- http://www.4am-media.com/modules.php?name=Articles (three excellent articles on Kerberos by Mike Bartosh, who knows more than almost everyone about Kerberos and Mac OS X implementations)
- http://web.mit.edu/is/kerberos/www/ (The home page for Kerberos. Marshall, Alexa, Scott, and the rest of the MIT Kerb team do amazing work, and without them, and a lot of other people at MIT (and Apple too!), we wouldn't have this really cool technology on our OS of choice.)
- Starts at http://www.afp548.com/articles/panther/kerberos1.html, and was invaluable as a source for this article. If you run Mac networks, you need to read this site, it's one of the best ones out there. Joel, Josh, and all the others do a fantastic job. Yes, I'm gushing, they earned it.
John Welch (email@example.com) is an IT Staff Member for Kansas City Life Insurance, a Technical
Strategist for Provar, (http://www.provar.com/) and the Chief Know-It-All for TackyShirt,
(http://www.tackyshirt.com/. He has over fifteen years of experience at making Macs work with other computer
systems. John specializes in figuring out ways in which to make the Mac do what nobody thinks it can, showing
that the Mac is a superior administrative platform, and teaching others how to use it in interesting, if
sometimes frightening ways. He also does things that don't involve computertry on occasion, or at least that's