Understanding NetWare Directory Services Rights
Articles and Tips: article
Senior Consultant
Systems Research
TIM MYERS
Senior Software Consultant
Novell Consulting Services
01 Apr 1993
Understanding the new NetWare 4.0 Directory Services rights may seem overwhelming at first. This AppNote lays out some fundamental concepts of the Directory rights structure. It starts with some definitions of the NDS structure, and proceeds to explain how rights are assigned using Access Control Lists. It also discusses inherited rights, security equivalences, and bindery emulation.
- Introduction
- NDS Objects
- NDS Properties
- Access Control Lists
- Inherited Rights
- Security Equivalences
- File System and NDS Rights
- Bindery Emulation
- Summary
Introduction
In NetWare 4.0's NetWare Directory Services (NDS), the "Directory" provides structure to a company's computer network system. This tree structure allows you to closely represent the way in which companies are typically organized. Instead of the "flat" organization of the old NetWare Bindery, NDS provides a hierarchical structure which can greatly simplify the administrative tasks of large, complex networks.
The Directory in NDS allows a client to enter, utilize, and become part of an enterprise- wide network. For those of us that have used bindery- based NetWare, expanding our mindset to encompass this new structure will be the biggest initial hurdle.
Since the NDS Directory structure should in some way represent the structure of the company in which it is installed, it is extremely important that the Directory be planned. Some guidelines for doing this are presented in the "Planning a NetWare 4.0 Directory Tree" AppNote in this issue.
This AppNote lays out some fundamental concepts of the NetWare 4.0 Directory rights structure that you will need to know as you plan your Directory. This AppNote attempts to present these concepts in a straightforward manner.
We start with some definitions of the NDS structure and then proceed to explain how rights are assigned using Access Control Lists. Next, we review the important concept of inherited rights and how they may be limited by the Inherited Rights Filter. Then we discuss the security equivalence enhancements. At the end we give a brief overview of Bindery emulation.
Note: As you read about these new rights, remember that we are not defining rights associated with the file system of NetWare servers, but only those rights that pertain to the NetWare Directory.
The NetWare Bindery
A computer network is made up of different entities or objects. These include - but are not limited to - users, servers, and printers. The network must have some way of identifying and dealing with these different objects. In previous versions of NetWare, this task was handled through the NetWare "bindery."
The NetWare bindery is a flat database which is unique to each NetWare server. It contains information such as a user's name, object ID, password, and security equivalences. Since the bindery information is unique to each server, each server is responsible for keeping track of its own information.
Prior to NetWare Directory Services, file servers did not communicate this information to other servers. As a result, passwords for each user account were kept on each server, even if the user accounts were the same on all servers. Even with NetWare Name Service (NNS), a utility program synchronized information between servers, but the servers never talked to each other directly.
Whenever the NetWare operating system (which in bindery-based NetWare is the same as the NetWare server) needs to check object information, as in the case when a user logs into the system, it searches for the object in its bindery files.
When we say that the bindery files are "flat," we mean that entries do not have any explicit relationship to other entries. Users could be organized into groups (which were also bindery entries), but without looking up each specific user, this group relationship was not apparent.
The NetWare Directory
With the NetWare Directory, the way in which objects are identified and dealt with by the NetWare system has changed substantially. The term "directory" comes from the name commonly used for telephone number and address reference books. This is also the name defined in the proposed CCITT X.500 standard.
Because the term "directory" also refers to the organizational file structure on a computer's hard drive, it is important to keep these concepts separate. In some instances, though, this common understanding will be helpful in understanding the NetWare Directory. To delineate between the two, we refer to the NDS Directory tree or structure as the Directory (with an uppercase D).
The NetWare Directory is the information database for all objects in your network. It defines the objects in the system on a network- wide scale. The Directory contains the information for all objects that are a part of the network, including users, groups, servers, printers, and so on. Now Users must identify themselves only once to the Directory (which authenticates them to the entire network), in contrast to having to log in to each specific server.
The Directory is organized in a hierarchical tree structure, in contrast to the flat structure of the bindery. The Directory information is structured to show relationships among different objects. You may now have an object in your network that is a container which holds other objects.
For a more detailed description of the NDS and the Directory tree, see the "Introduction to NetWare Directory Services" AppNote in this issue.
NDS Objects
As we have stated, there are many different objects in a network. In NDS terminology, the term "object" is used to mean any item which can exist in the network structure. Each object also has a defined set of properties.
Objects that can contain other objects are referred to as container objects. Other objects are simply endpoints that do not contain other objects. These objects are referred to as leaf objects. The special object called [Root] is automatically created at the top of the Directory tree.
Figure 1 shows an example of these different kinds of Directory objects.
Figure 1: Example of Directory tree objects.
Examples of container objects are Organization (O) and Organizational Unit (OU). The purpose of these objects is to organize your Directory information.
Examples of leaf objects are users, groups, NetWare servers, printers, and other network resources. The purpose of these objects is to identify and provide information about actual entities in your system.
It should be clear that the Directory does not force you to conform to a hierarchial structure. Underneath a single Organization (O), you could simply define all objects into a flat structure, something like a super-bindery.
However, a large system organized like that can quickly become cumbersome to manage. It would be like trying to manage government files if they were all stored in the same area of a single building. Whenever motor vehicle information was requested, for example, you would need to have someone search through tax, property, and other kinds of government information in order to find the motor vehicle information.
The Directory hierarchy allows you to take advantage of the natural organization of information.
Object Rights
As you might expect, each object in the NetWare Directory has rights that are associated with it. These rights control what users or other entities in the system can do to the specified object. These Directory object rights are summarized below:
|
Right |
Description |
|
Browse |
The right to see the object in the Directory tree. |
|
Create |
The right to createa new object below the specified objectin the Directory tree.(This right applies only to container objects.) |
|
Delete |
The right to delete the object from the Directory tree.Leaf objects and empty container objects arethe only objects that can be deleted. |
|
Rename |
The right to change the name of the object. This rightonly applies to leaf objects. |
|
Supervisor |
The right to all object access privileges as well as all rights to the object's properties. |
As an example, if you as a user had the Browse right to an object in the Directory tree, you would be able to see that object in the tree. When a user leaf object is installed into the Directory tree, the Browse right is given to the user object itself. This is so the user can see its own object in the tree.
NDS Properties
NDS properties are another important component in the Directory. All objects have properties. Each property can have at least one value; many of the properties can have multiple values. Rights for a given property apply to all of its values.
Property Rights
Each property in the NetWare Directory has rights associated with it. These rights control what users, or other entities in the system, can do to the property. These property rights are summarized below:
|
Right |
Description |
|
Compare |
The right tocomparea value to the value of the property.This does not allow you to see the property value. |
|
Read |
The right toread the values of the property. If the readright is given, compare operations are alsoallowed even if the Compare right is notexplicitly granted. |
|
Write |
The right toadd, remove, or change any values of the property. |
|
Add orDelete Self |
The rightto add or remove itself as a value of property.Thetrustee cannot affect any other values ofthe property. (This would be useful for propertiessuch as mailing lists, or group lists.) |
|
Supervisor |
All rights to the property. |
It is important to note that property rights can be assigned to all properties of an object, or only to specific properties of an object. For example, when a user object is created in the Directory, the user object itself is given the Read right to all properties of that object. In addition, the user is also given Read/Write rights to its Login Script property and the Print Job Configuration property. However, in this case it would not normally be appropriate for the user object to have Write access to its login restriction properties, for example.
Remember, object and property rights apply only to the NetWare Directory, not to the file system.
Access Control Lists
All objects can also have a property known as the Access Control List (ACL). The ACL property warrants special examination because it controls access to both the object and its properties. For both the object and its properties, it lists who has rights (trustees) and what those rights are (rights assignments).
Important: The ACL lists who has access to the particular object or properties. It does not list what the object might have rights to.
This concept is important to understand because if you want to grant a user object a right to a printer object, you must go to the printer object and make the user a trustee with the desired right. You would not go to the user object and make the printer object a trustee of that user.
Each ACL value can specify rights for one of the following:
A specific property, such as "Login Script"
All properties of that object "[All Property Rights]"
The object itself
The Supervisor right on the object effectively gives all rights to all properties. As an example, a user object will typically have Read rights to itself, Read rights to [All Properties Rights], and Read/Write rights to its Login Script property.
Since the ACL is itself a property of an object, the ACL can have (as one of its values) a trustee assignment to itself. If the trustee has the Write right to the ACL, that trustee is allowed to modify any of the rights of the object.
In actual use, it is unlikely that managers will only be assigning themselves the Write right to the ACL of their respective managed objects. It is more likely that they will assign themselves Supervisor object rights to their objects. This gives them all object and property rights to the object by default.
Additionally, when an object is created, the creator object automatically receives all object and property rights to the newly created object.
The ACL property of a given object defines the explicit rights granted to trustee objects on the given object. However, as we will discuss next, it is not necessary to grant explicit rights to every object.
Inherited Rights
In the NetWare Directory, object and property rights flow from the top of the structure down the tree. When rights flow down the tree, they are known as inherited rights. Inheritance is one of the most important areas to understand regarding the Directory rights. With proper planning, the Directory can organize the necessary rights for your objects with a minimum of explicit trustee assignments.
Note: Inheritance is a concept familiar to those who understand how rights flow in the NetWare volume directory structure. In that structure, if rights are granted to a user or group at one part of the tree, the rights flow down through any branches that exist.
As stated above, rights flow (or are inherited) in the NetWare Directory from the top of the tree downward. However, the only rights that are inherited are [Object Rights] and [All Properties Rights].
Only one specific trustee assignment is effective at a time. Thus, when specific trustee assignments are granted to the same user object at different points in the Directory tree, the lower rights assignment is the inherited one. The upper rights assignment is ignored in the lower portion of the tree. This fact underscores the need to carefully plan the inheritance of rights as you build your tree. You can control inheritance for a specific user by making multiple assignments.
Inherited Rights Filter (IRF)
The NetWare function that limits inherited rights for all users in the Directory is called the Inherited Rights Filter (IRF). Note that not only are IRFs available for Directory objects and [All Properties Rights] assignments, they are also available for specific property rights assignments. This functionality parallels the rights-filtering capability of the NetWare file system.
In contrast to the trustee assignments, IRFs do not grant rights. They exist for the sole purpose of revoking rights. Their effect for every object that does not have a trustee assignment to this object is to allow only the specified rights to exist.
In the instance where a specific trustee assignment is granted, the object to which the assignment is granted will override the IRF restrictions. This is true for both object and property rights.
This is an easy concept to understand if you remember that IRFs exist solely for rights "coming down the tree." They do not affect any rights granted at the point you setup the IRF.
Disallowing Supervisor Rights with an IRF. An exception exists in the case of the Supervisor rights being disallowed via the IRF. If you disallow the Supervisor property right, all objects who do not specifically have the Supervisor property right granted to this object will be disallowed that right from inheritance. The only exception is the Supervisor object right. By default, this right grants all property rights and cannot be limited by a property IRF. So if an object inherits the Supervisor object right from above, a property IRF has no affect on that object.
Important: If you disallow the Supervisor object right via an object IRF, this disallows inheritance of the Supervisor right from above. Therefore, you can effectively prevent Supervisor access to portions of your Directory by placing object IRFs which disallow the Supervisor object right from being inherited.
You should never block Supervisor rights from a part of the tree, however, without first making sure that there is some object which does have the Supervisor right to that part of the tree. This safeguard is not automatically enforced by the NDS.
In most cases, granting Supervisor access to the Directory in order to allow object additions, deletions, and modifications to separate users will be critical to the success of network administration. Users who need to run their own servers and their own departments will still want that flexibility. NDS security rights allow this.
At this point, we should emphasize that it is highly recommended that every company constructing an enterprise-wide network structure outline in writing the naming and structure methodology for the network Directory. This way, all subsequent supervisors and users can adhere to an integrated network structure.
Deleting Objects That Have Supervisor Rights. As the administrator of all or part of a Directory tree, you must take special precautions when deleting objects that have Supervisor rights. If you inadvertently remove all objects with Supervisor rights, you will have no effective way of managing that section of the tree.
One possible way to avoid this problem is to create a "master" user which has explicit Supervisor rights wherever they are absent in the tree. Regular administrators would not be allowed to use that user object, but it would be available if needed to re- establish control.
Another situation to be aware of involves IRFs which limit Supervisor access. If your user object is only granted the Supervisor object right, then as that right is inherited down the tree it can be blocked by object IRFs that disallow the Supervisor right. This means that the user object would have no rights in that part of the tree. If that same IRF allows other rights to flow through, the user object in question still does not have any rights.
Put another way, simply granting the Supervisor object right does not explicitly grant all object rights. It only grants them implicitly. You would need to grant the other object rights to yourself if you needed those rights. In the example above, other objects that were given the Browse object right higher in the tree would have more rights than the Supervisor user at the IRF point in the tree. For this reason, we recommend that you also grant all object rights when you are granting Supervisor object rights.
Security Equivalences
Security equivalence in the NetWare 4.0 environment is a powerful enhancement over the similar feature in previous versions of NetWare. There are some security equivalences which are system defaults and cannot be assigned or revoked. We will cover these security equivalences in this section.
One scenario in which assigned security equivalences might be useful is when one user (User A) from one part of an organization needs access to another user's (User B) files. To accomplish this, you could simply add User B to User A's security equivalence list.
To add a security equivalence to a user object, you must write-manage the object you wish to make the object security equivalent to. "Write-manage" means that you have at least the Write right to the ACL property of that object.
By using security equivalences, you can give your rights to any other user on the network.
Implied Security Equivalences
As previously stated, there are some default security equivalences which cannot be assigned or revoked. All objects are security equivalent to the following objects:
The [Root] object
Each successive container object directly from the root through the user's container object
The [Public] trustee
These default security equivalences cannot be changed, nor can they be viewed with the NETADMIN or NWAdmin utilities.
Why are user objects made security equivalent to the [Root] and to each container object directly from the [Root] to the container object that they are in? Unlike bindery-based NetWare, NetWare 4.0 allows any object to be a trustee of another object. This means you can assign file rights, or rights for accessing a printer, to an organizational unit, for example, rather than just to a group or specific users.
This ability lets administrators use the Directory tree's container objects as groups. For the purpose of illustration, let us assume a Directory structure that is organized in the following manner:
Each department in the company has its own Organizational Unit (OU) in the tree.
Each Organizational Unit (OU) contains each department's user objects.
Since all user objects created in the department's (OU) are implicitly security equivalent to the (OU), you can assign all the trustee assignments you want all users in that department to have to that (OU). If you need to move users from one department to another, you can do so without having to tediously reassign rights to the moved users. They immediately get all rights assigned to the department (OU) they move into, and lose any rights from the department (OU) they left.
Important: Be careful when assigning rights to container objects in the tree. Assigning rights to the root container of a tree will give all user objects in the entire tree that right (unless they are filtered out by an IRF).
The [Public] Trustee
The [Public] trustee is a special trustee which can be added to any object (as well as to server volume directories and files). Whatever rights are assigned to the [Public] trustee are granted to any client, even if that client has not been authenticated to NetWare Directory Services.
While this feature may be reminiscent of the user GUEST and group EVERYONE in previous versions of NetWare, it is not exactly the same. The [Public] trustee is not a real object. Even users which are not authenticated (not logged in) to NDS have the same rights as the [Public] trustee.
When a system is first installed, the [Public] trustee is granted the Browse right at the [Root] of the Directory tree. This allows all user objects in the tree to "get around" the tree. If desired, this right can be removed from the [Root] object.
A more secure setup would be to grant the Browse right to the root container of your Directory, as explained previously. Such an assignment would allow only authenticated objects in your tree to browse the entire tree, provided that the Browse right was not excluded with an IRF.
When a NetWare server is installed into the tree, the [Public] trustee is automatically given the Read and File Scan rights to the LOGIN directory on the SYS volume.
File System and NDS Rights
In NetWare 4.0, Supervisor rights to the volumes of a given server derive from Write management of the server object itself. In other words, any user which has at least Write rights to the ACL of the specified server's object will have Supervisor rights at the root of each of the specified server's volumes.
Another important thing to remember is that file system rights are granted to trustees, and trustees can be any NDS objects, not just users and groups. For example, if [Root] is made a trustee with Read rights in a given file system directory, all users (anywhere in the NDS tree) have the Read right in that directory. This is true because all users are security equivalent to [Root].
Bindery Emulation
Bindery emulation is the method which allows bindery- based utilities or programs to utilize a NetWare 4.0 NDS-based network. Bindery emulation provides a bindery structure for the leaf objects in a container object, so that bindery clients can access a 4.0 server and see the objects in that container as if they were objects in a bindery.
Bindery emulation works by first defining the container object which will constitute its bindery. This is called the bindery context. Bindery emulation also requires that a Writable replica of the partition containing that container must reside on the server (see Figure 2).
For more information about partitions and replicas, refer to the "Introduction to NetWare Directory Services" AppNote in this issue.
Figure 2: Example of NetWare 4.0 bindery emulation.
As an installation default, every installed NetWare 4.0 server has its bindery context set to the container it is in and that container is stored in a Writable partition.
So in Figure 2, if User A were to load the NetWare 3.x shell and run the LOGIN program from Server 1, it would login as a 3.x client and be able to see the other bindery-type objects (users, groups, printers, and so on) in that same container. User A would not be able to see objects for any other container object in the tree, because they aren't in Server A's emulated bindery.
Important: A workstation context and a server's bindery context are two different things. A workstation context is not applicable to bindery emulation and it does not set the server's bindery context. The server's bindery context can only be set at the server console.
Bindery emulation is enabled during default installation. It can be disabled by using the "SET BINDERY CONTEXT =" command at the server console.
Important: NetWare for Macintosh and bindery- based versions of NetWare still require bindery emulation. For this reason, we suggest that you leave bindery emulation enabled.
Summary
This AppNote has provided a basic overview of the object and property rights, access control lists, inheritance rights filters, security equivalences, and bindery emulation features of NetWare Directory Services. Future AppNotes in this series will provide information on NDS authentication and NetWare 4.0 auditing.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.