Chapter 11

To effectively manage a NetWare 5 network, you must have a thorough understanding of Novell Directory Services (NDS). By virtue of their integration, NDS and NetWare 5 are nearly synonymous.

On the surface, NDS appears to be simply a directory of the NetWare network resources and users. Much like an inventory, the NDS directory seems to be a mere listing of what is on the network. However, as we’ll see, that is just a surface evaluation. In fact, NDS provides a comprehensive set of administrative tools that can manage a global enterprise network as easily as a single server network with a few client workstations. NDS provides a single seat of administration, regardless of the number of users, workstations, or servers. And NDS will secure the resources on the network.

NDS provides security to an enterprise network by creating a hierarchical tree structure for all network resources to reside in (see Figure 11-1). Since all network resources reside in a single structure, they can also be managed from a single seat of administration. The NetWare Administrator program is the primary means for the single seat of administration for NetWare 5. An administrator who has access to the entire NDS tree can execute the NetWare Administrator program from any network client and manage any network resource even if that resource is located halfway around the world.

Three types of objects exist in the NDS tree structure:

• [Root] the root of the NDS tree, contains either Country or Organization container objects and very limited types of leaf objects
• Container objects objects that can contain either container objects or leaf objects
• Leaf objects objects that represent a network resource

The NDS container objects organize the leaf objects into manageable units. Designs for NDS trees can be based on location, or business unit or other functional criteria, which demonstrates the flexibility of the NDS architecture.

NDS security is established for each leaf object within the NDS tree. Security can be applied at a container object level, which then influences the security of the child objects contained within the parent container, thus simplifying the management of security.

Security in the NDS tree is established for an object by granting rights to objects in the tree. When an object has been granted rights to another object, it is considered a trustee of that object. An object must be a trustee in order to access other network resources. Objects can also be trustees of themselves. Object and property rights do not necessarily have to be granted to other objects. For example, each user is a User object within the NDS tree and each printer is a Printer object in the NDS tree. For a user to print to a printer, the User object must be granted appropriate rights to the Printing objects. And, by the same token, an object must be granted the appropriate rights to itself in order to make changes to its own status.

The NetWare Administrator is the tool used to administer the NDS tree from any workstation within the enterprise network. One major advantage of the hierarchical structure is the capability to create container administrators. Distributing administrators in this way creates a hierarchical administration structure, which is comparable to the way enterprises organize their network managers.

Container administrators are User objects that have been granted Supervisor rights to a container object and all the objects within that container, but not to any other container objects within the tree. Figure 11-2 illustrates this process. Using an Organizational Role object for the container administrators allows multiple container administrators to have the same rights, and it facilitates alternating administrators. For example, when creating a container administrator and the Supervisor rights are granted to the Organizational Role, the Organizational Role will have Supervisor rights to the file system of any servers within that container. In order to create a container administrator using an Organizational Role object, follow Exercise 11-1.

1. In the NetWare Administrator, browse to the container that will be administered. The Organizational Role object should be created in the container where it will have administrative rights.
2. Choose the Object menu and select Create.
3. Select Organizational Role from the Object Creation dialog box.
4. Give the Organizational Role an appropriate name.
5. Click the Create button.
6. The object should appear in the container. Right-click it and select Rights to Other Objects.
7. The Search Context dialog box will default to the current container context. Click OK.
8. In the Rights to Other Objects dialog box, click the Add Assignment button.
9. In the right pane of the Select Object dialog box, double-click the up arrow until the container object is available in the left pane.
10. Click the container object in the left pane and click OK.
11. Under the Object Rights section, check off Browse, Create, Delete, and Rename. If you want the Organizational Role to have the ability to manage the file system rights of any servers in that container, or if the Supervisor rights are required in this container, also check off Supervisor.
12. Click OK to save the new object rights.
13. Double click the Organizational Role object to view its details.
14. Click the button with three dots next to the Occupant box. Using this button will allow the addition of multiple occupants to the Organizational Role object.
15. Click Add.
16. Select the User objects in the left pane of the next dialog which will occupy the Organizational Role object. It may be necessary to navigate the tree in the right-pane window if the User objects do not exist in the same container context. Click OK. Repeat until all occupants are added.
17. The User objects will appear in the Occupant dialog box. Click OK.
18. Click OK to save the occupant changes to the Organizational Role object.

In Exercise 11-1, the container administrator was granted object rights to all objects within a container. Object rights are shown in Table 11-1.

The object rights are the basic rights needed to change objects within the tree. When a User object is granted rights within the NDS tree, the user who logs in with that User object id will have those same rights to the other objects in the tree. The Browse rights are the most important, since it allows the basic access of seeing the objects in the tree. If a user does not have the Browse rights to objects, they will not be able to view the resource or any of its details. In fact, the Browse rights are required for a user to even know whether a resource is on the network.

Each NDS object has specific attributes or properties, which are listed in Table 11-2. An example of a User object property is the Login Script property, which represents the user login script. Before an object can view or modify a property, it must have rights to that property. For example, a User object must be granted Write property rights to the User object’s own Login Script property in order for that user to be able to create, modify, and use their own user login script.

As illustrated in Figure 11-3, a trustee can be granted property rights to all properties or to selected properties. Using a selected property method for granting rights can fine-tune security. Note that in some cases, a trustee can inherit all properties rights from a parent object, and be granted explicit rights to selected properties.

When NDS installs the first time, it provides object and property rights that are generally sufficient for the network resource access required by users. Although the default NDS rights are available to users when they log in, these rights are not necessarily rights granted explicitly to User objects. Instead, some of the rights are granted to other objects to allow user access to the network.

The default rights for NDS may be extended when an NDS-aware application is installed. The NDS-aware application may add a default object or property right for its application to work appropriately. More often, that new default right is applicable to a new property or object within the NDS schema. For example, when Z.E.N.works is installed, the Workstation Manager adds several properties to container objects. One of these properties is the WM:Registered Workstation property. The container object is then granted the default property rights of Write, Compare, and Read to the WM:Registered Workstation property. This enables the importing of Workstation objects into the NDS tree. These rights are not part of NDS prior to Z.E.N.works installation.

The [Public] trustee is not an object within the NDS tree. It is a special trustee rights holder that is applicable to all users, regardless of whether they have logged in to the network yet. By default, then, each User object is security equivalent to [Public]. Any rights granted to [Public] are valid rights for everyone. Since [Public] is not an object within the NDS tree, but a trustee rights holder, the only way to grant or revoke rights to [Public] is to right-click the object and select Trustees of this Object. Then, after selecting Add Trustee, the [Public] trustee will appear as one of the available trustee options. Both object rights and property rights can be granted to [Public] in this way.

The [Public] trustee is granted Browse Object rights to the [Root] of the NDS tree. This right enables users to see objects in the tree before and after logging in. Users are thus able to browse for their context before they log in.

The NDS tree [Root] is granted the Browse and Inheritable Object rights to all NDPS printer, and non-NDPS Printer, Print Queue, and Print Server objects. This enables enterprise-wide printing.

When a User object is created, it is granted the Browse Object rights to itself. This allows the User object to "see" itself in the NDS tree.

By default, the [Public] trustee is granted Read rights to each User object’s Default Server property and Read rights to each NetWare Server object’s network address property. The combination of these two rights allows the login process to locate the default server name, and, secondarily, to find that server on the network through its network address property.

[Root] is granted Read property rights to each User object’s Group Membership property and Read property rights to each User object’s Network Address property. [Root] is also granted Read property rights to each Group object’s Members property. These property rights enable members of groups to be located on the network.

Container objects are granted Read property rights to their own Login Script property. This is required for User objects to inherit that right at login and be able to read and execute the container login script. Container objects are also granted Read property rights to the Print Job Configuration property. Since some print job configurations are created for a container, through inheritance this allows User objects to use the print job configuration.

New User objects are granted the following property rights that enable the object to read its own properties and modify the user login script and user print job configuration:

• Read property rights to all of the User object’s own properties Read and Write property rights to the User object’s own login script
• Read and Write property rights to the User object’s own Print Job Configuration property

Inheritance is the facility by which NDS passes rights (object rights, property rights, and/or file system rights) from one object to another. Rights flow down the NDS tree from as high as the NDS tree [Root] through container objects to leaf objects. Figure 11-4 displays object rights inheritance, which could apply to any NDS object.

An explicit right is a trustee assignment that has been granted to an object directly. An inherited right is a trustee assignment that was granted to an upper-level object and is received by the lower-level object through the NDS flow-down relationship. Property rights can be inherited the same as object rights. Figure 11-5 demonstrates a property right inheritance using a Login Script property as an example.

NDS security and NetWare File System security are administered separately. They even have different sets of rights that can be granted to trustees. There is one major point at which NDS rights flow into the file system. The simplest way to accomplish this is to grant Supervisor object rights for a parent container of a Server object to a trustee. However, if an object has the effective property right of Write to a Server object’s Trustee List (ACL) property, then that object has the Supervisor File System Rights to all volumes on that server. In the file system, unlike NDS, the Supervisor rights cannot be blocked by an IRF or a new trustee assignment lower in the directory structure. This is the point at which NDS rights flow into the file system. So you don’t necessarily have to have Supervisor effective NDS rights to have Supervisor rights in the file system.

— By Dan Cheung, CNI, MCNE, MCT

It is easy to confuse security equivalence with inheritance, but they are not the same. Although both are methods of passing rights from one object to another, security equivalence applies when an object is made equivalent to another object’s explicit trustee assignments, but not to that object’s inherited rights. Inheritance flows down the tree such that inherited rights can continue to be inherited by even further lower-level objects.

User objects are security equivalent to the Group objects of which they are members. Any NDS object can be granted explicit security equivalence to any other NDS object, leaf, or container, through the Security Equal To property page of the object that will receive new rights from other objects. There is an implied security equivalence between a leaf object and its direct parent container object.

1. In the NetWare Administrator, navigate the tree until you locate the User object.
2. Double-click the User object to display its details. Alternatively, highlight the User object, choose the Object menu, and select Details, or right-click the User object and select Details from the pop-up menu.
3. Click the Security Equal To property page, shown in Figure 11-6.
4. Click the Add button.
5. Navigate through the tree until the Admin object is displayed in the left-pane window.
6. Click the Admin object then click OK.
7. Click OK to save the changes to the User object and close the Details window.

The Inherited Rights Filter (IRF) is used to prevent inherited rights from traveling down the tree structure. The IRF is started from the Trustees dialog box, shown in Figure 11-7. The IRF can block any inherited rights, but cannot block those that are granted explicitly or through security equivalence. The fact that child leaf objects are implied to be security equivalent to their parent container objects means that those rights are not blocked by the IRF.

The IRF is applied for each object through the Trustees of this Object option using the IRF dialog box shown in Figure 11-8. When a right is checked off, that means it can be inherited. When the check box is clear next to a right, the right is filtered out and cannot be inherited.

Both object rights and property rights can be filtered. The rights that this affects are those that are inherited from upper level containers. When a right is explicitly granted, even though the IRF blocks that right, the object still has that right. For example, when setting up a container administrator, you may want to filter out upper-level administrators. The container administrator would make sure to have explicit supervisor rights to the container and then set up an IRF for that container with the Supervisor rights check box cleared. Although the IRF does not allow the Supervisor right, the container administrator has an explicit trustee assignment and maintains Supervisor capabilities.

Effective rights are those rights that are in effect for any NDS object. Effective rights can be

• inherited,
• filtered out,
• explicitly granted, or
• applied through security equivalence.

Effective rights are the combination of all the rights available to an object. Determining the effective rights is a matter of adding and subtracting the appropriate rights. The following steps should give you the effective rights for an object:

1. Determine the inherited rights.
2. Subtract the rights that are filtered out by the IRF.
3. Add the rights explicitly granted to the object.
4. Add the rights granted through security equivalence; that is, parent container object rights, group rights of which the object is a member, and explicit rights of objects to which this object is Security Equal To.

In Figure 11-9, each user has been granted identical rights at the organization level. In figuring what object rights the users have within their own contexts, the IRF will apply. The NY context IRF allows [SB] to flow down. That means that user RL’s inherited rights are [SB]. Add RL’s explicit [SB] and security equivalence [CDR] rights to obtain the effective rights of [SBCDR] within RL’s own context. User object JC will have the inherited [SBCDR] rights filtered by the IRF [B]. Add the security equivalence rights of [CDR] and no explicit rights for the effective rights of [BCDR]. For User object TM, all rights except Browse are filtered out through the .LON.MA IRF. Then the [B] rights are also allowed to be inherited through the .ACCT.LON.MA IRF. Through security equivalence, the TM user receives both [B] and [C]. The final effective rights for TM in that context are [BC].

NDS security is the key to keeping enterprise network resources protected. When implementing NDS security, it is best to follow some basic guidelines:

• Do not depend on the default Admin object for the administrative login. Instead, create multiple administrator objects with names that are not necessarily indicative of their administrative capabilities. After creating the administrators, disable the Admin object so that hackers, or the merely curious, do not attempt to find its password.
• Use Group or Organizational Role objects to assign explicit rights. This facilitates granting multiple User objects the same rights as the original user. Adding a member or occupant is a much simpler task than determining which rights need to be granted and then granting them to multiple users.
• Avoid using security equivalence through the Security Equal To property page. The rights granted through security equivalence are difficult to track. For example, when a user has been granted security equivalence to an object, if that other object’s rights are changed later on, the user’s rights will change, seemingly without cause.
• Do not grant more rights than are required.
• Avoid granting rights at the [Root] or Organization level. Keep these rights to a minimum, and increase rights as needed while "walking" down the NDS tree. By keeping rights to a minimum at the upper levels of the tree, it is easier to control inheritance, without IRFs.
• Avoid using IRFs, except where absolutely necessary. When there are security problems, many times in troubleshooting the problem the IRF is forgotten, and the problem goes unsolved or managed by granting too many rights when it was not required.
• Beware of assigning rights to the[Public] Trustee. Any rights assigned to the [Public] Trustee are available to users who have not yet logged into the network.

There is a basic four-step model to troubleshooting NDS security:

1. Gather information.
2. Develop a plan of attack.
3. Execute the plan.
4. Document the solution or return to step 1 and start over.

The first step is to gather information about the security problem. What is the user attempting to do? Does the user have too much access? Does the user have too little access? Is the security of another object the problem?

The history of the problem is valuable in troubleshooting. Did this problem always exist? Or did the security work before and now has changed? When did the problem start occurring? Have any changes to network security been made around this time?

If the security worked before and has suddenly changed, the plan of attack should concentrate on the changes that were made during the same time period. If the problem has always existed, then the plan of attack would most likely be to start with a layout of the effective rights for both objects and properties as they apply to the target NDS objects.

If there were prior security changes, the plan execution would most likely reverse the security changes and test the results. If the problem has always existed, the plan would be to determine:

• What effective rights are required
• What effective rights are actually there
• Which rights must be added or removed

Then the plan would be to change the rights so that the correct effective rights are in effect, and then to verify that they are the correct rights.

Finally, the verified solution should be documented in order to avoid the same issue from recurring.

Novell Directory Services (NDS) is the key to network security. NDS is set up as a hierarchical tree consisting of container and leaf objects. The container objects organize the leaf objects into the hierarchy and each object has properties.

NDS security is implemented by assigning trustee rights to the NDS objects, or the properties of those objects. The object rights are Supervisor [S], Browse [B], Create [C], Delete [D], Rename [R], and Inherited [I]. Object rights apply to actions that can be done to the objects themselves, not to the values within those objects. The only exception to this rule is that the Supervisor right will allow actions to be taken on the object’s properties.

Property rights are Supervisor [S], Compare [C], Read [R], Write [W], and Add Self [A]. The Supervisor right includes all other rights. Property rights are required for an NDS object to view or modify the values of an object’s property.

When NDS installs the first time, it includes some default security assignments that are designed to allow users the flexibility and access required to use the network. These rights are applicable to a special trustee, the [Public] Trustee. The [Public] Trustee is not an object, but a trustee assignment that is automatically granted to all users, whether or not they have logged in to the network.

NDS object and property rights can flow down the NDS tree and be inherited by objects. Although similar, security equivalence is the application of rights through making one object equal to the explicit trustee assignments that have been granted to another object.

Inherited rights can be blocked through the use of an Inherited Rights Filter (IRF). However the IRF does not block rights that have been granted through security equivalence.

Effective rights are the trustee assignments in effect when an object is being accessed by another object. The effective rights are calculated by adding the inherited rights, subtracting the IRF blocked rights, and adding the explicit trustee assignments and the rights granted through security equivalence.

There is a four-step process for troubleshooting NDS security problems: –(1) gather the information; (2) develop a plan of attack; (3) execute the plan; and (4) document the results.

• NDS provides security to an enterprise network by creating a hierarchical tree structure for all network resources to reside in. All network resources reside in a single structure and can be managed from a single seat of administration. The NetWare Administrator program is the primary means for the single seat of administration for NetWare 5. An administrator who has access to the entire NDS tree can execute the NetWare Administrator program from any network client and manage any network resource
• Three types of objects exist in the NDS tree structure: [Root], Container objects, and Leaf objects. The NDS container objects organize the leaf objects into manageable units. Designs for NDS trees can be based on location, or business unit or other functional criteria.
• NDS security is established for each leaf object within the NDS tree. Security can be applied at a container object level, which then influences the security of the child objects contained within the parent container.
• Security in the NDS tree is established for an object by granting rights to objects in the tree. When an object has been granted rights to another object, it is considered a trustee of that object. An object must be a trustee in order to access other network resources. Objects can also be trustees of themselves. Object and property rights do not necessarily have to be granted to other objects.
• The NetWare Administrator is used to administer the NDS tree from any workstation within the enterprise network. One major advantage of the hierarchical structure is the capability to create container administrators. Distributing administrators in this way creates a hierarchical administration structure, which is comparable to the way enterprises organize their network managers.
• Container administrators are User objects that have been granted Supervisor rights to a container object and all the objects within that container, but not to any other container objects within the tree.
• The object rights are the basic rights needed to change objects within the tree. When a User object is granted rights within the NDS tree, the user who logs in with that User object id will have those same rights to the other objects in the tree. The Browse rights are the most important, since it allows the basic access of seeing the objects in the tree.
• Each NDS object has specific attributes or properties. An example of a User object property is the Login Script property, which represents the user login script.
• A trustee can be granted property rights to all properties or to selected properties. Using a selected property method for granting rights can fine-tune security. In some cases, a trustee can inherit all properties rights from a parent object, and be granted explicit rights to selected properties.
• When NDS installs the first time, it provides object and property rights that are generally sufficient for the network resource access required by users. Although the default NDS rights are available to users when they log in, these rights are not necessarily rights granted explicitly to User objects. Instead, some of the rights are granted to other objects to allow user access to the network. The default rights for NDS may be extended when an NDS-aware application is installed.
• The [Public] trustee is not an object within the NDS tree. It is a special trustee rights holder that is applicable to all users, regardless of whether they have logged in to the network yet. By default, then, each User object is security equivalent to [Public]. Any rights granted to [Public] are valid rights for everyone.
• The [Public] trustee is granted Browse Object rights to the [Root] of the NDS tree. This right enables users to see objects in the tree before and after logging in. Users are thus able to browse for their context before they log in.
• By default, the [Public] trustee is granted Read rights to each User object’s Default Server property and Read rights to each NetWare Server object’s network address property. The combination of these two rights allows the login process to locate the default server name, and to find that server on the network through its network address property.
• Inheritance is the facility by which NDS passes rights (object rights, property rights, and/or file system rights) from one object to another. Rights flow down the NDS tree from as high as the NDS tree [Root] through container objects to leaf objects.
• An explicit right is a trustee assignment that has been granted to an object directly. An inherited right is a trustee assignment that was granted to an upper-level object and is received by the lower-level object through the NDS flow-down relationship. Property rights can be inherited the same as object rights.
• It is easy to confuse security equivalence with inheritance. Security equivalence applies when an object is made equivalent to another object’s explicit trustee assignments, but not to that object’s inherited rights.
• User objects are security equivalent to the Group objects of which they are members. Any NDS object can be granted explicit security equivalence to any other NDS object, leaf, or container, through the Security Equal To property page of the object that will receive new rights from other objects. There is an implied security equivalence between a leaf object and its direct parent container object.
• The Inherited Rights Filter (IRF) is used to prevent inherited rights from traveling down the tree structure. The IRF is started from the Trustees dialog box. The IRF can block any inherited rights, but cannot block those that are granted explicitly or through security equivalence.
• Effective rights are those rights that are in effect for any NDS object. Effective rights can be inherited, filtered out, explicitly granted, or applied through security equivalence. Effective rights are the combination of all the rights available to an object. Determining the effective rights is a matter of adding and subtracting the appropriate rights.
• NDS security is the key to keeping enterprise network resources protected. When implementing NDS security, it is best to follow some basic guidelines: Do not depend on the default Admin object for the administrative login. Use Group or Organizational Role objects to assign explicit rights. Avoid using security equivalence through the Security Equal To property page. Do not grant more rights than are required. Avoid using IRFs, except where absolutely necessary. Beware of assigning rights to the[Public] Trustee.
• There is a basic four-step model to troubleshooting NDS security: 1.Gather information, 2. develop a plan of attack, 3. execute the plan, and 4. document the solution or return to step 1 and start over.