It is possible to use ACI (access control information) that is resident inside the DIT, as opposed to
external access control definitions in slapd.conf or access.conf. The primary advantages to this are:
1. Access control info can be modified on-the-fly with no need to restart the server$
($ since 2.3, this is also possible with regular ACLs, using cn=config).
2. Access control info can be centrally managed and replicated with slurpd#
(# since 2.4, this will likely be possible with regular ACLs as well,
by applying sync replication to cn=config).
3. Access can be programmatically pre-resolved and updated*.
(* means if you are very careful and plan accordingly.
This is not universal by any means).
The disadvantages are:
1. There is no regex matching for subjects or objects.
2. Inheritance is not supported. Each object REQUIRES discrete controls+
(+ no longer true: see "children" and "subtree" scope).
3. Interaction between ACL and ACI can be hard to manage since ACI can
only handle a subset of masks exposed by ACLs. ACI is not independent
of other rules, and is generally subordinate.
4. Not too many people are using this feature, so documentation and testing
may be very sparse.
5. Syntax is vendor-specific and may not play well with others.
|