--- On Tue, 9/21/10, Markus Moeller <[email protected]> wrote:
> From: Markus Moeller <[email protected]> > Subject: [squid-users] Re: Squid 3.1.6, Kerberos and strange browser auth > behavior > To: [email protected] > Date: Tuesday, September 21, 2010, 12:13 PM > > "Aleksandar Ciric" <[email protected]> > wrote in message news:[email protected]... > > 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 3. GET with NTLM auth 4. 407 5. prompt for password 6. AS-REQ/AS-REP TGS-REQ/TGS-REP with AD server, 7. GET 8. OK. Much alike 3rd IE attempt (the sucessful one) in first case, except in first case there are steps 5, 6 and 7 repeated 3 times, first 2 times ending with 407. I couldn't find anything on even remotely similar problem on Internet, all my configurations are pretty standard default ones, examples taken from squid-cache and serverfault docs dealing with Squid-Kerb-AD topic. krb5.conf is identical on both servers, so is squid.conf. Same procedure followed when building this solution on both of em (Gentoo was supposed to be the production one). > > > Cira > > > > > > > > > > > > >
