[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Heimdal with Solaris 8 clients, amonst other things

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

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

> 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

Hope this helps.