Squid NTLM authentication project (FAQ here)

The NTLM authentication project aims at providing Microsoft NTLM proxy authentication support for Squid.

Current status (22/11/2000)

• Several sites successfully using it on a small scale.
• Occasional unknown errors with the Domain Controllers. No known reason.
• Samba/SMBSessSetupX-based and dummy backends.

Available documentation

Assorted notes from Robert Collins: (As at 16/11/2000)

Feature List (In this branch)

• NTLM Authenticate scheme support
• Config file driven 407 responses. (NTLM can now co-exist 100% when not being used so it's  no longer a compile time option). 
• User cache garbage colleciton
• Updated authentication framework. Authentication scheme and access control (including IP address movement, user expiry timeouts) are now disjointed.
• Nearly complete authentication rewrite.
• Full reconfigure support (Prior to this squid does not expire users in the user cache according to the new authenticate ttl).
• Dynamic Authentication scheme support. Squid only offers and accepts the authentication scheme that helpers are defined in squid.conf for. I.E. if you need Basic support, simply list an authenticate_program.
• NTLM usernames are logged as domain\user, not domain%5cuser.
• At a source level authenticate.c now handles nearly all the authentication functionality, and acl.c the access controls. This should allow easy integration of digest/kerberos etc as acl.c should need minimal (if any) changes.
• acl match caching for proxy_auth and proxy_auth_regex with authenticated users. This means that if you have long proxy_auth or proxy_auth_regex acls, repeated requests for a given username (even from
  multiple workstations) will short-circuit the username matching. For sites with 1000's of users, or complex regex's this should produce substantial CPU savings.
• New config directive authenticate_cache_garbage_interval to tune user cache garbage collection.
• multiplexed ntlm helper requests. fake_auth has been updated, I'm not sure whether the NTLMSSP helper will respond 'optimally' to this or not. It should work though (I can't test it :-[)
• (hopefully) generally cleaner interfaces internally, should be a lot easier to add digest et al in the future.
• Stateful helpers.
• Samba based backend for the ntlm scheme.
• "Fakeauth" backend - Extracted and hacked up copy of Andy Dorans' code. Sorry Andy but I've left it in a real mess :-[
  

Future things that would be nice to do (that this work makes easier/is needed for)

• Finish the authentication framework so we have an API for adding authentication schemes. (This is in progress).
• Digest authentication
• Kerberos authentication
• A win32 ntlm_helper for cygwin. This could use the LSASS on windows NT and would be _very_ simple. (Any win32 programmer that want to help, I'll give you all the doco you could want on what squid needs :-])

Assorted notes from Andy Doran:

Current status

• It seems fairly stable.
• Works with both IE4/IE5 on 95 and NT. The only difference between NT and 95 is that 95 doesn't like Unicode. NT works fine with ASCII though, so this isn't a problem.
• For every connection that IE opens, we get two TCP_DENIED messages in access.log while it authenticates (negotiation + authentication). This is a bit irritating.

Authenticator interface

The implementation I have (authenticator module only right now) implements a simple text based protcol that (a) passes basic intialisation information (b) does authentication queries, as you'd expect and (c) allows the authenticator module to track connection state for the benefit of authentication methods that require handshaking.

It's implemented using a library (libauth) that provides the foundation. The actual authenticator module code provides 3 methods - open(), close() and query(), making it pretty simple to write to.

I'm not clear on how this would affect performance

Proxying of NTLM web authentication

NTLM authentication is proxyable provided the client is willing to do NTLM WWW authentication through a proxy, there are two basic reasons I can think of: Squid isn't passing the authentication info correctly (i.e. all messages should be during 1 persistant connection for each authentication attempt) or IIS is checking the workstation/domain name.

I've managed a couple of FreeBSD firewals before and seen a lot of WINS queries directed at them. I don't know if it's related.

If I had the time I'd personally follow this through, but I'm working 13 hour days right now. Proxy authentication is a small part of that though.

Note from Henrik: It can. There is noting in NTLM authentication which makes it impossible to proxy, besides the fact that it requires a single persistent connection client<->origin server, with any number of proxies/tunnels in between. There is a very notable collision between RFC 2616 and MS NTLM authentication in that RFC 2616 advocates that client<->proxy and proxy<->origin connections are more or less independent by each other, while MS NTLM requires them to be tightly coupled as one connection.

Notes from Henrik:

Design ideas

I have now got a fair understanding of the NTLM authentication sheme. Next step would be to figure out how to correctly fit this in Squid...

• Most people interested in NTLM authentication want to do so against a domain controller of some kind. Then the challenge must be generated by the domain controller, not Squid, else there is no way to forward the authention to the domain controller.
• NTLM can be useful even without domain controller capability if you can accept some security-by-obscurity. Squid can "easily" fetch the logged in username from a faked NTLM authentication session.
• NTLM authentication can only be done on a persistent connection by design (NTLM uses randomly generated challenges). This applies both to the client->squid connection and squid->domain login controller connection, so it effectively requires an per connection persistent associaion client->squid->domain login controller session.

One approach would be to simply add the NTLM+RPC code to Squid, but it is a fairly large chunk of code needed, and I am not aware of any non-blocking implementation of the DCE-RPC (or whatever the RPC used by SMB/LM/CIFS is called) freely available.

The approach I am leaning towards is some more generalized approach to authentication with (for NTLM) sticky authenticators on a per client connection basis. The idea is to find a authenticator module method suitable for all three commonly used authentication methods (Basic, Digest, NTLM). Squid should only concern itself with the minimal decoding required to find the username, and caching of authentication responses. The rest should be handed off to the authenticator (probably as-is). I have yet to study some of the details of Digest authentication to find out what requirements that makes on Squid, so this picture may be slightly revised..

There is also need for a user-group concept. In some cases this can be joined with the authenticator, in other cases the need is separately on a per group basis. What I am leaning towards on this issue is to have two acl types:

auth_group: Membership indicated by the authenticator process.

group: Membership queried by a per group+username(or ident)+ip basis wia external helpers.

A third concept missing from Squid is divided user spaces, where one segment of the network is one domain of users and another segment is another domain of users. The way I see this solved is to add a authentication class directive, and have the authentication made and cached within that class.

auth_class company1 src 10.0.1.0/24 192.168.1.0/24
auth_class company2 src 10.0.2.0/25 192.168.2.0/24

This can also be generalized to have classes where authentication is unique on a IP basis
auth_class specialclass* src 192.168.3.0/24
where speciallclass* is a psuedo class with one unique class per IP within that range, all named specialclass in access checks outside the authentication.

The one ip per user limit I introduced earlier would be effective within each unique auth_class.

NTLM web/proxy authentication

NTML is a bit different and does not obey the standard rules of HTTP connection management. The authentication is a three step (5 way) handshake per TCP connection, not per request.

1a. Client sends unauthenticated request to the proxy / server.

1b. Proxy / server responds with "Authentication required" of type NTLM.

2a. The client responds with a request for NTLM negotiation

2b. The server responds with a NTLM challenge

3a. The client responds with a NTLM response

3b. if successful the connection is authenticated for this request and onwards. No further authentication exchanges takes place on THIS TCP connection.

From step 2 and onwards the connection MUST be persistent, or the whole thing has to start over from the beginning. The response in step 1 does not need to keep the connection persistent. However, as it still must eat any request body it might just as well keep the connection persistent all the way, unless there is a compability problem with other browsers preventing this.