Some more comments below:

"Fabian Hugelshofer" <f...@open.ch> wrote in message news:4b8fdb2e.5000...@open.ch...
Markus Moeller wrote:
Continuation needed means that the GSSAPI exchange has not finished and the server needs more data from the client. Can you see in wireshark if the token length is the one squid_kerb_auth says it is
 > squid_kerb_auth: Got 'YRYI...' from squid (length: 3607)

I could confirm that the data that the client sends in the HTTP request is the same that is received by squid_kerb_auth. "YR " is added by squid (the space in the log of my last post got lost).

Further, I discovered that authentication is working for users from certain domains, but not for those at whose location the proxy is standing at. I describe the AD domain setup in more details:

The computer account that is associated with the service principal in the keytab file is from domain A.EXAMPLE.COM. Users, for who access is not working, are from domain B1.B.EXAMPLE.COM. Access is working for users from C.EXAMPLE.COM and a few others. The users from these "other" domains have been tested by starting IE as a user from that domain on a computer in domain C.EXAMPLE.COM. I forgot to mention that all the clients are Windows XP with IE7.


Can you download kerbtray from microsoft and list the tickets you have on XP on a working and failing machine. Can you alos capture with wireshark the traffic on port 88 ?

The FQDN of the proxy is not in the Windows domain hierarchy. It is proxy.d1.d.example.com.

I compiled squid_kerb_auth_test from Squid 3.1. On the proxy:

## With a user from non-working domain B1.B.EXAMPLE.COM
# kinit us...@b1.b.example.com
us...@b1.b.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
2010/03/04 15:26:51| squid_kerb_auth_test: gss_init_sec_context() failed: An unsupported mechanism was requested. unknown mech-code 0 for mech unknown
Token: NULL
# kinit -S HTTP/proxy.d1.d.example....@a.example.com
us...@b1.b.example.com's Password:
kinit: krb5_get_init_creds: Server (HTTP/proxy.d1.d.example....@b1.b.example.com) unknown


This is correct it should not work as there is no HTTP/proxy.d1.d.example....@b1.b.example.com principal. You need to use another call to get a TGT for HTTP/proxy.d1.d.example.com like:

kinit us...@b1.b.example.com
kgetcred HTTP/proxy.d1.d.example....@a.example.com
klist

## With a user from the domain of the proxy (A.EXAMPLE.COM)
# kinit us...@a.example.com
us...@a.example.com's Password:
# squid_kerb_auth_test proxy.d1.d.example.com
Token: YIIF...
# kinit -S HTTP/proxy.d1.d.example....@a.example.com
us...@a.example.com's Password:

Tomorrow I will try with a user from another domain that is working and that is outside A.EXAMPLE.COM. The content of my krb5.conf is:

[libdefaults]
  default_realm = A.EXAMPLE.COM

[realms]
  A.EXAMPLE.COM = {
    kdc = 10.0.0.1
    kdc = 10.0.0.2
  }
  B1.b.EXAMPLE.COM = {
    kdc = 10.1.0.1
    kdc = 10.1.0.2
  }





[domain_realm]
 .example.com = A.EXAMPLE.COM
 example.com = A.EXAMPLE.COM
 .d1.d.example.com = A.EXAMPLE.COM
 d1.d.example.com = A.EXAMPLE.COM



Fabian



Reply via email to