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
