Options for Delegating Control
Users do not usually have the ability to view OUs. They use the Global Catalog to find objects that give them access to the resources within the network. OUs are designed to make administration easier for the administrative staff within the company. Keep this in mind when you are creating your OU structure. Build it with administration as the top priority; you can address other issues later.
 |
Jami is an administrator for the Accounting and Human Resources Divisions for her company. When the OU design was decided upon, she became the OU owner for the two OU trees: Accounting and HR. The HR department has been concerned about other departments having access to their files. After she reassured them that NTFS permissions were set correctly within the filesystem and that the file shares were created as hidden shares, they were pleased, but they wanted to make sure that users outside of their area could not see their file shares when performing a search within Active Directory.
To keep the all affected parties happy, Jami created a child OU under the HR OU and set the permissions on the OU so that only the HR personnel who needed to see the shared folders had the List Contents permission, along with any other permission they needed based on their account status. The shared folders were published to this OU. After testing the design, Jami was able to prove to the HR director that users from other divisions could not search and locate the folder.
| |
Because so much power can be wielded when a user is allowed to become an OU owner, they should be trained on the proper methods of delegation. This means that anyone who is allowed to delegate control to another user should understand the two methods of delegating permissions ”object-based and task-based ”as well as how inheritance affects the design. If OU owners are not properly trained on how to delegate control, the OU structure may be at a security risk with users who have too much power, or on the opposite extreme, with users who do not have the proper amount of authority to administer the objects they are supposed to control.
The OU owners are responsible for making sure that the appropriate users and groups have the ability to manage the objects they are responsible for. In the following sections, we will look at the options available to make sure those users and groups are properly configured for the access they need.
Understanding Delegation Methods
Object-based delegation grants a user control over an entire object type. Objects within Active Directory include users, groups, computers, OUs, printers, and shared folders. If a user needs to have control over computer accounts, you can use the Delegation of Control Wizard to allow Full Control permission only over computer objects within the OU. You may have another user who administers the User and Group objects within the OU. This level of control can be delegated as well.
Take, for instance, a company that has a remote office that manages its own users and resources but is controlled by the parent company. To keep the staff at the remote location from having too much control within the domain, an OU can be created to host the objects for that location. Then users from the remote office can be identified as the responsible parties and can have control over the objects delegated to them. If one user is responsible for adding new computers and maintaining systems and another is responsible for maintaining the User and Group objects, the Delegation of Control Wizard will allow you to easily set up the permissions required for them to perform their jobs. The Delegation of Control Wizard will only allow you to assign permissions, it will not allow you to revoke those permissions. If you want to revoke the permissions you will have to access the Access Control List on the OU to remove the account or change the permissions granted to the account.
| Note | For more information on how to use the Delegation of Control Wizard within the Active Directory administration tools, see MCSE: Windows Server 2003 Active Directory Planning, Implementation, and Maintenance Study Guide (Sybex, 2003). |
Task-based delegation grants a user the ability to perform specific functions against objects within the OU. Controlling objects at this level is more difficult to manage and maintain, but sometimes you may find it necessary. Take for instance a case where a company has a Help Desk department and one of its job duties is to reset passwords for users. However, you don t want them to modify any of the user properties. If you delegate the ability to work with user objects, the Help Desk personnel will have too much power. Instead, you can delegate the ability to reset passwords at the task level, locking them out of having the ability to affect the objects in any other way.
As mentioned earlier, however, it is much more difficult to manage the permissions granted at the task level than it is the object level. You will need to make sure that you are documenting the groups to which you are delegating permissions. Otherwise, you may find it problematic to try to track down where permissions are applied and troubleshoot access problems. As a best practice, try to design the OU structure so that you can take advantage of object-based delegation as much as possible.
Understanding Account and Resource OUs
In some Windows NT 4 directory service structures, the user accounts and resources are divided up into their own domains, based on the administrative needs of the domain owners. Because the domain is the administrative boundary within NT 4, the user account administrators have control over the account domain. Resource administrators have domains that are made up of the resources they are responsible for maintaining, usually systems that provided database, email, file, and print services, to name a few.
Depending upon the administrative needs of the organization, delegation of the sublevel OUs should follow a few rules:
The OU owner will have full control. The OU owner will have the ability to work with any object within the OU tree for which they are the owner. Once the domain owner delegates full control to the top-level OU for the OU owner, the OU owner will be able to take ownership of any object within that OU tree.
The OU admin can only control objects for which they have been granted permissions. The OU owner should only delegate the ability to work with the object types that the OU admin needs to modify. If the OU admin is an account admin, then only user and/or group object permissions should be granted. If the admin is a resource admin, only the appropriate object type should be delegated to them. OU admins should not have the ability to affect OUs, but only the objects within them.
Account OUs and resource OUs can provide the same functionality that account and resource domains provided under NT 4. Account OUs will hold the user and group accounts that are used when accessing the resources. Resource OUs will host the resources that users will need to access within the domain. These could be computer accounts, file shares, shared folders and contacts. You can build an OU structure that allows the user, group, and resource objects to be separated based on the staff that needs to have administrative control over them.
Let s look at an example of a company that has divided the OU structure based upon locations, with each location having users, and resources having local staff to support them. A domain owner creates an OU for the location Denver and delegates full control and OU ownership to Linda. Linda will be responsible for maintaining the OU hierarchy from this point on, although the domain owners will have the ability to modify and maintain the design if things go wrong. The manager of Information Technology decided that the OU owner accounts will be members of a group created within another container in the domain that the domain owners control. In this case, an OU is created within the OU named OU_Owners. Figure 5.8 shows an example of the design so far.
Figure 5.8: The OU structure after top-level OUs have been created
The Denver location does not have a large body of users and computers. After discussing the current administrative needs of the company, the forest owners decided that all of the users will reside within their own OU, groups will reside within another, and computers will have their own OU also. Appropriately, the OUs are named Users, Groups, and Computers, all located within the Denver OU.
Linda identifies the OU administrators that will be responsible for maintaining the users and groups. She also identifies which users will be responsible for maintaining the systems used at the Denver location. Although all of the objects could reside within the same OUs, there could be reasons why object types should be separated. Reasons could include Group Policy application or administrative control. For this example, we will discuss the implications of administrative control.
| Note | The application of Group Policy will be discussed in Chapter 6. |
The user accounts for Denver are maintained by two Human Resources personnel and three IT staff members, all of whom are located in the Denver office. The HR personnel are responsible for creating and deleting the objects representing the accounts, whereas the IT staff members maintain the objects. The IT staff is also responsible for creating, deleting, and maintaining group accounts within the Denver location. The corporate Help Desk is responsible for resetting passwords for the users if necessary. Once the level of responsibility is identified, Linda creates two groups for maintaining user accounts. The first group she creates is the HR Account Admins group; the second is the IT Account Admins. She creates both of these groups in the Denver OU so that she can maintain them. The Corporate Help Desk group already exists within another OU that is maintained by the forest owners.
To the HR Account Admins group, she delegates the task permissions necessary to create and delete the user object type at the Users OU. She gives the IT Account Admins group the task permissions it needs to perform all actions against the user object type within the Users OU, with the exception of creating or deleting them. And finally, she grants the Corporate Help Desk group the ability to reset the passwords on the user object type.
The only group that needs delegated rights to the Groups OU is the IT Account Admins group. Because they have the ability to create, delete, and manage the groups, they are granted Full Control permissions to the group object type in the Groups OU.
Computer accounts for the Denver location are controlled by a group of four administrators. These administrators are responsible for installing and removing the systems from the network and domain, and also for every aspect of maintaining those systems. Once the administrative need is identified, a group should be created so that permissions can be granted to it. Linda creates the Systems Admin group within the Denver OU so that she can maintain the membership of the group. Then the group is delegated Full Control permissions to the computer object type within the Computers OU. After Linda performs all of these actions, the OU hierarchy looks like the representation seen in Figure 5.9.
Figure 5.9: The OU structure after permissions have been delegated
Understanding Inheritance
Inheritance allows the permissions set at a parent level to be assigned at each child level automatically. The inheritance of object permissions from the parent object to the child object eases some of the administration headaches . Permissions set at the parent level are propagated to the child levels by default. Any object created within an OU will inherit the applicable permissions from the OU. With this being the case, whenever an account is granted permissions at the OU level, all of the child OUs and objects within those OUs inherit the settings.
OU owners have the ability to control all of the objects within their OU tree after the domain owner delegates the appropriate permissions to the top-level OU. In the preceding Denver example, Linda is able to create the child OUs Users, Group, and Computers. After delegating the appropriate permissions to the groups that will administer the objects, she can pretty much take a hands-off approach to the administration of those objects. However, if the need arises, she can still enforce some level of control over the objects. For instance, if an OU admin makes a mistake when creating an object or modifies an object incorrectly, Linda could use her authority to troubleshoot and correct the problem.
There will be occasions when the permissions set at higher levels within Active Directory are not the proper permissions needed at a lower level. If this is the case, inheritance can be blocked, which means that permissions set at the parent level will no longer pass to the child objects. When blocking the inheritance of permissions, the administrator who is initiating the block can choose whether or not to copy the inherited permissions to the object or remove them completely. If the inherited permissions are removed from the object, only the permissions that are explicitly set at the object level will apply. This could restrict an upper-level OU owner, OU administrator, domain owner, or forest owner from being able to perform actions against the object. If this happens, the OU owner, domain owner, or forest owner has the ability to reset the inheritable permissions on the object or objects that were affected.
The blocking of inheritance could be problematic for those users or groups who do not have the power to change the inheritable permissions setting. If inheritance is blocked to objects that a groups needs to have control over, they will not be able to effectively maintain those objects. At this point, the OU owner could step in and change the inheritance on the OU or object, or change the effective permissions on the objects that the group needs to control. Trying to troubleshoot inheritance issues can be time consuming and difficult, so try to limit the amount of inheritance blocking you use within your design.
Creating an OU structure for a brand new design can be challenging. Developing a design that allows the administrative functions to be performed easily is of the utmost priority. However, very few organizations have the option of creating a brand new design. An existing infrastructure probably already exists. If the organization is using a Windows NT 4 domain environment, you need to consider several design options.
EAN: 2147483647
Pages: 159