Empower support staff without sacrificing control
As an organization grows, so do the routine IT systems maintenance and administrative tasks required to keep customers satisfied and the network humming. If your company has ever experienced a serious hiring phase, you're aware of the work each new employee creates for the IT staff: a new account, a new profile and logon script, server-based storage space, access controls for applications and data, and, possibly, remote access capabilities. As printers proliferate throughout your enterprise, a myriad of printing problems flood the Help desk on a daily basis.
As networks expand and provide more resources, the load on the IT support staff rapidly increases—2000 users accessing 500 public resources produces more than 1 million potential support requests. Even a large IT staff can't manage this level of complexity in a timely and effective manner. Fortunately, Windows 2000 provides the much-needed ability to delegate routine management and support tasks throughout the enterprise. To successfully leverage the delegation features of Active Directory (AD), you first define organizational units (OUs), then identify the tasks you want to delegate and add staff members who are responsible for distributed management and maintenance. After this infrastructure is in place, you can run the AD Delegation of Control Wizard to quickly delegate the permissions and rights each group needs to carry out its assigned management activities.
The Power of OUs
An OU is a collection of AD objects, such as users, groups, computers, printers, and file shares, that you want to manage as one entity. All the objects in an OU must belong to the same domain. An OU is the smallest unit to which you can delegate administrative and maintenance tasks. (The larger structures that you can delegate to are sites and domains.) Win2K represents OUs as directory container objects, and each OU appears as a folder in the Active Directory Users and Computers utility.
If you're designing a Win2K enterprise, you've probably debated about how to partition your company into OUs. If you haven't yet started your AD design, allocate a significant block of time to planning your OU structure to leverage Win2K's delegation capabilities and distribute the support workload. The best OU designs group people and systems to expedite management, maintenance, and efficient user support. Delegating administrative control of each OU to groups or individuals empowers local and remote staff members to manage part or all of their operation.
The specifics of OU planning are beyond the scope of this article. In short, you can follow one of three main approaches to defining OUs: You can create them based on location, business unit, or job or area of responsibility (or on any combination of these approaches that reflects the best method for managing your network). A small company might have only one OU; a large international business might create an OU for each geographic location or independent business partner. To create OUs, you use the Administrative Tools' Active Directory Users and Computers utility or the equivalent Microsoft Management Console (MMC) snap-in.
For more information about OU planning, see Chapter 8, "Designing the Active Directory Structure," of the "Windows 2000 Deployment Planning Guide" in the Microsoft Windows 2000 Server Resource Kit. You can also download the deployment planning guide from http://
www.microsoft.com/windows2000/
library/resources/reskit/dpg/default.asp. (In the online version of the resource kit, which is more current than the printed version, Chapter 9 is the "Active Directory Planning Guide.")
Delegation and AD Object Security
Win2K has a granular approach to object administration. You delegate control of an object to an individual or group in two stages. First, you can allow (enable) or deny (disable) the right to create or delete a specific AD object. Second, you can grant or deny the right to modify any one or all of an object's attributes. Win2K manages security for object creation and deletion independently from modification of object attributes, so you can grant an individual or group the right to modify an object without letting the same individual or group create or delete the object. When you allow or deny object permissions, all subordinate objects inherit these permissions by default.
Let's explore some of the ways you can delegate management of user account objects. You can delegate the authority to create and delete user objects (i.e., user accounts). This functionality lets you permit a remote office to create and delete accounts for its OU autonomously. For example, you can delegate the authority to create and delete user objects to the human resources (HR) departments in your remote office OUs. You can delegate the right to modify all the attributes of a user account or only the ability to modify one attribute, such as a user's password or ZIP code. To make delegation even more complex, perhaps unnecessarily so, you can let one individual or group modify a user's password and permit another individual or group to modify only a user's contact information. These security concepts apply equally to all AD objects, be they computers, file shares, printers, OUs, sites, or domains.
Win2K implements the tasks you permit or deny as access control entries (ACEs) in an object's ACL. To give you a sense of Win2K's fine-grained control, let's look at user and group objects' permissions. A user object has four unique permissions: Change Password, Receive As, Reset Password, and Send As. A group object has only one unique permission: Send To. User and group objects share the following common permissions: Full Control, List Contents, Read All Properties, Write All Properties, Delete, Delete Subtree, Read Permissions, Modify Permissions, Modify Owner, All Validated Writes, All Extended Rights, Create All Child Objects, Delete All Child Objects, and Add/Remove Self As Member.
Win2K represents each of these permissions separately, so you can grant only one or a combination of permissions to manipulate an object. This granularity lets you safely delegate only the desired administrative tasks to individuals in your organization. You no longer need to disseminate the Administrator's password, so you can keep master control of the network in the hands of only a few staff members.
What Can You Delegate?
As you consider your OU design, you will benefit from identifying the tasks you want to delegate. As you proceed with an AD implementation, you'll know how many OUs to create, the number and type of tasks you expect to delegate in each OU, and the number of administrative groups you need to support your distributed network management model.
If your AD implementation includes OUs that operate fairly independently from the central office, you might want to empower local administrators to manage all aspects of their network operation. This entitlement might include creating and deleting new user and group objects, full control over groups and group membership, and group policy and group policy link management. If your organization has a centralized corporate Help desk, you might want to give the Level 1 Help desk group the authority to reset user and computer account passwords and let the Level 2 Help desk group reset user and computer account passwords, add and remove group members, and create or manage shares for user profiles and home directories.
Using the Delegation Wizard at Wildwood
Without an in-depth understanding of the complex Win2K security model, you might easily become lost trying to delegate control by manually creating and modifying an object's ACL. You would have to thoroughly understand every permission that applies to every AD object—no small task considering the range of objects and attributes available. The Delegation of Control Wizard makes delegation much easier.