Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Books Media Book Reviews

Kerberos: The Definitive Guide 177

Posted by timothy from the connecting-stuff dept.
nazarijo (Jose Nazario) writes "Everyone knows that Kerberos is the biggest solution to the single sign-on dilemma. How can you get everyone using one bank of accounts on loads of machines, from UNIX, OS X, and Windows environments, and do so securely? You can shoehorn in a variety of mechanisms, or you can adopt Kerberos. However, Kerberos intimidates a lot of people, somewhat deservedly so, but also somewhat needlessly. Enter Kerberos: The Definitive Guide, one of the latest 'definitive guides' from O'Reilly." Read on for the rest of Nazario's review.
Kerberos: The Definitive Guide
author Jason Garman
pages 272
publisher O'Reilly and Associates
rating 7/10
reviewer Jose Nazario
ISBN 0596004036
summary A comprehensive, cross platform guide to Kerberos

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
This discussion has been archived. No new comments can be posted.

Kerberos: The Definitive Guide More

Kerberos: The Definitive Guide

Comments Filter:

  • But are people comfortable with SSO! (Score:3, Insightful)

    by zyridium ( 676524 ) on Monday February 14, 2005 @04:03PM (#11671666)
    When are people going to realise that the problem with single sign on isn't a technical one....

    • Re:But are people comfortable with SSO! (Score:5, Interesting)

      by Anonymous Coward on Monday February 14, 2005 @04:05PM (#11671698)
      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.

      • SSO != Single Account (Score:4, Informative)

        by DrZaius ( 6588 ) <gary.richardson+slashdot@gmail.com> on Monday February 14, 2005 @04:25PM (#11671911) Homepage
        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.

        • Re:SSO != Single Account (Score:4, Informative)

          by 0racle ( 667029 ) on Monday February 14, 2005 @05:20PM (#11672485)
          Without a central account database you (the admin) would still need to create on each system that same account, name and possibly UID. In a large environment where SSO makes the most sence, using Kerberos without a central account database, either an LDAP directory or NIS, makes no sence.

          Incidentally SSH, FTP, mozilla and so forth need to be told to use Kerberos, they will not use it simply because you have a valid ticket.
          • Incidentally SSH, FTP, mozilla and so forth need to be told to use Kerberos, they will not use it simply because you have a valid ticket.

            Maybe you can answer me a question that has bugged me for ages... how does one 'kerberize' a client? For instance, the mass store ftp site for a research facility I use can only be accessed by a kerberized ftp client which is the brain-dead UNIX client, and it has to be downloaded in binary form. I would love to have something like ncftp be able to access the files. Any
    • single sign on is a damn useful thing for an enterprise network. where you have direct control (as the administrator at least i do) over all the places your employees might ever log on. and where they should only log on for company-related stuff. privacy never enters the equation in those cases

      out of the enterprise, it's a whole different game
    • Never.

      It is an article of faith that all technical problems have technical solutions. It is a further article of faith that if a problem can be called "technical" it will be -- no matter whether or not that's accurate. Because technical problems can by definition be solved by technology, and everyone wants problems to be solved, all problems are therefore technical.

      God forbid we have to change the way we do business to fix an issue. No! Just put a technical band-aid on it!

    • Re:But are people comfortable with SSO! (Score:5, Funny)

      by fm6 ( 162816 ) on Monday February 14, 2005 @04:17PM (#11671829) Homepage Journal
      You started to say something interesting and useful, then your attention wandered. Inquiring minds want to know: if the problem with SSO isn't technical, what is it?
    • I think you're confusing the single sign on presented here, which is an intra-enterprise sign-on, with universal single-sign on systems like Passport.

    • Re:But are people comfortable with SSO! (Score:4, Insightful)

      by slamb ( 119285 ) * on Monday February 14, 2005 @05:09PM (#11672361) Homepage
      When are people going to realise that the problem with single sign on isn't a technical one....

      The biggest one I see is technical: there's no good single sign-on system designed for the Internet.

      Kerberos is the only widely implemented system I'm aware of that implements one key criterium: service providers can't use the credentials passed to them to log in to another service. With web-based single sign-on systems, the password you enter for webmail will also get you in to the billing system. So if the webmail system is compromised (and it's typically held to a much lower standard), so is the billing system. That's no good.[*]

      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, unless you've instructed them on setting it up. And certainly not on whatever public computer they've run across.

      What we need is a single sign-on system with a different model. I think it would require:

      1. a cheap physical token that has public-key cryptography.
      2. a password entered directly into the token that you carry with you. You shouldn't have to trust the machine you're using to not capture your password. That model works for ATMs, but not for net cafes.
      3. no setup for each trust domain on each client machine. Presumably, it would authenticate the domain's keyserver using PKI. Either the existing system where you buy a certificate from Verisign on DNSsec.
      4. wide acceptance - the physical readers should be present on any random machine you stumble across, and so should supporting software.

      Certainly #2 and #3 are technical problems. #4 is not. #1 is arguable.

      [*] - Some web applications make some effort to avoid this problem. But they're not good enough. The University of Iowa has the HawkID system, which redirects all login requests to the hawkid one, and then back to the application. But you still enter the password into a web form given by the application, and there's no UI for seeing the destination of the form. When you enter it, you don't have a guarantee that the web application doesn't get the password. We need a new system just for authentication that makes potential security problems blindingly obvious.

      • > That model works for ATMs

        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 servi

        • No, the original poster knows what he's talking about.

          The problem with an ATM card is that it is not cryptographically self contained. Because it has no processing power, it cannot computer message authenticators etc. on its own. Instead, it has to reveal its secrets to the machine it is inserted into so that machine can do the procedure for it. This is why the false front thing works. The card tells everything it knows.

          The poster is talking about something like an ibutton or smart card that has on-

      • Re:But are people comfortable with SSO! (Score:4, Interesting)

        by rsilverman ( 266807 ) on Monday February 14, 2005 @10:29PM (#11674709)
        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...

        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. /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.
        • 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)

          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

    • 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 y

      • That's mostly correct, but I disagree with your last statement.

        The KDC is an attractive target because it has all of the secrets. Public key systems with a hiearchical PKI structure have a similar problem because the holder of the private key for the root certificate is also an attractive target---if an attacker gets that private key then they can issue new certificates for themselves. However, the Kerberos KDC is always online (hence vulnerable), whereas the private key for the root certificate migh

    • The issue with a universally single sign on is that people don't universally trust anyone. However, that doesn't mean that there isn't a use for a single sign on for a collection of related services. It would make sense to have a single OSDN signon, a single signon for all your work services (printer, fileserver, mail server, etc), one for home, one for school, and so forth.

  • AFS Coverage? (Score:4, Insightful)

    by xlark ( 689369 ) on Monday February 14, 2005 @04:09PM (#11671733)
    Too bad there seems to be no coverage of AFS. I'd love to see a book documenting using Kerberos V with AFS.
    • I'd buy it.
    • I assume you meant the Andrew File System and not another AFS [wikipedia.org]? As the obscurity of the name attests, its not that popular a file system.

      • Re:AFS Coverage? (Score:4, Informative)

        by TilJ ( 7607 ) on Monday February 14, 2005 @05:20PM (#11672492) Homepage
        Or, for a more modern reference check out http://www.openafs.org/ [slashdot.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.

      • Re:AFS Coverage? (Score:2, Interesting)

        by kenaaker ( 774785 )
        OpenAFS is also a optional installable package on the SuSE disks. There's also a Debian package with some pretty good server installation/setup instructions. SuSE pairs it up with Heimdal, not the MIT Kerberos.

        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

        • The question isn't how many people have access to AFS software. The question is how many people use AFS software. I could be wrong, but I'm doubtful that it's enough to justify space in this book.

    • Re:AFS Coverage? (Score:3, Informative)

      by 0racle ( 667029 )
      Something like this [uni-karlsruhe.de]?

  • Kerberos Dialogue (Score:5, Informative)

    by Anonymous Coward on Monday February 14, 2005 @04:10PM (#11671745)
    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 [mit.edu]

    • Bad HTML alert (Score:4, Informative)

      by fm6 ( 162816 ) on Monday February 14, 2005 @05:04PM (#11672310) Homepage Journal
      This is one of those occasions I'm grateful I still have Internet Explorer (and the IEView extension [mozdev.org]). 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.
      • I hate it when authors put too much text in the body tag, too.

        Sounds like bad FireFox code.

  • Not so bad (Score:1, Informative)

    by Anonymous Coward
    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.

    It was difficult at first but i've grown used to it, and it seems to be pretty great and .. er not so bad now.

  • Bad editing (Score:5, Informative)

    by Dop ( 123 ) on Monday February 14, 2005 @04:13PM (#11671781)
    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.

    • Re:Bad editing (Score:3, Insightful)

      by jayhawk88 ( 160512 )
      I made a list of corrections that I sent to both O'Reilly and the author which were ignored.

      Perhaps the corrections you sent had already been caught by someone else (at O'Reilly or otherwise), only too late to fix before this publication, and will be corrected in any future publications. Granted I suppose a note of thanks from the author would have been nice, but what did you expect, Hallmark?

      • Re:Bad editing (Score:2, Informative)

        by sharkey ( 16670 )
        Right. Do any of them appear in the Errata [oreilly.com] for the book?

    • Re:Bad editing (Score:4, Funny)

      by fm6 ( 162816 ) on Monday February 14, 2005 @04:50PM (#11672159) Homepage Journal
      Getting too arrogant? O'Reilly's books have been badly edited as long as I can remember. Although this is the first time I've heard of them failing to run a spell check. What they usually do is let the author free-associate all over the landscape, with no overall structure and too many footnotes, irrelevencies, and grade-school-level jokes. Doesn't matter if the author has some self-discipline, but most of them don't. Smart people, but not good at expressing themselves clearly or concisely.

      I never buy the O'Reilly book if another publisher has a decent title on the same subject. But it's often the case that O'Reilly has the only title on a particular subject, or the only one by an author who really knows the subject. So they kind of have a guaranteed audience. Which, as you say, tends to make them arrogant.

      What makes this particular frustrating is that somebody at O'Reilly sat down and wrote one of the best writer's guides I've ever seen [oreilly.com]. If only they'd make their writers actually read it!

  • "Dinosaurs" can play too. IBM has an implementation on z/OS that ties in with their LDAP implementation, their DCE implementations, etc. and it all connects with their "native' Resource Access Control Facility (or as it's now supposed to be known, Security Server). I've seen papers in fact where the LDAP/Kerberos combination can play nice with Active Directory should your organization's policies require it.

  • PKINIT (Score:3, Interesting)

    by savuporo ( 658486 ) on Monday February 14, 2005 @04:14PM (#11671800)
    Well, Kerberos is nice and everything but as long as the different PKINIT [isoc.org]implementations 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

    • Re:PKINIT (Score:1, Interesting)

      by cpuh0g ( 839926 )
      PKINIT is not yet standardized by the IETF. Whatever implementations are out there not will ultimately be broken by the time the document clears the IETF.

      Don't even bother trying to get interoperable PKINIT implementations working now, wait until the spec is finalized.

    • Re:PKINIT (Score:3, Insightful)

      by TheCabal ( 215908 )
      Uh, Win2k's Kerberos implementation is suprisingly standards-compliant. I've had NO issues whatsoever getting my MIT Krb5 systems taking to Win2k and Win2k3 KDCs. Microsoft even has a simple step-by-step guide on how to export the account data to a Kerberos keytab. If your krb5.conf file is set up properly, it's less than 5 minutes to set up the user account, export the keytab and import it onto your system.

      Try harder.

      • Re:PKINIT (Score:2, Informative)

        by cpuh0g ( 839926 )
        There is no PKINIT standard for them to be compliant with - yet. The current draft spec is at revision 23 and still being debated in the kerberos working group.

        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.

  • Uuh, kerberos is what? (Score:3, Funny)

    by Rosco P. Coltrane ( 209368 ) on Monday February 14, 2005 @04:15PM (#11671808)
    Everyone knows that Kerberos is the biggest solution to the single sign-on dilemma.

    You mean it isn't Passport? I'm so confused now...

  • Incase of Slashdotting... (Score:3, Funny)

    by Anonymous Coward on Monday February 14, 2005 @04:17PM (#11671821)
    bash-2.05a$ man kerberos

    KERBEROS(1)

    NAME
    kerberos - introduction to the Kerberos system

    DESCRIPTION
    The Kerberos system authenticates individual users in a network environment. After authenticating your-elf to Kerberos, you can use network utilities such as rlogin, rcp, and rsh without having to present passwords to remote hosts and without having to bother with .rhosts files. Note that these utilities will work without passwords only if the remote machines you deal with support the Kerberos system.
    .
    .
    .
    Currently, Kerberos support is available for the following network services: rlogin, rsh, rcp, telnet, ftp, krdist (a Kerberized version of rdist), ksu (a Kerberized version of su), login, and Xdm.

    SEE ALSO
    kdestroy(1), kinit(1), klist(1), passwd(1), rsh (1), rcp(1), rlogin(1), telnet(1), ftp(1), krdist(1), ksu(1), sclient(1), xdm(1), des_crypt(3), hash(3), krb5strings(3), rb5.conf(5), kdc.conf(5), kadmin(8), kadmind(8), kdb5_util(8), telnetd(8), ftpd(8), rdistd(8), sserver(8), klogind(8c), kshd(8c), login(8c)

    BUGS
    AUTHORS
    Steve Miller, MIT Project Athena/Digital Equipment Corporation Clifford Neuman, MIT Project Athena

    HISTORY
    Kerberos was developed at MIT. OpenVision rewrote and donated the administration server, which is used in the current version of Kerberos 5.

    RESTRICTIONS
    Copyright 1985,1986,1989-1996 Massachusetts Institute of Technology
    KERBEROS(1)
    • Or, this [wikipedia.org].
    • DESCRIPTION
      The Kerberos system authenticates individual users in a network environment. After authenticating your-elf to Kerberos, you can use network utilities such as rlogin, rcp, and rsh without having to present passwords to remote hosts and without having to bother with .rhosts files. Note that these utilities will work without passwords only if the remote machines you deal with support the Kerberos system.

      Oh, good. My-elf always needs convenient authentication.
    • After authenticating your-elf...

      What about hobbits, or men, for that matter?

  • 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 o
    • I'm confused. What does LDAP have to do with single sign-on? I thought it was just to manage directory information.
    • 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...

    • Re:interoperability with windows/ active directory (Score:4, Informative)

      by 0racle ( 667029 ) on Monday February 14, 2005 @06:01PM (#11672876)
      Kerberos and LDAP serve very different purposes. LDAP is a directory, it can store usernames, passwords, and a whole lot of other junk. in AAA it handles Authorization (usernames/UID's), and Auditing. Kerberos only provides Authentication, with a little auditing thrown in. Kerberos still requires there to be something else to provide that said username, identified by a ticket, is allowed to use a paticular resource. LDAP does have its own authentcation method, but for most things it is not used in favor of the more mature and tested kerberos authentication. In this manner LDAP provides the same functionality as your passwd file, and kerberos your shadow file. Using LDAP auth, to extend this analogy, would be like not using shadow passwords and simply keeping the password hash in the passwd file.

      Both the LDAP administration book and the Kerberos book mentioned here do work well together, I picked them both up when I kerberised/LDAPified my network at home. I haven't got my Solaris box up and running yet, so I don't know how difficult that will be.

    • Apples and oranges... (Score:4, Informative)

      by rmdyer ( 267137 ) on Monday February 14, 2005 @06:17PM (#11672997)
      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?

  • Single Sign-on needs more than kerberos (Score:3, Informative)

    by ThinkTiM ( 532164 ) on Monday February 14, 2005 @04:24PM (#11671904)
    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...

  • Kerberos? (Score:5, Funny)

    by null etc. ( 524767 ) on Monday February 14, 2005 @04:26PM (#11671919)
    Everyone knows that Kerberos is the biggest solution to the single sign-on dilemma.

    Well, duh! Even my grandmother uses Kerberos to solve her single sign-on dilemma!

  • Does the book address using Kerberos and one time passwords? I stopped using Kerberos after having problems with OTP tokens. I never got a SNK working right and it doesn't appear to support the RSA or VeriSign tokens.
  • 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
  • At 272 pages, it DoSes too much spare time. An that Kerberos name sounds !EVIL!
  • If you want working single-sign on across domains/organisational broders you can use Globus, the defaco open-source Grid framework/toolkit mostly in use in the research, univeristy world.

    New reworked version 4.0 scheduled for release this spring will provide for authorization thru firewalls and webproxies using Web Services tech.

    http://www-unix.globus.org/toolkit/docs/developme n t/4.0-drafts/GT4Facts/index.html/ [globus.org]
    http://www-unix.globus.org/toolkit/docs/developmen t/4.0-drafts/security/authzframe/index. [globus.org]
    • Sorry the links got screwed up, remove the trailing slash (*ugh* wheres the edit function then you need it!).
    • Here's a key indication that this Globus stuff isn't ready for prime-time yet...

      http://www-unix.globus.org/toolkit/docs/3.2/index. html [globus.org] "Globus Toolkit 3.2 Key Concepts (not yet available)"

    • Globus is nice, but it's dependency hell. The circular dependencies are particularly fun - which comes first? Globus or MPICH? For that matter, why is it specific to MPICH, when other MPI implementations may be more suited to the users' needs?

      I'm also not a great fan of so much code being based in Java. That strikes me as a lag-fest waiting to happen.

      Having said all that, Globus is undoubtably the best grid system out there. There are other ways to go parallel, but if you specifically need a grid system

      • yes I agree with you, it's pretty much a mess to install a barebones Globus today, it's a complex installation procedure with a shitload of external dependencies. Hopefully things will get simplier in the future as the new IBM/HP/SUN/Intel collaboration to adopt Globus as the major enterprise Grid standard starts to work on the obstacles for a widespread adoption.

        Using Java as the foundation (well, "reference implementation" really) for GT4, I think that's a good thing, then you find yourself on a daily ba
        • Since I can't mod a reply to one of my own posts, I can't mod that up, but that's probably the best analysis of Globus and of Java that I've seen. Thanks, I appreciate it.
  • NAT breaks kerberos making it useless in many situations.

    • Re: (Score:3, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
      • what apart from the big fat security warning in the hemdail docs concerning addressless tickets??? something to the effect "don't use addressless tickets because it opens you to the same weakness as using kerberos4" as for the post above saying don't use nat, your a wanker mate, where is a small organisation going to get 254 ips from for each of it's workstations?

  • Good book, but less quality that O'Reillys best (Score:5, Informative)

    by TilJ ( 7607 ) on Monday February 14, 2005 @05:08PM (#11672353) Homepage

    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:

    • OpenAFS (and this is a big one!)
    • web (browser and server) integration
    • A detailed discussion on setting up DNS support for Kerberos. Seriously, this eliminates most of the "maintaining a krb5.conf" issue.
    • GSSAPI
    • converting databases from Heimdal to MIT (or vice versa)
    • mixed KDCs (MIT master and Heimdal slave and vice versa)
    • scripting kadmin
    • best practices (i.e., what *is* a good KDC policy for new principals? Why?)
    • in-depth discussion on cross-realm trusts (including one-way trusts) and ways to use krb5.conf to avoid needing a ~/.k5login everywhere
    • Kerberos support in Ethereal, to aid in trouble-shooting (though to be fair this is fairly recent)
    • A real discussion of krb5to4. Sorry, a half-page doesn't cut it.
    • A better discussion of PAM and Kerberos. Do you know how many unrelated PAM modules there are all named krb5? Bah. If I wanted xdm and xscreensaver to do the right thing, the book wouldn't really help with that.
    • A listing of interesting Kerberos clients and servers and some practical configs for them would've been great. For example, Postgresql supports Kerberos, yet the book doesn't touch that.

    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 ;-)

    • 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. Serious
  • Obligatory book website [oreilly.com] and sample chapter [oreilly.com] links.

Slashdot Top Deals

Pascal is not a high-level language. -- Steven Feiner

Close