Introduction:
In Active Directory (AD), there is a significant feature called Group Policy that allows you to implement specific settings for users and computers. Administrators can apply hundreds of different settings to objects in AD by establishing Group Policy Objects (GPOs) and associating the GPO to domains, sites, and organizational units (OUs). Ironically, the versatility of Group Policy can also raise its complexity. It can specify a single setting for an entire domain, but it cannot easily specify distinct settings for hundreds of users or computers distributed across multiple geographic locations. Also, when numerous policies exist, it might be difficult to determine which settings are applied to a certain user or computer.
In the AD hierarchy, group policy settings that are related to parent objects are inherited by child objects. Also, Default Domain Policy is linked to the domain and is inherited by all domain hierarchy child objects. This is called GPO inheritance. It enables administrators to specify a common set of policies at the domain or site level while configuring specific policies at the OU level.
Group policy inheritance is useful in many cases. For example, assume you need to make some changes to your finance department. You can establish a GPO called “Finance Configuration” and link it to the Finance OU. After linking, the “Finance Configuration” is applied to all Finance OU users and everything the OU includes.
GPO inheritance and blocking:
In Active Directory, GPOs are inherited automatically throughout the GPO application order. If a group policy setting is enabled at the highest domain level but is not configured at the OU level, the highest domain level setting takes precedence and is applied. Similarly, if a setting is not configured at the domain level and is disabled at the OU level, the OU setting is inherited.
A user or a computer in an OU can have multiple GPOs applied to it. For example, Local Group Policy, GPOs linked to the site, GPOs linked to the domain, and GPOs linked to the OU. Also, multiple GPOs can be linked to any of these containers. The following is the order in which the Group Policy settings take effect.
- Local Group Policy settings are applied first.
- GPOs linked at the site level are applied next followed by the GPOs linked at the domain level and OU level. Since GPOs linked to the OU are processed last, they have the highest precedence.
- In the case of nested OUs, GPOs linked to the parent OUs are applied first followed by the GPOs linked to the child OU.
- If multiple GPOs are linked to a container, then the GPO with the lowest link order will have the highest precedence.
- To view the list of GPOs applied to a container, double-click the container and select the Group Policy Inheritance tab in the right pane. A list of GPOs with link order, location, and status will be displayed.
The final configuration of policy settings applied to a user or computer combines all the policy settings defined in each GPO. In case of any conflicts, the policy settings configured for the GPO with higher precedence override the GPO with lower precedence. However, this behavior can be altered using the block inheritance option. To block inheritance and apply only the policy settings configured in GPOs linked to a particular OU, right-click the OU and select Block Inheritance. This will block all the policy settings from GPOs linked at the domain level, site level, and parent OUs.
Enforcing a GPO:
GPOs can be enforced so that the GPOs linked to a higher level container like domain or a parent OU takes precedence over the GPOs linked to a lower level container. To enforce a GPO, select the GPO linked to a container. Right-click the GPO and select Enforced.
GPOs that are enforced will be applied to a lower-level container even when the ‘Block Inheritance’ option is enabled for that container. Learn how you can force a group policy update from here.
Disabling a GPO:
By default, both the Computer Configuration and User Configuration policy settings of a GPO are enabled and applied to all users and computers present in the container in which the GPO is linked. But, situations may arise in which the GPO has to be disabled for a particular period. To disable a GPO, follow these steps:
- In the left pane of the GPMC snap-in, double-click the container to see a list of GPOs linked to that container.
- Select the GPO which has to be disabled. In the right pane, select the Details tab.
- In the GPO status drop-down list, select any of the following settings.
- “All settings disabled” to disable the GPO.
- Select “Computer Configuration Settings disabled” to disable only the policy settings configured under computer configuration.
- Select “User Configuration Settings disabled” to disable only the policy settings configured under user configuration.
Configuring inheritance using PowerShell
The PowerShell console can be used to configure inheritance. The steps for managing inheritance are as follows:
Block & unblock inheritance:
- Open PowerShell.
- Run the following cmdlet to block or unblock inheritance for a specified domain or organizational unit (OU):
Set-GPInheritance
[-Target] <String>
-IsBlocked <BlockInheritance>
[-Domain <String>]
[-Server <String>]
[-WhatIf]
[-Confirm]
[<CommonParameters>]
Note: The Target option specifies the domain or OU’s Lightweight Directory Access Protocol (LDAP) distinguished name, while the IsBlocked parameter specifies whether to block or unblock inheritance.
Obtain inheritance information:
- Open PowerShell.
- To obtain Group Policy inheritance information for a specific domain or OU, use the following cmdlet:
Get-GPInheritance
[-Target] <String>
[-Domain <String>]
[-Server <String>]
[<CommonParameters>]
Active Directory empowers administrators with increased control over Group Policy Objects. Group Policy management features such as Block/Unblock Inheritance and Group Policy Enforcement give administrators the options they need to successfully implement Group Policies within Active Directory, particularly in large organizations where multiple GPOs are applied at different levels within the Active Directory, which may cause some GPOs to accidentally override others.
