RE: NTLM authentication, recent logs for Robert Collins

> Sorry to blather around again, but I read the logs
> intensively myself and
> made some observations.

No prob. I STILL haven't had the time to go over your logs,
but I'll try to comment this mail all the same.

> One thing first, forget about the PHEIN.. user, his authentication
> looked up until reboot, I'd say its a different problem maybe
> not related
> or just a consequence of earlier problems.

Ok.

> In all other cases I made the following observations:
>
> 1) the authentication cache is pretty ineffective. Actually its still
> surprisingly effective. It would be better IMHO if same
> users always
> ended up on the same ntlm-auth process. Maybe make a cheap hash
> (sum over user name string characters) and use it to map to the
> ntlm-auth process. For load balancing maybe send requests
> to the next
> free ntlm-auth process. But then remember where that user was
> authenticated and send all following requests for him to the same
> process.

It depends on your definition of "user". If with youser you
mean a domain\username entity, we can't do that. We get
to know that only at the end of the authentication handshake.
If you mean IP address, that could maybe be arranged. Performance
would decrease probably. The ntlm cache Robert wrote last week
should help greatly improve the hit-ratio and the overall performance.

> Ideally there should be one process per user and the pw
> cache in squid
> itself (or shared mem between ntlm-auth processes), IMHO.

The former is not a good idea (too many processes),
the latter is done.

> 2) Authentication never fails the first time. Or other way
> around, when
> Authentication has failed and we got disconnected, after
> the reconnect
> when (libntlmssp.c:153):Connecting to server was printed.
> Then the next authentication succeeds (even when for the
> same user).

Might be some problem with the challenge renewal? Actually
it's even likely. This might be a design error, which will need
to get addressed, and might be a consequence of our "ignorance is
bliss" approach.

The scenario might be something like this:

-client asks for a challenge
-client is served a challenge
-challenge is renewed (this is done via a disconnect/reconnect)
-client asks for an auth
-auth is denied, as the challenge doesn't match anymore.
 Client gets rejected.

I thought there were protections against this behaviour,
but it might be I missed something.
Please try a bigger challenge expiry timeout, and see if
the problem occurs with an increased frequency: currently the
renewal interval is set to 1 minute by default, try setting that
to 1 hour.

> This does not hold for the automatic reconnects now done. But I
> heard something this is also due to the now invalidated challenge?
>
> Anyway, urgent question/suggestion (might even try to hack it together
> tonight): What happens if we voluntarily disconnect after
> each successful
> Authentication? I'd really like to have that as an option to
> ntlm_auth.

That will be added as soon as I can get to work on that.
Be warned though that this will be an horrible performance hit,
both in terms of response time and in terms of DC load.

> Maybe the DC just thinks: Hey you process on TCP/netbios
> session xyz on
> machine abc, you really should decide now as which user you
> want to run.

MAYBE there is some kind of timeout requiring a certain time
between authentications, to fight brute-force-guessing
password-attacks.

> I think for safety we really should startup a new socket
> with a new TCP origin port for each authentication. I think
> it's really
> interesting to see how every connection dies after 1 or 2 successful
> attempts in a row. I don't know why its sometimes up to 3, maybe some
> time matters come in here, or there are other limits based on the
> TCP origin port which I didn't see.

We'll try that.

> It would explain too why test installions with a single or
> very few users
> seem to work but if you have one or two handfuls (5-10) it already
> breaks down.

Possible. If that's the case, maybe a delay in the decoders might be
enough. Caching is too good a performance gain to pass over so lightly.

> 3) And at last a question: What would happen if I restrict myself to 1
> ntlm process (to increase cache hits). Assume I'd accept it slowing
> down authentication a bit. But if there is currently no
> authenticator
> free, will it just block and wait for a free one or does
> the user get a
> definitive error?

It will wait.

-- 
	/kinkie
--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html