Gerrard Geldenhuis wrote:
>>> Are you using Chain On Update for Binds?
>> We are indeed, we used that howto to set it up. Reading it now again it
> does say it will use the chaining backend for binds. Why is that?
Why is that? I don't know .
According the the wiki http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate
the consumer will use the chaining backend when I do bind/write requests.
I can understand why you would want to "centrally" manage login attempts but
would it not better to handle login attempts locally on the consumer and then only if a
login attempts fail and you need to do a write then write to the master.
If you are
using account policy you will need to keep track globally of
the last login time, so that you can expire the account globally 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?
> 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?
My sentence was less than ideal. If changes get replicated down then I agree data
everywhere should be equally fresh within the time constraints it takes to replicated
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