A Group Policy Object (GPO) allows for the management of users, computers, and software. There are both local and domain-based GPOs. Local GPOs are created and applied at the level of the local computer. Domain GPOs are created at the domain level and can be linked to sites, domains, and organizational units (OU). Domain GPOs consist of the following components:
The GPC and GPT are linked by a common GUID. The GPC is an Active Directory object containing attributes and metadata about the GPO. The GPT holds the actual policies and is stored on a domain controller in SYSVOL.
Within Active Directory, GPOs can be passed and applied by inheritance. By default, GPOs are processed in the following order:
In this system, the last policy invoked is the one that applies. So a domain GPO would override a site GPO and the GPO of a child OU would override a GPO of its parent OU. This order can, however, be modified by various means. Link order can be custom-configured differently from the default. Also, policy inheritance from higher levels can be blocked at any lower level. Should such blocking be undesirable, it can be prevented though policy enforcement at the higher level.
Although it may seem that GPOs should apply directly to security groups, a somewhat less direct approach is in fact required. Domain GPOs are only effective if linked to a container, and the possible choices of such container are limited to sites, domains, and OUs. So to apply a GPO to a security group, the GPO must first be linked to a container including that group. Within a given container, GPO application can be filtered to include or exclude specific users, computers, and groups. So the most direct approach to creating a group-specific GPO would be to a) create the GPO, b) link it to the group's container, and c) filter GPO application to include the specific group.
References: