|
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 ListsAccess 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.
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.
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.As shown in Figure 8.8, the ACL maintains three pieces of information about a trustee assignment: object name, property name, and effective rights.
InheritanceInheritance 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. Novell has been using inheritance for a long time to apply rights to the NSS file system. If a user was granted rights at a specific directory, those rights implicitly applied to everything from that point down in the directory structureuntil explicitly removed. The same principle applies to eDirectory: If a user is granted rights at a given container object, those rights are implicitly applied to each object in the tree from that point downwarduntil explicitly removed. eDirectory implements inheritance through a dynamic model. This means that rights are calculated in real time whenever an eDirectory object attempts to perform any directory operation. To do this, eDirectory starts at [Root] and walks the tree down to the object, building a set of effective rights for that object along the way. If the effective rights for that object permit the requested operation, it is allowed to continue. If not, the operation is denied. At first, it might seem very inefficient to traverse the eDirectory tree from [Root] each time effective rights need to be calculatedand it would beexcept that eDirectory resolves this inefficiency through the use of external references. External references exist to protect database integrity by storing information about partitions that do have local replicas. In other words, the Master replica of a child partition will maintain an external reference to [Root]. In order to determine the effective rights for a user, eDirectory need only consult the locally stored external references instead of potentially crossing the entire network to find the information it needs. This reduces network traffic and increases the speed of eDirectory tremendously. For more information on external references, see Chapter 7, "Novell eDirectory Management." Inherited Rights FiltersInherited 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. WARNING Don't implement IRFs unless you are absolutely sure you understand the consequences of doing so. That said, it is sometimes desirable to limit the flow of rights through the eDirectory treeeither to segment administration or to isolate portions of the tree. If this becomes necessary, IRFs are the way to go. Just remember that less is usually more in this case. If you find yourself creating a large number of IRFs, it might be a sign of some fundamental eDirectory design issues. See 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:
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 RightsExplicit 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:
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 EquivalenceSecurity 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. TIP Using security equivalence is not an efficient way to manage access. If you find yourself using lots of security equivalences, it is a strong indication of a poor eDirectory tree design. See 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:
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:
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.
Effective RightsThe 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:
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 AdministrationOne 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 AuthorizationIn 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." |
|