Re: Needing state in NTLMSSP

Andrew Bartlett wrote:
 
> My first problem is that Squid doesn't pass the 'negotiate' packet to
> the helper at all! I'm currently testing a nasty little hack that will
> pass this along, but we also need to look at how the helpers are
> structured in general - we really do need one helper per client - say
> key it on the IP (to allow limited challenge reuse) and the contents of
> the negotiate packet.

Using the same hack in my early tests with NTLMv2.

Unfortunately IP is not entirely reliable as client identifier. There
may be multiuser stations such as terminal server or NAT devices
inbetween.. also the number of helpers we may have is limited.

> I am worried about the effectively one-helper-per-client side of this -
> it could be addressed by having the helper keep multiple states.
> (Because we don't need to request the challenge, or keep a socket open,
> it's relatively sane)

Which is the path we have to go I think. See my proposal last time this
was discussed. I assume this is what you refer to by 'v2' helper
protocol.

I have a almost completed plumbing done in the helper communication code
to allow for multiple concurrent queries to a single helper. Not yet
finished for stateful helpers however. Needed this for another project
involving long running external queries. Once finished implementation of
a 'v2' ntlm helper protocol becomes trivial in the Squid part of things,
and also almost trivial in the winbind helper.

Regards
Henrik
Received on Thu Jan 16 2003 - 02:41:16 MST