Quoting Amos Jeffries <squid3@xxxxxxxxxxxxx>:
> On Tue, 08 Sep 2009 17:54:28 +0200, apmailist@xxxxxxx wrote:
> > Quoting Amos Jeffries <squid3@xxxxxxxxxxxxx>:
> >
> >> On Tue, 01 Sep 2009 15:38:24 +0200, apmailist@xxxxxxx wrote:
> >> > Hello,
> >> >
> >> >
> >> > We are switching from an LDAP authentication to an AD one.
> >> > It works GREAT either with basic [password in clear :-( ] or ntlm
> >> > authentication schemes. SSO was also requested, and works great.
> >> >
> >> > We have one problem though :
> >> > - during the tests, some user accounts get locked very often. ( after
> 5
> >> > attempts).
> >> > We know it comes from software trying to connect to internet with
> older
> >> > passwords. But as we cannot guarantee it will not happen on a large
> >> > scale
> >> > when
> >> > we migrate,
> >> > ->> I am looking for a way to prevent these accounts getting locked.
> >
> > Still, is it possible to present specific autentication schemes depending
> > on the
> > useragent ?
> >
>
> Would be wonderful wouldn't it?
> Sadly, nobody has coded ACL control for auth_param usage yet.
> It might be possible if we can find someone with coding skills and time to
> do it.
>
Would be wonderful, yes :-)
But I'll try to do without it for now
> >
> >>
> >> What I would do in your place is setup an external ACL which accepted
> the
> >> Proxy-Auth header and processed it.
> >> Detect old-style logins and redirect to a special error page saying to
> >> change their settings.
> >> If the type is 'Basic' it returns OK. Otherwise ERR.
> >>
> >> external_acl_type oldAuthTest %{Proxy-Authentication} /bla.sh
> >> acl oldAuth external oldAuthTest
> >> deny_info http://blah.example.com/fix-your-proxy-login.html oldAuth
> >> http_access deny oldAuth
> >>
> >> ... http_access bits to do the new login stuff go below ...
> >>
> >> Amos
> >>
> >
> > Maybe I didn't explain clearly : it's not the migration process in itself
> > that
> > worries us. It's the everyday use of the future AD authentication :
> > Accounts
> > getting locked too often.
>
>
> By choosing to do locking at all you trade off having an account locked
> when attacked vs the frequency of it locking on the users own mistakes. By
> doing this you are gambling that the user is going to be smart enough to
> remember their access.
>
> You _will_ encounter users so dumb they lock their account on every second
> access. You _will_ at some point wish you never set this up. You might
> even be hit with an attack that made it worth using, (but which locks every
> single account...repeatedly).
>
> You _have_ to find all the ways false locking can happen and fix them
> properly or your security measure becomes worse than useless. The migration
> is the main process to find the worst and most obvious problems, making it
> bearable for the majority of users. Long term more devious ones will appear
> and need to be solved in turn. The only relief you have is the knowledge
> that as the systems mature the problems should be decreasing.
>
> Welcome to the world of security. :)
>
>
> > As anybody had such accounts locking problems ? If so, Could they share
> > with us
> > how they prevented these lockouts from happening ?
>
> These ways occur to me to solve it:
> - solving the problem causing the locking. Do this anyway!!
> - setting a high threshold on the lockdown.
> - setting a failure/time period ratio before locking.
> - not locking
>
> Amos
>
>
Again, I didn't describe the case fully (my fault, again).
We have some few pieces of software make attempts to access internet without the
user's full knowledge ( indeed they must have somehow, somewhere, sometime,
clicked blindlessly on a "I agree" button )
And it is these software that annoys us really, because they keep the proxy's
credentials in a secret place, and then makes numerous attempts to acces
internet. By so "attacking" the user's account, and locking it in a snap.
So, in this case, it is not really the dumb user's fault.
I agree with your proposals to solve the issue at it's root :
- disable auto-updates : we want this disabled anyway
(
http://blog.stealthpuppy.com/deployment/disable-adobe-updater-with-adobe-customization-wizard-8
)
- threshold : it's at a reasonable value right now ( but still not in the 100's)
I have just now discovered that it is maybe the second authentication scheme
that I had put into place as a failback ( or for non SSO-wise browsers, but I
believe they are not so many around these days )
I have a basic auth_param (/usr/bin/ntlm_auth) after the ntlm auth_param.
And a close watch to tcpdumps show that the "invalid" (old) credentials are
being sent in the basic way.
Strangely, the NTLM dialog stays stuck to the first NTLM_Negotiate, to which
squid doesn't reply with a NTLM_Challenge, but a 407, with only "basic"
Is squid replying without the NTLM Auth scheme because it has detected the
NTLM_Negotiate was incorrect ?
On the NTLM_Negotiate :
- the flags are the same,
- but the Proxy-Authorization: NTLM TlRBLABA is not the same as the one
presented by IE : the last character before the ==\r\n is different.
Proxy-Authorization: NTLM
TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==\r\n IE
Proxy-Authorization: NTLM
TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAAD2==\r\n Adobe updater
Here is the problem maybe ?
Adobe updater talking bad NTLM, Squid reverting to basic, and then Adobe Updater
sending saved-old-invalid credentials, 1 attempt per second with the basic
scheme, thus locking the account in less than 10 seconds. ( by the way it also
tries NTLM every second
So either I
-cut off the basic scheme, but I sense I might need it for some software ( av
updates, curl scripts, etc )
-cut off Adobe Updater and consorts
Andrew
