Rights Assignment Recommendations: Part 2
Articles and Tips: article
Research Engineer
Novell AppNotes Magazine
jfischer@novell.com
01 Feb 2003
Last month we discussed how to easily provide the appropriate rights to network users so that rights administration does not become a large burden. We also discussed recommendations to properly administer rights on the network.
This month, we'll talk about how to easily provide administrative rights on the network. Our discussion begins by defining two classifications of network administration: Centralized and Decentralized.
Two Classes of Network Administration
Centralized administration occurs when network control falls onto a limited number of people. The small group of network administrators controls all administration tasks for the entire network and the entire eDirectory tree. This type of network administration is found most often in smaller companies because it is more cost effective to employ a handful of network engineers that control the entire network.
The decentralized network administration model is normally used by larger companies where it is not possible for a small number of people to control the entire network. The decentralizeddecentralized model allows for more control to be spread out among more people within the organization. Many people, even several teams within a company, perform network administration tasks.
The ideal example of this model is a company help desk. Most companies now employ a group of help desk technicians to help monitor the network and fix computer problems for network users. In large companies, the help desk could consist of 20 people or more in order to handle the large volume of calls.
From a network administration point of view, you may not want each of these people to have control over the entire network. You can give them sufficient rights to handle specific tasks or control one section of the eDirectory tree.
Dividing control of the entire network to many people introduces several risks into the administration of your network. Security holes can occur intentionally or unintentionally simply because many people are controlling the network. Also, documenting changes to the network becomes very difficult to control and can lead to a disorganized network.
Centralized network administration is easy to implement. One person, or a small team of network administrators, has Supervisor rights to the entire tree and each person controls the entire network.
Decentralized administration requires more careful planning to set up and administer. Here are a few suggestions to leverage eDirectory to implement a decentralized administration approach.
Container Administrators.
A common implementation of the decentralized administrator is to use container administrators. You implement this by creating an eDirectory group object and by assigning the group object the rights to administrator that section of the tree.
For example, you can create the container_admins group inside an organizational unit (OU) and give the group rights to administer that container and any OUs underneath that section of the tree. Users who will be responsible for administering this section of the tree are made members of the group.
Here's how to create a container administrator group:
Through the ConsoleOne utility, right-click on an Organizational Unit (OU) object.
Select New > Group.
In the New Group dialog, enter Container_Admins as the name of the group.
Click OK.
Right-click the container where you created the group.
Select Trustees of this Object.
Click Add Trustee.
Browse to and select the Container_Admins group.
Click OK.
In the Rights Assigned to box, select Entry Rights and make sure the Supervisor and Inheritable boxes are checked.
Highlight Attribute rights and select Supervisor and Inheritable.
Click OK.
Click OK.
Now, any users you add as members of the Container_Admins group will have the necessary rights to administer to that container and to any of its subcontainers. This takes the administrative burden for that container away from the eDirectory tree admin and provides administrative functions for more people.
Organizational Role.
An organizational role object is another useful eDirectory object that can help you distribute the administrative functions within a network. An organizational role object is similar to a group object, in that you can assign rights to the object and any members of the organizational role have those rights. It differs from a group object in that it does not have as many properties to assign and does not have a login script that can execute for the object.
An organizational role object should be used when all you need the role to perform is rights administration tasks. A group object has a few more capabilities. A help desk role could be a good use for an organizational role object. The organizational role object could be assigned the appropriate rights.
Members of the organizational role object are called occupants. Just as with a group object, when occupants are assigned to the organizational role, they have the assigned rights of the object. Since many help desk roles have a high employee turnover rate, an organizational role could be an ideal way to manage the help desk function.
Administrative Assistant.
An administrative assistant could also be part of an organizational role object. You can assign the assistant to update the properties for the employees on their assigned team. By decentralizing this function, the container administrator would only have to create the user object and to assign rights without assigning user property information, such as title, department, location, job function and other properties. The administrative assistant could do this.
The administrative assistant could be made an occupant of an organizational role object that has been assigned rights to certain properties within a specified container. Here's how to create an organizational role object in ConsoleOne and how to assign it property rights to a container.
Right-click on a container object such as an organizational unit where you want to create the Role.
Select New > Object.
In the New Object box, select Organizational Role and click OK.
Assign a name for the role such as Assistants.
Right click the container where you created the Organizational Role.
Select Trustees of this object.
Click Add Trustee.
Browse to and select the Assistants object.
Click OK.
Click Add Property.
Select a property such as Description and check the Supervisor and Inheritable rights boxes.
Repeat steps 10 and 11 for other properties that you want to add.
Click OK.
Click OK.
Now, the organizational role object you created has rights to the properties you specified in its ACL for the container.
The key to an efficient decentralized network is to have clearly defined roles and responsibilities within the network. Each administration piece should be well defined, and documented, and each administrative user should have sufficient rights to perform this role without an abundance of rights.
Role Based Services
A new feature of eDirectory is the addition of Role Based Services (RBS). This service allows you to easily distribute the administrative load across administrative users. Essentially, RBS provides a different mechanism to grant necessary administrative rights to the appropriate users. This mechanism is different than the rights assignments given through groups, containers, and organizational roles.
Figure 1 illustrates the architecture of RBS.
How tasks are assigned to roles and how users are associated with those roles
A role is defined in the eDirectory tree. Each role has tasks associated with it. A task is an eDirectory task, such as creating users or other tasks that can be associated with the role.
For example, if the role were a Novell Licensing Administration role, then the tasks associated with the role would be to add/delete licenses from the tree. A user can be associated with the role and receive rights to perform the tasks assigned to the role. This provides an easy way to decentralize and efficiently manage administrative functions on the network.
In order to use RBS, the eDirectory schema must be extended to allow for RBS objects in the tree. Here's how to extend the eDirectory schema through ConsoleOne:
Select a tree object in Console One.
Click Tools > Install.
Follow the instructions in the wizard to complete the installation.
Select Role Based Services.
When RBS is installed in the tree, a Role Based Collection object is added to the tree along with several already-created roles. These roles have tasks associated with them. The default roles are:
DHCP Management
DNS Management
eDirectory Administration
iPrint Management
License Management
Users can be quickly associated with one of these roles, or you can create a custom role and authorize users to perform the tasks outlined in the role.
The iManager Tool
iManager is a new tool with NetWare 6. It is a web-based administration application that uses these roles to define who has access to perform each administrative function. To access iManager, open a browser on a workstation and in the address bar, enter
https://server_dns_name:2200
and select iManager from the list. You will be prompted for a login and, depending on the credentials of your user object, you will see the roles that have been granted to your user object.
Figure 2 illustrates the front page of iManager along with the roles to which your user object has been assigned. Each role can be expanded to see the tasks that have been assigned to this role. You will only see the roles that you have been assigned to access.
The front page of iManager showing your assigned roles
iManager is a nice tool to use in a decentralized administration environment because the tool is based on which roles have been defined. It is easy to see the administration roles that have been defined and the tasks associated with those roles, because iManager only shows the roles associated with the logged-in user. The user does not see other functions than what he or she has been given access to.
A role is defined as a group of administrative functions that a user can perform to manage the network. eDirectory pre-installs several roles, and other roles can be created to suit your network environment. For example, if it is useful for your network to have a help desk role to administer user objects, you could create such a role and it would only have sufficient rights to handle user objects in a given context of the eDirectory tree.
Follow these steps to create a new role in the iManager tool:
Click the configure button on the top navigation bar (see Figure 3).
The configuration button in iManager
Expand Role Management.
Click Create Role.
Enter a name such as Help Desk.
Browse to and select the RBS object.
Click Next.
Assign the tasks you want associated with the role by double-clicking them in the All Tasks window.
Browse to and select a person or group to be assigned to this role by clicking the browse button next to the Name field.
Browse to and select a context for this role to be active by clicking the browse button next to the Scope field.
Click Next.
Verify the information and click Finish.
Click OK.
It may be necessary to expand or reduce the responsibilities of a role that has already been created in the tree. For example, if you have a role that manages passwords and now you need that role to create user objects as well, you can add a new task to the role to also create objects in the eDirectory tree. In order to grant additional tasks or remove tasks from a role, you should choose the modify role link. Follow these steps to modify a role that has already been created:
Under Role Management, click Modify Role.
Scroll through the list of roles to find the role you want to modify.
Select the icon to modify the tasks or users that have access to the role.
Make the necessary changes to the role and click OK.
Role based administration can be an effective way to balance administrative rights in the organization. A role can grant the user the necessary rights to perform the administrative functions they need. It also allows for the administrator to more easily distribute rights and/or assignments without them becoming a burden.
Conclusion
In this month's article, we talked about how to provide decentralized network administration functions. We discussed several ways to facilitate the distribution of rights among the administrative staff. We also looked at RBS and how to create a new role in iManager.
* 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.