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.