4.2 Defining GP Repository Security Permissions and Scope

Other than members of the GPA_REPOSITORY_MANAGEMENT group created during GPA installation, by default, GPA users do not have permissions to perform any GPA tasks. You need to specifically grant permissions to each GPA user. You must also specify the objects in the GP Repository to which the user permissions apply, whether domains, categories, or GPOs.

You define GPA user security permissions and scope in GPA by adding GPA users to Active Directory groups and assigning specific GPA roles to those groups or by defining individual permissions for a GPA user for each object in the GP Repository.

4.2.1 Understanding Tasks and the GP Repository Structure

The GP Repository has a hierarchical structure similar to the structure of Active Directory. Starting at the top, the GP Repository has the following levels:

GP Repository
Domain
Category (similar to an OU in Active Directory)
GPO

Users can perform numerous tasks in the GP Repository. Refer to Section D.1, GP Repository Task Specifics, for a complete list of tasks and permission levels in the GP Repository.

4.2.2 Determining Security Inheritance Permissions

The GP Repository implements security inheritance. The following sections detail the rules that determine how security inheritance works.

Security Permission Levels

By default, any permission set at a higher level is propagated to lower levels. For example, assigning GPO approval permissions to a specific user for a category in the GP Repository grants approval permissions to that user for all GPOs in the category.

When you add a user or a group to a higher level in the GP Repository, the same user or group is automatically propagated to existing lower levels and to any newly created lower levels. For example, if you add a user account with certain security permissions to a GP Repository domain, the user account has the same security permissions for any categories and GPOs in the domain.

Local Permission Overrides

Permissions set on a lower level override permissions inherited from a higher level. If you explicitly set permissions on an object in the GP Repository, these security permissions override any inherited permissions. For example, a particular category inherits the Allow permission on the Delete Category task. By setting the permission to Deny for the Delete Category task, the new setting overrides the inherited Allow permission. The override is effective for the current category only.

Deny Permission Overrides

The Deny setting overrides the Allow setting. However, if a user has the explicit Allow permission for a task and the user is also member of a group for which the permission for that task is Deny, the user is allowed permission to perform that particular task.

The following table summarizes the resultant permissions for all possible combinations of explicit and inherited Allow and Deny permissions. A gray check box indicates an inherited permission.

Allow State	Deny State	Resultant Permission
		Deny
		Deny
		Deny
		Allow
		Deny
		Allow
		Allow

4.2.3 Configuring Security Attributes at Multiple Levels

Certain GP Repository tasks require configuration of security permissions at several levels in the GP Repository hierarchy. Some tasks in the GP Repository require a user to have a combination of permissions at several levels in the GP Repository hierarchy. For example, to import a GPO into a particular category in the GP Repository, a GPA user must have Import GPO from AD permissions at the domain level and Create GPO permissions at the category level.