RE: Heimdal with Solaris 8 clients, amonst other things

["Tim Bishop" <tim-lists@bishnet.net>]

> -----Original Message-----
> From: Johan Danielsson [mailto:joda@pdc.kth.se]
> Sent: 16 April 2002 16:49
>
> "Tim Bishop" <tim-lists@bishnet.net> writes:
>
> > The Solaris 8 client only wanted to offer des3-cbc-md5
>
> What client software is this? DES3 with MD5 is somewhat non-standard.

Whatever comes on Solaris 8 by default. I believe it's the SEAM client side
bits, which is derived from the MIT kerberos 5 implementation.

DES3 with MD5 did seem odd. In fact, we only got there by a bit of fiddling.
I've actually told the Solaris 8 client to use "des3-cbc-sha" (not
des3-cbc-sha1) but according to heimdal it's sending "des3-cbc-md5". I can't
seem to get it to send any other des3 types.

> > This seemed to work, but then we had problems with the krbtgt
> > principle not having that key. We tried everything we could think of
> > to add it, but to no avail.
>
> There should be an add_enctype command. In the mean while, you can do

kadmin> add_enctype
Unrecognized command: add_enctype
kadmin>

This would certainly be a useful and welcome addition :)

> something like this:
>
> # kadmin -l dump | grep krbtgt > foo
> # cat foo
> krbtgt/FOO.SE@FOO.SE
> 1::1:d602fd7f9de0c4c4:-::2:d602fd7f9de0c4c4:-::3:d602fd7f9de0c4c4:
> -::16:efa1d3b00e3e976de6ec7061f1139754a761ceaec74fad08:-
> 20010918072107:kadmin/admin@FOO.SE
> 20010918072108:kadmin/admin@FOO.SE - - - - - 126 -
> # string2key -5 -p krbtgt/FOO.SE@FOO.SE -k des3-cbc-md5
> Password: <just enter some random stuff here>
> Kerberos v5 key: d3da0e73b0b09bc157b05b6e6279d5d6234564d0ce6167a7
>
> Now change the entry by adding
> ::5:d3da0e73b0b09bc157b05b6e6279d5d6234564d0ce6167a7:-
> to the end of the second field. And then doing
> # kadmin -l merge foo
>
> Just to be safe, you should probably save a copy of your database
> (with kadmin dump or similar) before doing this.

Thanks. Although somewhat messy, it'd only be a one off event.

> > We thought we'd set one up, but when we moved the m-key file out of
> > the way the KDC still started. What's the correct way to make sure
> > our database is secured with a key?
>
> I'm not entirely sure the KDC actually checks if the keys are
> encrypted or not, but if they are and there isn't any master key file,
> ~nothing should work. I'll make the KDC complains in this case.
>
> If you check the output of the dump command above, the :: part of the
> keys are the mkvno the key is encrypted with, and :: means it's
> unencrypted.

Mine has a '1' between the ::. I guess this should imply it's encrypted?
However moving the key out of the way doesn't cause any problems starting
up. Again, more debugging output might be useful.. eg: "using master key to
decrypt database".

> Hope this helps.

Thanks for a prompt response.

Cheers,
Tim.


--
Tim Bishop (T.D.Bishop@ukc.ac.uk),
Computer Science Computing Officer,
University of Kent at Canterbury.
http://www.cs.ukc.ac.uk/people/staff/tdb/