NetWare 5.1 Administration

Chapter 8: Securing the NDS Tree

 

Objectives:

This chapter adds to your knowledge of the rights assigned to NetWare 5.1 objects by default and by intention. The objectives important to this chapter are on page 8-1:

  1. List and Explain NDS Default Rights
  2. List and Explain Guidelines for Implementing NDS Security
  3. Compare Centralized and Distributed Administration
  4. Determine Administrative Roles and Rights Assignments
Key Concepts:
List and Explain NDS Default Rights

NDS security means NDS rights. When certain actions are taken, objects are created and they are assigned default rights. You should know about all of them.

Page 8-2 lists four actions that will cause default rights to be assigned to objects:

  • Creating the Tree
  • Creating a container
  • Installing a server
  • Creating a user

When NDS itself is installed (during NetWare installation), two objects and a trustee are created automatically. (See page 8-3.)

  • The [Root] object is created.
  • The Admin object is created, and given the Supervisor and Inheritable object rights to [Root]. This allows Admin to supervise all objects by default.
  • The [Public] trustee is created, and given the Browse and Inheritable object rights to [Root]. This allows all objects to see the Tree and the objects in the Tree.

Next, when you create a container it is given two property rights to its own properties. The rights of the container flow down hill to the Users in it, so this means that any User in that container will also have these rights. (See page 8-4.)

  • A container, and its Users, are given the Read property right to the container's login script. This allows the Users in a container to read (and execute) the login script.
  • A container, and its Users, are given the Read property right to the container's print job configuration property. This means that all Users in the container can print the same way, using those configurations.

Now, for servers (See page 8-5.):

  • the person who creates a server (the system knows who is logged in) is given the Supervisor object right to it. This makes that person the administrator of the server. This also means that that person is also given the Supervisor file system right to any volumes on that server. A powerful position to be in.
  • the server itself is given the Supervisor object right to it.
  • the [Public] trustee (and, therefore, everyone) is given the Read property right to the Messaging server property of the server. This allows anyone on the network to communicate with the server, for requesting services.

Users' rights are more complex (See pages 8-6 and 8-7.):

  • [Root] is granted the Read property right to the User's Network Address property and Group Membership property. This will allow anything on the net to recognize who the user is and what groups they belong to.
  • The [Public] trustee is given the Read property right to User's Default Server property. Anything on the net can read this, to help the user log in.
  • The User is given the Read right to All Properties for itself. This lets the users read all data about themselves.
  • The User is given Read and Write property rights to its Login Script property. This allows the users to run and to change their personal login scripts. You may want to remove the Write ability.
  • The User is given Read and Write property rights to its Print Job Configuration property. This allows the users to create and send print jobs.
List and Explain Guidelines for Implementing NDS Security

On page 8-8, the text begins the discussion of guidelines for this chapter. Note the three reasons for granting rights:

  • to allow access to resources - the reason for the network
  • to allow someone to manage NDS objects - do not forget this one, else you get objects no one can administer
  • to provide administrative security measures

Each reason is explored here. Two special cases are noted in which a user of an object needs special rights (page 8-8):

  • to use a Directory Map object, give the user the Read property right to the Path property (or to All Properties) of the DMO.
  • to use a Profile Login Script, give the user the Read property right to the Login Script property of the Profile object

Regarding the assignment of rights for management purposes (pages 8-9 and 8-10):

  1. Test whether the default rights are enough. If so, don't grant more.
  2. Don't assign rights through All Properties - this is a breach of privacy.
  3. Do assign rights through Selected Properties - usually this is more precise and secure.
  4. Only assign Write permission to the ACL of an object when necessary. This is the Trustee list of an object. Someone who can write to it can make anyone a supervisor of it.
  5. Grant rights to Server carefully. This is a back door to the file system.
  6. If you give someone the Supervisor right to an object, you are giving them the Supervisor right to All Properties of that object. To limit this, grant that person CBDR object rights and other property rights as required.
  7. An object IRF that blocks Supervisor rights could keep you from administering an object below it in the Tree. Don't delete the only person who is a supervisor of a container!
  8. If a user has rights to a container, removing the Inheritable object right to that container (which is assigned by default) keeps a user from inheriting his container rights with respect to the objects in the container.

Page 8-11 discusses assignment of rights for administrative security reasons:

  1. Assign all object and property rights to administrative users, not just supervisor rights, since supervisor rights can be blocked.
  2. Use a different name, other than "admin" for your administrative login. This makes it harder for a hacker to guess which user has administrator privileges.
  3. Do not make users "security equivalent" to administrators. This method of granting rights is subject to failure if the original administrator is removed from the Tree.
  4. Change the administrators' passwords regularly. A hacker who gets access to an expired password is not helped, so change them often.
Compare Centralized and Distributed Administration

The concept of Centralized or Distributed administration of a Tree begins on page 8-12. It shows how Management Guideline Seven above is more important than you may think. Essentially, Centralized Administration means that one person, or a few people, can be responsible for the entire network. This means a lot of work for a few people if the network is very large. Distributed Administration means having several subordinate administrators, each with the rights necessary to do what they need to do in their assigned areas (usually containers).

On page 8-13, there is a list of tasks that should be assigned to a Central administrator:

  • Naming (or renaming) the Directory Tree - this is done once, not by each administrator
  • Creating the top levels of the Tree - this is a planning step, not done piecemeal
  • Managing creation and maintenance of partitions and replicas - discussed in depth in the Design class
  • Managing time synchronization - the components of the system need to agree on the time to know when changes to information take place, so that multiple changes can be reconciled
  • Assigning container administrators - someone must be in charge, so the Central administrator should do it

On page 8-14, there is a list of tasks to assign to the Distributed (Container) administrators:

  • Creating user accounts - this administrator is closer to the users
  • Managing user passwords - this is best done by someone closer to the users
  • Managing Print Services - the needs of the user are addressed here
  • Backing up and Restoring data - this breaks the task into smaller tapes
  • Managing File System Security - assigning rights to the users you serve
  • Installing additional servers - this will give the Container administrator the necessary rights to the server and the server's file system
  • Creating workgroup managers - this allows the container administrator to delegate tasks

Some rules for assigning rights to Container administrators are on pages 8-14 and 8-15:

  • If one person administers a container, assign rights to their user object.
  • If more than one person administers a container, assign rights to an Organizational Role and make them occupants of it (this is like being a member of a list). Assign rights to one of them (via their user object) as well, as a precaution.
  • Make sure that at least two trustees can administer a container, for fault tolerance.

Some further guidelines are listed on page 8-16. The idea is to create an Organizational Role object, assign it the necessary rights, and to assign the necessary users as occupants of the role. The question of what rights to assign is best answered by what rights are needed, especially if the container administrator is intended to get by IRFs or to be controlled by them. For instance, an administrator who is assigned the BCDRI rights to a container will not have the Supervisor right to the server in the container, and hence, will not have Supervisor rights to the File System on the server.

This issue becomes more complicated on page 8-18 with the idea of an Exclusive Container Administrator. This would be a person who is the only person meant to administer a container, to the exclusion of the Central administrator. This could happen for security reasons, if the container has financial or sensitive data in it. The danger is that if there is only one person who can manage a container, we are in trouble if their User object is deleted, if they quit, if they never come back to work, etc. The procedure for creating an Exclusive administrator is on page 8-19. DO NOT follow this procedure without putting a back door in place. The back door may be removed AFTER testing shows that your system is secure and manageable.

Determine Administrative Roles and Rights Assignments

Some terms relating to administration concepts are on pages 8-20 and 8-21. Note that the term Enterprise NDS Administrator means the highest Central administrator. The duties of this person are in the first note on page 8-20. They include duties noted above and the following:

  • partitioning the Tree
  • issuing the initial auditor password.
  • upgrading servers, clients, and applications.

On page 8-23, we have a chart of rights assignments for one user and five organizational roles:

  • Admin - this is the Enterprise administrator, and it is given S and I object rights to [Root] when NetWare is installed. This is the only default assignment on this chart.
  • Container administrator - should usually be granted SBCDRI object rights to the container.
  • Password Manager - should be granted RWI property rights to the Password Management property of a container
  • Print Server Operator - must be added to the list of operators on the Print Server object
  • Print Queue Operator - must be added to the list of operators on the Print Queue object
  • Print Job Operator - must be added to the NDPS Job Configurations property of an NDPS printer

Another list of guidelines appears on page 8-24:

  • Since object and property rights can be blocked, you may want to assign more rights to a Container administrator than the S object right. If S and I (and only S and I) are blocked at a lower level, the Container administrator may still be able to manage the lower level.
  • To avoid being blocked by an IRF, you may want to make Admin a trustee of lower containers, with the S object right to the container.
  • If a Container administrator is to manage the container's file system, give them the S object right to the servers in the container.
  • If a Container administrator is NOT to manage the container's file system, don't assign the S object right to the server to that administrator, block it at the server with an IRF, and make explicit File System rights assignments to someone who will administer it.
  • In the special case of an empty container, if the Container administrator is going to fill it, you only need to assign that person the Create right to the container. They will automatically get Supervisor and Inheritable rights to every object they create.