GSSAPI client on Windows

[Douglas E. Engert]

SFBZH at aol.com wrote:

> Thank you for your help, it is much appreciated.
> 
> I have reinstalled the MITKerberosForWindows-2.6.5.exe. Both gssapi32.dll and krb5_32.dll are up to date. The problem remains.
> 
> "Douglas E. Engert" <deengert at anl.gov> said:
> 
>>Not sure what you mean by "import the TGT & service ticket"
> 
> 
> By "import the TGT & service ticket", I mean that I have launched both
> 
>>kinit -5 user

Does leach show a ticket?

> 
> and
> 
>>kinit -5 -S service/pc36.domain.com

Don't do this. The libs will do it for you.

> 
> 
> I know that the gssapi should get the service ticket itself but I have a good reason to do that. (well, I think so)
> If the service ticket has not been previously imported, when gss_init_sec_context fails, the problem may come from the KDC, the network, the local krbcc32s, the local network configuration, the gssapi call...
> If the service ticket is already in the local cache, the problem is much more localised. Everything take place on the Windows station (pc35). The elements I have to check are my call to the gssapi, my kerberos local installation and my kerberos local configuration. (Incremental debugging :p ) It seems that the client program (gssapi) doesn't interact properly or doesn't interact at all with the local cache manager (krbcc32s) but I don't know how to check it. Is there a local cache configuration file? How does the gssapi find the local cache? How does it find out which mechanism to use? (krb4, krb5...)
>

Don't like your argument. Run it as intended and use ethereal to see if the libs
do any requests to the KDC.


> I fell my krb5.ini is weak. Is this correct? I've got nothing more than that:
> [libdefaults]
>     default_domain = domain.com
>     default_realm = DOMAIN.COM
> 
> [realms]
>     DOMAIN.COM = {
>         admin_server = pc36:750
>         kdc = 192.168.0.36:88
>     }
> 

Might work. Kerberos likes to do reverse name lookups on DNS names
and expects all host names to be fully qualified. Having you KDC
and hosts behind a NAT without being is DNS could be a problem.
You could look at local host tables before DNS. I believe this would
be a c:\windows\system32\drivers\etc\hosts


> 
> Best regards
> 
> M
> 
> 
> 

-- 

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