70-240 in 15 minutes a week: Delegation of Administrative Control and Working with Group Policy

70-240 in 15 minutes a week: Delegation of Administrative Control and Working with Group Policy


June 11, 2001

by Dan DiNicolo
http://www.win2000trainer.com

Welcome to article number 16 in my 70-240 in 15 minutes a week series. This week's article covers Delegation of Administrative Control under Active Directory, as well as part 1 of Implementing Group Policy. This includes a look at ACLs, object ownership and inheritance, as well as group policy object creation and application. This article again falls into the Active Directory portion of the series. Next week I'll continue with the second part of the group policy discussion, as well as a look at software management, and multiple tree forests and external trusts.

The material to be covered in the article includes:

- Active Directory object security overview
- Object permissions and ACLs
- Object ownership and inheritance
- Creating and customizing administrative tools
- Group Policy overview 


Active Directory Object Security Overview

A great way to begin looking at object security in the Active Directory environment is with an overview of the different security elements that you must be familiar with. Many of the concepts covered here were first introduced in earlier articles, though with much less detail. 

The first thing you'll need to remember when taking a look at object security is the concept of a security principal. In most simple terms, a security principal is an account type to which permissions can be assigned. This includes users, security groups, or computer accounts, which are characterized by the fact that they have a security identifier (SID) assigned to them. Every security principal is assigned a SID, made up of a domain identifier (also referred to as a SID), and a relative identifier (RID), the combination of which uniquely identifies the principal. 

When a user attempts to access a resource (such as another object in Active Directory) the applicable SIDs (for the user, groups he/she is a part of, and the associated computer account) are compared to the object's access control list (ACL). The ACL lists who can access the object and to what extent, as shown below for the win2000trainer.com domain object:

ACLs for Active Directory objects (such as users, groups, computers, etc) are very similar to those you might already be familiar with, such as those associated with NTFS permission assignment. Note, however, that the actual permissions found in the list (called access control entries, or ACEs) can be very different depending on the object type. 

There are two types of ACL that you should be aware of - discretionary access control lists (DALCs) and system access control lists (SACLs). A DACL is the list of permissions that security principals have on an object (as shown in the previous screen shot), while a SACL is the list of entries set up for auditing purposes on an object, as shown below:

You should also be aware of the concept of an access token. The access token contains the user and group SIDs, and is created when a user logs on to the domain. This token is subsequently compared to ACLs whenever a user attempts to access a network resource. The token is created with information provided by the domain controller that authenticates the user (user SID as well as SIDs for domain local and global group membership) as well as a global catalog server (which provides universal group SIDs). Object Permissions and ACLs

Although the concepts of permissions and ACLs were just discussed, you'll need to know a little more about them. First of all, every object in Active Directory has an associated ACL. This controls who can do what to an object. By default, the ACL associated with an object is hidden, but can be viewed in the object's properties after choosing to view Advanced Features from the View menu item in Active Directory Users and Computers:

After this has been done, access the ACL from the security tab in the object's properties. The list of ACEs will be different based on the type of object, and will control what users can and cannot do with respect to that object. As a best practice, you should note that it is generally not a good idea to change the ACL of individual objects. Instead, change the ACL on a parent object, and by default these changes will be inherited by all child objects. 

You will note that a DACL has two main columns in which ACEs can be modified - Allow and Deny. The rule is simple - the effective permissions that will apply to a user when accessing an object are the combination of all permissions that apply to the user, but an explicit deny always overrides an allow. The deny permissions should be used for special cases, such as when you want to give all users in the Help Desk group the ability to change object information for user accounts, but need to explicitly deny a single user who is a member of that group the same privilege.

Note also that the ACL that you see when viewing the permissions on an object is the standard list. If you click on the Advanced button, you are presented with a list of users and groups and their associated permissions, as shown below:

By choosing an entry from the list and then choosing View/Edit, you can access an even more granular level of permissions for the object, which includes controlling how inheritance settings will be applied to the object by default, as shown below.

Object Ownership and Inheritance

By default, objects are owned by the person who creates them. Who can create objects is controlled by the ACL of the object in which they are being created. For example, a user needs appropriate permissions on a container (such as an OU) in which they want to create a user object. In order to find out who owns an object, access the Security tab of an object, and then click the Advanced button. The owner tab will show you the current owner of the object, and give you choices as to who is allowed to take ownership of the object. Remember that much like NTFS ownership, ownership can only be taken, and not given. 

One of the reasons all of this is important is because Active Directory allows us a much more granular level of possible administrative control if we choose to take it. That is, we can delegate control of objects to other users or groups without giving them more control than we want to. For example, I could place all users in an OU called Company Users, and then delegate the ability to reset passwords to all Help Desk users. This allows members of the Help Desk group to Reset passwords, but not change anything else about a user's account. By the same token, I could delegate full control over the HR OU to a single user who is responsible for controlling HR resources. This user could then create users, change properties, and so forth, but only within the HR OU. 

Delegation can be controlled by directly editing the DACL associated with the object you wish to delegate and changing permissions, but this can be cumbersome and confusing. Instead, Active Directory Users and Computers provides the ability to run the Delegation of Control Wizard, a tool which provides a simplified way of delegating control according to common administrative needs. To run the tool, right-click on the appropriate object (an OU for example) and choose Delegate Control.

The Delegation of Control Wizard starts, allowing you to choosing to whom you wish to delegate control. I have chosen to delegate control of the Company Users OU to Help Desk staff, as shown below:

When I click next, it will ask what type of control I wish to delegate. This screen focuses on the most common task-based delegations, as shown below:

However, if I were to choose to create a custom task, I could give a user or group full control of the OU, or get even more granular, allowing a group the ability to only read and change the postal code properties of an account (shown in second screen shot below). You also have to choose whether you wish to grant the ability to control all objects, or only a particular type of object, as shown directly below:

Of course, the DACL of the object (and potentially child objects) will automatically change based on the settings you choose with the wizard. The wizard is highly recommended as the much simpler way of delegating administrative control in Active Directory. Remember that by default any permission that gets set on an object will be inherited by all child objects. If you wish to have a child object not inherit the permissions, you can simply uncheck the Allow inheritable permissions parent to propagate to this object' check box on the Security tab. You will be given the choice of either copying existing permissions to the object directly, or removing all associated permissions from the ACL.  Creating and Customizing Administrative Tools

As mentioned earlier in the series, it is possible to create custom MMC consoles that restrict the administrative tools that a user has access to. For example, you could create a custom tool that includes access to AD Users and Computers as well as Event Viewer, as shown below:

To do this, open an empty MMC window (mmc.exe from Run), choose Add/Remove Snap-ins from the Console menu item, and then add the appropriate tools. In saving the tool, there are two major options available, Author Mode and User Mode. In User Mode, the user cannot make changes to the console (which is good if you want a consistent environment). In Author mode, a user could add or remove snap-ins, for example. The mode should be selected prior to saving the tool, using the Options setting under the Console menu item.

Note that a user can still right-click a saved console and open it in Author mode by default. This can be restricted via group policy, but can also be easily accomplished by only giving the user the NTFS read permission to the file. Note that the consoles you create do not actually contain the tools. In order for a user to access the administrative tools with the console, Adminpak.msi (the installer for the administrative tools) must be installed on their machines. After you have created and customized MMC consoles, they can easily be distributed via group policy or as email attachments. 

Another option that is a little different than creating custom MMC consoles is creating what are called Taskpads. These are still administrative consoles, albeit simplified versions. The idea is that you might create Taskpads for users with limited administrative knowledge, such as a junior staff member who you want to create computer accounts for you. Taskpads are created by right clicking the appropriate object (such as an OU) within the MMC console and choosing New Taskpad View (the interface is really not consistent - you may need to choose the 'New Windows from here' option first). A wizard will walk you through the Taskpad and task creation process. Taskpads can also be used to launch scripts such as batch files through the Taskpad interface, which is useful if you've scripted a complex task that you want a less experience user to be able to run. An example of a simple Taskpad is shown below:

Group Policy Overview

As described in previous articles, group policy in Active Directory allows us a great deal of flexibility in terms of how users and their Windows 2000 computing environment is controlled and managed. Things that can be done with group policy include software distribution, updating settings such as Internet Explorer's proxy server settings, locking people out of Control Panel, and so forth. It is worth investigating the hundreds of settings that can be configured in group policy, but unnecessary to remember all (or even most) of them. However, be sure to at least familiarize yourself with the different possible settings and why they exist. For a good overview of all group policy settings and what they mean, you can either check each individual setting, or take a look at the whitepaper (the grouppolwp.doc file) found here


The main reason for the existence of group policy is to be able to control the user environment and make changes with the least amount of administrative effort. For example, I could remove the My Network Places icon from certain user desktops by setting up a group policy object applied to an OU. When users whose account exists within that OU would log on, the icon would not be available for them, regardless of what system they logged on to within the Active Directory forest (unless a conflicting policy had also been configured at another level, as we'll discuss in a moment).

Although the idea behind group policy settings is pretty straightforward, it can be confusing to configure them correctly, since settings can be made at many different levels. Group policy objects (GPOs) can be applied at the following levels:

Local
Site
Domain 
OU (and sub-OU)

The order listed above is also the order in which policy settings are applied. What that means is that policy settings at all levels merge with one another (with exceptions when Block Inheritance and No Override are used, to be discussed later). As such, if a local group policy says that I lose the Run command, site group policy says I lose access to Control Panel, domain group policy says my desktop wallpaper is the corporate logo, and the OU policy redirects my My Documents folder, then when I log on all of those things will happen. However, in the event that a conflict exists (for example the site policy takes away Run, while the OU policy says it should be available), then the lower-level policy settings take precedence. 

Local GPOs are stored on the local system, and only one can exist on a Windows 2000 machine. All other GPOs - those applied to sites, domains, and OUs - are stored in Active Directory. Actually, a GPO is made up of two parts. The group policy container is stored in the AD database (this contains most settings), while larger 'extras' such as logon scripts are stored in the group policy template, which is stored within the Sysvol folder on a domain controller. The path to where policy templates are stored is %systemroot%\SYSVOL\sysvol\domain_name\Policies, where the folder name for the template is the globally unique identifier (GUID) of the GPO. An example of the contents of this folder is shown below:

Group policy objects can be created by using the Group Policy MMC snap-in, but are usually created from within Active Directory Users and Computers. Remember that GPOs can only be configured and applied to the local system, sites, domains, and OUs. As such, you cannot be applied to the default built-in containers, such as Users or Computers. To create a new group policy object, right-click the appropriate container in AD Users and Computers and access the Group Policy tab. To create a new policy, click New, and give the policy a name, as I have below:

As the screen suggests, you can also add an existing policy. This is useful, especially if you wanted to link the same GPO to many OUs that required identical settings. After you have named the OU, you need to click on Edit to actually configure the policy settings:

Note that settings fall into two major areas, Computer Configuration and User Configuration. Settings in the top portion apply to Computer Accounts and settings in the bottom apply to User Accounts. As such, if your computer account were in an OU called Desktops, the computer configuration settings would be applied according to the GPO settings from that OU. By the same token, if your user account were in the Sales OU, user configuration settings would be applied from that OU. If either part of the OU is not being configured in a given GPO, you should disable that portion, which will speed up group policy processing. This is done by clicking the Properties button on the Group Policy tab and configuring the settings below:

Note that multiple GPOs may exist linked to the same container. For example, consider the screen below, where 3 different GPOs have been linked to the Company Users OU:

In this situation, it is possible that conflicting settings exist in the policies. When multiple GPOs exist at the same level, the policies are applied from bottom to top. That is, policies at the bottom of the list are applied before those above. The settings applied later always take precedence over those applied earlier. In the example above, User Policy 3 would be applied first, followed by User Policy 2, followed by User Policy. As such, if a site policy and domain policy also existed, the order of application would be:

Site
Domain
User Policy 3
User Policy 2
User Policy

Note that if any policies were applied to sub-OUs that existed within the Company Users OU, these would be applied after those listed above.

Since these topics are exceptionally involved, I am going to stop there for this week and expand on the remaining elements of Group Policy in next week's article, which include GPO linking, delegation, inheritance settings, and filtering. Next week's article will also include a look at distributing software via group policy, as well as implementing multiple domain forests and external trusts. Thanks again for supporting the series. I look forward to you questions and comments. Please note that I no longer answer technical questions by email, instead requiring that all technical questions be posted to my message board, where others will benefit from the answers as well. Best of luck with your studies this week.

Dan
dan@win2000trainer.com
http://www.win2000trainer.com