Re: Broken Negotiate NTLM auth, Squid 3.2

On 11.12.2012 07:12, Alex Rousskov wrote:
> On 12/10/2012 09:40 AM, Steve Hill wrote:
>>
>> I posted to the users list last week regarding Squid 3.2.3 breaking
>> Negotiate NTLM authentication. My original report was slightly
>> inaccurate - it looks like the regression was introduced between
>> 3.1.22
>> and 3.2.0.1.
>>
>> I've been investigating this today using Squid 3.2.3 and found that
>> the
>> problem is that when Auth::Negotiate::Config::fixHeader() is called,
>> authenticateProgram is unset.
>
> FWIW, I have seen that too. I failed to track the exact reason by
> looking at the code alone. Asked around on IRC, but nobody knew what
> the
> cause could be. My theory was that Squid starts using the wrong
> Config
> object. Your comments below semi-confirm that. I am waiting for more
> debugging from a customer to triage this further (using a patch with
> extra debugging added).
>
>
>> However, in
>> Auth::Negotiate::Config::decode() is is correctly set.
>>
>> There appear to be two instances of the Auth::Negotiate::Config
>> object:
>> - One instance is instantiated at the top of
>> src/auth/negotiate/auth_negotiate.cc as negotiateConfig and this
>> does
>> _not_ have authenticateProgram set. This is the instance for which
>> fixHeader() is called.
>> - One instance is instantiated elsewhere and has authenticateProgram
>> set. This is the instance for which decode() is called.
>>
>> Unfortunately, comparing the code between 3.1.20 (which works
>> correctly)
>> and 3.2.3 (which is broken), I can't see where authenticateProgram
>> should be set in the negotiateConfig instance. In fact, I don't
>> understand why there are two instances of this object in the first
>> place?
>
> Good question!
>
> Alex.

During and after reconfigure there are 2+ Config objects...

  * credentials setup under the previous configuration are RefCount
linked to the Config which they were setup with in order to guarantee
realm/timeout/etc details are not changed underneath the validation
code.
  * all *new* challenges should always use the current Config object.

Our configuration code is not smart enough yet to de-duplicate Config
objects when there have been no changes. Nor is it smart enough to
cleanly trigger closing of any existing connections with linked
connection-auth details to speed up the removal of old Config.

That could explain the alternative Config, but authenticateProgram
should *always* be set when that auth module is configured and used.

Amos
Received on Mon Dec 10 2012 - 22:06:55 MST