Santa Gates has a special toy from the land of Windows 2000. Question is, how does it work?
The Gift of Group Policy
Santa Gates has a special toy from the land of Windows 2000. Question is, how does it work?
“And what do you want for Christmas, little girl?” Santa
asked as I sat on his knee, picking fake white hair out
of my teeth.
Grinning up at him I said, “I want to be able to sit
at one console, issue commands, then put my feet up and
let the server push these policies out across the enterprise.
I want to be able to granularize that control so different
groups of computers and users can receive special instructions,
and, when necessary, I can delegate some of my duties
to my minions. And Santa? Could you rub my neck?”
“Here,” he said. “Have a candy cane.”
Father Christmas didn’t come through for me last year,
but Santa Bill did. Windows 2000 has a few new tricks,
and one of them provides me with much of what I wanted.
With Windows 2000 Group Policy you, too, can spin your
web of control around your little universe and beyond.
But, like many gifts, you may not know just what to do
with it when you first take off the wrapping. Not to worry—there
are lots of little helpers in the form of wizards, help
files, and 500-plus pages of documentation in the Windows
2000 Server Resource Kit.
Don’t get put off by the large amount of information
available on Group Policy. While properly planning and
implementing Group Policy will require a lot of work,
the payoff is tremendous. So what, exactly, is Group Policy,
what is it good for, and why am I so excited?
Group Policy Basics
The concept is simple:
Determine what’s different about computers and users.
Place like users and computers into groups.
These groups become the Organizational Units in
your Win2K empire.
Write a policy stating how each group should be
managed and secured.
Implement the policy using the tools provided.
Let the operating system enforce this policy across
The concept is clear—even the physical implementation
process is simple—but truly understanding how it works
and designing the correct solution for your Win2K network
can be difficult. To do so, you’ll need to understand
not only how to use the tool and what you want to happen
where, but also how the process happens. Let’s start with
Group Policy Object—A
GPO is policy definition. You can open a GPO in a Microsoft
Management Console and define or modify specific settings.
Group Policy Container—A GPC is an
object in the Active Directory to which a GPO can be linked.
Current GPCs are sites, domains and OUs. Nothing else
can have a GPO linked to it.
Group Policy Editor—The
GUI interface used to view and edit a GPO. The general
belief is that Group Policy only affects users with domain
accounts and Win2K computers that are in the domain. Strictly
speaking, this is true. Group Policy can’t be used to
manage Windows NT or Windows 9x computers—nor can it be
used to manage users with accounts in a Windows NT domain.
However, even Win2K computers that aren’t in a domain
(standalone systems) do have a Local Security Policy object
applied to them.
Group Policy and Security Groups
Granted, they’re confusing, but I don’t think either
name is going to change, so let’s get this straight right
now: Group Policy can’t be linked to Security Groups.
Group Policy is linked to GPCs. GPCs contain collections
of users and computers, printers, shares, security groups,
and the like. If a GPO is linked to a GPC, it’ll be applied
to the users and computers that are part of that GPC.
Since security groups can contain users from multiple
GPCs (a domain-level security group, for example, might
have users from many different OUs), the GPOs impact is
restricted to the user and computer accounts within the
In Figure 1, the triangle represents the ACME domain.
The domain has two non-default security groups, Clerks
and Managers. Both are part of the Westport OU. John’s
account is in the Westport OU, and he’s a member of the
Clerks group. Peter’s account is in the Westport OU, and
he’s a member of the Managers group. Alice’s account is
at the domain level, and she’s a member of the Managers
group. The GPO linked to the Westport OU includes the
restriction that all users’ desktop screens must display
the “Gold Petal” wallpaper. When Peter and John log on,
their desktops show this wallpaper. When Alice logs on,
her desktop doesn’t.
|Figure 1. Application of Group
Policy depends on the location of the user account,
not the security group.
Even though Alice and Peter are members of the same security
group, and that security group is in the Westport OU,
the application of the policy depends on the location
of the user account, not the security group. By default,
when linked to a GPC, the GPO applies to all users and
computers in the GPC, regardless of their membership in
a security group. You can, however, filter the application
of a GPO policy.
So What Can You Do with Group Policy?
Group Policy affects many features of Win2K. Using Group
Policy, you can perform the following functions:
Manage software installation
Implement logon and logoff scripts
Administer computers and users with extensive lists
of features (similar to Systems Policy in NT and Windows
Implement and manage security policy for the enterprise
While I can’t cover any of these in extreme detail, you
can get a good idea of the range and scope of coverage
by opening up the default Domain Policy. To examine this
Open the Active Directory Users and Computers console
from Start | Programs | Administrative Tools.
Right-click on the domain object (the topmost object
in the hierarchical display).
Select the Group Policy tab.
Click the Edit button.
Scroll, click and expand each item.
Double-click on items to see the possibilities each
has for configuration.
Note that on Administrative templates, an Explain
tab is available. Click on this tab to read what the
item will do. This valuable feature can help you understand
what making a change will do so that you won’t have
to guess from the possibly misleading title of the
To further understand Group Policy policies, use the
Server Resource Kit tool, gp.chm. This file is a collection
of html pages that explain all of the policies.
So you’ve been looking at the GPO for the domain and
are assuming that changes made here will roll out to every
user and computer in the domain. You’re correct—to a point.
Group Policy application depends on several things, including
definitions on the local, site, domain and OU levels;
user and computer definition location; GPO permissions
(see “Filtering Group Policy”); and the No Override and
Block Inheritance options.
As you know, GPOs can be linked at the site, domain and
OU levels. In addition, a local Security Policy exists
on every Win2K computer whether or not it’s in a domain.
This policy is the security policy on the standalone computer.
When a computer joins a domain, this policy is limited
by the application of policy elsewhere.
The location of a GPO limits its direct application to
computers and users within its GPC. However, if a GPC
is nested within another GPC, then the settings of the
external GPC will be applied to the users and computers
within the nested GPC. GPOs linked to these child GPCs
will also be applied to computers and users contained
within them. So a policy applied at the domain level can
affect all computers and users in the domain, but a policy
at the OU level only affects the computers and users in
In our example, users and computers in the Westport OU
are affected by their local computer security policy,
the domain policy, and the GPO linked to the Westport
OU. The order of all policy application and the resolution
of conflicts are carefully orchestrated by the rules of
policy inheritance, which I’ll explain shortly.
And What Can Group Policy Do to You?
Is all of this sounding too complex to figure out and
apply? How many of you didn’t use Systems Policy in NT
for this very reason? Are you thinking that you’ll just
manage your systems using the other built-in tools? Are
you postulating that Group Policy is for large enterprise
operations? Think again.
If you don’t understand and use Group Policy, it’ll use
you. There are default policies in place, and the hierarchical
application of Group Policy will occur whether or not
you elect to understand it. Sometimes, editing a GPO is
the only way to change how things work. Where do you modify
user rights in the domain? How about setting event log
policy, Kerberos, or IPSec policy? How can you enable
Audit? That’s right, you make changes in Group Policy.
It’s also important to understand that some policy changes
should only be made at a particular place.
Password settings and other Account Policies can
only be set in the domain GPO. Settings made elsewhere
won’t have an impact on domain users.
Audit Policy for most computers in the domain can
be set in the domain GPO; but to enable auditing for
Domain Controllers, you must do so in the Domain Controllers’
Changing the name of the Administrator account must
be done in the Domain Computers’ GPO.
Got that down? OK, make some changes to Group Policy
and then visit other computers in the domain. What? The
changes aren’t being displayed there? Even though Group
Policy can be used to control all of the computers in
the domain, changes won’t occur immediately. Changes are
applied according to default rules that can be modified
by—you guessed it—setting Group Policy. By default, computer
policy is refreshed at boot, and user policy at logon.
Both computer and user policies are refreshed periodically
throughout the day—every five minutes for domain controllers
and every 90 minutes for all other systems. The normal
process of Active Directory replication will also affect
the application of Group Policy.
Breathing easier? Wait. Since Group Policy can be linked
to GPCs, the impact of these multiple policies on the
user’s computer and his or her account will depend on
where in the Active Directory hierarchy the policy is
linked. Group Policies are inherited from GPOs higher
in the AD, and the impact is cumulative. But what happens
when there’s a conflict?
Understanding Group Policy Inheritance
To get a grip on inheritance, you must first back up
and make sure you’re clear on the hierarchical structure
of AD GPCs, AD replication, and the design of an OU structure.
Active Directory Group Policy Containers
As you know, sites express the physical design of your
network and can include multiple domains. A domain can
have computers in multiple sites. This is important, because
GPOs can be linked at the site level. You need to pay
attention here because of the implication of cross-domain
application of policy and the problems inherent in applying
Group Policy across slow links.
Domains are security boundaries. As such, GPOs linked
at the domain GPC affect all computers and users in the
domain. Also, there are some parts of Group Policy that
can only be set at the domain level. Thus, Account Policies
such as password and Kerberos policies can only be set
in GPOs linked to the domain GPC. Account Policies set
anywhere else—say, at the OU level—will only affect local
OUs are contained within the domain and can contain other
OUs. In fact, an entire OU hierarchy can be constructed
to deal with complex administrative requirements.
AD Replication Impact on Group
Every Active Directory architect must take into account
the impact of AD replication on the environment. AD replication
is the reason why changes made someplace in the AD are
appropriately changed elsewhere.
One of the largest concerns is the frequency of replication
and the delay inherent in even the smallest structure.
Information on the additions of users or changes to their
passwords, for example, isn’t immediately available on
all domain controllers in the domain. It takes time for
that information to be replicated. A good design can help
rectify this problem, but there will still be delays.
The application of changes to Group Policy, likewise,
is hit by AD replication. Part of the process includes
the delay in making the change and the distribution of
the information to the appropriate location so that it
can be replicated and applied. Another part has to do
with when Group Policy is applied. So even in a single-domain,
single-domain-controller environment, a change to group
policy won’t be immediately applied to a computer in the
In a larger environment, delays can be much longer. How
long will depend on the size of the enterprise, the effectiveness
of the AD design (including OU nesting levels), and the
application of Group Policy settings.
OU Hierarchy Design
Computer and user accounts will be affected by all GPOs
linked to the GPC they’re members of, as well as the GPOs
linked to any of their GPCs’ parents. In a simple AD structure—one
with a single OU level—a user or computer that’s a member
of an OU may be affected by five GPOs:
In a more complex AD design the user has the potential
of being affected by these GPOs as well as those linked
to any OU under which the OU is nested. The OU structure
can slow performance and delay applications in three ways:
A deeply nested OU structure and/or multiple GPOs
at each level can severely increase the time it takes
to log on.
A deeply nested OU structure and/or multiple GPOs
at each level can stretch out the time it takes a
system to boot.
Since Group Policy is periodically applied throughout
the day, the intricacy of the structure and normal
replication delays can increase the time it takes
before the change actually takes effect.
Group Policy Inheritance
Here’s the scoop on the inheritance process. When a computer
boots and a user logs on, Group Policy is applied in the
Top level OU (at the top of the hierarchy) policy
The next OU in the hierarchy policy
Subsequent OUs in the hierarchy policy
For purposes of discussion, I’ll speak of the policies
above others in this list as the distant policies and
those underneath them as closer-level policies. The following
rules, deviations, and exceptions apply:
If multiple GPOs are linked to the same GPC, the
policies are applied in the reverse order of their
listing. Thus, in Figure 2, first the Green Policy
will be applied and then the Red Policy. Any conflicts
between the policies will be resolved in favor of
the Red Policy.
|Figure 2. If multiple GPOs are
linked to the same GPC, the policies are applied in
the reverse order of their listing.
If a policy isn’t defined at a closer level, any
definition at a distant level will still be in effect.
So if a policy to set DACLs on a folder is defined
in the local policy but not defined in the OU GPO,
the DACLs will be set.
If a policy is defined, enabled, or otherwise, at
a distant level and also defined at closer level,
the closest level policy will win in the case of conflict.
Default GPOs exist. You should examine them for
default policies that will affect your GPO design.
There are defined locations for the settings of
some policies. Policies set anywhere else will have
no impact. An example of this is password policy,
which is set at the domain level.
A GPO can be designated NO OVERRIDE. If it is, no
other policy will override its settings.
A domain or OU can be designated Block Inheritance.
If it is, it won’t inherit the GPO settings of other
A GPO designated NO OVERRIDE will not be blocked
by Block Inheritance.
An example of Group Policy Inheritance is displayed in
|Figure 3. Group Policy inheritance
defines the process of application within an OU.
In this figure, there are GPOs at each level in the hierarchy.
Only one item in each GPO is identified for simplicity’s
sake. Please note, I’m just giving you an example of how
policy would be applied. The following list describes
the process that occurs in the application of Group Policy
to the users and computers within the PURPLE OU.
The local policy is applied. If the computer is
a server, the default is set to not allow all users
to log on locally. If the computer is Professional,
the group Everyone has the right to log on locally.
The domain policy is applied. The right to log on
locally isn’t defined. The group Everyone still has
the right to log on locally to Professional systems,
but not to servers.
The policy of the RED GPO is applied. The right
to log on locally isn’t defined. The logon message
(banner) is defined. The group Everyone will have
the right to log on locally on Professional, but not
on servers. All users logging on will be presented
with the logon banner.
The policy of the PURPLE GPO is applied. This policy
gives the group Everyone the right to log on locally.
No matter what the computer is, Server or Professional,
all users can log on locally. All users will be presented
with the logon banner.
Would users logging on to computers in the BLUE OU or
the RED OU be able to do so? (Only if the computer was
a Professional or the server had a modified local security
Now that you know that GPOs are applied
to computers and user members of a GPC,
you might be wondering if this default
activity can be changed. Of course it
To understand how, open the property
pages for the GPO and select the Security
tab. You’ll see the familiar structure
for assigning DACLs on an object. The
permissions are different, but the process
is the same. To limit the application
of a GPO within a GPC, you simply allow
or deny the Apply Policy and Read Policy
permissions to the specific security
groups you desire. Note that when you
first open the security pages, the Authenticated
Users group is given these permissions.
This means the policy is applied by
default to any users within the GPC
who have been authenticated. (Policy
for users is first applied at logon.)
To restrict or filter this application,
you need to adjust the permissions for
the desired security groups. Do you
remember Alice and Peter from the example?
Alice didn’t get the “Gold Petals” wallpaper
because her account wasn’t in the Westport
OU, but Peter did because he was. If
management decides that members of the
Managers group should have the ability
to choose their own wallpaper, you can
do this via the filtering process. Add
the Managers group to the security pages
and give them the Deny Apply Policy
Permission. The following figure shows
|To limit the application
of a GPO, simply allow or deny
policy permissions to specific security
Now when Peter logs on, his screen
won’t display the “Gold Petals” wallpaper.
You can also filter the application
of Group Policy to specific computers
within the GPC by creating or using
default computer groups and filtering
the application of policy. By default,
the GPO is applied to all computers
whose accounts are in the linked GPC.
Zeroing in on Security
So what’s got me breathing heavily and my fingers all
twitchy on the keyboard? It’s the implication of that
fourth bullet in the “What can you do…” heading above
(Implement and manage security policy for the enterprise).
Like every cool tool, it’s not the size that counts, but
what you can do with it.
As I cross the world preaching security, I’m often subject
to sighs of indifference that later change to groans when
my audience decides it wants to implement security in
a Windows network, but realizes the tedium of doing so.
Group Policy gives us a tool that can be used effectively
to implement, maintain, and audit security policy in the
I’ve introduced the basics to you. Next, you must design
your policy with the possibilities and implications firmly
in mind and the goals and structure of your organization
always guiding your steps. In fact, the design of your
security policy and its implementation through Group Policy
should be part of the design, deployment and on-going
maintenance of your Win2K network.
If you’ve already implemented Group Policy in your enterprise
and would be willing to allow me to use your design as
a case study in a project I’m working on, let me know.