Novell Home

A Secure Remote Control Is a Good Remote Control

Novell Cool Solutions: Feature
By Matthew Lewis

Digg This - Slashdot This

Posted: 4 May 1999
 

Say the word "remote control" in conjunction with "workstation" and most PC users understandably get a little nervous: "You can control my workstation? You're going to do what with it?"

But when it comes to making sure the power to remote control falls into the right hands, there are fewer worries with Z.E.N.works™ 1.0. The reason? Z.E.N.works uses NDS™ authentication to provide huge security improvements over other remote control offerings. That's because rights to remote control a workstation are based entirely on NDS rights. In other words, only users who have appropriate NDS rights to the Workstation object can remote control the workstation.

This week's Feature Article presents methods for using NDS rights to accomplish these tasks. Here's what we've got on deck:

Granting Remote Control Rights to a User
Revoking an Administrator's Remote Control Rights
Using Groups or Organizational Roles to Ease Administration
Using a Suggested NDS Tree Design: Workstation Containers

Within Z.E.N.works are three NDS rights that a user needs to have to remote control a workstation:

  • Browse entry right to the Workstation object
  • Read attribute right to the "WM:Network Address" attribute of the Workstation object
  • Write attribute right to the "DM:Remote Control" attribute of the Workstation object

This gives a user the rights needed to remote control a workstation without also giving that user rights to other portions of the Workstation object. This implementation also enables you to restrict users who have inherited the Supervisor or Write attribute right to the Workstation object from being able to remote control that workstation. Here we'll cover two common scenarios: granting a user rights to remote control a workstation, and revoking an administrator's rights to remote control a workstation.

Note that we're not going to cover assigning Browse entry rights to Workstation objects, since most trees have [Public] or [Root] browse access. If your tree does not have [Public] or [Root] browse access already established, remember to also grant the Browse entry right when performing the rights operations described below.

[Back to Top]

Granting Remote Control Rights to a User
There are several methods for granting a user the necessary rights to remote control a workstation. The easiest method is adding the user as an operator of the workstation. This is done within NetWare Administrator in the Details of the Workstation object. A workstation operator is given the Browse entry right to the Workstation object and Read and Write attribute rights to the attributes of the Workstation object. By definition, an operator of a workstation can remote control the workstation.

Another quick method for giving a user rights to remote control a workstation is to give the user either the Supervisor attribute right or Read and Write attribute rights to the Workstation object directly. On a larger scale you may want the user to be able to remote control any workstation in a particular container or in an entire subtree. In this scenario you may assign the Supervisor attribute right or Read and Write attribute rights to a container. Barring the existence of an Inherited Rights Filter, the user will then be able to remote control any workstation within the subtree below that container.

The drawback to the above approaches is that the user gains many more rights than simply the right to remote control. For instance, with the Operator approach the user essentially gains Read and Write attribute rights to all attributes on the Workstation object. In the case of granting rights to a container, the user gains the Supervisor attribute right or Read and Write rights to all attributes on all objects within the subtree below that container.

If you find that the above approaches give too many rights, you may want to assign the user only the specific attribute rights that he or she needs to remote control. The following describes how this would be accomplished using NetWare Administrator:

  1. Right-click the workstation to which you want to assign rights and select "Trustees of this Object."
  2. Click the "Add Trustee..." button, and then browse for and select the user to whom you want to give rights to remote control.
  3. With the user now selected in the "Trustees" list, select the "Selected Properties:" radio button in the "Property Rights" box.
  4. Scroll down through the attributes to "DM:Remote Control" and check the "Write" check box.
  5. Scroll down through the attributes to "WM:Network Address" and check the "Read" check box.
  6. Click OK to save the changes.

The user now has the necessary rights to remote control the workstation.

A new feature of NetWare® 5 allows for specific attribute rights to be inherited down the tree. For the previous example this means that instead of having to set those two specific attribute rights on each Workstation object, you could make those rights assignments on the container where the Workstation object is found. The user would then inherit those two specific rights to each Workstation object in the subtree below that container. You could even give a user the necessary rights to remote control any workstation in the tree by giving him or her those two specific attribute rights on [Root].

A Word about Inherited Specific Attribute Rights
In case you were wondering, inherited specific attribute rights are rights designed to make a trustee assignment at a container level for a specific attribute flow down the tree to all objects below that container. The attribute to which you are making the assignment need not exist within that container object. For instance, in the previous example, a specific attribute rights assignment was made on a container for the "DM:Remote Control" attribute. The container object does not actually have a "DM:Remote Control" attribute?only the Workstation object contains it. Therefore the rights assignment on the container only gives rights to Workstation objects within that container. Since no other objects contain the "DM:Remote Control" attribute, no other objects are affected by the rights assignment. Got it?

Some Cool Suggestions
The use of Organizational Roles or Groups and Workstation containers can greatly benefit you as you make these remote control rights assignments. Refer to the "Using Groups or Organizational Roles to Ease Administration" and "Using a Suggested NDS Tree Design Suggestion: Workstation Containers" sections below and consider how those two suggestions might help you in your specific environment.

[Back to Top]

Revoking an Administrator's Remote Control Rights
Some organizations have determined that not all users who have the Supervisor or Write attribute right to a Workstation object should be able to remote control the workstation. In this scenario some rights to the workstation need to be taken away from the user (revoked). This can be accomplished through the use of an explicit rights assignment or through an Inherited Rights Filter.

Using an Explicit Rights Assignment to Revoke Rights
Since explicit rights assignments override inherited rights assignments, it is possible to revoke the remote control right from a user who has the Supervisor or Write attribute right to a Workstation object. You may do this by selecting the Workstation object from which you want to revoke rights and adding the user as a trustee of the workstation with only the Read attribute right to the "DM:Remote Control" attribute. Follow these steps:

  1. Right-click the Workstation object from which you wish to revoke the user's rights and select "Trustees of this Object."
  2. Click the "Add Trustee..." button; then browse for and select the user from which you want to revoke rights to remote control.
  3. With the user now selected in the "Trustees" list, select the "Selected Properties:" radio button in the "Property Rights" box.
  4. Scroll down through the attributes to "DM:Remote Control" and check the "Read" check box. Make sure that the "Write" check box is now unchecked.
  5. Click OK to save the changes.

This administrative user will no longer be authorized to remote control that workstation but will maintain his administrative rights to all other attributes of the workstation. One shortcoming here is that since the administrator still has rights to the "Object Trustees (ACL)" attribute of the Workstation object, he can go in and revoke the explicit assignment that is blocking his ability to remote control that workstation. You may prevent this by similarly adding an explicit Read attribute right to the "Object Trustees (ACL)" attribute. In so doing you prevent the administrative user from making any changes to the trustees of the Workstation object. This might not be desirable either, however, since the administrative user can no longer make other trustee assignments for this workstation.

Using an Inherited Rights Filter to Revoke Rights
Another method for revoking remote control rights from administrative users is the Inherited Rights Filter (IRF). An Inherited Rights Filter is set up to strip away administrative rights from all users for a container or subtree containing workstations. Then administrative rights can be given back explicitly to those who are authorized to remote control the workstations.

In the following simple example (see Figure 1), assume that User1.B.A and User2.B.A both have the Supervisor attribute right to container A. Without an IRF on container C.A, User1.B.A and User2.B.A both have the Supervisor attribute right to workstation WS.C.A. Assume that you want User1 to have remote control rights to WS but that you do not want User2 to have remote control rights. You can set up the rights using an IRF as follows:


Figure 2

  1. Right-click container C.A and select "Trustees of this Object."
  2. Click the "Add Trustee..." button; then browse for and select User1.B.A.
  3. With User1.B.A now selected in the "Trustees:" list, make sure that "All properties" is selected in the "Property Rights" box and check the Property Rights "Supervisor" box.
  4. Click OK to save the changes.
  5. Right-click container C.A and select "Trustees of this Object" again.
  6. Click the "Inherited Rights Filter..." button.
  7. In the "Property Rights" box uncheck "Supervisor," "Write," and "Add Self." (Note that you may filter the Supervisor attribute right from a container only if another user has an explicit Supervisor attribute right to that same container. This restriction prevents you from cutting off all supervisor access from a portion of the tree. In this example, User1 was given an explicit Supervisor attribute right on the container prior to filtering the Supervisor attribute right from everybody else. User1's Supervisor attribute right to the container C.A will not be filtered by the IRF because it is not inherited, it is explicitly assigned.)
  8. Click OK.
  9. Click OK again to save the changes.

After these steps are completed, User2's rights to remote control will be revoked from the entire C.A subtree. User1, however, will still be able to remote control any workstation within that subtree. It should be noted that User2 has lost more than just remote control privileges within the C.A subtree. User2 has lost all Supervisor Property Rights privileges. Please see the "Using a Suggested NDS Tree Design: Workstation Containers" section below for more about this topic.

[Back to Top]

Using Groups or Organizational Roles to Ease Administration
You may want to use NDS Group objects or Organizational Role objects to ease the administrative burden of reassigning rights to the users who ought to be able to remote control the workstation. For instance, the previous example can be enhanced to use an Organizational Role called "Remote Control Admin" (see Figure 2):

  1. Right-click container C.A and select "Trustees of this Object."
  2. Click the "Add Trustee..." button; then browse for and select "Remote Control Admin.B.A."
  3. With "Remote Control Admin.B.A." now selected in the "Trustees:" list, make sure that "All properties" is selected in the "Property Rights" box and check the Property Rights "Supervisor" box.
  4. Click OK to save.


Figure 3

Now you may simply add the users to whom you want to grant remote control rights as Occupants of "Remote Control Admin" and they will have rights to remote control. Using an Organizational Role or Group means that you only have to set up rights once. If another user needs remote control rights you can simply add him or her into the Role or the Group and he or she will have rights. Likewise you can just as quickly revoke rights by revoking the user from the Role or Group.

The benefit of using Organizational Roles or Groups becomes even more significant if your workstations are located in numerous containers throughout the tree. Imagine if your workstations reside in even ten different containers. Setting up a user to remote control the workstations in those containers would require you to make ten different rights assignments for that user. Likewise, taking away those rights once given would require you to revoke ten separate rights assignments. Now imagine the burden if you had fifty, or a hundred, or five hundred containers that held workstations! With an Organizational Role or Group, granting or revoking remote control rights does not require any manual rights assignment.

[Back to Top]

Using a Suggested NDS Tree Design: Workstation Containers
As described in the preceding section, the Inherited Rights Filter method for limiting remote control access to a subset of administrative users has the drawback of limiting more than just remote control privileges. One easy way to avoid this effect is to design your Z.E.N.works roll- out to include containers to hold Workstation objects and nothing else. For instance, you might create an Organizational Unit object named "Workstations" in each container that has Users. You could set the Workstation Import Policy to create workstations in the "Workstations" container relative to the User Container. Another option, depending on your environment, might be to create one workstation container for each partition or one for the entire tree.

In any case, if you have placed Workstation objects in containers by themselves you can limit the remote control rights to administrative users on those containers, as described above, without limiting their rights to objects other than Workstation objects.

Conclusion
An organization based on NDS rights has tremendous flexibility and power in customizing its Z.E.N.works Remote Control security model. With a little administrative effort up front, granting and revoking rights to remote control can be established and will then require very little maintenance. This is especially true if Organizational Roles or Groups and Workstation containers are used. The availability of inherited specific attribute rights in NetWare 5 might be advantageous in your environment. Of course, each organization will have different needs. Some combination of our suggestions will probably provide you with a Z.E.N.works Remote Control security architecture that will satisfy your requirements.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell