9:23 p.m.
Hello,
Thanks to everyone having answered me earlier, I've managed to set up
password policy on the OpenLDAP provided in CentOS 5.5 repositories
(current version 2.3.43).
The setup: we have password policy enabled for users accounts in our
intranet. After 5 unsuccessful attempts the account is blocked for short
duration (30 seconds).
Does that mean that anyone now can keep all the accounts blocked most of
the time? Am I right that if anyone enters someone else' incorrect
password 5 times (in the given case), they will block the target account
(regardless of what IP address the attacker was connecting from)?
Narrower question: do password policy module developers plan to take
into account what IPs are used to connect (thus, blocking only access
from specific IPs)?
Thanks.
All the best,
Konstantin
11:29 p.m.
On Tuesday, 1 March 2011 07:23:41 Konstantin Boyandin wrote:
Hello,
Thanks to everyone having answered me earlier, I've managed to set up
password policy on the OpenLDAP provided in CentOS 5.5 repositories
(current version 2.3.43).
The setup: we have password policy enabled for users accounts in our
intranet. After 5 unsuccessful attempts the account is blocked for short
duration (30 seconds).
Does that mean that anyone now can keep all the accounts blocked most of
the time?
Well, you do the maths.
But, surely you have enough monitoring in place that you would be able to
notice a high rate of unsuccessful binds, so that the duration of "most of the
time" would not be very long.
Am I right that if anyone enters someone else' incorrect
password 5 times (in the given case), they will block the target account
(regardless of what IP address the attacker was connecting from)?
Yes. But, where is the line between a DoS and an attempt to break into an
account?
In either case, if this *is* only in your intranet, behaviour like this would
surely violate your terms of use policy ...
Narrower question: do password policy module developers plan to take
into account what IPs are used to connect (thus, blocking only access
from specific IPs)?
Maybe you should provide a specific use case, besides "my users violate my
terms of use, and I can't do anything about it".
Regards,
Buchan
12:01 a.m.
Hello Buchan,
01.03.2011 13:29, Buchan Milne writes:
On Tuesday, 1 March 2011 07:23:41 Konstantin Boyandin wrote:
> Hello,
>
> Thanks to everyone having answered me earlier, I've managed to set up
> password policy on the OpenLDAP provided in CentOS 5.5 repositories
> (current version 2.3.43).
>
> The setup: we have password policy enabled for users accounts in our
> intranet. After 5 unsuccessful attempts the account is blocked for short
> duration (30 seconds).
>
> Does that mean that anyone now can keep all the accounts blocked most of
> the time?
Well, you do the maths.
But, surely you have enough monitoring in place that you would be able to
notice a high rate of unsuccessful binds, so that the duration of "most of the
time" would not be very long.
While I am talking of the intranet, I feel I am in control. Logs are
monitored and if someone causes repetitive account lockouts, it's easy
to detect.
Problems can happen when there is need to open certain services from
outside (email, for example).
> Am I right that if anyone enters someone else' incorrect
> password 5 times (in the given case), they will block the target account
> (regardless of what IP address the attacker was connecting from)?
Yes. But, where is the line between a DoS and an attempt to break into an
account?
In either case, if this *is* only in your intranet, behaviour like this would
surely violate your terms of use policy ...
Of course.
> Narrower question: do password policy module developers plan to
take
> into account what IPs are used to connect (thus, blocking only access
> from specific IPs)?
Maybe you should provide a specific use case, besides "my users violate my
terms of use, and I can't do anything about it".
A typical use case is this. We make users change their passwords
regularly, password policy was introduced to further urge to use safer
credentials.
Now imagine a person's email being checked regularly from outside the
intranet. After the specified attempts the account gets locked. The only
option we have in such a case is to firewall the address that sends
wrong credentials.
In case the locks are IP-bound, they would only affect those attempting
to gain access (regardless of whether those are legitimate or
unauthorized attempts).
Thanks.
Sincerely,
Konstantin
12:36 a.m.
----- "Konstantin Boyandin" <temmokan(a)gmail.com> wrote:
>> Narrower question: do password policy module developers plan
to
take
>> into account what IPs are used to connect (thus, blocking only
access
>> from specific IPs)?
>
> Maybe you should provide a specific use case, besides "my users
violate my
> terms of use, and I can't do anything about it".
A typical use case is this. We make users change their passwords
regularly, password policy was introduced to further urge to use
safer
credentials.
Now imagine a person's email being checked regularly from outside the
intranet. After the specified attempts the account gets locked. The
only
option we have in such a case is to firewall the address that sends
wrong credentials.
There are other options. ppolicy is not meant to prevent attacks on accounts, but to try
and prevent attacks on accounts being successful. Prevention (or other responses) are only
possible if the attacks are detected. If you want attackers to be able to make as many
attempts as they like to try and compromise accounts, you would be better off without
ppolicy.
In case the locks are IP-bound, they would only affect those
attempting
to gain access (regardless of whether those are legitimate or
unauthorized attempts).
But it opens you up to making it easier for attackers to brute-force your accounts.
However, in your scenario of a user's email account being attacked, to LDAP, the
client IP address is that of your mail server, so having IP-specific lockout would not
help you.
Regards,
Buchan
4478
days inactive
4478
days old
openldap-technical@openldap.org
3 comments
2 participants
participants (2)
-
Buchan Milne -
Konstantin Boyandin