Understanding Security Equivalence
Articles and Tips: tip
Blair Thomas
01 Sep 1996
Security equivalence simply means that an object can be equivalent in rights to another object. The majority of rights assignments should be made by administrators through the use of security equivalence. The reason being that it is quick and easy to use security equivalence because you can deal with a large number of users rather than a single user at a time. Time is always a factor for network administrators and we recommend that you use security equivalence assignments to groups or containers as the best way to make rights assignments to large numbers of people.
To meet the needs of many users needing the same rights to a directory or file, you can create a group, assign rights to the newly created group, and add members to the group. The members of the group are security equivalent in rights to the group object. Therefore, any assignment made to a group will be received by its members through security equivalence. An example of this process is shown in Figure 1.
Figure 1: An example of creating a group and granting rights to the group. The users receive rights through security equivalence.
In addition, a container functions much the same way as a group except that the group is used in your login scripts and a group can span multiple containers. If all users in a container access the same resources, it may not be necessary to use groups. However, if you want to further differentiate your environment setting within a container, the group object is an effective way to go.
Rules Governing Security Equivalence
Because the use of security equivalency will be so common on your network, it is very important to understand how this feature of NetWare 4.1 security functions. You will save time as a network administrator if you understand the rules that govern security equivalence.
Rule 1. Security equivalent rights cannot be masked. If you receive a security equivalence, this assignment cannot be masked by the IRF.
Rule 2. Every object is security equivalent in rights to all container objects that are part of its distinguished name. This security is known as "implied" security equivalence. For example the user Guinevere.Fin.Ops.Camelot in the ACME tree is security equivalent to every object in its name. Therefore, if you were to grant the container FIN rights to a particular E-Mail server, user GUINEVERE would receive those rights through security equivalence.
Note: You cannot single out users to not receive rights granted to a container by using an IRF. If you grant rights to a container, all users that are in or subordinate to that container will always receive those rights.
Rule 3. Every object is security equivalent to [Root]. Once a user has successfully logged in to a server, that user is security equivalent in rights to [Root].
Rule 4. Every object is security equivalent to [Public]. The [Public] trustee allows users to browse the tree before logging in to a server. Each user is security equivalent to [Public] and the [Public] trustee has been granted browse rights at object [Root]. This assignment can be changed if you like.
Note: Be very careful with assigning rights to the [Public] trustee because of the security equivalency with all users. This means that they do not need to be authenticated in order to receive those rights. The assignment of file system rights is nonfunctional when using the [Public] trustee. You cannot grant access to files before the user has successfully logged in to the server. Generally, the use of the [Public] trustee for granting rights should be avoided.
Rule 5. An object is security equivalent to all objects listed in its Security Equals property. An NDS object will keep a list (known as the Security Equals Property) of all objects that it equals in rights.
Keep in mind that when a user logs in to a NetWare 4.1 server and authenticates to the Directory, Directory Services creates what is known as a security equivalence vector that is stored in the connection table on the server. The security equivalence vector contains a listing of that object's security equivalencies and is created on every server that the client authenticates to.
Inheritance
Inheritance is the method by which rights to objects and files flow down to subordinate levels of the tree. As previously stated, explicit trustee assignments at a higher level in your tree will flow down. The rights you receive at lower levels without assignment are known as inherited rights. Inheritable rights include an object's ACLs (object rights) and the [All Properties] ACL. Selected property rights are not inheritable in the NetWare 4.1 release.
Note: Sometimes there is the tendency to confuse security equivalence and inheritance. Keep in mind that inheritance is simply the way that previously granted rights flow down the tree to subordinate levels.
Earlier in our discussion we mentioned that explicit rights, such as the ADMIN user object possessing the Supervisor right at the [Root] object, flow down the tree. As shown in Figure 2, the Supervisor assignment continues to flow down the tree unless it is otherwise blocked or reassigned. Therefore, at each subsequent level in the tree the ADMIN object's rights are being received through inheritance.
Figure 2: Inheritance of the Supervisor right at the second and third levels of the tree.
Inherited rights also flow down independently of other rights assignments, such as those obtained through security equivalence. This means that the rights received through inheritance are not affected by actions you may take other explicit rights assignments. The two operate under separate rules. Do not mix up your security rules. Figure 3 shows how explicit rights assignments flow down independently of security equivalent rights.
Figure 3: The explicit assignment of the Supervisor right flows down the tree independently of the Browse right, which was received because user ALincoln is security equivalent to the [PUBLIC] trustee.
* 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.