On 01/17/2018 01:50 PM, Mark Reynolds wrote:
On 01/16/2018 07:28 PM, William Brown wrote:
On Tue, 2018-01-16 at 23:22 +0000, Mitch Patenaude wrote:
So the problems were
1) I needed to set 'passwordUnlock: on' even though that's supposed
to be the default value
2) In 'cn=config' I needed to set 'passwordIsGlobalPolicy: on' on
every server to enable replication of lockout params.
I wonder if either of these are bugs. Mark?
passwordIsGlobalPolicy is what you need to replicate these attributes - not a bug.
I think the reason it is off is that even when it is on we do not have a
real global account lockout management. replicating changes will
replicate the changes eg to failcount, but it is a replace operation,
which will be replicated, and as replication always has a latency, even
if it is very low you could have situations like this:
assume you 5 servers and have failcount == 0 everywhere, on all servers
simultaneously do a failed login, on each failedcount will changed to 1,
by doing replace(failedcount,1) and this will be replicated, in the end
you have 5 failed logins, but failedcount == 1 everywhere. and so on.
It can be even worse with specific timing. on sever 1 do 4 failed
logins, and before it is replicated do one on server2. the change on
server2 can have the highest csn and will win after replication, so it
will reset 4-->1 on server 1 and keep 1 on server 2, and you can start
again.
To get closer to a global policy we would first need to implement the
ldap-modify-increment operation (rfc4525), this would ensure that each
failed login is really counted. because of replication latency it could
still exceed the configured max fail count.
To do it absolutely we would need to define a "preferred" master,
changes to pw attribute would have to be chained to this master and the
replicated back, this gets complicated and we haven't yet talked about
failover of the preferred master.
So, enabling repl of pw policy attributes could make it more global, but
there are limitations. And so it is off by default and you need to know
what you do when you enable it
passwordUnlock is supposed to be "on" by default, but... If you use a subtree/user policy (aka local policy) the global policy default value of "on" is NOT picked up. That is a bug, and should of been fixed in https://pagure.io/389-ds-base/issue/49370, but in the patch passwordUnlock is not set to a default. I'll fix this today...
Thanks to Kevin Kelly for pointing me in the right direction. The
relevant documentation can be found here:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Serve
r/8.2/html/Administration_Guide/Managing_the_Password_Policy-
Configuring_the_Account_Lockout_Policy.html
-- Mitch
On 1/16/18, 1:44 PM, "Mitch Patenaude" <mpatenaude@xxxxxxxxxxxxxx>
wrote:
I'm trying to implement account lockouts for <n> failed login
attempts in a multi-master environment.
I used something like the following ldif to enable to lockouts:
dn:
cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com",cn=nsPwPolicyCont
ainer,ou=people,dc=example,dc=com
changetype: modify
add: passwordLockout
passwordLockout: on
-
add: passwordMaxFailure
passwordMaxFailure: 5
-
add: passwordResetFailureCount
passwordResetFailureCount: 1800
-
add: passwordLockoutDuration
passwordLockoutDuration: 1800
It works (kind of), but there are 2 problems:
1) Even though the passwordLockoutDuration is only 30 minutes, it
locks the user out indefinitely (i.e. accountUnlockTime:
19700101000000Z)
2) The accountUnlockTime attribute doesn't get replicated, so the
user is only locked out of 1 of the 4 master servers.
Any idea what I am doing wrong?
Thanks,
-- Mitch Patenaude mpatenaude@xxxxxxxxxxxxxx Systems
engineer
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@lists.fedoraproje
ct.org
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
rg
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
