Re: NTLMSSP and Squid

Hi Henrik,

Il 15.45 10/05/2003 Henrik Nordstrom ha scritto:
>Guido: I do not see how your win32 ntlm helper can work.

The helpers is based on code fragments from MSDN, Apache mod_ntlm and
ntlm_auth (SMB).
I have successfully tested that it authenticates user credentials: for
example, if you try to use credentials from an untrusted domain, the
authentication process fails and Internet Explorer asks for
Username/password/domain.

> From what I
>can tell you generate and forget your own challenge, and then fakes
>an authentication step with faked user credentails. This is not even
>mathematically possible to work and I suspect your helper is not
>acutally authenticating the user but in reality accepting mostly
>anything as long as the Squid library can make sense of... The
>challenge needs to be generated by AcceptSecurityContext() and the
>context generated whem making the challenge packet remembered when
>the helper later gets the AUTHENTICATE NTLMSSP packet.
>
>The correct operation of a server accepting NTLMSSP using the Windows
>SSP API is something like:
>
> 1. Set up the server state
> 2. Accept the NEGOTIATE packet and send this to
>AcceptSecurityContext with a NULL context handle and a pointer to
>where the new context handle can be returned.
> 3. Send the returned BLOB back to the client (this is the CHALLENGE
>packet).
> 4. When receiving the AUTHENTICATE packet process this BLOB with
>AcceptSecurityContext using the context returned in the new context
>handle pointer in 2 above.
> 5. Return success/failure to Squid, and free the context set up in
>2.
>
>
>Note about step 2: With the current state of Squid you will need to
>fake the NEGOTIATE packet blob with what you think the client is
>providing, or hack Squid to sent the NEGOTIATE packet to ntlm
>helpers. Warning: if you hack Squid to send the NEGOTIATE packet then
>there is a serious risk of cross-browser incompability in challenge
>reuses, with the effect that one user can cause authentication to
>randomly fail for others if the challenge returned by SSP for his
>NEGOTIATE packet is incompatible with the browser/OS used by the
>other user. But on the other hand this will most likely also allow
>NTLMv2 to function.

Thanks for the hints, I will try to implement this.

Regards

Guido

-
========================================================
Guido Serassio
Acme Consulting S.r.l.
Via Gorizia, 69 10136 - Torino - ITALY
Tel. : +39.011.3249426 Fax. : +39.011.3293665
Email: guido.serassio@acmeconsulting.it
WWW: http://www.acmeconsulting.it/
Received on Sun May 11 2003 - 08:27:41 MDT