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
> > (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 ?
>
> 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.
As anybody had such accounts locking problems ? If so, Could they share with us
how they prevented these lockouts from happening ?
Thanks,
Andrew
