Gentoo Squid, IE browser 1. GET google 2. 407, Proxy-Authenticate: Negotiate\r\n 3. GET google, Proxy-Authorization: Negotiate <token>, NTLMSSP 4. 407, Proxy-Authenticate: Negotiate\r\n 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) 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. --- On Tue, 9/21/10, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: However, you can speed up > From: Amos Jeffries <squid3@xxxxxxxxxxxxx> > Subject: Re: Re: Re: Squid 3.1.6, Kerberos and strange browser auth behavior > To: squid-users@xxxxxxxxxxxxxxx > Date: Tuesday, September 21, 2010, 3:42 PM > On Tue, 21 Sep 2010 21:48:10 +0100, > "Markus Moeller" > <huaraz@xxxxxxxxxxxxxxxx> > wrote: > >>--- On Tue, 9/21/10, Markus Moeller <huaraz@xxxxxxxxxxxxxxxx> > wrote: > >> > >>> From: Markus Moeller <huaraz@xxxxxxxxxxxxxxxx> > >>> Subject: Re: Squid 3.1.6, > Kerberos and strange browser > >>> auth > >>> behavior > >>> To: squid-users@xxxxxxxxxxxxxxx > >>> Date: Tuesday, September 21, 2010, 12:13 PM > >>> > >>> "Aleksandar Ciric" <aciric79@xxxxxxxxx> > >>> wrote in message news:353393.71638.qm@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > >>> > Hello, > >>> > > >>> > I have a Gentoo server with 3.1.6 Squid. > I have setup > >>> Kerberos authentication with our AD server > that works > >>> correctly when accessed from domain member > computer. > >>> > However when I access it from (fully > updated) Windows > >>> XP computer that is not a member of a domain I > get a prompt > >>> in IE8, I fill the prompt but have to > acknowledge it 3 time > >>> in a row until I am granted access. Wireshark > shows that IE8 > >>> successfully goes through AS-REQ/AS-REP > TGS-REQ/TGS-REP on > >>> each prompt acknowledgement. It sends same > ticket (according > >>> to version number) along with GET request but > is let through > >>> only on 3rd attempt. > >>> > > >>> > Chrome behaves a bit differently, it goes > through > >>> AS-REQ/AS-REP TGS-REQ/TGS-REP only once, but > only upon > >>> hitting refresh 3rd time (on 3rd GET) it gets > through (as > >>> with IE, it does send ticket on first 2 GETs > too). > >>> > > >>> > >>> It looks like Chrome caches the credentials. > >>> > >>> What does the log say ? Does IE/Chrome request > the > >>> same page three times ? Can you check what > squid is > >>> returning to the client (e.g. is there an > >>> Proxy-Authorization with a token returned )? > >>> > >> > >>I will check for exact Proxy-Authorization tomorrow > at work. I didn't > >>really know what to look for, I know Kerberos in > theory, but not how > >>kerberized HTTP auth exactly works in detail. > >>From what I can remember of todays Wireshark tests, > each browser would > >>send > >>GET request for a page on each attempt - for IE on > prompt > >>acknowledgement, > >>and for Chrome on refresh attempt. Each of those > gets would have the > >>proper > >>Kerberos ticket attached (Chrome only requests and > gets one, so it has > to > >>be the proper one, as you said IE probably flushes > credentials on > >>unsuccessful auth attempt). First 2 GET attempts > would be denied with > >>HTTP > >>Error 407, while 3rd would get OK. > >> > >> > >>> > Firefox does't even get to try it, it as > other > >>> browsers tries NTLM on startup but gives up > upon failure and > >>> doesn't switch to Kerberos, however it works > fine when user > >>> is logged in with domain credentials. > >>> > > >>> > I have similar working test setup on > Fedora 10, with > >>> 3.0.22 Squid and there is no such behavior > noticed, so it > >>> cant be the clients fault. (same config > setting both for > >>> Kerberos and Squid, same AD). It actually runs > on my desktop > >>> machine while Gentoo one is VM on VmWare > Infrastructure. > >>> Both machines are similar specs, VM one being > even faster > >>> (3ghz XEON with 2GB RAM). > >>> > I am puzzled as to what might be reason > for this > >>> behavior, any help would be more than > welcome? > >>> > > >>> > >>> What does squid return to the client in this > case ? Also a > >>> Proxy-Authorization with a token ? > >> > >>From what I observed (will confirm tomorrow in > detail) with Fedora Squid > >>it > >>behaves as it should - first (upon starting browser > with startpage set > to > >>google.com) > >>1. GET > >>2. 407 > > Also, 407 with what Proxy-Auth* headers ? > > >>3. GET with NTLM auth > > > > Why a GET with NTLM ? Does squid return > Proxy-Authorization NTLM ? > > Side note: going *way* back to ancient memories. IE would > pick auth > methods in the order presented by http headers (ie order > configured in > squid.conf). Other browsers would pick the strongest auth > methods they had > tokens available for. > > > > >>4. 407 > > Also, 407 with what Proxy-Auth* headers ? > > >>5. prompt for password > >>6. AS-REQ/AS-REP TGS-REQ/TGS-REP with AD server, > >>7. GET > >>8. OK. > >> > > > > What does 7 GET contain a Proxy-Authorization > Negotiate ? > > > > /2c > > Amos >
