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.
>> >
>> > I thought of two solutions :
>> >
>> > 1.
>> > I searched for a way to make Squid only ask 3 times in a row for a
>> > valid
>> > credential. But couldn't find it : Any clue ?
>>
>> Not possible. There is no such thing as a 'repeat' in HTTP. Every
>> request
>> is 'new'.
>>
>
> I was thinking of some kind caching , similar to
> authenticate_ip_shortcircuit_ttl
That would cache the first (possibly bad) set of credentials for N seconds
regardless of if they fixed their login correctly. Not exactly what you
seem to need.
>
>> > (After three bad attempts, Squid would not send a 407, but a 200 with
>> > the
>> > error
>> > page , maybe ?)
>> >
>> > 2.
>> > The other solution I went for was a more relaxed authentication scheme
>> > :
>> > using
>> > fakeauth_auth (NTLM), and basic as a failback for non-sso browsers.
>> > The idea is the following :
>> > IE ( the in-house main browser ) would send the windows credential in
a
>> sso
>> > way
>> > (thus the user is logged) in an automatic way (meaning the user
doesn't
>> see
>> > it,
>> > and cannot tamper the authentication). We rely on IE to send us the
>> > username
>> > (windows logon credential)
>> > Other browsers (FF) would use the basic scheme to send it's
>> > credentials.
>>
>> IE is the most limited of all browsers security-wise. Other web browsers
>> are mostly capable of NTLM and more advanced authentication Schemes
>> without
>> the bugs IE has.
>>
>> >
>> > The problem is that at least one browser that is NTLM-compatible
>> > (Opera)
>> is
>> > able
>> > to provide the user with a prompt during the authentication : And the
>> user
>> > may
>> > give any valid account, along with any password.
>>
>> This is true of _all_ web browsers.
>
> OK
>
>> > Here are the two lines :
>> > auth_param ntlm program /proxy3/libexec/fakeauth_auth
>> > auth_param basic program /proxy3/libexec/squid_ldap_auth -P -ZZ -v 3
>> > -c
>> 5
>> > -t 5
>> > -b ou=BLABLA -f(sAMAccountName=%s) -D "cn=reqaccount-BLABLA" -W
>> > /proxy3/etc/ldapauth_prd_secretfile -h dc002.fgn.com
>> > dc003.global.fgn.com
>> > Inverting the two lines forces all browsers to use the basic
>> > authentication.
>> > Is there a way to do NTLM only with SSO able browsers, and then revert
>> > to
>> > BASIC
>> > for all the others ?
>>
>> Yes. By using what you have configured above.
>> The problem you face is that Squid sends out a list of available
methods.
>> Then the browser chooses the authentication method its going to use and
>> sends credentials. If those credentials fail Squid responds with a
>> 407/'failed try again' and the browser does whatever it can to get new
>> credentials. Usually they start with a popup window to ask the user.
>>
>>
>> > I figure playing with useragent strings wouldn't be enough, because
>> > Opera
>> > can
>> > easily masquerade as IE (or used to).
>>
>> Agent strings is not relevant, only the credentials the browser pass to
>> Squid and the method chosen to send them.
>
> 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.
>
>>
>> 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
