[6951] in Release_7.7_team
Kerberos authentication problems in Keyserver project
daemon@ATHENA.MIT.EDU (Alex T Prengel)
Thu Sep 9 18:22:23 2010
From: Alex T Prengel <alexp@MIT.EDU>
To: release-team@mit.edu
Cc: alexp@mit.edu, ghudson@mit.edu
Content-Type: text/plain; charset="ISO8859-1"
Date: Thu, 09 Sep 2010 18:22:16 -0400
Message-ID: <1284070936.3527.26.camel@dit>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Hi,
I'm wondering if anyone on release-team can shed some light on an
intermittent problem the KeyServer pilot project is having with Kerberos
authentication for keyserved applications, or point me to a better place
to ask this.
The symptom is that at random intervals of one to several weeks, the
KeyServer's Kerberos authentication module locks up, and users
attempting to launch keyed applications get error messages like:
KeyAccess could not log on to KeyServer because the authentication
process failed during negotiation with the server.
Stopping and restarting the KeyServer process seems to clear this
condition until it occurs again.
Sassafras Software tech support tell us:
> it looks like kerberos (on the server) has gone AWOL. The log shows
> successful logins all through August and the first part of
> September,
> then today at 16:22 (presumably when users were being denied) there
> is a stream of these errors:
>
> gss_accept_sec_context (507) failed (851968, -1765328213)
> status: Generic unknown RC/IO error
>
> Error code -1765328213 is KRB5_RC_IO_UNKNOWN, might be a catch-all
> error code. Google doesn't find much other than some mention of the
> credential cache code. Since this is a Kerberos (GSSAPI) error
> there
> is little we can do about it in our code. And since the error is
> not
> specific I don't have a suggestion for how to fix the problem other
> than to note that restarting the process seems to clear the condition.
> From what I can tell the error is local to the KS host and has
> nothing to do with the (remote) Kerberos server or the (remote) KA
> clients. KS, like all Kerberos clients, links with the GSSAPI/
> Kerberos libraries where much of the real work is done. These
> libraries maintain a large internal state on behalf of the calling
> process, and this is where the problem must be happening.
> Restarting
> the KS process clears out the Kerberos library's (bad) state and
> creates a nice new working state.
The server host is a VM running RHEL 5.2; the libgssapi rpm is
libgssapi-0.10-2.
Thanks,
Alex
