--- 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
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
>
