Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC

[Jeffrey Hutzelman]

On Tuesday, May 16, 2006 06:40:29 PM -0400 Jeff Blaine 
<jblaine at kickflop.net> 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) <jhutz+ at cmu.edu>
   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) <jhutz+ at cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA