NTLM authentication popups, etc

I'm working on a couple of paid squid + active directory deployments
and they're both seeing the occasional NTLM auth popup happening.

The workaround is pretty simple - just enable the IP auth cache. This
however doesn't solve the fundamental problem(s), whatever they are.

The symptom is logs like this:

[2009/06/15 16:20:17, 1] libsmb/ntlmssp.c:ntlmssp_update(334)
  got NTLMSSP command 1, expected 3

And vice versa (expected 3, got 1.) These correspond to states in
samba/source/include/ntlmssp.h - 1 is NTLMSSP_NEGOTIATE; 3 is
NTLMSSP_AUTH.

The conclusion here is that there's a disconnect between the
authentication state of the client -and- the authentication state of
ntlm_auth.

I'm trying to eliminate the possibilities here.

The stateful helper stuff seems correct enough, so requests aren't
being queued to already busy stateful helpers.

The other two possibilities I can immediately think of:

* 1 - authentication is aborted somewhere for whatever reason; an
authentication helper is stuck at the wrong point in the state engine;
the next request coming along starts at NTLMSSP_NEGOTIATE but the
ntlm_auth helper it is handed to is at NTLMSSP_AUTH (from the partial
authentication attempt earlier); error
* 2 - the web browser is stuffing different phases of the negotiation
down different connections to the proxy.

Now, debugging (1) shouldn't be difficult at all. I'm going to try and
determine the code paths that lead to and from an aborted auth
request, add in some debugging and see if the helper is closed.

Debugging (2) without full logs (impractical in this environment) and
full traffic dump (again, impractical in production) is going to be a
bit more difficult. I'm thinking about adding some hacky code to the
Squid ntlm auth class which keeps a log of the auth blobs
sent/received from/to the client and ntlm_auth. I can then dump the
entire conversation out to cache.log whenever authentication
fails/errors. This should at least give me a hint as to what is going
on.

(1) can explain the client state == NTLMSSP_NEGOTATE but ntlm_auth
state is NTLMSSP_AUTH problem but not vice versa. (2) explains both.
It is quite possible it is the combination of both however.

Now, the reason this is getting somewhat annoying and why I'd like to
try and understand/fix it is that -another- problem seen by one of
these clients is negotiate/ntlm authentication from IE (at least IE8)
through Squid. I've got packet dumps showing the browser sending
different phases of the negotiation down separate proxy connections
and then reusing the original one incorrectly. My medium term plan is
to take whatever evidence I have of this behaviour and throw it at the
IE group(s) at Microsoft but in the short term I'd like to make
certain the proxy authentication side of things is completely
blameless before I hand off stuff to third parties.

Ideas? Comments?

adrian
Received on Tue Jun 16 2009 - 07:22:02 MDT