[squid-users] Question about Bug 1681

I have a question regarding the following bug:
http://www.squid-cache.org/bugs/show_bug.cgi?id=1681

It appears as though this bug is only something that occurs with
squid's ntlm_auth, we however use samba's ntlm_auth, and I see simular
problems.

snippet from squid.conf
auth_param ntlm program /opt/samba/bin/ntlm_auth
--helper-protocol=squid-2.5-ntlmssp

We seem to have the exact same problem though. We are running
squid2.6 Stable 9, and samba 3.0.25b. Is this patch needed for our
environment?

And can someone explain what is happening during this strace -p of one
of our ntlm_auth processes, is the timeout occurring because the DC
isn't responding?

read(0, "YR TlRMTVNTUAABAAAAB7IIogMAAwAzA"..., 1024) = 76
read(3, "\206J\25\345+\5\204\317", 8) = 8
write(1, "TT TlRMTVNTUAACAAAABgAGADAAAAAFg"..., 204) = 204
read(0, "KK TlRMTVNTUAADAAAAGAAYAHIAAAAYA"..., 1024) = 220
select(6, [5], NULL, NULL, {0, 0}) = 0 (Timeout)
write(5, "$\10\0\0\r\0\0\0\247\3\0\0\214\0\0\0\0\0\0\0\0\0\0\0\0"...,
2084) = 2084
select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
select(6, [5], NULL, NULL, {5, 0}) = 0 (Timeout)
select(6, [5], NULL, NULL, {5, 0}) = 1 (in [5], left {3, 343000})
read(5, "\264\f\0\0\2\0\0\0\0\0\0\0NT_STATUS_OK\0\0\0\0\0\0\0\0"...,
3240) = 3240
select(6, [5], NULL, NULL, {5, 0}) = 1 (in [5], left {5, 0})
read(5, "HDQ\\voj9088\0", 12) = 12
write(1, "AF HDQ\\voj9088\n", 15) = 15

From the tcpdump, It appears as though the following happens:

client -> proxy (HTTP Get google)
proxy -> client (407 not authorized NTLM auth)
client -> proxy (HTTP Get google NTLM NEGOTIATE YR) TlRMTVNTUAABAAAAB7...
proxy -> clent (407 not yet NTLM CHALLENGE TT) TlRMTVNTUAACAAAABg...
client -> proxy (HTTP Get google NTLM AUTH KK) TlRMTVNTUAADAAAAGA...
Domain\UserID

Is there more happening from the client to Domain controller? I only
did a tcpdump on the squid server.

Thank you,
Brian
Received on Mon Mar 03 2008 - 08:57:02 MST