Access control
This chapter covers ITDS Access Control Lists (ACLs) and how to manage them. ACLs provide a means to protect information stored in a LDAP directory. Administrators use ACLs to restrict access to different portions of the directory, or specific directory entries. LDAP directory entries are related to each other by a hierarchical tree structure. Each directory entry (or object) contains the distinguished name of the object as well as a set of attributes and their corresponding values.
14.1 Overview
Since directories are used for storing various kinds of data, ranging from publicly accessed to highly sensitive, and are accessed by different users, therefore it is of utmost importance to restrict users from tampering with other users’ data. For example, a user after logging in should not be allowed to delete or modify an entry which he did not create although he should be able to see it. This is achieved by implementing Access Control Lists (ACLs). ACLs are a means of controlling or restricting users from accessing different parts of the DIT.
The way access control is implemented in ITDS is as follows.
For each entry (In a directory server terms ‘dn’) that need to be access controlled, accompany it with the relevant list of the users and their corresponding permissions.
For example, if it is required to deny write access to a user “cn=user1,o=ibm,c=us” on the entry “ou=payroll,o=ibm,c=us” then we can do so by modifying the entry “ou=payroll,o=ibm,c=us”. The modification required is basically the addition of a new attribute, aclEntry to “ou=payroll,o=ibm,c=us“. However, if the entry “ou=payroll,o=ibm,c=us“ already contains aclEntry, do not worry, this is a multivalued attribute. Just add one more value to aclEntry and we are done.
Here is what we need to add to “ou=payroll,o=ibm,c=us”:
aclEntry=access-id:CN=USER1,O=IBM,C=US:normal:rsc:normal:deny:w
Do not worry too much on how exactly do we add this attribute to the desired entry or where all in the directory will that impact or what does “normal” mean, etc. We will cover this in this chapter. Currently it is essential to have just the meaning of the above line understood. The above line, when read in plain English, signifies that a user (access-id) with dn “cn=user1,o=ibm,c=us”, is:
(grant)ed (r)ead, (s)earch and (c)ompare access over the (normal) attributes.
(deny)ed (w)rite access over the (normal) attributes.
Please read the line of aclEntry and the description following it in parallel. Reading in this manner will make the concept of ACLs very easy to understand.
We have more forms of ACL specification. The above example explicitly sets ACLs for an access-id that is, a single user. Similarly we can set the ACLs for a group and make sure that all the users with alike permissions are put into the same group. There is more to it, as will be seen, when we traverse through the rest of this chapter.
14.2 ACL model
To begin with, let us see how the ACL model looks like. The ACL model is based on two sets of attributes:
The entryOwner information
The Access Control Information (ACI)
In conformance with the LDAP model, the ACI and the entryOwner information both are represented as attribute-value pairs. The LDIF syntax can be used to administer these values.
14.2.1 EntryOwner information
The entry owners have complete permissions to perform any operation on the object regardless of the aclEntry. Additionally, the entry owners are the only ones who are permitted to administer the aclEntries for that object. EntryOwner is an access control subject, it can be defined as individuals, groups or roles. The attributes that define the entryOwnership are:
entryOwner: Defines an entry owner
ownerPropagate: Specifies whether the owner set is propagated to the children.
 
Note: The directory administrator and administration group members are the entryOwners for all objects in the directory by default, and this entryOwnership cannot be removed from any object.
14.2.2 Access Control information
The ACI specifies a subject’s (user’s) permission to perform a given operation against a LDAP object. Do not confuse this with ACL. ACL is basically a cumulative set of the entry owners and the ACI.
ACI is further split, depending upon the way intended to specify the ACLs. We can specify the ACLs, whereby we specify a set of rights to the user “cn=user1,o=ibm,c=us” over the current object. The descendants also may get impacted depending upon the setting of the aclPropagate attribute. Such ACLs are known as non-filtered ACLs. On the other hand, we can also specify the set of rights to the user “cn=user1,o=ibm,c=us“ over a set of objects conforming to the filter “cn=a*”, which is a more generalized way of setting ACLs. Such ACLs are called filtered ACLs. It is as easy as that. Below is the classification in more detail.
Non-filtered ACLs
This type of ACL applies explicitly to the directory entry that contains them, but may be propagated to none or all of its descendant entries. The default behavior of the non-filtered ACL is to propagate. The attributes that define non-filtered ACLs are:
aclEntry - Defines a permission set
aclentry=access-id:CN=USER1,O=IBM,C=US:normal:rsc:normal:deny:w
aclPropagate - Specifies whether the permission set is propagated to the descendant entries
aclpropagate=TRUE
Consider Figure 14-1 for a better explanation of non-filtered ACLs.
Figure 14-1 A simple Directory Information Tree (DIT)
Suppose we define the acls at entry A as:
aclentry=access-id:CN=USER1,O=IBM,C=US:system:deny:rsc:critical:deny:rwsc:sensitive:deny:rwsc:normal:rsc:normal:deny:w:object:deny:ad:restricted:deny:rwsc
The above aclEntry is an example of defining non-filtered acls. There are two reasons for this being an example of non-filtered acls:
The attribute aclentry does not exist for non-filtered ACLs. For non-filtered ACLs we have the attribute ibm-filterAclEntry.
There is no mention of the filter of the affected objects.
Consider the DIT in Figure 14-1 on page 398. Suppose we define ACLs at A, specifying “cn=user1,o=ibm,c=us“ has write access over it. This is going to propagate down the tree till the leaves (If aclPropagate at A is set to true), or till the point where another set of explicitly ACLs have been defined, whichever happens to come earlier. In other words, if no other explicit ACLs have been defined at A1 and A3, both A1 and A3 will have the ACLs, as defined at A, that is, specifying a write access to “cn=user1,o=ibm,c=us” over them.
Filtered ACLs
Filter based ACLs employ a search, using a specified object filter, like “cn=user*”, to select the directory entries to which they apply.
 
Note: The key thing to remember in case of filtered ACLs is that the filter we’re specifying is for the objects that will be impacted and not the subject. This filter is often misread as the set of subjects, rather than objects.
The directory entry that contains the filter ACL will serve as the base of the search. The scope of the search will be subtree, which includes the “entry containing the filter”, as well as, zero, one, or more of its descendant entries.
Filter-based ACLs do not propagate in the same way that non-filter-based ACLs currently do. By nature, they inherently propagate to any comparison matched objects in the associated subtree. For this reason, the aclPropagate attribute, which is used to stop propagation of non-filter ACLs, does not apply to the new filter-based ACLs.
Consider our DIT in Figure 14-1 on page 398, if we set a filter ACL at A, with a filter (cn=a2*), then it would map to A2, and the filteracls would propagate to A2. There is not a means whereby, we can restrict ACL propagation, using attributes like aclPropagate, as like in case of non-filtered acls. This will not be the case if the ibm-filterAclInherit is set to false at A2. However, We will see that case later.
The default behavior of filter-based ACLs is to accumulate from the lowest containing entry, upward along the ancestor entry chain, to the highest containing entry in the DIT. The effective access is calculated as the union of the access rights granted, or denied, by the constituent ancestor entries. There is an exception to this behavior. For compatibility with the subtree replication feature, and to allow greater administrative control, a ceiling attribute is used as a means to stop accumulation at the entry in which it is contained. The ibm-filterAclInherit attribute is used as this ceiling attribute, which is explained later. Do not confuse this with aclPropagate. aclPropagate decides whether we can send the ACLs down the tree, whereas ibm-filterAclInherit tells where we are supposed to consider the filters defined above me, in the DIT, for access evaluation.
What this means is that if we deny write access to the filter cn=a* at the entry A to the user “cn=user1,o=ibm,c=us” and we grant access to the filter cn=a* at the entry A1, then at the time of access evaluation at A1/A3/A4 the access provided for the user at both A and A1 is taken into consideration, which happens to be an access of grant : write at A1 and an access of deny : write at A. Since deny is more stronger than grant, the effective access of user “cn=user1,o=ibm,c=us” over A1/A3/A4 turns out to be deny:write. That seems very much simple, is not it?
Filter based ACLs are maintained using the following attributes:
ibm-filterAclEntry: It is the same form as the aclEntry attribute but has an additional component called object filter.
ibm-filterAclInherit: When set to False, it terminates ACL accumulation. Its default value is True.
If this still seems confusing, do not worry, the following example would help.
Consider Figure 14-1 on page 398 again. Suppose we define a filter ACL entry as like below at the entry cn=a,o=ibm,c=us:
ibm-filterAclentry=access-id:CN=USER1,O=IBM,C=US:(cn=a*):object:deny:ad:normal:rwsc
Then, here is what we are providing the user “cn=user1,o=ibm,c=us”: Please note the filter first. The filter “cn=a*” means all the entries conforming to “cn=a*”, which are at or below the subtree “cn=a,o=ibm,c=us”, since that’s where this Filter ACL has been defined. Let us consider what we have granted/denied for the user cn=user1,o=ibm,c=us. The entries conforming to cn=a* are referred to as objects for the convenience of explanation, in the next two bullets.
user1 is (deny)ed (a)dd children under the current entry or (d)elete the current entry.
user1 is granted (r)ead, (w)rite, (s)earch and (c)ompare access over the objects.
The objects mentioned above are the set of entries, having DNs conforming to the filter cn=a*, that is, over the users A, A1, A2, A3 and A4 mentioned above.
The above example should definitely have brought forth a clearer picture of the filtered acls. How exactly they are setup and the relevant details are the subject matter of the rest of the chapter. So do not worry, please go ahead for further details.
 
Note: Given an entry in the DIT, we can specify either the non-filtered acls or the filtered acls over that entry. We cannot have a combination of both at the same given entry.
14.3 Access control attribute syntax
As indicated in “ACL model” on page 397, the ACL attributes can be managed using LDIF notation. The syntax of the filter ACL attributes are a minor modifications of the current non-filter based ACL attributes. The Backus Naur Form (BNF) for the ACI and entryOwner attributes is shown below:
<aclEntry> ::= <subject> [ ":" <rights> ]
<aclPropagate> ::= "true" | "false"
<ibm-filterAclEntry> ::= <subject> ":" <object filter> [ ":" <rights> ]
<ibm-filterAclInherit> ::= "true" | "false"
<entryOwner> ::= <subject>
<ownerPropagate> ::= "true" | "false"
<subject> ::= <subjectDnType> ':' <subjectDn> | <pseudoDn>
<subjectDnType> ::= "role" | "group" | "access-id"
<subjectDn> ::= <DN>
<DN> ::= distinguished name as described in RFC 2251, section 4.1.3.
<pseudoDn> ::= "group:cn=anybody" | "group:cn=authenticated" | "access-id:cn=this"
<object filter> ::= string search filter as defined in RFC 2254, section 4 (extensible matching is not supported).
<rights> ::= <accessList> [":" <rights> ]
<accessList> ::= <objectAccess> | <attributeAccess> | <attributeClassAccess>
<objectAccess> ::= "object:" [<action> ":"] <objectPermissions>
<action> ::= "grant" | "deny"
<objectPermisssions> ::= <objectPermission> [ <objectPermissions> ]
<objectPermission> ::= "a" | "d" | ""
<attributeAccess> ::= "at." <attributeName> ":" [<action> ":"]
<attributePermissions>
<attributeName> ::= attributeType name as described in RFC 2251, section 4.1.4. (OID or alpha-numeric string with leading alphabet, "-" and ";" allowed)
<attributePermissions> ::= <attributePermission> [<attributePermissions>]
<attributePermission> ::= "r" | "w" | "s" | "c" | ""
<attributeClassAccess> ::= <class> ":" [<action> ":"] <attributePermissions>
<class> ::= "normal" | "sensitive" | "critical" | "system" | "restricted"
Wondering what the above stuff is all about! The following lines would clarify the above contents in a more elaborate way.
14.3.1 Subject
Subject is the entry or entity which requests access to operate on a directory entry or object. It consists of a combination of DN-type and a DN. The valid DN types are access-Id, Group and Role.
For example, a subject might be "access-id: cn=personA, o=IBM” or “group: cn=deptXYZ, o=IBM". If a DN contains “:” (colon), it must be surrounded by double quotes. The double quotes which are parts a DN should be escaped with backslash character. All directory groups can be used in access control. Roles that are used in access control must have an objectclass of AccessRole.
 
Note: Any group of the type AccessGroup, GroupOfNames, GroupofUniqueNames, or groupOfURLs structural objectclasses or the ibm-dynamicGroup, ibm-staticGroup auxiliary objectclasses can be used for access control.
Roles and Groups have similar implementations but differ conceptually. A user belonging to a role is assumed to be possessing the necessary authorities that are required to do any job associated with that Role. With group membership, there is no such associated assumptions.
Roles are similar to groups in that they are represented in the directory by an object. Additionally, roles contain a group of DNs. Roles that are used in access control must have an objectclass of AccessRole.
Let us consider an example. We have a group of users who are part of the team A. Name this group as group A. Now define a role, “player of team A”. Now whoever conforms to the group A, or “player of team A” is a part of the team A. It is just a different perspective of looking at the same end-object.
14.3.2 Pseudo DNs
Pseudo DNs are maintained by the server and are used for Access Control. These pseudo DNs are used to refer to large number of DNs that possess a common characteristic in relation to either the operation being performed or the object on which the operation is being performed.
Three pseudo DNs are supported by LDAP Version 3 (just to mention that this is the version of LDAP that we are talking of and not the product itself):
access-id: cn=this
When specified as part of an ACL, this DN refers to the bindDN, which matches the DN on which the operation is performed. For example, if an operation is performed on the object "cn=personA, ou=IBM, c=US" and the bindDn is "cn=personA, ou=IBM, c=US", the permissions granted are a combination of those given to "cn=this" and those given to "cn=personA, ou=IBM, c=US".
Now the obvious question is where do we find the necessity of having a dn such as “cn=this” in my directory? Well, let us take an example to have this absorbed. Consider a directory for the employees of an organization as like the IBM Bluepages directory. We can find a lot of information in this directory pertaining to the employees. The user has the access to modify his/her information, as like his telephone number, contact number etc. but there are fields which can’t be edited by the employees, but only an administrator should, like his manager’s name. There is where we can definitely use the access-id cn=this and define the ACL to deny write on the relevant attributes.
group: cn=anybody
When specified as part of an ACL, this DN refers to all users, even those that are unauthenticated. Users cannot be removed from this group, and this group cannot be removed from the database.
Well, this group is problematic for somebody. If we fire a simple query like, “ldapsearch -s base objectclass=*”. That is, the root DSE search without any credentials, we are authenticated to the directory server with the default credentials of the group “cn=Anybody”. Consequently we are able to run the rootdse search successfully. Some people might say, all the data in my directory server is confidential. We are not ready to expose any of this information. How am we supposed to hide it, because all the “people in the world” are able to see it, being the members of the group “cn=Anybody”. that is, by firing anonymous searches.
 
Note: Searches against the directory server, which are fired without any credentials are also called Anonymous searches.
Well, there a lot of decent ways of getting around this problem. The simplest way is to block the anonymous searches to the directory server. The relevant settings are to made in the directory server via webadmin, as follows:
a. Connect to the directory server via the webadmin.
b. Click Manage connection properties.
c. Select the General tab.
d. By default the Allow anonymous connections check box is ticked.
e. Uncheck this check box.
Refer to Figure 14-2 on page 404 on how to disable anonymous access to the directory.
Figure 14-2 Disabling anonymous access to the directory
 
Note: Disallowing anonymous binds might cause some applications to fail.
The other ways to get over such an issue is to make use of ACLs, wherever necessary and enforce authenticated access. We can also make use of SSL to enforce secured access to our directory. Other way is to make use of plug-ins (written by self or have them written by some service personnel, but that will cost money). There are documents, shipped along with the directory server to write plug-ins. The main purpose of the plug-in is to filter the calls coming to the directory server. That is, listen to the calls to the directory server, before the server and if no proper credentials are accompanied by the client’s request, block that request and do not allow that to pass through.
The reason this group has been part of our implementation or in other words cannot be removed from the implementation is that this particular feature is part of the RFC 2251 of the LDAP protocol. Though some users do not like this feature, there are some other good reasons of keeping this group. Suppose there are a million users in our directory server. Suppose, we need to provide read access to everyone in our directory server. It is not wise enough to create a group of 1 Million members and provide a read access to this group at the relevant places. It is just a matter of tailoring the provided features to suit ones purpose.
group: cn=Authenticated
This DN refers to any DN that has been authenticated by the directory. The method of authentication is not considered.
"cn=Authenticated" refers to a DN that has been authenticated anywhere on the server, regardless of where the object representing the DN is located. It should be used with caution, however. For example, under one suffix, "cn=Secret", there could be a node called "cn=Confidential Material", which has an aclentry of "group:cn=Authenticated:normal:rsc". Under another suffix, "cn=Common", there could be the node "cn=Public Material". If these two trees are located on the same server, a bind to "cn=Public Material" would be considered authenticated, and would get permission to the normal class on the "cn= Confidential Material" object.
14.3.3 Object filter
This parameter applies to filtered ACLs only. The string search filter as defined in RFC 2254, is used as the object filter format. Because the target object is already known, the string is not used to perform an actual search. Instead, a filter-based compare on the target object in question is performed to determine if a given set of ibm-filterAclEntry values apply to it.
Let us have this more simplified. Consider our DIT of Figure 14-1 on page 398 again. Let us suppose we define a set of ACLs for the user “cn=user1,o=ibm,c=us” at the entry A, and the filter we specify is “cn=a*”. When we specify this filter, the directory server will not do an ldapsearch to find out the objects, matching the filter, and tell the user “cn=user1,o=ibm,c=us” : “Look! These are the set of objects that you have so-and-so access!” Instead, here is what the directory server would do. When we fire a query against an entry, authenticated as the user “cn=user1,o=ibm,c=us” the entry we are targeting upon, would be compared against the defined set of filters, till the top of the tree, or till the point that the filters can be chased, verify the permissions of the entry “cn=user1,o=ibm,c=us” over that entry. The filter chasing is avoided by specifying the ibm-filterAclInherit=false.
Depending upon the access rights calculated in this manner, either our intended operation succeeds or fails, for want of sufficient permissions.
14.3.4 Rights
Access rights can apply to an entire object or to attributes of the object. The LDAP access rights are discreet. One right does not imply another right. The rights may be combined together to provide the desired rights list following a set of rules discussed later. Rights can be of an unspecified value, which indicates that no access rights are granted to the subject on the target object. The rights consist of three parts:
Action
Defined values are grant or deny. If this field is not present, the default is set to grant.
Permissions
There are six basic operations that may be performed on a directory object. From these operations, the base set of ACI permissions are taken. These are: Add an entry, delete an entry, read an attribute value, write an attribute value, search for an attribute, and compare an attribute value.
The possible attribute permissions are: read (r), write (w), search (s), and compare (c). Additionally, object permissions apply to the entry as a whole. These permissions are add child entries (a) and delete this entry (d).
Table 14-1 summarizes the permissions needed to perform each of the LDAP operations.
Table 14-1 Permissions needed to perform LDAP operations
Operation
Permissions needed
ldapadd
add (on parent)
ldapdelete
delete (on object)
ldapmodify
write (on attribute being modified)
ldapsearch
search, read (on attributes in RDN)
search (on attributes specified in the search filter)
search (on attributes returned with just names)
search, read (on attributes returned with values)
ldapmodrdn
write (on RDN attribute)
ldapcompare
compare (on attribute being compared)
 
Note: For search operations, the subject is required to have search (s) access to all the attributes in the search filter or no entries are returned. For the ldapsearch to be successful, the subject is required to have search (s) and read (r) access to all the attributes in the RDN of the entries that are expected to be returned or these entries are not returned.
Access target
Access target refers to the scope to which the permissions apply. These permissions can be applied to the entire object (add child entry, delete entry), to an individual attribute within the entry, or can be applied to groups of attributes (Attribute Access Classes) as described below.
Attributes requiring similar access rights or permissions are grouped together in classes. Attributes are mapped to their attribute classes in the directory schema file. These classes are discrete that is, access to one class does not imply access to another class. Permissions are set with regard to the attribute access class as a whole. The permissions set on a particular attribute class apply to all the attributes within that access class, unless individual attribute access permissions are specified.
IBM defines five attribute classes that are used in evaluation of access to user attributes: Normal, sensitive, critical, system, and restricted. For example, the attribute commonName belongs to the normal class, and the attribute userPassword belongs to the critical class. All user defined attributes belong to the normal access class unless otherwise specified.
The system class attributes that apply to access control are:
 – aclSource: This attribute identifies the source from which a given entry is supposed to inherit ACLs.
 – ibm-effectiveAcl: This attribute gives the effective ACLs on an entry after taking into consideration all ACLs defined at self, the default ACLs and also the ACLs that are inherited.
 – ownerSource: This attribute identifies the source from which a given attribute is supposed to inherit its owner.
These attributes are maintained by the LDAP server and are read-only to the directory users and administrator.
The restricted class attributes that define access control are:
 – aclEntry: This attribute stores the information pertaining to non-filtered ACLs.
 – aclPropagate: This attribute indicates whether the ACLs defined at this level are supposed to be propagated down the tree.
 • aclPropagate=true indicates that the acls need to be propagated, or
 • aclPropagate=false indicates that the ACL propagation stops here.
 – entryOwner: This attribute stores information as to who exactly is the owner of a given entry.
 – ibm-filterAclEntry: This attribute stores the information pertaining to filtered ACLs.
 – ibm-filterAclInherit: This attribute indicates whether a given entry is supposed to inherit filter ACLs, from its ancestors, for evaluating effective access.
 – ownerPropagate: This attribute indicates whether the owner specified at a given entry is supposed to be propagated down the tree.
 • ownerPropagate=true indicates that the owner needs to be propagated.
 • ownerPropagate=false indicates that the owner need not be propagated.
By default all users have read access to the restricted attributes but only entryOwners can create, modify, and delete these attributes.
Here is an aclEntry for a user with the permissions set on different attribute classes:
aclentry=access-id:CN=USER1,O=IBM,C=US:system:deny:rsc:critical:deny:rwsc:sensitive:deny:rwsc:normal:rsc:normal:deny:w:object:deny:ad:restricted:deny:rwsc
The above line, when read in plain English, signifies that a user (access-id) with dn “cn=user1,o=ibm,c=us”, is:
(deny)ed (r)ead, (s)earch and (c)ompare access over the (system) attributes.
 
Note: Write to (system) attributes is denied by default for all users, including the directory administrator.
(deny)ed (r)ead, (w)rite, (s)earch and (c)ompare access over the (critical) attributes.
(deny)ed (r)ead, (w)rite, (s)earch and (c)ompare over the (sensitive) attributes.
(grant)ed (r)ead, (s)earch and (c)ompare access over the (normal) attributes.
(deny)ed (w)rite access over the normal attributes.
(deny)ed to (a)dd and (d)elete any (object) that is, children.
(deny)ed (r)ead, (w)rite, (s)earch and (c)ompare access over the (restricted) attributes.
 
Note: denied is deliberately put up as denied, just for the sake of making co-relation between the line of the aclentry and the relevant description easier.
14.3.5 Propagation
All entries in the directory may or may not have aclEntry or entryOwner explicitly defined on them. If either of these values is not explicitly defined, it is inherited from an ancestor entry in the DIT.
Each explicit aclEntry or entryOwner applies to the entry on which it is set. Additionally, the value might apply to all descendants that do not have an explicitly set value. These values are considered propagated; their values propagate through the directory tree. Propagation of a particular value continues until another propagating value is reached.
 
Note: Filter-based ACLs do not propagate in the same way that non-filter-based ACLs do. They propagate to any comparison matched objects in the associated subtree.
aclEntry and entryOwner can be set to apply to just a particular entry with the propagation value set to “false”, or to an entry and its subtree with the propagation value set to “true”. Although both aclEntry and entryOwner can propagate, their propagation is not linked in anyway.
The aclEntry and entryOwner attributes allow multiple values within the same entry, however, the propagation attributes, aclPropagate and ownerPropagate, can only have a single value within the same entry.
The system attributes aclSource and ownerSource contain the DN of the effective node from which the aclEntry or entryOwner are evaluated, respectively. If no such node exists, the value default is assigned.
Now we would consider some examples as to how the above defined attributes have been evaluated at different levels of the DIT.
Case 1: Here is the way of getting the aclSource, ownerSource, aclEntry and entryOwner for a given entry “o=ibm,c=us” via the command-line query “ldapsearch”:
D:>ldapsearch -s base -D <admin dn> -w <admin pw>-b o=ibm,c=us objectclass=* aclSource ownerSource aclEntry entryOwner
o=IBM,c=US
ownerSource=default
aclSource=default
entryOwner=access-id:CN=ROOT
aclEntry=group:CN=ANYBODY:system:rsc:normal:rsc:restricted:rsc
“o=ibm,c=us“ being the suffix entry the ownerSource and the aclSource are set to default. As seen, the entryOwner is the directory administrator (cn=root in this case) and the ACLs are the ones set by default that is, for cn=Anybody, as none have been set explicitly.
Case 2: Now let us see the same set of attributes for which we do not specify explicit ACLs, but which inherit from o=ibm,c=us, where we have not specified any ACLs either:
D:>ldapsearch -s base -D <admin dn> -w <admin pw> -b cn=user1,o=ibm,c=us objectclass=* aclSource ownerSource aclEntry entryOwner
cn=user1,o=ibm,c=us
ownerSource=default
aclSource=default
entryOwner=access-id:CN=ROOT
aclEntry=group:CN=ANYBODY:system:rsc:normal:rsc:restricted:rsc
As seen above, the ownerSource and the aclSource are still set to default. Do you not think that these values have been set so, as their parent that is, o=ibm,c=us has not been set with any explicit value? There is no harm in believing so.
Time to prove it.
Case 3: If we set some ACLs at o=ibm,c=us as “aclEntry=access-id:CN=USER1,O=IBM,C=US:object:ad:normal:r”, then here is what we get for the same set of attributes:
D:>ldapsearch -s base -D <admin dn> -w <admin pw> -b cn=user1,o=ibm,c=us objectclass=* aclSource ownerSource aclEntry entryOwner
cn=user1,o=ibm,c=us
ownerSource=default
aclSource=O=IBM,C=US
entryOwner=access-id:CN=ROOT
aclEntry=access-id:CN=USER1,O=IBM,C=US:object:ad:normal:r
Did you notice the aclSource being modified to o=ibm,c=us? That is the way it goes.
Case 4: Now let us see the same attributes for an entry which comes below “o=ibm,c=us“, in the DIT. we have defined explicit ACLs at the entry which we are searching in this case:
D:>ldapsearch -s base -D <admin dn> -w <admin pw> -b ou=Payroll,o=ibm,c=us objectclass=* aclSource ownerSource aclEntry entryOwner aclPropagate
ou=payroll,o=ibm,c=us
aclPropagate=TRUE
ownerSource=default
aclSource=OU=PAYROLL,O=IBM,C=US
entryOwner=access-id:CN=ROOT
aclEntry=access-id:CN=USER1,O=IBM,C=US:system:deny:rsc:critical:deny:rwsc:sensitive:deny:rwsc:normal:rsc:normal:deny:w:object:deny:ad:restricted:deny:rwsc
As seen above, the ownerSource is still default. Since ACLs have been explicitly defined at this entry, the aclSource happens to be the same entry. we have shown here one more flag aclPropagate, for a specific reason, which would be clearer down the line.
Case 5: Now let us see the same set of attributes for an entry which is actually inheriting ACLs from an entry, where ACLs were explicitly defined. The same attributes for an entry below ou=Payroll,o=ibm,c=us would be seen as:
D:>ldapsearch -s base -D <admin dn> -w <admin pw> -b cn=accountant,ou=Payroll,o=ibm,c=us objectclass=* aclSource ownerSource aclEntry entryOwner
cn=accountant,ou=payroll,o=ibm,c=us
ownerSource=default
aclSource=OU=PAYROLL,O=IBM,C=US
entryOwner=access-id:CN=ROOT
aclEntry=access-id:CN=USER1,O=IBM,C=US:system:deny:rsc:critical:deny:rwsc:sensitive:deny:rwsc:normal:rsc:normal:deny:w:object:deny:ad:restricted:deny:rwsc
As seen above the aclSource happens to be “OU=PAYROLL,O=IBM,C=US“, which happens to be its parent entry and we do not have o=ibm,c=us anywhere in the picture. The reason for this, of course you might have guessed by now, that the aclPropagate at ou=Payroll,o=ibm,c=us was set to true. Curious to know what happens if we set the same to false? Check out the next case.
Case 6: Let us see the result in that case:
D:>ldapsearch -s base -D <admin dn> -w <admin pw> -b cn=accountant,ou=Payroll,o=ibm,c=us objectclass=* aclSource ownerSource aclEntry entryOwner
 
cn=accountant,ou=payroll,o=ibm,c=us
ownerSource=default
aclSource=O=IBM,C=US
entryOwner=access-id:CN=ROOT
aclEntry=access-id:CN=USER1,O=IBM,C=US:object:ad:normal:r
Is that not what you were expecting? The ACLs from o=ibm,c=us are inherited in this case, rather than ou=Payroll,o=ibm,c=us.
Let us sum this up. An object's effective access control definitions can be derived by the following logic:
If there is a set of explicit access control attributes at the object, then that is the object's access control definition.
If there is no explicitly defined access control attributes, then traverse the directory tree upwards until an ancestor node is reached with a set of propagating access control attributes.
If no such ancestor node is found, the default access, as described in the following section, is granted to the subject.
 
Note: The attributes pertaining to ACLs, that is, aclEntry, entryOwner, aclPropagate, ownerPropagate, aclSource, ownerSource, ibm-filterAclEntry and ibm-filterAclInherit are operational attributes.In the sense that they do not get dumped when we run the db2ldif or the ldapsearch tool against the server. An explicit mention of these attributes is required while firing ldapsearch, for these to get dumped. Examples of how to get up to the ACL attributes has already been explained in the CASEs mentioned lately.
14.3.6 Access evaluation
Access for a particular operation is granted or denied based on the subject's bind DN for that operation on the target object. Processing stops as soon as access can be determined.
The checks for access are done by first determining the entry ownership and then evaluating the object’s ACI values.
Filter-based ACLs accumulate from the lowest containing entry, upward along the ancestor entry chain, to the highest containing entry in the DIT. The effective access is calculated as the union of the access rights granted, or denied, by the constituent ancestor entries. The existing set of specificity and combinatory rules are used to evaluate effective access for filter based ACLs.
Filter-based and non-filter-based attributes are mutually exclusive within a single containing directory entry. Placing both types of attributes into the same entry is not allowed, and is a constraint violation. Operations associated with the creation of, or updates to, a directory entry fail if this condition is detected.
When calculating effective access, the first ACL type to be detected in the ancestor chain of the target object entry sets the mode of calculation. In filter-based mode, non-filter-based ACLs are ignored in effective access calculation. Likewise, in non-filter-based mode, filter-based ACLs are ignored in effective access calculation.
To limit the accumulation of filter-based ACLs in the calculation of effective access, an ibm-filterAclInherit attribute set to a value of “false” may be placed in any entry between the highest and lowest occurrence of ibm-filterAclEntry in a given subtree. This causes the subset of ibm-filterAclEntry attributes above it in the target object's ancestor chain to be ignored. The resulting access resolves to the default filter ACL value.
By default, the directory administrator, administration group members, and the master server (or peer server for replication, that is, ibm-slapdMasterDN) get full access rights to all objects in the directory except write access to system attributes. Other entryOwners get full access rights to the objects under their ownership except write access to system attributes. By default all users have read access rights to normal, system, and restricted attributes. If the requesting subject has entryOwnership, access is determined by the above default settings and access processing stops.
If the requesting subject is not an entryOwner, then the ACI values for the object entries are checked. The access rights as defined in the ACLs for the target object are calculated by the specificity and combinatory rules.
Specificity rule
The most specific aclEntry definitions are the ones used in the evaluation of permissions granted/denied to a user. The levels of specificity are:
Access-id is more specific than group or role. Groups and roles are on the same level.
Within the same dnType level, individual attribute level permissions are more specific than attribute class level permissions.
Within the same attribute or attribute class level, deny is more specific than grant.
For example, if a defined ACI entry contains an access-id subject DN that matches the bind DN, then the permissions are first evaluated based on that aclEntry. Under the same subject DN, if matching attribute level permissions are defined, they supersede any permissions defined under the attribute classes. Under the same attribute or attribute class level definition, if conflicting permissions are present, denied permissions override granted permissions.
Let us take some examples to absorb this.
Consider our DIT as in Figure 14-1 on page 398. Suppose we create a group and name it as “Group1”. We add “cn=user1,o=ibm,c=us” to “Group1”. Now at the entry A, we are setting two sets of ACLs: We are providing “rsc”, that is, (r)ead, (s)earch and (c)ompare access to “Group1” and denying write to it. Now when we bind as the user “cn=user1,o=ibm,c=us”, we are denied write on A, as the group to which we belong, is denied for writes. Now, we set the ACLs for user “cn=user1,o=ibm,c=us”, whereby we are giving write access to this user. Now, when we bind as “cn=user1,o=ibm,c=us”, what should we be allowed to do? We will be allowed to write, as the access-id is more specific than group. That clarifies point 1 specified above.
Now let us go to the next point. Suppose, in the entry A, we provide “rsc” access to “cn=user1,o=ibm,c=us” over the “normal attributes”. We provide the “rwsc” access to the same user over the attribute “telephoneNumber” for this entry. Now what should we be allowed to do with the attribute “telephoneNumber”, when we bind as the user “cn=user1,o=ibm,c=us”? Isn’t that obvious that we are given write access, though the corresponding attribute class (normal) is denied of the write? The reason being, of course that the attribute telephoneNumber is explicitly allowed for writes.
That should clarify point 2 mentioned above.
Now, let us go to the next point. Suppose we set the ACLs at entry A, with aclPropagate set to true. We set the ACLs whereby, we deny write to the attribute “telephoneNumber” in the entry A. That propagates down the tree and appears in A1, assuming that we have not specified ACLs explicitly at A1. Now even if we give a “rwsc” access to the user “cn=user1,o=ibm,c=us” over the attribute “telephoneNumber” in the entry A1, the user will not be allowed to write to that attribute, because the deny which propagated from the parent is more specific than grant. Hope this clears all the three rules of specificity.
Combinatory rule
Permissions granted to subjects of equal specificity are combined. If the access cannot be determined within the same specificity level, the access definitions of lesser specific level are used. If the access is not determined after all defined ACIs are applied, the access is denied.
For example, consider the two cases of ACIs defined on cn=user1,o=ibm,c=us described below:
Case 1:
 – access-id: cn=this: at.attribute1:grant:rws
 – access-id: cn=user1,o=ibm,c=us:at.attribute1:grant:rs:at.attribute1:deny:w
In the above case, the (w)rite permission on attribute1 will be denied to the user cn=user1,o=ibm,c=us as access cannot be explicitly determined.
Case 2:
(cn=user1,o=ibm,c=us belongs to group cn=group1)
 – access-id: cn=this: at.attribute1:grant:rws
 – access-id: cn=user1,o=ibm,c=us:at.attribute1:grant:rs:at.attribute1:deny:w
 – group:cn=group1:at.attribute1:grant:w
In this case, after failing to determine access at the specificity level of access-id, the access definitions of lesser specific levels (group) is determined. Since, the group has (w)rite permissions on attribute1, write permission will be granted to cn=user1,o=ibm,c=us.
That was simple stuff, we believe.
 
Note: After a matching access-id level aclEntry is found in access evaluation, the group level aclEntries are not included in access calculation. The exception is that if the matching access-id level aclEntries are all defined under cn=this, then all matching group level aclEntries are also combined in the evaluation.
A defined null value permission prevents the inclusion of less specific permission definitions.
Group and Role membership is determined at bind time and last until either another bind takes place, or until an unbind request is received. Nested groups and roles, that is a group or role defined as a member of another group or role, are not resolved in membership determination nor in access evaluation.
14.3.7 Working with ACLs
In this section we discuss working with ACLs.
Using the Web Administration Tool
This is to view ACL properties using the Web Administration Tool utility and to work with ACLs.
Select a directory entry. For example, ou=Payroll,o=ibm,c=US.
Click Edit ACL. The relevant panel shows up with the Effective ACLs tab preselected.
Refer to Figure 14-3 on page 416 on how to edit an ACL.
Figure 14-3 Edit ACL
This panel has five tabs:
Effective ACLs
Effective owners
Non-filtered ACLs
Filtered ACLs
Owners
The Effective ACLs and Effective owners tabs contain read-only information about the ACLs.
Figure 14-4 Effective ACLs
Effective ACLs
Effective ACLs are the explicit and inherited ACLs of the selected entry. We can view the access rights for a specific effective ACL by selecting it and clicking the View button. The panel (View access rights panel) in which we are supposed to click the View button is put up in Figure 14-3 on page 416. The following three sections appear, as shown in Figure 14-4.
The Rights section:
 – Add child grants or denies the subject the right to add a directory entry beneath the selected entry.
 – Delete entry grants or denies the subject the right to delete the selected entry. In the above example, the Add child and the Delete entry are left unspecified, which is taken as a “Deny”. Now the obvious query would be that if already have “Deny” in place, then why do we need to make use of “Unspecified“. Well, reason that the “Unspecified” is kept is that it is an indication that there would be no relevant definitions at this level of the DIT. The relevant values would be propagated by whatever gets propagated down the tree. In this case, there wasn’t as yet anything to propagate down the tree, hence this was left as Unspecified.
The Security class section defines permissions for security classes. Attributes are grouped into a set of classes, known as the security classes, depending upon the amount of security associated with them. Here are the list of possible security classes, an attribute may fall into:
 – Normal - Normal attributes are the ones requiring the least security, for example, the attribute commonName or cn.
 – Sensitive - Sensitive attributes are the ones requiring a moderate amount of security, for example homePhone.
 – Critical - Critical attributes are the ones requiring the most security, for example, the attribute userpassword.
 – System - System attributes are read only attributes that are maintained by the server.
 – Restricted - Restricted attributes are the ones, used to define access control.
Each security class has one or more of the following permissions associated with it:
 – Read - The subject can read attributes.
 – Write - The subject can modify the attributes.
 – Search - The subject can search attributes.
 – Compare - The subject can compare attributes.
Click OK to return to the Effective ACLs tab. Click Cancel to return to the Edit ACLs tab.
Effective owners
Effective owners are the explicit and inherited owners of the selected entry.
Refer to Figure 14-5 on page 419 for how this section appears in the Web Administration Tool.
Figure 14-5 Effective owners
Non-filtered ACLs
We can use this tab for adding new non-filtered ACL entries or modifying existing non-filtered ACL informations. When we click the Non-filtered ACLs link, we get a panel as shown in Figure 14-6.
Figure 14-6 Non-filtered ACLs
Supply the necessary information above, taking into consideration the following:
Propagate ACLs - Select the Propagate check box to allow descendants without an explicitly defined ACL to inherit from this entry. If the check box is selected, the descendent inherits ACLs from this entry and if the ACL is explicitly defined for the child entry, then the ACL which was inherited from parent is replaced with the new ACL that was added. If the check box is not selected, descendant entries without an explicitly defined ACL will inherit ACLs from a parent of this entry that has this option enabled. This point is already explained in our Case Studies earlier.
DN (Distinguished Name) - Enter the Distinguished name of the entity requesting access to perform operations on the selected entry, for example, cn=Marketing Group.
Type - Enter the Type of DN. For example, select access-id if the DN is a user.
Adding and editing access rights
There are two ways of setting the access rights on an object:
Click the Add button to add the current/new subject DN in the list of subject DNs (Distinguished Name). (or)
Select a dn from the existing list of subject dns and click the Edit button to modify the ACLs pertaining to the selected DN.
The Add access rights and Edit access rights panels, which appear after clicking Add or Edit, allows us to set the access rights for a new or existing Access Control List (ACLs). The Type field defaults to the type we selected on the Edit ACL panel. If we are adding an ACL, all other fields default to blank. If we are editing an ACL, the fields contain the values set last time the ACL was modified.
To set access rights in the Rights section:
Grant/Deny permissions to add a child.
Grant/Deny permissions to delete the entry itself.
Grant/Deny Read, Write, Search and Compare permissions to different security classes of attributes.
Define an attribute and explicitly Grant/Deny Read, Write, Search and Compare permissions to it. These permissions are more specific than the permissions on the attribute classes.
Refer to Figure 14-7 on page 421 for the panel where we are supposed to specify new/modify existing Access rights.
Figure 14-7 New ACLs specified
The panel to Edit ACLs is as like the above, the only difference being the title of “Edit Access Rights : <subject dn>”.
Removing ACLs
We can remove ACLs in either of two ways:
Select the radio button next to the ACL we want to delete. Click Remove.
Click Remove all to delete all DNs from the list.
Figure 14-8 on page 422 shows these buttons.
Filtered ACLs
This tab can be used for adding new filtered ACLs or editing existing filtered ACLs. When we click the Filtered ACLs tab, we get the following screen.
Figure 14-8 Filtered ACLs
We need to fill the following fields:
Accumulate filtered ACLs
 – Select the Not specified radio button to remove the ibm-filterACLInherit attribute from the selected entry.
 – Select the True radio button to allow the ACLs for the selected entry to accumulate from that entry, upward along the ancestor entry chain, to the highest filter ACL containing entry in the DIT.
 – Select the False radio button to stop the accumulation of filter ACLs at the selected entry.
DN (Distinguished Name) - Enter the (DN) Distinguished name of the entity requesting access to perform operations on the selected entry, for example, cn=manager,ou=hr,o=ibm,c=us.
Type - Enter the Type of DN. For example, select access-id if the DN is a user.
Once the above fields have been entered, we need to click the appropriate button that is, either Add, Edit, Remove or Remove All, depending upon what operation we want to do.
Adding and editing access rights
Click the either the Add button to add the DN in the DN (Distinguished Name) field to the ACL list or the Edit button to modify the ACLs of an existing DN.
Refer to Figure 14-9 for the add/edit access rights.
Figure 14-9 Add Filter ACLs
To set access rights:
1. In the Rights section:
a. Grant/Deny permissions to add a child.
b. Grant/Deny permissions to delete the entry itself.
2. In the Filter section, enter an object filter like objectclass=person, depending upon to which all descendant objects in the DIT this ACLs should apply. The current filtered ACL propagates to any descendant object in the associated subtree that matches the filter in this field. We have already dealt with filters in one of our earlier sections. Hope you remember the concept of filters! Feel free to go back and browse through the concept again, if needed.
3. Grant/Deny Read, Write, Search and Compare permissions to different attribute classes (security class).
4. Define an attribute and explicitly Grant/Deny Read, Write, Search and Compare permissions to it. These permissions are more specific than the permissions on the attribute classes.
Removing ACLs
We can remove ACLs in either of two ways:
1. Select the radio button next to the ACL, that you want to delete. Click Remove.
2. Click Remove all to delete all DNs from the list.
This is very much like the case of non-filtered ACLs.
Providing access on the attributes
This part is common to both the filtered and non-filtered ACLs. Suppose we want to specify the ACLs over the individual attributes here is how we do: Once the tab Add Access Rights comes up, where we specify the ACLs for the attribute classes or the permissions to add children, or delete entries, there is a section at the bottom with the heading Attribute, below which there is a drop-down of attributes. We select the attribute to be access controlled and click Define. We would get the selected attribute added on the panel, next to which there would be dropdowns for specifying the access-rights. If we do not specify any or if we click Cancel the attribute would go back to the dropdown and will not appear on the panel, else (that is, when we click OK) it would appear on the Panel. Figure 14-10 shows the attribute, once it is defined.
Figure 14-10 Portion of the panel for making attributes access controlled
If we need to delete the attribute, just select the attribute, using the check-box at the left of the attribute and click Delete.
Owners
Entry owners can be explicit or propagated (inherited).
Enter the following information on the Owners tab:
Select the Propagate owners check box to allow descendants without an explicitly defined owner to inherit from this entry. If the check box is not selected, descendant entries without an explicitly defined owner will inherit owner from a parent of this entry that has this option enabled.
DN (Distinguished Name) - Enter the Distinguished Name of the entity requesting access to perform operations on the selected entry, for example, cn=Marketing Group.
Type - Enter the Type of DN. For example, select access-id if the DN is a user.
Adding an owner
Click Add to add the DN (specified in the DN(Distinguished name) field) to the list of already existing Owners or it can be the first entry to click the list.
Figure 14-11 shows the panel for an entry, for which we have explicitly specified an owner, “cn=manager,o=ibm,c=us”:
Figure 14-11 Owners of an entry
Removing an owner
We can remove an owner in either of two ways:
Select the radio button next to the owner's DN that we want to delete. Click Remove.
Click Remove all to delete all owner DNs from the list.
That was all with the activities pertaining to ACLs that can be performed via the GUI. Let us see how the similar activities can be done via command line.
Using command line utilities to manage ACLs
The following sections provide information on how to use command line utilities to manage ACLs.
Adding ACIs and entry owners
The following example shows how to add an entryOwner(cn=owner,o=ibm,c=us) for a given entry (cn=person1,o=ibm,c=us). Create an ldif file say acl.ldif, with the following contents:
dn: cn=person1,o=ibm,c=us
objectclass: person
cn: person1
sn: person1
entryowner: access-id:cn=owner,o=ibm,c=us
ownerPropagate: True
Add the above LDIF using the following syntax:
# ldapadd -D <admin dn> -w <admin password> -f acl.ldif
In a similar manner, we can add a group or role as an entry owner. The above example was for an (access-id) as the entry owner. The other examples shown below, under the section of “Adding ACLs and Entry Owners” should follow similar method for the additions.
The next example shows how an access ID "cn=Person 1, o=IBM,c=US" is being given permissions to read, search, and compare the (at)tribute attribute1. The permissions apply 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 using our ceiling attribute. That attribute is the ibm-filterAclInherit attribute. It is been set to "false".
dn: cn=person1,o=ibm,c=us
objectclass: person
cn: person1
sn: person1
ibm-filterAclEntry: access-id:cn=Person1,o=IBM,c=US:(objectclass=groupOfNames):at.attribute1:grant:rsc
ibm-filterAclInherit: false
The next example shows how a role "cn=System Admins,o=IBM,c=US" is being given permissions to (a)dd objects below the node o=ibm,c=us, and (r)ead, (s)earch and (c)ompare (at)tribute attribute2 and the (critical) attribute class. The permission applies only to the node containing this ACI. This is achieved by setting the aclPropagate attribute to false.
dn: o=ibm,c=us
objectlass: organization
o: ibm
aclEntry: role:cn=System Admins,o=IBM:object:grant:a:at.attribute2:grant:rsc:critical:grant:rsc
aclPropagate: false
Modifying ACI and entryOwner values
Like other attributes, the ACL attributes (except the system attributes) can be modified using ldapmodify and follow the general syntax as shown below:
dn: some entry
changetype: modify
<action>: <acl-attribute>
<acl-attribute>: <value>
Where:
action (without the “<“ braces) is one of the following:
 – replace: If the attribute value does not exist, create the value. If the attribute value exists, replace the value.
 – add: If the ACI or entryOwner does not exist, the ACI or entryOwner with the specific values is created. If the ACI or entryOwner exists, then add the specified values to the given ACI or entryOwner.
 – delete: Deletes an ACL entry with a given value.
acl-attribute is one of entryOwner, ownerPropagate, aclEntry, aclPropagate, ibm-filterAclEntry, or ibm-filterAclInherit.
value is the value of the given attribute.
For example, consider any entry cn=person1,o=ibm,c=us with the following acl definition:
1) aclentry=access-id:CN=ABC:object:deny:d:object:a
2) aclentry=access-id:CN=P1,O=IBM,C=US:normal:rwsc:object:a
In order to remove the acl entry cn=ABC, the syntax of ldapmodify will be:
ldapmodify -D <admindn> -w <adminpw>
dn: ou=person1,o=ibm,c=us
changetype: modify
delete: aclentry
aclentry: access-id:CN=ABC:object:deny:d:object:a
 
Note: All the four lines after the line of ldapmodify, depicted above, can be put into an ldif file and that can be passed over to ldapmodify using the -f option. After all, ldapmodify and ldapadd ultimately boil down to the same utility.
After the above command, only the second (2) aclentry “aclentry=access-id:CN=P1,O=IBM,C=US:normal:rwsc:object:a” remains.
If in the above ldapmodify operation, the value of acl entry to be removed is given as:
ldapmodify -D <admindn> -w <adminpw>
dn: ou=person1,o=ibm,c=us
changetype: modify
delete: aclentry
aclentry: access-id:CN=ABC:object:deny:d
 
Note: We have not given the object add (object:a) permission in the aclentry value.
In such a scenario, both the acl entries will remain but the deny permissions on object delete (object:deny:d) will be removed from the first acl entry, this is, the value of “Delete entry” in the acl entry will be changed to “unspecified” form “deny”.
Searching ACI and entryOwner values
Suppose we have an entry ou=payroll,o=ibm,c=us and we want to see all the information pertaining to acls for that entry. Here is how that can be done:
E:>ldapsearch -D <admin dn> -w <admin pw> -b ou=payroll,o=ibm,c=us objectclass=* aclEntry aclPropagate entryOwner ibm-filterAclEntry ibm-filterAclInherit ownerPropagate
 
ou=payroll,o=ibm,c=us
ownerPropagate=TRUE
aclPropagate=FALSE
entryOwner=access-id:CN=ROOT
aclEntry=access-id:CN=USER1,O=IBM,C=US:system:deny:rsc:critical:deny:rwsc:sensitive:deny:rwsc:normal:rwsc:restricted:deny:rwsc
 
cn=accountant,ou=payroll,o=ibm,c=us
ownerPropagate=TRUE
aclPropagate=TRUE
entryOwner=access-id:CN=ROOT
aclEntry=access-id:CN=USER1,O=IBM,C=US:object:ad:normal:r
Two entries are returned as shown above, with the ACL showing that these are non-filtered ACLs.
Let us see the same search run against an entry with filtered-acls in it:
E:>ldapsearch -D cn=root -w root -b ou=hr,o=ibm,c=us objectclass=* aclEntry aclPropagate entryOwner ibm-filterAclEntry ibm-filterAclInherit ownerPropagate
 
ou=hr,o=ibm,c=us
ownerPropagate=TRUE
ibm-filterAclInherit=TRUE
entryOwner=access-id:CN=ROOT
ibm-filterAclEntry=access-id:CN=USER1,O=IBM,C=US:(uid=*):object:deny:ad:normal:rwsc
Now let us sum up what we have learned in this chapter.
14.4 Summary
The following presents a summary from this chapter:
ACLs are a means of protecting our information from unauthenticated access.
ACLs are a means of providing different users, a different abstraction of the data contained in the repository, base on their roles or need to know.
The ACL model encompasses two main parts:
 – EntryOwner information: Information pertaining to who owns the entry.
 – ACI or the Access Control Information: This is the main ingredient of the ACL model, describing the individual or group-wise access rights.
Then we saw the classification of ACLs into the following:
 – Non-filtered ACLs: These are the ACLs where we specify the subject and the object clearly. The object that is going to get impacted is the entry where the ACLs are defined and the descendants, provided the aclPropagate flag is set to true.
 – Filtered ACLs: These are the ACLs where we specify the impacted objects, by means of a filter. Hence this is a more generalized specification of ACLs.
Then we saw the BNF of the Access Control Information and the detailed explanation of the same.
Then we saw how exactly the ACL Propagation takes place.
Thereafter, we saw how exactly the ACLs get evaluated. Under this we saw two rules of ACL evaluation:
 – The specificity rules
 – The combinatory rules
Thereafter we saw the different ways of working with the ACLs, as like:
 – The WebAdmin way for the people fond of GUI
 – The command line way for the ones who love to run scripts more than pressing buttons
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset