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 <huaraz@xxxxxxxxxxxxxxxx> wrote: > From: Markus Moeller <huaraz@xxxxxxxxxxxxxxxx> > Subject: Re: Re: Re: Squid 3.1.6, Kerberos and strange browser auth behavior > To: squid-users@xxxxxxxxxxxxxxx > Date: Wednesday, September 22, 2010, 11:46 AM > > >"Aleksandar Ciric" <aciric79@xxxxxxxxx> > wrote in message > >news:375975.43025.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > >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 > > >
