Propagating ACLs

ACLs can be set on any entry in the hierarchy. ACLs (including ACL filters) can propagate through the directory hierarchy. These ACLs, called propagating ACLs, have the aclPropagate attribute set to TRUE. All descendants of this entry inherit the ACL set at that point, unless overridden. In order to specify an ACL different from that of its parent, a new ACL must be explicitly set.

When setting the new ACL, there is again a choice of whether to propagate the ACL. If set to TRUE, the ACL propagates down to all descendants. If set to FALSE, the ACL is not propagated; it instead becomes an override ACL. The ACL is not propagated through the hierarchy, but instead applies only to the one particular entry that it is associated with within the hierarchy. If unspecified, aclPropagate is set to TRUE.

An entry without an explicit ACL receives its ACL from the nearest propagating ancestor ACL. If there is no propagating ACL, the entry receives the default ACL. Propagated ACLs do not accumulate as the depth in the tree increases. The scope of a propagated ACL is from the explicitly-set propagating ACL through the tree until another explicitly-set propagating ACL is found.

The same rules apply to propagating the entry owner permissions (including ACL filters for entry owners) based on the ownerPropagate attribute.

Example of propagation

Following is the explicit ACL for entry ou=deptXYZ, o=IBM, c=US:

aclPropagate:  TRUE
aclEntry: group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc
aclEntry: access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rwsc:critical:rsc
aclEntry: group:cn=Anybody:normal:rsc
aclSource: ou=deptXYZ, o=IBM, c=US

In the absence of an explicit ACL for entry cn=personA, ou=deptXYZ, o=IBM, c=US, the following is the implicit, propagated ACL for the entry:

aclPropagate: TRUE
aclEntry: group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc
aclEntry: access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rwsc:critical:rsc
aclEntry: group:cn=Anybody:normal:rsc
aclSource:ou=deptXYZ, o=IBM, c=US

In this example, a propagating ACL is set on ou=deptXYZ, o=IBM, c=US. No ACL is set on the child cn=personA, ou=deptXYZ, o=IBM, c=US. Therefore, the child inherits its ACL value from the nearest ancestor with a propagating ACL. This happens to be ou=deptXYZ, o=IBM, c=US, which is reflected in the aclSource attribute value. The aclEntry and aclPropagate values are identical to those values in the explicit propagating ACL set at ou=deptXYZ, o=IBM, c=US.

Examples of overrides

Following is an explicit ACL for entry o=IBM, c=US:

aclPropagate:  TRUE
aclEntry:   group:cn=IBMRegs, o=IBM, c=US:normal:rcs:sensitive:rsc
aclEntry:   group:cn=Anybody:normal:rsc
aclSource:  o=IBM, c=US

Following is an explicit ACL for entry ou=deptXYZ, o=IBM, c=US:

aclPropagate: FALSE
aclEntry: group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc
aclEntry: access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rwsc:critical:rsc
aclEntry: group:cn=Anybody:normal:rsc
aclSource: ou=deptXYZ, o=IBM, c=US

Note that in the explicit ACLs above, aclSource is the same as the entry DN. This attribute is generated and managed by the LDAP server; it cannot be set when modifying ACLs.

Following is an implicit ACL for entry cn=personA, ou=deptXYZ, o=IBM, c=US:

aclPropagate:  TRUE
aclEntry:  group:cn=IBMRegs, o=IBM, c=US:normal:rcs:sensitive:rsc
aclEntry:  group:cn=Anybody:normal:rsc
aclSource:  o=IBM, c=US

In this example, a propagating ACL is set on o=IBM, c=US. An override ACL is set (aclPropagate is FALSE) on the child ou=deptXYZ, o=IBM, c=US. Therefore, the ACL set at ou=deptXYZ, o=IBM, c=US pertains only to that particular entry.

The child cn=personA, ou=deptXYZ, o=IBM, c=US inherits its ACL value from the nearest ancestor with a propagating ACL (which is o=IBM, c=US as reflected in the aclSource). The ACL on ou=deptXYZ, o=IBM, c=US is not used because aclPropagate is FALSE.

Other examples

In these examples, the root administrator DN or adminDN configuration option is cn=admin, c=US.

The following example shows the default ACL:

aclPropagate:  TRUE
aclEntry: group:cn=Anybody:normal:rsc:system:rsc
aclSource: default
ownerPropagate:  TRUE
entryOwner:  access-id:cn=admin,c=US
ownerSource:  default

The following example shows a typical ACL for entry cn=personA, ou=deptXYZ, o=IBM, c=US:

aclPropagate:  TRUE
aclEntry:  group:cn=deptXYZRegs, o=IBM, c=US:normal:rcs:sensitive:rsc
aclEntry:  access-id:cn=personA, ou=deptXYZ, o=IBM, c=US:object:ad:normal:rwsc:sensitive:rwsc:critical:rsc
aclEntry:  group:cn=Anybody:normal:rsc:system:rsc
aclSource:  ou=deptXYZ, o=IBM, c=US
ownerPropagate:  TRUE
entryOwner:  access-id:cn=deptXYZMgr, ou=deptXYZ, o=IBM, c=US
ownerSource:  ou=deptXYZ, o=IBM, c=US

This is an inherited ACL and an inherited owner. Both owner properties and ACL properties are inherited from entry ou=deptXYZ, o=IBM, c=US. In this example, members of group cn=deptXYZRegs, o=IBM, c=US have permission to read, search, and compare attributes in both the normal and sensitive attribute access classes. They do not have permission to add or delete entries under this entry. Nor do they have permission to access any information or change any information about attributes in the critical attribute access class. Unauthenticated, and all other bound users, have permission to read, search, and compare attributes in the normal and system attribute access classes only. The personA has add and delete permission on the entry; read, write, search, and compare permissions on normal and sensitive attributes; and read, search, and compare permission on critical attributes. The deptXYZMgr had full access to the entry because it is the owner of the entry. As always, an LDAP root or directory data administrator have unrestricted access to the entry.