Re : GSSAPI client on Windows

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re : GSSAPI client on Windows

SFBZH
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" <[hidden email]> 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
and
>kinit -5 -S service/pc36.domain.com

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

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
    }


Best regards

M
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Re : GSSAPI client on Windows

Jeffrey Altman
[hidden email] wrote:

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

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 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
>     }
There should be no need to specify the default ports and you should use
fully qualified domain names for the host entries.   Other than that
there is nothing wrong here.

The most likely point of failure is DNS.  If you are using IP addresses
because you don't have a working DNS for your private subnet, that is
where you must look first.


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re : GSSAPI client on Windows

Douglas E. Engert
In reply to this post by SFBZH


[hidden email] 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" <[hidden email]> 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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev