On 14.06.2012 02:29, Amos Jeffries wrote:
> 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
>
(sorry, didn't mean routing but reason ;) ) So a 5-10 second delay is to
be considered "normal"? Not sure about the actual load of the DC, but I
can't imagine it's _that_ high to cause such delay (especially as I only
did some testing alone without multiple users using this proxy).
>> 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.
Let me rephrase that - is there any way of getting around the problems
I'm seeing with the current setup by using some other method and/or
newer version of Squid?
Thanks, Garry
