Configuring Active Directory Server Roles : Administering Active Directory - Planning the OU Structure (part 2) - Delegating Administrative Control

2. Understanding OU Inheritance

When you rearrange OUs within the structure of Active Directory, you can change several settings. When they are moving and reorganizing OUs, systems administrators must pay careful attention to automatic and unforeseen changes in security permissions and other configuration options. By default, OUs inherit the permissions of their new parent container when they are moved.

By using the built-in tools provided with Windows Server 2008 and Active Directory, you can move or copy OUs only within the same domain.

You cannot use the Active Directory Users And Computers tool to move OUs between domains. To do this, use the Active Directory Migration Tool (ADMT) v3.1. This is one of the many Active Directory support tools.

3. Delegating Administrative Control

We already mentioned that OUs are the smallest component within a domain to which administrative permissions and group policies can be assigned by administrators. Now, you'll take a look at specifically how administrative control is set on OUs.

Delegation occurs when a higher security authority assigns permissions to a lesser security authority. As a real-world example, assume that you are the director of IT for a large organization. Instead of doing all of the work yourself, you would probably assign roles and responsibilities to other individuals. For example, if you worked within a multidomain environment, you might make one systems administrator responsible for all operations within the Sales domain and another responsible for the Engineering domain. Similarly, you could assign the permissions for managing all printers and print queues objects within your organization to one individual user while allowing another individual user to manage all security permissions for users and groups.

In this way, you can distribute the various roles and responsibilities of the IT staff throughout the organization. Businesses generally have a division of labor that handles all of the tasks involved in keeping the company's networks humming. Network operating systems (NOSs), however, often make it difficult to assign just the right permissions, or in other words, do not support very granular permission assignments. Sometimes, fine granularity is necessary to ensure that only the right permissions are assigned. A good general rule of thumb is to provide users and administrators the minimum permissions they require to do their jobs. This way you can ensure that accidental, malicious, and otherwise unwanted changes do not occur.

In the world of Active Directory, you use the process of delegation to define responsibilities for OU administrators. As a system administrator, you will be occasionally tasked with having to delegate responsibility to others—you can't do it all, although sometimes some administrators believe that they can. We understand the old IT logic of doing all the tasks yourself for job security, but this can actually make you look worse and not better.

If you do find yourself in a role to delegate, remember that Windows Server 2008 was designed to offer you the ability to do so. In its simplest definition, delegation allows a higher administrative authority to grant specific administrative rights for containers and subtrees to individuals and groups. What this essentially does is eliminate the need for domain administrators with sweeping authority over large segments of the user population. You can break up this control over branches within your tree, within each OU you create.

When you are considering implementing delegation, keep these two main concerns in mind:

Parent-child relationships

The OU hierarchy you create will be very important when you consider the maintainability of security permissions. OUs can exist in a parent-child relationship, which means that permissions and group policies set on OUs higher up in the hierarchy (parents) can interact with objects in lower-level OUs (children). When it comes to delegating permissions, this is extremely important. You can allow child containers to automatically inherit the permissions set on parent containers. For example, if the North America division of your organization contains 12 other OUs, you could delegate permissions to all of them at once (saving time, and reducing the likelihood of human error) by placing security permissions on the North America division. This feature can greatly ease administration, especially in larger organizations, but it is also a reminder of the importance of properly planning the OU structure within a domain.

Inheritance settings

Now that you've seen how you can use parent-child relationships for administration, you should consider inheritance, the process in which child objects take on the permissions of a parent container. When you set permissions on a parent container, all of the child objects are configured to inherit the same permissions. You can override this behavior, however, if business rules do not lend themselves well to inheritance.

4. Applying Group Policies

One of the strengths of the Windows operating system is that it offers users a great deal of power and flexibility. From installing new software to adding device drivers, users can make many changes to their workstation configurations. However, this level of flexibility is also a potential problem. For instance, inexperienced users might inadvertently change settings, causing problems that can require many hours to fix.

In many cases (and especially in business environments), users only require a subset of the complete functionality the operating system provides. In the past, however, the difficulty associated with implementing and managing security and policy settings has led to lax security policies. Some of the reasons for this are technical—it can be very tedious and difficult to implement and manage security restrictions. Other problems have been political—users and management might feel that they should have full permissions on their local machines, despite the potential problems this might cause.

That's where the idea of group policies comes in. Simply defined, group policies are collections of permissions that you can apply to objects within Active Directory. Specifically, Group Policy settings are assigned at the site, domain, and OU levels, and they can apply to user accounts, computer accounts, and groups. Examples of settings that a systems administrator can make using group policies include the following:

• Restricting users from installing new programs

• Disallowing the use of Control Panel

• Limiting choices for display and Desktop settings