f



"Stored master key is corrupted while initializing kadmin.local interface"

Howdy folks,

I'm running an MIT KDC for two small realms (a few dozen principals
each) on FreeBSD 4-STABLE for i386. I haven't tried to manipulate any
principals via the kadmin interface ia a while (probably two weeks), and
when I tried it recently I ran across an unusual problem: kadmind wasn't
running.

Thinking that that was unusual, but not a bit deal, I attempted to fire
up kadmind:

# /usr/local/krb5/sbin/kadmind -r SEEKINGFIRE.PRV
kadmind: Stored master key is corrupted while initializing, aborting

Oh, that's not good. So I tried via via kadmin.local (which should give
the same result, I know):

# /usr/local/krb5/sbin/kadmin.local
Authenticating as principal tillman/admin@SEEKINGFIRE.PRV with password.
kadmin.local: Stored master key is corrupted while initializing
kadmin.local interface

That's definitely not working. krb5kdc is running and working fine, but
without kadmin I'm probably headed for trouble :-)

So I thought I'd try my other realm. I skipped the kadmind and went
straight to kadmin.local:

# /usr/local/krb5/sbin/kadmin.local -r ROSPA.CA
Authenticating as principal tillman/admin@SEEKINGFIRE.PRV with password.
kadmin.local: Stored master key is corrupted while initializing
kadmin.local interface

Note that this realm is on the same server, but has it's own directory
and it's own stashed master key (.k5.ROSPA.CA versus
..k5.SEEKINGFIRE.PRV).

I have multiple copies of both on-line and tape backups of the stashed
master key ... and the md5sum on all of them agree with each other (and
the "real" version!). Both the tape and on-line backups have versions
ancient enough that they predate this problem by months.

Any ideas as to what might be causing this or how I might go about
trouble shooting it?

-T



Background information:

[root@pluto sbin]# uname -a
FreeBSD pluto.seekingfire.prv 4.9-RC FreeBSD 4.9-RC #0: Tue Sep 30 23:40:54 CST 2003 toor@athena.seekingfire.prv:/usr/obj/usr/src/sys/PLUTO  i386

[root@pluto sbin]# portversion -v | grep krb5
krb5-1.3.1                  =  up-to-date with port

(I upgraded from 1.2.x semi-recently - I suspect the upgrade may be part
 of the problem, though I cna't justify that feeling empirically.)


-- 
"The real question is not whether machines think but whether men do."
	- B. F. Skinner, _Contingencies of Reinforcement_
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

0
10/27/2003 5:50:23 PM
comp.protocols.kerberos 5541 articles. 1 followers. jwinius (31) is leader. Post Follow

2 Replies
479 Views

Similar Articles

[PageSpeed] 48

Did you upgrade from 1.2.x to 1.3.1 between now and when things
stopped working?  If so, the default master key enctype for 1.3.1 is
different from the enctype for 1.2.x.  So you may need to explicitly
specify the master key enctype in your kdc.conf if you have an old
realm.


________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

0
hartmans (370)
10/27/2003 7:24:11 PM
On Mon, Oct 27, 2003 at 01:25:20PM -0500, Sam Hartman wrote:
> Did you upgrade from 1.2.x to 1.3.1 between now and when things
> stopped working?  If so, the default master key enctype for 1.3.1 is
> different from the enctype for 1.2.x.  So you may need to explicitly
> specify the master key enctype in your kdc.conf if you have an old
> realm.

It's entirely possible and quite likely, though I don't know for sure as
I only discovered the problem yesterday.

Would you point me to a URL to an archived post or a "heads-up"
announcement that I could take a look at for the kdc.conf changes? From
the man page I'm guessing that the tag I want is 'master_key_type' and
that it goes in the '[realms]' section, but I don't know what the old or new
types are.

Thanks,

-T


-- 
Laws to suppress tend to strengthen what they would prohibit.  This is the fine 
point on which all the legal professions of history have based their job 
security.
	- Bene Gesserit Coda
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

0
10/27/2003 7:54:41 PM
Reply: