Group Policy is an integral part of every Active Directory enterprise. As soon as Active Directory is installed,...
Group Policy is put into action with default Group Policy Objects (GPOs) and settings. The default configuration of the settings in the default GPO is important for the security of the organization. The default settings propagate down to new user and computer accounts as they are created in the domain. Understanding this propagation, or inheritance, of GPO settings is essential to ensure the default settings are maintained properly and that the new GPOs and settings are properly designed and implemented.
There are two default GPOs in every Active Directory domain:
- Default Domain Policy
- Default Domain Controllers Policy
The primary responsibility of the Default Domain Policy is to establish the account policies for all domain user accounts, as well as the local accounts that exist in the local Security Accounts Manager (SAM) of member servers and clients in the domain. This GPO is linked to the domain node in Active Directory.
The primary responsibility of the Default Domain Controllers Policy is to establish the User Rights for the domain controllers in the domain. This GPO is linked to the Domain Controllers organizational unit (OU).
Understanding Group Policy inheritance
Group Policy inheritance is a little different than the permission inheritance that you are familiar with regarding files and folders. However, the overall concepts are the same. Let's take a look at the permission concept and then the Group Policy concept.
If you have a top-level folder that contains sub-folders and files at each level, the permissions established at the top-level folder would be inherited by all sub-folders and files. This is the default (and suggested) behavior of permissions.
For Group Policy, let's assume that you have a top-level organizational unit that contains sub-OUs and user accounts at each OU level. A GPO that is linked to the top-level OU would affect all user accounts down through this OU structure. It acts like inheritance, but it is really called scope of management. Since the user accounts are under the OU hierarchy where the GPO is linked, they will receive the settings in the GPO related to users.
Like anything else, the default inheritance can be altered with settings like "Block Inheritance" and "Enforce" inheritance. These settings negate the behavior detailed above and can cause some security weaknesses if not completely considered. This insecure environment is exacerbated with the complexity that is added when trying to troubleshoot Group Policy with these settings made. Therefore, these settings should be avoided unless they are designed for, and even then should be used sparingly.
Group Policy Applications
Group Policy settings apply to two types of objects: user accounts and group accounts. Each GPO has two parts when you're editing them in the Group Policy Object Editor: User Configuration and Computer Configuration. All of the settings under the Computer Configuration target computer accounts, and likewise all the settings under User Configuration target user accounts.
Therefore, if we go back to our simple example and expand on it a bit, we can clearly see how Group Policy applies to objects located in Active Directory. The GPO that is linked to the top-level OU has Start Menu policies configured, which all fall under the User Configuration part of the GPO. This means that if I swap the user accounts out of these OUs and replace them with only computer accounts, no objects would be affected by the GPO settings related to the Start Menu.
Group Policy can be a bit confusing, but once you get the core concepts down, it is much easier to tackle its implementation. Understanding that GPOs inherit down to objects that reside in the OU structure is the first key concept. Second, the correct object type must be in the Scope of Management of the GPO, so the correct settings can affect the correct object types.
About the author: Derek Melber, MCSE, MVP and CISM, is the director of compliance solutions for DesktopStandard Corp. He has written the only books on auditing Windows security available at The Institute of Internal Auditors' bookstore and also wrote the Group Policy Guide for Microsoft Press -- the only book Microsoft has written on Group Policy. You can contact Melber at firstname.lastname@example.org.