Logo
PREGNANCY
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
 
 
Windows Server

Windows Server 2008 R2 : Planning Domain Group Policy Objects (part 2)

3/25/2011 6:46:06 PM

Domain GPOs

When an Active Directory domain is deployed, a default domain policy and a default domain controller policy are created. The default domain policy defines the password and account policies for all domain user accounts and local user accounts for domain member servers and workstations. A few additional settings are also defined within the default domain policy regarding the Encrypting File System, Kerberos authentication, and a few other network-related security settings.

As a best practice, the only changes that should be made to the default domain policy should be modifying the password and account policy settings and nothing else. Additional settings that are required at the domain level should be defined in separate policies linked to the domain. The settings configured on domain-linked GPOs will be applied to all computer and user accounts in the domain, including all domain controllers. Settings configured at the domain level should be deployed as default settings and not as organizational standards. For example, as a domain default, the organization might want to configure all computers to enable Windows Update and get updates from the Windows Software Update Services (WSUS) at headquarters and to configure a few default firewall exceptions to allow for remote administration from the IT department. Common default settings applied at the domain level, but not in the default domain policy, can include the following:

  • Default screensaver settings

  • Default Windows Update settings

  • Default firewall profile and rule configurations

  • Default Encrypting File System settings and recovery agent

  • Trusted root certification authorities

  • Certificate enrollment configurations

All Windows systems that are members of an Active Directory domain will inherit the user password and account policies from the domain and apply this policy to local accounts on these systems. In some cases, it might be necessary to leverage local user accounts on systems with a less-restrictive password policy to support a particular service or application. This task can be accomplished by adding a GPO at the organizational unit that defines a less-restrictive password and account lockout policy. This particular password and account lockout policy will only apply to local user accounts on the computers contained within the linked organizational unit. The only thing that will break this configuration is if the default domain policy is enforced.

In situations when special or specific domain user accounts cannot adhere to the domain password policy, if the domain is operating in Windows Server 2008 or Windows Server 2008 R2 domain functional level, a fine-grained password policy can be created and applied to the necessary user accounts.

Domain Controller GPOs

When an Active Directory domain is deployed, a default domain controller policy is created. This is different from the default domain policy in many ways, but the most prevalent distinction is that this policy is applied to the domain controllers organizational unit and not the entire domain. The default domain controller policy only applies to objects in this organizational unit, which should contain all of domain controllers of the specific domain, and no other objects.

The domain controllers organizational unit inherits all policies linked to the domain and each domain controller also inherits any site-linked GPOs if any exist. These policies will be applied by the domain controllers and might not be desirable. As a best practice, to avoid impacting domain controller security and reliability, try to limit the configuration settings defined within domain-linked policies or specifically deny the application of these group policies to the enterprise domain controllers security group within each domain of the forest.

Note

Moving a domain controller out of the domain controllers organizational unit is not recommended as adverse effects could result, including compromising the security of the entire domain as well as breaking authentication and replication functionality.


The default domain controller policy defines user rights assignment settings for domain controller management as well as defines settings to control the security of network communication. Most organizations do not require any changes made to the default domain controller policy or any additional policies linked to the domain controllers organizational unit. Common settings applied at the domain controller organizational unit level can include the following:

  • User rights assignment updates for domain controllers (commonly used for backup agent accounts)

  • Restricted group policies for domain security groups

  • Event Viewer settings

  • Audit settings for domain controllers

  • Domain controller–specific Windows Update settings

  • Remote administration settings for domain controllers

Active Directory Site GPOs

By default, no group policies are created for Active Directory sites. Policies linked to Active Directory sites will be applied to all computers that connect to the domain from the particular subnets associated with the site and, of course, the users who log on to these particular computers. If computers are moved to new sites, these computers will pick up and process any policies linked to the new site and none from the original site. For example, if an Active Directory site is created for the virtual private network (VPN), when a computer is connected to the corporate network using the VPN, any policies linked to the VPN site will be applied to the computer.

Site policies can be a very effective way to simplify administration of mobile users, but if used incorrectly, site policies can cause a lot of issues. For example, using site policies to deploy printers can simplify end-user management for visiting employees. On the other hand, installing software for all computers in a site or enforcing networking settings might impact mobile computers if these settings are not overwritten or restored when the user and the system return back to the main office or disconnect from the corporate network. Site GPOs are not commonly used, but when they are, some of the common settings can include the following:

  • Wireless and Wired Network Policies

  • Deployed Printers (User Configuration)

  • Internet Explorer Proxy Configuration

Small Business

Many small businesses run Windows Server systems and Active Directory domains. Unless these businesses run an edition of Small Business Server, most small business Active Directory infrastructures do not effectively leverage local or domain group policies using the default configuration. Many of these Active Directory deployments are flat and all computers and users remain in the default containers and only apply the default domain policy. For small businesses with limited IT resources and budget, aside from updating the password and account lockout settings in the default domain policy, there are a few GPO settings that can enhance management and reliability. Please keep in mind that the following small business group policies are not recommended for Small Business Server (SBS) or Essential Business Server (EBS) deployments, as SBS and EBS deploy a number of preconfigured policies that provide some of the features included in the following policies and much more.

Group Policy management for small businesses should be kept simple. The following list of recommendations should be considered for small business Group Policy configurations:

1.
Review and, if necessary, adjust the password and account lockout policy in the default domain policy to match the requirements of the organization.

2.
Create a new policy named Corporate Computer Policy and disable the User Configuration section of this policy. Within this policy, configure Windows Update settings, deploy network printers, enable remote administration, and configure firewall exceptions or rules to allow for proper communication between the servers and workstations on the network. If necessary, also configure Internet Explorer Security Zone settings. Link this policy to the domain.

3.
Create a new policy named Corporate User Policy and disable the Computer Configuration section of this policy. Within this policy, configure user mapped drives, default screensaver settings, and, if necessary, lock down the desktop, Start menu, and Control Panel. In some cases, folder redirection configuration would also be recommended, but this is an advanced configuration and might not be feasible for small businesses. Link this policy to the domain.

4.
Edit the default domain controller policy and configure the Windows Update settings to download and notify the administrator when updates are ready. Many organizations configure Windows Update on workstations to autoinstall and autoreboot, but on a domain controller (or any server for that matter), this might be risky. For a small business, allowing for autoinstall and autoreboot might present more of a risk than having a tech regularly perform a manual update task.

Delegated Administration

Delegating administration to perform Active Directory functions is becoming a very common task in medium- and large-size organizations. Delegation tasks, such as allowing the telecom group to update telephone numbers for all Active Directory user accounts or allowing help desk staff to unlock user accounts and reset user passwords, are simple to implement using the Active Directory Users and Computers snap-in. To configure delegation of Active Directory objects such as user accounts, security and distribution groups, and computer objects, this task is not best handled with domain policies. Instead, these delegation tasks are handled by configuring security permissions at the domain level, organizational unit level, or on the particular object itself. One way to simplify or clarify this concept is to remember that if the task will be performed using the Active Directory Users and Computers snap-in, this is delegated by configuring security permissions on a container or object. If the task would normally be performed by logging on to a computer and configuring settings or configuring the profile of a user or group of users, most functions related to this type of task can be performed using domain policies.

Group Policy Objects are, in fact, Active Directory objects and delegating Group Policy administration rights is also performed by configuring security access on Active Directory containers, such as domains and organizational units. Group Policy management includes several tasks, which can be delegated in the following configurations:

  • New domain group policy creation— This is performed by adding the user account or security group to the domain Group Policy Creator Owners security group or delegating this right using the Group Policy Management Console (GPMC) at the Group Policy Objects container. Although delegating this right allows the user to create new policies, this user or group is not granted the right to edit settings or modify security on existing GPOs.

  • Edit settings on an existing GPO— After a GPO is created, the right to edit that particular GPO can be delegated using the GPMC.

  • Edit settings, modify security, and delete a GPO— These tasks are delegated using the GPMC on a single GPO at a time. The Modify security right allows the designated user to change the security filtering, basically defining which users and computer objects will apply the policy if these objects are in containers linked to that particular GPO.

  • Link existing GPOs— The ability to link GPOs to Active Directory containers is performed by editing the security settings on the particular Active Directory site, domain, or OU. This is known as the Manage Group Policy Links security right.

  • Create and edit WMI filters— The right to create new WMI filters or have full control over all WMI filters in a domain can be delegated at the WMI Filters container using the GPMC. Also, the right to edit or grant full control over an existing WMI filter can be delegated to a user or group. Delegating the right to edit or to grant full control does not enable linking WMI filters to GPOs as that requires edit rights permissions on a particular GPO.

  • Perform GPO modeling using GPMC— GPO modeling delegation is performed by editing the security settings on the particular Active Directory site, domain, or OU. This task allows a designated user the ability to perform dry runs or simulated tests to determine the results of linking a policy to a particular container or moving a user or computer object to a different container in Active Directory. This is also known as the Generate Resultant Set of Policy (Planning) security right. If the user running GPMC is not running GPMC on the domain controller, the user needs to be added to the domain’s Distributed COM Users security group to run Group Policy Modeling from another system.

  • Perform GPO results using GPMC— This task can be performed on local machines if the user is a local administrator and the GPMC is installed. It can also be run by using the GPresult.exe from the command line or by loading the rsop.msc Microsoft Management Console snap-in. By default, local administrators can run this tool against all users on a machine. To delegate this right in Active Directory, edit the security settings on the particular Active Directory domain or OU that contains the computer and user accounts. This task allows the user to remotely connect to the computer to query the Group Policy logs to generate a historical report of previously logged Group Policy processing events. This is also known as the Generate Resultant Set of Policy (Logging) security right. To run this task against a remote computer, aside from having this right in Active Directory, the user also needs to be a member of the computer’s local Distributed COM Users security group, or the domain group if running modeling or results against a domain controller. Additional configuration might also include possible firewall policy changes on the required computers to enable the remote administration firewall exception.

Other -----------------
- Windows Server 2008 R2 : Planning Workgroup and Standalone Local Group Policy Configuration
- Exchange Server 2010 : Components of a Secure Messaging Environment (part 3) - Using Email Disclaimers
- Exchange Server 2010 : Components of a Secure Messaging Environment (part 2)
- Exchange Server 2010 : Components of a Secure Messaging Environment (part 1) - Hardening Windows Server 2008
- Considering the Importance of Security in an Exchange Server 2010 Environment
- Installing BizTalk Server RFID 2010
- BizTalk Server 2010 : Configuring EDI Trading Partners
- BizTalk Server 2010 : Accessing the EDI Version 5010 HIPAA Schemas
- Exchange Server 2010 : Managing Recipients and Distribution Groups (part 2) - Distribution Groups
- Exchange Server 2010 : Managing Recipients and Distribution Groups (part 1) - Mail Contacts & Mail-Enabled Users
- Exchange Server 2010 : Resources and Shared Mailboxes
- Windows Server 2003 : Monitoring Network Performance (part 3)
- Windows Server 2003 : Monitoring Network Performance (part 2) - Performance Console Differences
- Windows Server 2003 : Monitoring Network Performance (part 1) - Using the Networking Tab in Task Manager
- Windows Server 2008 R2 : Group Policy Management for Network Clients - Group Policy Feature Set
- Windows Server 2008 R2 : Group Policy Management for Network Clients - Windows Group Policies
- SharePoint 2010 PerformancePoint Services : SharePoint List Data Source
- SharePoint 2010 PerformancePoint Services : Data Sources - Import from Excel Workbook
- SharePoint 2010 : Visio Graphics Services Overview
- SharePoint 2010 : Access Services Overview
 
 
Most view of day
- Microsoft OneNote 2010 : Using the Research and Translate Tools (part 2) - Translating a Word or Phrase with the Research Pane
- Automating Vista Events
- Microsoft Dynamic AX 2009 : .NET Business Connector - Introduction
- BizTalk Server 2009 : Editing and Resubmitting Suspended Messages (part 1) - Sample Flows for Edit and Resubmit
- Integrating SharePoint 2013 with the Office Applications (part 3) - Microsoft Excel
- Windows Server 2003 on HP ProLiant Servers : The Physical Design and Developing the Pilot - Network Services
- Windows Phone 8 : Designing for the Phone - Blend Basics (part 2) - Brushes
- Microsoft Content Management Server Development : Validating Placeholder Controls - Validating the SingleImagePlaceholderControl
- Microsoft Excel 2010 : Using Formulas - Copying a Formula, Formula Operators
- Using Wireless Bluetooth Devices : Adding Bluetooth-Enabled Devices
Top 10
- Windows Phone 8 : Configuring Mailbox Settings (part 5) - Configuring Automatic Replies
- Windows Phone 8 : Configuring Mailbox Settings (part 4) - Lightening the Display,Changing the Mailbox Sync Settings
- Windows Phone 8 : Configuring Mailbox Settings (part 3) - Message Signatures, Blind CCing Yourself
- Windows Phone 8 : Configuring Mailbox Settings (part 2) - Unlinking Mailboxes, Conversation View
- Windows Phone 8 : Configuring Mailbox Settings (part 1) - Linking Mailboxes
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 6) - Tracking installed roles, role services, and features
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 5) - Installing components at the prompt
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 4) - Managing server binaries
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 3) - Adding server roles and features
- Managing Windows Server 2012 Systems : Configuring Roles, Role Services, and Features (part 2) - Installing components with Server Manager - Viewing configured roles and role services
 
 
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
2015 Camaro