RE: I know the Problem with ntlm

> > > Thomas,
> > > can you please cc your replies on this discussion to the list: I
> > > am not the only squid-ntlm developer.
> > >
> > > Hacing looked into case-sensitivity for usernames, I don't know if
> > > ldap/unix systems will allow test and Test to be
> different usercodes,
> > > but in case they do I am not going to make the username check
> > > case-insensitive for that reason. What I will do is make
> sure that the
> > > username returned from NTLM is always uppercase.
> >
> > I can do that at the authenticator level, only with lower case
> > (it's just a matter of personal taste, I dislike upper-case).
> > If you want, I can make a command-line switch to change the
> behavior.
> > The check against the domain is case-insensitive anyways...
> > This is exactly the reason why I implemented the case-insensitive
> > switch for http_auth acls. I don't know whether it's in the current
> > CVS, if not I can send you a patch.
>
> I can't recall the results of the discussion on squid-dev,
> but as it applies
> to all auth acls I think it is a 'bad thing'. Still if the
> helper can be
> consistently lowercase that'd solve one of Thomas's issue

Basically it was said "it works, but it's a hack. Be it known.
It can be solved much better with splay trees. Re-implement that
with splay trees". Which is what I'm going to do as soon as I can
get the "new and improved" NTLMSSP authenticator to work.
My system is now really live, with a peak load of about 100 reqs/sec
(I still don't know how much that is compared to others' loads),
and it's beginning to feel the strain. I need to save
those extra CPU cycles. Pity I can't profile on a live system,
it would be nice to know what hogs most. But all those memory
accesses to verify the authorization aren't for sure doing
much good to the CPU's data cache.

> > > The usernames are of the format domain\user because that
> is the couple
> > > used by MS who wrote the spec. (It's not a feature it's what
> > > the decode
> > > process returns).
> >
> > I did it for consistency with the Microsoft Proxy behaviour.
> > It would be nice however if logged entries weren't URLencoded,
> > at least as far as the \ character goes.
> >
> > > A similar issue exists with domain names where you
> > > have www.foo.net or www. Just using www can result in
> > > confusion. So just
> > > using GOEBELT could be a problem. I.E. what if you have two user
> > > domains, and a repeated username across them?
> >
> > With the current domain code, it shouldn't work at all.
> > The domain is _required_.
> >
> > > What we could do is get the helper to return just the
> > > username component
> > > (turned on or off with a command switch) - kinkie what do you
> > > think? The
> > > helper should do it as it is where caching and
> optimisations are being
> > > placed at this point.
> >
> > Cannot do. What about the case where you have user foo\bar
> and gazonk\bar
> > then? No, the domain part is to remain. Blame Microsoft for such a
> > dumb design.
>
> What if the user has only one domain, and like it that way?
> their choice...

True, but if they're not in a domain (ANY domain), no auth will
take place at all. Whom would you check the auth against?
Maybe we could make a special-case "*" domain, meaning
"check against the default domain as defined in the conf-interface".
But it could be tricky, or it could not work at all.

> Anyway lets move these details over to squid-dev, or offline?

squid-dev sounds fine.

-- 
	/kinkie