About Access Control Lists
Articles and Tips: article
Senior Editor
Novell AppNotes
01 Jun 2001
An Introduction To Access Control Lists
One basic form of Novell Directory Services (NDS) security is to control who has what type of access to objects. NDS accomplishes this with the access control list (ACL). ACLs are the most important mechanism for determining access to NDS and its objects. Simply put, an ACL specifies who has rights to an object and to its attributes.
These rights are different from file system rights that many of you are familiar with if you have "grown up" on NetWare. If you have file system access on a server, you can work with the files and directories that you have been given rights to access. But if an ACL makes you a trustee of a server, you can work with the server object and with the server object attributes that you have been given the rights to. For example, through the ACL, you can be given rights to rename the server object or delete the server object in NDS. File system rights do not give such permissions; they give you rights only to the file system. Whereas, ACL rights are only for network resource objects in NDS, such as printer objects, user objects, server objects, etc.
You can think of an ACL as a key to the object. Any object listed in another object's ACL has a key to that object. The type of key an object has is determined by the type of rights you assign in the ACL (these are covered further in this column). An object that has access to another object is called a trustee of the object that it has access to. Keep in mind that objects can also be trustees of themselves.
The ACL itself is a multi-valued optional attribute that is defined on the Top class, which is the most superior object class in the NDS inheritance hierarchy. Because all NDS objects inherit from the Top class, all NDS objects inherit the ACL as it is defined there. This particular ACL is a very basic access control list which grants an object's creator Supervisor rights to the object. This ensures that every object in the NDS tree has an object that holds supervisory rights to it, so that somebody can delete, modify, create subordinate objects, etc to that object.
In addition, some base object classes have a default set of values that are pre-defined for their ACL attribute, called the default ACL. The default ACL provides a minimum amount of security access for newly created objects. When an object is defined from an object class that has a default ACL, that object's ACL contains those pre-defined values automatically when that object is created. For example, this allows the User object class to automatically have rights to read and write the Login Script and Print Job Configuration attributes.
An object class inherits the default ACL templates that are defined for any of its super classes, and it can have additional ACL values of its own. For example, the Print Server object class inherits default ACL templates from the Top and Server classes, and then defines a default ACL for itself (Print Server class).
ACL Rights and Privileges
The ACL contains three types of values that define the rights and privileges it will grant:
Trustee name
Protected attribute
Assigned privileges
Trustee Name
The trustee name is the name of the NDS object the rights are being granted to. (These rights are explained in the Assigned Privileges section.) In some instances the trustee name is a user name, such as nmclain. In other instances, the trustee name is the name of a network resource, such as a particular server. In addition, the trustee name can hold the following special values:
Public. An ACL that has Public as its trustee name defines the rights that the trustee has to this NDS object may be able to view or access the object without being authenticated to NDS. Any rights granted to Public will also be granted to all NDS objects in the tree-this makes it free to anybody (John Q. Public). As a general rule, you will need to be careful as to how you will grant this.
[Root]. An ACL that has [Root] as the trustee name defines the rights the trustee has to an NDS object when the trustee is authenticated to NDS. Any rights granted to Root will also be granted to all authenticated NDS objects. As a general rule, you will need to be careful as to how you will grant this.
Inherited Rights Filter. An ACL that has Inherited Rights Filter as the trustee name is being used to block rights that would otherwise flow down the tree from the object that is holding this ACL on down the tree.
[Self] or [Creator]. An ACL with either Self or Creator as the trustee name is naming itself as the trustee of the ACL and is granting itself rights to itself. In the ACL, NDS replaces the terms [Self] and [Creator] with the actual object's name. [Self] is replaced with the object's name that is holding the ACL. The object is a trustee to itself. [Creator] is replaced with the trustee's name that created the object that is holding the ACL.
Protected Attribute
The protected attribute can specify three types of access control rights. Simply put, the value in this field specifies whether the rights are being granted to the object as a whole (Entry Rights), all the object's attributes (All Attributes Rights), or a specific attribute (Specific Attribute Rights). These are defined below:
Entry Rights. These rights grant the trustee rights to the NDS object (also called an entry) as a whole. A trustee who is granted these rights will be able to do operations on the object as a whole, depending upon the rights the trustee is given. These rights include browsing for the object, deleting the object, and creating objects subordinate to it. However, Entry Rights don't include rights to any attributes.
All Attributes Rights. These rights grant the trustee rights to all attributes of the NDS object. Giving a trustee Entry Rights doesn't give the trustee rights to work with the attributes. If you want the trustee to be able to browse for, read and compare all of the object's attributes, for example, grant the trustee All Attributes Rights.
Specific Attribute Rights. These rights grant the trustee rights to a specific attribute of the NDS object. If you want the trustee to only be able to work with specific attributes, create an ACL granting the trustee rights to each specific attribute the trustee needs.
The rights you can give the trustee depend on whether you have given the trustee Entry Rights, All Attributes Rights or Specific Attribute Rights.
Assigned Privileges (Rights)
These are the specific rights that NDS grants to the trustee for an object. The rights the trustee can have depend on the protected attribute in the ACL. (The protected attribute is the Entry Rights, All Attributes Rights, and Specific Attributes Rights that we have just discussed.) The assigned privileges or rights are listed below and are in association with each protected attribute value.
Privileges Associated with Entry Rights.
If the protected attribute is Entry Rights, these are the privileges (rights) you can assign in the ACL:
Browse. Allows the trustee to discover NDS objects.
Create. Allows the trustee to create subordinate NDS objects below this one.
Delete. Allows the trustee to delete the NDS object.
Rename. Allows the trustee to rename the NDS object.
Supervisor. Allows the trustee to have all rights to the NDS object and its attributes.
If the object is a container, these rights apply to all objects in the container.
Privileges Associated with All Attributes Rights.
If the protected attribute is All Attributes Rights, these are the privileges (rights) you can assign in the ACL:
Compare. Allows the trustee to verify whether a given attribute value matches an existing value within the container.
Read. Allows a trustee to read an attribute value. Granting this rights implies that the Compare right is also allowed.
Write. Allows a trustee to add, modify, or delete an attribute value. If a trustee is given the Write right to an ACL, it can modify that object's trustee assignments. This means that an object with the Write right to another object's ACL can make any rights assignments to that object. As a security rule, be careful how you grant the Write right. By default, users don't receive Write rights to their own ACL. As a general rule, don't grant users Write rights to any ACL, including their own user objects, because the Write right to the ACL controls all access to those particular objects. A user possessing the Write right to a container ACL has the ability to make any changes to that object's ACL. For example, the user could assign anyone Supervisor object rights to that object and could modify the object as well.
Add or Delete Self. Allows a trustee to add or delete its entry as an attribute value. This right enables the trustee object to add or delete itself as an attribute value at will.
Supervisor. Allows the trustee to have all rights to the attribute.
If the object is a container, these rights apply to all objects in the container.
Privileges Associated with Specific Attribute Rights.
The Specific Attribute Rights can have the same privileges that are listed under the All Attributes Rights above. These rights can't be inherited by objects in a trustee container. Inheritable ACLs, introduced in NetWare 5, changes this.
NetWare 5 has a feature called Inheritable ACLs. These help you to more easily manage the objects and properties of the NDS tree. With inheritable ACLs, you can allow specific property rights to be inherited down the entire tree. For example, the NDS inheritable ACLs allow you to assign Supervisor rights to operators or help desk staff for specific types of objects or resources without giving Supervisor rights to the entire tree. You could assign rights to a group to manage the telephone numbers in the tree.
Example ACLs
Let's look at some default ACLs in the NDS schema. The schema reference document defines the default ACL template on the object definition page. You can view or download the schema reference document at the http://www.developer.novell.com URL. As we look at these ACLs, remember that these are the default ACLs that NDS makes as it is initially installed on a server. You can use ConsoleOne to assign other ACLs to specific objects.
Let's first look at a simple default ACL. This is the default ACL for the Device object class:
Device Object Class Default ACL Template
Object Name
|
Default Rights
|
Affected Attributes
|
Class Defined For
|
[Creator] |
Supervisor |
[Entry Rights] |
Top |
This default ACL tells us that when you create a Device object, NDS will automatically give the object that created it (probably a user object such as nmclain) Supervisor rights to the newly created object. You can tell this because the value for Object Name is [Creator]. This means that NDS will give rights to the object's creator, which in this case is nmclain. The value in Default Rights is Supervisor. This means that NDS will automatically give nmclain Supervisor rights to the object. The value in the Affected Attributes is [Entry Rights]. This means that NDS will give nmclain Supervisor rights to the whole object (or entry). Remember that objects other than users can create objects in NDS. In that case, the term [Creator] will be replaced by that object's common name.
Those three values basically constitute the entire ACL. The sample template shows a category called Class Defined For. This category is not part of the ACL. It merely shows you where this object class is inheriting the ACL from. In this case, Device is inheriting this ACL from the Top object class. This default ACL is the ACL that all objects inherit from the Top class, which ensures that every object has one other object with Supervisor rights to it.
Now let's look at another default ACL template. This is the default ACL template for the Print Server object class.
Print Server Object Class Default ACL Template
Object Name
|
Default Rights
|
Affected Attributes
|
Class Defined For
|
[Creator] |
Supervisor |
[Entry Rights] |
Top |
[Public] |
Read |
Network Address |
Server |
[Self] |
Supervisor |
[Entry Rights] |
Server |
[Root] |
Read |
[All Attributes] |
Print Server |
The Print Server object Class has four trustees assigned to it in its ACL. The trustees are the objects listed in the Object Name category. The first trustee is the trustee inherited from the Top class. This trustee is the object that created the print server, and that object will have supervisor rights to the entire object.
The next trustee in this ACL is [Public]. NDS will automatically assign Read rights to the Network Address attribute to any object that is not authenticated to NDS. For example, unauthenticated users will be able to read the network address to this print server. In this case, the ACL is assigning a specific right, Read, to a specific address, Network Address. The Print Server object inherits this ACL from the Server object class.
The third trustee in this ACL is [Self]. This refers to the Print Server object itself. Here, NDS will give the print server Supervisor rights to its own object. Remember the Entry Rights attribute value means the rights to the entire object and all its attributes. The Print Server also inherits this ACL from the default Server object class.
The last Trustee in this ACL is [Root]. NDS will replace the term [Root] with the tree name. So, NDS assigns these rights to the entire tree. In this case, the Affected Attribute is [All Attributes]. This means that NDS is granting all authenticated objects in the tree the Read right to all of the Print Server's attributes. So, authenticated objects in the NDS tree can read the values in all of the Print Server object's attributes. This ACL is defined specifically for the Print Server call.
Let's look at one more default ACL example: the User object class.
Print Server Object Class Default ACL Template
Object Name
|
Default Rights
|
Affected Attributes
|
Class Defined For
|
[Creator] |
Supervisor |
[Entry Rights] |
Top |
[Public] |
Read |
Message Server |
User |
[Root] |
Browse |
[Entry Rights] |
User |
[Root] |
Read |
Group Membership |
User |
[Root] |
Read |
Network Address |
User |
[Self] |
Read |
All Attributes |
User |
[Self] |
Read/Write |
Login Script |
User |
[Self] |
Read/Write |
Print Job Configuration |
User |
The first ACL is the ACL that all objects inherit from Top. The User object class only inherits one ACL. All of the other ACLs are defined specifically for the User object class. When NDS creates the user object, it assigns [Public] as a trustee and gives it Read rights to the User object's Message Server attribute. This means that any unauthenticated object in the NDS tree, such as an unauthenticated user can read the value in the user's Message Server's attrribute. This would be the name of a user's Message Server.
This ACL template tells us that NDS assigns [Root], or all authenticated objects in the entire tree, the following rights:
Browse to the entire user object [Entry rights] . This means that all authenticated objects can browse and find the user object and all of its attributes.
Read to the specific attributes group membership and network address. This means that all authenticated objects can read the values in the user object's Group Membership and Network Address attributes.
NDS also assigns the User object [Self] the following rights:
Read to [All Attributes]. This means that the user object can read its own attributes.
Read/Write rights to it's own specific attributes Login Script and Print Job Configuration. This means that by default, a user can only write values to it's Login Script and Print Job Configuration attributes.
Assigning New ACLs to Objects
You can assign new ACLs to objects in ConsoleOne. For example, if you wanted to give users more rights to their own object, you would simply enter those rights in ConsoleOne and choose whether to give the users:
[Entry Rights]. The rights to their entire object.
[All Attributes]. All of the attributes of their object.
A specific attribute. A specific attribute on their object, such as Login Script.
You would then assign the particular right you want to give the user for that category (assigned privilege.)
You would use the same general process to assign objects rights to other objects. For example, if you wanted to grant a user rights to a Print Server, you would use ConsoleOne, open the Print Server's object and assign the Print server a trustee by entering the user's common name. You would then assign the user rights to the entire print server object ([Entry Rights]), all of the print server's attributes ([All Attributes]), or one of the print server's specific attributes. You would then give the user the specific rights you wanted the user to have on the object or its attributes.
Conclusion
ACLs are extremely powerful, and you should closely control their access for every object on your network. Because the ACL is a property of an object, anyone who has Write rights to an object's ACL property can modify it. This means that someone with the Write rights to the ACL can make rights assignments for that object.
Using the default ACL values is a closed-door approach to security. It tightly limits access to NDS objects. As an administrator, you must open up security doors by granting additional rights only when necessary. Keep in mind that by default the majority of your users receive sufficient access rights when they are created.
* 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.