CNE Training Guide NetWare 4.1 Administration

Previous chapterNext chapterContents


- 5 -

NetWare Directory Services Security


NetWare Directory Services (NDS) provides a logical view of the network resources and provides access to these resources in a uniform manner. The user needs to log in to the network just once. Once logged in, access to network resources is controlled by NDS security.

In this chapter, you learn how NetWare 4.x NDS security is implemented, and how it can be used to provide access to only those parts of the NDS tree to which the user should have access.

Understanding Network Security

NetWare 4.x security includes the traditional NetWare 3.x security dealing with login security and file system security. NetWare 4.x adds an additional component called the NDS security. The three elements of NetWare 4.x security are as follows:

Figures 5.1 and 5.2 show the NetWare 3.x and NetWare 4.x security. Chapter 4, "NetWare 4.x File System Security," deals with file system security. At each of the levels (or elements) of security, a number of tools and options exist. To implement security effectively on a network, you need to understand how to implement the different options at each level and which tools NetWare 4.x provides to implement network security.


STUDY NOTE: The three components of NetWare 4.x security are


Using Login Security

The login security in figures 5.1 and 5.2 has a number of components. Login security controls who can gain initial entry into the network. The login authentication of a user must be done against the User object stored in the global NDS database. A user logging in as an object CN=KARANJIT in container O=ESL must, for example, type in the following command after initial attachment to the network:

LOGIN .CN=KARANJIT.O=ESL

or

LOGIN .KARANJIT.ESL

Figure 5.1 NetWare 3.x network security.

Figure 5.2 NetWare 4.x network security.

The first login command specifies the complete name of the User object. The second form uses the typeless complete name. This assures that the user can log in from any context in the NDS tree. The context, you recall from the discussion in Chapter 2, "Introduction to NetWare Directory Services," is the location (pointer) in the NDS tree. Partial names also can be used by the user to log in to the network. If the current context is [Root], for example, the following commands can be used:

LOGIN CN=KARANJIT.O=ESL

or

LOGIN KARANJIT.ESL

If the current context is O=ESL, the container that holds the User object, the following command can be used:

LOGIN CN=KARANJIT

or

LOGIN KARANJIT

Before a user can successfully log in, the user has to pass through several login restriction checks (see fig. 5.3). These login restrictions are as follows:

The login restrictions in figure 5.3 are initiated on NDS objects through the NetWare Administrator or the NETADMIN tools.

Figure 5.3 The Login Restrictions.

Account Restrictions

Account restrictions can be controlled by changing the account restriction properties for a User object. Account restrictions include the ability to restrict a User object in the following ways:

Figure 5.4 shows the account restriction properties for a User object. In this figure, the account is enabled, as indicated by the absence of the check in the Account Disabled check box. The account is set to expire 8/22/99 at 2:00:00 AM. Also, the concurrent connections are limited to three. This limitation means that the user CN=KARANJIT.O=ESL can log in to no more than three stations at the same time.

Figure 5.4 The Login Restrictions dialog box. To get to figure 5.4, you need to perform the following actions:

1. Log in to the network with Administrator privileges to at least a portion of the NDS tree that has User objects defined.

2. Start the NetWare Administrator Tool. You should see a screen similar to figure 5.5.

Set the context of the NDS tree so you can see the entire NDS tree. You can set the context by performing the following steps:

Figure 5.5 NetWare Administrator showing NDS tree.

3. Examine a container that has User objects defined.

Highlight a User object and examine its properties by double-clicking on the User object or by right-clicking on the User object and selecting the Details option.

Figure 5.6 shows the properties of the User object.

4. Select the Login Restrictions page button, and you see the dialog box for setting Account Restrictions (refer to fig. 5.4).

Note that account restrictions can be used to:

Figure 5.6 Properties of User object CN=KARANJIT.O=ESL.

Password Restrictions

Password restrictions are properties of a User object. Password restrictions include the ability to restrict a user's password in the following ways:

Figure 5.7 shows the password restriction properties for a User object. In this figure, the user is enabled to change his or her password. A password is required, and its minimum length is five. The user is forced to change passwords periodically at intervals of 40 days. The current password expires on 4/3/95 at 2:00:00 AM. The password that a user enters must be unique from previous passwords the user used. The user is allowed a limit of six grace logins after the password expires. If the user does not change the password in the specified number of logins, the account is disabled. It can be re-enabled by an administrator.

Figure 5.7 The Password Restrictions dialog box.

To get to figure 5.7, you need to perform the following actions:

1. Log in to the network with administrator privileges to at least a portion of the NDS tree that has User objects defined.

2. Start the NetWare Administrator Tool.

3. Examine a container that has User objects defined.

4. Highlight a User object and examine its properties by double-clicking on the User object, or by right-clicking on User object and selecting Details option.

5. Select the Password Restrictions page button, and you see the dialog box for setting password restrictions (see fig. 5.7).


STUDY NOTE: Password restrictions can


Time Restrictions

Time restrictions are properties of a User object. Time restrictions can be used to restrict a user's login ability in the following ways:

Figure 5.8 shows the login time restriction properties for a User object. In this figure, the user is enabled to log in on weekdays only. Access on Saturday and Sunday is denied during those times shaded in gray. On weekdays, the user is not able to log in from 10 pm to 12 am or from 12 am to 4 am. This limitation means that the user can log in only from Monday through Friday between 4 am and 10 pm.

If users are logged in and reach a restricted time, the system gives a five-minute warning, saying that they need to log out. If users are still logged in after five minutes, the system will forcibly log them out. Any unsaved information will be lost.

Figure 5.8 The Time Restrictions dialog box.

While NDS uses a universal network time based on Greenwich Mean Time (GMT), and adjusts for time zone differences, login restrictions do not account for time zone differences. For example, if you live in a geographical region that uses US Mountain Time, and you set the time restrictions during Mountain Daylight Savings Time (MDT) to permit weekday access from 8 am to 8 pm, then time restrictions will be off by one hour when your region goes back to US Mountain Standard Time (MST). This means that users who arrive at 8 am, when the time is set to Mountain Standard Time, will not be able to log in until 9 am. This is because the NetWare server time on the server they initially attach to is adjusted back one hour but the login time restrictions are not adjusted. To compensate for time differences within a time zone, you can set login time restrictions with a buffer of one hour before and after normal login time restrictions.

To get to figure 5.8, you need to perform the following actions:

1. Log in to the network with Administrator privileges to at least a portion of the NDS tree that has User objects defined.

2. Start the NetWare Administrator Tool.

3. Examine a container that has User objects defined.

4. Highlight a User object and examine its properties by double-clicking on User object, or by right-clicking on User object and selecting Details option.

5. Select the Login Time Restrictions page button, and you see the dialog box for setting Time Restrictions (see fig. 5.9).


STUDY NOTE: NetWare 4.x time restrictions can be used to:


Station Restrictions

Station restrictions (also called network address restrictions) include the capability to restrict a user's ability to log in to specific workstations. In NetWare 4.x, the station restrictions are more powerful and general than NetWare 3.x. Station restrictions in NetWare 3.x can be done only on the hardware address (MAC address) of the workstation's network board. In NetWare 4.x, station restrictions include the ability to restrict based on a protocol address. For this reason, the station restrictions also are called network address restrictions in NetWare 4.x. Network address restrictions are properties of a User object and enable you to restrict logins based on network addresses such as the following:

The Network Address formats for some of the previous address types are shown in figures 5.9 through 5.11.

The IPX/SPX address format (see fig. 5.9) consists of a 4-byte network number and a 6-byte hardware address. The hardware address is the MAC (Media Access Control) address of the network board.

Figure 5.9 IPX/SPX address restriction.

The TCP/IP address format (see fig. 5.10) is the IP address and consists of a 4-byte logical address that is expressed in a dotted-decimal notation. Each of the 4 bytes that make up the IP address is expressed in its equivalent decimal number (range 0 to 255) and separated by a dot (.).

Figure 5.10 TCP/IP address restriction.

The Ethernet/Token Ring address format shows the SAP (Service Access Point) address and a 6-byte MAC address. The SAP is a 2-byte field that is part of the Logical Link Control (LLC, also called IEEE 802.2) that could be used with frame types such as ETHERNET_802.2, ETHERNET_SNAP, TOKEN-RING, and TOKEN-RING_SNAP. The 6-byte MAC address is broken down into a 3-byte BLOCKID and a 5-byte Physical Unit ID (PUID). The terms BLOCKID and PUID are used with IBM's SNA or SAA networks. For LAN usage, these fields are considered to be one long field that can be used to code the station's MAC address.

Figure 5.11 Ethernet/Token Ring address restriction.

To see the network address restriction screens shown in figures 5.9 to 5.11, you need to perform the following steps:

1. Log in to the network with administrator privileges to at least a portion of the NDS tree that has User objects defined.

2. Start the NetWare Administrator Tool.

3. Examine a container that has User objects defined.

4. Highlight a User object and examine its properties by double-clicking on the User object, or by right-clicking on User object and selecting Details option.

5. Select Network Address Restrictions page button, and you see the dialog box for setting address restrictions.


STUDY NOTE: Network address restrictions are properties of a User object. They enable you to restrict logins based on the following address types:


Intruder Limits

Intruder limits are set in a container object by selecting the Intruder Detection page button in the container's properties using the NetWare Administrator. Intruder limits apply to all User objects within the container (see fig. 5.12). They limit the user's access to the network if an incorrect password is typed in too many times.

Figure 5.12 Intruder Detection screen for container objects.

You can also set intruder limits by using NETADMIN. This procedure is outlined next:

1. Highlight the container for which intruder detection is to be set using NETADMIN.

2. Press F10.

3. Select the View or edit properties of this object option.

4. Select Intruder Detection. You will see the same type of information displayed as in figure 5.12.

The user account is locked if it exceeds the intruder detection limits. The network administrator can use the Intruder Lockout Detection screen for the User object to see the number of incorrect login attempts and the station address that was used by the intruder. To enable login for a locked user, deselect the Account Locked check box. Enabling a user's account, once it has been locked, requires Supervisor rights.

To get to figure 5.12, you need to perform the following steps:

1. Log in to the network with Administrator privileges to at least a portion of the NDS tree that has User objects defined.

2. Start the NetWare Administrator Tool.

3. Examine a container that has intruder limits defined.

4. Right-click on container object and select the Details option.

5. Select the Intruder Detection page button, and you see the dialog box for accessing the Intruder Detection screen.


STUDY NOTE: Intruder Detection is set in a container object and applies to all User objects within the container.

Intruder limits are used to lock a user's access to the network if an incorrect password is typed in too many times.

The container objects on which intruder detection can be set are:


Understanding Login Authentication

When a user first logs in to the network, the network authenticates the user against the information stored in the user's object, such as the user's login name and password. Once authenticated, further requests are validated to ensure that the requests originate from the user's workstation and that they have not been illegally altered in transit across the network. NetWare 4.x's authentication mechanism takes place in the background, with no more direct user involvement after the user types in the object and password correctly. In other words, further authentication takes place in the background and is transparent to the user. The authentication of a user is done on each session basis. If the user logs out of the network, background authentication ceases until the user attempts to log in to the network again.


STUDY NOTE: NetWare 4.x authentication is done on a session-by-session basis and takes place continuously in the background (see fig. 5.13). Background authentication is done during a specific user session, but ceases when a user logs out and exits from the session.

Authentication is used to ensure that only a valid user could have sent the message, and that the message came from the workstation where the initial authentication data was created. It validates that only the sender could have built the message, and that the message has not been illegally modified during transit across the network. It also guarantees that the message is for the current session only, thus eliminating the threat from play-back attacks, where an attempt is made to capture a valid session and play it back on the network.


STUDY NOTE: Authentication ensures that:


Figure 5.13 NetWare 4.x login authentication.

NetWare 4.x provides a scheme for continual background authentication after the initial authentication is complete. This provision makes it difficult to assume the identity of a legitimate user connection.

Accessing NDS Resources

When a client accesses a network resource represented by an NDS object, the NDS locates that resource in the NDS tree and verifies that you are a valid user and have proper permissions to access that resource. The sequence of steps that are performed are listed, next:

1. Client requests NDS resource.

2. NetWare server responds.

3. NDS locates object in the directory.

4. Resource location is identified.

5. NDS checks client has a valid name and appropriate permissions.

6. Client is connected to the resource.

Examining NDS Security Concepts

After the user is validated for network services, the NDS security is used to determine the network resources (NDS objects) to which the user is allowed access. The kinds of operations a user is permitted to perform on an NDS object and files and directories in volumes on the network require certain rights. The operations permissible on NDS objects are called NDS object rights and the operations permissible on a NetWare file system are the file system rights.

Several examples can be given of how NDS object rights are useful. Suppose a user wants to view the structure of a tree. Should the user be enabled to view the directory structure? Viewing the structure (also called browsing) of a tree would be very valuable for a user if the user needs to find out what network resources are available on the network. One of the object rights is called Browse, which enables the user to view the directory structure. Other useful rights are Create, Delete, or Rename. You do not want an ordinary user to have these rights. An administrator user should have a special right called the Supervisor right that grants the administrator all privileges to a directory object.

Figure 5.14 shows that if object rights could not be inherited, explicit rights would have to be assigned at each directory and container level. This would involve greater security administration than is needed in most cases. Using inheritance can simplify the assignment of rights, as seen in figures 5.15 and 5.16.

When a right is assigned to a container object, should all objects in that container get those rights? Objects in a container that receive rights from a parent (superior object) container are said to inherit rights. Inheritance is a very important property and is used in object rights to simplify the assignment of rights. Consider the situation of an Organizational Unit container that has 1,000 objects underneath it (see fig. 5.14).

Figure 5.14 If object rights could not be inherited.

Figure 5.15 Inheritance in object rights for NetWare 4.x.

Figure 5.16 Blocking inheritance of object rights in NetWare 4.x.

For the most part, a user/group needs the same rights to all the objects in that container. If objects could not inherit rights from their parent container, each one of the 1,000 objects would have to be granted a right individually! Most administrators would not appreciate performing such a task. If, on the other hand, objects could inherit rights, the desired object right could be granted just once for the Organizational Unit container (see fig. 5.15). What if some objects in the container needed a different set of rights (see fig 5.16)? In this case, a mechanism to block the flow of rights below a certain container is needed. This mechanism is called the Inherited Rights Filter (IRF) and is discussed in greater detail in a later section of this chapter.

Another important question is the following: Do you want any network administrator to have complete control over the NDS tree for the entire organization? Such control would give this user access to all network resources. Many large organizations are reluctant to grant such access. NDS object rights provide the ability to restrict access to portions of the NDS tree, even to administrator users. Care should be used to prevent a situation where no one has administrative rights to a portion of the NDS tree.

Understanding NDS Rights

NDS provides for two types of rights. The rights to perform operations on the NDS tree structure, and the rights to perform operations on properties of an object (see fig. 5.17). These two types of rights are quite different.

NDS rights that deal with the structure of objects in the NDS tree are called object rights. These are used to view and manage objects in the NDS tree.

NDS rights that deal with the ability to access the values stored in the properties of an object are called property rights. Property rights deal with what a user can do with the values of a property.

Figure 5.17 Object versus property rights.

When working with the NDS structure, for instance, you might need to browse the tree, or rename an object. When you are examining the properties of an object, the Browse right is not meaningful. You typically want to be able to read the value of a property or to write to it. You might want a user to have Read access to his or her e-mail address property, for example, but you might not want the user to change his or her e-mail address. You might, on the other hand, enable users to modify their login scripts. In this case, they need to have Write access to the login script property for their User object.

An NDS object that is granted an explicit right is called the trustee of the object (see fig. 5.18). The trustee can be any object in the NDS tree. It is easy to understand that User objects and Group objects can be trustees, because they all deal with users. But it might seem strange, at first, to think of a container object as a trustee to another object.

Figure 5.18 Trustee of an object and rights to an object.

Chapter 2, "Introduction to NetWare Directory Services," discusses that container objects are a convenient way of grouping NDS objects into a logical structure that reflects the organization of an enterprise. Container objects can be considered as groups where the members of the container are the NDS objects in the container. Making a container a trustee to another object gives all objects in that container rights to the designated object. These rights, furthermore, flow down to other containers and objects, unless explicitly blocked at a tree level.

In summary, the two types of NDS rights are the following:

The next few sections discuss object rights first. A discussion of property rights follows.


STUDY NOTE: An NDS object that is granted a specific (explicit) right is called the trustee of the object.

Two types of NDS rights are object rights and property rights.

The specific (explicit) right that is granted to an NDS object is called a trustee assignment. The two types of trustee assignments are:


Clarifying Terminology

When a right is assigned to an object A for another object B, the object A is called a trustee of object B. The process of granting this right is called a trustee assignment. Often, the object that has been granted the right and the right that has been granted are called a trustee assignment. A trustee can be any other object. In NetWare 3.x, a trustee could be a user account or a group account. In NetWare 4.x, other leaf objects and container objects can also be made trustees.

When a User object is a trustee, the user who is logged in as the User object can perform the operations allowed by the trustee assignment. When a container is made a trustee of an object, all objects in that container can perform the operations allowed by the trustee assignment. Similarly, when a Group object is made a trustee for an object, all User objects listed in the Group object's Group Membership property can perform the operations allowed by the trustee assignment.


AUTHOR'S NOTE: A procedural difference is found in adding rights in NetWare 4.x compared with adding rights in NetWare 3.x. In NetWare 3.x, when SYSCON was used to assign trustee assignments, you selected the user who was to be given the trustee assignment first. After having selected the user, you then assigned rights to that user. When veteran NetWare 3.x users attempt to do this using the NetWare Administrator tool in NetWare 4.x, they tend to select the user first and then try to give trustee assignments to that user, just as they are accustomed to doing in NetWare 3.x. In NetWare 4.x, however, you must first go to the object of which the user is being made a trustee, and then make trustee assignments to that object. Keeping this clear in your mind avoids potential confusion in assigning rights.

Exploring Object Rights

Object rights are assigned to an object in the NDS tree and control the operations that can be performed on the object as a whole. They do not control access to information within the object, except for one important exception. This is a situation when a Supervisor object right has been granted to an NDS object. Granting the Supervisor object right gives full control over the information inside the object, but Supervisor right, like any other right, can be blocked by an Inherited Rights Filter (IRF).

Control of information kept inside the object (property) is accomplished by property rights.

Table 5.1 shows the different object rights that are possible.

Table 5.1 Object Rights

Object Right Abbreviation Meaning
Supervisor S Grants all rights. Assigning this right automatically gives Supervisor rights to the object's All Properties (discussed later in this chapter).
Browse B Grants the right to see an object in the NDS tree. When a request is made to search for an object, its name is returned.
Create C Applies to container objects only. Gives the right to create a new object within the container. Cannot be given to leaf objects because they cannot contain subordinate objects.
Delete D Grants the right to delete an NDS object. Only leaf objects and empty container objects can be deleted.
Rename R Grants the right to rename an object. Applies to leaf and container objects.

Supervisor Object Right

The Supervisor right grants all possible rights to the User object. An object with Supervisor rights has full access to the information inside the object. This right is an exception. Normally, the object rights do not affect access to the contents of the object.

A special right called the All Properties right is used to describe all the properties. When a Supervisor object right is assigned, a Supervisor property right also is assigned, which means that all access to the information inside the object is given if an object has the Supervisor object right. Needless to say, this right must be given with care. If you find it necessary, you can block the Supervisor right to branches of an NDS tree by removing this right from the Inherited Rights Filter for the top-level container for a tree branch.

Browse Object Right

The Browse object right is, perhaps, the most common right given. For readers familiar with NetWare file system security, the Browse object right is similar to the File Scan right for file systems. A Browse right for an object gives the trustee the ability to see the object's name in the NDS tree. Without this right (if a Supervisor right is not given), the object is hidden from the user's view.

If a Browse right is not granted to a trustee for a container, the trustee is denied access to all containers and objects within that tree branch. The default is to give everyone the Browse right to the [Root] object. Because all objects in a directory tree are under the [Root] object, the Browse right is inherited (it also can be said that it flows down) by all objects in the NDS tree.

If, for security reasons, you want to deny access to users in a specific part of the NDS tree, you can do so by blocking the Browse right (using the IRF) for the container that represents the tree branch.

Create Object Right

The Create object right gives the trustee the ability to create subordinate objects underneath the container. Because leaf objects cannot have subordinate objects beneath them, the Create right is not assignable to leaf objects. Figure 5.19 shows an attempt to assign an object right to a leaf object, such as the User1.CORP.ESL. Notice that the object right Create is not shown as an option for this user.

Figure 5.19 Create right not possible for leaf objects.

You also must have Browse rights, in addition to Create rights to a container, before you can create an object underneath the container. The Browse right is usually inherited because [Public] is assigned the Browse right to the [Root] object. You do not need the Browse right to change to a context using the CX command.

Delete Object Right

This right grants the trustee the right to delete an object. A container object can be deleted only if it has no other objects underneath it. You must delete the leaf and subcontainer objects before you can delete a container. This rule is primarily in effect to prevent inadvertent damage to the NDS tree. This is similar to files and directories; you cannot delete the directory unless it is empty (all files are removed).

If a file server is active, its object cannot be deleted. Again, this limitation is for reasons of security, so that access to the file server is not lost while users are connected to it.


WARNING: You can delete a file server's Volume object, even while user's are logged in to it! This action can have disastrous consequences, because users cannot access the volume using NDS. Do not try this on a production system! To safeguard this from happening, remove the Delete right in the Inherited Rights Filter.


PRACTICAL TIP: If someone manages to delete the Volume object, try the following fix:

1. Create a Volume object using NetWare Administrator or NETADMIN.

2. If an error message is generated:

a. reboot the server.

b. connect to the server using VLM /PS=servername. Replace servername with name of server that has the physical Volume whose Volume object representation was deleted.

3. Log in as Admin and start NetWare Administrator.

a. Create a Volume object.

4. Specify the Host Server property to be the NDS name of server, and Host Volume to be SYS.

Alternatively, you can try the following:

1. LOAD INSTALL.NLM at the server.

2. Select Maintenance/Selective Install option.

3. Select Directory Options.

4. Select Install/Reinstall mounted volumes into the directory. You are asked to log in to the NDS as Admin. INSTALL then prompts you to add deleted volumes back into the NDS structure. The volume is placed in the current server context.


Rename Object Right

The Rename object right enables the trustee to change the Name property for the object. Both leaf and container object names can be changed. In pre-NetWare 4.02 releases, only the leaf object names could be changed.


PRACTICAL TIP: Decide on the names of the container objects with careful consideration. You might want to take into account how easily recognizable the container name is to users of the network, its length (should not be too long), and its appearance, as seen in the NDS tree (lowercase, uppercase, or combination of both).

Understanding the [Public] Trustee

Earlier, it was mentioned that everyone is given the Browse right. Readers familiar with NetWare 3.x might recall that everyone received the Read and File Scan (RF) rights to SYS:PUBLIC through the group called EVERYONE. No default group is called EVERYONE (or a similar name) in NetWare 4.x. So the problem is, how do you assign the Browse right to all users in the tree?

The problem is further compounded by the fact that the Browse right would be nice to have for users who are not logged in to the network, but merely attached.

The difference is that users who are logged in to the network have been authenticated by NDS. Users who are attached have a connection to the SYS:LOGIN directory of a NetWare file server so that they can have access to the LOGIN.EXE, CX.EXE, NLIST.EXE and other programs. With this connection, they can log in to the network, or search the NDS tree for the name of a resource. The network security, in most cases, is not threatened if a user can see the names of network resources. In extremely secure environments, the Browse right can be revoked from any part of the NDS tree. Another benefit of the Browse right that is available to attached users and workstations is that it permits the NDS to interface with third-party tools or other X.500 implementations that might need to search Novell's NDS (DIB--Directory Information Base, in X.500 terms), for names of resources and its tree structure.

In order to solve this problem, the designers of NDS created an implicit group called [Public]. An implicit group is different from an explicit group (such as Group objects). Membership to an implicit group is implied by other means. In the case of the group [Public], all workstations that are attached (connected to but not logged in, as yet) to a NetWare 4.x network, automatically are members of the group [Public], making it possible to assign rights to workstations that are not authenticated by NetWare 4.x.


STUDY NOTE: [Public] is an implied group and includes all users who have a network connection, even though they might not be authenticated by the network.

You must take care when assigning rights to [Public]. Otherwise, non-authenticated connections to the network can have excessive rights to the network.



AUTHOR'S NOTE: Other operating systems, such as Windows NT, also have the concept of an implicit group, where membership to certain groups is implied to users accessing a Windows NT station across a network.

When the server is first installed, the group [Public] is made a trustee of [Root] and given the Browse object right to the [Root] object. Figure 5.20 illustrates this trustee assignment, and figure 5.21 shows the NetWare Administrator screen that depicts the assignment of these rights. The Browse object right is inherited by all containers and their sub-containers, down to the individual leaf objects because [Public] has the Browse object right. This right enables a user to browse the directory tree.

Figure 5.20 The Browse right to trustee [Public] on [Root] object.

Figure 5.21 The NetWare Administrator showing default trustee assignments to [Root] object.

Situations might occur when you want users to browse only portions of the NDS tree, rather than allow the entire NDS tree to be browsed. In those cases, the default trustee assignment of Browse for [Public] to [Root] object can be removed, and this right can be assigned to the root container (top of tree branch) for which the user needs to see directory resources. See figures 5.22 and 5.23, which illustrate this concept. These figures show that the Browse right can be granted to all connected users to a specific tree branch. In figures 5.22 and 5.23, the root of this tree branch is at the organization object level O=ESL; it also could be at a lower level in the tree, such as at an Organizational Unit level.

Figure 5.22 The Browse right to trustee [Public] for container O=ESL.

Figure 5.23 The NetWare Administrator showing Browse right to [Public] for container O=ESL.


STUDY NOTE: [Public] is similar to the NetWare 3.x group EVERYONE with the difference that:


Examining Default Object Rights

NetWare 4.x sets certain default system rights to simplify the number of administration tasks that would otherwise have to be performed. One of these default rights is the Browse right that the [Public] trustee gives to the [Root] object. Other default rights are discussed in the following paragraphs.

The container object that contains the SYS: Volume object receives the Read and File Scan (RF) rights to the SYS:PUBLIC directory of the Volume object. These rights are indicated in figure 5.24, which shows that the CORP.ESL container that is the parent container of the server Volume object is given the access rights of Read and File Scan. This allows all objects, such as User and Group objects, defined in that container to inherit these rights.

In essence, this is equivalent to assigning Read and File Scan rights to group EVERYONE in NetWare 3.x. If you have upgraded your server from NetWare 3.x to NetWare 4.x, and if the group EVERYONE had Read and File Scan rights to SYS:PUBLIC, you will also see the Group object EVERYONE in the container where the upgraded NetWare 4.x server and volume objects are installed. You should also see the Group object EVERYONE as a trustee to SYS:PUBLIC with Read and File Scan rights.

Figure 5.24 The rights to SYS:PUBLIC.

The initial user Admin is by default given the Supervisor object right to [Root]. This means that the Admin user inherits Supervisor object rights to all objects and their contents in the NDS tree. For this reason the password to the initial Admin user must be guarded with care. The Admin user by default is placed in the Organization object container and is named Admin. For security reasons, it might be advisable to rename this User object first and then move it to another context.

The User object, by default, has the following object trustees assigned to it:

1. The [Root] object is made a trustee to the User object and is given the Browse object right (see fig. 5.25), which means that any NDS object can browse the User object.

2. If the creator of the User object is not the Admin user, who has Supervisor rights, the creator is made a trustee with Supervisor rights to the newly created object.

Figure 5.25 The Default [Root] trustee assignment for User object.

Another default right is that the creator (Admin) of the server object is given the Supervisor object right to the server object. Assigning Supervisor rights to server objects also gives Supervisor rights to All Properties. Supervisor All Properties right also implies Write property right to the ACL property of the server object. Anyone who has the Write property right to the ACL property of the server object is given Supervisor right to the root of the server's volumes. It is implied that assigning the Supervisor right to a server object gives all file system rights to volumes attached to that server.

The default rights assigned during NDS installation, file server object installation, and User object creation are summarized in tables 5.2, 5.3, and 5.4.

Table 5.2 Default NDS Rights During NDS Installation

Trustee NDS Right Comments
Admin [S] object right to [Root] Allows Admin user to administer the entire NDS tree.
[Public] [B] object right to [Root] Allows users to view the NDS tree using CX and NLIST in the SYS:LOGIN directory without first being authenticated by the NDS tree.

Table 5.3 Default NDS Rights During Server Installation

Trustee NDS Right Comments
Server object creator [S] object right to server object Allows creator (usually administrator of container) to administer the server object.
[Public] [R] (Read) property right to Messaging Server property Allows network messaging clients to identify the messaging server assigned to the server.
Server [S] object right to server object Allows privileged processes running on server to modify parameters in the server object.

Table 5.4 Default NDS Rights for User Object

Trustee NDS Right Comments
[Public] [R] (Read) property right to Default Server property of User object Allows network clients to identify the default server for the user.
[Root] [R] (Read) property right to Network Address and Group membership property of User object Allows authenticated network clients of the NDS tree to identify the login network address and the group memberships of the user.
User [R] (Read) property right to All Properties of User object Allows user to read the values of any property stored in the User object.
[RW] (Read, Write) property rights to the Login Script property for the User object Allows users to change their login scripts.
[RW] (Read, Write) property rights to the Print Job Configuration property for the User object Allows users to change their print job configurations.

Understanding Inheritance of Object Rights

When an object trustee assignment is made, the right granted to the trustee is inherited by all objects subordinate to it. In the case of container objects, all leaf objects in the container and all Organizational Units inherit this right. This inheritance of rights is sometimes called the flowing down of rights.


STUDY NOTE: If an object is given an explicit trustee assignment at a lower level in the tree, any object rights that were inherited from above are overwritten.

Figure 5.26 shows an example of an NDS tree, where User object KSS is made a trustee of the Organization container O=ESL. The trustee assignment that has been given is the [B C D] rights. This is the right to Browse, Create, and Delete objects. The container O=ESL has two Organizational Units: OU=CORP and OU=ENG. The rights assigned to user KSS for O=ESL flow to these Organizational Units. The Organizational Unit objects inherit the [B C D] right. The [B C D] right for trustee KSS, in turn, flows down to the Organizational Units below OU=CORP and OU=ENG. It is important to realize that the [B C D] right is only for a specific trustee; in this case, the trustee is the User object.

Figure 5.26 Example of inheritance of object rights.

The rights assigned to Organizational Unit container OU=ENG flow to its two organizational units, OU=OPS and OU=LAB. The rights inherited by OU=LAB container flow further down the tree, but the OU=R&D Organizational Unit has an explicit trustee assignment of [B] for User object KSS. This explicit trustee assignment overrides the trustee assignment user KSS inherits for OU=R&D from the parent container OU=LAB. The trustee assignment for User object KSS becomes the new right of [B]. This new right flows down to subordinate containers below OU=R&D. In figure 5.26, these subordinate containers are OU=LASER and OU=NNET. User object KSS inherits the rights of [B] to these containers.

It also is interesting to see that in OU=OPS, underneath the OU=ENG container, no explicit trustee assignment was given to user KSS. In this case, the trustee assignment [B C D] flows down and is inherited by the OU=MAINT container that is subordinate to OU=OPS.

Besides an explicit trustee assignment that overrides any inherited rights, inheritance also can be controlled by the use of the Inheritance Rights Filter. This topic is discussed next.


STUDY NOTE: The NDS rights that are inherited are different from the NetWare file system rights. Object rights granted to a Volume object are not inherited by the file directories in that Volume object.


NOTE: You must be careful about assigning rights to top-level containers. Assigning rights to the [Root] container gives User objects that right to the entire tree, unless this right is explicitly removed using IRF.

Examining the Inherited Rights Filter

The Inherited Rights Filter (IRF) is a part of a property of the object, called the ACL property (also called the Object Trustees property). It can be used to control which rights are allowed to be inherited from above.

Every NDS object has an IRF. The default value of the IRF is all object rights [S B C D R], meaning that an NDS object has the potential to inherit all rights. The IRF often is confused with the actual object right. The sole purpose of the IRF is to block a right from flowing down. The IRF cannot be used to block an explicit trustee assignment.


STUDY NOTE: The explicit trustee assignment overrides any Inherited Rights received from above and causes the IRF to be ignored.

The IRF functions in a manner similar to the Inherited Rights Filter for NetWare 4.x file system (same as NetWare 3.x, Inherited Rights Mask, except for the name change). The important difference is that the Supervisor right can be removed for IRF for NDS. In the NetWare file system, the Supervisor right cannot be removed from the IRF for a file or directory.

When the Supervisor right is removed from the IRF for an NDS object, the Supervisor right is essentially blocked from that tree branch. Before removing a Supervisor right from the IRF of an NDS object, you must make another object a trustee with explicit Supervisor rights for that object.

Figure 5.27 shows an attempt to remove the Supervisor right for an NDS object. The trustee, CORP.ESL, is highlighted in the Trustees box, which means that the operations that are performed are in relationship to this trustee object. An attempt was made to remove the Supervisor right from the IRF. Figure 5.27 shows the error message that you see when an unsuccessful attempt was made to clear this box.

Figure 5.27 An attempt to remove Supervisor right from an IRF for a container object.

The reader who is interested in experimenting with this should try the following:

1. Log in as an Admin user and start the NetWare Administrator.

2. Right-click on a container and select Trustees of this Object.

3. Highlight the container in the Trustee List box and select the Inherited Rights Filter button.

4. You should see the Inherited Rights Filter screen.

5. Click on any of the object rights in the Filter panel. The rights should be exposed for your view.

6. Try to remove the Supervisor object right by clicking on the box against it. You should see the error message in figure 5.27.

If an explicit Supervisor trustee assignment to an object exists, the Supervisor object right can be removed from the IRF. In this case, though, the Supervisor right is blocked. At least one object can manage the object and its subordinate objects.


PRACTICAL TIP: Though the Supervisor right can enable a trustee to perform all operations on an object, it is a good practice to assign the other rights in case the Supervisor right is removed accidentally. From the preceding discussion, you can determine that NetWare 4 checks to see if at least one trustee that has a Supervisor right exists before allowing the Supervisor right to be removed; but you still might want to assign other rights as a precautionary measure.

Exploring Security Equivalence

A User object can be granted all the security rights of another NDS object. This situation is called security equivalence and is a property of the User object. Figure 5.28 shows that user Dei is made security equivalent to the users Jan.CORP.ESL and Lisa.ESL, organization role BackupOp.CORP.ESL, group Mgrs.ESL and the Organizational Unit SALES.ESL. This example indicates that Dei inherits, by the definition of security equivalence, whatever rights the previously mentioned objects have. These rights are in addition to the rights that user Dei already has.

Figure 5.28 The security equivalence property of a User object.


STUDY NOTE: Security equivalence is a property of the User object. You may be asked questions on security equivalences, such as when you should make use of security equivalences. These points are discussed in this section.

Because security equivalence is a property of the User object, the user must not have the right to make changes to this property. If a user has the Write property right to the security equivalence property and the Write property right to the ACL property of an Admin User object, the user could assign an Admin User object as one of the values for the security equivalence property. This action would give the user all the rights the Admin user has. The default for a newly created user is that users can read their security equivalence property. You should not normally have to change this value.

One situation in which security equivalence might be particularly useful is when a user in an organization needs access to files and directories of another user. This user could be made security equivalent to the user whose files and directories need to be accessed. To perform this task, you need to have the Write property right for the User object (property rights are discussed later in this chapter).

Using Object Effective Rights

An object's effective rights are the rights that a user actually has to the object. The effective rights are not the same as the rights inherited from a parent container, because these could be blocked by the IRF. Also, a user can have a right blocked, but might inherit that right because a group to which the user belongs has an explicit or inherited trustee assignment for the object. By the same token, an effective right is not the same as an explicit trustee assignment. A user can inherit other rights because a group to which the user belongs has an explicit or inherited trustee assignment for the object.

The effective rights need to be calculated for each situation. Because of the hierarchical structure of the NDS tree, a right can be inherited from a number of sources. This possibility makes the determination of the origin of NDS rights an interesting and challenging task.

Consider the example in figure 5.29. To compute the effective rights of user KSS to the Printer object HP_PRINTER, you must consider effective rights that come from any of the following sources:

Figure 5.29 The sources for computing effective rights.

1. Explicit trustee assignment: This assignment includes the trustee assignment on HP_PRINTER that lists user KSS as a trustee (see fig. 5.30).

2. Inherited from trustee's parent container: Trustee assignment on HP_PRINTER that lists OU=CORP as a trustee. This assignment also includes a trustee assignment on HP_PRINTER that lists other parent containers, such as O=ESL and [Root], as trustees. This is because the user KSS is in the tree branch with these objects as roots of the tree branch (see fig. 5.31).

Figure 5.30 Effective object rights: explicit trustee assignment.

Figure 5.31 Effective object rights: inherited from trustee's parent container.

3. Inherited from direct assignment to object's container: Trustee assignment on the container OU=ENG that lists user KSS as a trustee (see fig. 5.32). The rights assigned must pass through the object HP_PRINTERs IRF.

Figure 5.32 Effective object rights: inherited from direct assignment to object's container.

4. Inherited from assignment of trustee's container to object's container: Trustee assignment on the container OU=ENG that lists User object KSS's parent containers such as OU=CORP, O=ESL and [Root] as a trustee (see fig. 5.33). The rights assigned must pass through the object HP_PRINTER's IRF.

5. Trustee assignment to a Group object: Any trustee assignment made to the Group object MGRS of which the user KSS is a member (see fig. 5.34).

Figure 5.33 Effective object rights: inherited from assignment of trustee's container to object's container.

Figure 5.34 Effective object rights: trustee assignment to a Group object.

6. Trustee assignment to a security equivalent object: If user KSS is made a security equivalent to object KARANJIT, any right that the user KARANJIT has to HP_PRINTER automatically is inherited by user KSS (see fig. 5.35).

Figure 5.35 Effective object rights: trustee assignment to a security equivalent object.


STUDY NOTE: Study the different ways, listed in this chapter, that an object could derive its effective rights.

As you can determine from the previous discussion, you must consider the following in order to compute effective rights:

The next section presents case studies to give you practice in computing effective rights.

Calculating Object Effective Rights

Understanding how effective rights are computed for an object in the NDS tree is extremely important for NetWare 4.x administration. For this reason, many case studies are presented to help you understand how effective rights work in NetWare 4.x.

Figure 5.36 shows a worksheet that can be used for computing effective rights. This figure also shows a partial directory tree with the containers O=ESL, OU=CORP, and OU=ACCTG. The worksheet for computing effective rights shows the entries for each of these containers. For each container, entries are shown for the following:

While practicing how to compute effective rights, you should discover that the worksheet is an invaluable aid because it systematically shows the rights at each level. With more experience and practice in computing effective rights, you might be able to dispense with the use of a worksheet and compute effective rights more directly.

Figure 5.36 Worksheet for computing effective rights.

Ten case studies are presented, with a discussion of solutions for each case study. The case studies range from the simple to the complex. Ten case studies might seem to be a lot, but the more practice you have, the more confident you should feel, not just for passing the exams, but also for real-life tasks of designing security on a NetWare 4.x network.

Case Study 1--Computing Effective Rights

Figure 5.37 shows a directory tree for organization IBL. Drew becomes a trustee of Organization O=IBL and receives Browse, Create, and Rename rights. The IRFs for the containers follow:

IRF for O=IBL        [S B C D R]
IRF for OU=CORP      [  B C D  ]
IRF for OU=MKTG      [S     D R]

Calculate Drew's effective rights in containers O=IBL, OU=CORP, and OU=MKTG. Assume that Drew does not inherit rights from any other source than the ones listed in the case study.

Figure 5.38 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented.

Figure 5.37 A directory tree for organization IBL.

Figure 5.38 The completed worksheet.

Entries for O=IBL

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B C R] has been given to the user. The explicit trustee assignment overrides any other inherited rights, so the effective rights for the user in container O=IBL are the same as the explicit trustee assignment. That is, Drew's effective rights for O=IBL are [B C R].

Entries for OU=CORP

The IRF, according to the case study, is [ B C D ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [    B C D     ]
Effective rights of parent  [    B C      R]
_______________________
Inherited Rights            [    B C       ]

The masking operation is a logical AND operation, which means that an entry needs to be in the IRF rights and Effective rights of the parent container for it to be in the final result.

The Inherited Rights for OU=CORP are [B C ]. Because no trustee assignment is made in OU=CORP, the effective rights are the same as the Inherited Rights. That is, Drew's effective rights for OU=CORP are [B C].

Entries for OU=MKTG

The IRF, according to the case study, is [ S D R ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S         D R ]
Effective rights of parent  [    B C       ]
_______________________
Inherited Rights            [              ]

The Inherited Rights for OU=MKTG are [ ], or No Rights. Because no trustee assignment is made in OU=MKTG, the effective rights are the same as the Inherited Rights. That is, Drew's effective rights for OU=MKTG are No Rights.

Case Study 2--Computing Effective Rights

Figure 5.39 shows a directory tree for organization IAF. Hari becomes a trustee of Organization O=IAF and receives Browse, Create, Delete, and Rename rights. The IRFs for the containers follow:

IRF for O=IAF    [S B C D R]
IRF for OU=CORP  [S B C D  ]
IRF for OU=MKTG  [S B     R]

Figure 5.39 Object effective rights: NDS tree for case study 2.

Calculate Hari's effective rights in containers O=IAF, OU=CORP, and OU=MKTG. Assume that Hari does not inherit rights from any other source.

Figure 5.40 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.40 Object effective rights: worksheet for case study 2.

Entries for O=IAF

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B C D R] has been given to the user. The explicit trustee assignment overrides any other inherited rights, so the effective rights for the user in container O=IAF are the same as the explicit trustee assignment. That is, Hari's effective rights for O=IBL are [B C D R].

Entries for OU=CORP

The IRF, according to the case study, is [S B C D ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B C D   ]
Effective rights of parent  [   B C D  R]
_______________________
Inherited Rights            [   B C D   ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=CORP are [B C D ]. Because no trustee assignment is made in OU=CORP, the effective rights are the same as the Inherited Rights. That is, Hari's effective rights for OU=CORP are [B C D].

Entries for OU=MKTG

The IRF, according to the case study, is [ B C D R ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [  S B        R ]
Effective rights of parent  [    B C D      ]
_______________________
Inherited Rights            [    B          ]

The Inherited Rights for OU=MKTG are [ B ]. Because no trustee assignment is made in OU=MKTG, the effective rights are the same as the Inherited Rights. That is, effective rights for OU=MKTG are [ B ].

Case Study 3--Computing Effective Rights

Figure 5.41 shows a directory tree for organization SCS. Dei becomes a trustee of Organization O=SCS and receives Browse, Create, Delete, and Rename rights. Dei also is given a trustee assignment of [B C D R] to OU=LAB. The IRFs for the containers follow:

IRF for O=SCS    [S  B        ]
IRF for OU=ENG   [S  B        ]
IRF for OU=LAB   [S  B  C    R]

Figure 5.41 Object effective rights: NDS tree for case study 3.

Calculate Dei's effective rights in containers O=SCS, OU=ENG, and OU=LAB. Assume that Dei does not inherit rights from any other source.

Figure 5.42 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Entries for O=SCS

The IRF, according to the case study, is [S B ]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B C D R] has been given to the user. The explicit trustee assignment overrides any other inherited rights, so the effective rights for the user in container O=SCS are the same as the explicit trustee assignment. That is, effective rights for O=SCS are [B C D R].

Figure 5.42 Object effective rights: worksheet for case study 3.


Entries for OU=ENG

The IRF, according to the case study, is [S B ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B       ]
Effective rights of parent  [   B C D  R]
_______________________
Inherited Rights            [   B       ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights in order for it to be in the final result.

The Inherited Rights for OU=ENG are [B ]. Because no trustee assignment is made in OU=ENG, the effective rights are the same as the Inherited Rights. That is, Dei's effective rights for OU=ENG are [B ].

Entries for OU=LAB

The IRF, according to the case study, is [S B C R ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [ S B C      R   ]
Effective rights of parent  [   B            ]
________________________
Inherited Rights            [   B            ]

The Inherited Rights for OU=LAB are [ B ]. Because an explicit trustee assignment of [B C D R] is made in OU=LAB, the effective rights are the same as the explicit trustee assignment. That is, Dei's effective rights for OU=LAB are [ B C D R ].

Case Study 4--Computing Effective Rights

Figure 5.43 shows a directory tree for organization SCS. Karanjit becomes a trustee of Organization O=SCS and receives Supervisor rights. Karanjit also is given a trustee assignment of Browse, Create, Delete, and Rename to OU=ENG. The IRFs for the containers follow:

IRF for O=SCS    [S B  C D R ]
IRF for OU=ENG   [S B  C     ]
IRF for OU=LAB   [  B      R ]

Figure 5.43 Object effective rights: NDS tree for case study 4.

Calculate Karanjit's effective rights in containers O=SCS, OU=ENG, and OU=LAB. Assume that Karanjit does not inherit rights from any other source.

Figure 5.44 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.44 Object effective rights: worksheet for case study 4.

Entries for O=SCS

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [S ] has been given to the user. The explicit trustee assignment overrides any other inherited rights, so the effective rights for the user in container O=SCS are the same as the explicit trustee assignment. That is, Karanjit's effective rights for O=SCS are [S (B C D R)]. The rights in parentheses of (B C D R) are implied rights. If the trustee has Supervisor rights, the trustee automatically has the other rights.

Entries for OU=ENG

The IRF, according to the case study, is [S B C]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B       ]
Effective rights of parent  [S (B C D R)]
_______________________
Inherited Rights            [S (B C D R)]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=ENG are [S (B C D R)]. Because a trustee assignment of [B C D R] is made in OU=ENG, the effective rights are the same as the explicit trustee assignment, and override any inherited rights. That is, Karanjit's effective rights for OU=ENG are [B C D R ]. An interesting fact about this case study is that the inherited rights to OU=ENG were all object rights. But by explicitly assigning lesser rights, the greater rights inherited from above are overridden.

Entries for OU=LAB

The IRF, according to the case study, is [ B R ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [    B      R  ]
Effective rights of parent  [    B  C D R  ]
________________________
Inherited Rights            [    B      R  ]

The Inherited Rights for OU=LAB are [ B R ]. Because no explicit trustee assignment is made in OU=LAB, the effective rights are the same as the Inherited Rights. That is, Karanjit's effective rights for OU=LAB are [ B R ].

Case Study 5--Computing Effective Rights

Figure 5.45 shows a directory tree for organization KJBR. John becomes a trustee of Organizational Unit OU=LAB and receives the Supervisor right. Group object OWNERS received a trustee assignment of Browse and Create for Organization O=KJBR. John is a member of this group.

Figure 5.45 Object effective rights: NDS tree for case study 5.

The IRFs for the containers are shown here:

IRF for O=KJBR , [S B C D R ]
IRF for OU=PDEV  [S B       ]
IRF for OU=LAB   [  B C D R ]

Calculate John's effective rights in containers O=KJBR, OU=PDEV, and OU=LAB. Assume that John does not inherit rights from any other source.

Figure 5.46 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.46 Object effective rights: worksheet for case study 5.

Entries for O=KJBR

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B C ] has been given to the group OWNERS, of which John is a member. The explicit trustee assignment overrides any other inherited rights, so that the effective rights for the user in container O=KJBR are the same as the explicit trustee assignment. That is, John's effective rights for O=KJBR are [B C ]. The worksheet also shows that the effective rights computed are for Group object OWNERS, of which John is a member. When calculating effective rights, remember that you can avoid confusion by keeping track of the sources of the rights because it is possible to have rights from several sources.

Entries for OU=PDEV

The IRF, according to the case study, is [S B]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B            ]
Effective rights of parent  [   B C          ]
_______________________
Inherited Rights            [   B            ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=PDEV are [ B], and the source is the Group object OWNERS. Because no trustee assignment is made in OU=PDEV, the effective rights are the same as the inherited rights. That is, John's effective rights for OU=PDEV are [B ], and the source of this right is group OWNERS.

Entries for OU=LAB

The IRF, according to the case study, is [ B C D R ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [    B  C D R   ]
Effective rights of parent  [    B  C       ]
________________________
Inherited Rights            [    B          ]

The Inherited Rights for OU=LAB are [ B ], and the source is group OWNERS.

An explicit trustee assignment of [S ] has been given to user John. The explicit trustee assignment overrides any other inherited rights for user John only. The last point is important to understand. Inherited rights of [B] exist, but this is through group OWNERS. So the explicit right of [S] for user John does not override the inherited rights for group OWNERS, which is the reason that it is so important to keep track of the source of the rights. The effective rights in this case are the sum of the inherited rights from group OWNERS and the explicit trustee assignment for user John.

Inherited Rights for group OWNERS   [    B          ]
Trustee Assignment for user John    [  S            ]
_________________________________
Effective Rights                    [  S B (C D R ) ]

The effective rights are through membership to group OWNERS and through assignment to User object John, and they are [ S B (C D R) ]. The (C D R) rights are implied because of the presence of the Supervisor [S] right.

If the trustee assignment of Supervisor right was revoked from user John for OU=LAB, user John still would have the Browse right from membership to Group object OWNERS. And, if the user John was removed as a member of group OWNERS, John still would have the explicit Supervisor right granted to him for OU=LAB and the implied rights of (B C D R).

Case Study 6--Computing Effective Rights

Figure 5.47 shows a directory tree for organization KJBR. Bob becomes a trustee of Organizational Unit OU=LAB and receives the Supervisor right. Bob is a member of two Group objects: group OWNERS and group MGRS. The Group object OWNERS has been given a trustee assignment of Browse and Rename rights for Organization O=KJBR. The Group object MGRS has been given a trustee assignment of Browse, Create, and Delete right for Organization Unit OU=PDEV.

Figure 5.47 Object effective rights: NDS tree for case study 6.

The IRFs for the containers are shown here:

IRF for O=KJBR   [S B C D R ]
IRF for OU=PDEV  [S B C   R ]
IRF for OU=LAB   [S   C     ]

Calculate Bob's effective rights in containers O=KJBR, OU=PDEV, and OU=LAB. Assume that Bob does not inherit rights from any other source than the ones listed in the case study.

Figure 5.48 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.48 Object effective rights: worksheet for case study 6.

Entries for O=KJBR

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B R ] has been given to the group OWNERS, of which Bob is a member. The explicit trustee assignment overrides any other inherited rights for group OWNERS, so the effective rights for Bob in container O=KJBR are the same as the explicit trustee assignment. That is, Bob's effective rights for O=KJBR are [B R ]. The worksheet also shows that the effective rights that were computed are for Group object OWNERS, of which Bob is a member. When calculating effective rights in cases where rights could be from several sources, you should keep track of the sources of the rights to avoid confusion.

Entries for OU=PDEV

The IRF, according to the case study, is [S B C R]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B C  R           ]
Effective rights of parent  [   B    R           ]
__________________________
Inherited Rights            [   B    R           ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=PDEV are [ B R], and the source is the Group object OWNERS. An explicit trustee assignment of [ B C D] is made to OU=PDEV through group MGRS.

The explicit trustee assignment overrides any other inherited rights for group MGRS only. The explicit right of [B C D] for group MGRS does not override the inherited rights for group OWNERS, which is the reason that it is so important to keep track of the source of the rights. The effective rights in this case are the sum of theinherited rights from group OWNERS and the explicit trustee assignment for group MGRS, and Bob is a member of both.

Inherited Rights for group OWNERS   [     B     R        ]
Trustee Assignment for group  MGRS  [     B C D          ]
_________________________________
Effective Rights for Bob            [     B C D R        ]

The effective rights are through membership to group OWNERS and MGRS.

If the user Bob was removed as a member of group OWNERS, Bob still would have the explicit [ B C D] rights granted to him by membership to MGRS. And, if Bob was removed as a member of group MGRS, Bob still would have the inherited [ B R] rights granted to him by membership to OWNERS.

Entries for OU=LAB

The IRF, according to the case study, is [ S B C ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [ S  B  C        ]
Effective rights of parent  [    B  C   D  R ]
________________________
Inherited Rights            [    B  C        ]

The Inherited Rights for OU=LAB are [ S B C ], and the source is group MGRS.

An explicit trustee assignment of [S ] has been given to user Bob. The explicit trustee assignment overrides any other inherited rights for user Bob only. The last point is important to understand. Inherited rights of [B C] exist through group MGRS. The explicit right of [S] for user Bob, therefore, does not override the inherited rights for group MGRS, which is the reason that it is so important to keep track of the source of the rights. The effective rights in this case are the sum of the inherited rights from group MGRS and the explicit trustee assignment for user Bob.

Inherited Rights for group  MGRS    [     C         ]
Trustee Assignment for user Bob     [ S             ]
_________________________________
Effective Rights                    [ S B C (D R )  ]

The effective rights are through membership to group MGRS and through assignment to User object Bob, and they are [ S B C (D R) ]. The [(D R)] rights are implied because of the presence of the Supervisor [S] right.

If the trustee assignment of Supervisor right was revoked from user Bob for OU=LAB, user Bob still would have the Create and Browse rights from membership to Group object MGRS. And, if the user Bob was removed as a member of group MGRS, Bob still would have the explicit Supervisor right granted to him for OU=LAB, and the implied rights of (B C D R).

Case Study 7--Computing Effective Rights

Figure 5.49 shows a directory tree for organization MicroCon. JConnor becomes a trustee of Organizational Unit OU=RESEARCH and receives the Supervisor, Create, Delete, and Rename rights. JConnor also becomes a trustee of OU=LAB and receives the Create right. [Public] receives the Browse right to organization O=MicroCon.

Figure 5.49 Object effective rights: NDS tree for case study 7.

The IRFs for the containers follow:

IRF for O=MicroCon     [S B C D R ]
IRF for OU=RESEARCH    [S B       ]
IRF for OU=LAB         [  B C D R ]

Calculate JConnor's effective rights in containers O=MicroCon, OU=RESEARCH, and OU=LAB. Assume that JConnor does not inherit rights from any other source than the ones listed in the case study.

Figure 5.50 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.50 Object effective rights: worksheet for case study 7.

Entries for O=MicroCon

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B ] has been given through [Public], of which JConnor automatically is a member. The explicit trustee assignment overrides any other inherited rights for [Public] (of which there are none), so the effective rights for JConnor in container O=MicroCon are the same as the explicit trustee assignment. That is, JConnor's effective rights for O=MicroCon are [B ]. The worksheet also shows that the Effective rights that were computed are for [Public], of which JConnor is a member. When calculating effective rights where there could be rights from several sources, you should keep track of the sources to avoid confusion.

Entries for OU=RESEARCH

The IRF, according to the case study, is [S B ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B       ]
Effective rights of parent  [   B       ]
__________________________
Inherited Rights            [   B       ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=RESEARCH are [ B ], and the source is [Public]. An explicit trustee assignment of [ S C D R] is made to OU=RESEARCH for user JConnor.

The explicit trustee assignment overrides any other inherited rights for user JConnor only. The explicit rights of [S C D R] for user JConnor does not override the inherited rights of [B], whose source is [Public], which is the reason that it is so important to keep track of the source of the rights. The effective rights in this case are the sum of the inherited rights from [Public] and the explicit trustee assignment for user JConnor.

Inherited Rights for [public]             [    B        ]
Trustee Assignment for user JConnor       [  S   C D R  ]
_________________________________
Effective Rights for JConnor              [  S B C D R  ]

The effective rights are through [Public] and trustee assignment to JConnor.

Entries for OU=LAB

The IRF, according to the case study, is [ B C D R]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [   B  C   D  R  ]
Effective rights of parent  [S  B  C   D  R  ]
________________________
Inherited Rights            [   B  C   D  R  ]

The Inherited Rights for OU=LAB are [ B C D R ], and the sources are [Public] and user JConnor. JConnor's contribution to this right is [ C D R], and [Public]'s contribution is [ B ]. An explicit trustee assignment of [S ] has been given to user JConnor. The explicit trustee assignment overrides any other inherited rights for user JConnor only. JConnor has inherited rights of [C D R], so the explicit right of [ C ] for user JConnor overrides the inherited rights of [C D R]. The effective rights in this case are the sum of the inherited rights from [Public] and the explicit trustee assignment for user JConnor.

Inherited Rights for [Public]           [   B                ]
Trustee Assignment for user JConnor     [ S   C D R          ]
_________________________________
Effective Rights for JConnor            [   B C D R          ]

The effective rights are through membership to [Public] and through assignment of the [C ] right to User object JConnor.

If the Trustee Assignment of the Create right was revoked from user JConnor for OU=LAB, user JConnor still would have the Browse right from [public]. And, if the [Public] with Browse right was removed as a trustee for O=MicroCon, user JConnor still would have the explicit Create right granted to him for OU=LAB.

Case Study 8--Computing Effective Rights

Figure 5.51 shows a directory tree for organization MicroCon. BWayne becomes a trustee of each of the container objects O=MicroCon, OU=RESEARCH, OU=LAB. For O=MicroCon, BWayne receives Supervisor right; for OU=RESEARCH, BWayne receives Browse, Create, and Delete rights; and for OU=LAB, BWayne receives the Create and Delete rights. [Public] is given the Browse and Rename rights to organization O=MicroCon.

Figure 5.51 Object effective rights: NDS tree for case study 8.

The IRFs for the containers follow:

IRF for O=MicroCon     [S B C D R ]
IRF for OU=RESEARCH    [S B C D R ]
IRF for OU=LAB         [S B     R ]

Calculate BWayne's effective rights in containers O=MicroCon, OU=RESEARCH, and OU=LAB. Assume that BWayne does not inherit rights from any other source than the ones listed in the case study.

Figure 5.52 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.52 Object effective rights: worksheet for case study 8.

Entries for O=MicroCon

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B R ] has been given through [Public], of which BWayne is automatically a member. The explicit trustee assignment overrides any other inherited rights for [Public] (of which there are none). BWayne also receives an explicit trustee assignment of Supervisor for O=MicroCon. So, the effective rights for the user BWayne in container O=MicroCon are the sum of the rights through [Public] and through an explicit assignment.

Inherited Rights for [public]        [   B       R  ]
Trustee Assignment for user BWayne   [S             ]
_________________________________
Effective Rights for BWayne          [S  B (C D) R  ]

The Effective rights are through membership to [Public] and through assignment to User object BWayne of the [S ] right. The [ (C D) ] rights are implied because of the Supervisor [S] right.

Entries for OU=RESEARCH

The IRF, according to the case study, is [S B C D R]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B  C D  R ]
Effective rights of parent  [S  B (C D) R ]
__________________________
Inherited Rights            [S  B (C D) R ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=RESEARCH are [S B (C D) R ], and the sources are [Public] and BWayne. BWayne's contribution to the effective rights is [S], and [Public]'s contribution is [B R].

An explicit trustee assignment of [ B C D ] is made to OU=RESEARCH for user BWayne. The explicit trustee assignment overrides any other inherited rights for user BWayne only. The explicit right of [B C D ] for user BWayne overrides the Supervisor (S) right in the inherited rights. With the Supervisor right gone, only the [B R] right in the Inherited rights mask for [Public] remains. The explicit assignment of [B C D] for BWayne cannot override inherited rights from another source, such as [Public], which is the reason that it is so important to keep track of the source of the rights. The effective rights in this case are the sum of the inherited rights from [Public] and the explicit trustee assignment for user BWayne.

Inherited Rights for [Public]          [     B       R   ]
Trustee Assignment for user BWayne     [     B C  D      ]
_________________________________
Effective Rights for BWayne            [     B C  D  R   ]

The effective rights are through [Public] and trustee assignment to BWayne. Please also note that the Browse right is contributed by both [Public] and BWayne. If the Browse right is removed from either [Public] or BWayne, but not both, user BWayne still would have the Browse right.

Entries for OU=LAB

The IRF, according to the case study, is [S B R]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B         R  ]
Effective rights of parent  [   B  C   D  R  ]
________________________
Inherited Rights            [   B         R  ]

The Inherited Rights for OU=LAB are [ B R ], and the sources is [Public] and user BWayne. BWayne's contribution to this right are [ B ], and [Public]'s contribution is [ B R]. An explicit trustee assignment of [C D ] has been given to user BWayne. The explicit trustee assignment overrides any other inherited rights for user BWayne only. BWayne has inherited rights of [B ]. So, the explicit right of [C D R] for user BWayne overrides the inherited rights of [B] for BWayne. The effective rights in this case are the sum of the inherited rights from [Public] and the explicit trustee assignment for user BWayne.

Inherited Rights for [Public]         [   B         R  ]
Trustee Assignment for user BWayne    [      C  D      ]
_________________________________
Effective Rights for BWayne           [   B  C  D   R  ]

The effective rights are through membership to [Public] and through assignment to User object BWayne of the [C D] right.

If the trustee assignment of the Create and Delete rights were revoked from user BWayne for OU=LAB, user BWayne still would have the Browse and Rename rights from [Public]. And, if the [Public] with Browse and Rename rights was removed as a trustee for O=MicroCon, user BWayne still would have the explicit Create and Delete right granted to the user for OU=LAB.

Case Study 9--Computing Effective Rights

Figure 5.53 shows a directory tree for organization SCS.

Figure 5.53 Object effective rights: NDS tree for case study 9.

[Public] is given the Browse right to the [Root] object. User KSS is given the Create right to O=SCS. The Organizational Unit OU=CORP is given the Create and Delete right to OU=ENG. The Group SCIENTISTS is given the [C D R] rights to O=SCS. User KSS is a member of group SCIENTISTS.

The IRFs for the containers follow:

IRF for [Root]   [S B C D R ]
IRF for O=SCS    [S B C D R ]
IRF for OU=ENG   [S B C D   ]

Calculate KSS's effective rights in containers [Root], O=SCS, and OU=ENG. Assume that KSS does not inherit rights from any other source than the ones listed in the case study.

Figure 5.54 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.54 Object effective rights: worksheet for case study 9.

Entries for [Root]

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B ] has been given through [Public], of which KSS is automatically a member. The explicit trustee assignment overrides any other inherited rights for [Public] (of which there are none). So, the effective rights for the user KSS in container [Root] are the same as the explicit rights through [Public].

Entries for O=SCS

The IRF, according to the case study, is [S B C D R]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B  C  D  R      ]
Effective rights of parent  [   B               ]
__________________________
Inherited Rights            [   B               ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for O=SCS are [ B ], and the source is [Public].

An explicit trustee assignment of [ C ] is made to O=SCS for user KSS. The explicit trustee assignment overrides any other inherited rights for user KSS only. Group SCIENTISTS has an explicit trustee assignment of [C D R], which overrides any inherited rights for group SCIENTISTS, if any occurred. The effective rights are the sum of the inherited rights for [Public], and explicit trustee assignments for user KSS and group SCIENTISTS.

Inherited Rights for [Public]             [     B               ]
Trustee Assignment for user KSS           [       C             ]
Trustee Assignment for group SCIENTISTS   [       C D R         ]
_________________________________
Effective Rights for KSS                  [     B C D R         ]

Entries for OU=ENG

The IRF, according to the case study, is [S B C D]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B  C   D     ]
Effective rights of parent  [   B  C   D  R  ]
________________________
Inherited Rights            [   B  C   D      ]

The Inherited Rights for OU=ENG are [ B C D ], and the sources of these rights are [Public], user KSS, and group SCIENTISTS. KSS's contribution to this right is [C ], [Public]'s contribution is [ B ], and group SCIENTISTS' contribution is [D]. An explicit trustee assignment of [C D R ] has been given to container OU=CORP, of which user KSS and group SCIENTISTS are member objects. The explicit trustee assignment overrides any other inherited rights for user container OU=CORP only.

Inherited Rights for KSS, [public], group SCIENTIST   [  B  C D   ]
Trustee Assignment for container OU=CORP              [     C D R ]
_______________________________________
Effective Rights for KSS                              [  B  C D R ]

Case Study 10--Computing Effective Rights

Figure 5.55 shows a directory tree for organization SCS.

Figure 5.55 Object effective rights: NDS tree for case study 10.

[Public] receives the Browse right to the [Root] object. The Organizational Unit container OU=CORP receives the Rename right to OU=ENG and the Supervisor right to O=SCS. User KSS receives a trustee assignment of Browse, Create, Delete, and Rename to O=SCS.

The IRFs for the containers follow:

IRF for [Root]     [S B C D R ]
IRF for O=SCS      [  B C D R ]
IRF for OU=ENG     [S B C D   ]

Calculate KSS's effective rights in containers [Root], O=SCS, and OU=ENG. Assume that KSS does not inherit rights from any source other than the ones listed in the case study.

Figure 5.56 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.56 Object effective rights: worksheet for case study 10.

Entries for [Root]

The IRF, according to the case study, is [S B C D R]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B ] has been given through [Public], of which KSS is automatically a member. The explicit trustee assignment overrides any other inherited rights for [Public] (of which there are none). So, the effective rights for the user KSS in container [Root] are the same as the explicit rights through [Public].

Entries for O=SCS

The IRF, according to the case study, is [ B C D R]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [ B  C  D  R  ]
Effective rights of parent  [ B           ]
__________________________
Inherited Rights            [ B           ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for O=SCS are [ B ], and the source is [Public].

An explicit trustee assignment of [ B C D R ] is made to O=SCS for user KSS. The explicit trustee assignment overrides any other inherited rights for user KSS only. Group OU=CORP has an explicit trustee assignment of [S ], which would override any inherited rights for OU=CORP, if there were any. The effective rights are the sum of the inherited rights for [Public], and explicit trustee assignments for user KSS and OU=CORP.

Inherited Rights for [Public]      [     B         ]
Trustee Assignment for user KSS    [     B C D  R  ]
Trustee Assignment for OU=CORP     [ S             ]
_________________________________
Effective Rights for KSS           [ S   B C D  R  ]

Entries for OU=ENG

The IRF, according to the case study, is [S B C D]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                         [S  B  C   D     ]
Effective rights of parent  [S  B  C   D  R  ]
________________________
Inherited Rights            [S  B  C   D     ]

The Inherited Rights for OU=ENG are [S B C D ], and the sources of these rights are [Public], user KSS, and OU=CORP. KSS's contribution to this right is [B C D R], [Public]'s contribution is [ B ], and OU=CORP's contribution is [S]. An explicit trustee assignment of [R ] has been given to container OU=CORP, of which user KSS is a member object. This explicit trustee assignment overrides any other inherited rights for user container OU=CORP only. OU=CORP has an inherited rights value of [S], and this is overridden by the new trustee assignment of [R]. All that remains of the inherited rights are just the [B C D R].

Inherited Rights for KSS, [public]        [  B  C D   ]
Trustee Assignment for container OU=CORP  [         R ]
_______________________________________
Effective Rights for KSS                  [  B  C D R ]

Examining Property Rights

Property rights are used to control access to information inside an NDS object. All objects have properties, because all objects are used to store information. An object can have many properties, and different objects can be expected to have different properties. A Volume object, for example, has a host server property with a value that is the name of the NetWare server with which the volume is associated.

This property does not exist for a User object, however. Similarly, a user has a group membership property that does not exist for a Volume object. The group membership is an example of a property that is multi-valued. Another example is the telephone number property. A user can have several phone numbers, so the telephone property for the user has the characteristic of accommodating multiple values. The location property of an object is single-valued, because an object can have only one location.

Table 5.5 lists the property rights that are defined for an NDS object.

Table 5.5 Property Rights Summary

Property Right Abbreviation Meaning
Supervisor S Grants all rights to All properties
Compare C Grants the right to compare the value to a property. Does not enable you to see the value.
Read R Grants the right to read the value of a property. Read includes the Compare right, even if the Compare is not explicitly given.
Write W Grants the right to add, remove, change any values to the property.
Add or Delete A Applies to list property values Self such as group membership. Grants the trustee the right to add/remove itself from the property value. The trustee cannot add/delete other values of the property. Useful for mailing lists, group lists.

The Supervisor property right grants all rights to a property. This property can be blocked by the Inherited Rights Filter, if you so desire.

The Compare property right grants the right to compare the value of a property. A trustee with the Compare property right enables a trustee to compare the property value to any value. The result of this comparison is a logical True, if there is a match; and a logical False, if there is no match. This property right is useful for NDS tools that need to check for the existence of a specific value. The Compare right does not give you the right to read a property value. This right is granted by a special property value.

The Read property right grants the right to read a value for a property. This property right is useful for NDS tools that need to display selected property values of an NDS object. If a trustee can read the value, it follows that the trustee should be able to compare the property value against another value. For this reason, a Read property right includes the Compare property right.

The Write property right allows the property value to be changed. Some property values are multi-valued. In this case, the Write property enables the trustee to remove or add values to the property.

The Add or Delete Self property right allows the addition of a new property value or the removal of an existing property value. This right applies to multi-valued properties such as group memberships, mailing lists, or the Access Control List (ACL). The Add or Delete Self property right cannot be used to change the value of properties other than itself.

The Write property right includes the Add or Delete Self property.

All Properties Right versus Selected Property Right

The property rights can be assigned selectively to specific properties, or they can be applied to all the properties of an object. When a property right is assigned to all the properties of an object, it is called the All Properties right. When a property right refers to an individual or selected property, it is called Selected Property right. An example of a property right assignment is when a User object is created in a container. The User object is given the Read property right to all of its properties (All Properties). It is also given a Read/Write property right to its login script property and the Print Job Configuration Property, which enables users to modify their user login scripts and print job configurations. If you want to prevent a user from performing these activities, you must restrict these property rights.

The All Properties right is a convenient way of assigning default property rights to all properties. If some exceptions to this default are found, the Selected Property right can be used to individually set the property right of any property. The Selected Property right overrides the property right set by the All Properties right.

The Access Control List Property

Every object has an Access Control List (ACL) property, also called the Object Trustees property. This property contains a list of all trustees that have a trustee assignment to the object or its property. It does not list other objects to which this object might have rights. In order to grant a right, therefore, you must go to the object and assign a trustee.

The ACL property value can be used to specify any of the following:

Because an ACL is a property of the object that describes the trustee assignments to the object, it can include a trustee assignment to itself. This trustee assignment to the ACL property describes which of the operations defined by the property rights [S C R W A], a trustee could perform.

Consider what would happen if a trustee had a Write property right to the ACL. Such a trustee could then modify the ACL and grant and revoke privileges by changing the ACL value. To perform such modifications, the trustee would also need the Read property right and the Browse object right to the object. The trustee could grant itself Supervisor right to the object, which would give the trustee complete control over the object and its subordinates (unless blocked by an IRF or explicit assignment).

In actual practice, it is unlikely that you want to give an Admin user just the Write right to the ACL property. You probably want to give the Admin user Supervisor object right, which would provide complete control over the object and its subordinates, unless, as noted earlier, you block the Supervisor right.

Normally, you do not single out the ACL property (appears as Object Trustee property in the NetWare Administrator Tool) for giving property rights. You can, however, inadvertently grant the Write right to All Properties. This grant, in turn, grants the Write right to the ACL property, and then the problem in which a user can obtain Supervisor rights exists.


NOTE: Do not assign users the Write property right to the ACL property or the All Properties.

NDS Rights and the File System

A trustee who has the Write property right to the NetWare server's ACL property is granted the Supervisor file system right to the root of each of the server's volume. It is, therefore, important that you do not inadvertently give the Write right to the server's ACL property or the Write right to the server object (All Properties of the server object).

Normally, the NDS rights are independent from the file system rights. The only exception is the one mentioned previously. Actually, the exception is necessary to provide an easy way for a trustee with Supervisor rights to access files and directories in Volume objects.


NOTE: A trustee who has the Write property right to the NetWare server's ACL property is granted the Supervisor file system right to the root of each of the server's volumes.

Consider the Admin user, who normally is given the Supervisor object right to the root container of the tree branch that the user is expected to manage. This user has Supervisor rights to all objects in the tree branch, unless the Supervisor right is explicitly blocked using the IRF. The Supervisor object right grants to the user the Supervisor property right to All Properties for all objects, including the server object. If the user has the Write property right to the server object, the user then inherits the Supervisor NetWare file system right to the root of all volumes for which the server is a host.


NOTE: To make a user an administrator of a tree branch, grant the user Supervisor privileges to the root of the tree branch.

The Admin user could be explicitly granted the Supervisor NetWare file system right to the root of a Volume. In general, any NDS object can be granted an explicit NetWare file system right to a file or directory in any Volume.

Figure 5.57 shows a situation in which the NDS user Admin1.CORP.ESL has been granted Supervisor, Read, and File Scan rights to the SYSTEM directory of a volume, and figure 5.58 shows that the NDS Group object Nfsgroup.CORP.ESL has been granted Read and File Scan rights.

Figure 5.57 NetWare file system right assigned to a user NDS object.

Figure 5.58 NetWare file system right assigned to a group NDS object.

Care must be exercised when assigning a container object a right to another NDS object or a NetWare file system. A right assigned to a container object is inherited by all objects within that container, because a container acts as a logical group of NDS objects.

If a Supervisor NetWare file system right is granted to the [Root] object, for instance, all objects in the [Root] directory are assigned the Supervisor NetWare file system right. And because [Root] is the top-most container of an NDS tree, all objects in the NDS tree are included.

Calculating Property Effective Rights

Calculating property effective rights is similar to calculating object effective rights. The same rules of inheritance apply.

Objects property rights can be dealt with in terms of their All Property Rights or Selective Property Rights. Only All Property Rights can be inherited. Selective Property Rights cannot be inherited. Consider what happens if a Selected Property is allowed to be inherited. A selected property might have no meaning for objects farther down in the tree. Intruder detection is a property of a container object, for example, and if this property is inherited to an object, such as a User object that does not have an intruder detection property, it does not make sense. It might be convenient, however, to assign rights to information inside objects, regardless of the different types of properties NDS objects can have. This task can be done by allowing the All Properties right to be inherited.

The All Properties option and Selected Properties option have separate Inherited Rights Filters, so a right can be blocked at any level. Also, a right assigned to a Selected Property overrides the rights that can be inherited through the All Properties option.

Case Study 1--Computing Property Effective Rights

Figure 5.59 shows a directory tree for organization IBL. Drew becomes a trustee of Organization O=IBL and receives the All Properties rights of Create, Read, Add/Delete Self. The All Properties IRFs for the containers follow:

IRF for O=IBL            [S C R W A]
IRF for OU=CORP          [  C R W  ]
IRF for OU=MKTG          [S     W A]

Figure 5.59 Property effective rights: NDS tree for case study 1.

Calculate Drew's property effective rights in containers O=IBL, OU=CORP, and OU=MKTG. Assume that Drew does not inherit rights from any source other than the ones listed in the case study.

Figure 5.60 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.60 Property effective rights: worksheet for case study 1.

Entries for O=IBL

The IRF, according to the case study, is [S C R W A]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [C R A] has been given to the user. The explicit trustee assignment overrides any other inherited rights, so the effective rights for the user in container O=IBL are the same as the explicit trustee assignment. That is, the property effective rights of the user for O=IBL are [C R A].

Entries for OU=CORP

The IRF, according to the case study, is [ C R W ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                          [    C R W     ]
Effective rights of parent   [    C R      A]
_______________________
Inherited Rights             [    C R       ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=CORP are [C R ]. Because no trustee assignment is made in OU=CORP, the effective rights are the same as the Inherited Rights. That is, property effective rights for OU=CORP are [C R].

Entries for OU=MKTG

The IRF, according to the case study, is [S W A ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                          [S          W A ]
Effective rights of parent   [     C R       ]
_______________________
Inherited Rights             [               ]

The Inherited Rights for OU=MKTG are [ ], or No Rights. Because no trustee assignment is made in OU=MKTG, the effective rights are the same as the Inherited Rights. That is, property effective rights for OU=MKTG are No Rights.

Case Study 2--Computing Property Effective Rights

Figure 5.61 shows a directory tree for organization IBL. James becomes a trustee of Organization O=IBL and receives the All Properties rights of Create, Read, and Write. The All Properties IRFs for the containers are shown below:

IRF for O=IBL            [S C R W A ]
IRF for OU=CORP          [S C R W A ]
IRF for OU=MKTG          [S   R     ]

Calculate James's property effective rights in containers O=IBL, OU=CORP, and OU=MKTG. Assume that James does not inherit rights from any source, other than the ones listed in the case study.

Figure 5.62 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.61 Property effective rights: NDS tree for case study 2.

Figure 5.62 Property effective rights: worksheet for case study 2.

Entries for O=IBL

The IRF, according to the case study, is [S C R W A]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [C R W] has been given to the user. The explicit trustee assignment overrides any other inherited rights, so the effective rights for the user in container O=IBL are the same as the explicit trustee assignment. That is, James' effective property rights for O=IBL are [C R W (A)]. The [(A)] right is implied from the Write right.

Entries for OU=CORP

The IRF, according to the case study, is [S C R W A]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                           [S  C R W  A  ]
Effective rights of parent    [   C R W (A) ]
________________________
Inherited Rights              [   C R W (A) ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=CORP are [C R W (A)]. Because no trustee assignment is made in OU=CORP, the effective rights are the same as the Inherited Rights. That is, James' effective property rights for OU=CORP are [C R W (A)].

Entries for OU=MKTG

The IRF, according to the case study, is [S R ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                           [S      R      ]
Effective rights of parent    [    C  R W (A)]
________________________
Inherited Rights              [   (C) R      ]

The Inherited Rights for OU=MKTG are [ (C) R ]. The [ (C) ] inherited right is implied because of the presence of the Read right in the Inherited Rights. Because no trustee assignment is made in OU=MKTG, the effective rights are the same as the Inherited Rights. That is, James' effective property rights for OU=MKTG are [ (C) R].

Case Study 3--Computing Property Effective Rights

Figure 5.63 shows a directory tree for organization DCS. James becomes a trustee of Organization O=DCS and receives the All Properties rights of Create, Read, and Write. James is a member of the group ATEAM. ATEAM receives the All Properties rights Write and Add/Delete Self to OU=SALES. James also becomes a trustee of Organizational Unit OU=MKTG, and receives the All Properties of Write. The All Properties IRFs for the containers follow:

IRF for O=DCS            [S C R W A ]
IRF for OU=SALES         [S C R W A ]
IRF for OU=MKTG          [S   R     ]

Figure 5.63 Property effective rights: NDS tree for case study 3.

Calculate James's effective property rights in containers O=DCS, OU=SALES and OU=MKTG. Assume that James does not inherit rights from any source other than the ones listed in the case study.

Figure 5.64 shows the completed worksheet containing the answers. The explanations for entries in the worksheet are presented next.

Figure 5.64 Property effective rights: worksheet for case study 3.

Entries for O=DCS

The IRF, according to the case study, is [S C R W A]. No rights are inherited from above, and therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [C R W] has been given to the user. The explicit trustee assignment overrides any other inherited rights, so the effective rights for the user in container O=DCS are the same as the explicit trustee assignment. That is, James' effective property rights for O=DCS are [C R W (A)]. The [(A)] right is implied from the Write right.

Entries for OU=SALES

The IRF, according to the case study, is [S C R W A]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                           [S  C R W  A  ]
Effective rights of parent    [   C R W (A) ]
________________________
Inherited Rights              [   C R W (A) ]

The masking operation is a logical AND operation, which means that an entry needs to be in both the rights for it to be in the final result.

The Inherited Rights for OU=SALES are [C R W (A)]. A trustee assignment is made to Group object SALES of Write and Add/Delete Self. This would override any inherited trustee assignments for Group object ATEAM. But since no trustee assignments are inherited for Group object ATEAM, there are no rights to override. You cannot override the inherited rights of [C R W (A) ], because these rights are for User object James and not Group object ATEAM.

Because James is a member of group ATEAM, his rights to OU=SALES are the sum of the inherited and effective rights.

Inherited Rights for user James    [  C  R  W (A) ]
Trustee Assignment for ATEAM       [        W  A  ]
__________________________________
Effective Rights for James         [  C  R  W  A  ]

That is, property effective rights of User object James for OU=SALES are [C R W A]. Notice that the Add/Delete Self right is no longer an implied right [(A)], because it was explicitly assigned to group ATEAM. Also, the Write right is derived from both the Inherited Rights and trustee assignment to Group object ATEAM. If this right is removed from the trustee assignment, the Write right still exists in the effective rights because it is derived from the Inherited Rights.

Entries for OU=MKTG

The IRF, according to the case study, is [S R ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

IRF                           [S      R      ]
Effective rights of parent    [    C  R W A  ]
________________________
Inherited Rights              [   (C) R      ]

The Inherited Rights for OU=MKTG are [ (C) R ]. The actual right inherited is [R], but the [ (C) ] inherited right is implied, because of the presence of the Read right in the Inherited Rights. Both of these rights are due to rights assigned to user James. Because an explicit trustee assignment is made in OU=MKTG to user James, the explicit trustee assignment of [W] overrides the inherited rights. That is, effective property rights for OU=MKTG are [ W (A) ]:

Inherited Rights for James    [   (C)  R           ]
Trustee Assignment for James  [              W (A) ]
_________________________
Effective Rights for James    [              W (A) ]

Guidelines for Implementing NDS Security

Novell offers the following NDS security guidelines.

1. Start with the default assignments.

The default assignments are adequate for most users and most circumstances. The defaults are designed to give users access to information they need without giving them excessive rights.

2. Avoid assigning rights through All Properties of an object.

All Properties rights can give users access to private information about users and other objects. In some cases, excessive rights can accrue to users, because they have rights to critical properties such as the Object Trustee (ACL) property of an object.

3. Use Selected Property rights to assign/restrict properties.

Use Selected Property rights to assign or restrict access to individual properties. Remember that Selected Property rights override All Properties rights.

4. Be careful how you assign Write property right to the Object Trustees (ACL) property of an object.

The Write property right to the ACL of an object enables users to add themselves as trustees to the object and give themselves Supervisor rights. Remember that if you have All Properties Supervisor or Write property right to an object, you will automatically have Write property to the ACL of the object, unless you use the Selected property IRF for the ACL property to block the Write right.

5. Assigning Supervisor object right grants to the trustee the All Properties Supervisor property right to the object.

Because of the all inclusive privileges that are implied by Supervisor object rights, you might want to assign to the container administrator a more limited set of rights. For example, you might assign the [BCDR] object rights to the container, and selected property rights to specific properties. If you decide to use the All Properties rights, ensure that the user does not derive the Write property right to the Object Trustees (ACL) property. You can prevent inheritance of rights by using explicit trustee assignment to a property or using the selected property IRF.

6. Use caution in assigning Supervisor object right to the server object.

Assigning a trustee Supervisor object right to the server object gives to the trustee the All Properties right to the server object. The All Properties Supervisor property right to the server object gives to the user the Write property right to the ACL of the server object. The Write property right to the ACL of the server object gives to the user the Supervisor file system right to the root of all volumes attached to the server.

7. Be careful about filtering the Supervisor object right and deleting the only user who has rights to a subtree.

In decentralized administration, it is common for the container administrator to be the only user to have Supervisor object right to the container. Others are prevented from having Supervisor object right by the use of the IRF. If the only user that has Supervisor object right (the container administrator, in this case) is deleted, that particular branch of the NDS tree can no longer be managed.

For Profile objects and Directory Map objects, you need to assign additional NDS rights:

1. To use a Profile object, the user must have the Read property right to the Login Script property of the Profile object. If the user has the Read All Properties right to the Profile object, this implies that the user also has the Read property right to the Login Script property (unless the selected property IRF is set for the Login Script property to block the Read right).

2. To use a Directory Map object, the user must have the Read property right to the Path property of the Directory Map object. If the user has the Read All Properties right to the Directory Map object, this implies that the user also has the Read property right to the Path property (unless the selected property IRF is set for the Path property to block the Read right).

Comparing NetWare File System Security with NDS Security

Both NDS and NetWare file system security make use of the concepts of trustees, trustee rights, inheritance, and the Inherited Rights Filter. For a user to gain access to an object (NDS or file/directory), the user must be made a trustee to an object and given appropriate rights. The rights flow down the tree and can be blocked by the IRF. The actual rights a user has at any level of the tree are called effective rights.

The differences between NDS and NetWare file system security follow:

When a User object is created, automatic file system rights are created, except to the user's home directory, if one was specified at the time of creation. Figure 5.65 shows the rights to newly created user CN=KSS.O=IMF to the home directory USERS\KSS in volume CN=FS1_SYS.OU=SALES.O=ESL. Notice that the user has [S R W C E M F A] rights to his home directory; that is, the user has All Rights to his home directory.

Figure 5.65 The rights of user KSS in home directory.

In NetWare 3.x, the term Inherited Rights Mask (IRM) was used to describe the mechanism to block the flow of NetWare file system rights. In NetWare 4.x, the term Inherited Rights Filter (IRF) is used for both file system rights and NDS object rights.


STUDY NOTE:Another minor distinction, though not documented in the Novell manuals, is that in NetWare 3.x the Supervisor file system rights were called Supervisory. They are now called Supervisor in NetWare 4.x.

As in NetWare 3.x, the file system Supervisor right granted to a directory also grants Supervisor rights to files and directories below the directory.

One major conceptual difference between the NetWare 3.x and NetWare 4.x file system is the scope of the trustee. In NetWare 3.x, the trustee could be only a user account or a group account defined in the server's bindery. In NetWare 4.x, User objects and Group objects in containers other than in the location where the volume is installed can be assigned trustees. The trustee is not limited to the User and Group objects; it can be any NDS object, such as another container object. If a container object is made a trustee of file/directory, all objects within it (including, of course, User and Group objects) inherit the trustee rights to the file or directory.


PRACTICAL TIP: When dealing with assigning file/directory rights, it is simpler to assign the rights using a container object, if the NDS containers and the leaf objects are properly designed to reflect usage of resources.

Any NDS object that has a Write right to the ACL property (Object Trustee property) of the NetWare server object also is granted the Supervisor right to the root of each of the volumes hosted by the NetWare server. Because a Supervisor file/directory right cannot be blocked by an IRF, this fact should be a consideration in setting up security rights.

The Write property right can be granted through the following:

1. Write right to All Properties of the NetWare server object.

2. Write right to the Selected Property ACL (Object Trustee) for the NetWare server object.

3. Supervisor right to the All Properties right or ACL property (Selected Property) for the NetWare server object.

4. Supervisor object right to the NetWare server object. This causes the object to have Supervisor right to the All Properties of the NetWare server object.

5. Security equivalence to an object that has any of the rights listed previously.


STUDY NOTE: The differences between NDS and NetWare file system security are the following:


Directory and file attributes in NetWare 4.x are a superset of the rights for NetWare 3.x. That is, NetWare 4.x directory and file attributes include all those for NetWare 3.x, and the rights listed in table 5.6.

Table 5.6 Additional NetWare 4.x Attributes

Attribute File/Directory Abbreviation Description
Migrate File M Indicates that the file has migrated to near-line storage.
Don't Migrate File/Directory Dm Prevents a file or the files in a directory from migrating.
Compress File Co Indicates whether a file has been compressed.
Don't Compress File/Directory Dc Prevents a file or the files in a directory from being compressed.
Immediate Compress File/Directory Ic Marks specified file or files in a directory for compression as soon as the OD can perform compression.
Can't Compress File Cc Indicates that a file cannot be compressed because of limited space saving benefit.

The attributes Migrate (M), Compress (Co), and Can't Compress (Cc) are status attributes that indicate the status of individual files only. The other attributes, Don't Migrate (Dm), Don't Compress (Dc), and Immediate Compress (Ic), apply to both files and directories, and specify actions that are to be performed or prevented from occurring.


STUDY NOTE: The attributes Migrate (M), Compress (Co), and Can't Compress (Cc) are status attributes and indicate the status of individual files only. Attributes Don't Migrate (Dm), Don't Compress (Dc), and Immediate Compress (Ic) apply to both files and directories.

The Data Migration feature is installed using INSTALL.NLM and requires a near-line-storage media that acts as a secondary to the primary hard disk storage area.

The compression feature is enabled or disabled on a volume-by-volume basis during installation. It can be further controlled by a variety of SET parameters.


STUDY NOTE: The Data Migration feature is installed using INSTALL.NLM, and the compression feature is installed on a per-volume basis.

Study Guide for the Chapter

If you are preparing for the NetWare 4.x Administration CNE exams, review the chapter with the following goals:

1. Review the different types of login restrictions that can be performed in NetWare 4.x. Understand the basics of NetWare login authentication. Understand how NDS security is implemented. Use the Study Notes as a quick review.

2. Pay particular attention to the topics of NDS trustee assignments for objects and properties. Understand how inheritance and security equivalence can be used in computing effective rights. Go through the case studies and understand the reasoning behind the solutions to them. Practice assigning NDS rights using NetWare Administrator. You may be asked questions on this procedure.

3. After studying this chapter, attempt the sample test questions. If you make mistakes, review the appropriate topic.

Except for Chapter 2, "Introduction to NetWare Directory Services," on NDS fundamentals, this chapter is the most important one, because it deals with issues on NDS security, which is essential for implementing NDS effectively.

Chapter Summary

In this chapter, you learned the basics of NetWare 4.x security. NetWare security is layered. The first layer you must pass through is login authentication and login restriction. The second layer is NDS security. The last (third) layer is the NetWare file system security. You also read an explanation of how login authentication is performed.

Most of the chapter was spent in NDS security issues, because this is a new area for NetWare 3.x administrators. Several case studies were presented to help you understand how NDS security works.

Chapter Test Questions

Test questions can have a single correct answer or multiple correct answers. Where a single answer is desired, it is indicated by a l notation that precedes the possible answers. Some questions require you to select more than one answer; these are indicated by the n preceding each answer. Not all the questions are multiple choice; occasionally, you might get a question that asks you to type in an answer. The answer in this case is usually a one word answer. The answer is not case sensitive. So you can type in the answer in lower- or uppercase.

Certain questions will be repeated in different ways, so that you can recognize them even when the wording is different. Taking practice quizzes will not only test your knowledge but will give you confidence when you take your exam.

For questions dealing with calculating Effective Rights, the answers should include any implied rights. For example, if the computed effective property right is [ R ], your answer should also include the Compare (C) right, as the Read right also includes the Compare right. Therefore the correct answer would be [C R] and not just [R]. In the case studies, the notation [ (C) R] was used to indicate that the Compare right was an implied right. Unless the test question asks you to make the distinction between actual effective rights and implied rights, you should include both in your answer.

1. The ______ command logs in as a user Mona defined in the Organizational Unit ART, in the Organization RAL, given that the current context is O=ART.

A. LOGIN Mona.RAL

B. LOGIN .Mona.ART.RAL

C. LOGIN .Mona.RAL.ART

D. LOGIN Mona.ART.RAL.

2. Which of these are valid login restrictions for NetWare 4.x?

A. Account restrictions

B. Password authentication

C. Station restrictions

D. Password synchronization and time-out

E. Time restrictions

3. Network address restrictions are properties of a ______.

A. User object

B. container object

C. Organizational Unit object

D. Organization object

E. Volume object

4. In NetWare 4.x, intruder detection ______.

A. is used to lock out a user if the user makes unauthorized access to the network

B. prevents unauthorized access by non-Admin users

C. locks a user's access to the network if an incorrect password was typed in too many times

D. prevents a server from responding to an unauthorized access request

5. In NetWare 4, authentication assures that ______.

A. the message applies to a valid user session

B. the message comes from a secure monitoring station that was used to build the initial authentication data

C. the message applies to the current session

D. the message applies to any valid user session

6. The Rename trustee assignment can be used to rename a/an ______ object.

A. Root

B. container

C. leaf

D. Organization

E. Organizational Unit

7. The Create object right applies to ______ objects only.

A. top

B. container

C. leaf

D. Organization

E. Organizational Unit

8. Which of the following is correct for a newly created User object?

A. The [Root] object is made a trustee of the container object the user is installed in.

B. The [Root] object is made a trustee of the User object and given Rename rights.

C. The [Root] object is made a trustee of the User object and given Supervisor rights.

D. The [Root] object is made a trustee of the User object and given Read right to Network Address and Group Membership property.

E. The [Root] object is made a trustee of the User object and given Read right to Network Address property.

9. When an NDS tree is newly created, the [Public] trustee is given ______.

A. Read object rights to [Root]

B. Read object rights to every container object immediately under [Root]

C. Create object rights to every container object immediately under [Root]

D. Browse object rights to [Root]

E. Browse object rights to every container object immediately under [Root]

10. The Admin user account for a newly created NDS tree is given ______.

A. Write rights to the ACL property of every server object

B. Supervisor object rights to all container objects

C. Supervisor object rights to all leaf objects

D. Supervisor object rights to [Root]

11. Assigning rights to the [Root] container gives ______.

A. container objects the right to all leaf objects in their container

B. User objects that right to the entire tree

C. User objects that right to the entire tree unless this right is explicitly removed using IRF

D. leaf objects the right to all container objects

12. Which of the following statements about IRF is true?

A. The IRF is the same as the Inherited Rights.

B. The IRF is the same as the effective rights.

C. The default IRF for objects is all rights.

D. The IRF is set only for container objects.

13. If a user has the Write right to the Security equivalence property and Write property right to the ACL of an Admin User object ______.

A. the user can read other users' security equivalence

B. the user can modify other users' security equivalence

C. the user can become security equivalent to another user, but not the Admin user

D. the user can become security equivalent to any user including the Admin user

14. An effective right can originate from any of the following sources:

A. Explicit trustee assignment

B. Inherited from trustee's parent container

C. Inherited from direct assignment to object's container

D. Inherited from the leaf object

E. Inherited from assignment of trustee's container to object's container

15. To compute the effective rights, which of the following can be used?

A. Inherited Rights Mask

B. Inherited Rights Filter

C. Inherited Rights

D. Explicit Trustee Assignment

E. Public rights

16. The Selected Property right overrides the property right set by the ______.

A. object trustee rights

B. selected property rights of parent

C. All Properties right

D. Inherited Rights Filter

E. Inherited Rights

17. If a user was given a Read and Write right to the ACL property, the user ______.

A. could only assign himself the right of the parent container

B. could become an Admin user by changing the ACL

C. could become the Admin user of the container object only

D. cannot acquire Admin privileges

18. A trustee who has the Write property right to a NetWare server's ACL ______.

A. is assigned the Write privileges to the root of the volumes attached to the server

B. is assigned the Read/Write privileges to the root of the volumes attached to the server

C. is assigned the Read/File Scan/Write privileges to the root of the volumes attached to the server

D. is assigned the Supervisor privileges to the root of the volumes attached to the server

19. To make a user an administrator of a tree branch, you can minimally ______

A. grant the user Supervisor privileges to the root of the tree branch

B. grant the user Supervisor privileges to the root of the NDS tree

C. grant the user Write privileges to the All Properties of the root of the tree branch

D. grant the user Supervisor privileges to the All Properties of the root of the tree branch

20. Which of the following attributes apply to files only?

A. Don't Migrate (Dm)

B. Migrate (M)

C. Don't Compress (Dc)

D. Immediate Compress (Ic)

E. Compress (Co)

F. Can't Compress (Cc)

21. The NetWare 4.x compression is installed on a ______.

A. directory basis

B. file basis

C. volume basis

D. file server

22. The Don't compress (Dc) attribute ______.

A. indicates that the file has migrated to near-line storage

B. prevents a file or the files in a directory from migrating

C. indicates if a file has been compressed

D. prevents a file or the files in a directory from being compressed

E. specifies file or files in a directory are marked for compression as soon as the server can perform compression

F. indicates that a file cannot be compressed because of limited space saving benefit

23. The Can't compress (Cc) attribute ______.

A. indicates that the file has migrated to near-line storage

B. prevents a file or the files in a directory from migrating

C. indicates if a file has been compressed

D. prevents a file or the files in a directory from being compressed

E. specifies file or files in a directory are marked for compression as soon as the server can perform compression

F. indicates that a file cannot be compressed because of limited space saving benefit

24. The following figure shows a directory tree for organization IBL. BJoy is made a trustee of Organization O=IBL and given the rights of Supervisor, Browse, and Create. BJoy is also given a trustee assignment of Browse in OU=MKTG. The IRFs for the containers are shown as follows:
	IRF for O=IBL                [S B C D R]
	IRF for OU=CORP              [S B C    ]
	IRF for OU=MKTG              [      D R]
The [Public] group has been given Browse right to [Root].

What is BJoy's effective rights in container OU=MKTG? Assume that BJoy does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Browse, Create

B. Browse

C. Browse, Create, Delete

D. Supervisor

E. Create, Delete

F. No Rights

25. The following figure shows a directory tree for organization IBL. BJoy is made a trustee of Organization O=IBL and given the All Properties rights of Supervisor, Compare, Read. The IRFs for the containers are shown as follows:
	IRF for O=IBLS               [S C R W A]
	IRF for OU=CORP              [  C R W  ]
	IRF for OU=MKTG              [S     W A]
What is BJoy's effective rights in container OU=MKTG? Assume that BJoy does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read

B. Supervisor

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write

E. No Rights

26. The following figure shows a directory tree for organization IBL. BJoy is made a trustee of Organization O=IBL and given the rights of Supervisor, Read. BJoy is also given a trustee assignment of Write in OU=MKTG. The IRFs for the containers are shown as follows:
	IRF for O=IBL           [S C R W A]
	IRF for OU=CORP         [S C R    ]
	IRF for OU=MKTG         [    R W A]
What is BJoy's effective rights in container OU=MKTG? Assume that BJoy does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Write, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. No Rights

27. The differences between NDS and NetWare file system security are that ______.

A. NDS rights are further sub-divided into object rights and property rights

B. there is no Supervisor right in NDS whereas NetWare file system has Supervisor right

C. in NDS rights, the Supervisor object right and property right can be blocked by the IRF. In NetWare file system right the Supervisor right cannot be blocked

D. NDS rights do not flow to a NetWare file system right, except in one important case

E. NDS rights are the same as NetWare file system rights

28. Which of the following rights allows you to rename a leaf or container object?

A. Supervisor

B. Create

C. Delete

D. Rename

E. Browse

29. Which one of these NDS objects cannot have Create rights?

A. Root

B. container

C. leaf

D. Organization

E. Organizational Unit

30. Which of the following statements about [Public] is true?

A. [Public] is a special trustee that includes all users in a container object.

B. [Public] is a special trustee that includes all users in an Organization object.

C. [Public] is a special trustee that includes all users in an Organizational Unit object.

D. [Public] is a special trustee that includes all users connected to the network.

31. Security equivalence is a property of the ______.

A. leaf object

B. container object

C. Root object

D. User object

E. Group object

32. The following figure shows a directory tree for organization IBL. BJoy is made a trustee of Organization O=IBL and given the rights of Supervisor, Browse, and Create. BJoy is also given an object trustee assignment of Create and Delete in OU=MKTG. The IRFs for the containers are shown as follows:
	IRF for O=IBL                [S B C D R]
	IRF for OU=CORP              [S B C    ]
	IRF for OU=MKTG              [      D R]
The [Public] group has been given Browse right to [Root].

What is BJoy's effective rights in container OU=MKTG? Assume that BJoy does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Browse, Create

B. Browse

C. Browse, Create, Delete

D. Supervisor

E. Create, Delete

F. No Rights

33. The Write property right grants you ______.

A. the right to change any values to the property

B. the right to remove and change any values to the property

C. the right to add, remove, change any values to the property

D. the right to read, add, remove, change any values to the property

34. The following figure shows a directory tree for organization IBL. Amy is made a trustee of Organization O=IBL and given the rights of Supervisor, Read. Amy is also given a trustee assignment of Write in OU=MKTG. The IRFs for the containers are as follows:
	IRF for O=IBL              [S C R W A]
	IRF for OU=CORP            [S C R    ]
	IRF for OU=MKTG            [    R W A]
What is Amy's effective rights in container OU=MKTG? Assume that Amy does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Read, Write, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. No Rights

35. The following figure shows a directory tree for organization SCS. KSS is made a trustee of Organization O=SCS and given the rights of Supervisor and Create. KSS is also given a trustee assignment of Browse in OU=CORP. The IRFs for the containers are as follows:
	IRF for O=SCS               [S B C D R]
	IRF for OU=CORP             [S B C    ]
	IRF for OU=MKTG             [    C D R]
The [Public] group has been given Browse right to [Root].

What is KSS's effective rights in container OU=MKTG? Assume that KSS does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Browse, Create, Delete, Rename

B. Browse

C. Supervisor, Browse, Create

D. Supervisor, Create

E. Create

F. No Rights

G. Create, Delete, Rename

36. The figure that follows shows a directory tree for organization SCS. KSS is made a trustee of Organization O=SCS and given the rights of Supervisor. KSS is also given a trustee assignment of Delete and Rename in OU=CORP. The IRFs for the containers are as follows:
	IRF for O=SCS                [S B C D R]
	IRF for OU=CORP              [S B C    ]
	IRF for OU=MKTG              [    C D  ]
The [Public] group has been given Browse right to [Root].

What is KSS's effective rights in container OU=MKTG? Assume that KSS does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Browse, Create, Delete, Rename

B. Browse

C. Delete

D. Supervisor, Browse, Create

E. Create, Delete

F. No Rights

G. Delete, Rename

37. The figure below shows a directory tree for organization SCS. DAVID is made a trustee of Organization O=SCS and given the rights of Create, Rename. DAVID is also given a trustee assignment of Delete in OU=MKTG. The IRFs for the containers are as follows:
	IRF for O=SCS            [S  B C D R ]
	IRF for OU=CORP          [   B C   R ]
	IRF for OU=MKTG          [   B   D R ]
The [Public] group has been given Browse right to [Root].

What is DAVID's effective rights in container OU=MKTG? Assume that DAVID does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Browse, Create, Delete, Rename

B. Browse, Delete

C. Delete

D. Browse, Delete, Rename

E. Browse, Create, Rename

F. No Rights

G. Browse

38. The figure below shows a directory tree for organization SCS. MARIAN is made a trustee of Organization O=SCS and given the rights of Supervisor, Create, Rename. MARIAN is also given a trustee assignment of Delete, Rename, and Create in OU=CORP and a trustee assignment of Rename in OU=MKTG. The IRFs for the containers are shown as follows:
	IRF for O=SCS              [S B C D R]
	IRF for OU=CORP            [         ]
	IRF for OU=MKTG            [         ]
The [Public] group has been given Browse right to [Root].

What is MARIAN's effective rights in container OU=MKTG? Assume that MARIAN does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Browse, Create, Delete, Rename

B. Rename

C. Delete

D. Supervisor, Create, Rename

E. Delete, Create, Rename

F. No Rights

G. Browse

39. The following figure shows a directory tree for organization NTE. Tesla is made a trustee of Organization O=NTE and given the all property rights of Supervisor, Compare. Tesla is also given all property trustee assignment of Read and Write in OU=LAB. The IRFs for the containers follow:
	IRF for O=NTE               [S C R W A]
	IRF for OU=INVE             [S C R    ]
	IRF for OU=LAB              [    R W A]
What is Tesla's effective rights in container OU=LAB? Assume that Tesla does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Write, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. No Rights

40. The following figure shows a directory tree for organization NTE. Bohr is made a trustee of Organization O=NTE and given the all property rights of Read and Write. Bohr is also given all property trustee assignment of Read and Write in OU=INVE. The IRFs for the containers are as follows:
	IRF for O=NTE              [S C R W A]
	IRF for OU=INVE            [S C R    ]
	IRF for OU=LAB             [      W  ]
What is Bohr's effective rights in container OU=LAB? Assume that Bohr does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Write, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. No Rights

F. Supervisor, Compare, Read

41. The following figure shows a directory tree for organization NTE. Rutherford is made a trustee of Organization O=NTE and given the all property rights of Read. The IRFs for the containers follow:
	IRF for O=NTE               [S        ]
	IRF for OU=INVE             [S C R    ]
	IRF for OU=LAB              [    R W A]
What is Rutherford's effective rights in container OU=LAB? Assume that Rutherford does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Write, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. Compare, Read

F. No Rights

42. The following figure shows a directory tree for organization NTE. Faraday is made a trustee of Organization O=NTE and given the all property rights of Supervisor. The IRFs for the containers are shown as follows:
	IRF for O=NTE              [S         ]
	IRF for OU=INVE            [S       A ]
	IRF for OU=LAB             [          ]
What is Faraday's effective rights in container OU=LAB? Assume that Faraday does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Supervisor, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. Supervisor

F. No Rights

43. The following figure shows a directory tree for organization NTE. Neumann is made a trustee of Organization O=NTE and given the all property rights of Supervisor. The IRFs for the containers are as follows:
	IRF for O=NTE               [          ]
	IRF for OU=INVE             [S       A ]
	IRF for OU=LAB              [S         ]
What is Neumann's effective rights in container OU=LAB? Assume that Neumann does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Supervisor, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. Supervisor

F. No Rights

44. The following figure shows a directory tree for organization NTE. Bose is made a trustee of Organization O=NTE and given the all property rights of Supervisor. Bose is also given the Write property to OU=LAB. The IRFs for the containers are as follows:
	IRF for O=NTE               [         ]
	IRF for OU=INVE             [         ]
	IRF for OU=LAB              [         ]
What is Bose's effective rights in container OU=LAB? Assume that Bose does not inherit rights from any source other than the ones listed in the case study.

A. Supervisor, Compare, Write, Read, Add/Delete Self

B. Write, Add/Delete Self

C. Supervisor, Write, Add/Delete Self

D. Compare, Read, Write, Add/Delete Self

E. Supervisor

F. No Rights


Previous chapterNext chapterContents


Macmillan Computer Publishing USA

© Copyright, Macmillan Computer Publishing. All rights reserved.