RE: NTLM authentication, recent logs for Robert Collins

> -----Original Message-----
> From: Chemolli Francesco (USI) [mailto:ChemolliF@GruppoCredit.it]
> Sent: Friday, 27 October 2000 1:19 AM
> To: 'Dr. Michael Weller'; Chemolli Francesco (USI)
> Cc: Robert Collins; squid-users@ircache.net
> Subject: 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.
> > >

We only need the process for a user for two http requests. 1- to get the
challenge and 2- to perform the authentication. After that the helper is
not used for that connection again. If the user is active that may not
be for hours. Also running that many process _will_ create a thundering
herd on a busy cache. I estimate a single helper with multiplexed
requests (part of the rewrite code) can authenticate upwards of 20 users
without load problems. The DC may give us problems though.

> > > 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.

Michael, run ./configure --help. If you see --enable-ntlm-auth-caching
as an option, then you have one of the early in-squid-cache versions. I
have nearly finished a rewrite of the authentication system in squid
that should provide significant benefits on sites with long proxy_auth
ACL's, as well as providing better user access caching and
maintainability.

If you wish to try the in-squid-cache, beware - it is currently alpha
quality. The rewrite was undertaken to streamline the guts in squid, and
that should be usable in a test fashion by monday. (It works at the
moment, but it is at your own risk. Bugs accepted, but until the code is
100% complete, my focus is getting it 'out there'.

>
> > 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 less helpers increases the cache efficiency. Less NTLM helpers is a
*good thing*.

> > 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.
>

The ntlm challenge cache in squid is completely passive, and disjoined
from the DC connection which is maintained by the helper.

Rob

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