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
No article about Kerberos would be complete without a link to one of the more interesting introductions out there:
Designing an Authentication System: a Dialogue in Four Scenes
we use kerberos here at work, and we solved the single-sign on issue with our program, co-sign. I think it's at cosign.org? Unsure.
.. er not so bad now.
It was difficult at first but i've grown used to it, and it seems to be pretty great and
I've read the majority of this book and overall it's pretty good. However, even considering that this is a first edition book there are quite a few mistakes (mostly editing... grammar, spelling, etc).
I made a list of corrections that I sent to both O'Reilly and the author which were ignored. I think O'Reilly is getting too arrogant and it's going to hurt their reputation.
I think another good way to look (if you're interested in good interoperability) is openLDAP. I know there are a lot of tie-ins to Kerberos, but I believe it's a better direction to go, when you look at features, and supporting naming services, printers, etc.
:-)
I've been pretty happy with the O'Reilly "LDAP" book, which has been terribly helpful. To be honest, it's still been a bit of a pain. I blame Sun more than anything else; should be a lot easier if you were implementing on Linux. I have used a lot of google also, but nobody seems to have the true complete guide to getting things working on Solaris, even if they claim to.
Regardless of all of this, maybe the LDAP book and this one could work well together.
YMMV.
Everyone knows that Kerberos is the biggest solution to the single sign-on dilemma. Single sign-on needs more than what Kerberos provides - so Kerberos is only a component of a solution. Kerberos only does the authentication part, it's often paired with LDAP to hande authorization...
Or, this.
There is a big difference between SSO and having a central account database.
Single Sign On means your enter your username/password once and you can connect to any resources you are allowed to.
For example, you'd log into your Windows XP PC. Without entering your password again, you can browse other computers in the AD Domain. You start Outlook and you never have to enter your login info for your exchange server. From there, you point IE at your intranet server and it uses the kerberos ticket to log you in without a password.
In the unix world, it means getting a ticket with kinit. From there, ssh, ftp, mozilla and so forth should be smart enough to not require you to log in again.
-- DrZaius - Minister of Sciences and Protector of the Faith
The editor comments on a book about a network authentication and encryption protocol, i comment about an approach that i consider better and more modern.
In your parent post you claim that OpenSSH is a replacement of Kerberos. It's not offtopic, I grant you that. On the other hand. you are wrong in your claim.
In the myth of Eros and Psyche, Psyche had to sneak past Kerberos to get into Hell and borrow Persephone's beauty secret. She used honey cakes to get past. Aeneas also used honey cakes to get past.
Orpheus played music, and Hercules just picked him up and dragged him out.
What I say does not represent the views of my employers, my friends, my cats, or myself.
Actual answer:
Kerberos is an authentication protocol. You have a client, a server, and a kerberos server. The kerberos server itself has three parts, the key distribution center, the authentication server and the ticket granting server. This is a symmetric encryption system: no public or private keys, just private keys.
Before anything happens, both Client and Server share their cryptographic keys with the Key Distribution Center. This setup is required for kerberos to work. Kerberos doesn't work if you can't set things up beforehand.
When it's authentication time, Client goes to Ticket Grantor and says, "I want to talk to Server, and here's my key." Ticket Grantor asks Server, "Client wants to talk to you. Is that okay?" Server says it's okay, so the Ticket Grantor sends a ticket-granding ticket (encrypted with Ticket Grantor's key, so only TG can read it) and a session key (encrypted with the Client's key, so only Client can read it) to Client. Note that at this point we haven't authenticated Client -- we've just checked that Client is authorized to talk to Server.
Client unencrypts the session key using its own key. If Client really is who it says it is, the unencrypted key will be correct. Client goes to Ticket Grantor with the ticket-granting ticket and the session key and says, "Look, I can do it! It's me! Gimme a real ticket already so I can talk to the server." Ticket Grantor says "Ok" and does gives the Client a ticket encrypted with the Server's key and a new session key encrypted with the Client's key.
The Client decrypts the session key: now it knows how to handle talking to the Server. Then it sends the Server the ticket. If the Server is who the kerberos server thinks it is, it will be able to decrypt the ticket and establish a session with the client.
It's more complicated than that, but I think this covers it. Does that help? I expect if I have erred I will be corrected forthwith, as nothing gets the right answer faster than posting the wrong one.
What I say does not represent the views of my employers, my friends, my cats, or myself.
This is one of those occasions I'm grateful I still have Internet Explorer (and the IEView extension). The authors of this page made the classic blunder of coding their HTML to the browser, not the the standard. Specifically, they used tables to encode non-tabular text. The result looks like a play script on whatever browser they tested it on, but Firefox doesn't have the smarts to deal with a table that long. And why should it, except to accomodate inept page designers? A goal that deserves some priority, but not an infinite amount.
It's suprisingly easy to do. I've done it for a couple of organizations and at the house. Simplifies my ssh logons considerably. Microsoft was suprisingly strict with its standards compliance on this one.
Microsft Krb5 interop guide
Just set your krb5.conf file to use the AD server as the KDC. Thats it.
If that is too much for you, then there are also a ton of documents available from Microsoft that tell you, step-by-step, how to do it.
I'm a Kerberos fan. I wrote the Kerberos5 chapter of the FreeBSD Handbook (and I have a re-write mostly completed) and I worked with quite a few Realms over the past few years.
I've read Kerberos: TDG several times now, and I've tried to find the answers to obscure problems often in it -- usually, without success. I think it should have been named Kerberos: An introduction because it isn't a Definitive Guide. Look at the page count alone: it's a slim, slim book. An in spite of being slim it tends to be a repititious. Not a good sign for something trying to living up the Definitive Guide tag.
It also misses quite a few topics that would be great to see covered in a second edition:
I liked the book. I'll take it over not having an O'Reilly Kerberos book any day. But I look forward to a revised second edition ;-)
"The purpose of argument is to change the nature of truth." -- Bene Gesserit Precept
Wrong. Use addressless tickets. Problem solved.
It's a little bit more than just tweaking krb5.conf, but that is the hardest part. You still have to create a user account, export the credentials to a keytab and move the keytab to the system.
I think you are confused with the difference between PKINIT and Kerberos V5. They are 2 different things.
Yes, getting MIT KRB5 to interop with Win2K is easy. But there is no PKINIT available from MIT yet, though, which leads me to think you are confusing 2 different protocols.
When was the last time you used it? '96? The convention regarding Kerberos has been to use addressless tickets for a long time now.
Or, for a more modern reference check out http://www.openafs.org/.
For folks unfamiliar with AFS, it gives you (as compared to NFS) features like volume management, failover, Kerberos authentication, ease of client maintenance and intelligent client-side caching.
"The purpose of argument is to change the nature of truth." -- Bene Gesserit Precept
Something like this?
"I use a Mac because I'm just better than you are."
You are spreading misinformation. Kerberos is an authentication system/protocol. LDAP is a directory service. The two are not the same. Technically you should never use LDAP for authentication since it wasn't designed for it. People do it, but that doesn't make it right.
Kerberos was made to guarantee the authenticity of a user or service that has been granted access to the network. The right way to secure LDAP would be to use Kerberos authentication. You can use SSL with LDAP but you are just passing around encrypted plain text passwords. SASL allows the client to select whatever the best protocol it can support.
What many in the industry have done with LDAP is wrecked it by using SSL with secret stores where the directory holds the encrypted passwords for every service you need to access. This basically amounts to nothing more than Microsofts old PWL files on Win9x. Its just a temporary patch for a long term problem, but many industry PHBs throw their hands up because even after a decade of Kerberos, very few products have been Kerberized. At least Microsoft was smart enough to realize with Win2k that in the long term, only Kerberos is the right way to do it.
In the end though, this turns out to be a hot debate of public key vs. private key authentication systems. Kerberos is a private key system that has done well, but not as well as public key used in the internet. People are simply extending LDAP and public key as an alternative authentication system to using Kerberos. While many people may think this is a better solution, I beg to differ.
So how about it slashdotters, which is it? Which system will win out, public, private, or a combination of both?
http://www.pantheon.org/articles/c/cerberus.html More random info.
Actually it doesn't work for ATMs either. There's a hack that's been reported locally where someone sets up a reader/screen/button panel over the top of an ATM faceplate. They read the card, record the PIN (that YOU entered), and says there's a problem with the account. Then they can replicate your card and they have your PIN.
This is why I don't like SSI. There is no end to the number of clever hacks people will dream up, and I don't want to have to trust that ALL of my service providers have correctly thought about, designed, and implemented their security measures. At least now, if my Amazon ID gets cracked wide open, it doesn't affect my ability to talk to my bank. And like any intelligent person, I may choose to read the NYT online by supplying my password on a public terminal, where I would never use one to talk to my bank.
The challenge occurs if you have users who belong to more than, say, 8 groups. In this case, the PAC exceeds the W2k3 threshold for UPD responses, so your kerberos client needs to support TCP (mit 1.3.1 or above). A workaround is to change the threshold, see kb837761, to enable legacy krb5 clients on w2k3 servers change MaxDatagramReplySize to 4000 decimal (about the same as w2k). I had to do this to enable pam_krb5 from our VMware ESX servers...