Re: [squid-users] NTLM or fakeauth_auth
Quoting Amos Jeffries squ...@treenet.co.nz:
On Tue, 08 Sep 2009 17:54:28 +0200, apmail...@free.fr wrote:
Quoting Amos Jeffries squ...@treenet.co.nz:
On Tue, 01 Sep 2009 15:38:24 +0200, apmail...@free.fr 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
Re: [squid-users] NTLM or fakeauth_auth
Quoting Henrik Nordstrom hen...@henriknordstrom.net: tis 2009-09-08 klockan 17:54 +0200 skrev apmail...@free.fr: Still, is it possible to present specific autentication schemes depending on the useragent ? Not yet. 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 ? From what I remember AD allows for bad NTLM logins with an old password for quite some time without locking the account, to avoid the issue with shares/applications continuing using the old password after the user have changed his password. But if using Negotiate (kerberos) then this pretty much should be a non-issue as Kerberos is ticket based and not directly derived from the password, or at least that's my understanding. I too was thinking of implementing kerberos, with the assumption (still to be verified) that those annoying pieces of software going to internet without the user's full knowledge ( a***e updater for instance ) would not implement this scheme. Will keep you posted, Thanks
Re: [squid-users] NTLM or fakeauth_auth
Quoting Amos Jeffries squ...@treenet.co.nz:
On Tue, 01 Sep 2009 15:38:24 +0200, apmail...@free.fr 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
Re: [squid-users] NTLM or fakeauth_auth
tis 2009-09-08 klockan 17:54 +0200 skrev apmail...@free.fr: Still, is it possible to present specific autentication schemes depending on the useragent ? Not yet. 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 ? From what I remember AD allows for bad NTLM logins with an old password for quite some time without locking the account, to avoid the issue with shares/applications continuing using the old password after the user have changed his password. But if using Negotiate (kerberos) then this pretty much should be a non-issue as Kerberos is ticket based and not directly derived from the password, or at least that's my understanding. Regards Henrik
Re: [squid-users] NTLM or fakeauth_auth
On Tue, 08 Sep 2009 17:54:28 +0200, apmail...@free.fr wrote:
Quoting Amos Jeffries squ...@treenet.co.nz:
On Tue, 01 Sep 2009 15:38:24 +0200, apmail...@free.fr 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
[squid-users] NTLM or fakeauth_auth
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 ? (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. 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. 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 ? I figure playing with useragent strings wouldn't be enough, because Opera can easily masquerade as IE (or used to). Thank you for your ideas. Andrew
Re: [squid-users] NTLM or fakeauth_auth
On Tue, 01 Sep 2009 15:38:24 +0200, apmail...@free.fr 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'.
(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.
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.
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
