Access Denied: Blocking Inheritance and Overrides of Group Policies

Editor's Note: Do you have a security-related question about Windows 2000? Send it to rsmith@montereytechgroup.com, and you might see the answer in this column!

I want to make sure that I'm applying the security settings in my Group Policy Objects (GPOs) correctly. In group policy, what's the relationship between the Block Policy inheritance and No Override options, and how can I best use them?

In short, No Override takes precedence over Block Policy inheritance, but read on. Remember that Windows 2000 applies GPOs in a specific sequence. Win2K first applies a local computer's GPO, then (in order) any site-linked GPOs, domain-linked GPOs, and organizational unit (OU)—linked GPOs. When two or more GPOs define a value for the same policy (with very few exceptions, such as logon scripts), the last policy wins. For example, if you define the Audit account management category with Success, Failure at the domain level but specify Failure for the same policy in a GPO linked to a lower-level OU (i.e., OUs beneath the domain), computers in that lower-level OU will end up with the Audit account management category set to Failure.

You can specify the Block Policy inheritance setting on domains and OUs. To do so, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, double-click a domain or OU, and click the Group Policy tab, as Web-exclusive Figure 1 shows. If you select the Block Policy inheritance option at the domain level, when computers in this domain apply group policy, they won't apply any site-linked GPOs. If you select the Block Policy inheritance option on an OU, computers in this OU won't apply site-linked GPOs, domain-linked GPOs, or GPOs linked to higher-level OUs. Note that Win2K always applies a computer's local GPO regardless of Block Policy inheritance settings, but because the local GPO is the first one applied, any conflicting policies in subsequent GPOs override the local GPO. You can use the Block Policy inheritance option when you have a subset of computers or users that you want to insulate from policies you set at the domain or higher level. Put those users or computers in an OU and select the Block Policy inheritance check box. Now, you can manage those computers exclusively through GPOs linked to that OU.

What I've described is default behavior, but consider what happens when you use the No Override option. You select the No Override option by clicking that column in the list of GPOs that Figure 1 shows. No Override is a GPO link-level setting instead of a domain- or OU-level setting. Therefore, if you link the same GPO to more than one site, domain, or OU, the No Override setting won't follow the GPO. You can control No Override at each point at which a GPO is linked. If you specify No Override on a GPO link, the policies you've defined in that GPO override any conflicting policies in GPOs processed later in the group policy application sequence. Policies that you define in No Override GPO links defeat conflicting policies even in GPOs that specify the Block Policy inheritance setting or other subsequently applied GPOs that specify the No Override setting.

You can use the No Override setting to configure mandatory policies. For example, you might have certain default domain-level policies (i.e., you can override them at lower OUs to manage legitimate exceptions). You can configure these policies in the Default Domain Policy GPO. You might also have policies that you want to apply without exception to all computers or users in the domain. If so, define these mandatory policies in a new GPO that you create called Mandatory Domain Policies, link the Mandatory Domain Policies GPO to the domain, and configure the new GPO link with the No Override setting. Rest assured that policies that you define in Mandatory Domain Policies will override any policy conflicts that OU-linked GPOs inadvertently create at lower levels in the domain. For more information about how group policy works, see my two-part series, "Controlling Group Policy, Part 1," http://www.win2000mag.com, InstantDoc ID 15704, and "Controlling Group Policy, Part 2," http://www.win2000mag.com, InstantDoc ID 15886.

Discuss this Article 3

Graham (not verified)

on Apr 28, 2008

Nice article. But as far as I can see there's some kind of mismatch between article's header and contents. The header states 'Access Denied: Properly Applying Security Settings in GPOs' where's the article itself discusses group policy precedence and appliance procedures isn't it?