By Justin Whitlock

With a NetWare installation, no one system is responsible for security. But arguably the two most important security safeguards are Novell Directory Services (NDS) and file system security. NDS security controls access to the NDS directory. File system security controls access to files on a NetWare server. These two separate systems are governed by distinct sets of rights:

  • NDS—There are two sets of NDS rights. The first set consists of Supervisor, Browse, Create, Erase, and Rename object rights. The second set consists of Supervisor, Read, Compare, Write, and Add Self property rights.
  • File system—The file system rights are Write, Read, Modify, File Scan, Access Control, Create, Erase, and Supervisor (use the acronym WoRMFACES to help remember them).

NDS and file system security are like apples and oranges. They don’t mix, except for one instance: the NDS Supervisor right to the server object. When a user has the Supervisor right to the server, that user has the Supervisor right to all files on that server. And once a user has the Supervisor right to the file system, there is no way to block the user from that system. Clearly, you need a way to allow certain users to have the NDS Supervisor right so they can handle administrative tasks—but without giving them uncontrolled access to the entire file system. Let’s take a look at a scheme for accomplishing that.

Granting the Supervisor right
How does a user get the Supervisor right to the server object? When an organization’s first NetWare 4.x or 5.x server is installed, the OS creates the Admin user object. This object is a user object like any other and can be deleted, renamed, and modified. But the Admin object is special because it’s automatically made a trustee of the [Root] in the NDS tree and granted the Supervisor object right. This assignment flows into all container objects and all leaf objects. More importantly, the Supervisor object right flows into all server objects in the tree, thus giving the Admin object the Supervisor right to all files on all servers in the tree. This assignment enables the Admin object to administer the network file system no matter how big or small the network is.

Selected properties in the ACL provide the key
So how can an administrative user be allowed to manage objects in NDS without having access to the network file system and all the sensitive data therein? One solution is to grant the user Create, Delete, Browse, and Rename access at the container level. However, the problem with this assignment is that the user won’t be able to change any value of preexisting objects. For example, the user can’t reset another user’s password. Obviously, this would be a problem for an administrator.

To give the administrator change permissions, you will need to grant the user the Write and Read rights to all properties. However, granting the Write right to all properties gives the user the Write right to the access control list (ACL). In NetWare, this assignment is the equivalent of having the Supervisor right to the server object—so we’re back where we started, right? Well, not quite. All you need to do is use Selected Properties. Give the user the Read right to the ACL in Selected Properties and the problem is solved.

What have we learned? We know the NDS Supervisor right flows from the server object to all files on the server. So if you want a user other than Admin to administer NDS without having all file system rights, grant that user Create, Delete, Browse, and Rename object rights at the container level. Then, grant the user Read and Write rights to all properties, with Read rights to the ACL in Selected Properties.
If you’d like to share your opinion, start a discussion below or send the editor an e-mail.