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
