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
