Parts of Active Directory Security Policies

The Active Directory security components include forest, site, domain, OUs, computer objects, user objects, group policy objects (GPOs), local computer policy, administrative templates, and security templates.

History of Group Policy

Active Directory group policy was an evolutionary product. Nearly every version of Windows allowed registry edit files to be created manually and applied using various registry tools (such as Reg.exe) or imported using Regedit.exe. Prior to group policy, registry edit files were the most common way to modify Windows security settings, but the registry edit mechanism has two big problems:

• How to distribute

• Registry edits require that the logged on user applying the registry edit file have full administrator permissions to the registry keys being written

The latter issue wasn't a problem in the days before the move to the Windows NT family. In Windows 3.1 and Windows 9x (and Windows ME), every user had full access to all resources. In the Windows NT family, most registry edit files required that the user applying the file have administrator rights. This is the case even today, and entities trying to establish secure environments don't allow their end users to be administrators. This means administrators have to log in locally and apply the registry edit file manually or supply administrator logon credentials using another alternative method. The alternative methods, such as batch or script files, led to their own problems, such as plaintext password use.

Starting with Windows 95, Microsoft provided a way to automate registry-based security using a mechanism called system policy. Using a program called the System Policy Editor (Poledit.exe), administrators could create system policy files and apply them to Windows 9x systems. A similar program was introduced in Windows NT 4.0. System polices could be applied to local users or local machines, but all changes tattooed the registry. Any change made to a user applied globally, affecting all users, although policies could be applied to groups as well. System policy introduced Administrative templates (*.ADM) and many of the settings that we still see in group policy today. If you have Windows 9x machines to manage, review the following resources: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q147381 or www.zisman.ca/poledit. Unfortunately, very few administrators took the opportunity to learn about or use system policies.

In Windows NT Service Pack 4, Microsoft introduced security templates, the System Editor (Secedit.exe), and the Security Configuration Manager (SCM). Security templates could be created manually with a text editor, or graphically using the SCM. SCM introduced many of the same GPO categories we see today, including Local Policy, Account Policy, Restricted Groups, and System Services.

Security templates and SCM proved wildly popular with many enterprise administrators even though a much larger majority of administrators didn't know they existed or didn't see their potential. But many of Microsoft's largest customers did see the value and asked for even more functionality. Microsoft responded with Active Directory GPOs, Administrative templates, and enhanced security template functionality.

The functionality of GPOs introduced in Windows 2000 Active Directory (known as Active Directory 1.0) was better than anything else that existed for any other platform. In order to do a similar thing for Unix or Windows, vendors or administrators would have to create an enormous amount of batch files or scripts. Even today, only a few similar (although less functional) products are available for non-Windows platforms. Active Directory 1.0 was a great leap forward, but many of the enterprise management tools for better managing group policy didn't arrive until Active Directory 2.0 (released in conjunction with Windows Server 2003). It provided even more GPO functionality, GPO filtering, and the Group Policy Management Console (GPMC). Today, Microsoft continues to expand what GPOs can manage and do, and they are adding improved management tools. Many vendors offer add-on companion tools that extend group policy or offer even easier management.

Security Templates

Prior to the GPMC, security templates were the only way to make Windows security settings transportable. Security templates can be imported into GPOs and Local Computer Policy, even though security templates do not have all the security settings that a GPO does (see Figure 15-2).

Figure 15-2

Security templates still allow Windows security settings to be easily portable, and to be applied to non-domain computers. If security templates are applied locally using Secedit.exe or the Security Configuration and Analysis console (see Figure 15-3), the security template settings tattoo the registry. Security templates can be created manually or using the Security Templates console (see Figure 15-4).

Figure 15-3

Figure 15-4

Local Computer Policy

Every Windows 2000 and later computer has a Local Computer Policy. It gets applied to the computer every time the computer starts if it contains settings. Security templates can be imported into Local Computer Policy and any Active Directory security settings, if they conflict, override Local Computer Policy settings. However, Local Computer Policy should always be configured, because it applies even when DCs are not contactable. In some environments, legitimate and unauthorized users will sometimes disconnect the computer from the network just long enough during the boot sequence to bypass the application of domain-based GPOs.

Group Policy Objects

GPOs are the primary method for automating computer security settings. GPOs can be created locally (although it's called Local Computer Policy), at the site, domain, or OU level. Common GPO settings were covered in Chapter 14. One or more GPOs can be created and linked at the domain, site, and OU container objects.

Default GPOs

Active Directory includes two GPOs by default:

• Default Domain Policy

• Default Domain Controllers Policy

These two policies are created when the first domain controller in the domain is created (using Dcpromo.exe). They contain Microsoft's recommended default settings. The Default Domain Policy is linked to the domain container (e.g., contoso.com) and is applied to all users and computers in the domain. The Default Domain Controllers Policy is linked to the domain controller's OU and applied to all DCs in the domain. All computers, including domain controllers, usually have the Default Domain Policy GPO applied.

Use Chapter 14 to guide you in modifying them to offer more security. In most cases, the original policies should never be modified or implemented. Copy them, rename, and disable the original policies. Make all changes to the new copies so that if something ever goes terrible wrong, the original GPOs can be applied. For W2K3 domain controllers, Microsoft also has a program called Dcgpofix.exe (called Recreatedefpol in W2K) installed by default that will restore these two policies to their original default settings.

GPO Application Pathway

GPOs can be applied at the following levels:

• Locally (using Local Computer Policy)

• Site

• Domain

• OU

Group policy settings are applied when the computer boots up and logs on to the domain, and when the user logs on. The computer settings are applied first, then the user's settings. When a computer boots up, the Local Computer Policy Computer Configuration settings, if any exist, are applied. Then, when the user logs on, the Local Computer Policy User Configuration settings, if any exist, are applied. Then any site-level GPOs are applied. Next, any domain-level GPOs are applied. Lastly, any OU-based GPOs are applied, starting from the top of the directory tree and moving down through the branch containers.

If there are no conflicting settings, all the settings accumulate to create the effective security policy. If any settings conflict between the various GPOs, the last policy applied wins (unless other special settings, as covered below, are involved). The GPO application pathway rule (see Figure 15-5) is known as the LSDOU rule.

Figure 15-5

If multiple GPOs are linked at the same level and settings conflict, the last applied GPO wins again. In this case, it is the highest GPO in the Group Policy Editor (see Figure 15-6). The Group Policy Editor calls the application order priority. The GPMC tool displays a similar listing of GPOs, but calls the precedence order the link order (see Figure 15-7). Both tools allow the GPOs to be moved up and down to assist in the correct GPO application order.

Figure 15-6

Figure 15-7

Extreme GPO Fighting

The previous GPO application rules can be further controlled using a few other mechanisms:

• Disabling

• GPO Category Enforcement

• WMI Filtering

• Block Inheritance

• No Override

• Loopback Policy Processing

• NTFS Settings

Disabling GPOs

GPOs can be disabled overall, meaning both Computer and User Configuration settings, or just one side of the GPO disabled. Other than domain- or site-level GPOs, each GPO should only be applied to either a computer object or user account, but not both at the same time. Disabling the other side of the GPO (see Figure 15-8) will significantly quicken the application speed of GPOs. For the same reason, completely disable test GPOs not being used by anyone when not in active testing.

Figure 15-8

Category Policy Processing Enforcement

Each GPO category can be disabled or enforced on a per-GPO basis. The following GPO categories can be disabled or enforced under \Computer Configuration\Administrative Templates\System\GroupPolicy:

• Registry

• Internet Explorer

• Software Installs

• Folder Redirection

• Scripts Processing

• Security

• IP Security

• Wireless Policy

• EFS Recovery Policy

• Disk Quotas

Figure 15-9 shows the registry category being enforced and reapplied during periodic refreshes even if the GPO hasn't changed. This is another important point. After a GPO is applied, it will not re-apply again until either the GPO changes or the GPO refresh interval is exceeded (usually every 90 minutes with a zero- to 30-minute random offset on non-DCs — to prevent all policies from being re-applied to all PCs at the same time). If the GPO itself has not changed since the last application, the settings are not re-applied until the maximum GPO refresh interval has been met (which is every 17 hours with a random offset).

Figure 15-9

This creates a security issue. Once a GPO is applied, users with appropriate permissions can manually disable or override the setting set by the GPO. The unauthorized change would not be undone until the maximum refresh interval were met. Administrators should require that all GPO settings be re-applied at the regular refresh interval. Of course, this does impose more network and local processing overhead during the GPO application process.

WMI Filtering

Starting with Windows XP, GPOs can be filtered (meaning not applied) to an OU by further selecting additional criteria as queried by the WMI filter. Filters can involve many different fields and criteria, resulting in filters such as the following: only to Windows 2003 machines, only to machines with 100MB free hard drive space, and so on. WMI filters are only understood by XP and later computers, not W2K. W2K will ignore filters and apply GPO.

Blocked Inheritance

GPOs can be blocked on a per-OU basis (see Figure 15-10) using a featured called block inheritance. When block inheritance is set on an OU, no GPO set above that level will apply to the current OU or any of its child OU containers. GPOs linked directly at the OU level will still apply. Because blocking inheritance is indiscriminate regarding which policies it will prevent from applying, block inheritance is not used much in the real world.

Figure 15-10

No Override

Enabling the No Override (it's called Enforced in GPMC) attribute will make a GPO apply to objects in an OU even when Blocked Inheritance is enabled also. Any GPO with No Override set will also be applied last, so that if there are any conflicts, its settings will win. If multiple GPOs have No Override set, the rules fall back to the original LSDOU application pathway.

Loopback Policy Processing

A special GPO-specific setting called Loopback Policy Processing can be used to make Computer Configuration settings take precedence over User Configuration settings. Usually, User Configuration settings win in a conflict because they are applied after the Computer Configuration settings. If enabled, the \Computer Configuration\Administrative Templates\System\GroupPolicy\User GroupPolicy loopback processing mode option (see Figure 15-11) will instruct Active Directory to re-apply Computer Configuration settings after the User policies have been applied.

Figure 15-11

In Replace mode, the Computer Configuration settings are the only ones allowed to be applied in the effective settings (even non-conflicting User Configuration settings are removed). In Merge mode, only settings in conflict with the Computer Configuration settings are replaced. Loopback policy processing can be set per GPO. It is meant to be used in situations, such as public kiosks, where the User settings should have little to no effect on the settings configured on the computer.

GPO Permissions

The permissions of a GPO determine whether or not a particular GPO will apply to a user or computer, or who can manage, link, and edit it. In order for a GPO to apply to a particular user or computer, two things must be true:

• The computer or user must be in an OU that the GPO is linked to or inherited into.

• Computer or user (or a group they belong to) must have the Read and Apply Group Policy permissions enabled.

If either of those two requirements is not met, the GPO will not apply. Often, administrators deny a user or computer the capability to Apply Group Policy, so that the GPO will not apply. Table 15-3 shows the default GPO permissions, each of which can be allowed or denied.

Table 15-3

GPO Permissions	Description
Full Control	Users with this permission can Read and Apply the GPO, edit the GPO settings, delete the GPO, manage links, and manage GPO permissions.
Read	Users with this permission can read the GPO and its settings. Normal users must have this permission to apply the GPO settings, along with the Apply Group Policy permission.
Write	Users with this permission can read, write, and delete the GPO. Administrators may need this GPO permission to even view the GPO.
Create Child Objects	Allowed to create GPO child objects
Delete Child Objects	Allowed to delete GPO child objects
Apply Group Policy	Users must have this permission to apply GPO settings. Normally given to non-admin users and not given to Administrators. Should be set to Deny to prevent GPO application.
Special Permissions	Any combination of the above permissions

GPO permissions, like regular NTFS settings, are set on a per-user, per-computer, and per-group basis. GPO settings only apply to users and computers, but the security permissions to Read and Apply the group policy can be given to groups (and as long as the group members are in an OU "hit" by the GPO, it will apply). Table 15-4 displays the default GPO permissions assigned to various security groups.

Table 15-4

Group	Default GPO Permissions Assigned
Authenticated Users	Read and Apply Group Policy
Enterprise Admins	Read, Write, Apply Group Policy, Delete and Create Child Objects
Domain Admins	Read, Write, Apply Group Policy, Delete and Create Child Objects
Administrators	Read, Write, Apply Group Policy, and Create Child Objects

By default, Enterprise Admins can create, delete, and manage any OU or GPO in the forest or site. Domain Admins can create, delete, and manage any OU or GPO in their domain (and subdomains). As you can also see, by default, any GPO created that "hits" a user or computer will apply.

Many sources recommend that you use GPO deny permissions to prevent administrators from having GPO settings applied. This is exactly the wrong advice. Administrator accounts are the ones most likely to be sought after by hackers. You should allow GPOs to apply to all accounts by default, and only disable ultra-restrictive GPOs from applying to administrators, and even then only sparingly.

The sheer number of ways in which GPOs can be applied and controlled can make it difficult to determine which setting won and by which GPO.

Determining Effective GPO Policy

With all the possible ways of GPOs to interact, it can sometimes be difficult to determine which GPO caused what security setting. You can use Gpresult.exe (an excellent command-line tool) or the Resultant Set of Policy (RSoP) GUI console to display what domain-based GPO settings and Local Computer Policy settings are affecting a particular user or PC. The RSoP wizard can be initiated in Active Directory Users and Computers (choose All Tasks and Resultant Set of Policy (Logging) after right-clicking a user or computer) or using its own RSoP MMC console tool.

The RSoP tool is a great addition to Windows Server 2003 (it was not available in GUI form in Windows Server 2000), as it leads the administrator through a series of wizard dialog boxes asking whether the user or computer GPOs, or both types, should be reported. It then lists the various GPO settings and what domain-based GPO ended up applying the effective setting (see Figure 15-12). In RSoP Planning mode, the administrator can mimic an object move or security group modification (among other options) to see what the impact would be on the effective GPO settings. The only drawback of RSoP is that it does not display the effects of Local Computer Policy settings.

Figure 15-12

Gpresult.exe is a command-line-based tool. If typed alone at the command prompt without any parameters, it will report what groups the current user and group belong to, other information that might affect GPO application, and then the GPOs applied. If run with the /V parameter, it will report each effective setting (see Figure 15-13) and can display the effects of both domain-based and GPO-based security policies.

Figure 15-13

Now that we have all the pieces and parts understood, we can begin to apply the knowledge in a thoughtful way.