The following two examples show an administrative subdomain being established. The first example shows a single user being assigned as the entryOwner for the entire domain. The second example shows a group assigned as the entryOwner.
entryOwner: access-id:cn=Person A,o=IBM ownerPropagate: true entryOwner: group:cn=System Owners, o=IBM ownerPropagate: true
The next example shows how an access-id "cn=Person 1, o=IBM" is being given permissions to read, search, and compare attribute1. The permission applies to any node in the entire subtree, at or below the node containing this ACI, that matches the "(objectclass=groupOfNames)" comparison filter. The accumulation of matching ibm-filteraclentry attributes in any ancestor nodes has been terminated at this entry by setting the ibm-filterAclInherit attribute to "false".
ibm-filterAclEntry: access-id:cn=Person 1,o=IBM:(objectclass=groupOfNames):
at.attribute1:grant:rsc
ibm-filterAclInherit: false
The next example shows how a group "cn=Dept XYZ, o=IBM" is being given permissions to read, search and compare attribute1. The permission applies to the entire subtree below the node containing this ACI.
aclEntry: group:cn=Dept XYZ,o=IBM:at.attribute1:grant:rsc aclPropagate: true
The next example shows how a role "cn=System Admins,o=IBM" is being given permissions to add objects below this node, and read, search and compare attribute2 and the critical attribute class. The permission applies only to the node containing this ACI.
aclEntry: role:cn=System Admins,o=IBM:object:grant:a:at.
attribute2:grant:rsc:critical:grant:rsc
aclPropagate: false