Gerrard Geldenhuis wrote:
> -----Original Message-----
> From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-
> bounces(a)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
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
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