Learning and Applying the Rules of NDS Security
Articles and Tips: article
Senior Consultant
Novell Consulting Services
BLAIR W. THOMAS
Senior Consultant
Novell Consulting Services
01 Aug 1997
NDS object security has not been well understood by most network administrators. This AppNote cuts through the mystery and clearly presents the basic rules of NDS security, along with numerous examples of how to implement it.
Introduction
Novell Directory Services (NDS) security actually consists of two parts known as file system security and object security. Both aspects of IntranetWare security work together to provide a flexible and effective method for controlling access to your network. The file system security provides access control to files and directories. The object security provides access control to NDS objects and associated operations. You must determine to what extend you want to enable the many file system and NDS security features at your disposal. NetWare is well regarded for providing a high degree of network security, and much of the security administration happens by default (as explained in this AppNote).
Excerpted from Chapter 13, "Managing NetWare Security" in Novell's Guide to IntranetWare Networks by Jeffrey F. Hughes and Blair W. Thomas (Novell Press, 1996, ISBN # 0-7645-4516-7). To order this book, call 800-762-2974 or 317-596-5200.
This AppNote assumes the reader has a basic understanding of NetWare's file system security, which has changed very little from NetWare 3. All the rules governing rights administration are the same in IntranetWare. As an administrator you don't have to learn any new concepts to manage your IntranetWare files. However, those who are new to NetWare 4 and NDS may not fully understand how access is controlled to objects in the NDS tree.
This AppNote outlines the concepts and rules for each area of NDS security. With the groundwork in place we will then focus on some specific examples and explain how security is implemented for each.
Learning the Rules of NDS Security
The first step in understanding NDS security is to understand the rules that govern it. This AppNote will outline the concepts and rules for each area of security. With the groundwork in place we will then focus on some specific examples and explain how security is implemented for each.
NDS security uses the same terminology as file system security. In fact, your familiarity with NetWare 3 file system security will provide you with a great foundation for understanding IntranetWare security. The following concepts will be discussed and are shown in Figure 1:
Trustee Assignments
Security Equivalence
Inheritance
Inherited Rights Filter
Effective Rights
Figure 1: The NDS security pyramid serves as a visual basis for understanding the order and concepts of NDS security.
Trustee Assignments
A trustee assignment indicates the rights granted to an object for a specific file, directory, object, or property. An object that has been granted rights to manage another object is said to be a trustee of that object. A trustee assignment is a direct, explicit assignment of rights to a particular object. Sometimes you will hear the term explicit trustee assignment, which means the same thing. A trustee assignment is listed first in our pyramid diagram because it is the first point at which rights assignments are made. It is the basis for all subsequent security assignments, such as security equivalence and inheritance. Security always begins with a trustee assignment. For example, the use of a group object requires you to grant the group a trustee assignment that the members of the group receive through security equivalence.
The installation of IntranetWare, as another example, causes some default trustee assignments (templates) to be made for user and server objects. As an administrator you will most likely make additional trustee assignments for groups, containers, and other administrators as explained in the following section.
Default Trustee Assignments for Users. During the installation of your first IntranetWare server the ADMIN user object (if you've named it that) receives an explicit assignment of object Supervisor at object [ROOT]. This assignment is the first trustee assignment made by the IntranetWare installation software and initially is the only object in the tree with object Supervisor rights at [ROOT].
|
Note: The ADMIN object is just a user object like any other object, but it hasbeen granted object Supervisor rights at [ROOT]. It can be renamed, deleted, and moved like any other user object. Be careful. |
Also, during installation of IntranetWare, [PUBLIC] receives an object trustee assignment of object Browse at object [ROOT]. With this right all users can browse the tree after attaching to a server before logging in. This enables users to use the CX command to browse the tree and discover object names once they have loaded the NetWare client software and have attached to an IntranetWare server. Figure 2 shows the PUBLIC rights received at the time of installation of IntranetWare.
Figure 2: This diagram shows the default trustee assignments made at the installation of IntranetWare.
IntranetWare Server Default Trustee Assignments. The IntranetWare installation utility also makes trustee assignments at the file system level. The ADMIN object has object Supervisor rights to the tree. The server object is in the tree and therefore ADMIN has rights to your servers. Because the ADMIN object has object Supervisor rights to the server object, the ADMIN object also receives Supervisor rights to the NetWare file system of that server. This is the only instance in IntranetWare security where object rights have an impact on file system rights. In fact, any object with Write rights on a server's ACL has Supervisor rights on the file system of that server.
[PUBLIC] receives the Read property right to the server object's Messaging Server property right so that if the server is being used for the default login server, its property can be located. This assignment is in the template for the server object.
The container object that the new server is installed into receives Read and File Scan rights to the server's \PUBLIC directory. This default access enables all users in the container to execute any files stored on the server's \PUBLIC directory. The container also receives Create rights to the server's \MAIL directory.
Figure 3 shows how these trustee assignments are made when a server object is first created.
Figure 3: This example shows how trustee assignments are made for a server object during installation of IntranetWare.
Default Trustee Assignments for Users. When user objects are created they also receive some default trustee assignments (refer back to the section on ACLs and default ACLs). These assignments greatly reduce the amount of work required by a NetWare administrator to set up user accounts and provide for their access. The following access is automatically granted during creation of a user object.
For our purposes let's assume that a new user object has been created in the TOKYO container. The newly created user object receives the Read and Compare rights to All Properties by default. The All Properties is a category that is visible with either NWADMIN or NETADMIN by selecting Rights to Other Objects. Having the Read right to All Properties allows the user to read the values of his or her own user properties. The Compare right is a subset of Read and enables the value of the property to be compared with another value.
The user object is granted Read and Write rights to its own login script and print job configuration. These rights permit the users to change their own login script and print job configuration if they want. Figure 4 shows these rights assigned along with the others when a user object is created.
Figure 4: Rights assignments are made when a user object is created.
Understanding the Rules of Trustee Assignments. As was mentioned earlier, there are rules that govern the functionality of trustee assignments. Learning these rules can make it much easier for you to understand and use NetWare security.
Trustee assignments flow down the tree.
A trustee assignment for objects and All Properties rights flows down the tree unless it is blocked by an Inherited Rights Filter (IRF). The IRF is explained later in this AppNote. For example, if user SIRKAY were granted Supervisor rights tothe TOKYO container, these rights would flow down to any subsequent containers and objects below TOKYO unless an object has an inheritedrights filter.
An explicit trustee assignment at a lower level in the tree replaces all previous trustee assignments.
As shown in Figure 5, user SIRKAY has been granted explicit Create and Rename rights beginning at object TOKYO. This trustee assignment flows down until it is blocked by an IRF or reassigned by another explicit assignment. In this example, we reassign the object the BROWSE right at the OU=CRIME. This explicit assignment will replace all other higher assignments at the OU=CRIMElevel in the tree.
Figure 5: An explicit rights assignment made at a lower level in the tree will replace any previous explicit assignment to that object.
Selected property rights override any assignment made in the All Properties category.
At the time of user creation, a user object receives the Read property right to all of its own properties. Any selective assignment of a property right using the Selected Properties category will override anything assigned through the All Properties category. For example, by default all users have the Read property right to all of their own user object properties. Notice also that a user also receives by default the read and write rights to his login script and print job configuration. The fact that the read write is given again in the selected properties assignment indicates that it has overridden the previous assignment made in the All Properties category.
The Access Control List (ACL) property of every object stores trustee assignments to that object.
Each object can contain a property known as the ACL. A user by default does not have write rights to its own ACL orto that of any other object. Keep in mind that some objects may not have ACLs if they already have received the explicit right.
Do not grant users the Write rights to any ACL, including their own user object,because the Write right to the ACL controls all access to that particular object.
For example, a user possessing the write right to a container ACL has the ability to makeany changes to that object'sACL. The user could assign anyone Supervisor object rightsto that container and could modify the object as well.
Understanding Security Equivalence
Security equivalence simply means that an object can be equivalent in rights to another object. The majority of rights assignments should be made by administrators through the use of security equivalence. It is quick and easy to use security equivalence because you can deal with a large number of users rather than a single user at a time. Time is always a factor for network administrators, and we recommend that you assign security equivalence to groups or containers as the best way to make rights assignments to large numbers of people.
To meet the needs of many users requiring the same rights to a directory or file, you can create a group, assign rights to the newly created group, and add members to the group. The members of the group are security equivalent in rights to the group object. Therefore, any assignment made to a group will be received by its members through security equivalence.
In addition, a container functions much the same way as a group except that the group is used in your login scripts and a group can span multiple containers. If all users in a container access the same resources, it may not be necessary to use groups. However, if you want to further differentiate your environment setting within a container, the group object is an effective way to go.
Rules Governing Security Equivalence. Because the use of security equivalence will be so common on your network, it is very important to understand how IntranetWare security functions. You will save time as a network administrator if you understand the rules that govern security equivalence.
Security equivalent rights cannot be masked.
If you receive a security equivalence, this assignment cannot be masked by an IRF.
Every object is security equivalent to all container objects that are part of its distinguished name.
This security is known as implied security equivalence. For example, the user GUINEVERE.FIN.OPS.CAMELOT in the ACME treeis security equivalent to every object in its name. Therefore, if you were to grant the container FIN rights to a particulare-mail server, user GUINEVERE would receive those rights through security equivalence.
|
Note: You cannot single out users to not receive rights granted to a container byusing an IRF. If you grant rights to a container, all users in or subordinate to that container will always receive those rights. |
Every object is security equivalent to [ROOT].
Once a user has successfully logged in to a server, that user is security equivalent to [ROOT].
|
ConsultingExperience Be very careful with assigningrights to the [PUBLIC] trustee because of the security equivalence with all users since they do not need to be authenticated to receive those rights. The assignment of file system rights is nonfunctional when using the [PUBLIC] trustee. This means that you cannot grantaccess to files before the user has successfully logged in to the server. Generally, the use of the [PUBLIC] trustee for granting rights shouldbe avoided. |
Every object is security equivalent to [PUBLIC].
[PUBLIC] with the default rights of Browse enables users to browse the tree before logging in to a server. Each user is security equivalent to [PUBLIC], and [PUBLIC] has been granted Browse rights at object [ROOT]. This assignment can be changedif you like.
An object is security equivalent to all objects listed in its Security Equals property.
An NDS object will keep a list (known as the Security Equals Property) of all objects that it equals in rights.
Keep in mind that when a user logs in to an IntranetWare server and authenticates to the Directory, Directory Services creates what is known as a security equivalence vector that is stored in the connection table on the server. The security equivalence vector contains a list of that object's security equivalencies and is created on every server that the client authenticates to.
Inheritance
Inheritance is the method by which rights to objects and files flow down to subordinate levels of the tree. As previously stated, explicit trustee assignments at a higher level in your tree will flow down. The rights you receive at lower levels without assignment are known as inherited rights. Inherited rights include only the object rights and the All Properties rights. Selected property rights are not inherited.
|
Note: Sometimes there is the tendency toconfuse security equivalence and inheritance.Keep in mind that inheritance is simply theway that previously granted rights flow downthe tree to subordinate levels. |
Earlier in our discussion we mentioned that explicit rights, such as the ADMIN user object possessing the Supervisor right at the [ROOT] object, flow down the tree. The Supervisor assignment continues to flow down the tree unless it is otherwise blocked or reassigned. Therefore, at each subsequent level in the tree the ADMIN object's rights are being received through inheritance.
Inherited rights also flow down independently of other rights assignments, such as those obtained through security equivalence. This means that the rights received through inheritance are not affected by actions you may take on other explicit rights assignments. The two operate under separate rules. Do not mix up your security rules.
Understanding Inherited Rights Filters (IRFs) The filter known as the Inherited Rights Filter (IRF) is used to block inheritance. The IRF can be applied to object rights, the All Properties category, and the Selected Properties category.
|
Note: As mentioned earlier, you cannot place an IRF on rights received through securityequivalence. You can apply the IRF only to object rights, the All Properties category,and the Selected Properties category. |
The IRF enables the NetWare administrator to specify which rights can be inherited from an object. It is easier to understand the concept of the IRF if you compare it to a shell around an object. When you place an IRF on an object you are placing an imaginary shell around the object. The rights that are enabled in the IRF are the only rights that users will have to an object. For example, you could place an IRF of Browse on a server object in a container. One user must maintain Supervisor rights over the object, however. All other users can inherit only the Browse right because of the IRF that is placed around the server object.
Inherited ACLs. Each partition [ROOT] object contains a property known as the inherited Access Control List. The inherited ACL property contains the summation of ACLs from parent containers. Unless an IRF is in effect all objects in the partition will receive the rights contained in the inherited ACL. NDS can then calculate rights for objects in its partition without having to walk the Directory tree. As changes to ACLs are made to the Directory tree, NDS will update the multivalued inherited ACL property.
The NDS janitor process has the responsibility to maintain the inherited ACLs by recalculating inheritance if any changes are made to the inherited ACLs.
|
Note: The ACL is both the trustee assignments made and the filters applied. The same attribute(property) name is used for both. |
Rules that Govern the IRF
The IRF cannot grant rights; it only revokes previously assigned rights.
Keep in mind that the IRF is an imaginary shell wrapped around an object.
You can enable an IRF for every Object, Property, File, and Directory.
In most cases you will not need to use that many IRFs because the user's default rights are limited to begin with. As shown in the scenarios at the end of the AppNote, most IRFs are used to protect servers and to separate file system and NDS administration.
The Supervisor Object/Property rights can be revoked by an IRF.
An IRF can be applied to all objects, including the server object. Therefore, you can limit a person's Supervisor access to an IntranetWare file server by applying an IRF to the server object. Remember that a user possessing the managed right (write right to the ACL) to a server object also has rights to the file system volumes for that server as well.
The Supervisor File/Directory rights cannot be revoked by an IRF.
This feature is identical to NetWare 3 Supervisor rights in that any user that has Supervisor rights to a file system directly cannot have file system rights masked on that file server.
Understanding Effective Rights
The last step in the security pyramid is the calculation of effective rights. Effective rights are what an object can actually do after all other security factors are calculated against the object. The following sources are used in the calculation of effective rights of one object to another:
The object's ACL
The object's explicit assignments
All security equivalent access privileges
For example, we will discuss an object A with access to object B using security equivalence calculated at the time of authentication. The rights would be calculated as follows:
The sum of explicit assignments would be calculated back to partition root. Object B would be calculated back to object B's partition root. Of course, an IRF would negate some assignments.
Add in the inherited ACLs from partition root.
Object A receives all explicit and inherited ACLs to which A is security equivalent.
Understanding Managed Rights
Managed rights (or management rights) is a term used to describe an object (ADMIN, for example) that has the Write right to an object's ACL. Managed rights means that the trustee has all power over an object and can modify anything pertaining to that object. For some operations in NDS you must have managed rights to perform that operation. Below is a list of NDS operations and the managed rights that are required to perform them:
All partition operations including Create, Merge, Add replica, and Move Subtree require the trustee to have Write rights to the target partition server object. The Merge operation requires managed rights to the [ROOT] objects of both trees.
A schema modification requires the trustee to have Write rights to the ACL of the Directory's [ROOT] object.
Any modifications to the following properties require Write rights to that object's ACL: - Security Equals - Group Membership - Profile Membership
Backup requires managed rights on the object(s) being backed up.
The Add/Remove replica operation requires the following: - Managed rights on the partition root - Managed rights on the target server
Implementing NDS Security
With an understanding of the basic concepts of security, we can now begin a discussion of how to use and implement NDS security for your network. As stated earlier, the pyramid shown in Figure 13.6 shows a very logical approach for understanding IntranetWare security. Each section of the pyramid will now be explained with examples on how you can implement security in your environment for the greatest benefit.
For our examples we will refer to the ACME tree to implement security procedures throughout the entire organization. The following scenarios will be discussed in terms of NetWare security. All scenarios make the assumption that you are an administrator with object Supervisor rights at the [ROOT] of your tree are assigned.
Security required to install an IntranetWare server under the OU=NORAD container
Security Concepts to Understand
Trustee Assignments
Security Equivalence
As a temporary administrator you are asked to install an IntranetWare server in the NORAD container into the ACME tree. There are currently no administrators in your location, and this server must be brought up immediately.
Contact your main administrator to obtain Create rights for the NORAD container. Supervisor rights at your container are needed to install an IntranetWare server into your own container or to add a partition replica to partition root. This can be accomplished in several ways as described in the following steps.
The first way is to simply have the administrator explicitly grant you Supervisor rights to the NORAD container. This method is difficult to track if many similar requests are made to the main NDS administrator. The administrator soon forgets who has been granted rights.
The second and recommended way is to use NWADMIN or NETADMIN to create an organization role in the NORAD location and grant the role Supervisor rights to the NORAD container knownas NORAD_ADMIN.
The main administrator can then move you into the role temporarily as an administrator so that you can install the IntranetWare server. An IntranetWare installation with an add replica will NOT complete unless you have Supervisor rights to the container in which the server is being installed.
Security required to install an application on your IntranetWare server in the CAMELOT container and grant application access toyour users
Security Concepts to Understand
File System Trustee Assignments
Supervisor rights to a server object
You are a file system administrator in the LABS location responsible for installing all new applications on the location's file servers.
You must have at a minimum the Create right to the APPS subdirectory on your IntranetWare, for example. In most cases you will use Supervisor trustee rights to perform these operations.
If you have Supervisor object rights over the file server object, you will also have Supervisor rights over the file system.
Install your application according to the directions.
Make sure that all executable files related to this application are flagged as sharable read only. Most application installations automatically do this for you, but it doesn't hurt to check.
Create any supporting objects that may be needed such as groups or directory maps. This requires Create right sat the container. You may also need file system rights as well.
Consider using Novell'sApplication Launcher (NAL) to launch applications as NDS objects from a user'sdesktop. For more information on the Novell Application Manager, refer to the AppNote entitled "???" in this issue.
Security procedures for granting an individual rights to manage a help desk center at the CAMELOT location
Security Concepts to Understand
Trustee Assignments
Security Equivalence
Your responsibility is to assist in managing a help desk at the CAMELOT location.
Using NWADMIN or NETADMIN, create a series of specialized organizational roles for your help desk administration such as user administrators, server administrators, and tree administrators. Although currently Directory Services does not enforce rights to a specific object class, you can create organizational roles that designate these type of administrators.
Assign Create, Delete, and Rename rights to the user administrator's role.
Assign Supervisor file system rights to the serveradministrator's role for each server in the container to be managed.
Create an organizational role at the top of your tree with explicit Supervisor rights at [ROOT]. Move the top help desk administrators into the organizational role as occupants.
Make IRF assignments where appropriate to limit administrator access to certain areas of your system.
Creation of subadministrators for each major location in the ACME tree
Security Concepts to Understand
Trustee Assignments
Security Equivalence
Inheritance
You have been given the assignment to create subadministrators for each major location in the ACME network and assign individuals to manage the network from that level down. You currently manage the network with only the ADMIN user object.
Using NWADMIN or NETADMIN, create an organizational role object in the containers NORAD, RIO, TOKYO, CAMELOT, SYDNEY,and TOKYO.
Using NWADMIN or NETADMIN, grant the newly created organizational role objects Supervisor rights to their respective containers.
Choose one or more administrators to participate in the organizational role and add them as role occupants using NWADMIN or NETADMIN.
Assign the ADMIN user explicit Supervisor rights to each of the organizational role objects.
Using NWADMIN or NETADMIN, place an Inherited Rights Filter of Browse (and possibly Read) on each of the organizational roles to prohibit management of the role by the occupants.
These new administrators will have the power to create additional objects, including subordinate containers, in their respective locations. The administrators have Supervisor rights at these lower levels in the tree through inheritance.
Creating a file system administrator and an NDS administrator in the OU=TOKYO location
Security Concepts to Understand
Trustee Assignments
Security Equivalence
Inherited Rights Filter
Administration in the TOKYO container is being divided into two responsibilities. One individual will handle only the file system administration, while the other will handle NDS administration. Each must have separate rights.
Using NWADMIN or NETADMIN, create two organizational roles. Name the first role NDS_ADMIN and the second role FILE_ADMIN.
Using NWADMIN or NETADMIN, assign the NDS_ADMIN role Supervisor Rights to the TOKYO container.
Using NWADMIN or NETADMIN, assign the FILE_ADMIN role Supervisor rights to the server objects TOK-SRV1 and TOK-SRV2.
Using NWADMIN or NETADMIN, place an Inherited Rights Filter of Browse (and possibly Read) on the server objects TOK-SRV1 and TOK-SRV2.
Rights necessary to perform partitioning operations at different levels in the NDS tree
You have been made responsible for partitioning operations on the ACME network. You want to prohibit all partitioning operations except those performed by you and another administrator.
Using NWADMIN or NETADMIN, grant the other administratorsin their organizational roles all rights to their respective containers except the Supervisor object right. Grant Read and Create rights on the container ACL also. (Keep in mind that other administrators will not be able to install IntranetWare servers into the tree without the Supervisor right to the container if they are adding a replica. You can grant them the right temporarily to handle this situation or add the replica for them.)
Create an organizational role for yourself and other tree administrators for partitioning operations called OR_PARTITIONS.
If you have not already done so, grant the organizational role explicit object Supervisor rights to each container immediately subordinate to [ROOT].
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.