Gerrard Geldenhuis wrote: >> -----Original Message----- >> From: 389-users-boun...@lists.fedoraproject.org [mailto:389-users- >> boun...@lists.fedoraproject.org] On Behalf Of Rich Megginson >> Sent: 12 November 2010 18:22 >> To: General discussion list for the 389 Directory server project. >> Subject: Re: [389-users] Bind to consumer binds to provider as well >> >> >>> I can imagine though that with this approach you can potentially have >>> >> more auth attempts than is allowed for. >> >> I guess we need some sort of fine grained approach, so that you would only >> chain certain operations, and only under certain conditions. What would >> that look like? >> > > Admittedly my knowledge of the internals is close to zero and I am not sure > what the list of possible operations are. > > I am also not aware what the motivation behind the current design is. > > We had a discussion about the different types of race conditions that one > might possibly run into. > A. Current behaviour > All bind requests go to master > Failed logins gets replicated back to consumer > > B. Suggested behaviour > All bind requests stay local > Failed bind requests gets chained back to master > Master replicates failed login attempts back to consumer. > > In both A and B you could have a higher number of attempts than is actually > allowed before the replicated failed login attempts gets written back to > consumer where it will stop the user authenticating. There is a marginal > potential for higher number of potential requests if you don't chain bind > requests. However this would probably only be exposed if someone is trying to > programmatically break the system as normal retry time on the console would > take longer than the time it would take to replicate failed login attempts > back. > > If the delay time between the consumer and the chaining backend is quite big > then it makes authenticating against the chaining backend rather slow and > takes away scalability in my opionion. Although you would need a very high > number of bind requests before it becomes a problem. Latency is really the > big issue here. > Are you using global password policy? > >>>> In order to have global password policy. Let's say for example that >>>> you have password policy which states accounts are locked out after 3 >>>> unsuccessful login attempts. If you have 5 directory servers, each >>>> with local password policy, that effectively means an attacker has 15 >>>> tries to guess the password instead of 3. >>>> >>>> >>>>> If we replicate changes down to the consumer how can the data be >>>>> >>>>> >>>> "fresher" than the consumer? >>>> >>>> > > ________________________________________________________________________ > In order to protect our email recipients, Betfair Group use SkyScan from > MessageLabs to scan all Incoming and Outgoing mail for viruses. > > ________________________________________________________________________ > -- > 389 users mailing list > 389-us...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/389-users >
-- 389 users mailing list 389-us...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
