ok, I will add timers to corelate log events with wireshark output, all
machines sync to AD NTP.
According to this, situation is clear (if one can say so).
If I acknowledge the pass prompt fast 3x in a row (that is 3 GET's get sent), I
get all 3x(DEBUG: Got / Decode / AF) lines in the cache.log the very moment and
an OK for last GET.
In second test, with pause after 2 acks, on first 2 acks of pass prompt (each
dispatches a GET request with valid kerb token) I get no reaction in log ... so
I waited about 10 secs for 3rd ack, did it and got all 3x(DEBUG: Got / Decode /
AF) lines at the same time according to log.
Unlike the situation detailed below where I only got one (DEBUG: Got / Decode /
AF).
Point is that 3rd GET seems to trigger processing the auth momentarily, any
less won't do. The time doesn't seem to matter.
When same desktop client (I tried several just to make sure) is logged in with
a valid domain username, none of this happens. After 1st 407 it goes through
TGS-REQ/TGS-REP and sends GET with GSSAPI (doesn't even try NTLM) and receives
OK.
I don't know how to resolve this or what to troubleshoot further. (beside
scrapping the Gentoo machine and trying with CentOS or Ubuntu server)
desktop_wireshark:
12:58:24.377414 1. GET google
12:58:24.379208 2. 407, Proxy-Authenticate: Negotiate\r\n
12:58:24.404808 3. GET google, Proxy-Authorization: Negotiate <token>,
NTLMSSP
12:58:24.406647 4. 407, Proxy-Authenticate: Negotiate\r\n
(no token)
5. Ack. the pass prompt
12:58:36.936887-943069 6. KRB5 AS-REQ/AS-REP, TGS-REQ/TGS-REP (with AD server)
12:58:37.033969 7. GET google, Proxy-Authorization: Negotiate <token>,
GSS-API (SPNEGO)
12:58:37.036221 8. 407, Proxy-Authenticate: Negotiate\r\n
(no token)
9. Ack. the pass prompt again after ~5 sec pause (same
user/pass, it stays filled in)
12:58:43.258456-263817 10. KRB5 AS-REQ/AS-REP, TGS-REQ/TGS-REP (with AD server)
12:58:43.264872 11. GET google, Proxy-Authorization: Negotiate <token>,
GSS-API (SPNEGO)
12:58:43.267059 12. 407, Proxy-Authenticate: Negotiate\r\n
(no token)
13. Ack. the pass prompt again after ~5 sec pause (same
user/pass, it stays filled in)
12:58:50.390082-395554 14. KRB5 AS-REQ/AS-REP, TGS-REQ/TGS-REP (with AD
server)
12:58:50.396739 15. GET google, Proxy-Authorization: Negotiate <token>,
GSS-API (SPNEGO)
12:58:50 DEBUG: Got / Decode / AF (squid cache log)
12:58:50.575546 16. 200 OK, Proxy-Authentication-Info: Negotiate
(token)
P.S.
I used pause cause I lack microseconds in squid cache.log
--- On Wed, 9/22/10, Markus Moeller <[email protected]> wrote:
> From: Markus Moeller <[email protected]>
> Subject: [squid-users] Re: Re: Re: Squid 3.1.6, Kerberos and strange browser
> auth behavior
> To: [email protected]
> Date: Wednesday, September 22, 2010, 11:46 AM
>
> >"Aleksandar Ciric" <[email protected]>
> wrote in message
> >news:[email protected]...
> >Gentoo Squid, IE browser
> >
> >1. GET google
> >2. 407, Proxy-Authenticate: Negotiate\r\n(beside scrapping the whole Gentoo
> >thing and going for some CentOS)
> >3. GET google, Proxy-Authorization: Negotiate
> <token>, NTLMSSP
> >4. 407, Proxy-Authenticate: Negotiate\r\n
>
> Interesting. I thought Negotiate will use Kerberos first
> and then NTLM.
>
> >5. Pass Prompt (stays on after ack)
> >6. KRB5 AS-REQ/AS-REP, TGS-REQ/TGS-REP (with AD
> server)
> >7. GET google, Proxy-Authorization: Negotiate
> <token>, GSS-API (SPNEGO)
>
> What does squid say here in the logfile ? If the token is
> complete it should
> already return 200 OK
>
> If not 8. should return also a token after Negotiate.
> Can you confirm that
> 8. does not contain a GSSAPI token ?
>
> >8. 407, Proxy-Authenticate: Negotiate\r\n
> >pause (here I waited about a minute to type all this)
> >9. Ack the pass prompt again (same user/pass, it stays
> filled in)
> >10. KRB5 AS-REQ/AS-REP, TGS-REQ/TGS-REP (with AD
> server)
> >11. GET google, Proxy-Authorization: Negotiate
> <token>, GSS-API (SPNEGO)
> >12. 200 OK, Proxy-Authentication-Info: Negotiate
> >
> >token in 7 & 11 is exactly the same, same pvno, as
> are kerberos ticket
> >version numbers in 6 and 10.
> >
> >There is no difference in 2, 4, 8 headerwise.
> >
> >Apparently that pause removed the need for third time,
> however you can
> >blitz through the entire process by acknowledging pass
> prompt 3x in a row,
> >which would only add steps 6,7&8 once more.
> >
> >Interesting is that a rather long pause (tried 30secs,
> needs about a
> >minute) made all the difference.
> >
>
> Regards
> Markus
>
>
>
