I came across these articles that may be of some use in this topic. I humbly admit that I am no expert on this topic, and these may not be of any use. Plus, I am not a fan of the product, but maybe it helps?
http://technet.microsoft.com/en-us/library/cc772726%28v=ws.10%29.aspx http://blogs.technet.com/b/askds/archive/2010/08/18/fine-grained-password-policy-and-urgent-replication.aspx Gabe On Wed, Apr 9, 2014 at 8:40 AM, Ludwig Krispenz <lkris...@redhat.com> wrote: > > On 04/09/2014 04:17 PM, Rich Megginson wrote: > >> On 04/09/2014 08:09 AM, Simo Sorce wrote: >> >>> On Wed, 2014-04-09 at 15:50 +0200, Ludwig Krispenz wrote: >>> >>>> Something like this is what we have experienced for real and cause >>>>> >>>> us to >>>> >>>>> actually disable replication of all the lockout related attributes >>>>> >>>> in >>>> >>>>> the past. >>>>> >>>> But also here it can get complicated, we cannot really use >>>> failedlogincount and replicate it, eg if it is "2" on each server an >>>> their are parallel login attempts, we would increment it to "3" and >>>> replicate, so we would have 3 on all servers, not what we wanted. >>>> We could replicate changes to lastfailedauth and when receiving an >>>> update for this attribute locally increase failedcount, but it would >>>> also have to be used for resets (deleting lastFailedAuth), but there >>>> could also be race conditions, maybe there are other local attrs >>>> needed. >>>> >>> Yes, the current mechanism is deficient in many ways. For example the >>> failedcount/lastfailedauth attibutes are really suboptimal, a better >>> mechanism woul dbe to have a failedauths (not plural) multivalued >>> attribute and just append dates there (perhaps pre/postfixed with the >>> replica idto avoid any possible conflict). This way if 2 servers are >>> being attacked simultaneously they still should replicate their own >>> failure and each server can see that 5 dates are present in the last X >>> minutes and quickly lock the user, nor failedcount would be necessary >>> and no races incrementing it would occur. >>> >> >> This is an interesting idea. Please file a ticket in the 389 trac >> explaining this. >> >> >>> The only issue would be in cleaning up the attribute to not let it grow >>> to much, but that could be accomplished by simply *not adding any more >>> failed counts once the account is locked (only logging locally that >>> someone tried to log in on a locked account) and deleting the attribute >>> completely when the acocunt is unlocked, this again would reduce the >>> attributes necessary for handling locking own to 1 from the current 3 >>> (lastsuccessauth/lastafiledauth/failedcounter) however it still does >>> nothing to solve replication issues and has other replication races >>> problems (not sure what happens if a server try store a new failed auth >>> date and the other is deleting the old values at the same time. >>> Perhaps deleting by value is safe enough and won't cause issues, >>> Deleting the whole attribute may cause issues instead). >>> >> >> Handling of simultaneous updates of multi-valued attributes and update >> resolution works well. >> >> >>> And the bad news: I claimed that the replication protocol ensures that >>>> the last change wins except for bugs, and looks like we have one bug >>>> for single valued attributes in some scenarios. I have to repeat the >>>> test to double check. >>>> The update resolution code for single valued attrs is a nightmare, >>>> Rich and I several times said we need to rewrite it :-( >>>> >>> Is there a ticket that tracks this and explains the issue(s) ? >>> >> >> https://fedorahosted.org/389/ticket/47442 >> > my scenario was slightly differenent, without modrdn, but delete:oldvalue, > add:newvalue[i] on three servers i=1,2,3 "simultaneously" > > >> >>> Simo. >>> >>> >> > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel >
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
