One of the most important sections of a GPO is the Security Settings section. The Security Settings section, under the Windows Settings section, allows you to secure many aspects of the computer and user policies. The following are some of the configurable options for the Security Settings section:

Computer Section Only of the GPO

■         Account Policies

■         Local Policies

■         Event Policies

■         Restricted Groups

■        System Services

■            Registry

■            File System

■             Wired Network

             Windows Firewall With Advanced Security

             Network List Manager Policies

■             Wireless Networks

            Network Access Protection

            Application Control Policies

■            IP Security Policies

             Advanced Audit Policy Configuration

Computer and User Sections of the GPO

■             Public Key Policies

            Software Restriction Policy

Restricted Groups

The Restricted Groups settings allow you to control group membership by using a GPO. The group membership I am referring to is the normal Active Directory groups (domain local, global, and universal). The settings offer two configurable properties:  Members and Members Of.

The users on the Members list do not belong to the restricted group. The users on the Members Of list do belong to the restricted group. When you configure a Restricted Group policy, members of the restricted group that are not on the Members list are removed. Users who are on the Members list who are not currently a member of the restricted group are added.

Software Restriction Policy

Software restriction policies allow you to identify software and to control its ability to run on the user’s local computer, organizational unit, domain, or site. This prevents users from installing unauthorized software. Software Restriction Policy is discussed in greater detail later in this chapter in the section “Implementing Software Deployment.”

Client- Side Extensions

In Windows Server, Group Policies are designed using both server-s ide and client- side extensions (CSEs). The server-s ide elements include a user interface for creating each Group Policy Object (GPO). When a Windows client system logs into the Active Directory network, the client- side extensions (normally a series of DLL files) receive their GPOs and the GPOs make changes to the Windows client systems.

Within GPOs, there are computer policies that exist for each CSE. The policies normally include a maximum of three options: Allow Processing Across A Slow Network Connection, Do Not Apply During Periodic Background Processing, and Process Even If The Group Policy Objects Have Not Changed.

Group Policy Objects

So far, I have discussed what Group Policies are designed to do. Now it’s time to drill down to determine exactly how you can set up and configure them.

To make them easier to manage, Group Policies may be placed in Group Policy Objects (GPOs). GPOs act as containers for the settings made within Group Policy files, which simplifies the management of settings. For example, as a system administrator, you might have different policies for users and computers in different departments. Based on these requirements, you could create a GPO for members of the Sales department and another for members of the Engineering department. Then you could apply the GPOs to the OU for each department. Another important concept you need to understand is that Group Policy settings are hierarchical— that is, you can apply Group Policy settings at four different levels. These levels determine the GPO processing priority.

Local Every Windows operating system computer has one Group Policy object that is stored locally. This GPO functions for both the computer and user Group Policy processing.

Sites At the highest level, you can configure GPOs to apply to entire sites within an Active Directory environment. These settings apply to all of the domains and servers that are part of a site. Group Policy settings managed at the site level may apply to more than one domain within the same forest. Therefore, they are useful when you want to make settings that apply to all of the domains within an Active Directory tree or forest.

Domains Domains are the third level to which you can assign GPOs. GPO settings placed at the domain level will apply to all of the User and Computer objects within the domain. Usually, you make master settings at the domain level.

Organizational Units The most granular level of settings for GPOs is the OU level. By configuring Group Policy options for OUs, you can take advantage of the hierarchical structure of Active Directory. If the OU structure is planned well, you will find it easy to make logical GPO assignments for various business units at the OU level.

Based on the business need and the organization of the Active Directory environment, you might decide to set up Group Policy settings at any of these four levels. Because the settings are cumulative by default, a User object might receive policy settings from the site level, from the domain level, and from the OUs in which it is contained.

You can also apply Group Policy settings to the local computer (in which case Active Directory is not used at all), but this limits the manageability of the Group Policy settings.

Group Policy Inheritance

In most cases, Group Policy settings are cumulative. For example, a GPO at the domain level might specify that all users within the domain must change their password every 60 days, and a GPO at the OU level might specify the default desktop background for all users and computers within that OU. In this case, both settings apply, so users within the OU are forced to change their password every 60 days and have the default Desktop setting.

What happens if there’s a conflict in the settings? For example, suppose you create a scenario where a GPO at the site level specifies that users are to use red wallpaper and another GPO at the OU level specifies that they must use green wallpaper. The users at the OU layer would have green wallpaper by default. Although hypothetical, this raises an important point about inheritance. By default, the settings at the most specific level (in this case, the OU that contains the User object) override those at more general levels. As a friend of mine from

Microsoft always says, “Last one to apply wins.”

Although the default behavior is for settings to be cumulative and inherited, you can modify this behavior. You can set two main options at the various levels to which GPOs might apply.

Block Policy Inheritance The Block Policy Inheritance option specifies that Group Policy settings for an object are not inherited from its parents. You might use this, for example, when a child OU requires completely different settings from a parent OU. Note, however, that you should manage blocking policy inheritance carefully because this option allows other system administrators to override the settings made at higher levels.

Force Policy Inheritance The Enforced option (sometimes referred as No Override) can be placed on a parent object, and it ensures that all lower- level objects inherit these settings. In some cases, you want to ensure that Group Policy inheritance is not blocked at other levels. For example, suppose it is corporate policy that all network accounts are locked out after five incorrect password attempts. In this case, you would not want lower- level system administrators to override the option with other settings.

You generally use this option when they want to enforce a specific setting globally. For example, if a password expiration policy should apply to all users and computers within a domain, a GPO with the Force Policy Inheritance option enabled could be created at the domain level. You must consider one final case: If a conflict exists between the computer and user settings, the user settings take effect. If, for instance, a system administrator applies a default desktop setting for the Computer policy and a different default desktop setting for the User policy, the one they specify in the User policy takes effect. This is because the user settings are more specific, and they allow system administrators to make changes for individual users regardless of the computer they’re using.