Re: Broken Negotiate NTLM auth, Squid 3.2

On 12/10/2012 03:06 PM, Amos Jeffries wrote:
> 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!

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

What if there was no reconfiguration involved?

Alex.
Received on Tue Dec 11 2012 - 00:09:31 MST