On Monday 25 February 2002 12:00, Chemolli Francesco (USI) wrote:
> No can do unless you can supply the challenge to the authentication
> provider, which is a no-go for NTLMSSP which is going to stay.
> Challenge generation will be at best at the helper level.
If you look back in the discussion a little I have the same opinion
here. Robert seems to differ, wanting to put as much as possible of
the challenge logic into Squid and use a secure channel to the DC for
verifying the responses, relayed via winbindd.
> Well, we'd need a better helper (looking back at the current
> NTLMSSP, well let's just say it's not something I'm proud of - in
> fact I'm ashamed) AND a way of multiplexing stuff to/from the
> helper. All of this has already been told :)
No big deal. Extending the (what you call ugly) NTLMSSP helper for N
concurrent sessions should be no more than about 30 minutes job to
clean up the few global states left. The hard part is in Squid to
kill the challenge reuses and instead keep track of multiple
sessions to each helper. A client connection is exclusively bound to
a helper session during the authentication.
The protocol can easily be revised. Only requires a minimal change to
include the session number and to include the negotiate packet.
Commands for the sessions are multiplexed to the helper, one at a
time.
Regards
Henrik
Received on Mon Feb 25 2002 - 06:46:09 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:49 MST