NetWare 5.1 Administration

Chapter 7: Managing NDS Security

 

Objectives:

This chapter discusses rights again, but this time NDS rights, not file system rights. The objectives important to this chapter are listed on page 7-1:

1. Define NDS Security
2. Identify How NDS Security Differs from File System Security
3. Control Access to NDS Objects
4. Determine Rights Granted to NDS Objects
5. Block Inherited Rights
6. Determine Effective Rights
7. Troubleshoot NDS Security Problems

Key Concepts:

Define NDS Security

The good part about this chapter is that some of it will be familiar if you understand Chapter 5. The bad part is that it is similar enough to be confusing where it is different. The text begins with the similarities:

• Trustees to NDS objects are created as we created trustees to parts of the file system
• Users are granted rights to NDS objects, but not the same rights as in the file system
• Inheritance is present in the system of NDS rights
• Inherited Rights Filters are more powerful in NDS, in that they can block the NDS Supervisor rights (there are two, here)
• Effective rights must be calculated, like those in the file system

You must understand that NDS and the file system are two separate systems. This chapter about NDS rights should nail that down for you. The text makes the point that one person in a company may be made the administrator of the file system and another the administrator of NDS. This is extreme, but possible.

Identify How NDS Security Differs from File System Security

On page 7-3, you see a set of bulleted items emphasizing differences between NDS and the file system. Note that:

• There are two kinds of NDS rights: object rights and property rights
• Rights in NDS do not flow into the file system (except for one back door)
• As noted above, the NDS Supervisor rights (yes, both of them) can be blocked by IRFs

More on the back door later. (There must be some mysteries in these notes.)

Control Access to NDS Objects

NDS objects can become trustees of other NDS objects (and even trustees of themselves) by being placed on the other object's Trustee List. The Trustee List is actually called the ACL: the Access Control List. A view of an object's ACL is presented on page 7-5. Unfortunately, the picture is a view from ConsoleOne, so nothing is visible except the Trustees themselves. (In NetWare Administrator, you can see the lists of rights more easily. Rights that are "grayed out" are not active. Object rights are shown on the left side of the screen, and Property rights on the right side.)

You can grant rights to users and other objects by granting rights to the containers that they are placed in. A list of objects that can become Object Trustees is on page 7-6. Note that these are the objects that relate to users, and that all except the User object allow you to assign rights to multiple users simultaneously.

• User objects - these stand for users
• Group objects - these contain lists of users
• Organizational Roles - these contain specific users
• Containers - User (and other objects) exist in containers and inherit rights from them
• [Root] - all objects in the Tree descend from the [Root]. Rights granted to it are inherited by all authenticated users.
• [Public] trustee - everything on the network is in this group, authenticated or not.

There are six object rights, relating to what a user may or may not do to or with an object. The rights are explained on page 7-9:

• Supervisor - includes the other OBJECT rights, like the Supervisor right in the file system, but this one can be blocked with an NDS IRF
• Browse - the right to see an object in an NDS tree, otherwise it is hidden from the user
• Create - only applies to container objects, it means the user can create new objects in it
• Delete - the right to delete an object from the NDS tree
• Rename - the right to change an object's name, like the Modify right in the file system
• Inheritable - applies only to container objects; turned on, it allows rights to a container to apply to objects in the container. By default, this right is turned on. The new idea is that it can be turned off for a user, creating something like an IRF that applies to that user only.

In another class, we decided a good acronym to remember them was C-BRDS ("sea-birds"). In NetWare 4.11, there was no Inheritable right. In NetWare 5 and 5.1, there is, so the mnemonic is now C-BIRDS.

Just to allow a bit more confusion, the text explains that objects are records in the NDS database. A record can be called an entry, in some database terminologies. A record of this sort can also be called an entry object. So, this is the justification for calling object rights by another term: entry rights. They are called this in ConsoleOne.

The six property rights are more specific. These are rights to the information stored in the NDS properties of an object.

• Supervisor - yes, Virginia, there is another Supervisor right. This one is equivalent to the total of the other PROPERTY rights. It is an NDS right, and can be blocked by an NDS IRF.
• Compare - the ability to compare the value of a property to another value. You can know whether the two values match, but you may not "read" the property value. Think of logging in: the system allows you to compare a password you type to the value of the password property of a User object. It does not allow you to read the value of that property.
• Read - this is the right to read, to know the value of a property. If you can do this, you have more than the Compare right.
• Write - the ability to change the value of a property, and it is more than the Add Self right
• Add Self - the ability to add or erase oneself as the value of a property. Pretty limited, but it gives you a way to set up a back door into the system.
• Inheritable - new with NetWare 5, applies only to container objects; when this is turned on, the rights you have to a container's properties are also rights to the properties of the objects in the container. This is granted by default for All Property rights, not granted by default for Selected Property rights. (These are defined below. Patience...)

In another class, we tried for a good acronym to remember them, and got SCRAW (what the "seabirds" call) and C-WARS. Of course, we need the I as well. I-SCRAW or IC-WARS?

Note that the Compare right is like the Read right, but much less powerful. The Add Self right is like the Write right, but less powerful.

Now hang on, because it is about to get rough.

Property rights may be assigned to a trustee in two different ways. A trustee could be given the Read and Write rights to All Properties of a specific object. That is, this trustee has those two rights for each and every property of the specified object.

The other way is to grant specific rights to Selected Properties of an object. We could click the Selected Properties button in NetWare Administrator, and proceed to assign rights for this trustee to each individual property of the object. It would be very time consuming to grant all rights this way, so you can do both. You may first grant the general rights you want the trustee to have to All Properties, then assign different rights to specific properties with the Selected Properties method. Rights that are assigned with the Selected Properties method overwrite (replace) rights for that property that were put in place from an All Properties assignment.

Take a deep breath and think about it. Then read the the section above again.

Now about that back door, I promised you: if a user has the Supervisor object right to an NDS file server object, the user will automatically have Supervisor file system rights to the file system on that file server. In other words, if you have "sea birds" to the file server, you get "worm faces" on it, too. (Think about all the sea gulls that hang around McDonalds. Of course, McDonalds doesn't really put worms in the food. That is only an Urban Legend.)

Determine Rights Granted to NDS Objects

Inheritance is illustrated on page 7-14. The user Admin is assigned all object rights (SBCDRI) to the EMA container. She inherits those rights in the NYC container, which is the child of the EMA container, and the Corp container, which is the child of the NYC container. The FS1 server is a leaf of the Corp container, so she gets all rights that apply, namely all but C and I. These are NDS rights, and the server is a leaf, therefore since she cannot logically create anything in a leaf. It is impossible to have the NDS object Create right or Inheritable right for a leaf.

Inheritance has a trick to it:

• you can inherit NDS Object rights, by default
• and you can inherit NDS All Property rights, by default
• but you can only inherit Selected Property rights if the Inheritable right is specifically turned on. (Breathe in, breathe out. Very important.)

Block Inherited Rights

Inherited rights can be changed by a new trustee assignment at a lower level. This is like the inherited rights in the file system. Inherited Rights Filters work like the file system, except that they are more powerful, and can block the Supervisor object and property rights. NDS IRFs can be used to block object rights and property rights.

Determine Effective Rights

Effective rights exist here, too. A handy guide is on page 7-20. Note the qualified way it is worded. It is an additive process, sometimes.

• the user can be assigned rights to the object as a Trustee - an IRF will not affect this. None of the rights described below are affected by an IRF, if the rights are granted through a Trustee assignment to the object in question. For example, if I create an IRF to a container and block all rights to it, the IRF does not affect your rights to the container if I specifically made you a Trustee of the container.
• the user may get rights through a Group or Organizational role - an IRF can affect this
• the user may have equivalent rights to someone else - the object's IRF can affect this
• rights flow to a user from Containers - an IRF can affect this
• since [Root] is a container, and everything is in [Root], rights flow from it to all users - an IRF can affect this
• the user is a member of the [Public] trustee, and gets rights - an IRF can affect this

In NetWare Administrator, you can determine a user's effective rights from the User object by accessing the User's Rights to Other Objects. You can also determine rights from the object you wish to know if the user has rights to, by accessing its Trustees. You should practice both methods.

In ConsoleOne, the procedure is similar. To determine what objects are Trustees of a User, right-click the User object, then select Trustees of this Object. If you want to see the effective rights an object has, right-click the object, then click the sequence Properties | NDS Rights | Effective Rights.

Troubleshoot NDS Security Problems

The discussion of security begins on page 7-30. The purpose of assigning rights, as always, is to give the users access to what they need, and to deny access to what they should not have. Administrators need more rights than ordinary users.

Users will automatically have the Browse object right to other objects in the NDS tree, because the [Public] trustee has it.

A previous edition of the text offered a chart of guidelines for managing Object and Property rights. It is worth considering that advice:

1. Start with the default assignments. This means to consider whether the defaults are actually enough rights for a user. They exist because they are often correct.
2. Avoid using All Properties assignments. Their point is valid, that All Properties assignments can lead to security breaches.
3. Use Selected Properties assignments. By assigning only those rights that are necessary, and assigning them specifically, you avoid any unintentional granting of rights.
4. The Write right to the ACL property of an object is dangerous. A user who can write to this property can assign, add, or delete trustees of the object, and change their rights. What more do you need to get any other right you want?
5. Grant the Supervisor object right carefully. This item contains the two back doors for this chapter: a user who has the Supervisor object right to a server gets the Supervisor (file system) right to all volumes on that server. Also, a user who can write to the ACL of the server can give the Supervisor object right to anyone.
6. If you grant the Supervisor object right to an object, this implies granting the Supervisor right to All Properties of that object.
7. Be careful blocking Supervisor rights with IRFs. You can end up with no one capable of administering a container, or other objects. To paraphrase an old theological question: If the Administrator is all powerful, can he create a container so secure that he himself cannot administer it? Yes. By using an IRF, the Administrator can block all inherited rights to a container, therefore he would lose all rights to it unless he ALREADY had rights that were not inherited. After the IRF is in place, it is too late to grant specific trustee rights. If no one already has them, who will grant them?

On pages 7-30 through 7-32, we are given procedures for checking why a user does or does not have certain rights. This is used when someone has too many or too few rights, and we must change the situation.

The more common situation is that a user has too many rights, so the procedure on page 7-31 addresses that problem. The procedure on page 7-32 is for discovering why a user does not have the rights he or she needs.

Both procedures involve checking the rights assigned to user via the various containers, groups, etc. that they may belong to. The second procedure adds the ideas of checking for IRFs. With regard to IRFs, remember that a user might be assigned rights to a container, but those rights do not flow to the container's contents if the Inheritable aspect of those rights is turned off. This is like an IRF that is personal to that user.