NTLM authentication

I thought I'd send out a general update on this (for anyone who cares :-])
so that the squid gurus out there can tell us if we've made any horrible
mistakes.

Chemoli and I are making large amounts of progress on the NTLM
authentication.

Thanks for your comments Henrik (I presume your back on deck now?) We've
found some issues that _may- hit performance on squid, and there is no
workaround I can see - by the definition of the NTLM protocol...

One issue is that the challenger _must_ be a machine that knows the users
password (that's why I mentioned the need for usernames and password s on
the squid box in one of my previous mails).
Unless squid itself knows the users passsword it cannot validate the
challenge response. We're handing that off to the domain controller (as MS
Proxy itself does).
So with the challenge generated by the NT domain controller, squid _could_
cache the challenge and the expected response for a 'user', but that will
cause any user that uses a machine before it times out to get a
username/password box, which NTLM is meant to avoid. On the up side no
external authentication is needed on the persistent connection once done.

For the moment - it can be expanded on - we've added stateful helpers to
squid, so squid remains largely ignorant of the content of the
authentication and also doesn't block. Digest authentication has the same
general requirements as NTLM, and should be able to leverage much of the
same code.

The external helper is now theoretically able to talk with a SMB server and
validate users, but we've yet to test that.

We've cut out the use of the auth_user hash __for NTLM authenticated
connections__. This was a performance choice.
To successfully authentication with NTLM we must store data in the conn
structure, rather than doing a hash lookup to see if we know a user, by ip
or name, we can get the username direct form the conn structure.
upside: less lookups once authenticated
downside: for NTLM the single-ip code won't work at the moment. It would be
easy to put in though.

Henrik, the alterations in the NTLM branch I was talking about, remove the
pump module and change the request flow. We've done our coding now though
so, I hope the original NTLM branch was ok!

We've leaving the authentication type differentiated proxy_auth code for
later, once the core is bedded down.

That's about it really.. look for working NTLM authentication soon!

Oh, regarding the NTLM and Basic header order, I've lookup it up - RFC
2617 - and MS is breaking spec (again).

I'm going to post something to them sometime soon and see waht they say.

Rob
Received on Mon Jul 31 2000 - 17:37:37 MDT