[2245] in Kerberos-V5-bugs
Re: "Miscellaneous RPC error" with beta7
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Wed Sep 18 11:23:32 1996
Date: Wed, 18 Sep 1996 11:23:04 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: Nick Kralevich <nickkral@porsche.autobahn.org>
Cc: Barry Jaspan <bjaspan@MIT.EDU>, krb5-bugs@MIT.EDU,
"Benjamin
C. Craft" <bcraft@bcraft.camd.lsu.edu>
In-Reply-To: [2244]
Nick,
I believe I know what is causing your problem. If you configure
kadmind (via kdc.conf) to send logging output to stderr, such that the
debugging information from the RPC library and the logging output were
interspersed, I believe you will see something like this:
gssapi_seal_seq: failed
GSS-API authentication error sealing sequence number: The context has expired
GSS-API authentication error sealing sequence number: No error
Sep 16 09:51:09 Miscellaneous RPC error: 206.79.223.2, internal error
sealing sequence number
"Context has expired" means the GSS-API context has expired, which
means the Kerberos tickets on which the context is based have
expired. This is happening to you for the same reason I just
described on the Kerberos mailing list: there is a bug in KADM5 such
that if you do not set max_life in kdc.conf, it defaults to zero,
which means "no lifetime."
The bug in KADM5 has been fixed for the next release. In the mean
time, you need to add "max_life = 8h 0m 0s" (or whatever max_life you
want) to kdc.conf, and then either destroy and re-create your
database, or just run kadmin's modify_principal command on all your
existing principals to explicitly re-set their max_life to a non-zero
value.
The fact that you had to enable debugging information at compile time
to discover the actual source of the problem is also a bug; kadmind
should have a way of reporting GSS-API errors from the RPC library
directly. This will also be fixed.
Barry
