Designing Group Policy in an Active Directory environment

If you’ve implemented your sites, domains and OUs in the wrong way, Group Policy will be difficult to use and troubleshoot. So the first step in planning how you’re going to implement Group Policy on your network is to plan how you’re going to implement Active Directory itself. Such planning includes decisions like: How many forests you will deploy (one or several)? How many domain trees? Will there be child domains? What kind of OU structure will each domain have? And so on. Each of these decisions should always be made by asking the question: What impact will my decision have on how Group Policy is implemented in my enterprise? Let’s look at some guidelines that can help you design Active Directory effectively as far as Group Policy is concerned.
K.I.S.S.
The first and obvious principle is to “Keep It Simple, Stupid!” or “K.I.S.S.” In the context of Group Policy planning, this means two things:
If a single domain will meet all your company’s needs, then use only one domain. The reason simply is that the number of Group Policy Objects (GPOs) you will need to create is roughly proportional to the number of domains you have in your forest. For while linking a GPO residing in one domain to a container (domain, site or OU) in a different domain does reduce the total number of GPOs you need to deploy, it can have a significant performance impact and shouldn’t generally be done.
Keep your OU structure relatively simple, for example two or three levels of OUs at most. The reason is similar here to why you should keep your number of domains as low as possible: administrative overhead.
So let’s say you begin your Active Directory design by deciding you’re going to us a single domain (see Figure 1) with two or maybe three levels of OUs within it. That’s a good place to start. What’s next?

Figure 1: Have only one domain if possible
Server OUs
Group Policy isn’t just for managing desktops; it’s also terrific for locking down servers to ensure they’re secure and working properly. And by servers I mean both member servers (which include file servers, print servers, web servers, DHCP servers, and so on) and domain controllers. The best way to lock down domain controllers is to leave them in the default Domain Controllers OU and configure a GPO linked to that OU. There are two ways you can do this:
Configure the settings in the Default Domain Controllers Policy.
Create a new GPO, link it to the Domain Controllers OU, and configure it.
Which approach is better? Some experts recommend leaving the default GPO untouched and creating a new GPO and moving it to the top of the link order for GPOs linked to the OU. That way if something goes wrong later you at least have your default GPO in place and untouched. On the other hand, if you run the new Security Configuration Wizard (SCW) of Windows Server 2003 Service Pack 1 on a domain controller, then in addition to other changes it will modify certain settings in the Default Domain Controllers Policy to make your domain controller more secure. So either approach works fine, but personally I prefer the second approach.
What about your member servers? The trick here is to realize that the different member server roles are basically incrementally different from a baseline (having no role) member server. So a good approach is to create a top-level Member Servers OU and then beneath it add additional OUs for each role (Figure 2):

Figure 2: OU structure for member servers.
The advantage of this approach is that you can now create a baseline Member Servers GPO that generally secures any member server and link it to the Member Servers OU. That way all of the member servers in child OUs will automatically inherit this policy. Then you can create a Print Servers GPO and link it to the Print Servers OU, a File Servers GPO and link it to the File Servers OU, and so on. These different GPOs linked to child OUs of the Member Server OU can be used to incrementally harden security for each server role over the basic hardening provided by the Member Servers GPO.
Here’s a tip: if you want to find out more about using the above approach to harden servers using Group Policy, read the Windows Server 2003 Security Guide which is available from the Microsoft Download Center. This Guide has terrific suggestions on how to secure different server roles and it’s well worth plowing through its almost 300 pages of content. If you don’t have time to read the whole Guide, check out my blog ITreader.net and click Group Policy under Topics and you’ll find lots of useful information that I’ve culled from my own reading of the Guide as well as other Microsoft resources.
Desktop and User OUs
The OU structure you plan for your domain can depend on various things including your company org chart, branch offices, number of departments, and so on. There’s no hard and fast single best way of designing OUs for a domain, but the following tips can help you avoid problems later on when you start creating GPOs to lock down users and their desktop computers.
First off, you should only create an OU if there is some compelling reason for it to exist. For example, if users in the Sales, Marketing, and Reference departments all have similar needs as far as security goes, group their accounts into a single OU instead of three. Then if Sales users have some minor difference in security requirements from the other two departments, you can create and link another GPO to the OU and use security filtering to ensure only members of the Sales group have that GPO setting applied to them.
Next, you should try to create your OUs along departmental lines rather than geographical location. That way you can make more effective use of delegation when you need to use it. If you must have geographical OUs, make them the top-level OUs and then create child OUs beneath them for each division or department (Figure 3):

Figure 3: A typical OU structure.
Next, create separate OUs for computer accounts and user accounts (Figure 4). That way you can use separate OUs to lock down machine settings and user settings. Of course, you could achieve the same thing by lumping together computer and user accounts into a single OU, linking two GPOs to that OU, and disabling the machine settings in one OU and the user settings in the other OU. But keeping your computer and user accounts in separate OUs will make it easier for you to troubleshoot when Group Policy doesn’t do what you expected, and it makes mistakes in configuring policy less likely also.

Figure 4: Use separate OUs for computer and user accounts.
Also, try to avoid using Blocking, Enforced, Loopback, and other ways of modifying the default Group Policy inheritance order. That’s because using these features can make it really hard to troubleshoot why Group Policy isn’t doing what you intend it to do. If you find you absolutely must use these features in your Group Policy design, you probably haven’t designed your Active Directory structure very well. The one exception to this rule is security filtering, which is a powerful tool that can help make GPO targeting more accurate without complicating the design. I’ll cover security filtering in a future article on WindowsNetworking.com.
Finally, avoid making changes to the Default Domain Policy. Instead, create a new GPO, link it to the domain, and configure its settings as needed. But be very careful what you configure in any GPO linked to a domain because any settings you configure will be inherited by all computer and user accounts in all OUs in the domain. So the moral is, wherever possible configure policy at the OU level and not at the domain level, and use domain GPOs only for configuring account policy for the domain.