Re: [squid-users] Problems setting up Kerberos authentication

Markus Moeller wrote:
> 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 ?

Using kerbtray did not show a difference. Capturing the traffic on port
88 shows that in both cases the client walks through the domain
hierarchy and at the end gets a ticket for the proxy service.

Comparing the tickets that are sent in the HTTP request with Wireshark
did not show any difference at all. For what I can see there

I used debug_options ALL,1 29,9. Both cases start with:

2010/03/04 13:39:49| authenticateValidateUser: Validating Auth_user
request '(nil)'.
2010/03/04 13:39:49| authenticateValidateUser: Auth_user_request was NULL!
2010/03/04 13:39:49| authenticateAuthenticate: broken auth or no
proxy_auth header. Requesting auth header.
2010/03/04 13:39:49| authenticateFixHeader: headertype:38 authuser:(nil)
2010/03/04 13:39:49| authenticateNegotiateFixErrorHeader: Sending
type:38 header: 'Negotiate'
2010/03/04 13:39:50| authenticateAuthenticate: header Negotiate YII...
2010/03/04 13:39:50| authenticateAuthenticate: This is a new checklist
test on FD:71
2010/03/04 13:39:50| authenticateAuthenticate: no connection
authentication type
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '1'.
2010/03/04 13:39:50| authenticateDecodeAuth: header = 'Negotiate YII...
2010/03/04 13:39:50| authenticateAuthUserLock auth_user '0x8593128'.
2010/03/04 13:39:50| authenticateAuthUserLock auth_user '0x8593128' now
at '1'.
2010/03/04 13:39:50| authenticateDecodeNegotiateAuth: Negotiate
authentication
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| User not fully authenticated.
2010/03/04 13:39:50| authenticateNegotiateAuthenticateUser: auth state
negotiate none. Negotiate YII...
2010/03/04 13:39:50| authenticateNegotiateAuthenticateUser: Locking
auth_user from the connection.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '2'.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| User not fully authenticated.
2010/03/04 13:39:50| authenticateValidateUser: Validating Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateValidateUser: Validated Auth_user
request '0x8552f98'.
2010/03/04 13:39:50| authenticateStart: auth_user_request '0x8552f98'
2010/03/04 13:39:50| authenticateNegotiateStart: auth state '1'
2010/03/04 13:39:50| authenticateNegotiateStart: state '1'
2010/03/04 13:39:50| authenticateNegotiateStart: 'YII...
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98'.
2010/03/04 13:39:50| authenticateAuthUserRequestLock auth_user request
'0x8552f98' now at '3'.
2010/03/04 13:39:50| squid_kerb_auth: Got 'YR YII... ' from squid
(length: 3607).

Then for the non-working case:

2010/03/04 13:39:50| squid_kerb_auth: continuation needed
2010/03/04 13:39:50| authenticateNegotiateHandleReply: Helper:
'0x82d5d40' {TT oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo=}
2010/03/04 13:39:50| authenticateNegotiateHandleReply: Need to challenge
the client with a server blob 'oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo='

The only difference that I can see is that in the non-working case the
ticket length is 3607 and in the working case 2643.

>> ## With a user from non-working domain B1.B.EXAMPLE.COM
>> # kinit user1_at_B1.B.EXAMPLE.COM
>> user1_at_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.com_at_A.EXAMPLE.COM
>> user1_at_B1.B.EXAMPLE.COM's Password:
>> kinit: krb5_get_init_creds: Server
>> (HTTP/proxy.d1.d.example.com_at_B1.B.EXAMPLE.COM) unknown
>>
>
> This is correct it should not work as there is no
> HTTP/proxy.d1.d.example.com_at_B1.B.EXAMPLE.COM principal. You need to use
> another call to get a TGT for HTTP/proxy.d1.d.example.com like:
>
> kinit user1_at_B1.B.EXAMPLE.COM
> kgetcred HTTP/proxy.d1.d.example.com_at_A.EXAMPLE.COM
> klist

At the moment I don't have kgetcred available. I will try this later.
Thanks for the hint.

Using a user from the domain that is not working on a computer of the
domain that is, did not help. Is definitely somehow domain-related. The
tickets are being sent and look the same in both cases.

Fabian
Received on Mon Mar 08 2010 - 14:54:58 MST