On Tuesday, May 16, 2006 06:40:29 PM -0400 Jeff Blaine <[EMAIL PROTECTED]> wrote:
> Yes, MIT k5 1.4.3 > > The only Solaris piece I ever expect to use is pam_krb5.so > > I've yet to touch/test Linux + K5, but it will be promptly > after I find most of the hiccups with Solaris + MIT for > now. Then it's on to Cyrus IMAP integration and other > fun stuff. > > Maybe I'm just sore about it, but perhaps something should > be mentioned about this in the docs? I can't really wrap > my head around how this bit me and there wasn't a pile of > of mailing list archive chatter by other people being > bitten (when I searched before posting...). That is, I > don't see that I am doing anything rare here. I'm trying > to use MIT K5 as a KDC in a homogenous environment. Out > of the box, I got bit the first time I touched anything > that didn't come from MIT. If nobody finds that bad, > so be it -- I'm not going to drag it out further. The problem is not that you touched something that didn't come from MIT. The problem is that you have software that is old, and doesn't support as many enctypes as newer software. When you added an entry for that service to the Kerberos database, you gave it keys for enctypes the server software doesn't actually support. Neither kadmin nor the KDC have any way of knowing this, other than you telling it. An easy approach that solves this problem most of the time is to make sure that the tools you use to register a service in the Kerberos database are from the same software distribution as the service itself. That way, they'll support the same set of enctypes and no one will get confused. Unfortunately, this doesn't work all the time, for several reasons. Nico alluded to an issue with Solaris 9's kadmin which requires that the KDC go to some effort to recognize that particular client and do the right thing. More generally, the kadmin protocol is not standardized, so there is no guarantee that any client will work if it didn't come from your KDC vendor. That's something I hope to see change, eventually, but that depends a lot on the availability and willingness of people to do the work to define a standard admin protocol. In the meantime, recent versions of Solaris and MIT kadmin interoperate, but only because those parties have gone to some effort to make it so. And of course, life gets fun when you have multiple software versions that will share a service key For example, if you plan to use Sun's pam_krb5 and also run some other telnetd or sshd on the same machine, you need to make sure the host principal only has keys of types supported by all of those services. To some extent, this becomes a matter of understanding exactly what's going on, and going to some effort to get it right. It'd be nice for it to all Just Work(tm), but in this case it turns out to be tricky to get all the edge cases right. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA > Here's a bug, too :) > > kadmin.local: ktadd -e des-cbc-crc host/noodle.foo.com > ktadd: Invalid argument while parsing keysalts de Well, I can't speak for MIT, but I seem to recall that at least at one time, the error reporting in this case had some problems. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
