Access control changes

If a Modify DN operation is accompanied by the newSuperior parameter, changes in effective ACLs and in effective ownership of the relocated entries may result. Regardless of the effective ACLs which applied to the moved subtree in its old location, the moved subtree inherits any propagating ACLs applying to the newSuperior entry. As a consequence, entries to which a user had access before the request might no longer be accessible by that user, and entries to which access was denied for a given user before the request is accessible by that user.

Explicit ACLs in the entry or subtree override propagating ACLs. All explicit ACLs which were in the moved subtree at its original location move along with the entries.

When renaming a DN, it is possible that ACLs and entryOwners containing the renamed DN are modified. Therefore, before such a move or rename, users should carefully consider how ownership and accessibility to entries protected by these attributes might change after the move, and what ACL and ownership changes might be wanted, if any.

The following is an example of how a Modify DN operation might affect access controls:
ModifyDNRequest ::= {
entry            o=Athletics, o=Human Resources, o=Deltawing, c=AU
newrdn           o=Adult Athletics
deleteoldrdn     FALSE,
newSuperior      ou=Sport, ou=Vision On Demand, o=Deltawing,c=AU
}


ldapmodrdn -h ldaphost -p ldapport -D binddn -w passwd -s "ou=Sport,
 ou=Vision On Demand, o=Deltawing, c=AU" "o=Athletics,o=Human Resources,
 o=Deltawing, c=AU" "o=Adult Athletics"
Figure 1. Before Modify DN operation
Figure 2. After Modify DN operation
Assume that the entry with DN o=Human Resources, o=Deltawing, c=AU has an explicit propagating ACL containing the following aclEntry:
aclEntry: access-id: cn=Mark Edmondson, ou=Vision On Demand, ou=Delta Home Media Ltd.,
o=Deltawing,c=au:normal:rwcs:sensitive:rwcs:critical:rws:object:d
Also, assume that the entry with DN ou=Sport, ou=Vision On Demand, o=Deltawing, c=AU has an explicit propagating ACL containing the following aclEntry:
aclEntry: access-id: cn=Mark Edmondson, ou=Vision On Demand, ou=Delta Home Media Ltd.,
 o=Deltawing,c=au:normal:rws:sensitive:r:critical:r:object:a
If the user bound as DN cn=Mark Edmondson, ou=Vision On Demand, ou=Delta Home Media Ltd., o=Deltawing,c=AU performs the example Modify DN operation, there are at least two consequences that should be noted:
  • While this DN previously had rwcs permissions on sensitive attributes in the entry o=Athletics, o=Human Resources, o=Deltawing, c=AU and rws permissions on critical attributes in the same entry, this DN has only r access on both sensitive and critical attributes in the entry after the relocation. It might be expected that a given DN has the same accessibility to specific entries and data in the directory after a Modify DN operation as it had to those entries and data before the operation, but this example demonstrates that such an expectation is not valid.
  • If, after completion of the Modify DN operation, the bound user decides that they want to return the moved entry (and its subordinates) back to their original location in the directory hierarchy, this is not possible with the access controls currently in place. The bound DN has only object:d permission on the old superior node ("o=Human Resources, o=Deltawing, c=AU") where object:a is needed to affect the move of an entry or subtree under the superior node, and the bound DN has only object:a permission on the moved entry ("o=Adult Athletics, ou=Sport, ou=Vision On Demand, O=Deltawing, c=AU") where object:d is needed to move the entry. Therefore, while it might be expected that a given DN can reverse a Modify DN operation under all circumstances, this example demonstrates that such an expectation is not valid.