GuidesDesigning an effective Group Policy Strategy

Designing an effective Group Policy Strategy




Sean Stecker

Sure, we’ve all seen and heard of Windows
2000 technologies.  Many of us have
even implemented it, and actually made it work. 
But have we really unlocked the full potential of Microsoft’s most
powerful OS?  There are many
exciting technologies in place in Windows 2000, but without some tweaking,
you’re just scratching the surface.

Sure, weve all seen and heard of Windows 2000 technologies. Many of us have even implemented it, and actually made it work. But have we really unlocked the full potential of Microsofts most powerful OS? There are many exciting technologies in place in Windows 2000, but without some tweaking, youre just scratching the surface.

Today we are going to dig deep into what I
feel is the most compelling reason for a Windows 2000 upgrade, Group Policy. 
With a well planned Group Policy infrastructure in place, you can really
flex your administrative muscle.  A
bad design on the other hand, will fill up your voicemail box with more
complaints than your eardrums can handle.

 

What is Group Policy? 

Group Policy is a much improved extension of
System Policy Editor in Windows NT 4.  The
implementation of Group Policy allows you to administer your network
dynamically.  Applying changes to
only the groups, users, or computers that you see fit.  Here is a very brief listing of just some of the areas Group
Policy covers:
 

  • Password
    policies
  • Internet
    configuration
  • Network
    configuration
  • Approved
    applications
  • Desktop
    environment
  • Control
    panel applets
  • Logon
    and logoff scripts
  • Printer
    options
  • Start
    menu options
  • Offline
    file synchronization
  • Software
    deployment

Group Policy allows you to manage very
granular aspects of your workstation, server, and domain environments.  Not only can you cover almost every aspect of network
planning and administration today, you can dynamically change it in the future
as the need arises, with nary a single visit to a client machine.
 

If you’ve never perused the Group Policy
settings before, now is the time to do it. 
Select Start | Run and type “mmc” (without the quotes). 
Next, select Console | Add / Remove Snap-in. Click the Add button, scroll
down the list and select Group Policy, click Add, then click Finish (then Close
and then OK, whew!) This will create a blank Management Console with the Local
Computer Policy Object in it.  This
is the Group Policy Object for the local workstation, and where we will begin
our introduction to Group Policy.  Take
the time now to save the Group Policy snap in, which by default will save to the
Administrative Tools program menu.
 

Start by opening the plus signs in the left
pane of the Group Policy (hereafter known as GP) Snap-in, digging down to show
all of the available configuration options that GP gives us.  Double click on one of the policies in the right pane and
click on the “Explain” tab.  (see
page 2)
Microsoft provides full documentation of each policy object here. 

Before you get started with the actual implementation of GP in your
environment, it is highly recommended that you read through these explanations
of each policy setting.  You may be
surprised as to what you may find, some policies don’t mean what you think at
first glance.  

 

Definitions 

Group Policy Object
A GPO is a policy setting.  The
setting of a default desktop for instance, is configured in a GPO.

Group Policy Container
– Active Directory objects where GPOs are linked.  Only sites, domains,
and OUs can have GPOs linked to them.

 

Active Directory considerations 

With all of the technology built into
Windows 2000 you shouldn’t have to set all of these options at the workstation
level right?  Right. 
GP can be applied in many different areas.  In fact, some settings in GP, like Domain User Account
settings, won’t work unless they’re set in the correct place.  There are 5 major areas where you will apply GP:
 

  1. The
    local computer
  2. The
    site
  3. The
    domain
  4. The
    domain controller(s)
  5. The
    OU

Obviously with so many places GP can be
applied, this implementation could get out of hand very quickly.  Don’t be disheartened, with a little patience, and by
following some simple rules, even very large networks can be handled with GP
relatively easily.

 

Group Policy inheritance 

So, what if I set my users desktop
background in the local computer GPO to be red, and set it in the Domain GPO to
be yellow?  What color do I get,
orange?
 

Here we can begin to see the complexity and
possible downfalls of GP if not designed correctly. 
The answer is yellow.  Here’s
why:
 

In order to design a robust, scalable tool
for this endeavor, Microsoft formulated a set of rules that define how GP
behaves.  By allowing us the ability
to create multiple settings in multiple areas for our domain structure, there
will inevitably be some overlap.  In
order to make sense out of chaos, we have inheritance as our number one rule in
GP.  Understanding GP inheritance is
critical to a successful design and implementation. 

GP will be applied to the user or computer object in the same order as
listed above:

(see
page 3)
 

  1. The
    local computer
  2. The
    site
  3. The
    domain
  4. The
    domain controller(s)
  5. The
    OU

In the case of nested OU’s, GP is applied
in order from the highest level OU, or parent, down to the lowest level OU. 
You can also have more than one GPO applied to the site, domain, and OU
portions of the above list at the same time. 
In this case, the GPO’s are applied in reverse order of their listing
in the GPC properties. 

Notice also that a site can span multiple
domains.  This is a potentially
damaging scenario if not properly planned for in a multi-domain environment. 

Care needs to be taken when creating GPO’s linked to site GPC’s if
they span multiple domains to prevent unplanned cross domain policy
implementation.
 

In the case of multiple settings being
applied with multiple GPO’s, the rule of thumb is “closest one wins”.  Simply put, GP is applied in order as listed above to the
workstation, or user.  If a setting
is defined in the Domain GPO, and then defined differently at the OU level, the
setting specified at the OU level takes precedence. 

 

Exceptions 

As with almost everything in this world,
there are exceptions to the rules:
 

  1. Computers
    that are members of a workgroup will only process the local computer GPO.
  1. At
    any site, domain, or OU, you can select Block Policy Inheritance. 
    This setting is applied to the entire site, domain, or OU, not the
    affected GPO’s.  Therefore Block Policy Inheritance rejects all GP
    settings that reach the site, domain, or OU from above, except those
    specified as No Override.
  1. Any
    GPO linked to a site, domain, or OU can be set to No Override with respect
    to that site, domain, or OU.  If
    more than one GPO has been set to No Override, the GPO highest in the
    hierarchy takes precedence.

Block Policy Inheritance can be used to
abolish GP settings for a particular OU.  For
example, you can block all policy inheritance for your IT Support OU, to prevent
system lock down settings that are present in your organization.  

The No Override option is useful in a
distributed management environment.  With
the granular permission possibilities in Windows 2000, a representative from
Human Resources could be responsible for administration of the HR OU.  Including account creation, password resets, and GP. 

The IT team may want to insert a password uniqueness policy to the entire
organization.  By using the No
Override setting, the IT team can be assured that the password uniqueness policy
will be applied to everyone, even those OU’s where the Block Policy
Inheritance option has been set.

 

Group Policy design approach 

As with every level of network design, you
should have a solid understanding of your end goal in mind when designing your
GP structure.  Are you looking to
decentralize your administrative support of network objects? 
Taking advantage of the very detailed permissions structure in Windows
2000 can allow your organization to implement “Departmental Administrators”. 

Persons who are not in IT Support, but instead members of each
department, responsible for account creation, password resets, even file
permission administration of their assigned areas.  

Or are you looking to maintain a centralized
support model?  One in which all
administrative responsibility is contained within the IT Support group. 
This is the traditional method of administration in most organizations.
 

You effectively have two choices in GP
implementation, Layered and Monolithic GPO design. 
The layered approach’s goal is to establish the GP settings in as few
GPOs as possible, while allowing dynamic control of your GP policy, and is best
suited for environments where change to GP may be frequent.  The monolithic approach tries to apply the desired GP
settings to a given user or computer with very few GPOs. 

All GP settings are contained in the GPOs set specifically on the
affected user, computer, or OU, to get the desired result. 
Monolithic designs are advantageous to organizations where change to GP
will be minimal. (see
page 4)
 

The layered approach requires a base GPO
applied to the domain.  This applies
desired settings to as many users and computers as possible, without overlapping
policy settings.  OU specific GPOs
are created next in order to apply settings tailored to individual departments,
users, or computers, resulting in the final GP structure applied to the end user
or computer at logon.  Note that
this approach does result in longer logon times, due to the number of GPOs
applied.
 

The monolithic approach dictates that most
settings be applied to a single (or very few) GPO or GPOs. 
This single GPO is then applied to the site, domain, or OU where
required. The monolithic design model is best suited for organizations where GP
will be common among most, if not all objects in the domain, and those settings
will change very infrequently, if at all.  With
the smaller number of GPOs to process, logon time is reduced. 

 

Filtering your GPO’s scope 

You can further refine your GP settings with
standard permissions.  In order for
the GPO to be applied to a particular user or security group, that user or group
needs to have Read and Apply GP permissions to it. 

If the user can’t read it, they can’t understand it, and consequently
don’t apply it.  Do not
automatically go out and remove the default Authenticated Users groups- Read
and Apply GP permissions to your GPO’s to prevent them from seeing the
settings.  This will effectively
exclude them from inheriting your GP settings that you have worked so hard to
create.
 

To really utilize the full benefits of Group
Policy, consider setting a permissions structure on the GPO’s to filter out
unwanted policies.  This is a much
more granular way of applying GP to your community. 
The use of Block Policy Inheritance to filter out inheritance is an all
or nothing scenario.  For example,
you simply want to block a specific portion of GP, such as the denial of using
registry editing tools to one OU.  It
is much simpler to filter out one GPO dedicated to registry settings, than to
deny all GP, then recreate everything but the registry settings to get the
effective inheritance.  See the
following example for details.

 

Example GPO filter 

In this example, we will filter specific
portions of Group Policy in our fictional organization Trake Inc.  Trake’s single domain model contains OU’s that house each
specific operating group (Electrical Engineering, Sales, IT Support, and CAD). 
In order to create a granular implementation of GP, we have implemented
several GPO’s specific to groups of intended settings.  

  1. Password
    policy
    – GPO that specifies a minimum of 8
    characters for passwords, expiring every 90 days.
  2. Desktop
    policy
    – GPO that specifies no Run command in the Start Menu, a
    default desktop background, the addition of Logoff to the Start Menu, and
    the denial of use for the application Microsoft Outlook Express (Trake
    utilizes another email system).
  3. Registry
    policy
    – GPO that specifies the denial of use for all registry editing
    tools.
  4. File
    synchronization policy
    – GPO that specifies the options for file
    synchronization of Offline Files.
  5. Scripts
    policy1
    – GPO that specifies the use of a logon script to
    automatically map certain drive letters to data shares for the end users.
  6. Scripts
    policy2
    – GPO that specifies the use of a logon script to
    automatically map certain drive letters to distribution share points for the
    IT Support staff.

In our example, the Password, Desktop, and
Registry policies will be set at the Domain level, the Scripts and File
Synchronization policies will be set at the OU level. 
(see
page 5)
 

By setting the Password, Desktop, and
Registry policies at the Domain level, we have ensured that all security groups
in the Domain will receive these settings. 
The IT Support OU requires a different logon script that maps drives to
various software distribution areas on the network. 

Therefore, we have set the Scripts policy 2 on the IT Support OU only. 
All other OU’s receive the standard Scripts policy 1. 
The Sales OU contains Sales staff that travel on a regular basis.  The network admin for Trake has setup the salesman’s
laptops to utilize Offline Files so the sales staff can view reports and sales
figures while on the road.  We have
set the File Synchronization policy on the Sales OU as well, to define the
Offline File settings for the sales staff.
 

However, we have a problem with our GP
implementation.  The IT Support
staff requires access to the registry editing tools due to the nature of their
job troubleshooting software and hardware at the end user location. 
To prevent the inheritance of the Registry policy setting, we set the
Deny permission for the IT Support security group on the Registry policy GPO. 

Remember, the Deny permission setting automatically overrides any other
access permission setting, in this case the Authenticated Users permission of
Read and Apply GP.  This prevents
the “Disable registry editing tools” setting from being applied to the IT
Support staff security group.
 

If we had used the Block Policy Inheritance
option to prevent this inheritance, we would also have to create the Domain GPO
links specifically to the IT Support OU in order to apply the Password and
Desktop policies.   As you can
see, filtering the scope of GPO’s allows us much more flexibility in our GP
design, as well as fewer steps in implementation.

 

Summary 

A successful implementation of Windows 2000
technologies in your organization can help you realize financial and
administrative savings immediately.  Windows
2000 has been designed to minimize repetitive tasks, and allow greater
flexibility in network design than was present with NT 4.0. 
However, no Windows 2000 rollout would be complete without taking
advantage of Group Policy.  Administrative
control over your environment has never been simpler, or as far reaching.
 

With a well designed implementation of Group
Policy, you can assure your organization an environment of stability, user
friendliness, and the ability to change dynamically as the need requires.

 

More to come- 

This article covered the design and
implementation of Group Policy within a given organization. 
The purpose of this article was to give the reader a sense of the overall
strategy of Group Policy design.  As
I mentioned earlier in the article, GP can also control software deployment. 
This is a very exciting proposition for those organizations where
software deployment mechanisms such as Microsoft’s Systems Management Server
is not in place.   I will cover
this topic in a future article, as the software deployment technologies in Group
Policy are certainly worthy of their own article.

    Latest Posts

    Related Stories