Re: NTLM, Windows and the sessionkey field

On Sunday 24 February 2002 08:11, Robert Collins wrote:

> Not a big deal really. The _only_ required difference is whether
> squid asks for a challenge or provides it's own, and that can be
> turned on and off via a startup handshake, or a config entry.
> Parsing the negotiate can be implemented without altering the
> helper protocol. I plan on retaining support for the current
> helper-squid protocol indefinately anyway, because winbindd doesn't
> exist on win32, and NTLMSSP works.

Fine.

Let me put it this way: Until Squid has full support for generating
LANMAN, NTLMv1 and NTLMv2 challenges then make sure you send the
negotiate packet to the helper or else there is no sane way the
helper can generate a correct challenge.

The current protocol where the challenge is generated by quessing is
broken.

If you later revise the implementation to have the challenge
generated by Squid then this is fine.

> Actually it's not. Kerberos doesn't fit in the same scheme. NTLMv2
> though - yes.

Are you positively sure that forwarding of a kerberos ticket cannot
be done over NTLMSSP?

How does native MSAD clients access NT4 servers?

> This is an interesting point. Personally if someone wants to add a
> third party scheme to http-ntlm, they will need something that
> doesn't exist: doco on MS's innards. They will also need to alter
> MSIE to support it. Squid will be the least of their worries.

I don't think they will need to aler MSIE as long as there is a
NTLMSSP security provider for the protocol.

MS has some doco on how to write NTLMSSP security providers, at least
for the Windows CE platform..

> This is adding complexity thats not needed. Several reasons:
> 1) _Only_ winbindd and local file helpers can support multiple
> challenges. The NTLMSSP helper cannot support multiple outstanding
> challenges - without serious backend changes in the smbval library
> we are using.

From what I have seen of the code so far this extending the helper
with a domain switch would be trivial.

> 2) The helpers would need to start using non-blocking IO, removing
> all the simplicity benefits of having them outside squid in the
> first place.

Not really. It is acceptable if the helper blocks for a short while
as long as the core is smart enought to not give the helper any
additional sessions while it is waiting for a reply from the helper.

> If you mean the ability to have pending authentications
> overlapping, then we already have that.

Explain please.

> What do you mean by authentication package?

packet. The third final NTLMSSP packet.

Regards
Henrik
Received on Sun Feb 24 2002 - 05:43:22 MST