Re: [squid-users] Problem with Single Sign-On & NTLM

On 14.06.2012 00:49, Garry wrote:
> Hi,
>
> following some howtos/tutorials on the net I managed to get SSO with
> NTLM to work ... anyway, there are some significant delay during
> authentication ...
> I see the two failed 407 requests, then there's some 5-10 second
> delay
> before the successful requests follow.
>
> I've did some strace on the processes and found that the ntlm helper
> seems to be causing the delay, specifically the one with the
> squid-2.5-ntlmssp
> helper protocol. Here's an excerpt from the strace run:
>
> 7289 14:14:15 _llseek(2, 0, [809868], SEEK_CUR) = 0
> 7289 14:14:15 write(2, "NTLMSSP Sign/Seal - Initialising"..., 45) =
> 45
> 7289 14:14:15 munmap(0xb775d000, 4096) = 0
> 7289 14:14:15 fstat64(2, {st_mode=S_IFREG|0640, st_size=809913,
> ...}) = 0
> 7289 14:14:15 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb775d000
> 7289 14:14:15 _llseek(2, 0, [809913], SEEK_CUR) = 0
> 7289 14:14:15 write(2, "Got NTLMSSP neg_flags=0xa2088205"..., 33) =
> 33
> 7289 14:14:15 munmap(0xb775d000, 4096) = 0
> 7289 14:14:15 write(1, "AF administrator\n", 17) = 17
> 7289 14:14:15 read(0, "YR TlRMTVNTUAABAAAAB4IIogAAAAAAA"..., 4096) =
> 60
> 7289 14:14:24 uname({sys="Linux", node="BSSVR03", ...}) = 0
> 7289 14:14:24 socket(PF_NETLINK, SOCK_RAW, 0) = 5
>
> The system call that delays the processing above is actually the
> "read(0," call at 14:14:15, which _starts_ at :15, but doesn't finish
> until :24 ... I've combined tracing both the Squid process and the
> auth
> helper, but can't discern any routing that in itself would cause the
> delay (see below).

It is not routing as such. The helper has to contact the network DC and
generate new crypto keys, this can take time. Especially if the DC is
under load.
This should help explain what work each of those I/O lines is
triggering:
http://wiki.squid-cache.org/Features/AddonHelpers#Negotiate_and_NTLM_Scheme

>
> I also noticed a post on the Net that talked about M$ deprecating
> NTLM
> (now they do?) in favor of Kerberos, and that Squid 3.2 would have
> the
> direct Kerberos auth available. Does this mean I can use 3.2 with
> direct
> Kerberos for SSO instead of this POS NTLM auth?

What do you mean by "direct kerberos"?

Squid-3.2 can login to its upstream peers using Kerberos.
All current Squid accept Kerberos via "Negotiate" authentication scheme
in HTTP.

Amos
Received on Thu Jun 14 2012 - 00:29:27 MDT