Migrating to Netware 4.1 -- Ch 10 -- Implementing NetWare 4.x Security

Previous page
Table of content
Next page
'; zhtm += '

' + pPage + ''; zhtm += ''; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 } //-->


Migrating to Netware 4.1

- 10 -

Implementing NetWare 4.x Security

  • Login Security
    • Account Restrictions
    • Password Restrictions
    • Time Restrictions
    • Station Restrictions
    • Intruder Limits
  • Login Authentication
  • NDS Security
  • NDS Rights
  • Clarifying Terminology
  • Object Rights
    • Supervisor Object Right
    • Browse Object Right
    • Create Object Right
    • Delete Object Right
    • Rename Object Right
  • The [Public] Trustee
  • Default Object Rights
  • Inheritance of Object Rights
  • Inherited Rights Filter
  • Security Equivalence
  • Object Effective Rights
  • Calculating Object Effective Rights
    • Case Study 1--Computing Effective Rights
    • Case Study 2--Computing Effective Rights
    • Case Study 3--Computing Effective Rights
    • Case Study 4--Computing Effective Rights
    • Case Study 5--Computing Effective Rights
    • Case Study 6--Computing Effective Rights
    • Case Study 7--Computing Effective Rights
    • Case Study 8--Computing Effective Rights
    • Case Study 9--Computing Effective Rights
    • Case Study 10--Computing Effective Rights
  • Property Rights
    • All Properties Right versus Selected Property Right
    • The Access Control List Property
    • NDS Rights and the File System
  • Calculating Property Effective Rights
    • Case Study 1--Computing Property Effective Rights
    • Case Study 2--Computing Property Effective Rights
    • Case Study 3--Computing Property Effective Rights
  • Network Administration Strategies
    • Setting Up a Container Administrator and Assigning Rights
    • NDS Security Guidelines
    • Exclusive Container Administrator
    • Setting Up Central Administration of Containers (Non-Exclusive Container Administrator)
    • Danger of Giving a Workgroup Manager Write Property Right to the ACL of a Container
    • Types of Administrative Accounts
    • Objects with Special Rights Assignments
    • Rights for Traveling Users
  • Guidelines for Determining Excessive Rights
  • Guidelines for Determining the Cause of Insufficient Rights
  • NetWare File System Security

Now that your NetWare 4 network is installed, you are probably wondering how to keep it secure. There are three elements to NetWare 4 security:

  • Login security

  • NDS security

  • File system security

This chapter describes each of these elements. NDS security is a vast and complex subject and one you should be familiar with if you want to get the most from NetWare 4. Most of this chapter focuses on NDS security. NetWare 3 has no equivalent to NDS security. Study this chapter carefully. NDS security is a very versatile and powerful tool, and if implemented correctly, it will give your users the freest possible access to network resources without compromising security. This power, however, comes with some real dangers if you don't assign rights carefully and systematically.

Login Security

Login security, shown in figure 10.1, has a number of components. Login security controls who can gain initial entry into the network. Unlike NetWare 3.x, where the authentication of a user was done against the definition of the user in a server's bindery, the login of a user in NetWare 4 must be done against a global NDS database. For instance, a user logging in as object CN=KARANJIT in container O=ESL, must, after initial attachment to the network, type either of the following commands:

LOGIN .CN=KARANJIT.O=ESL

or

LOGIN .KARANJIT.ESL

Figure 10.1 NetWare 4 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 will recall from the discussion in Chapter 2, "Designing Your NDS Tree," is the location (pointer) in the NDS tree. The user can also use a partial name to log in to the network. For example, if the current context is [Root], the following commands could 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 being logged in to, the following commands could 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. 10.2). These login restrictions follow:

  • Account Restrictions

  • Password Restrictions

  • Station Restrictions

  • Time Restrictions

  • Intruder Limits

Figure 10.2 Login restrictions.

The login restrictions in figure 10.2 are similar to those in NetWare 3.x, except that the restrictions are applied to NDS objects, and they are done through the NetWare administrator and the NETADMIN tools.

The procedure for setting these restrictions is briefly described in the following sections.

Account Restrictions

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

  • Disabling the user account

  • Setting an expiration date on the user account

  • Limiting Concurrent Connections

Figure 10.3 shows the account restriction properties for a User object. In this figure the account is enabled. This is indicated by the absence of the check box on Account Disabled. The Account Has Expiration Date shows that the expiration date on the account is 8/22/99 at 2:00:00 a.m. Also, the concurrent connections are limited to 3. This means that the user CN=KARANJIT.O=ESL can log in on no more than three stations at the same time.

Figure 10.3 Account (Login) Restrictions dialog box.

To get to figure 10.3, 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 10.4.
Set the context of the NDS tree so you can see the entire NDS tree. You can set the context by performing the following:

Select the View menu, then Set Context

3. Examine a container that has User objects defined. Figure 10.5 shows a portion of the NDS tree that has several users defined.

Highlight a User object and examine its properties. You can do this by double-clicking on the User object. Or right-click on the User object and select the Details option.

Figure 10.6 shows the properties of the User object.

4. Press the Login Restrictions page button, and you will see the dialog box for setting account restrictions.

Figure 10.4 NetWare Administrator showing NDS tree.

Figure 10.5 NDS tree with several user objects defined.

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

Password Restrictions

Password Restrictions is a property of a User object. Password Restrictions includes the capability to restrict a user's password in the following ways:

  • By enabling the user to change (or not change) the user password.

  • By requiring (or not requiring) that a password always be set.

  • By specifying (or not specifying) a minimum password length.

  • By forcing (or not forcing) users to change passwords periodically. The periodicity of change can be set from 1 to 365 days, and can be set to start at any date and time.

  • By forcing (or not forcing) users to set unique passwords.

  • By limiting grace logins to a specific number from 1 to 200.

Figure 10.7 shows the Password Restrictions properties for a User object. In this figure, the user is allowed to change her password. A password is required, and its minimum length is 5. The user is forced to change passwords periodically starting from 10/1/94 at 2:00:00 AM, and at intervals of every 40 days after that. The password that a user enters must be unique from previous passwords the user might have used. The user is allowed a limit of 6 grace logins after the password expires, and currently there are 5 grace logins left. If the user does not change the password in the specified number of logins, the account is disabled. It can be reenabled by an Administrator.

Figure 10.7 The Password Restrictions dialog box.

To get to figure 10.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. You can do this by double-clicking on the User object. Or, right-click on the User object and select the Details option.

5. Select the Password Restrictions page button, and the Password Restrictions dialog box appears.

Time Restrictions

Time Restrictions is a property of a User object. The Time Restrictions property can restrict a user's login privileges in the following ways:

  • The user can log in during specific days of the week only.

  • The user can log in during specific times of the day only.

  • The granularity of time interval that can be set for logging in is 30 minutes.

Figure 10.8 shows the Login Time Restrictions properties for a User object. In this screen, the user is allowed to log in on weekdays only. Access on Sunday and Saturday is denied for the times from those days shaded in gray. On weekdays, the user is not allowed to log in from 10 p.m. to 12 a.m., or from 12 a.m. to 4 a.m. This means the user can only log in from Monday through Friday between 4 a.m. and 10 p.m.

Figure 10.8 The Login Time Restrictions dialog box.

To get to figure 10.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. You can do this by double-clicking on the User object. Or, right-click on the User object and select the Details option.

5. Select Login Time Restrictions page button, and the Time Restrictions dialog box appears.

Station Restrictions

Station Restrictions (also called Network Address Restrictions) include the capability to restrict a user's ability to log in from specific workstations. In NetWare 4.x, Station Restrictions is more powerful and general than in NetWare 3.x. Station Restrictions in NetWare 3.x could only be done on the hardware address (MAC address) of the workstation's network board. In NetWare 4.x, Station Restrictions include the capability to restrict based on a protocol address. For this reason, the station restriction also is called Network Address Restriction in NetWare 4.x. Network Address Restriction is a property of a User object, and enables you to restrict logins based on protocol addresses for the following:

  • IPX/SPX

  • SDLC

  • AppleTalk

  • OSI

  • TCP/IP

  • Ethernet/Token-Ring

The Network Address formats for some of the address formats are shown in figures 10.9 through 10.11.

Figure 10.9 IPX/SPX address restriction.

Figure 10.10 TCP/IP address restriction.

Figure 10.11 Ethernet/Token-ring address restriction.

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

The TCP/IP Address format (refer to fig. 10.10) is the IP address, which is a 4-byte logical address that is expressed in a dotted-decimal notation. Each of the 4 bytes that make up the IP address are expressed in their equivalent decimal number (range 0 to 255) and separated by a dot (.).

The Ethernet/Token-Ring address format (refer to fig. 10.11) 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), which 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 can be considered to be one long field that can be used to code the station's MAC address.

NOTE: Because of the potential confusion the terms BLOCKID and PUID can create with non-SNA network administrators, Novell might change the way addresses are entered for Ethernet/Token-Ring. Also, ARCnet users will have to use the Ethernet/Token-Ring Address entry. This is counter-intuitive. Hopefully changes will be made to make these fields more understandable. For more details on address mechan-isms, refer to the author's book, NetWare: The Professional Reference, also from New Riders Publishing.

To see the Network Address Restriction screens shown in figures 10.9 through 10.11, 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. You can do this by double-clicking on the User object. Or, right-click on the User object and select the Details option.

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

Intruder Limits

Intruder Limits is set in a container object and applies to all User objects within the container. It limits the user's access to the network if an incorrect password was typed too many times. The account is then locked, and you can use the screen in figure 10.12 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, select the Account Locked check box.

Figure 10.12 The Intruder Lockout screen.

To get to the Intruder Lockout screen, 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. You can do this by double-clicking on User object. Or, right-click on User object and select the Details option.

5. Select the Intruder Lockout page button, and you will see the dialog box for accessing the Intruder Lockout screen (refer to fig. 10.12).

NOTE: Intruder Limits is set in a container object and applies to all user objects within the container.

NOTE: The container objects on which Intruder Limits can be set are

Organization objects

Organizational Unit objects

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 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.

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 ensures 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.

NetWare 4.x authentication is based on the RSA (Rivest, Shamir, Adleman) algorithm. This is a public key encryption algorithm that is extremely difficult to break. The public and private key are strings of numbers that are independent of each other. This independence means that one cannot derive one key from the other. Prime numbers (numbers divisible only by one and themselves) have this property, so they are typically used for public and private keys. One of the keys is kept private, which means only a designated user knows about it, and the other key is public, which means that all users on the network can have access to it. If a message is encrypted with a private key, it can be decrypted with a public key. And, if a message is encrypted with a public key, it can be decrypted with a private key. This means that a workstation can encrypt its name M, with a private key Kp to form an encrypted message. Any entity on the network, such as a NetWare server, can decode this message with the public key (Kg) using the decryption algorithm (such as RSA), and discover that only the user M could have sent it (because the message contains a coding for the user name).

This relationship can be expressed mathematically as the following: Message M, encrypted with private key Kp, using encryption algorithm E = E(M,Kp)

Decrypting message N using public key Kg, using decryption algorithm D = D(N,Kg)

If message N was is an encrypted message; that is, N = E(M,Kp), it follows that: D(E(M,Kp), Kg) = M In step 1 of figure 10.13, a client agent on behalf of the user requests authentication. Authentication Services returns the private key for the user encrypted with the user's password (Pu). This is shown as step 2. That is, Authentication Services returns:

Figure 10.13 NetWare 4 Login Authentication.

E(Kp, Pu) The user types the password and the client agent uses the password supplied by the user (Pu) to decrypt the message. That is, the private key is known to the user, by using: D(E(Kp,Pu), Pu) = Kp The password is then erased from memory to prevent a hacker (correctly speaking, a cracker) from illegally obtaining it. With the private key the client agent creates a credential (also called an authenticator). The authenticator contains the user's complete name, the workstation's address, and a validity period that is the period of time the authenticator will remain valid. There are also other undocumented values that make up the authenticator. In other words, the authenticator (A) is a mathematical function of the previously named values: A = f(Complete Name of user, Workstation's Address, Validity Period ...) The client then creates a signature (S), by encrypting the Authenticator (A) with its private key (Kp). S = E(A, Kp) A proof (P) is then constructed that contains values derived from the Signature (S), the request for authentication (Rq), and a random number generated value (Rn), and is further encrypted by the user's public key (Kg). P = E (f(S, Rq, Rn), Kg) The (S, Rq, Rn) in the equation above is a mathematical combination of the Signature (S), request for authentication (Rq), and a random number generated value (Rn).

The proof is then sent across the network, instead of the signature (S). This prevents anyone from illegally obtaining the signature. The proof (P) accompanies each authentication request, and is unique for a request. The random number generator makes it different for each message.

The final request for service (see step 3 in fig. 10.13) contains the request for authentication, the authenticator, and the proof. Final Request = Rq+A+P Authentication Services checks that the proof contains the signature and the message request. It can do this by decoding the proof with the private key (Kp). D (P, Kp) = D (E(f(S, Rq, Rn),Kg), Kp) = f(S,Rq,Rn). Once S has been obtained, it can decode S with a public key (Kg). Remember that, S = E(A, Kp) So decoding S would give back the Authenticator: D(S, Kg) = D(E(A,Kp), Kg) = A Also, the Authenticator (A) was A = f(Complete Name of user, Workstation's Address, Validity Period ...) From the previous, the Authentication Services can discover the complete name of the user, its workstation address, the validity period, and any other parameters that were encoded. It would be extremely difficult for any other workstation to spoof another workstation's identity.

The proof assures the Authentication Services that the message has not been modified.

As you can see, the scheme is clever and sufficiently complicated that breaking the authentication security is a daunting task.

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

NDS Security

Once the user is validated for network services, NDS security determines which network resources (NDS objects) the user can access. The kind of operations a user is permitted to perform on an NDS object, and on files and directories in volumes on the network, are called rights. The operations permissible on NDS objects are called NDS object rights and the operations permissible on a NetWare file system are called file system rights. These two are quite different. The discussion in this section focuses on NDS object rights.

NDS object rights have many uses. Suppose a user wants to view the structure of a tree. Should the user be allowed to view the directory structure? Viewing the structure (also called browsing) of a tree would be very valuable for a user if the user were 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 types of rights that are useful are the Create, Delete, or Rename objects rights. You would not want an ordinary user to have these rights. An Administrator should have a special right called the Supervisor right, which would grant the Administrator all privileges to a directory object.

When a right is assigned to a container directory 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 an 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. 10.14). For the most part, a user/group needs the same right 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!

Figure 10.14 If object rights could not be inherited.

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. 10.15). What if some objects in the container need a different set of rights (see fig 10.16). In this case, there needs to be a mechanism to block the flow of rights below a certain container. This mechanism is called the Inherited Rights Filter (IRF) and will be discussed in greater depth in another section.

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

Figure 10.16 Blocking inheritance of object rights in NetWare 4.

Another important question is: 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 do this. NDS object rights gives 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.

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. 10.17). These two rights are quite different.

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

Figure 10.17 Object versus property rights.

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

NDS rights that restrict access to 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.

An NDS object that is granted a specific right to another object is called the trustee of the object (see fig. 10.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 may seem strange, at first, to think of a container object as a trustee to another object. In Chapter 2, you learned 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. Moreover, these rights flow down to other containers and objects unless explicitly blocked at a tree level.

In summary, there are two types of NDS rights:

1. Object rights

2. Property rights

The next few sections discuss object rights. This will be followed by a discussion of property rights.

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

Clarifying Terminology

When a right is assigned to object A for another object, B, then 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, along with the right that has been granted, is 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 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 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.

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.

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

Table 10.1 shows the different object rights possible.

TABLE 10.1 Object Rights

Object Right Abbreviation Meaning
Supervisor S Grants all rights. Assigning this right automatically gives Supervisor rights to the objects All Properties (discussed in a later section).
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 directory object within the container. Cannot be given to leaf objects, because they cannot contain subordinate objects.
Delete D Grants right to delete an NDS object. Only leaf objects and empty container objects can be deleted.
Rename R Grants right to rename 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 is an exception. Normally, object rights do not affect access to the contents of the object.

A special right, called the All Properties property, is used to describe all the properties. When a Supervisor right is assigned, a Supervisor property right is also assigned to All Properties. And it is for this reason that all access to the information inside the object is given if an object has the Supervisor 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 that is 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 by (in other words, it flows down to) all objects in the NDS tree.

If you want--for security reasons--to deny access to users in a specific part of the NDS tree, you can do this 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 10.19 shows an attempt to assign an object right to a leaf object, such as the User1.CORP.ESL_XXX. Notice that the object right Create is not shown as an option for this user.

Figure 10.19 The Create right is not possible for leaf objects.

You must also have Browse rights, in addition to Create rights, to a container before you can create an object underneath the container using a tool such as NetWare Administrator.

Delete Object Right

This grants the trustee the right to delete an object. A container object can only be deleted if it has no other objects underneath it. You must delete the leaf and sub- container objects before you can delete a container. As you can see, this rule is primarily to prevent inadvertent damage to the NDS tree.

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

NOTE: You can, however, delete a file server's Volume object, even while users are logged in to it! This can have disastrous consequences, as users cannot access the volume using NDS. Don't try this on a production system!

TIP: If someone does manage to delete the Volume object, try this fix:

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

2. If an error message is generated, a) reboot the server, and b) connect to the server using VLM /PS=servername. Replace servername with the name of the server that has the physical Volume whose Volume object representation was deleted.

3. Log in to server and 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 using INSTALL.NLM:
From the file server console:

1. Type LOAD INSTALL.NLM.

2. Select Directory Options.

3. Select Install/Reinstall mounted volumes into the Directory.

You will be asked to log in to the NDS as an Admin. INSTALL will then prompt you to add deleted volumes back into the NDS structure. The volume will be 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.

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).

The [Public] Trustee

Earlier it was mentioned that everyone is given the Browse right. Readers familiar with NetWare 3.x may recall that almost everyone was given the Read and File Scan (RF) rights to SYS:PUBLIC. This was done using the group called EVERYONE. There are no default groups called EVERYONE (or a similar name) in NetWare 4.x. So the problem is, how do you assign to everyone the Browse right?

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 that they can use to 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 useful aspect of the Browse right that is available for attached users/work-stations is that it permits NDS to interface with third-party tools or other X.500 implementations that might want to search Novell's implementation of NDS (DIB (Directory Information Base) in X.500 terms for names of resources and information on the tree structure.

To solve this problem, the designers of NDS created an implicit group called [Public]. An implicit group is different from other groups, called explicit groups (such as group objects), in the sense that it does not have an explicit membership. 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, are automatically members of the group [Public]. This makes it possible to assign rights to workstations that are not authenticated by NetWare 4.x.

TIP: You must take care to assign to [Public] a minimal set of rights. Otherwise, non-authenticated connections to the network can have excessive rights to the network.

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

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

There may be situations where you want users to browse only portions of the NDS tree, rather than allow the entire NDS tree to be browsed. In this case, the default trustee assignment of Browse for [Public] to the [Root] object can be removed, and this right assigned to the root container (top of tree branch) for which the user needs to see directory resources. See figures 10.21 and 10.22, 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 10.22 and 10.23, the root of this tree branch is at the organization object level O=ESL; it could also be at a lower level in the tree such as at an organizational unit level.

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

Figure 10.21 NetWare administrator showing default trustee assignments to [Root] object.

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

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

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

[Public] does not have an explicit membership; that is, users cannot be added or deleted.

Membership to [Public] is based on being connected to the network.

Default Object Rights

NetWare 4.x sets certain default system rights to reduce the number of administration tasks you would otherwise have to perform. One of these default rights is the [Public] trustee's Browse right to the [Root] object. Some of the other default rights are discussed in this section.

The container object that contains the SYS volume object is given the Read and File Scan (RF) rights to the SYS:PUBLIC directory of the volume object. This is shown in figure 10.24. This figure 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 10.24 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 is by default placed in the organization object container and is named Admin. For security reasons, it might be advisable to rename this User object and move it to another context.

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

  • The [Root] object is made a trustee to the User object and given the Browse object right (see fig. 10.25). This means that any NDS object can browse the User object.

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

Another default right is that the creator of the server object is given the Supervisor object right to the server object.

The default rights assigned during NDS installation, file server object installation, and user object creation are summarized in tables 10.2, 10.3, and 10.4.

Figure 10.25 Default [Root] trustee assignment for user object.

TABLE 10.2 Default NDS Rights during NDS Installation

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

TABLE 10.3 Default NDS Rights during Server Installation

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

TABLE 10.4 Default NDS Rights for User Object

Trustee NDS Right Comments
[Public] [R] (Read) property right to Default Server property of user object Enables 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 Enables 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 Enables user to read the values of any property stored in the User object. Enables users to change their login scripts.
[RW] (Read, Write) property rights to the Login Script property for the user object [RW] (Read, Write) property rights to the Print Job Configuration property for the user object Enables users to change their print job configurations.

Inheritance of Object Rights

When an object trustee assignment is made, the right granted to the trustee is inherited by all objects that are subordinate to it. In the case of container objects, this means that all leaf objects in the container, and all sub-containers, inherit this right. This inheritance of rights is sometimes called the flowing down of rights. 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 10.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 sub-containers: the organizational units OU=CORP and OU=ENG. The rights assigned to KSS for O=ESL flow to these sub-containers. 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. The user rights to organizational unit container OU=ENG flow to its two sub-containers OU=OPS and OU=LAB.

Figure 10.26 Example of inheritance of object rights.

The rights inherited by the OU=LAB container flow further down the tree, but the OU=R&D sub-container 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 then becomes the new right [B]. This new right flows down to subordinate containers below OU=R&D. In figure 10.26, these subordinate containers are OU=LASER and OU=NNET. User object KSS inherits the right [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 can also be controlled by the use of the Inherited Rights Filter. This topic is discussed next.

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 a right to the [Root] container will give User objects that right to the entire tree, unless this right is explicitly removed using IRF.

Inherited Rights Filter

The Inherited Rights Filter 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 what inherited rights are allowed to be received from above.

Every NDS object has an Inherited Rights Filter (IRF). The default value of the IRF is all object rights [S B C D R]. This means that an NDS object has the potential to inherit all rights. The IRF is often confused with the actual object right. The sole purpose of IRF is to block a right from flowing further down. The IRF cannot be used to block an explicit trustee assignment. 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 the NetWare 4.x file system (which is the same as NetWare 3.x's 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 could not 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 Supervisor rights for that object.

In the first NetWare 4.0 release, you were given a warning message when you attempted to remove the Supervisor object right from an IRF. You could, however, override this warning and remove the Supervisor right from the IRF anyway. This essentially produced a black hole in the tree that no one could have access to. Starting with NetWare 4.01, the warning was changed to an error message. If you attempt to remove the Supervisor right from an IRF, an error message is produced instead. This error message informs you that:

You cannot filter the Supervisor object right because no object has explicit Supervisor object right to this object.

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

Figure 10.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 (see fig. 10.28).

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 check box. You should see the error message in figure 10.27.

Figure 10.28 The Inherited Rights Filter screen.

If at least one 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, there is at least one object that can manage the object and its subordinate objects.

TIP: Though the Supervisor right can allow a trustee to perform all operations on an object, it is a good practice to assign other rights, in case the Supervisor right is accidentally removed. From the above discussion, you can see that NetWare 4.01 (and higher) checks to see if there exists at least one trustee that has a Supervisor right before allowing the Supervisor right to be removed; but you might still want to assign other rights as a precautionary measure in case of failures or bugs in an NDS release.

Security Equivalence

A User object can be granted all the security rights of another NDS object. This is called security equivalence, and is a property of the User object. Figure 10.29 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 previosuly mentioned objects have. These rights are in addition to the rights that user Dei already has.

Figure 10.29 The Security Equivalence property of a User object.

NOTE: Security equivalence is a property of the User object.

Because Security Equivalence is a property of the User object, care should be taken that the user does not have the right to make changes to this property. If a user does have such a right 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 would give the user all the rights the Admin user has. The default for a newly created user is that a user can read his Security Equivalence property, and you should not normally have to change this value.

One situation where 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).

Object Effective Rights

An object's effective rights are the rights that a user actually has to the object. The effective right is not the same as the rights inherited from a parent container, because these could be blocked by the IRF. Also, a user may have a right blocked for it, but might inherit a right because a group that the user belongs to 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 that the user belongs to 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 may be inherited from a number of sources. This makes the determination of NDS rights an interesting and challenging task. Consider the example in figure 10.30.

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.

  • Explicit trustee assignment. This includes the trustee assignment on HP_PRINTER that lists user KSS as a trustee (see fig. 10.31).

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

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

  • 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. 10.34). The rights so assigned must pass through the object HP_PRINTER's IRF.

  • Trustee assignment to a Group object. Any trustee assignment made to the Group object MGRS in which the user KSS is a member of (see fig. 10.35).

  • 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 is automatically inherited by user KSS (see fig. 10.36).

Figure 10.30 Sources for computing effective rights.

Figure 10.31 Effective object rights: explicit trustee assignment.

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

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

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

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

As you can see from the preceding discussion, to compute effective rights, one must consider the following:

  • The rights explicitly granted to a User object.

  • The rights inherited from above.

  • The rights granted to container objects between the object and the [Root]. This applies to container objects that are between the object and the [Root] and the trustee and the [Root].

  • The rights granted through security equivalence.

The next section will present case studies that will give you practice in computing effective rights.

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

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, a number of case studies will be presented that will help you understand how effective rights work in NetWare 4.x. Please see figure 10.37.

Figure 10.37 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, there are entries for:

  • Inherited Rights Filter (IRF)

  • Inherited rights

  • Trustee assignment

  • Effective rights

Figure 10.37 Worksheet for computing effective rights.

You'll find that the worksheet is an invaluable aid for determining effective rights 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 worksheet and compute effective rights more directly.

Ten case studies are presented, each with a discussion of solutions. The case studies range from simple to complex. Ten case studies might seem to be a lot, but the more practice you have the more confident you will 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 4.39 shows a directory tree for organization IBL. Drew is made a trustee of organization O=IBL and given the rights of Browse, Create, and Rename. The IRFs for the containers are shown below:

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 sources other than the ones listed in the case study.

Figure 10.38 Object effective rights: Directory tree for Case Study 1.

Figure 10.39 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.39 Object effective rights: Worksheet for Case Study 1.

Entries for O=IBL

The IRF, according to the case study, is [S B C D R]. There are no rights inherited from above; 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 is the same as the explicit trustee assignment. That is, the effective rights of the user 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:

RF                            [    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 both sets of rights 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, 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:

RF                            [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, effective rights for OU=MKTG are No Rights.

Case Study 2--Computing Effective Rights

Figure 10.40 shows a directory tree for the organization IAF. Hari is made a trustee of organization O=IAF and given the rights of Browse, Create, Delete, and Rename. The IRFs for the containers are shown below:

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 10.40 Object effective rights: Directory 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 sources other than the ones listed in the case study.

Figure 10.41 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Entries for O=IAF

The IRF, according to the case study, is [S B C D R]. There are no rights inherited from above; 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, effective rights of the user for O=IAF are [B C D R].

Figure 10.41 Object effective rights: Worksheet for Case Study 2.

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, effective rights for OU=CORP are [B C D].

Entries for OU=MKTG

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     ] ---------------------------------------------- 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 10.42 shows a directory tree for organization SCS. Dei is made a trustee of organization O=SCS and given the rights of Browse, Create, Delete, and Rename. Dei is also given a trustee assignment of [B C D R] to OU=LAB. The IRFs for the containers are shown below:

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

Figure 10.42 Object effective rights: Directory 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 sources other than the ones listed in the case study.

Figure 10.43 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.43 Object effective rights: Worksheet for Case Study 3.

Entries for O=SCS

The IRF, according to the case study, is [S B ]. There are no rights 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 of the user for O=SCS are [B C D R].

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 sets of rights for it to be in the final result.

The inherited rights for OU=CORP are [B ]. Because no trustee assignment is made in OU=ENG, the effective rights are the same as the inherited rights. That is, 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, effective rights for OU=LAB are [ B C D R ].

Case Study 4--Computing Effective Rights

Figure 10.44 shows a directory tree for organization SCS. Karanjit is made a trustee of organization O=SCS and given the rights of Supervisor. Karanjit is also given a trustee assignment of Browse, Create, Delete, and Rename to OU=ENG. The IRFs for the containers are shown below:

Figure 10.44 Object effective rights: Directory tree for Case Study 4.

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

Calculate Karanjit's effective rights in containers O=SCS, OU=ENG, and OU=LAB. Assume that Karanjit does not inherit rights from any sources other than the ones listed in the case study.

Figure 10.45 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.45 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]. There are no rights inherited from above; 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, the effective rights of the user for O=SCS are [S (B C D R)]. The rights in parentheses (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 C       ] Effective rights of parent      [S (B C D  R)] ---------------------------------------------- Inherited Rights                [S (B C D R) ]

The masking operation is a logical OR operation, which means that an entry needs to be in both sets of 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, effective rights for OU=ENG are [B C D R ]. What is interesting about this case study is that the inherited rights to OU=ENG were all object rights. But by explicitly assigning a lesser right, this lesser right overrides the greater rights inherited from above.

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 there's no explicit trustee assignment to OU=LAB, the effective rights are the same as the inherited rights. That is, effective rights for OU=LAB are [ B R ].

Case Study 5--Computing Effective Rights

Figure 10.46 shows a directory tree for organization KJBR. John is made a trustee of organizational unit OU=LAB and given the Supervisor right. There is a group object OWNERS that has been given a trustee assignment of Browse and Create for organization O=KJBR. John is a member of this group.

The IRFs for the containers are shown below:

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 sources other than the ones listed in the case study.

Figure 10.47 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.46 Object effective rights: Directory tree for Case Study 5.

Figure 10.47 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]. There are no rights 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 the effective rights for the user in container O=KJBR are the same as the explicit trustee assignment. That is, the effective rights of the user for O=KJBR are [B C ]. The worksheet also shows that the effective rights that were computed are for Group object OWNERS, of which John is a member. When calculating effective rights where there could be rights from several sources, you should keep note of the source of the rights because a right can come from many different sources, and you can easily become confused if you do not keep track of the right's origin.

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 sets of rights for it to be in the final result.

The inherited rights for OU=PDEV are [ B], and the source of that inheritance 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, the 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          ] ---------------------------------------------- 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. There is an inherited right of [B], but this is through group OWNERS. So the explicit right of [S] for user John does not override the inherited right for group OWNERS. This is why 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: [ 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 is revoked from user John for OU=LAB, user John would still have the Browse right from membership to Group object OWNERS. And, if the user John were removed as a member of group OWNERS, John would still 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 10.48 shows a directory tree for organization KJBR. Bob is made a trustee of organizational unit OU=LAB and given 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 rights for organizational unit OU=PDEV.

Figure 10.48 Object effective rights: Directory tree for Case Study 6.

The IRFs for the containers are shown as follows:

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 source other than the ones listed in the case study.

Figure 10.49 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.49 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]. There are no rights inherited from above; 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 the user in container O=KJBR is the same as the explicit trustee assignment. That is, effective rights of the user 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 where there could be rights from several sources, you should keep a note of the source of the rights because a right can come from a number of different sources, and you can easily become confused if you do not keep track of the right's origin.

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. This is why 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 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 the groups OWNERS and MGRS.

If the user Bob is removed as a member of group OWNERS, Bob would still have the explicit [ B C D] rights granted to him by membership to MGRS. And, if Bob is removed as a member of group MGRS, Bob would still 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 C ]. The rights inherited from above are the effective rights of the parent container masked with the IRF for this container:

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

The inherited rights for OU=LAB is [ 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. There is an inherited right of [C], but this is through group MGRS. So the explicit right of [S] for user Bob, does not override the inherited rights for group MGRS. This is why 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: [ S (B) C (D R) ]. The [(B) (D R)] rights are implied because of the presence of the Supervisor (S) right.

If the trustee assignment of Supervisor right is revoked from user Bob for OU=LAB, user Bob would still have the Create right from membership to Group object MGRS. And, if the user Bob is removed as a member of group MGRS, Bob would still 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 10.50 shows a directory tree for organization MicroCon. JConnor is made a trustee of organizational unit OU=RESEARCH and given the Supervisor, Create, Delete, and Rename rights. JConnor is also made a trustee of OU=LAB and is given the Create right. [Public] is given the Browse right to organization O=MicroCon.

The IRFs for the containers are shown as follows:

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 sources other than the ones listed in the case study.

Figure 10.51 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.50 Object effective rights: Directory tree for Case Study 7.

Figure 10.51 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]. There are no rights inherited from above; therefore, the entry for Inherited Rights is None. An explicit trustee assignment of [B ] has been given through [Public], of which JConnor 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 in container O=MicroCon are the same as the explicit trustee assignment. That is, the effective rights of the user 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 a note of the source of the rights because a right can come from a number of different sources, and you can easily become confused if you do not keep track of the right's origin.

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 of that inheritance 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 right of [S C D R] for user JConnor, does not override the inherited rights of [B] whose source is [Public]. This is why 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 the 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 these rights 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. There are inherited rights of [C D R] for JConnor. So, the explicit right of [C D R] 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      [      C        ] ---------------------------------------------------------- Effective Rights for JConnor             [   B  C        ]

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

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

Case Study 8--Computing Effective Rights

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

The IRFs for the containers are shown as follows:

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 sources other than the ones listed in the case study.

Figure 10.52 Object effective rights: Directory tree for Case Study 8.

Figure 10.53 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.53 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]. There are no rights inherited from above; 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 is also given 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 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 sets of rights for it to be in the final result.

The inherited rights for OU=RESEARCH are [S B (C D) R ], and its 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, there are only the [B R] rights in the inherited rights mask for [Public]. The explicit assignment of [B C D] for BWayne, cannot override inherited rights from another source such as [Public]. This is why 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 the trustee assignment to BWayne. Please also note that the Browse right is contributed by both [Public] and BWayne. If the Browse right were to be removed from either [Public] or BWayne, but not both, user BWayne would still 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 are [Public] and user BWayne. BWayne's contribution to these rights is [ 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. There is an inherited right of [B], for BWayne. So the explicit rights of [C D R] for user BWayne override the inherited right 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 is revoked from user BWayne for OU=LAB, user BWayne would still have the Browse and Rename rights from [Public]. And, if the [Public] with Browse and Rename right is removed as a trustee for O=MicroCon, user BWayne would still have the explicit Create and Delete rights granted to the user for OU=LAB.

Case Study 9--Computing Effective Rights

Figure 10.54 shows a directory tree for organization SCS.

Figure 10.54 Object effective rights: Directory 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 container OU=CORP is given the Create and Delete rights 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 are shown as follows:

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 sources other than the ones listed in the case study.

Figure 10.55 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.55 Object effective rights: Worksheet for Case Study 9.

Entries for [Root]

The IRF, according to the case study, is [S B C D R]. There are no rights 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. There is also an explicit trustee assignment of [ D R] for group SCIENTISTS. This would override any inherited rights for group SCIENTISTS, if there were any. The effective rights are the sum of the inherited rights for [Public] and the 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          [         D  R  ] ------------------------------------------------------------------ Effective Rights for KSS                         [    B C  D  R  ]

The effective rights are through [Public] and the trustee assignments to KSS and group SCIENTISTS.

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's 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 10.56 shows a directory tree for organization SCS.

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

Figure 10.56 Object effective rights: Directory tree for Case Study 10.

The IRFs for the containers are shown as follows:

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 sources other than the ones listed in the case study.

Figure 10.57 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Entries for [Root]

The IRF, according to the case study, is [S B C D R]. There are no rights inherited from above; 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 right through [Public].

Figure 10.57 Object effective rights: Worksheet for Case Study 10.

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 is [ 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. There is also an explicit trustee assignment of [S] for group OU=CORP. This 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 the 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 ]

The effective rights are through [Public] and trustee assignments to KSS and OU=CORP.

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 these rights 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]. What remains of the inherited rights is just [B C D].

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

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. For example, a volume object has a host server property whose value is the name of the NetWare server the volume is associated with. But this property does not exist for a user object.

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.

NOTE: The X.500 term for a property is an attribute. An attribute can consist of a type and one or more values. In NDS, these values are termed property values. The attribute type determines the characteristics of the attribute, such as its syntax, number of values allowed, how the values can be tested for comparison, and so on. If the attribute value can contribute toward the name of an object, it is called a distinguished attribute value. An example of this would be the name attribute of an object.

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

TABLE 10.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 allow you to see the value.
Read R Grants right to read the value of a property. Read includes the Compare right, even if the Compare right is not explicitly given.
Write W Grants the right to add, remove, or change any values to the property.
Add or A Applies to list property values such as group
Delete Self 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.

The Compare property right grants the right to compare the value of a property. A trustee with the Compare property right allows a trustee to compare the property value to any value. The result of this comparison is a logical True if there is a match or a logical False if there is no match. This property right would be 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 would be 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 allows the trustee to remove or add values to the property.

The Add or Delete Self property right allows the addition of 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 a property other than itself.

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

All Properties Right versus Selected Property Right

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 a Selected Property right. An example of property rights 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. This allows the user to modify his user login script and print job configuration. Should you want to prevent a user from performing these activities, you will have to restrict these property rights.

The All Properties right is a convenient way of assigning default property rights to all properties. If there are some exceptions to this default, 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 that this object might have a right to. Because of this, to grant a right, you must go to the object and then assign a trustee. You cannot go to the trustee and add objects that this trustee might have rights to.

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

  • An object right, such as the [S B C D R] rights

  • A right to all properties of the object, called the "All Properties" right

  • A right to a specific property

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 would describe which of the operations described 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. Specifically, it could grant itself Supervisor right to the object; this 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 would want to give an Admin user just the Write right to the ACL property. You would probably want to give the Admin user Supervisor object right. This would give the Admin user complete control over the object and its subordinates, unless, as noted earlier, you block the Supervisor right.

Normally, you would probably not single out the ACL property (which appears as Object Trustee property in the NetWare Administrator tool) to give property rights to. But you could inadvertently grant the Write right to All Properties. This in turn would grant the Write right to the ACL property, and then the problem described earlier would exist.

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 volumes. 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 pointed out in the previous example. 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 is normally given the Supervisor object right to the root container of the tree branch that user is expected to manage. This user would then have Supervisor rights to all objects in the tree branch, unless the Supervisor right is explicitly blocked. The Supervisor object right would grant 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 also be granted the Supervisor NetWare File System right to a volume object. In general, any NDS object can be granted an explicit NetWare File System right to a file or directory in any volume object, even though an NDS object is usually granted NDS security rights. Figure 10.58 shows a situation where the user Admin1.CORP.ESL has been granted Supervisor, Read, and File Scan rights to the SYSTEM directory of a volume, and figure 10.59 shows that the NDS group object Nfsgroup.CORP.ESL has been granted Read and File Scan rights.

Figure 10.58 NetWare File System right assigned to a user NDS object.

Figure 10.59 NetWare File System right assigned to a group NDS object.

Excercise care 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.

For instance, if a Supervisor NetWare File System right is assigned to the [Root] object, all objects in the [Root] directory will be assigned the Supervisor NetWare File System right. And because [Root] is the top-most container of an NDS tree, this assignment would include all objects in the NDS tree.

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 Properties rights or Selected Property rights. Only All Properties rights can be inherited. Selected Property rights cannot be inherited. Consider what would happen if a Selected Property were allowed to be inherited. A selected property might have no meaning for objects further down in the tree. For instance, intruder detection is a property of a container object, and if this property were inherited to an object that does not have an intruder detection property, such as a User object, it would not make sense. On the other hand, it might be convenient to assign rights to information inside objects, regardless of the different types of properties NDS objects can have. This can be done by allowing the All Properties right to be inherited.

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

Case Study 1--Computing Property Effective Rights

Figure 10.60 shows a directory tree for organization IBL. Drew is made a trustee of organization O=IBL and given the All Properties right of Create, Read, Add/Delete Self. The All Properties IRF for the containers are shown as follows:

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

Figure 10.60 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 10.61 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Entries for O=IBL

The IRF, according to the case study, is [S C R W A]. There are no rights inherited from above; 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].

Figure 10.61 Property effective rights: Worksheet for Case Study 1.

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 sets of 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, the property effective rights for OU=MKTG are No Rights.

Case Study 2--Computing Property Effective Rights

Figure 10.62 shows a directory tree for organization IBL. James is made a trustee of organization O=IBL and is given the All Properties rights of Create, Read, and Write. The All Properties IRFs for the containers are shown as follows:

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

Figure 10.62 Property effective rights: NDS tree for Case Study 2.

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

Figure 10.63 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Entries for O=IBL

The IRF, according to the case study, is [S C R W A]. There are no rights inherited from above; 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, the property effective rights of the user for O=IBL are [C R W (A)]. The [(A)] right is implied from the Write right.

Figure 10.63 Property effective rights: Worksheet for Case Study 2.

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, the property effective 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, property effective rights for OU=MKTG are [ (C) R].

Case Study 3--Computing Property Effective Rights

Figure 10.64 shows a directory tree for organization DCS. James is made a trustee of organization O=DCS and is given the All Properties right of Create, Read, and Write. James is a member of the group ATEAM. ATEAM is given the All Properties right of Write and Add/Delete Self to OU=SALES. James is also made a trustee of the organizational unit OU=MKTG, and given the All Properties right of Write. The All Properties IRF for the containers are shown as follows:

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 10.64 Property effective rights: Directory tree for Case Study 3.

Calculate James' property effective 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 10.65 shows the completed worksheet. The explanations for entries in the worksheet are presented next.

Figure 10.65 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]. There are no rights inherited from above; 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, the property effective rights of the user 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 sets of 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 because 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 is [C R W A]. Notice that the Add/Delete to 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 the trustee assignment to group object ATEAM. If this right were removed from the trustee assignment, the Write right would still exist in the effective rights because it would then be 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, property effective 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) ]

Network Administration Strategies

For a small organization, the NDS tree can be managed by a single Administrator user. For larger organizations, it is more practical for the functions of network administration to be carried out by a number of users. In this case, the network administration tasks need to be divided among several network administrators. One way of doing this is to assign a tree branch to each administrator.

Figure 10.66 shows the NDS tree for organization O=ESL with several Administrators for the department tree branches. The tree branches with the organizational units OU=CORP, OU=ENG, and OU=MKTG have Administrators CN=Admin.OU=CORP.O=ESL, CN=Admin.OU=ENG.O=ESL, and CN=Admin.OU=MKTG.O=ESL, respectively. Typically, these Administrators have complete responsibility for managing their NDS tree branch, but no rights to manage another tree branch. The department Administrators do not have rights to manage objects in the context O=ESL. Resources in context O=ESL are managed by user CN=Admin.O=ESL that is defined in the O=ESL context. The CN=Admin.O=ESL Administrator can create new organization containers and manage rights to the [Root] object, but typically does not have rights to manage the tree branches for the individual departments.

Figure 10.66 Administrators per NDS tree branch.

A second way to manage the NDS tree is to have one administrator account that manages the entire NDS tree (centralized administration), and additionally assign assistant administrators who help the main network administrator. You can also distribute certain administration tasks to assistant administrators who each preside over those tasks for a specific network branch. This is similar to the work group manager concept used in NetWare 3.x.

In general, centralized administration is appropriate for a small network that wants to have a single administrator. There are, however, some tasks that should be centrally administered; these include the following:

  • Naming the directory tree

  • Installing the first NetWare server in the directory tree

  • Creating the top-most levels of a directory tree

  • Managing partitioning, replication, and time synchronization

  • Assigning container Administrators (administrators of sub-trees)

Distributed management is generally preferred for larger networks. The following tasks can generally be distributed:

  • Creating user accounts

  • Defining and configuring print services

  • Assigning file system trustees

  • Creating workgroup managers

  • Installing additional servers in the NDS tree

  • Performing filesystems and backups

Setting Up a Container Administrator and Assigning Rights

If only one person is expected to be the Administrator of a container, you can create the appropriate trustee assignments for the user.

If you need to assign more than one person as an Administrator for the container, you can make use of the Organizational Role object. If you decide to use Organizational Role objects, you should, as a precaution, give another user Supervisor object trustee assignments to the container, in case the Organizational Role object is accidentally (or deliberately) deleted. The Organizational Role is particularly useful when the users who are assigned administrative responsibilities are changed often, but the administrator's responsibility does not change. When a user is made an occupant of an Organizational Role, the Organizational Role object is listed in the user object's Security Equal to property.

The following is a guideline for setting up container administrators using Organizational Role objects:

1. Create an Organizational Role object in the container to be managed.

2. Make the Organizational Role object a trustee to the container with appropriate trustee rights.

The choice of trustee rights will depend on the extent of control to be given to the container administrator versus the control to be retained by the original network administrator.

3. Assign any necessary rights to the file system for the container administrator.

4. Make Administrator users occupants of the Organizational Role object.

Although you could use the Security Equivalence property of user objects to create multiple container administrators, this approach is not recommended. If the user object that has the explicit Administrator rights is deleted, all user objects that derive Administrator rights because of security equivalence will loose the administrator rights. In certain situations, such as the exclusive container administrator, this could result in a loss of administrative control over the container and the corresponding tree branch.

NDS Security Guidelines

Only Administrator users who need to manage NDS objects on a regular basis need additional NDS rights. Most ordinary users do not need to create and delete objects or modify their property values. 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 might give users access to private information about users and other objects. In some cases, excessive rights might 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 the 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 the 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 may 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 an explicit trustee assignment to a property or using the selected property IRF.

6. Use caution in assigning the 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 sub-tree.

In decentralized administration, it is common for the container administrator to be the only user to have the Supervisor object right to the container. Others are prevented from having the 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.

The following are additional considerations for assigning rights:

1. When assigning rights to a container administrator, it is preferable to assign all rights explicitly, rather than just assigning the [S] object right. This ensures that the container administrator can still manage the branch if the [S] object right is blocked by an IRF setting at a lower level.

2. Because the IRF can be used to restrict the rights of an Admin user, consider adding the Admin user as an occupant of the administrator Organizational Role (if one is used) for each container. This will enable the Admin user to perform container administration, even if the IRF is used to block the Admin user's rights.

3. Decide if the container administrator will manage the file systems for that container.

If the administrator is to manage the file system, give the administrator effective Supervisor object right to the server object. If the administrator has Supervisor object right to the container, this right will flow down to the server objects in the container (unless blocked by and IRF setting on the server object).

If the administrator is not to manage the file system, revoke from the user the supervisor object right to the server object. This can be done by removing the Supervisor right from the IRF of the server object. Before doing this, give another user Supervisor object right to the server object and hence to the file system.

4. If the tree branch is not yet created, give the container administrator only the Create object right. The container administrator will be given the Supervisor object right to every object he or she creates.

5. Use groups to simplify the assignment of rights.

Use the natural grouping property of containers to assign rights to users in the container.

Use NDS group objects to assign rights to users. Give the NDS group object appropriate rights, and make users who need these specific rights members of the group.

The members of an NDS group object can be from different containers. Such groups objects are sometimes referred to as global groups. If the users are separated from the resources they need by WAN links, consider the implications of accessing the resource over the WAN link.

Exclusive Container Administrator

An exclusive container administrator has Supervisor rights over a specific container only. All rights for other network administrators outside the container are blocked. This approach, which compartmentalizes administration functions on a container basis, is useful in organizations that have need to have strict security.

As figure 10.66 indicates, in this approach, you must block the rights of the original Administrator account CN=Admin.O=ESL. The general procedure for creating a separate Admin account for a department is shown below. The description will be given in terms of creating a separate Administrator for OU=CORP.O=ESL (refer to fig. 10.66). The administrator account for the OU=CORP.O=ESL tree branch will be referred to by the name CN=Admin.OU=CORP.O=ESL. If you need to perform this procedure on your NDS tree, you will probably have different names for the root of the tree branch and the Admin user accounts, and you will have to make appropriate substitutions for these names.

1. Create an Admin account in the Department container. In the case of figure 10.66, this is the user CN=Admin.OU=CORP.O=ESL.

2. Assign to the newly created Admin account the following rights:

Object rights of [S B C D R] to OU=CORP.O=ESL

All Properties rights of [S C R W A] to OU=CORP.O=ESL

3. Revoke rights from the IRF for OU=CORP.O=ESL to block access rights for other network administrators outside the tree branch.

The reason for doing this is to prevent CN=Admin.O=ESL from inheriting access rights to OU=CORP.

You should set the following rights:

IRF for object rights to [B]

IRF for All Properties for OU=CORP to [R]

Keeping the Browse right in the IRF for object rights will allow users to see the objects in the CORP tree branch. The All Properties Read right will allow other network administrators to read the properties of NDS objects in the tree branch, unless an object has a selected property right to override this.

4. Remove any trustee assignments to OU=CORP and any of its subcontainers for the original administrator (CN=Admin.O=ESL).

5. Make sure the new container administrator, CN=Admin.OU=CORP.O=ESL, has Supervisor object rights to himself or herself. Also ensure that no other user such as CN=Admin.O=ESL has rights to CN=Admin.OU=CORP.O=ESL. If another user has access rights to CN=Admin.OU=CORP.O=ESL, he can restrict the right to this user.

6. Make sure that no other user is a security equivalent to the newly created Administrator and that there are no aliases to this User object.

Before revoking the Supervisor object right from the IRF for a container, you must have a user who has Supervisor object right to that container. Otherwise, the system will prevent you from revoking the Supervisor IRF right and you will get an error message that You cannot filter the Supervisor object right because no object has explicit Supervisor object right to this object.

STOP: Before revoking the Supervisor object right from the IRF for a container, you must have a user who has the [S] object right to that container.

The NetWare utilities do not prevent you from deleting the only User object that has Supervisor object rights to the tree branch. You can, therefore, lose control of an NDS tree branch if you inadvertently (or by design) delete the User object that has Supervisor object rights to the NDS tree branch. If you delete the only User object that has Supervisor object rights to the NDS tree branch, you have created a "black hole" in the NDS tree.

If you use an Organizational Role object to create exclusive container administrators, create an explicit trustee assignment for at least one of the container administrator's user objects. This will prevent loss of administrative control over a container in case the Organizational Role object is deleted.

Setting Up Central Administration of Containers (Non-Exclusive Container Administrator)

Because of the risk of losing control over a tree branch by either delegating responsibility to a department administrator or through inadvertent creation of a "black hole" in the NDS tree, you might want to use a central network administration with work-group managers that act as assistant administrators. You must implement security in such a manner so that you can prevent loss of control over a tree branch. You can use the procedure that follows as a guideline. The description will be given in terms of creating an assistant Administrator for OU=CORP.O=ESL (see fig. 10.67). The Administrator account for the OU=CORP.O=ESL tree branch will be referred to by the name CN=WMgr.OU=CORP.O=ESL. If you need to perform this procedure on your NDS tree, you will probably have different names for the root of the tree branch and the Admin user accounts, and you will have to make appropriate substitutions for these names.

1. Create a Workgroup Manager account, CN=WMgr, in the Department container. In the case of figure 10.67, this is the user CN=WMgr.OU=CORP.O=ESL.

2. Assign to the newly created Workgroup Manager account the following rights:

Object rights of [B C D R] to OU=CORP.O=ESL

All Properties rights of [C R W A] to OU=CORP.O=ESL

Selected Property rights of [C R] to Object Trustees (ACL)

Assigning the Selected Property rights of [C R] to the ACL property is important. Otherwise, the Workgroup Manager can inherit the Write property right for the ACL property through the All Properties rights, and this gives the Workgroup Manager the ability to modify the trustees for the CORP container, and even give himself or herself the Supervisor object right to the CORP container.

Figure 10.67 Creating Workrgroup Manager accounts.

3. Make sure that CN=Admin.O=ESL has an explicit Supervisor trustee assignment to manage OU=CORP. You can do this by assigning the following rights to CN=Admin.O=ESL:

Object rights of [S B C D R] to OU=CORP.O=ESL

All Properties rights of [S C R W A] to OU=CORP.O=ESL

4. Make sure that CN=Admin.O=ESL has an explicit Supervisor trustee assignment to CN=WMgr.OU=CORP.O=ESL. This can be done by assigning the following rights for CN=Admin.O=ESL:

Object rights of [S B C D R] to CN=WMgr.OU=CORP.O=ESL

All Properties rights of [S C R W A] to CN=WMgr.OU=CORP.O=ESL

5. Remove rights from IRF for CN=WMgr.OU=CORP.O=ESL to prevent the Workgroup Manager from inheriting excessive management rights. Set the IRF as follows:

IRF for Object rights for CN=WMgr.OU=CORP.O=ESL set to [B]

IRF for All Properties rights for CN=WMgr.OU=CORP.O=ESL set to [C R]

6. Restrict Workgroup Manager CN=WMgr.OU=CORP.O=ESL rights as follows:

Object rights for CN=WMgr.OU=CORP.O=ESL set to [B ]

Selected Property right for CN=WMgr.OU=CORP.O=ESL set to [C R ] for ACL property

Selected Property right for CN=WMgr.OU=CORP.O=ESL set to [R W ] for Login Script property

Selected Property right for CN=WMgr.OU=CORP.O=ESL set to [R W ] for Print Job Configuration property

Danger of Giving a Workgroup Manager Write Property Right to the ACL of a Container

A common problem in setting up a workgroup manager who acts as an assistant Administrator is the failure to revoke Write property rights from the ACL property of the container.

Consider a workgroup manager CN=WMgr.OU=CORP.O=ESL who has been given the following rights to manage the OU=CORP.O=ESL tree branch. Object rights of [B C D R] to OU=CORP.O=ESL All Properties rights of [C R W A] to OU=CORP.O=ESL The [B C D R] object rights and [C R W A] All Properties rights are assigned for WMgr.CORP.ESL. Because the [C R W A] All Properties implies that the user WMgr.CORP.ESL has Write property right to the OU=CORP.O=ESL container's ACL property, the user WMgr.CORP.ESL can modify this ACL property.

A possible scenario is that the WMgr.CORP.ESL has acquired Supervisor object rights, by selecting the "Trustees of this Object" for the CORP container, using the NetWare Administrator, and adding explicit rights to himself or herself.

To prevent this scenario, you should explicitly assign to the Workgroup Manager the Selected Property right of [C R] to the ACL property for the container.

Types of Administrative Accounts

The Admin account that is created for the Directory tree should be retained, even if you decide not to use central administration. This account is needed for centralized operations such as partition management, NDS backups, and restructuring of the top-level of the NDS tree. You don't have to call the Administrator account for the NDS tree Admin; it can be renamed to any other valid user name.

Because users can be assigned different rights at each level of the NDS tree, NetWare 4 administration gives you extreme flexibility in setting up an administrative structure to suit your organization. Table 10.6 shows some sample network administrative roles, recommended by Novell. This table also shows the rights assignments required for the administrative role.

TABLE 10.6 Example Administrative Roles

Role Recommended Account Rights Functions Performed by Administrator
Enterprise NDS Administrator Admin user object such as the default Admin object [S] object right to [Root] during initial installation Install the first server and name the NDS tree.
Create top-level of the NDS tree. Manage partitioning, replication, and time synchronization. Assign container administrators. Upgrade servers, clients and applications. Enable auditing and issuing initial auditor password.
Container Administrator User object assigned rights to container or occupant of an Organizational Role object [SBCDR] object rights to appropriate container Perform backup and restore operations. Create and configure print services for the container. Upgrade server, client and application software for users in containers. Monitor file system performance. Install NDS objects in container. Monitor server performance. Write and maintain login scripts. Monitor disk space usage, assign file system trustees. Track errors.
Print Server Operator PS operator user; Organizational Role whose occupants are users who are print server operators Add to Print Server Operator property of print server Load and bring down the print server.
Print Queue Operator PQ operator user; Organizational Role whose occupants areusers who are print queue operators Add to Print Queue Operator property of print queue Manage print jobs in queue(delete, change order, hold/resume print jobs). Change queue status.

Objects with Special Rights Assignments

The following objects access specific network resources and might require additional rights:

  • Profile login script

  • Directory map

  • Alias of User object

  • Mailing list administrator

The following sections describe these special objects and explain how to assign them special rights.

Special Rights for Profile Login Script Object

The profile object contains the profile login script. User objects have a property called Profile that can be set to point to a Profile object. The Profile login script is a way of implementing a common login script that is shared by any user who has her Profile property pointing to the same profile object. The profile login script is executed after the system login script (if one exists) but before the user's login script (if one exists). The system login script is the login script for the user's container. If the user's login script does not exist, and the NO_DEFAULT directive has not been specified in the system or profile login script, the default login script is run.

The following simple exercise demonstrates the rights needed to run a profile login script.

1. Create a container O=IBL, and a User object James in that container.

2. Create the Profile object CProf in O=IBL and examine its default trustees.

You will notice that the Profile object CN=CProf.O=IBL does not have any default trustees.

3. In the profile login script for the profile object CN=CProf.O=IBL, place the following login script statement:

WRITE "Profile login script for CProf is executed"

4. Set the Profile property for the user to point to the CN=CProf.O=IBL object.

Starting with NetWare 4.1, if you have not assigned to the user the Read property right to the Profile object's login script property, you will see a message informing you of this. Save the assignment to the Profile object, but for the time being do not assign any additional trustees to the Profile object.

5. Log in as the user CN=James.O=IBL.

You will notice that the profile login script for the user James is not executed. The reason for this is that user James does not have [R] property right to the Profile object's Login Script property.

6. Log in as Admin.

Make user CN=James.O=IBL a trustee of CN=CProf.O=IBL with the [R] Selected Property rights to the Login Script property.

7. Log in as the user CN=James.O=IBL, again.

You will notice that the profile login script for the user James is executed. The reason for this is that user James now has [R] property right to the Profile object's Login Script property.

When a Profile object is created, it does not have any default trustees. A user whose Profile property is set to a Profile object must be able to read the profile login script in order to execute it. This means that the user must have the Read property right to the Profile object's Login Script property.

NOTE: The Novell documentation says that if the User and the Profile object are in the same container, no additional rights to the Profile object are needed. If the container in which the profile login script was created is made a trustee of the Profile object and given the Read property right to its login script, this would be true. As the exercise above indicates, this is not true for NetWare 4.x, and a user must have the Read property right to the profile login script, even if the User and the Profile object are in the same container.

NOTE: When a Profile object is created, it does not have any default trustees. To execute the profile login script, you must have the [R] property right to the Profile object's Login Script property.

The following steps are needed to set up profile login script for a user.

1. Create the Profile object and set its profile login script.

2. Set the Profile property of a user to point to the Profile object.

3. Assign to the user the [R] property right to the Profile object's Login Script property.

If all users are in the same container, you can assign the container a trustee of the Profile object and give it the [R] property right to the Profile object's Login Script property.

Typically, users who share a profile login script are in different containers. If they are in the same container, using the system login script for that container is usually sufficient. If the users are members of a Group object or an Organizational Role object, you can make the Group object or Organizational Role object a trustee of the Profile object. Alternatively, you might want to individually assign users trustees of the Profile object.

Special Rights for Directory Map Object

The Directory Map object is used for simplifying the use of the MAP command and for making the MAP command independent of changes to the location of the directory being mapped to. To use the Directory Map object, you must have the Read All Properties right to the Directory Map object. When a Directory Map object is first created, it does not have any default trustee assignment. You must explicitly assign the [R] All Properties right to the Directory Map object.

The following shows an attempt to map to a Directory Map object (CN=DirMap.O=ESL) by a user who does not have the Read All Properties right to the Directory Map object.

F:\>MAP G: = .CN=DirMap.O=ESL MAP-4.12-195: Directory [CN=DIRMAP.O=ESL] cannot be located.

If the user is assigned the [R] All Properties right to the CN=DirMap.O=ESL, the above command works correctly as shown:

F:\>MAP G: = .CN=DirMap.O=ESL Drive G: = NW4KS_SYS.CORP: \DOC

In the previous example, the Directory Map object, CN=DirMap.O=ESL, was set to point to the NW4KS_SYS:DOC directory. The user should have at least [R F] file system rights to the directory being pointed to for the MAP command to work.

NOTE: When a Directory Map object is first created, it does not have any default trustee assignment. Before you can use the Directory Map object, you must assign the [R] All Properties right to the Directory Map object. Note that the [R] property right also implies the [C] property right.

NOTE: You might want to make the container in which the Directory Map object is defined a trustee to the Directory Map object and give to the container the [R] All Properties right. This will give all users in the container the [R] All Properties right to the Directory Map object and allow them to use it.

The Directory Map object has a property called Rights to Files and Directories. Assigning rights to a file system via this property does not cause these rights to be inherited by the users mapping to the Directory Map object.

Special Rights for Alias User Objects

To understand the rights needed by alias users to execute their login scripts, consider the situation in figure 10.68 that shows an NDS tree for organizations IBL and UNE.

Organization IBL has a user James defined in the container O=IBL, and organization UNE has an Alias object Bond that is an alias to CN=James.O=IBL. The user

Figure 10.68 Alias user object and login scripts.

CN=Bond.O=UNE is the alias user, and the user CN=James.O=IBL is called the aliased user. The O=IBL has a system login script set that has the following login script statements:

WRITE "Executing login script for container IBL"

User CN=James.O=IBL has his Profile property set to the Profile object CN=CProf.O=IBL. The profile login script has the following login statement:

WRITE "Executing profile login script CProf"

User CN=James.O=IBL has the following statements in his user login script:

WRITE "Executing login script for user James"

Additionally, user CN=James.O=IBL is a trustee of the Profile object CN=CProf.O=IBL and has the [R] property right to the Profile object's Login Script property. Because Bond is an alias to user James, Bond is automatically a trustee of CN=CProf.O=IBL with the same rights. The NetWare Administrator will not allow you to add the alias and the aliased user as trustees of the same object (try it to verify this for your NetWare 4.x server).

If you log in as user CN=James.O=IBL, you will see messages similar to the following:

Executing login script for container IBL Executing profile login script CProf Executing login script for user James

If you log in as the alias user CN=Bond.O=UNE, you will see messages similar to the following:

Executing profile login script CProf Executing login script for user James

Notice that the login script for the O=IBL container is not executed for the user CN=Bond.O=UNE. When an alias user logs in, NetWare runs the container login script for the container the alias user is in and not the container login script for the aliased user.

If you create a system login script for container O=UNE, and place in it the statement:

WRITE "Executing login script for container UNE"

Then log in as the alias user CN=Bond.O=UNE. You will see messages similar to the following:

Executing profile login script CProf Executing login script for user James

Notice that the login script for the O=UNE container is not executed for the user CN=Bond.O=UNE, even though it has been set. For an alias user to execute the login script of the container it is defined in, the alias user must be granted the [R] property right to the Login Script property of its container. If this is done, logging in as alias user CN=Bond.O=UNE will produce messages similar to the following, showing that the alias user's container login script is executed.

Executing login script for container UNE Executing profile login script CProf Executing login script for user James

NOTE: It might seem a little strange that the alias user needs to be granted an explicit trustee assignment to the Login Script property of the container, especially because the container is made a trustee of itself and given the [R] Selected Property right to its Login Script property.

The reason for assigning the alias user an explicit trustee assignment to the Login Script property of the container is because the alias user is really a "phantom" user whose true existence is in the container that holds the aliased user, even though the alias user does not execute the system login script of the aliased user. The aliased user needs to have [R] property right to the alias' container's Login Script property.

If you assign the alias user the [R] property right to its container and then go back to reexamine the trustee assignments of the alias's container, you will see that the aliased user is listed as a trustee, even though you initially made the alias user a trustee of the container.

The alias user does not execute the system login script of the aliased user. It executes the login script of the container in which it is defined.
For the alias user to execute the login script of the container it is defined in, the alias user must be granted the [R] property right to the Login Script property of its container.

Special Rights for Mailing List Administrator

One of the properties of User objects, Organizational Role objects, Organizational Unit objects, and Organization objects is the e-mail Address property. This property can be used to enter the electronic mail address for the object. The actual value of the e-mail address will depend on the type of e-mail system that is being used.

Some organizations prefer to delegate the responsibility of maintaining properties such as e-mail Address, Telephone Number, FAX Number, and postal address to a special user called the Mailing List Administrator. The Mailing List Administrator should be able to modify these properties and should therefore have Read and Write property rights to the properties they will manage. The Mailing List Administrator account can be implemented as a User object. If a more formal designation is needed for the Mailing List Administrator, it can also be implemented as an Organizational Role object.

NOTE: The Mailing List Administrator should have the [R W] property rights for the following properties that the Mailing List Administrator will manage:

E-mail Address

Telephone Number

FAX Number

Postal address:

Street

City

State or Province

Postal (ZIP) code

Postal Office Box properties

The trustee rights assigned to the Mailing List Administrator must be assigned for each NDS object the Mailing Administrator will manage. For a large organization, this can become a very laborious process. You might be tempted to give to the Mailing List Administrator rights for the users they will manage through a Group object or a Container object, but you will end up giving the Mailing Administrator more rights than he or she should have. Also, assigning the All Properties rights to the Mailing List Administrator would also give the Mailing List Administrator the Write property right for the ACL property. If the Mailing List Administrator has the Write property to the ACL of an object, the Mailing List Administrator can modify the trustee assignments to the object.

Rights for Traveling Users

You must pay special attention to the NDS rights of traveling users who access their network from remote locations. The following discussion is based on Novell's classifications of traveling users:

  • Users who divide their work time between home and office

  • Users who need access from a temporary location while they are working on special projects

  • Users who spend a considerable amount of their work time traveling and need access to the network regularly from remote locations

For each type of user you should consider the following issues:

  • Access to files on server volumes

  • Access to applications

  • Access to files from several remote locations

  • Access to resources such as printers and e-mail accounts

  • Authenticating to NDS and NDS objects

  • Number of traveling users

  • Type of computer used by traveling users (portable versus desktop)

Users Who Travel between Two Offices

The users who divide their time between two work locations need access to similar resources in both locations. This is especially true if they do the same type of work at each location. Novell recommends the following as one of the ways of handling this situation:

  • Create two user objects, one in each location

  • Give required rights to each user for the resources needed at each location

  • Give necessary rights to profile login script and Directory Map objects

Users on Location Temporarily or Users Who Travel to Many Remote Locations

The users who are at a location temporarily or those who travel on a regular basis to many remote locations need access to appropriate files, directories, printers, and applications. Novell recommends the following as one of the ways of handling this situation:

  • Create an alias user object, or assign the user to a Group or Organizational Role object.

  • Give required rights to Alias, Group, or Organizational Role objects for network directories and resources.

  • Give necessary rights to Alias, Group, or Organizational Role objects to read any Profile Login Script and Directory Map objects.

  • When creating aliases, make the original user object a trustee to the alias' container and grant the user Read property rights to the container's login script property.

Guidelines for Determining Excessive Rights

Occasionally you might discover that a user or group of users has excessive rights. Excessive rights are any rights that are above and beyond those required by users to complete their tasks. Excessive rights can also give users the ability to acquire additional rights or restrict rights of other users. To correct the problem of excessive rights, you must be able to trace the origin of these rights. In a NetWare 4 environment, this can be particularly challenging because of the many levels of NetWare security and the large number of sources from which rights can be acquired. The following is a guideline for determining excessive rights:

1. Determine the explicit rights granted to the following objects:
a. User objects

b. Group and Organizational Role objects

c. Containers between the user and the [Root]

d. Security Equivalencies

e. Rights granted to the [Public] and the [Root] trustee.

2. Rights inherited through explicit trustee assignments to any of the objects listed in the previous item. Also, determine the rights inherited through group membership, container membership, or security equivalence.

3. Use the NetWare tools to determine trustee assignments and effective rights.

For NDS rights, you can use NETADMIN or NetWare Administrator (NWADMIN).

Use the following as an outline to determine the NDS Effective Rights using NWADMIN.

1. Right-click on the resource you want to check.

2. Select Trustees of this Object.

3. Select Effective Rights button.

4. Select the Browse button, locate the user object, and click on OK.

5. You should see the Effective Rights for the user.

For File System rights, you can use NWADMIN, NETADMIN, FILER, or the RIGHTS command.

Use the following as an outline to determine the file system effective rights using NWADMIN.

1. Double click on the volume object to see the directory tree structure underneath it.

2. Right-click on the directory you want to check.

3. Select Trustees of this Object.

4. Select the Effective Rights button.

5. Select the Browse button, locate the user object, and click on OK.

6. You should see the effective rights for the user.

Guidelines for Determining the Cause of Insufficient Rights

This is the opposite of the problem discussed in the previous section. Occasionally you might run into a situation where a user does not have sufficient rights to perform a task or has just lost those rights because of changes made to the NDS. In this case, you must consider the following:

1. Check to see if any explicit rights the user is supposed to have have been granted. Check to see if any IRFs are blocking the user's rights. If they are, you can set the IRF to pass the desired rights or make an explicit trustee assignment.

2. Check to see if the user is a member of the Group or Organizational Role objects that have been assigned the rights needed by the user.

3. If the user was given rights through security equivalence, check the user's security equivalence property to see if the security equivalencies exist. Also, check to see if the user still exists. This is the risk when making one user a security equivalent to another user.

4. Check the rights of the container through which the user inherits the rights. If a reorganization of the NDS tree has taken place, certain rights might not have been properly assigned to Container objects.

NetWare File System Security

NetWare 4.x file system security is very similar to NetWare 3.x file system security. A detailed discussion of file system security is beyond the scope of this book, but in this section I will point out some of the major differences between NetWare 3.x and NetWare 4.x. For details on NetWare 3.x File System Rights, refer to NetWare: The Professional Reference.

When a user object is created, no automatic file system rights are created, except to the user's home directory if one was specified at the time of creation. Figure 10.69 shows the rights of 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.

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.

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.

Figure 10.69 Right of user KSS in home directory.

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 NetWare 3.x and NetWare 4.x file systems is the scope of the trustee. In NetWare 3.x, the trustee could only be 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 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 a file or directory, all objects within it (including, of course, user and group objects), inherit the trustee rights to the file or directory.

TIP: It is simpler to assign file/directory rights using a container object if the NDS container and 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 is also 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 should be a consideration in setting up security rights.

The Write property right can be granted with these steps:

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 above.

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 additionally, the rights listed in table 10.7.

TABLE 10.7 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 if 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 Specified file or files in a directory are marked 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 and 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.

NOTE: The attributes Migrate (M), Compress (Co), and Can't Compress (Cc) are status attributes and indicate the status of individual files only; the 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 the INSTALL.NLM and requires a near-line storage medium 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.

When your network is running, you'll want to set up the security arrangements that will govern the users' access to network resources.

In this chapter, you learned about NetWare 4.x security. NetWare security is layered. The first layer is Login security. The second layer is NDS security. The last (third) layer is NetWare File System security.

You were presented with a detailed explanation of Login Authentication. Certain mathematical equations were presented to show you how authentication works. Most of the chapter was spent on NDS security issues because this is a new area for NetWare 3.x administrators. A number of case studies were presented to help you understand how NDS security works.




© Copyright, Macmillan Computer Publishing. All rights reserved.


Previous page
Table of content
Next page
Migrating to NetWare 4.1
Migrating to Netware 4.1
ISBN: 1562055232
EAN: 2147483647
Year: 1995
Pages: 22
Authors: Karanjit Siyan
BUY ON AMAZON
MySQL Stored Procedure Programming
Introducing Microsoft Office InfoPath 2003 (Bpg-Other)
SQL Hacks
Programming Microsoft ASP.NET 3.5
After Effects and Photoshop: Animation and Production Effects for DV and Film, Second Edition
DNS & BIND Cookbook
flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net
Privacy policy