On 6/07/2012 11:42 p.m., Bruno Santos wrote:
Hi !


I've configure squid 3.1.10-1 (latest available for CentOS 6.2) with NTLM 
authentication, but squid keeps asking for username and password. And sometimes 
more than once...


Users are authenticated in the domain, using IE6/7/9, but squid keeps asking 
for username/password.


Those with other browsers and Linux it's normal, but in windows no. I don't 
know if Firefox in windows is supposed to ask for password or not, but it asks.

For machines logged into the domain being logged into a proxy which uses the domain credentials - the browser should never ask. This is a strong sign that the proxy is using different credentials than the ones used to log into the machine, or is loosing them somehow..



I have everything working with samba and winbind.


Samba recognizes the user and winbind too.


Wbinfo authentication:



wbinfo -a teste%12345
plaintext password authentication succeeded
challenge/response password authentication succeeded


Squid ntlm_auth also is working ok



/usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
teste 12345
OK

How much delay is the next thing to look for: I suspect 0.2sec?


I notice something in the logs that are also a lots of TCP_DENIED before 
TCP_MISS (and squid din't ask for password)
An example of access a website:



111.111.11.11 TCP_DENIED/407 4758 GET 
http://www.venezuelatuya.com/tour/minitour.JPG - NONE/- text/html
1341573268.467 8 111.111.11.11 TCP_DENIED/407 4778 GET 
http://www.venezuelatuya.com/tour/minioccidente.jpg - NONE/- text/html
1341573268.469 9 111.111.11.11 TCP_DENIED/407 4766 GET 
http://www.venezuelatuya.com/tour/minicentro.jpg - NONE/- text/html
1341573268.472 11 111.111.11.11 TCP_DENIED/407 4778 GET 
http://www.venezuelatuya.com/tour/minilosroques.jpg - NONE/- text/html
1341573268.472 11 111.111.11.11 TCP_DENIED/407 4774 GET 
http://www.venezuelatuya.com/tour/minimorrocoy.jpg - NONE/- text/html
1341573268.474 10 111.111.11.11 TCP_DENIED/407 4770 GET 
http://www.venezuelatuya.com/tour/minicaracas.jpg - NONE/- text/html
1341573268.474 10 111.111.11.11 TCP_DENIED/407 4762 GET 
http://www.venezuelatuya.com/tour/miniandes.jpg - NONE/- text/html
1341573268.474 10 111.111.11.11 TCP_DENIED/407 4778 GET 
http://www.venezuelatuya.com/tour/minimargarita.jpg - NONE/- text/html
1341573268.549 275 111.111.11.11 TCP_MISS/200 2186 GET 
http://www.venezuelatuya.com/scripts/mapapaginaprincipal.js teste 
DIRECT/207.58.139.197 applicat
ion/javascript
1341573268.576 139 111.111.11.11 TCP_MISS/200 444 GET 
http://www.venezuelatuya.com/principal.css teste DIRECT/207.58.139.197 text/css

This appears to be normal.
 * Over the course of 7ms the client delivers 8 requests.
* squid responds with auth-needed challenge as required by NTLM to each of these.

This might be connections opened in parallel, or requests pipelined at once before the first response comes back. 8 is a suspicious number, that is the default browser config value for maximum number of connections to open for any one website. I highly suspect this is 8 new connections being opened and performing NTLM handshake.


50ms later there are more denies. Which looks like the connections earlier authenticated (partially?) got closed and new ones needed authenticating.

1341573268.602 1 111.111.11.11 TCP_DENIED/407 4467 GET 
http://www.venezuelatuya.com/tour/minioriente.jpg - NONE/- text/html
1341573268.606 1 111.111.11.11 TCP_DENIED/407 4770 GET 
http://www.venezuelatuya.com/tour/minioriente.jpg - NONE/- text/html
1341573268.608 1 111.111.11.11 TCP_DENIED/407 4907 GET 
http://googleads.g.doubleclick.net/pagead/ads ? - NONE/- text/html
1341573268.617 1 111.111.11.11 TCP_DENIED/407 5186 GET 
http://googleads.g.doubleclick.net/pagead/ads ? - NONE/- text/html
1341573268.699 399 111.111.11.11 TCP_MISS/200 3817 GET 
http://www.venezuelatuya.com/scripts/barrabusqueda.js teste 
DIRECT/207.58.139.197 application/ja
vascript

About 200ms after the earlier bunch of DENIED/407 responses an identical bunch pass through successfully. Exactly like the auth challenge was being responded to with correct credentials.

1341573268.741 272 111.111.11.11 TCP_MISS/200 2801 GET 
http://www.venezuelatuya.com/tour/minioccidente.jpg teste DIRECT/207.58.139.197 
image/jpeg
1341573268.745 137 111.111.11.11 TCP_MISS/200 3520 GET 
http://www.venezuelatuya.com/tour/minioriente.jpg teste DIRECT/207.58.139.197 
image/jpeg
1341573268.753 274 111.111.11.11 TCP_MISS/200 2062 GET 
http://www.venezuelatuya.com/tour/minilosroques.jpg teste DIRECT/207.58.139.197 
image/jpeg
1341573268.755 276 111.111.11.11 TCP_MISS/200 2725 GET 
http://www.venezuelatuya.com/tour/miniandes.jpg teste DIRECT/207.58.139.197 
image/jpeg
1341573268.867 400 111.111.11.11 TCP_MISS/200 4137 GET 
http://www.venezuelatuya.com/tour/minitour.JPG teste DIRECT/207.58.139.197 
image/jpeg
1341573268.869 396 111.111.11.11 TCP_MISS/200 3447 GET 
http://www.venezuelatuya.com/tour/minicentro.jpg teste DIRECT/207.58.139.197 
image/jpeg
1341573268.877 400 111.111.11.11 TCP_MISS/200 3310 GET 
http://www.venezuelatuya.com/tour/minimorrocoy.jpg teste DIRECT/207.58.139.197 
image/jpeg
1341573268.880 403 111.111.11.11 TCP_MISS/200 3829 GET 
http://www.venezuelatuya.com/tour/minimargarita.jpg teste DIRECT/207.58.139.197 
image/jpeg
1341573268.882 404 111.111.11.11 TCP_MISS/200 3452 GET 
http://www.venezuelatuya.com/tour/minicaracas.jpg teste DIRECT/207.58.139.197 
image/jpeg


You can test this theory by grabbing a TCP packet trace of the HTTP requests and responses between Squid and client.

-------------------------------------------------------------




and my krb5.conf
It would seem not relevant. You did not configure Negotiate/Kerberos in squid.conf. However, there is a strange lack of 407. NTLM specifies two DENIED/407 challenges for token exchange before anything is accepted (MISS/200). Kerberos on the other hand responds to the first 407 with a pre-calculated key (keytab entry) which skips straight to the MISS/200.


Any clue why it's happening ?


squid is also a member of group wbpriv



id squid
uid=23(squid) gid=23(squid) groups=88(wbpriv),23(squid)




I also have dansguardian listening in port 8080.

Some other possibilities are:

Is DG rejecting NTLM auth responses and only working when Basic are provided? or is DG doing part of the NTLM exchange itself (ie advertising NTLM can be used), which leaves Squid with only two request/response actions to complete the NTLM setup?


Amos

Reply via email to