3.3 Inheritance
ACL inheritance determines whether the rights granted to a parent object can flow down the eDirectory tree to subordinate objects. Access control privileges are applied according to the hierarchical structure of eDirectory. For example, if a subject has been granted the Browse privilege for an object, the subject will also have the privilege to browse that object’s subordinates.
In NetWare® 4.x, when a user is given [Entry Rights] or [All Attributes Rights] to a container object, the user is given the same rights to all of the subordinated objects of that container. These rights are called inherited rights because they are not explicitly given to the subordinate objects, but are received (or inherited) from the container object.
If the user is given specific property rights, and not [All Attributes Rights], those rights do not flow down to the subordinate objects of the container. In other words, if the user has Read rights to the Name attribute of a container, the user does not have Read rights to the Name attribute of the objects subordinate to the container. However, it the user has [All Attributes Rights] to the container, the user has [All Attributes Rights] to all objects subordinate to that container as well.
In NetWare 5.x, inherited rights can behave as they did in NetWare 4.x, but NetWare 5.x allows them to be configurable. When a user is given [Entry Rights] or [All Attributes Rights] to a container object, the Inheritance Control right, a new right in NetWare 5.x, determines whether the user is given the same rights to the subordinate objects of that container. Also this right determines whether the rights to a specific attribute can be inherited. Both the blocking of inheritance of [Entry Rights] or [All Attributes Rights] inheritance and the enabling of inheritance for specific attributes is new functionality in NetWare 5.x.
The inheritance of ACLs to specific attributes enables the creation of managers who can administer certain attributes in a branch of the eDirectory tree without having to grant the managers Supervisor rights to the objects. For example, you can create a telephone number manager by granting the manager an ACL to the Telephone Number attribute of an eDirectory container object. The privilege set should include the Read, Write, and Inheritance Control rights.
Inheritance is influenced by
3.3.1 Equivalence
Security equivalence simply means that a user has the same rights as another object in the eDirectory tree. Logged in users are always security equivalent to the root-most object in the tree, [Public], and all the parent objects in their distinguished name.
One method for creating a security equivalence is to make one (principal) object a member of another (secondary) object’s Security Equals attribute list. Access to a protected object can then be granted to the principal object by granting privileges to the secondary object. If the principal is also granted explicit access to the object, then the access privileges are the sum of the two privilege sets. The resulting privileges after all inheritance filters are applied are called the principal’s effective privileges (or effective rights). A principal object will receive equivalences from as many objects as it is security equivalent to.
An object can be made security equivalent to a group object. The NetWare® utilities make an object security equivalent to any group the object is made a member of. Simply being a member of a group, however, does not give an object privileges of the group. It is having the group in the object’s security equals list that makes the object security equivalent.
Security equivalences are also formed by virtue of a trustee being a member of a particular subtree. All objects in the tree are equivalent to their superiors. Any privileges assigned to a parent object will be inherited by the subordinate objects.
Security privileges can be assigned all objects in the tree by granting privileges to the root-most object in the tree. This method uses the name of the root-most object as the trustee of the privilege set. All objects are subordinate to the root-most object by default so any privileges assigned to that object are applied to all objects. Similarly, all NetWare 4.x and 5.x objects are implicitly equivalent to [Public]. Even users not logged in to the network (not authenticated) can be given privileges to objects in eDirectory by adding an ACL entry with [Public] as the trustee of a privilege set.
The following figure shows how the accumulated privileges for a user are determined. The user’s distinguished name is Hector.WimpleMakers.Marketing, and he is the equivalent of 4 objects: [Public], Wimple Dev Group, WimpleMakers, and Marketing. He is equivalent to WimpleMakers and Marketing because he is subordinate to these objects in the eDirectory tree. He is equivalent to [Public] because he is attached to the eDirectory tree, to the root-most object in the tree because he is authenticated to the eDirectory tree, and to Wimple Dev Group because his Security Equivalents attribute includes this group. Even though no privileges are assigned explicitly to Hector, his aggregate privileges are the sum of all of his equivalences. Hector’s effective privileges will be his aggregate privileges as long as no inheritance masks restrict them.
Figure 3-9 Accumulating Privileges
See Also:
3.3.2 Inheritance Masks
Inheritance can also be restricted by an inheritance mask. An inheritance mask is an entry in the ACL whose subject field contains a special inheritance mask name. The privilege set in the inheritance mask lists those privileges that may be granted through inheritance. Inheritance masks can be defined at both the object level and the attribute level. Inheritance at the object level and the attribute level are kept separate.
The following figure shows how inheritance operates. In this figure, a subject is assigned R, D, A, and B privileges to an object that is the superior of another object. The subject has not been assigned privileges to the subordinate object. By inheritance, the subject would normally have the same rights on the subordinate object. The subordinate object, however, has an inheritance mask that allows only B to be inherited. As a result, the R, D, and A privileges are not allowed and only the masked privilege is inherited.
Figure 3-10 Inheritance with a Inheritance Mask
An inheritance mask applies only to inherited rights. In NetWare 4.x, inherited rights are assignments made of objects and all attributes. In NetWare 5.x, inherited rights are determined by the setting of the Inheritance Control right.
If a subject receives privileges to a protected object by explicit values in the ACL, inheritance does not apply and the inheritance mask is ignored. However, where no ACL value is defined for a subject, the inheritance mask indicates which privileges may be inherited.
Inheritance masks are used to selectively filter privileges down the eDirectory tree. For example, suppose user Joe is give [Entry Rights] of Browse, Create, and Rename to a container. This particular container has four subordinate container objects, each of which has other subordinate objects. You want Joe to inherit his rights from the first container down to all the subcontainers except one. In this one subcontainer, you don’t want Joe to have the right to create subordinate objects. An inheritance masks easily solves this problems. You can place an inheritance mask on the subcontainer that filters out the Create [Entry Right]. All objects that have the Create [Entry Rights] to the parent of this container do not inherit the Create right to this subcontainer.
Inheritance masks are stored as ACL values of eDirectory objects. eDirectory uses this mask to compute the effective rights one object has on another object or attribute. If no inheritance mask exists, all inherited privileges are granted.
Inheritance masks can be defined for objects, specific attributes, or all attributes of an object. In some Novell literature these masks are referred to as Inherited Rights Filters (IRFs). When programmers request creation of one of these masks they must specify [Inheritance Mask] as the trustee name of the ACL entry. The privilege set specifies the rights that can be inherited. The protected attribute specifies [Entry Rights], [All Attributes Rights], or a specific attribute.
3.3.3 Inherited ACLs
Because of eDirectory inheritance, access control information defined at one point in the eDirectory tree is applied to all subordinate regions of the tree. The effect of inheritance is cumulative. If a subject receives privileges as a user at one place in the tree and as a group member at another point in the tree, the sum of these privileges is available to the subject at lower points in the tree. (Inheritance may be limited by an inheritance mask.)
However, eDirectory partitioning creates gaps in the flow of access control information downward through the tree. It would be inconvenient to try to assess a subject’s inherited privileges across several partitions for each request that the subject initiated on a particular partition. eDirectory alleviates this problem through Inherited ACLs.
The Inherited ACL is an attribute attached to each partition root object. Like a regular object ACL, each entry in the Inherited ACL has a subject field, a protected attribute field, and a privileges field. The Inherited ACL has an entry for every subject for which privileges have been defined in the superior partitions.
When a name server is calculating the effective rights of a subject in relation to a protected object, the name server begins with the Inherited ACL. To any privileges found in the Inherited ACL, the name server adds any additional privileges found in the given partition leading down to the protected object.
The Inherited ACLs are maintained by an eDirectory background process. When ACL modifications are made, this process initiates a summarization of the ACL for any replicas that are affected by the change and that are stored on the server. The result of this summarization is forwarded to any subordinate partition object. Within the partition, inherited ACL information is propagated among replicas by the partition’s synchronization processes.
Inherited ACLs are automatically created by the eDirectory server at the time a new partition is created.
3.3.4 Effective Rights Calculations
eDirectory uses everything described in the sections titled Object Rights, Attribute Rights, Section 3.3, Inheritance, and Section 3.3.1, Equivalence to calculate the Effective Rights of an object to another object. Inheritance masks can mask out rights that are inherited from higher in the tree, but may be overridden by explicitly assigned rights and security equivalences below the inheritance mask. You need to be familiar with how each of the rights-assignment methods work before you can design an eDirectory tree with the security implemented as you want it, and without confusion as to why a user does or does not have the rights you desired.