Volume Number: 21 (2005)
Issue Number: 2
Column Tag: Programming

Patch Panel

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 you.

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?"

3. "Bob"

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 krbtgt/REALM.COM@REALM.COM.

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 following:

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.

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.

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.

Conclusion

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.

Bibliography

• 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 (jwelch@provar.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 the rumor.