GSSAPI client on Windows

[SFBZH@aol.com]

Jeffrey Altman <jaltman at columbia.edu> wrote:
>Unfortunately, by doing so you are removing your best opportunity to
>diagnose where there problem actually lies.   As you describe it, how
>would you know if the gssapi32.dll library was in fact unable to talk
>with the ccache?  One way of knowing that it does is by letting it
>obtain the ticket for you.
I don't really understand your point of view. Anyway, I have tried both situations:
I have tried to launch gss_init_sec_context with a cache containing only the TGT.
I have tried to launch gss_init_sec_context with a cache containing the TGT and the service ticket.
Both tests have failed the same way (same error message). None has generated any network activity with the KDC.

I have chosen to have the service ticket in the cache before launching gss_init_sec_context because it is the simplest use of gss_init_sec_context (the ticket re-use). I am in a situation where the ticket is in the cache and the gssapi should only read it and give the data to the client. Unfortunately, it fails. I assume that both gssapi and the cache manager work properly (people have already managed to use gss_init_sec_context). I conclude that the problem is in my use of the gssapi, in my configuration of the cache manager or in the way gssapi and the cache manager interact.

I don't think the problem is a network problem.
pc35 successfully ping pc36 and pc36.domain.com
pc36 successfully ping pc35 and pc35.domain.com
and kinit successfully import the TGT and the service ticket.

Is there a way to localize more precisely the problem?

M