RE: NTLM authentication, recent logs for Robert Collins

> On Thu, 26 Oct 2000, Chemolli Francesco (USI) wrote:
>
> > 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.
> Oh, IC. I didn't know that.
>
> > 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.
> Done for a long time (1-2 weeks) or should I download a new
> CVS version?

I believe you should update, but I'll let Robert confirm this.

> I'm under the impression it does not work, at least there are plenty
> authentications for the same user. Maybe cause he started a second
> IE or it changed its 'key' (what is send to squid). At second glance
> I cannot find an instance where it does not find the exact
> same key on a
> second auth process. But I also cannot find one where it does.

Huh? I don't follow you.

What happens is that every helper has a key. When a client connects, it
gets handed that key and authenticates against that. So "what key will
it get" gets translated to "what helper will the client be connected to".
Let's say that helpers are numbered from 0 to N+1. A client will be
connected to helper K only if all helpers 0..K-1 are busy.
So the key each client will get is a semi-random function of the current
load.

> So in my case the same <user> is authenticated again and again
> (differing key (challenges?) until it finally fails.

Because it will be selected for different helpers. HTTP traffic
is quite bursty.

> > 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
>
> I already did that. It was one of my first reactions. I raised the
> housekeeping from 60 to 1800 then 3600 and the challenge refresh
> from 1800 default to 3600 then 7200.
>
> The problem stays but seems to be a *tiny little* less frequent.
> It's definitely more often than the challenge refresh time.

Ok.

> > 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.
>
> Well, I doubt it, since it already does that anyway because
> right now I
> already see every second or at least third actual
> authentication fail and
> lead to a reconnect. In the long term: Initial authentication
> of new IE to
> squid is already slow. If there are enough processes so each
> new user gets
> one I don't see a problem. Most of the time the ntlm-auth
> cache should be
> consulted.

This is the problem. If I am forced to issue new challenges
over and over again, the cache will be completely ineffective.

> For the moment I'd rather prefer a slow logon.

Sure.

> > It will wait.
>
> Yep, I got that hint from Robert before I had asked. We are
> trying that
> now. Stay tuned for results.

Thanks.

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