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(a)shutterfly.com>
>> 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(a)shutterfly.com Systems
>> engineer
>>
>>
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproje
>>
ct.org
>>
>>
>> _______________________________________________
>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.o
>> rg
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
--
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