Re: NTLMSSP and Squid

On Sat, 2003-05-10 at 23:45, Henrik Nordstrom wrote:
> On Saturday 10 May 2003 13.49, Henrik Nordstrom wrote:
> > On Saturday 10 May 2003 13.26, Robert Collins wrote:
> > > The stateful helper logic was only ever a workaround for helpers
> > > that *had* to maintain state across requests. We can keep the
> > > logic for reuse, but it won't be needed once we switch to passing
> > > everything through with no challenge reuses ever, and the
> > > negotiate is given to the helper.
> >
> > Keeping state WILL be required somewhere.
> >
> > You cannot process an AUTHENTICATE packet without knowing the
> > information used when generating the CHALLENGE packet.
>
> To summarise the needs for state one more time:
>
>
> wb_ntlmauth:
> Needs to keep the NTLM challenge value
>
> ntlm_auth:
> Needs to keep the SMB connection who gave the challenge

Samba's ntlm_auth:
        Keeps internal state as to the challenge that it supplied to squid..

> Native win32 ntlm using Microsoft NTLM SSP AcceptSecurityContext()
> function to process and generate NTLMSSP packets:
> Needs to keep the SSP context object who processed the NEGOTIATE
> packet and generated the CHALLENGE packet.
>
> hypothetical ntlmssp relay auth, for example if using a IIS server for
> NTLMSSP processing:
> Needs to maintain the connection to the NTLMSSP server used.
>
>
>
> 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.

This sounds correct, from my understanding of this and from what I've
had to do for Samba.

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

Samba's ntlm_auth intends to operate in a similar way. For the moment,
it works, but it's very ugly pretending to be in 'datagram mode' when we
are not...

Samba's ntlm_auth expects a negotiate packet, and just copes if it's not
there. But you loose things like unicode...

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet@pcug.org.au
Manager, Authentication Subsystems, Samba Team  abartlet@samba.org
Student Network Administrator, Hawker College   abartlet@hawkerc.net
http://samba.org     http://build.samba.org     http://hawkerc.net