GSSAPI client on Windows

[Douglas E. Engert]

SFBZH at aol.com wrote:

> 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 agree with Jeff on this. Dont try and get a service ticket first. It will just cause
problems. And as you have said it failes either way, so that is not the problem
it does not get this far. But when you get the real problem fixed, you want
to use the gssapi as it was desiged to get the ticket for you.

> 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.

Still looks like a network/DNS problem to me.

> 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?

Fix you network. Try nslookup on these names, and the
reverse lookups of the ip numbers.


> 
> M
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444