Evaluation of Filtered ACLS

Filtered ACL evaluation behaves significantly differently than non-filtered ACLs. The default behavior of filter based ACLs is to accumulate upward along the ancestor chain, from the lowest to highest containing entry in the Directory Information Tree (DIT).

The effective access is determined by joining the access rights granted or denied by the constituent ancestor entries. The only exception to this behavior is if replication is enabled. In that case a ceiling attribute is used to stop accumulation at the entry in which it is contained.

The set of access control attributes used specifically for filter based ACLs are:

• ibm-filterACLEntry
• ibm-filterACLInherit

The ibm-filterACLEntry specifies the effective access that applies to the target object based on: non-filter ACLs, or filter ACLs, depending on how they have been distributed in the DIT.

The ibm-filterACLInherit is the ceiling attribute which is used to stop accumulation at the entry in which it is contained.

Return to top of page

Example:
Refer to Appendix with title "Filtered ACLs and non-filtered ACLs – sample LDIF file" at the end of Directory Server Administration Guide (Knowledge center links: V10.0.x, V6.4, V6.3.1) and issue following search: (see version specific search commands below)

# idsldapsearch -D cn=root -w secret -b "o=Level43,o=Level32,o=Level21,o=Level11,o=IBM,c=US" -s base "objectclass=*" aclpropagate aclsource entryowner ownerpropagate ownersource ibm-filterAclEntry ibm-filterAclInherit ibm-effectiveAcl

Search Results:
o=Level43,o=Level32,o=Level21,o=Level11,o=IBM,c=US
ibm-filterAclInherit=TRUE
ownersource=default
ownerpropagate=TRUE
aclsource=O=LEVEL43,O=LEVEL32,O=LEVEL21,O=LEVEL11,O=IBM,C=US
aclsource=O=LEVEL32,O=LEVEL21,O=LEVEL11,O=IBM,C=US
entryowner=access-id:CN=ROOT
ibm-effectiveAcl=access-id:CN=USER1,O=IBM,C=US:normal:rwsc:sensitive:rwsc:critical:rwsc
ibm-filterAclEntry=access-id:CN=USER1,O=IBM,C=US:(o=Level43):normal:rwsc:sensitive:rsc:critical:rwsc

Return to top of page

ACL Evaluation:
This entry is a simple example of how filtered ACLs accumulate. The filtered ACL defined on the o=Level32,o=Level21,o=Level11,o=IBM,c=US entry is combined with the filtered ACL defined on the o=Level43,o=Level32,o=Level21,o=Level11,o=IBM,c=US entry to give read, write, search and compare access to all three classes of attributes for user 1.

The "ibm-effectiveAcl" shown in the above search results shows the accumulation of access. As highlighted below, on the "o=Level32" entry, a filtered ACL was set on "o=Level43" which grants the CN=USER1 user to have read, write, search, compare access on the normal and sensitive classes of attributes. It also grants read, search and compare for the critical class of attributes but not write access.

The filtered ACL defined on the "o=Level43" entry grants the CN=USER1 user to have read, write, search, compare on the normal and critical classes of attributes. It also grants read, search and compare for the sensitive class of attributes but not write access.

The "ibm-effectiveAcl" is determined by accumulating upward along the ancestor chain, from the lowest to highest. In this case we join the filtered ACLs from "o=Level32" and "o=Level43". This results in the CN=USER1 user being granted read, write, search and compare on the normal, sensitive and critical classes of attributes.

Entry for "o=Level32"

dn: o=Level32, o=Level21, o=Level11, o=IBM, c=US
o: Level32
objectclass: organization
objectclass: top
ibm-filterAclEntry: access-id:CN=USER1,O=IBM,C=US:(o=Level42):normal:rwsc:
sensitive:rsc:critical:rsc
ibm-filterAclEntry: access-id:CN=USER1,O=IBM,C=US:(o=Level43):normal:rwsc:
sensitive:rwsc:critical:rsc
ibm-filterAclEntry: access-id:CN=USER2,O=IBM,C=US:(o=Level44):normal:rwsc:
sensitive:rsc:critical:rsc

Entry for "o=Level43"

dn: o=Level43, o=Level32, o=Level21, o=Level11, o=IBM, c=US
o: Level43
objectclass: organization
objectclass: top
ibm-filterAclEntry: access-id:CN=USER1,O=IBM,C=US:(o=Level43):normal:rwsc:
sensitive:rsc:critical:rwsc

Return to top of page
 

---

 

Version Specific Search Commands for Gathering ACL information

	Version 8.0.1, 6.4, 6.3.1, 6.3, 6.2 and 6.1
	Version 6.0
	Version 5.2

---

 

IBM Tivoli Directory Server 8.0.1, 6.4, 6.3.1, 6.3, 6.2 and 6.1

Command Syntax for gathering ACL information:

idsldapsearch -p <port #> -D <admin DN> -w <admin DN password> -b "your base DN" -s base "objectclass=*" +ibmaci

Return to top of page
 

IBM Tivoli Directory Server 6.0

Command Syntax for gathering ACL information:

idsldapsearch -p <port #> -D <admin DN> -w <admin DN password> -b "your base DN" -s base "objectclass=*" aclentry aclpropagate aclsource entryowner ownerpropagate ownersource ibm-filterAclEntry ibm-filterAclInherit ibm-effectiveAcl

Return to top of page
 

IBM Tivoli Directory Server 5.2

Command Syntax for gathering ACL information:

ldapsearch -D <admin DN> -w <admin DN password> -b "your base DN" -s base "objectclass=*" aclentry aclpropagate aclsource entryowner ownerpropagate ownersource ibm-filterAclEntry ibm-filterAclInherit ibm-effectiveAcl

Return to top of page