Slashdot Mirror
Kerberos: The Definitive Guide
I got started using Kerberos many moons ago, at my university. This is probably how many people got to know about it. While I didn't use it very much, it's there that I learned the basics and experimented a bit with Kerberos. Interest in it took off after Microsoft incorporated Kerberos authentication mechanisms into Windows 2000. Suddenly it wasn't such arcane knowledge.
Two open source Kerberos implementations exist, the MIT reference implementation, and the Heimdal Kerberos implementation. Even then, there are two main versions which you can find, Kerberos IV and Kerberos V. Kerberos IV went away for most environments with the passing of the Y2K mark, but some legacy apps need support. So, you still have to deal with it on occasion.
In writing Secure Architectures with OpenBSD, I got a lot more intimate with Kerberos, and even set up a decently sized realm in my house. Hence, I got to experience the turmoil of setup and debugging. A book like Kerberos: The Definitive Guide (K:TDG) would have been very welcome. Instead, I slogged my way through it, and got it to work for the most part.
K:TDG will help you set up your Kerberos world by introducing you to the complex subject, terminology, and the pieces. Once you learn the basics, you recognize that a simple realm is actually somewhat easy to set up. The author, Jason Garman, uses a mixed Mac OS X, UNIX, and Windows environment, focusing on UNIX most of the time. The bulk of the examples deal with MIT Kerberos 5 version 1.3 (krb5-1.3) but should work for most versions. Some attention is given to the Heimdal implementation (which is integrated with BSD, for example), and for the most part you'll be OK. Windows examples are also pretty copious but always come second. If you're comfortable with UNIX, you'll easily be able to translate these into Windows examples to help bridge the Windows gaps.
Chapter 1 is an obligatory Introduction, a short chapter that introduces the key concepts of Kerberos and what the book will cover. A very quick comparison of Kerberos to DCE, SESAME, and earlier versions of Kerberos is given. This chapter serves as a nice selling point for the book, it's the type of thing you'd flip through in the book store to decide if you should buy the book or not.
Chapter 2 is a decent overview for the new user of Kerberos to the system and how it works. Kerberos is placed into its role in a AAA infrastructure - authentication, authorization, and accounting - as well as some caveats that are commonly made. You'll learn about core Kerberos features like tickets, realms, principles, instances, ticket granting tickets, and the ticket cache. A decent overview for practical purposes is given, but you will definitely want another resource if you're interested in diving headlong into Kerberos.
These pieces come together in Chapter 3, where the actual protocols are described. They're laid out for a non-cryptographer, so go elsewhere if you want to learn the real formal material behind the system. Understanding the protocols is important to understanding the service as a whole. For someone new to Kerberos, you'll probably want to spend a little more time reading this to get oriented in the Kerberos world. The chapter doesn't mess around too much and delivers a fair treatment of the material.
Chapter 4 is the meat of the book's material, setting up your implementation. It all starts with the KDC (key distribution center) and realm initialization. Again, the bulk of the treatment is on the MIT implementation on UNIX, with the Heimdal and then Windows sections following next. Slave KDCs are also introduced, which is useful for large environments. An OS X server is missing, but Kerberos clients for all three (UNIX, Windows and OS X) is given. The role of DNS is also explained well, a useful touch that's missing in some Kerberos documents I've used in the past. This chapter will get you started, and with some of the supplied documentation you should be up and running in no time.
Chapter 5 is devoted to troubleshooting, an all too familiar task for a new Kerberos administrator. Common problems, their diagnosis, and resolution are discussed. I like the presentation of this chapter and think it will be useful for most real-world situations you'll encounter.
Security concerns with Kerberos are covered in Chapter 6, which discusses concrete and abstract attacks on the Kerberos scheme. Since all of the security in Kerberos resides in your KDC hosts, obviously this covers some of the material. However, the clients can exposes your Kerberos realm to attacks, as well, and how to circumvent these problems is covered. A decent and practical chapter, and covered on both UNIX and Windows.
In Chapter 7 a number of Kerberos enabled applications are discussed. After all, you can do more than just log on locally with Kerberos, you can use remote login programs like SSH, remote access scenarios like printing, and even control X via Kerberos. While not every application that I would have liked was covered, the treatment was fair and should get you started with a number of Kerberos enabled tools in your new realm.
A strong selling point of the book is given in Chapter 8, titled Advanced Topics. Three main topics are discussed. The first is cross-realm authentication, where you have more than one separate Kerberos realm on your network but you want to have users switch between the two without creating accounts in the other. This can get tricky, and the book does a decent job of introducing it, but it's not as complete as it could be. The second main topic in this chapter is Kerberos 4 and 5 interoperability, which is relatively straightforward. Most Kerberos 5 implementations come with tools to process Kerberos 4 ticket scenarios to handle legacy applications. And finally, a really valuable section covers UNIX and Windows Kerberos interoperability, a hairy issue. Again, incomplete but strong enough that you should be able to get it working with some elbow grease. This is probably the most valuable chapter of the book, which does a decent job at the introductory level, but you'll be left to tie up a few loose ends on your own.
An obligatory case study is given in Chapter 9, where you can see a number of configuration samples and even a mixed Windows-UNIX environment. Not terribly useful when compared to chapters 4 and 8, but overall worthwhile. It may answer some of your questions, even. Chapter 10 wraps up the book with looking at Kerberos futures, which isn't all that useful, honestly. What gets more useful is the appendix, which gives an administration reference. Lots of commands are given for MIT, Heimdal and even for Windows, so you can quickly jump there to refresh your memory on a topic.
Overall this book is recommended if you need a place to start working on Kerberos, especially in a mixed environment. The MIT and Heimdal documents are a fair place to start for a UNIX only Kerberos realm, but if you find they aren't enough, this is probably the right book for you. The book's main strength is that it covers Kerberos on the three main platforms in use (Windows, OS X, and UNIX), although it could provide a deeper treatment to the mixed environment than it gives. Still, you should be able to use this as a starting point, and it's probably the best treatment I've seen so far on Kerberos setup and administration.
You can purchase Kerberos: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
Large corporations and educational institutions benefit greatly from single-sign-on ... Consider a college - When you have 10 computer labs with 4-5 operating systems and N SANs all mounting common home directories, the ability to log in to all of them with the same username/password saves a LOT of support headaches. We used to implment (S)LDAP, which worked great for everything but the Win2k boxes - SSO for OSX+Linux with NFS mounted homes actually made a lot of people happy.
Well, Kerberos is nice and everything but as long as the different PKINITimplementations dont get along with eachother, *cough*win2000*cough, we can still do simple social engineering to recover passwords...
Heimdal has a pretty good support by now but the docs are scarce at best, and getting it ( the PKINIT part ) to interoperate is Mayor Payne
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
Although its been a few months since I've last tried. I recall hours upon hours trying to build fetchmail to worth with Kerberos 5 authentication. And after that failing because mit updated something but fetchmail didn't, or the like. And as far as I know, everyone at school here (Iowa State) has had the same problem. So I say "boo to kerberos!" Or at least boo to requiring it exclusivly over any other secure methods of remote access. My solution to this problem is one I would recomend to anyone trying to get around kerberos e-mail authentication is to simply have your e-mail forwarded to a g-mail account and pull it off of there to your box. Here at ISU, at least, its pretty easy to get your mail forwarded to another address. Again, "down with kerberos!"
The Public/Private key mechanisms seem to be another layer that's stacked on top of some of the simpler authentication mechanisms. Which is why is getting OpenSSH to work with Kerberos or Kerberos with OpenAFS can be a real grind. And when OpenSSH doesn't have anyplace to retrieve the public key information from (like your home directory) because it can't prove who the user is you're reduced to entering the password for the underlying target system authentication system every time...
My impression of Kerberos is that it is more about Authentication (proving who you are) than anything else. Once you can prove who a user is, now you have another set of problems, in particular, Authorization.
If you mention using the Public/Private key stuff (like OpenSSH uses) around some of the Kerberos groups, you'll get some interesting viewpoints.
I know I've vastly over-simplifying this.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
MIT Kerberos supplies a Kerberos-aware telnetd that also does DES encryption, but why bother? I'd much rather use OpenSSH. Modern OpenSSH ports don't require a patch, you just need to use the --with-krb5 directive when compiling.
OpenLDAP = Some Assembly Required
I just took another look at this neglected package a couple of months ago. The default schemas still had areas for teletype addresses but no email. There was barely any support for groups.
I went running back to commercial LDAP servers soon after...
My understanding of kerberos (please correct me if I'm wrong) is that it's a symmetric key system. Every computer shares a secret key with a central server that handles authentication.
The problem is that the central server, if compromised (or administered by someone of malicious intent), can authenticate anyone as anyone else to anyone else on the network. In other words, you have to trust a third party.
In a public key system, the worst thing the key authority can do is refuse to publish and/or sign your public key. You don't have to trust anyone but yourself.
So as a Kerberos guru, would you recommend any books over this one? I'm the IT Manager at a company and we're having authentication problems comming out of our ears. I've tried to figure out a solution and right now it looks like Kerberos is our best hope for a number of systems, but I'm having a hard time wrapping my mind around it (yeah it intimidates me).
*RANT* Of course half of our problems are that each new (usually Windows based) systems that cook up their own custom based authentication. Seriously, you'd think IIS had no authentication capabilities by itself - and it's not like these things work in any browser other than IE any damn way. Err., anyway, Kerberos can't fix all of our problems, but just merging 3 of our Unix based systems into Kerberos would make things more manageable.
The installation is simple enough, but the setup throws you into the deep end. The nicest part of the whole setup is that once it's up and running, it's the lowest hassle file server I've dealt with. When I need to rebuild one of the servers(distribution version upgrades mostly), I just tell OpenAFS to move everything onto other servers, rebuild the old server and move stuff back onto it without interferring with users at all.
Part of the yast2 setup for Kerberos also turns on Openafs client function. Which seems a little backward.
Kerberos isn't designed for the Internet. You need to set it up explicitly for each trust domain on each client computer. So users can't just pull out their personal laptops and use them to log in...
/etc/krb5.keytab). A Kerberos client can run anywhere and does not require a prior host connection with the realm at all. You *can*, in fact, do exactly what you describe here as impossible: connect your laptop to a network and type "kinit user@REALM" to get credentials, then use a kerberized application such as OpenSSH. The Kerberos software can find a KDC for "REALM" from the DNS (assuming the appropriate rr's are available). Note that this is secure despite the insecurity of the DNS in general, since Kerberos is a shared-secret system: since you share a secret with the KDC (essentially your password), you can validate the KDC's response.
I'm afraid your entire point here is just technically false. Kerberos only requires host setup with if the host is a server; that is, to run a kerberized service on it, you need to establish a shared key for the service principal with the Kerberos system (KDC) and store it on the host where the corresponding server can find it (e.g.
My bad; you're right. I was originally thinking of a different situation and confused myself. That situation is single sign-on for all Internet services with a single authentication token. (Like authenticating to slashdot through slamb.org.) Then there wouldn't be a pre-established relation between the service hosts and the KDC, either. Plus, you'd need support for pseudonyms to make it fly with the privacy advocates. I.e., I using my slamb@slamb.org identity to authenticate as anon1932@slamb.org, provided that slamb.org allows it. (Presumably you'd do this with a domain shared by other people, so your identity is not completely obvious anyway.)
But even with the situation I described in the grandparent post, there's still the problem of trusting the computer you're sitting at. Typing a password into an untrusted lab computer is no good. It's an acceptable risk to run a session through there, but to supply authentication information that can be re-used...no thanks.