[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Authentication Methods for LDAP - last call



Paul Leach wrote:
> 
> > > As will all the ACLs on which the user's DN is present.
> >
> > ACLs can be fixed by a brute-force query-replace on the directory.
> > Password verifiers can't.
> 
> You've missed a slight problem of scale in the real world.
> The user's DN is on ACLs could be on 100s of directory servers in just one
> organization, and could be on ACLs in 1000s of organizations' directories
> world-wide. And in integrated environments, they could be on the ACLs on
> files on possibly 10,000 file servers, just in one organization. Result: a
> brute-force query-replace is not feasible.
> 
> It's like saying that brute force can defeat any encryption algorithm (given
> enough time) -- true but not relevant.
> 
> And how do you change a user's DN in scripts that munge ACLs?

Just a small side comment on user DNs in ACLs. The
maintenance of ACLs can be quite a nightmare for this
very reason. Which is why I advocate access control
schemes that require far fewer ACLs, generally do not
require changing ACLs in individual entries, and do not
require changing ACLs when entries move.

We've implemented an ACL scheme with these properties.
Basically, the idea is to use the content of entries to
determine which ACLs apply. Users who want different
ACLs to apply simple change the content of their entry
(if allowed), not the ACL itself. LDAP filters are
very useful for this purpose. We've found it cuts down
on ACL maintenance and problems with maintenance pretty
dramatically.

Anyway, ACLs hard-coded in scripts are still a problem,
but it seems like we are improving the world if we don't
require password changes when entries move. Saying that
other things will need to be changed anyway is not really
an argument for not improving the world.

Every little bit helps.         -- Tim