Re: [ldapext] Fwd: I-D ACTION:draft-behera-ldap-password-policy-08.txt

[Neil Dunbar <neil.dunbar@hp.com>]

On Tue, 2004-10-26 at 14:54 +0200, Ludovic Poitou wrote:

> There are cases where replicating these attributes has a cost higher 
> than the benefits.
> When the Directory Servers are behind a load balancer, applications need 
> a consistent view.
> But when the service is geographically distributed and the 
> authentications are mainly local to one server (with a possible 
> failover), then keeping the attributes per server is really acceptable.
> The policy could be understood as "5 consecutive failed attempts on a 
> machine and you're out of this machine"

I see what you're saying - but what you're then doing is placing the
semantics of an Information Security policy into the hands of the LDAP
operations/design teams. I'm not sure too many InfoSec people would like
that notion. In other words, if the LDAP ops team deploy another 20
servers, they're not going to ask their security teams to validate that
installation - they're just going to do it. But that would have the
effect of adding a boatload of extra guessing capability into the
password protection mechanisms. If the rest of the passwords constraints
aren't up to that, then you might well be compromising baseline
security.

I suppose you could always redirect binds from read-only replicas
towards a writeable replica. That way you're guaranteed to maintain
consistency across the domain. Similarly, I suppose you could use
network segmentation to restrict the LDAP servers that you can bind to
from a particular part of the network.

I still think the draft should comment on the issues arising from
replication, since it's far from obvious what needs to be done in all
cases.

Cheers,

Neil


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext