Re: gssapi problem

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yves Dorfsman <address@hidden> writes:

> In our environment, a lot of the clients are on MS Windows, and
> gserver works fine. But when they do not logout of MS Windows for a
> few days, they get the following error message when they try to update
> or commit:
>
> "GSSAPI authentication failed: No credentials are available in the
> security package"

I would expect this kind of error at such time as the
ticket-granting-ticket (TGT) expires or if the cache has been deleted by
some other process for some reason.

> If they log out and back in from MS Windows, then it works fine with
> gserver again. It doe not happen with any other software, only with
> CVS.

I have never used an MS Windows Kerberos environment.

Are you certain that the other software is really using GSSAPI?

It is entirely possible that the other software has a cache of the
user's password and/or is not reauthenticating on every connection as is
done by CVS. For example, just mounting a file share may never be
reauthenticating itself with the server.

> Anybody has seen a behaviour similar to this ?

For only CVS? No. I have not seen this occur with only CVS executables.

I have seen the kind of error you mention when the current credentials
could not be renewed on the KDC or when the KDC policy had a hard time
limit on authenticated credentials which had expired and not been
renewed.

If the ticket-granting-ticket (TGT) expires, then you should be able to
renew it with a command like 'kinit' (At least, I suspect there is also
a 'kinit' command your MS Windows users could use for this purpose.)

If you have a 'klist' command which works, you will see output something
like this:

$ TZ=UTC; export TZ
$ date
Sun Jun  3 14:43:45 UTC 2007
$ klist -5
Ticket cache: FILE:/tmp/krb5cc_29543_PzbBs19284
Default principal: address@hidden

Valid starting     Expires            Service principal
06/03/07 10:34:46  06/04/07 00:34:46  krbtgt/address@hidden
06/03/07 10:34:48  06/04/07 00:34:46  afs/address@hidden
06/03/07 10:34:50  06/04/07 00:34:46  daemon/address@hidden
$ w mdb
  2:44pm  up 114 day(s),  7:36,  15 users,  load average: 0.04, 0.04, 0.04
User     tty           login@  idle   JCPU   PCPU  what
mdb      pts/22        2:34pm            1         w mdb
$

In the above case, the login time was 2:34pm UTC and the expire time
occurs six hours after the time of the login. If I am not able to renew
my krbtgt after the six hours, then I would expect the kind of error you
are seeing. I would then need to run the 'kinit' command to either renew
or regenerate my TGT. Normally, a renew should just work fine and should
have been transparent as long as the KDC is configured to allow it.

If you want to try to reproduce the problem, then using a 'kdestroy'
command to destroy your credentials followed by running the CVS command
should give you the same kind of error.

This problem is really outside of the scope of CVS as such as I would
expect the same kind of problem to arise for any kerberos application
which needs access to a new or renewed TGT.

Hmmm... A quick google of the error finds a similar problem replicated
here:

    http://rcmail.vintela.com/pipermail/putty/2005-August/000029.html

wherein there seems to be an issue with Microsoft's SSPI. The GSSAPI
layer of SSPI apparently will only provide applications with the
original ticket, even after the client has renewed their ticket.

Apparently Windows XP SP2 needs "WindowsXP-KB885887-x86-ENU.exe" installed.
Check Microsoft Knowledge Base article KB885887 for possible links to
the .exe

If that fails, I urge you to contact the folks that run your KDC to see
if they can help you better.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)

iD8DBQFGYtm9Cg7APGsDnFERAojWAKDeuKOkR5ZB8gSwmaYj9w5nB7EeNgCfRh0S
T7bkMnJ2IRo0YWSxTy2S3+A=
=+RAr
-----END PGP SIGNATURE-----