The Two Default Group Policy Objects

The Two Default Group Policy Objects

Whenever you create a new domain, three things automatically happen:

  • The initial (and only) OU, named Domain Controllers , is created automatically by the DCPROMO process.

  • A default GPO is created and linked to the domain level, called "Default Domain Policy."

  • A default GPO is created for the Domain Controllers OU, called "Default Domain Controllers Policy."

This section helps answer, "Why are these GPOs different from all other GPOs?"

These two GPOs are special. First, you cannot easily delete them (though you can rename them). Next, it's a best practice to only modify these GPOs for the security settings that we'll describe in this section. Too often, people will modify the "Default Domain Controller Policy" GPO or "Default Domain Policy" GPOonly to mess it up beyond recognition. So, these special default GPOs systems shouldn't be modified with the "normal stuff" you do, day to day. In general, stay clear of them, and modify them only when a setting prescribed for them is actually required.

Instead of modifying the "Default Domain Controller Policy" GPO or "Default Domain Policy" GPO for normal stuff, you should create a new GPO and link it at the level you want, then implement your policy settings inside that new GPO.

Note 

The "Default Domain Policy" GPO and "Default Domain Controllers Policy" GPO can actually be deleted, but I strongly recommend that you don't. If you truly want to delete either of the default policies, you'll need to add back in the "Delete" Access Control entry to a group you belong to, Domain Administrators, for instance. Even then, I can't see why you would want to delete them. If you want to disable their link for some reason (again, I can't imagine why), do that, but leave the actual GPOs in place.

It's not that the GPOs themselves are really all that different, but rather that the location of these GPOs is special, as you'll see later in this chapter. The locations in question are the domain level and the Domain Controllers OU.

GPOs Linked at the Domain Level

If you take a look inside the domain level, you'll see one GPO that was created by default: the "Default Domain Policy." The purpose of this GPO is to set the default configurations for the "Account Policies" branch in the Group Policy Object Editor. These Account Policies encompass three important domain-wide security settings:

  • Password policy

  • Account Lockout policy

  • Kerberos policy

Again, the default policy settings are set inside the "Default Domain Policy" GPO and linked to the domain level. However, you can change the defaults of the Account Policies in one of several ways:

  • By modifying the "Default Domain Policy" GPO directly

  • By creating your own GPO linked to the domain level and changing the precedence order within the domain level

You'll see how shortly.

Again, the special part about the domain level of Group Policy is that this is the only place these three policy settings can be set for the domain. And the default settings for the domain are prespecified in the "Default Domain Policy" GPO.

If you try to set Password policy, Account Lockout policy, or Kerberos policy anywhere else in the domain, (say, at any OU or on any site), the settings are ignored when users log on to the domain; they don't matter, and only those linked to the domain level take effect.

Microsoft has taken a lot of heat for the fact that Account Policies must agree for all the accounts in the domain. This means that if two administrators of two OUs can't agree on Account Policies (usually things like password length), they'll need to split into two domainsa major administrative overhead and nightmare.

Special Policy Settings for the Domain Level

In addition to Password policy, Account Lockout policy, and Kerberos policy, three additional policy settings take effect only when a GPO is linked to the domain level. They are located under Computer ˜ Windows Settings ˜ Security Settings ˜ Local Policies ˜ Security Options:

  • Automatically Log Off Users When Logon Time Expires You can set up accounts so that users logged on to Active Directory must log off when they exceed the hours available to them.

  • Rename Administrator Account You can use this policy setting to forcefully rename the Administrator account. This works only for the Domain Administrator account when set at the domain level. This is useful as a level of "extra protection" so that no matter what the Administrator account is renamed to in Active Directory Users And Computers, it will "snap back" to this name after Group Policy refreshes. The "display name" in Active Directory Users And Computers won't actually change, but the underlying "real" name of the account will be changed.

  • Rename Guest Account You can rename the domain Guest account using this policy setting. This works only for the Guest account when set at the domain level.

Setting these three special security settings at any other level has no effect on domain accounts contained within Active Directory. However, if you linked a GPO containing these settings to an OU, the local computer would certainly respond accordingly .

Tip 

Again, these policies cannot affect domain accounts when a GPO containing these settings is linked to, say, the Sales OU or Marketing OU. This is because these policies must specifically affect the Domain Controllers OU (really, the Domain Controllers within them).

Modifying the "Default Domain Policy" GPO Directly

You can dive into the "Default Domain Policy" GPO in two ways. Use the Group Policy Management Console (GPMC), and click the domain name. You'll see the "Default Domain Policy" GPO linked to the domain level. If you try to edit the GPO at this level, you'll see the standard set of policy settings you've come to know and love while inside the Group Policy Object Editor. (Though again, as I've stated, you won't want to add "normal stuff" to this GPO.)

However, since the "Default Domain Policy" GPO is "special," Microsoft provides an alternate way to get right into the Security settings of the "Default Domain Policy." Follow these steps:

  1. Log on to the Domain Controller WINDC01 as a Domain Administrator.

  2. Choose Start ˜ Programs ˜ Administrative Tools ˜ Domain Security Policy.

You will be immediately placed into the "Default Domain Policy" GPO focused on the Security settings, as seen in Figure 6.1. These two methods are identical and modify the exact same location; however, the second method is a special "limited view" and shows only the security settings within the GPO.

image from book
Figure 6.1: The "Default Domain Policy" GPO (linked to the domain level) sets the domain's default Account Policies, Kerberos policy, and Password policy. If you link GPOs containing these policy settings anywhere else, they are essentially ignored when Active Directory is being used.

For instance, you can specify (among other settings) that the password length is 10 characters , the user is locked out after the third password attempt, and Kerberos ticket expiration time is 600 minutes. But these values are only valid for the entire domain.

Warning 

Again, if you want to add more policy settings at the domain level (which would WARNING affect all users or computers in the domain)great! But try to leave the "Default Domain Policy" GPO alone, except when you need to change the "special" policy settings as described in this section.

Creating Your Own Group Policy Object Linked to the Domain Level and Changing the Precedence

Recall that at any level (site, domain, or OU), all the policy settings within all the GPOs linked to a level are merged unless there is a conflict. Then, the GPO with the highest precedence "wins" at a level. I talked about this in Chapter 2. The same is true regarding the settings special to the domain level: Password policy, Account Lockout policy, and Kerberos policy.

The defaults for these three policies are set within the "Default Domain Policy" GPO, but you could certainly create and link more GPOs to the domain level that would override the defaults. Though that doesn't necessarily mean that you should. Take a look at the example in Figure 6.2.

image from book
Figure 6.2: If you have a GPO with a higher precedence than the "Default Domain Policy" GPO, it will "win" if there's a conflict.

Here, a GPO is higher in priority than the "Default Domain Policy." If you do this, you better know precisely what you are doing! Again, this is because any policy setting within any GPO with a higher priority than the "Default Domain Policy" GPO will "win."

Which Approach Do You Take?

As you've seen, you can either modify the "Default Domain Policy" GPO or create your own GPO and ensure that the precedence is higher than the "Default Domain Policy" GPO. If you need to modify a special domain-wide account policy setting, which approach do you take? Here are the two schools of thought:

  • School of Thought #1 Modify only the Account Policies settings in the "Default Domain Policy" GPO. Then, ensure that it has the highest precedence at the domain level. This guarantees that if anyone does link other GPOs to the domain level, this one always wins.

  • School of Thought #2 Leave the defaults in the "Default Domain Policy" GPO. Never modify the "Default Domain Policy" GPOever. Create a new GPO for any special settings you want to override in the "Default Domain Policy" GPO. Then, link the GPO to the domain level, and ensure that it has higher precedence than the "Default Domain Policy" GPO (as seen in Figure 6.2).

Various Microsoft insiders have given me different (sometimes conflicting) advice about which to use. So what do I think?

If you want to modify any special domain-wide security settings, use School of Thought #1. This is the simplest and cleanest way. If you do it this way, you'll always treat the "Default Domain Policy" GPO with kid gloves and know it has a special use. And you can check in on it from time to time to make sure no one has lowered the precedence on it. Additionally, some applications, such as Microsoft SMS, will specifically modify the Default Domain Policy GPO. Hence, if you want that application to run smoothly, it's best to let it do what it wants to do.

School of Thought #2 has its merits. Leave the "Default Domain Policy" GPO "clean as a whistle ," and then create your own GPOs with higher precedence settings. However, I don't think this is a great idea, because you might forget that you set something important inside this new GPO.

Either way works, but my preference is for School of Thought #1.

Group Policy Objects Linked to the Domain Controllers OU

How is the Domain Controllers OU different? You can see there is also a default GPO linked, named the "Default Domain Controllers Policy" GPO. But, before we dive into it, let's take a step back. First, it's important to think of all the Domain Controllers as essentially equal. If one Domain Controller gets a policy setting (Security setting or otherwise ), they should all really be getting the exact same policy settings. On logon, users choose a Domain Controller for validation at random; however, you want the experience they receive to be consistent, not random. Moreover, when you, as the Domain Administrator, log on to a Domain Controller at the console, you also want your experience to be consistent.

Oh, and did I mention that when servers are finished being promoted into Domain Controllers via DCPROMO, they automatically end up in the Domain Controllers OU? So, that's where the "Default Domain Controllers Policy" GPO comes in to play. Again, it's easy to find the "Default Domain Controllers Policy" GPO. It's linked to the Domain Controllers OU.

You can also get right into the Security settings of the "Default Domain Controllers Policy" GPO by following these steps:

  1. Log on to the Domain Controller WINDC01 as a Domain Administrator.

  2. Choose Start ˜ Programs ˜ Administrative Tools ˜ Domain Controller Security Policy.

You will be immediately placed into the "Default Domain Controllers Policy" GPO focused solely on the Security settings.

These two methods are essentially identical and modify the exact same location; however, the second method shows only the available security settings within the GPO. Since all Domain Controllers are, by default, nestled within the Domain Controllers OU, all Domain Controllers are affected by all the aspects inside the "Default Domain Controllers Policy" GPO. Of specific note are the Security settings, as shown in Figure 6.3.

image from book
Figure 6.3: The "Default Domain Controllers Policy" GPO affects every Domain Controller in the domain.

For instance, you'll want the same Event Log settings for all Domain Controllers. You'll want to set it once, inside a GPO linked to the Domain Controllers OU, and have it affect all Domain Controllers. By default, the "Default Domain Controllers Policy" GPO has the following set to specific defaults, which should remain consistent among all Domain Controllers.

Tip 

Right-click any node and choose "Export List " from the shortcut menu to export to a text file for an easy way to document complex settings, such as User Rights Assignments.

Audit Policies Located in Computer Configuration ˜ Security Settings ˜ Audit Policy. Here you can change the default auditing policies of Windows 2000 or Windows 2003. Windows 2000 is a little light for my taste, and Windows 2003 is a little strong. We talk about auditing later in this chapter in the "Auditing with Group Policy section.

User Rights Assignment Located in Computer Configuration ˜ Security Settings ˜ User Rights Assignment. Here you can configure which accounts you will "Allow log on locally" or "Log on as a service" among other specific rights.

Domain Controller Event Log Settings Located in Computer Configuration ˜ Security Settings ˜ Event Log. Set them here, and all Domain Controllers will obey. Settings such as the maximum size of logs are contained here. Note, however, that decreasing the size of an Event Log will not take effect on the DCs; you can enforce a log size increase, but not a decrease.

Various Security Options Located in Computer Configuration ˜ Security Settings ˜ Local Policies ˜ Security Options. Here you'll find settings such as "Interactive logon: Do not display last user name," which will affect the behavior of clients , servers, and/or Domain Controllers. Windows 2000 domains have different names for these settings. In "Security Options Comparison" on this book's website. You can download a chart that shows how to convert between Windows 2000 domains and Windows 2003 domains.

The same rules apply to the Domain Controllers OU as they do for the domain level. That is, you can put a GPO in at a higher precedence than the "Default Domain Controllers Policy" GPO. However, my recommendation is to use the "Default Domain Controllers Policy" GPO for the "special" things that you set at this level, and ensure that it's got the highest precedence when being processed within the OU.

image from book
Mea Culpa

In the first edition of this text, I made a mistake. It was a whopper. And I'm sorry if my mistake caused you any harm. I claimed that the "Default Domain Controllers Policy" GPO itself had one additional "superpower." That is, I claimed that the "Default Domain Controllers Policy" GPO would hunt down and affect any Domain Controller no matter which OU the Domain Controller was in. That isn't true. Not at all. But, upon reflection, I can see where I made my mistake, and I can explain, at least, why I thought this was the case.

If you modify the "Default Domain Controllers" GPO after a Domain Controller has been moved to another OU and then forcefully perform a background refresh on the Domain Controller, that Domain Controller will pick up the changes. However, once the Domain Controller realizes that it has been moved to another OU (between 30 and 120 minutes), the Domain Controller will stop honoring the policies in the Domain Controllers OU.

I performed a bad test and didn't wait 120 minutes (or reboot the machine). I got bad data and reported it. So, again, I apologize. In short: don't move your Domain Controllers out of the Domain Controllers OU. You'll get erratic behavior, your Domain Controllers won't all be alike in the settings they receive, and they'll receive error messages in the Event Log. All in allnot good.

image from book
 

Oops, the "Default Domain Policy" GPO and/or "Default Domain Controllers Policy" GPO Got Screwed Up!

If you modify the "Default Domain Policy" GPO or "Default Domain Controllers Policy" GPO such that you want to return it back to the defaults, you might just have a shot. The procedure is different for Windows 2000 domains or those with Windows 2003 Domain Controllers. First, you'll need to determine which default GPO got screwed up; then you need to take the appropriate steps. These procedures are among the most popular request for Microsoft Product Support Services. However, these tools should be performed only as an absolute last resort because it will restore your defaults as if the installation were done "out of the box." So, be careful. If you have a backup of your defaults, you should try to perform a restore firstbefore using these "emergency only" tools.

Repairing the Defaults for Windows 2003 Domains

As long as you have even one Windows 2003 Domain Controller, you have it made in the shade . Well, not too made, as you might already be in the doghouse if the default GPOs are screwed up. However, Windows 2003 domains with their Windows 2003 Domain Controllers come with a new command-line tool, DCGPOFIX , to make it easy to restore back to the defaults. You can tell DCGPOFIX to restore the "Default Domain Policy" GPO (with the /Target:Domain switch) or the "Default Domain Controllers Policy" GPO (with the /Target:DC switch.) Or both with the /Target:BOTH switch, as in Figure 6.4.

image from book
Figure 6.4: Use DCGPOFIX with Windows 2003 Domain Controllers to restore the defaults if necessary.

Optionally, you can simply reset the User Rights Assignment for Windows 2003 instead of plowing back the entire "Default Domain Controllers" GPO. To do so, see the Knowledge Base article "HOW TO: Reset User Rights in the Default Domain Group Policy in Windows Server 2003" (KB 324800).

Repairing the Defaults for Windows 2000 Domains

If the "Default Domain Policy" GPO or "Default Domain Controller Policy" GPO for a Windows 2000 domain get irreparably damaged, you can download and run a tool that was previously available only to customers when they called Microsoft Product Support Services. That is, Windows 2000 now has an equivalent to Windows 2003's DCGPOFIX. But its name is RecreateDefPol, and you have to download it. Here's a ( shortened ) link to the tool: www.tinyurl.com/3yyr3 .



Group Policy, Profiles, and IntelliMirror for Windows 2003, Windows XP, and Windows 2000
Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)
ISBN: 0782144470
EAN: 2147483647
Year: 2005
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net