Novell Open Enterprise Server Administrators Handbook SUSE Linux Edition [Electronic resources] نسخه متنی

eDirectory Authorization

Now that users have authenticated to the network, you must provide them with access to all the resources they need. This also entails preventing them from accessing resources that they do not need. It wouldn't do to have sensitive documents describing future products open to and accessible to just anyone. The reality of the corporate world is that some resources must be maintained as "need to know." Although determining exactly who needs access to what is a decision beyond most network administrators, Novell eDirectory provides powerful tools for implementing those decisions. This section discusses eDirectory access control concepts and how they work together to provide proper access to objects in the eDirectory tree.

Access Control Lists

Access control lists (ACLs) are stored in each eDirectory object to identify those other objects that have been granted some sort of control over it. Each object in an eDirectory tree maintains two types of access rights. The first set of rights is entry rights. Entry rights define how an object can be manipulated by other directory entities, as described in Table 8.1.

Table 8.1. Valid Entry Rights in eDirectory
ENTRY RIGHT	DESCRIPTION
`Browse`	Allows a trustee to discover and view the object in the eDirectory tree.
`Create`	This right applies only to container objects. It allows the trustee to create new objects within the container.
`Delete`	Allows a trustee to delete the object.
`Rename`	Allows a trustee to rename the object.
`Supervisor`	Allows a trustee full access to the object and its attributes.

The second set of rights is property rights. Property rights define how the attributes associated with an object can be manipulated. eDirectory property rights are described in Table 8.2.

Table 8.2. Valid Property Rights in eDirectory
PROPERTY RIGHT	DESCRIPTION
`Compare`	Allows a trustee to compare or to see if an attribute contains a given value.
`Read`	Allows a trustee to read an attribute value. This right confers the `Compare` right.
`Write`	Allows a trustee to add, delete, or modify an attribute value. This right confers the add or delete `Self` right to the attribute.
`Self`	Allows a trustee to add or delete its name as an attribute value (if applicable).
`Supervisor`	Assigns a trustee all attribute rights.

When entry and/or property rights are conferred on an eDirectory entity, it becomes a trustee of the conferring object. The list of trustees, and the specific object and property rights they have been granted, is maintained in an access control list associated with each eDirectory object. Figure 8.8 shows a representative ACL as seen from iManager.

Figure 8.8. eDirectory access control list in iManager.

[View full size image]

As shown in Figure 8.8, the ACL maintains three pieces of information about a trustee assignment: object name, property name, and effective rights. Object Name
This field identifies the object that is being granted rights. It can also contain one of the special entry references outlined in Table 8.3.

Table 8.3. Special Trustee References in eDirectory
REFERENCE	DESCRIPTION
`Inherited rights filter`	eDirectory uses this reference to mask or filter privileges rather than granting rights.
`[Public]`	eDirectory uses this reference to grant rights to all objects in the eDirectory tree, including both authenticated and non-authenticated objects.
`[Root]`	eDirectory uses this reference to grant rights to all authenticated entries.
`Creator`	eDirectory uses this reference to grant all rights to the client that created the object.
`Self`	eDirectory uses this reference to allow objects to add or delete themselves as values of attributes and to grant the object rights to its own attributes.

Property Name
This field specifies the type of right that is being granted. It also specifies how that right is to be applied. Rights can be assigned to a specific property, to all properties, or to the object itself.

Effective Rights
This field lists the rights that have been granted for a given property. In the eDirectory schema, most object classes specify a default access template that is used to create an ACL attribute for a new object. This default template provides basic access control for the new entry, allowing it to function in the directory. Different object classes have different default ACL templates to reflect their different needs. For example, the default ACL template for the User object grants the Write right to its own login script attribute. This allows users to change their personal login scripts as necessary.

Inheritance

Inheritance is one of the most powerfuland sometimes frustratingconcepts in eDirectory security planning. It is similar to the security equivalence concepts (discussed previously) in that it deals with the determination of effective rights at any given point in the eDirectory tree. On the one hand, inheritance promises to save untold amounts of work by automating the assignment of rights in the eDirectory tree. On the other hand, because of the way that inheritance works, things sometimes don't happen exactly as you might have planned.Chapter 7, "Novell eDirectory Management."

Inherited Rights Filters

Inherited Rights Filters (IRFs) are used to restrict inheritance in a directory tree. IRF use looks pretty straightforward on the surface, but it can cause all kinds of interesting situations to arise. Many calls have been logged to Novell's Technical Support groups because administrators got carried away with controlling every single aspect of eDirectory security instead of just trusting the environment to handle things properly.Chapter 7 for more information on eDirectory tree design. The first thing to recognize about IRFs is that they can filter supervisory rights in eDirectory, unlike supervisory rights in the NSS file system. This makes it possible to limit the control of Admin users higher up in the tree, but it also threatens to destroy your capability to administer the directory tree properly.

To configure an IRF, complete the following steps:

1.	Launch iManager and select the View Objects icon. Locate the container or object for which you want to set an IRF.
2.	Click the object and select Modify Inherited Rights Filter.
3.	Click Add Property to create an IRF.
4.	Select the property for which you want to define an IRF and click OK. You can create an IRF for entry rights, for all properties, or for specific properties.
5.	Uncheck those rights that you want to be blocked by the IRF and select OK to save your changes. The page used to modify the IRF is shown in Figure 8.9. Figure 8.9. Modifying IRF properties in iManager. [View full size image]

WARNING It is very important to remember the dynamic nature of rights calculation in eDirectory. For example, if you are going to create a container administrator and filter administrative rights to that container from above, create the new Admin object first. If you set the IRF first, you will find yourself locked outunable to define a user with administrative control for the container. An IRF is a two-edged sword.

After configuring IRFs, be sure to test your changes to ensure that the desired behavior was achieved. If problems are encountered, you may have to remove the IRF, and then re-add IRF components one at a time until you have isolated the misconfiguration.

Explicit Rights

Explicit rights are those specifically assigned to an object at some point in the eDirectory tree. When one object is given specific rights to another, it is called a trustee . To assign explicit rights, complete the following steps:

1.	Launch iManager and select the View Objects icon. Locate the container or object for which you want to add a trustee.
2.	Click the object and select Modify Trustees.
3.	Click Add Trustee. Browse to the eDirectory object to which you want to assign trustee rights and click OK. You can select multiple objects if desired.
4.	Click the Assigned Rights link next to each object, specify the appropriate rights for this trustee, and then click Done (see Figure 8.10). Property and Rights Specify the rights you want to grant for this trustee. If you want to assign specific property rights only, click Add Property to select specific properties from a list. You can assign entry rights, all property (attribute) rights, specific property rights, or any combination of the three. Inheritable If you are assigning a trustee to a Container object, you can check the Inheritable box if you want those rights to flow down to other objects within the container. Figure 8.10. Assigning explicit trustee rights in iManager. [View full size image]

Assigning explicit rights is a very straightforward process, but as with IRFs, there are some caveats. For example, unlike security equivalence, explicit assignments are not cumulative. An explicit assignment pre-empts the implicit rights that a user might have had through inheritance. Making explicit rights assignments can easily eliminate rights that existed previously. Make sure you understand what is being provided through inheritance and security equivalence, and how your explicit assignment will affect those existing rights, before making manual changes to trustee rights.

Security Equivalence

Security equivalence in eDirectory is used to assign one object identical eDirectory rights to those already assigned to another object. eDirectory offers explicit and implicit security equivalence. Under the rules of inheritance described previously, security equivalence will continue to flow down from the point it is granted. In other words, if JHarris in Provo.Quills is granted equivalence to the Admin object, those rights will be granted at [Root] just as they are for Admin. Equivalence provides a method to grant users in one area of the eDirectory tree rights to objects in another.Chapter 5 for more information on eDirectory design.

Implicit security equivalence occurs automatically when an object is inserted into the eDirectory tree. Every eDirectory object has security equivalence with the following objects: The [Root] object The [Public] trustee Each container between it and [Root]
Security equivalence to [Root] and [Public] provides basic access to eDirectory so that the new object can perform basic network tasks, such as navigating the directory, locating servers, and initiating an authentication request. All specific rights are derived from the inheritance from the container object(s) within which the object exists.

Explicit security equivalence is identical to implicit security equivalence, except the network administrator has to assign the equivalence manually. Use explicit security equivalence whenever one user needs explicit rights identical to another's rights, but cannot get those rights through normal inheritance or implicit security equivalence. To assign explicit security equivalence, complete the following steps:

1.	Launch iManager and select the View Objects icon. Locate the container or object to which you want to grant security equivalence.
2.	Click the object and select Modify Object.
3.	Select the Security tab and click Security Equal To.
4.	Specify the object to which this object will be security-equivalent and click OK.
5.	Click OK to save the security equivalence.

Explicit security equivalence is most often used with Group objects, which were discussed earlier in this chapter. Each member of an eDirectory group is assigned as security equal to the Group object. In this way each user receives the rights associated with that group. Contrary to rights assignment, security equivalence is cumulative. This means that an object's implicit and explicit security equivalence will be added together in order to determine its effective rights.

THE DANGER OF EXPLICIT SECURITY EQUIVALENCE

Not all uses of explicit security equivalence are appropriate. For example, some administrators have used security equivalence to make their User object equivalent to the Admin object. This gives them all rights associated with the Admin object. The danger in this is that when you derive your rights from another object, those rights are never specifically recorded in your object. For example, if JHarris.Provo.Quills is security equal to Admin.Quills, whenever JHarris attempts to perform some directory operation, eDirectory will look at the effective rights of Admin. If Admin has sufficient rights to perform the operation, JHarris, as a security equal, is granted permission as well. Can you see the danger? Some time down the road, JHarris is happily administering eDirectory. Why keep the Admin object around when it is never used? But the instant the object is deleted, JHarris loses all his administrative rights because they are derived from the Admin object and not explicitly assigned.

Even worse, unless some other object has been explicitly granted supervisory rights to the eDirectory tree, deleting the Admin object might delete the ability to administer eDirectory.

Explicit security equivalence can be a powerful tool, but you can end up laying a trap for yourself, or others who might come after you. In most cases, the explicit security equivalence should be restricted to use with Group objects. For applying specific rights to a single object, it is often best to assign those rights explicitly, rather than relying on another object to supply them.

Effective Rights

The whole point of all the preceding rights controls is to ensure that a given user, or other eDirectory object, has the appropriate rights on the network to do what's needed. Effective rights are the cumulative result of all the different rights tools working together. In the end, there are eight ways that one object can get rights to another: Object 1 is a trustee of Object 2. Therefore, Object 1 has explicit rights to Object 2.

A parent container of Object 1 is a trustee of Object 2. Therefore, Object 1 has rights to Object 2 due to implicit security equivalence.

Object 1 has explicit security equivalence to Object 3, which is a trustee of Object 2. Therefore, Object 1 has trustee rights to Object 2, which are equivalent to Object 3.

[Public] is a trustee of Object 2. Therefore, Object 1 has rights to Object 2 through implicit security equivalence to [Public].

[Public] is a trustee of a parent container of Object 2, and those rights flow down the tree due to inheritance. Therefore, Object 1 has rights to Object 2 through the combination of implicit security equivalence and inheritance. Object 1 is a trustee of one of Object 2's parent containers, and those rights flow down the tree to include Object 2 due to inheritance.

A parent container of Object 1 is a trustee of a parent container of Object 2. Therefore, Object 1 has rights to Object 2 through a combination of explicit rights, implicit security equivalence, and inheritance.

Object 1 is security equivalent to Object 3, which is a trustee of a parent container of Object 2. Therefore, Object 1 has rights to Object 2 through the combination of explicit security equivalence and inheritance.

NOTE

Inherited rights filters cannot affect the effective rights in the first four cases because no inheritance is being used. However, IRFs can modify or eliminate the effective rights provided in the last four cases because they depend on inheritance.

With eight ways to derive effective rights between two objects, it's easy to see how rights issues can get complicated very quickly. In most cases, the best solution is to let inheritance do the work of assigning rights wherever possible. The default combination of implicit security equivalence and dynamic inheritance is suitable for 90% of the directory installations out there. Assign rights through containers and let them flow downward. As your directory tree evolves over time, situations can arise that cannot be satisfied by inheritance alone. If this happens, use groups, explicit assignments, and IRFs sparingly to address these exceptions.

When using IRFs, be careful that a single object doesn't become a point of failure. Consider what might happen if a User object is corrupted, or if that user becomes malicious. Always have a second or third option for accessing a branch of the tree that is restricted. Just as the military establishes a chain of command so that the mission can continue if one person is lost, eDirectory administrators have to make sure that proper access can continueor at least be repairedif the default method of access is lost. TIP One way of doing this is to create a secondary User object with full administrative rights, and then add a Browse IRF to that object. This effectively hides the secondary Admin from view but provides emergency administrative access should it be necessary.

Role-Based Administration

One exciting instance of authorization is the capability to assign specific administrative roles to users in the eDirectory tree. Although this was possible in a limited fashion with the use of organizational roles, iManager offers you a previously impossible level of control and ease of use. You can now define most any network activity as a role , and assign the eDirectory rights necessary to perform that activity to a user or group of users. For more information on configuring role-based administration with iManager, see Chapter 5.

File System Authorization

In addition to the authorization required for accessing eDirectory objects, OES Linux requires file-system-level authorization for accessing volumes, directories, and files. This level of security is only available on NSS volumes and does not apply to native POSIX file systems, such as resierfs and ext2/3. For more information on file system authorization with NSS, see Chapter 11, "OES Linux File Storage and Management."