Kerberos: The Definitive Guide

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

Comments

FP

[Anonymous Coward]

First Post you fuckers!

2nd post

[Anonymous Coward]

2nd post dipshits

But are people comfortable with SSO!

[zyridium]

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!

[Anonymous Coward]

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.

Re:But are people comfortable with SSO!

[Feyr]

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

Re:But are people comfortable with SSO!

[Daedala]

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!

[Anonymous Coward]

I certainly hope so considering I am working on a Single Sign-on project at work! All our customer facing applications will now have a unified logon. The challenge is trying to attach the legacy applications to the system.

Re:But are people comfortable with SSO!

[fm6]

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?

Re:But are people comfortable with SSO!

[ergo98]

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!

[blogeasy]

True. If it goes beyond the borders of a single company it becomes a competitive and political issue. Microsoft tried to offer their Passport as a single sign-on and identity solution, but obviously it doesn't work for several reasons including Microsoft's reputation for security and the fact that all that identity information resides with one company.

Sun and several other companies came up with the Liberty Alliance to provide a federation of companies that could collectively provide a single sign-on network, but it is taking a while to get it going. Although, it seems to be gaining new ground slowly but surely with IBM as one of the lastest additions to the alliance.

It would be nice, to one day, be able to use a widely recognized single sign-on source that is not controlled by a single company.

Re:But are people comfortable with SSO!

[Anonymous Coward]

Huh? Actually this is one thing that Windows DOES do well, unlike Linux which is stuck with some silly NIS server (just a list of names and passwords... it's up to the app to support it) in place of a real domain (which has built-in centralized control of access to remote resources).

Re:But are people comfortable with SSO!

[slamb]

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.

Re:But are people comfortable with SSO!

[Anonymous Coward]

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?

No, he was never saying anything interesting. It's just a karma whore trick: state a bold conclusion some people will agree with. Don't provide an explanation. The people who agree will mentally fill in their own explanation where yours should be and mod up your post accordingly. No one else can say your argument is bad, because you haven't made one.

Re:But are people comfortable with SSO!

[MonsterChicharo]

Been there, done that. A layer of abstraction is the way to go. Create a component, a front-end of sorts, for each legacy system. Integrate that, and not the system itself, to the sso solution. Use the current, legacy accounts as pointers to the new unified account. Have the new component accept sso tokens of some kind - kerberos tokens work marvels, if you have the patience to use the GSSapi; if not, a sso web solution that can grant tokens (catching cookies is a simple thing to do).

Re:But are people comfortable with SSO!

[noidentity]

Kerberos is the only widely implemented system I'm aware of that implements one key criterium [...]

Is criterium a new element? Or is it more like unobtainium?

Re:But are people comfortable with SSO!

[Clod9]

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

Re:But are people comfortable with SSO!

[iabervon]

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.

Re:But are people comfortable with SSO!

[Anonymous Coward]

It's much simpler than that. Just have web sites start accepting asymmetric key certificates. Any certificate is fine, just with minimum strength requirements. The user supplies the public key instead of their username, and then to sign on they just sign a challenge or simply use it to set up a diffie helmen SSL session using the server's public key. Easy as hell, secure, and most importantly decentralized and structureless. Every user has their public/private keypair and can even use different pairs if they don't want data mining to associate them with different sites. The only thing left to do is make a good management client for users to run on their home PC to manage their certs.

Re:But are people comfortable with SSO!

[hey!]

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-board computing power that can compute message digests etc. without using the computer it is connected to. That comptuer is just another part of the network so far as the device is concerned -- that is to say it is used to transmit the cryptographic proof that the transaction is authorized by the bearer without being privy to how that computation was performed.

It would absolutely foil an attempt at password theft, although it possible that in such a system a man in the middle kind of attack could be performed, where the device told the user it was withdrawing $100 but it was withdrawing $500. Even that could potentially be addressed.

Re:But are people comfortable with SSO!

[rsilverman]

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.

Re:But are people comfortable with SSO!

[Anonymous Coward]

he he... its like you take off your pants, and the rest will do the fscking, and you will get credit (or whatsoever it is). Or like, whoring, but no whoring.

I am not whoring, am I? Forget it, I am anonymous anyway...

Re:But are people comfortable with SSO!

[slamb]

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

Re:But are people comfortable with SSO!

[tommyth]

At the university I'm at, we have some 20,000 computers, plus we have to sign on (in other words, associate our NIC's MAC address) to the network with our Kerberos SSO information. And it's used for every department imaginable, from laundry money to getting jobs listings. Fortunatly, the minimum password length is 12 characters, and it has to be changed every 6 months (?). Long story short, when well implimented, Kerberos SSO can be a Good Thing.

Re:But are people comfortable with SSO!

[bombshelter13]

Nontechnical, obviously.

I'm still waiting for the O'Reilly series...

[goldspider]

...of debatable, incomplete, inconclusive, inexact, questionable, and unreliable guides.

Perhaps a teabagging is in order?

[Anonymous Coward]

Any cocksmokers? Non?

Offtopic? Post is a Direct Quote!

[Anonymous Coward]

n/t

AFS Coverage?

[xlark]

Too bad there seems to be no coverage of AFS. I'd love to see a book documenting using Kerberos V with AFS.

Re:AFS Coverage?

[Dop]

I'd buy it.

Re:AFS Coverage?

[fm6]

I assume you meant the Andrew File System and not another AFS? As the obscurity of the name attests, its not that popular a file system.

Re:AFS Coverage?

[TilJ]

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.

Re:AFS Coverage?

[0racle]

Something like this?

Re:AFS Coverage?

[kenaaker]

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

Re:AFS Coverage?

[fm6]

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?

[quinto2000]

It's actually very popular, but in university settings. It was part of the first ever campus network.

Kerberos?

[zoloto]

I've heard of this before, but with all the lesser admin stuff I've done before I haven't had time to explore it, nor had the need to yet.

Can someone sum up what it is exactly?

Re:Kerberos?

[darth_MALL]

Sure

Re:Kerberos?

[Anonymous Coward]

If you don't learn to use Google, you're going to do lesser admin stuff for the rest of your life.

Or you'll be promoted to management.

Re:Kerberos?

[Daedala]

Kerberos was the three-headed dog who guarded the entrance to hell in Greek mythology. He could be bribed with honey cakes.

Re:Kerberos?

[einhverfr]

I assume you have a root account on your realm with the password of "honey cakes" or did you mean something else?

Re:Kerberos?

[Anonymous Coward]

troll? Are you guys kidding me? it was an honest question about the kind of authentication kerberos was. good work moderators, you deserve a smack in the head for that one.

Re:Kerberos?

[Daedala]

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.

Re:Kerberos?

[Anonymous Coward]

well, i've been in school for a while - haven't covered this stuff yet.

Re:Kerberos?

[Daedala]

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.

Re:Kerberos?

[einhverfr]

I got the reference ;-)

I was just wondering if the same trick would work on the three headed dog guarding your network... ;-)

Re:Kerberos?

[Anonymous Coward]

http://www.pantheon.org/articles/c/cerberus.html More random info.

Re:Kerberos?

[emurphy42]

When it's authentication time, Client goes to Ticket Grantor and says, "I want to talk to Server, and here's my key."

No, it just says "I want to talk to Server". Ticket Grantor then gives out a session key encrypted with Client's password. And now this next bit:

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

makes a lot more sense.

moD 0p

[Anonymous Coward]

result of a quarrel FAnatic known my bedpost up my 'Yes' to any outreach are unless you can work every chance I got

Kerberos Dialogue

[Anonymous Coward]

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

Not so bad

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

Re:Not so bad

[Anomalyst]

no result for cosign.org or co-sign.org and a vivisomo search is all about loans, not worth trying to find the needle in THAT haystack. Did you try your "Help...About"?

I POOP ON KERBEROS

[Anonymous Coward]

poop
|
|
v
kerberos

OpenSSH ...

[GNUALMAFUERTE]

I see OpenSSH as the best choice if you are in a Unix network. It's an incredible big, can-do-everything beast, so you can run just about any other service you want over it, from File transfers, to remote X11 displays. it's very flexible, and it integrates nicely in the unix environment. When you have to deal with non unix machines, it's not so easy or integrated, but then again, neither is kerberos, and there are a lot of good ssh implementations for Windows.

ALMAFUERTE

Re:OpenSSH ...

[GNUALMAFUERTE]

May someone explain why is this OFFTOPIC???.

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.

Re:OpenSSH ...

[einhverfr]

I should not feed the trolls.... But oh well....

OpenSSH is great for some things, but it does NOT do remote authentication for services, nor does it authenticate the service to the client. So it does not scale well.

Kerberos scales better and is more secure than OpenSSH for most things, I think. You can even use it along with telnet to provide a single-sign on remote shell with an encrypted session (without the key management issues of OpenSSH). Of course you can also use OpenSSH with Kerberos (requires a patch I think) but then that negates your point.

Also, it is *easy* to integrate Win2k and XP with Kerberos.

Re:OpenSSH ...

[einhverfr]

I would have modded it as a TROLL....

Mainly because SSH is not a network authentication protocol. It is a remote access protocol and this is fundamentally different.

Re:OpenSSH ...

[Homology]

May someone explain why is this OFFTOPIC???.

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.

Re:OpenSSH ...

[Anonymous Coward]

May someone explain why is this OFFTOPIC???.

Overrated would have been a much better choice, but I can see how offtopic works. Your "solution" has nothing to do with the topic, but I'm not going to spend all day explaining to you why.

Re:OpenSSH ...

[kenaaker]

I would say it was only slightly offtopic. OpenSSH is a collection of technologies, with the primary purpose being to set up communications pipes between systems. Generally, when it does authentication, it uses the underlying system authentication functions. That would be the /etc/passwd based authentication, NIS, LDAP, PAM, or what have you.

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.

Re:OpenSSH ...

[TheCabal]

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.

Re:OpenSSH ...

[wfberg]

OpenSSH is great for some things, but it does NOT do remote authentication for services, nor does it authenticate the service to the client. So it does not scale well.


If you store the keys you need to authenticate at other services in the .ssh directory of the server you log into first, then ssh authenticates you to other services..

Kerberos isn't particularly impressive at scaling, what with all those secret keys flying about.

Really, the only thing SSH doesn't do is authenticate the remote service to the extent that Kerberos would, although really the only benefit Kerberos brings is that it prevents some MITM attacks - it's still based on remote systems (working together) "proving" who they are by knowing a shared secret (your password).

Now, if Kerberos got hip to the 1990s way of doing things and started using public key encryption, you'd be on to something! In fact, combine PKI for SSO with something like XML and/or webservices, and hey presto, you've reinvented SAML and WS-Security.

Re:OpenSSH ...

[einhverfr]

If you store the keys you need to authenticate at other services in the .ssh directory of the server you log into first, then ssh authenticates you to other services..

Not really. It authenticates you to *a user account* on the *host system.* This is very different from authenticating to, say, and LDAP service, an HTTPS application, or a database manager. OpenSSH cannot readily do this. Sure you can use it for mining expeditions (lots of tunnels) but this does not approach problem in a reasonable manner.

Kerberos isn't particularly impressive at scaling, what with all those secret keys flying about.

It seems to scale better than the alternatives. I assume that this is why Novell, IBM, and even Microsoft use it for their larger-scale AAA systems. The reason is simply central management. You could try to hack something together using LDAP and SSH but the same issues exist regarding the fact that it doesn't really have a way to authenticate you to a centrally managed account from an application server's perspective.

Really, the only thing SSH doesn't do is authenticate the remote service to the extent that Kerberos would, although really the only benefit Kerberos brings is that it prevents some MITM attacks - it's still based on remote systems (working together) "proving" who they are by knowing a shared secret (your password).

No, actually, it protects you against modified replay attacks. MITM is a problem which can occur with SSH, SSL, and even Kerberos on the first time a key for a PKI server is received. This can be a X509 CA, and SSH server, or a Kerberos KDC.

OTOH, the fact that each ticket is signed and timestamped (and cached against playback), and each service (including the KDC) is authenticated to the client, there is no way to forge or replay the ticket unless the keys are compromised.

I do agree with your points regarding PKI but I am not really sure that there is a secure way to do this. It is a difficult problem (i.e. login requires the key which either must be cashed and then decrypted with a passphrase or be carried on the person of the user). This has its own dangers and is far from being perfect.

Re:OpenSSH ...

[einhverfr]

I have not compiled OpenSSH from source in a while so my knowledge could be out of date.

However, I see that we reasonably agree regarding the fact that Kerberos and OpenSSH address different needs and are not interchangable.

Re:OpenSSH ...

[Dop]

While OpenSSH can accept kerberos passwords, if you want to accept Kerberos tickets you'll still need a patch. We do it all the time, OpenSSH is just one of the many services on our network that use Kerberos for authentication.

Bad editing

[Dop]

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

[Anonymous Coward]

feelings hurt?

Re:Bad editing

[jayhawk88]

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

[sharkey]

Right. Do any of them appear in the Errata for the book?

Re:Bad editing

[Dop]

Yeah, I'm not looking for credit or money or anything, just acknowledgment that my attempt to be helpful was actually seen by a human. As it stands I'm less likely to send corrections in the future.

Although a Valentine's Day card would have been a nice gesture...

Re:Bad editing

[fm6]

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. If only they'd make their writers actually read it!

Re:Bad editing

[Anonymous Coward]

Maybe they could publish Writing Hacks! or a 700 page Writing in a Nutshell!

Re:Bad editing

[Anonymous Coward]

Granted I suppose a note of thanks from the author would have been nice, but what did you expect, Hallmark?

Can't speak for the original poster, but as one of the millions of people too lazy to do what he did, yes, I'd expect some sort of thank you.

Re:Bad editing

[chromatic]

If you used the errata form on the book's catalog page, your report went into a request tracking system which sends mail to the editor and the author. From there, both can suggest changes or corrections to make in the next printing or edition. When the next printing or edition comes due, the editor receives an automated message asking for a collection of changes -- conveniently tracked in the request tracker.

As far as I've seen, the system works. None of the books I've edited have gone in for reprint yet though.

Peace Making: The Definitive .... (+1, Patriotic)

[Anonymous Coward]

Guide

Patriotically as always,
K. Trout, CTO

Kerberos, it's not just for mammals anymore

[TheLoneGundam]

"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

[savuporo]

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

Re:PKINIT

[cpuh0g]

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

[TheCabal]

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

[cpuh0g]

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.

Re:PKINIT

[Anonymous Coward]

But does it work the other way around? I really don't know, I recall reading that you can change a registry value and it will accept standard kerberos as well - but I'm not too sure of that.

I'm rather wary of using Windows for authentication. All I keep on seeing is that Windows needs to be in control for the windows clients to work. Need DNS, well WE can do your DNS for you. Need DHCP, then WE will handle that too. Need Authentication, leave it to US. And by the end you are so tied up in one (somewhat inflexible) solution that there's no way out.

Re:PKINIT

[cpuh0g]

Windows needs to be in control for other Windows clients to work in a domain. For non-Windows clients, you can use AD or not use AD, you are not locked in. You can even point your windows box at a Unix KDC and most things will still work.

It is very commmon for AD to be used as the KDC for large enterprises because it is actually pretty well designed. It consolidates the naming service and the authentication service in an easy-to-manage package. Most Unix packages must have separate naming services and authentication services, which means alot of duplicate information being stored and duplication of admin work.

Uuh, kerberos is what?

[Rosco P. Coltrane]

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

Re:Uuh, kerberos is what?

[theguywhosaid]

(MS) Passport is a linux box in a redmond basement running kerberos.

Incase of Slashdotting...

[Anonymous Coward]

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)

Re:Incase of Slashdotting...

[Anonymous Coward]

His band is good, too.

Re:Incase of Slashdotting...

[PMJ2kx]

Or, this.

Re:Incase of Slashdotting...

[gardyloo]

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.

Re:Incase of Slashdotting...

[1u3hr]

After authenticating your-elf...

What about hobbits, or men, for that matter?

interoperability with windows/ active directory

[fakeid]

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.

Re:interoperability with windows/ active directory

[Piquan]

I'm confused. What does LDAP have to do with single sign-on? I thought it was just to manage directory information.

Re:interoperability with windows/ active directory

[Anonymous Coward]

you put the password db backend of ldap to be kerberos? not 100% on-topic, I know ...

Re:interoperability with windows/ active directory

[0racle]

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.

File that

[mccrew]

I see OpenSSH as the best choice...

File that one in the "When your only tool is a hammer everything looks like a nail" folder.

Single Sign-on needs more than kerberos

[ThinkTiM]

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

Easy answer

[ta bu shi da yu]

Moderators on slashdot are idiots.

SSO != Single Account

[DrZaius]

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

[0racle]

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.

Re:SSO != Single Account

[Orp]

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 idea how this can be done? I've googled far and wide and have not found an answer.

Leigh

Re:SSO != Single Account

[0racle]

how does one 'kerberize' a client
It has to be written to talk to kerberos.

Programmers Guide for Heimdal Kerberos.
Kerberized Kermit FTP Client

There are probably others.

Re:SSO != Single Account

[forlornhope]

Check out libsasl, libsasl2, libgsasl. They have the nessisary parts to do that. Though that may only be for servers. You may have to use the kerberos libraries. I've not done it, but that looks like a good place to start.

Re:SSO != Single Account

[LordMyren]

cant you use gssapi too/instead?

Re:SSO != Single Account

[0racle]

Yes. What is GSSAPI?

How does this relate to Kerberos? Included with most major Kerberos 5 distributions is a GSSAPI implementation. Thus, if a particular application or protocol says that it supports the GSSAPI, then that means that it supports Kerberos, by virtue of Kerberos including a GSSAPI implementation.

So whether you used Kerberos directly or used GSSAPI or SASL would simply depend upon your needs and how you intended to use advanced authentication. OpenLDAP uses KerberosV via SASL because SASL allows it to plug into other auth methods if needed, OpenSSH can use KerberosV via GSSAPI included with both Heimdal's and MIT's KerberosV implimentations.

Kerberos?

[null etc.]

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!

Unsure

[ta bu shi da yu]

Could have something to do with the way that Microsoft uses LDAP and Kerberos in their domain setups. The two are different things through.

Kerberos and OTP

[wkk2]

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.

Re:Kerberos and OTP

[Anonymous Coward]

Nor can you use Kerberos to authenticate for software that uses MSCHAP, MSCHAPV2, CHAP, MD5 or any other password hashing systems. You _must_ have a plaintext password.

This counts it out for use with many wireless 802.1x authenticaiton protocols.

Sigh.

Fetchmail, Linux, e-mail, Kerberos

[trip11]

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

Re:Fetchmail, Linux, e-mail, Kerberos

[Anonymous Coward]

No, the correct reaction here is down with fetchmail.

Re:Fetchmail, Linux, e-mail, Kerberos

[cpuh0g]

The key problem is that there is no standard Kerberos programming API. The MIT implementation is very popular but even it is not completely standard. Heimdal is also popular, but the programming interface is different.

Fetchmail probably chose to implement their Kerberos authentication using some deprecated APIs that are no longer supported. So, "Boo, Fetchmail" for being shortsighted.

The solution is to program to GSSAPI (which is an IETF standard) and use the Kerberos mechanism as the security provider. This makes your application portable and ties it to a known standard rather than depending on a specific release of a non-standard implementation.

Re:Fetchmail, Linux, e-mail, Kerberos

[daniel de graaf]

Iowa State's mail servers uses Kerberos 4, not 5. Don't know why, but it does. I am able to get fetchmail working here, compiled on Debian with fetchmail-6.2.5 and the kerberos4kth-dev package. See http://wiki.amesfug.org/AmesFUG/IsuHints/Kerberize dMail.

Just Three?

[exp(pi*sqrt(163))]

Hesiod disagrees:

...a monster not to be overcome and that may not be described, Cerberus who eats raw flesh, the brazen-voiced hound of Hades, fifty-headed, relentless and strong

Re:Just Three?

[Daedala]

Yeah, but that's Hesiod. Who believes Hesiod over Virgil?

Yeah, pure DoS

[swanswan]

At 272 pages, it DoSes too much spare time. An that Kerberos name sounds !EVIL!

Does it address UNIX - AD using KerberosV?

[Wintrmte]

Just curious if it actually talks about how to get clients using MIT Kerberos 5 on *NIX to authenticate against an W2K or W2K3 AD DC.

This has been my biggest challenge thus far with interoperability of KerberosV..

Re:Does it address UNIX - AD using KerberosV?

[TheCabal]

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

Re:Does it address UNIX - AD using KerberosV?

[cpuh0g]

Wow, if that is challenging for you, how much time does it take you to tie your shoes?

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.

Re:Does it address UNIX - AD using KerberosV?

[TheCabal]

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.

Re:Does it address UNIX - AD using KerberosV?

[Anonymous Coward]

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

Re:Does it address UNIX - AD using KerberosV?

[Anonymous Coward]

Wow.

Re:Does it address UNIX - AD using KerberosV?

[Wintrmte]

Actually, it's a lot more difficult than that. I'm able to get my credentials from AD when I kinit, but if I use OpenSSH 3.9p1 compiled with Krb5 I get an ASN.1 encoding error.

Care to enlighten me on that, oh mighty one?

Re:Does it address UNIX - AD using KerberosV?

[cpuh0g]

Perhaps the patches you applied for OpenSSH are not entirely correct and cannot properly handle the large tickets that AD issues.

This is a much different problem from the parent post which said (basically) "I can't get my unix KRB5 to work with Active Directory."

Excuse me?

[elwoodblues16]

Everyone knows that Kerberos is the biggest solution to the single sign-on dilemma.

Not really. In fact, I have no idea what you're talking about.

Re:Excuse me?

[dbIII]

Everyone knows that Kerberos is the biggest solution to the single sign-on dilemma.

Not really. In fact, I have no idea what you're talking about.

He's the little teddy bear with wings that gaurds the clow cards - or the other mythical beast - or the authentication system.

GlobusSingle Sign on

[nr]

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/developmen t/4.0-drafts/GT4Facts/index.html/
http://www-unix.globus.org/toolkit/docs/developmen t/4.0-drafts/security/authzframe/index.html/
http://www-unix.globus.org/toolkit/docs/3.2/index. html#security/
http://www.globus.org/

Re:GlobusSingle Sign on

[nr]

Sorry the links got screwed up, remove the trailing slash (*ugh* wheres the edit function then you need it!).

Re:GlobusSingle Sign on

[jd]

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, Globus is probably the best choice.

I would never have thought of it as an efficient mechanism for single-sign-on, but I guess it would work. The main problem I would have with it is that it is unicast, which means that if you have a particularly large or complex grid, you'd have a lot of excess replication of data and an unnecessary network overhead.

What you'd really want for a SSI system is a reliable multicast mechanism for distributing the security tokens. That way, when you log in, you log in on every machine simultaneously. The session would merely not be activated until you attached to that specific machine.

Re:GlobusSingle Sign on

[nr]

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 base working in a heterogenious environment with a multitude of platforms like Linux, Solaris, HP-UX, Tru64, AIX, IRIX and even exotic ones like Cray Unicos you will appreciate the convenience and ability to just execute the darn code without having to fiddle around with recompilations, incompatible librarys, etc. I belive Java was introduced 10 years to early for it's own good, computer technology was'nt ready for it, giving it a bad reputation in most peoples mind as being a slow resource hog (it's all relative right? what does run slow on a 5 year old PII 450 Mhz may run very fast of a brand new P4 3.8 GHz). It's all by design, the designers of the Java language did purposely sacrifice some performance and resource usage to gain hardware and operating system independence and higher level abstraction ("virtualization").

The dependency on MPICH is due to the use of a modified version called MPICH-G3, basicly a bunch of patches to standard MPICH to integrate it with the resource manager GRAM. In order to use a vendor provided MPI, one has to run the jobs thru a batch-job scheduler as LSF/Condor, then the scheduler handles the communication with the RM.

Globus uses proxy certificates much like SSH does for single sign-on. Multicast may work nice inside a specific organization (a university, a research center, etc) but for inter-organizational authtentication I do not think multicast is a viable alternative.

Re:GlobusSingle Sign on

[jd]

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.

In other news: Fire, Hot, Sissors, Sharp!

[DarthVain]

Someone explain to me how this is news?

(I did write an elaborate message but it got toasted, so this is all you get.)

Kerebos and PicoJava/8255

[Anonymous Coward]

One of the most elegent implementations of Kerebos is on the 8255 using PicoJava. I strongly urge anyone with an interest in the subject to look up Dr. Kamal's paper describing it.

in one word - NAT

[timmarhy]

NAT breaks kerberos making it useless in many situations.

Re:in one word - NAT

[cpuh0g]

Wrong. Use addressless tickets. Problem solved.

Re:in one word - NAT

[Anonymous Coward]

Which is the "it" of which you speak.

If you mean "NAT is useless in many situations", I must agree. That braindead violation of routing protocols just to keep users off the internet (i.e. can't serve web pages without paying their ISP twice) really should die.

Kerberos, as well as any other program that NAT breaks, is not broken just because your router lies.

Re:in one word - NAT

[finkployd]

When was the last time you used it? '96? The convention regarding Kerberos has been to use addressless tickets for a long time now.

Re:in one word - NAT

[agraupe]

Well, if NAT didn't exist there would be an extreme shortage of IP addresses (although IPv6 would have been completely adopted by now). Also, I can serve web pages via port forwarding. What do you say to that?

Re:in one word - NAT

[timmarhy]

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?

Re:in one word - NAT

[cpuh0g]

That warning is complete BS.

There is little or no security benefit from adding addresses to Kerberos tickets. I have not seen this particular warning, but it seems like they are totally misrepresenting the threat.

Basically, there is no security risk in using addressless tickets and it certainly does not open the system up to the KRB4 weaknesses, which are completely different.

Re:in one word - NAT

[finkployd]

what apart from the big fat security warning in the hemdail docs concerning addressless tickets???

First up, let's get one thing straight. Heimdal is a throughly shitty impletmentation of Kerberos.

something to the effect "don't use addressless tickets because it opens you to the same weakness as using kerberos4"

Total BS, another reason to avoid Heimdal (they seem to not understand a lot about Kerberos).

Finkployd

You are basically as stupid as a human can be

[Proctal Relapse]

"WAAAH, I can't get fetchmail to work with Kerberos, it must be Kerberos' fault!!"

how about you put down the amyl nitrite, unwedge the cock from your jaws and read the fucking manual? or, failing that, get a senior admin on the case? I got fetchmail and krb5 working together in about one hour, back in 2000, starting from scratch. that is to say that in sixty minutes, I had krb5 compiled, installed, I had a realm up and running, and I had fetchmail working with the whole thing. go kinit a revolver with a few bullets, kdestroy your cerebellum, and leave us the fuck alone with your bullshit. jesus.

Re:You are basically as stupid as a human can be

[Anonymous Coward]

Interesting insight. Judging by your overt expression of written rage, it appears that even the average slashdotter gets laid more than you do.

Since you are astute at pointing out the intelligence of others, I thought you should know that you ended the sentence in your subject line with a preposition, you dumbass.

Bad HTML alert

[fm6]

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.

Re:Bad HTML alert

[19thNervousBreakdown]

Displays fine for me (FF 1.0). It's not even a particularly long table, it's broken up into 4 separate tables.

Re:Bad HTML alert

[marc_moore]

I hate it when authors put too much text in the body tag, too.

Sounds like bad FireFox code.

Re:Bad HTML alert

[fm6]

You have a more adept eye than I (excuse the pun). FF divides the table into two equal columns, making it difficult to connect the speaker with the dialogue. For me, anyway.

Firefox's "bug" here is that it doesn't try to make a column with unspecified width as narrow as possible. Or at least it doesn't try hard enough in this case. That's not really a bug, since no HTML specification requires a browser to do that, even though most browsers do. A classic case of coding to the browser instead of the specification.

Re:Bad HTML alert

[tawhaki]

Konqueror has no problem at all rendering that page. I can't test with Firefox, as I don't have that installed.

Re:Bad HTML alert

[Anonymous Coward]

I hate it when authors put too much text in the body tag, too.

So do I. It means the text is unreadable in every web browser ever written.

Please learn the difference between "tag" and "element".

Re:Bad HTML alert

[NutscrapeSucks]

+ The page is from 1998, before IE took over the market.
+ Firefox renderes it identically to Netscape 4.8
+ The document was "converted to HTML by Theodore Ts'o" (who is a Linux Kernel developer).
+ It is a document targeted towards UNIX users.

Not exactly where you'd expect IE-oriented HTML, eh?

One has to conclude that Firefox is rendering it to the author's intentions, and that IE is doing it 'wrong' -- but just happens to be more readable.

Plus, I'd argue that this is a perfect use of table, as row/column information is a bitch in pure CSS.

Re:Bad HTML alert

[Anonymous Coward]

Plus, I'd argue that this is a perfect use of table, as row/column information is a bitch in pure CSS.

Rows and columns are a doddle in CSS. display: table-cell. It's a little more unwieldy in CSS-minus-everything-Internet-Explorer-screws-up, but a long way away from being "a bitch" - just float and clear the names to the left and set a width.

Re:Bad HTML alert

[fm6]

CSS does have some usability issues. And it is difficult to do real tables in CSS. But that's irrelevent for two reasons: (a) this isn't a real table; (b) a simple flow like this is not very hard in CSS.

You do have a good point about the date. Seven years ago, using tables was pretty much the only way to do this kind of layout.

Good book, but less quality that O'Reillys best

[TilJ]

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

Re:Good book, but less quality that O'Reillys best

[archen]

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.

Re:Good book, but less quality that O'Reillys best

[Anonymous Coward]

Jesus. One of the sheep, blaw, blaw, blaw, blaw, Microsoft sux, blaw, blaw, blaw, blaw... The only other thing you say is that you don't understand the alternative! My, you have so much to add!

Re:Good book, but less quality that O'Reillys best

[Anonymous Coward]

And WHERE did I say Microsoft sux? One of the sheep? Look in the mirror.

Re:Good book, but less quality that O'Reillys best

[bloo9298]

Are you looking specifically for Kerberos on Windows, or Kerberos in general? If the former "Secure Networking with Windows 2000 and Trust Services" is surprisingly good. If the latter, get the Kerberos RFCs and read the MIT source code...sorry.

hmmm

[c0p0n]

but... aren't you scaried about that thingie called KERBEROS? I mean, imagine that you ecounter some guy called PANTOCRATOR on a dark back alley or something...

fuck you

[Anonymous Coward]

you godawful fuckin' moron! i understand you don't read the freaking article, but could you, at least, read the first few lines?? For crying out loud, it's a book review in a few paragraphs - hell, you don't need to click through to get to the article.. just keep staring blank-faced at your screen like the idiot you are...

what is wrong with this world?

Re:fuck you

[Anonymous Coward]

You

OpenLDAP = Some Assembly Required

[xxxJonBoyxxx]

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:OpenLDAP = Some Assembly Required

[stuntpope]

I don't have OpenLDAP available to me right here, but I believe both groups and the email attribute for people is in the OpenLDAP core schema.

Symmetric key vs public key

[j1m 5n0w]

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.

Re:Symmetric key vs public key

[bloo9298]

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 might be used offline. There is still the hard problem of someone convincing the root authority to certify an untrustworthy public key, but at least it is difficult for attackers to reach the private key via a network attack.

One of the mildly alarming things about Kerberos is the use of service and host keys, stored on hosts other than the KDC. They are used to authenticate a server (maybe a telnet server) when a client connects. The Kerberos designers targeted environments where hosts are secure from physical attack. It is not clear that everyone deploying Kerberized services understands that. I am not criticizing the Kerberos designers or Kerberos itself, just suggesting that it is sometimes used in inappropriate circumstances. Not that there's much that you can do to authenticate machines/servers without physical security or tamper-resistant hardware that you consider trustworthy.

Defacto - yeah right...

[xxxJonBoyxxx]

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 Toolkit 3.2 Key Concepts (not yet available)"

True, but irrelevant

[Theatetus]

OpenSSL, while nice, is transport-level. The secure communication provided by OSSL does nothing to authenticate a given user or service. Now, Kerberos has and needs transport-level security, it just doesn't use OpenSSL to do it. You could, conceivably, re-write something like Kerberos using the public-private key model (which would solve some of the dilemmas in Kerberos design and introduce new ones), but that would be re-inventing a pretty big wheel.

Personally, I use SSL to fake authorization on my network (this assumes secure hardware and some other things; no solution is foolproof; YMMV; etc.), so you can see where I fall on that debate.

Apples and oranges...

[rmdyer]

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?

Re:Apples and oranges...

[Anonymous Coward]

Wrong ! LDAP is a protocol used to access directories - Lightweight Directory Access Protocol. I believe it was base upon an ISO standard X.509 or some such thing.

Re:Apples and oranges...

[bloo9298]

Wrong ! LDAP is a protocol used to access directories - Lightweight Directory Access Protocol. I believe it was base upon an ISO standard X.509 or some such thing.

To the AC: LDAP is derived from the X.500 directory work. X.509 is the authentication framework part of the X.500 work. X.509 includes a definition of public-key name certificates using the X.500 naming convention. If you want to find out more, search for the online book "Understanding X.500 - The Directory".

As to your reply to rmdyer, I think you might as well teach your grandmother to suck eggs.

The whole puzzle, a challenge for Open-Source.

[Hurderos]

Its good to see any type of book come out on Kerberos. Besides setup, configuration and management an even bigger challenge is programming to the API although GSSAPI/SASL is supposed to alleviate this problem for some definition of alleviate.

The whole arena of Single-Sign-On (SSO) is at once a great opportunity and a great challenge to the Open-Source community. Unfortunately its also an arena where Open-Source initiatives seem to be slow in getting traction. In part this may be due to the fact that this type of work isn't very sexy. Unfortunately its also the area where control of the enterprise is going to get won or lost.

Anybody who has been around Kerberos, SSO and other middleware initiatives know the frightful politics involved with this stuff at the organizational level. When technology like this gets deployed its extremely difficult to get organizations to change direction or try alternative solutions. The case can be made that the SSO middleware/identity solution that gets deployed is perhaps the single most important decision affecting the overall IT architecture of an organization.

The issue that makes all this extremely important to the Open-Source community is the fact that whatever gets deployed tends to 'tie' the applications to the back-end server architecture. I don't think this fact is even remotely lost on those individuals or companies that prefer to see proprietary systems win control in the enterprise. Ultimately whoever or whatever defines who an individual is and what rights they have to access information has a pretty significant position of power in the information delivery world.

The basic tools exist in open-source form but tend to have extremely high individual learning curves and little margin for error once deployed. Whats required for Open-Source to win in this space is a credible integration of these technologies which allow them to be deployed and managed in a coherent and consistent fashion.

At the risk of getting in a plug the Hurderos Project is focused on these issues right now. Our goal is to provide an open-source based solution which is a superset of the functionality provided by Active Directory. The project web-site is at http://www.hurderos.org for anyone interested in learning a bit more.

One of the issues that the project has extensively focused on is developing an open-source/open-protocol alternative for authorization. Its fair to conclude that Kerberos answers the authentication problem but an even bigger issue is authorization, which is really the question that most people want answered at service delivery time.

Everyone concludes that LDAP directories should be used for authorization but no real methodology is articulated for doing this. The only real 'standard' unfortunately is Microsoft's use of Privilege Authentication Certificates (PAC) in Active Directory. Providing an authorization alternative to these is really at the heart of the project.

The Samba project is working diligently to provide an open-source alternative to Active Directory. Unfortunately this goal is potentially problematic from a couple of angles. The first being philosophical and the second much more pragmatic.

From a philosophical perspective the claim can be made that Open-Source doesn't innovate but rather clones. Thats certainly a topic for arguement in and of itself but an unbiased observer would have to conclude that 'cloning' has been a major focus of Open-Source initiatives. Cloning Active Directory, while useful, tends to perpetuate this notion.

A clone of Active Directory is also problematic in the increasingly troubled legal waters that OSS initiatives will be steering through. Casual infringement of Intellectual Property will be problematic in and of itself. I would anticipate that it will be much more difficult to defend when the stated goal is to create a working clone of another product.

The huge opportunity for Open-Source is to fix a fundamental problem that has vexed enterp

Everyone with basic technical knowledge.

[Anonymous Coward]

Admittedly, that's a far cry from everyone.

SSH != SSL

[Anonymous Coward]

Einstein!

Obligatory Devil's Dictionary MisQuotation

[Anonymous Coward]

Cerebus (Kerberos):
The watch-dog of Hades, whose duty it was to guard the entrance -- against whom or what does not clearly appear; everybody, sooner or later, had to go there, and nobody wanted to carry off the entrance. Cerberus is known to have had three heads (Metrodorus, Isadorus and Theodorus, or MIT for short), and some of the poets have credited him with as many as a hundred. Professor Graybill, whose clerky erudition and profound knowledge of Greek give his opinion great weight, has averaged all the estimates, and makes the number twenty-seven -- a judgment that would be entirely conclusive if Professor Graybill had known (a) something about dogs, and (b) something about arithmetic.

Sorry, this isn't enough for a true SSO solution

[totro2]

I have to say I highly doubt this book will get effectively get Kerberos "everywhere". Not even close. Only once a new layer of administrative convenience is painted over Kerberos (and OpenAFS, OpenLDAP, which all together make something tremendously useful), will Kerberos ever matter.

I've been a Unix System Administrator for 4 years, and trust me, I would love to see Kerberos, OpenAFS, and OpenLDAP are to get together in a convenient way.

All three are extremely flexible and therefore complex systems. Sadly, there are no best practices that clearly show a "best standard" way to integrate them all to truly be that silver bullet SSO system for the all-singing, all-dancing universal access to local login, distributed filesystem, email, web, etc.

Why should you believe me? Case study: I know of one commercial product that does sucessfully combine these three into a worthy-of-geek-praise general solution/product: the "bkbox" (www.bkbox.com).

I've met and spoken to the main developer (Noel Burton-Krahn) several times. And no, I don't work for him. He's got a Masters in Computer Science and it took him many months FULL TIME to truly understand these three and integrate them. Only by using low level tools like "strace" and combing the mailing lists did he finally understand enough to combine these three into a server where both Linux and Windows clients could connect in various ways (including web and email). This goes to show the complexity and obviously poor documentation out there.

In summary: Kerberos, OpenAFS, and OpenLDAP are intensely complex, poorly documented (for use in real-world scenarios), and are therefore years away from being on the LAN of Joe Linuxnut, much less the nearest elementary school computer lab.

I think that there is a huge oppurtunity for fame by creating a layer of convenience on top of these 3 that actually make a best-practices SSO solution a snap. Will it be implimented as a webmin module? Some simple Wizards in Gnome or KDE? A Plone Product? Using D-bus?

I hope someone can prove me wrong.

Isn't anyone ever going to cover...

[Anonymous Coward]

Wang: The Definitive Guide

Biggest is bestest

[Anonymous Coward]

It's cool when you have the biggest solution. Until someone comes up with a bigger solution.

Re:Sorry, this isn't enough for a true SSO solutio

[Anonymous Coward]

This proves his shiny master doesn't count for much, considering how easy we set it up here for 4000 computers, mixed Linux/Solaris/FreeBSD/Windows, eh?

Links

[darkpurpleblob]

Obligatory book website and sample chapter links.

Re:The whole puzzle, a challenge for Open-Source.

[bloo9298]

Christ on a bike, this is the most insightful post in the whole discussion (although there are many good technical replies) and yet it is ignored!

You have set yourself a difficult task though, both technically and in terms of selling your solution to the rest of the world. Good luck!

Re:The whole puzzle, a challenge for Open-Source.

[Anonymous Coward]

I am interested in your project, and I just modded you up.

But you don't seem to have a mailing list, and the most I could find are a few announcements on the kerberos list.

Please contact me at mfedyk@matchmail.com

There was also a mention of Hurderos on the OpenAFS-dev list that pointed me in your direction.

Mike