<

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x

A Simple Explanation of Group Policy Inheritance in Active Directory

Published on
7,914 Points
2,214 Views
7 Endorsements
Last Modified:
Joseph Hornsey
I built my first network in 1994 using PowerLAN.  From there I messed around with NetWare and then moved to Windows NT and Cisco.
Trying to figure out group policy inheritance and which settings apply where can be a chore.  Here's a very simple summary I've written which might help.  Keep in mind, this is just a high-level conceptual overview where I try to avoid getting bogged down in the details.
Group Policy is an incredibly powerful feature in Active Directory that allows one to implement specific configurations for users and computers. By creating Group Policy objects (GPOs), administrators can apply thousands of different settings to objects within Active Directory by linking the GPO to sites, domains, or organizational units (OUs).

Unfortunately, Group Policy's flexibility can also increase its complexity.  It's one thing to specify a single setting, such as a password complexity rule, to the entire domain.  It's an entirely different thing to specify unique configurations for thousands of users or computers spread across different geographic areas.  One area where there can be confusion is in determining which settings are applied to a particular user or computer when multiple policies exist.

Inheritance in Group Policy works very similarly to inheritance when it comes to NTFS permissions.  The basic rule is "settings on parent objects are inherited by child objects".

For example, let's say you have an Organizational Unit (OU) hierarchy as follows:

AD-1.PNGEvery Active Directory domain has a "Default Domain Policy" which is a Group Policy Object (GPO) which contains the default settings for the domain.  That GPO is linked to the domain:

DDP.PNG

Because it is linked to the domain, every OU under the domain inherits the settings of the Default Domain Policy GPO.

Let's say the Default Domain Policy configures users to get a green desktop background.  Regardless of where your user account is in the domain, you end up with a green desktop because the settings in the Default Domain Policy are inherited by all child objects (everything in the domain).

ddp-green.pngNobody has to enforce this; it's just how Group Policy works.

Now, let's say that you need to create some settings for your sales department.  So you create a GPO called "Sales Stuff" and you link it to the Sales OU:

ssgpo.pngOnce you do that, the settings in Sales Stuff is applied to everything in the Sales OU, including Managers, Sales Reps and Sales Admin and everything they contain.  Again, this is just how Group Policy works.

When multiple GPOs are applied, they are applied from the top down.  So, the first GPO applied is the Default Domain Policy and the second is the Sales Stuff.  (It's not quite like that, but close enough for this discussion).

As each policy is applied, it will overwrite conflicting settings that previous policies applied.  In our example, the Default Domain Policy GPO changes the desktop color to green.  But, let's say the Sales Stuff policy has the desktop color set to yellow.

Well, the first policy applied when you logon is the topmost policy.  That's the Default Domain Policy.  So, it changes the setting on your computer to make the desktop background green.  However, the Sales Stuff policy is applied next and it changes the setting to make the desktop background yellow.

ssp-yell.png
The end result is your desktop is yellow.

Keep in mind, this only applies for configured settings which conflict with each other.  In this case, the desktop color.  But, if the Default Domain Policy also dictated what kind of mouse pointer you had, and that wasn't specified in the Sales Stuff policy, the Default Domain Policy settings would be there, and because they won't get overwritten by the Sales Stuff GPO, they would apply.

Well, the CEO will have none of that!  By God, those desktops are going to be green, or some heads are going to roll!

No problem.  In your Group Policy Management console, right-click on the Default Domain Policy and select "Enforced".

Untitled.png
Now, the Sales Stuff policy cannot overwrite the Default Domain Policy settings (and neither can any other GPO).  So, when you log on, any setting the Sales Stuff policy would have overwritten, including the desktop color, are kept intact.

ssp-green.pngSo, regardless of the Sales Stuff settings, your desktop is green.

This is a very simplified explanation, but I hope it might clear up some fog on how this works.

Feel free to get in touch with questions or comments.  If you find this article helpful, please give it a thumbs up!

Thanks!
7
Comment
2 Comments
LVL 67

Expert Comment

by:Jim Horn
Nice article on a large Active Directory and SQL Server permissions issue that DBA's work with a lot.  Nicely illustrated as well.  Voting Yes.
0
LVL 8

Expert Comment

by:Yashwant Vishwakarma
Nice article Joseph :)
got some idea about active directory concepts.
Voted YES.
1

Featured Post

OWASP: Avoiding Hacker Tricks

Learn to build secure applications from the mindset of the hacker and avoid being exploited.

Join & Write a Comment

This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month