The Administrator Shortcut Guide to Active Directory Security Chapter 3

{LANG_NAVORIGIN} Operating System Microsoft
By: Derek Melber, Dave Kearns, and Beth Sheresh, 04/14/2005



[Editor’s Note: The following excerpt is from Chapter 3 of the free eBook The Administrator Shortcut Guide to Active Directory Security (Realtimepublishers.com) written by Derek Melber, Dave Kearns, and Beth Sheresh and available from a link at http://cc.realtimepublishers.com/portal.aspx?pubid=289.]

So far, this guide has provided an introduction to a directory service as well as many of the security considerations that you must manage to keep all objects secure. In addition, we have explored Microsoft AD, with all of its security control mechanisms. You should have a good understanding of the AD infrastructure areas that will require the most attention in order to protect your assets. The assets that need to be protected include user accounts, group accounts, data files, databases, and OS files.

In the previous chapter, we discussed the various methods that administrators have at their disposal to control these AD assets. We focused much of the discussion on delegation of administration, which allows administrators to offload many routine and mundane administrative tasks onto junior administrators, Help desk workers, and other employees of the company. GPOs are of particular interest for delegation, as they enable administrators to control the ability to create, link, edit, and view GPOs.

Before we dive into who will manage GPOs—we will tackle the details of controlling the management of GPOs in the next chapter—we must first establish a foundation of knowledge by exploring the basics of GPOs. One of the most important aspects of a GPO is its ability to control security for user and computer accounts in the domain. A GPO has almost 1000 policy settings. The security settings are spread throughout the structure of the GPO, so simply finding a specific GPO setting can be a daunting task. This chapter will lay out the structure of a GPO, indicating where the essential security policies reside, allowing you to efficiently find the settings that you need.

Once you’re familiar with how a GPO is structured, it is important to understand how the GPOs interact with one another. This interaction follows routine inheritance rules, which is an aspect of GPOs that can be very frustrating as a result of the complexity. We will explore when, why, and how to use the tools that control inheritance of GPOs, tackling terms such as no override, block policy inheritance, security group filtering, and Windows Management Instrumentation (WMI) filtering.

As in the previous chapter, we will stress the point that AD, security, and GPOs must be designed. Failing to consider security and GPOs during the design of AD almost ensures disaster. The reason is the complexity that results from GPO implementation. Let’s begin by defining policy-based security.

Policy-Based Security

When you think about policy-based security, you most likely consider terms such as consistency, reliability, uniformity, and standardization. In addition to these, you can also throw in customization, mandatory, and absolute. Policy-based security is provided through GPOs. Such has not always been the case with Microsoft OSs, but policy-based security is standard with Windows AD. When the first domain controller is installed in the first domain, tree, and forest, GPO security is in control. Even the default GPOs provide the structure for policy-based security, in the following manner:

• Consistency—The structure of a GPO provides consistency for all security settings by the way that the GPOs are applied. The intent of GPOs is to ensure that every time a computer starts or a user logs on, security is applied the same every time. This consistency is accomplished during authentication with the domain controllers, which are in control of the AD infrastructure. As long as the computer is a member of the domain and a user account from the domain is used for authentication, the security settings will always be applied.
• Reliability—Because GPOs are controlled by AD, DNS, and authentication, they are out of the hands of the user at logon. This setup ensures a reliable application of the GPOs, which provides a secure environment that is out of the control of any user or computer.
• Uniformity—GPOs are applied to OUs, the domain, or sites. This application typically will affect multiple objects (either user or computer accounts). Each object that is affected by the GPO will receive the same settings by default. This application provides for an easy way to ensure that multiple objects have uniform security settings applied to them.
• Standardization—The security settings that are built-in to GPOs are the common security settings that any environment will require. This commonality provides a standard that all GPOs begin with. If such were not the case, each GPO might have different settings and options, resulting in a confusing and irregular application of security throughout the domain.
• Customization—GPOs provide an almost endless interface for custom policy and security settings. From registry values to software installation, GPOs provide a method to customize settings for target computers. In addition, WMI filters allow GPOs to target computers with specific credentials for hardware, OSs, configurations, and more.
• Mandatory—When a GPO is applied to a target object, the setting is mandatory for that object. In most cases, the local GUI grays out, ensuring that it cannot be changed by the local user. If the setting is enabled to be changed locally, there are methods that enable you to change those settings back to the GPO settings as often as every couple of seconds.
• Absolute—With the ability for a GPO to mandate policy and security settings, then force the settings down to the target object, the GPO has the final, absolute say on any setting. This is comforting from an administrative standpoint, because many manual settings are only suggestive, allowing the local user to make changes that can only be changed back with another administrative manual alteration.

What Group Policies Control

If you are new to AD and GPOs, you might be wondering: What does a GPO control? First, consider Figure 3.1.


Figure 3.1: The Group Policy Editor showing the format of a typical GPO.

This figure represents the image that you should always conjure when you are asked what a GPO controls. The reason that this image is important is that it clearly answers the question. Notice that a GPO has two sections: Computer Configuration and User Configuration. These are the only two objects that GPOs can affect: computer and user accounts.

The next thing to consider when trying to answer this question is which object is being affected by the GPO policy that is configured. For this answer, you can also refer to Figure 3.1. If the policy that you set is under User Configuration, the policy will only affect user accounts. A policy that is set under the User Configuration section of the GPO can’t affect a computer account. The same is true for the Computer Configuration section and policies in the GPO. These can only affect computer accounts.

If a GPO can only affect computer and user accounts, then what about the other objects? Can a GPO apply to an OU? Not exactly. An OU is an object that contains other objects, such as user and computer accounts. GPOs are linked to OUs; GPOs don’t apply to OUs. A GPO linked to an OU will have an affect on all of the computer and user accounts in the OU and child OUs, but not to the OU itself. The same case can be made for the domain node and sites. GPOs are linked to these objects, they don’t apply to these objects.

To make sure that this is clear, we will explore scenarios that will help you remember what GPOs apply to. All of the following scenarios will use the OU structure that Figure 3.2 shows.


Figure 3.2: OU structure for scenarios.

All of the scenarios will also use the following GPOs and links listed in Table 3.1.

GPO Name	Linked To	GPO Policy	Section
No Run Option	Users OU	Remove Run menu from Start Menu	User Configuration
Legal Notice	Client_comps	Legal Notice Caption Legal Notice Text	Computer Configuration

Table 3.1: GPOs used in the example scenarios.

The scenarios will use the accounts and the account locations that Table 3.2 shows.

Account name	Account type	Location
TomT	User	Users OU
BettyF	User	Users OU
JoeB	User	Admin OU
Tom_PC	Computer	Client_comps OU
Betty_PC	Computer	Client_comps OU
Server4	Computer	Servers OU
Employees	Group	Users OU

Table 3.2: User and group accounts used in the scenarios.

Scenario 1: What will Tom see if he logs onto his own computer?
     Answer: He will see the Legal Notice and won’t have the run command.

Scenario 2: What will Betty see if she logs onto Toms’ computer?
     Answer: She will see the Legal Notice and won’t have the run command.

Scenario 3: What will Joe see if he logs onto Betty’s’ computer?
     Answer: He will see the Legal Notice and will have the run command.

Scenario 4: What will Tom see if he logs onto Server4?
     Answer: He will not see a Legal Notice and won’t have the run command.

Scenario 5: What will Betty see if she is a member of the Employees group and logs onto Server4?
     Answer: She will not see a Legal Notice and won’t have the run command.

Scenario 5: What will Joe see if he is a member of the Employees group and logs onto Server4?
     Answer: He will not see a Legal Notice and will have the run command.

>From these example scenarios, you can see clearly that the location of the user and computer accounts are essential and the membership in groups has no bearing with a default configuration of GPOs.
















Your IP address will be sent with this e-mail

From e-mail to e-mail