GSSAPI client on Windows

Douglas E. Engert deengert at
Fri Jul 8 10:53:24 EDT 2005

SFBZH at 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> 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/

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 =
>     default_realm = DOMAIN.COM
> [realms]
>     DOMAIN.COM = {
>         admin_server = pc36:750
>         kdc =
>     }

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>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

More information about the krbdev mailing list