Windows NTLM authenticator

From: Serassio Guido <guido.serassio@dont-contact.us>
Date: Sun, 07 Sep 2003 20:03:02 +0200

Hi Henrik,

Do you remember the following discussion in May ?

I have just rewritten the win32 ntlm helper according your direction, it
seems mainly to work, with some minor problems.

>Guido: I do not see how your win32 ntlm helper can work. 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,

Currently I'm internally faking the NEGOTIATE packet

>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.

I have tried too this solution, but the things seems to more instable. The
helper is ready to run in this mode, the code is already present, just
commented with an #ifdef.

>Regards
>Henrik

I have some doubt about challenge's reuse: with this type authenticator,
challenge can be reused ?
To me it seems no: whit setting of auth_param ntlm
max_challenge_reuses different from 0, the authenticator fails.

Another question: it works fine with Mozilla's NTLM and with IE when the
machine is in the right domain, when the machine is in another domain, IE
pop-up randomly asking username/password/domain again.

So, if possible, do you can give a look to the sources to see if there
anything missing ?

Thanks

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 Sep 07 2003 - 12:03:26 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:20:40 MST