>--- On Tue, 9/21/10, Markus Moeller <huaraz_at_moeller.plus.com> wrote:
>
>> From: Markus Moeller <huaraz_at_moeller.plus.com>
>> Subject: [squid-users] Re: Squid 3.1.6, Kerberos and strange browser auth
>> behavior
>> To: squid-users_at_squid-cache.org
>> Date: Tuesday, September 21, 2010, 12:13 PM
>>
>> "Aleksandar Ciric" <aciric79_at_yahoo.com>
>> wrote in message news:353393.71638.qm_at_web114210.mail.gq1.yahoo.com...
>> > 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
Why a GET with NTLM ? Does squid return Proxy-Authorization NTLM ?
>4. 407
>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 ?
>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
>> >
Received on Tue Sep 21 2010 - 20:48:37 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 22 2010 - 12:00:04 MDT