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.
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 GP Repository Task Specifics, for a complete list of tasks and permission levels in the GP Repository.
Under the server node in the GP Repository there is a GPR Security Management node. When you expand this node, there are three sub-nodes, ActiveViews, Roles, and Assignments.
You use these three sub-nodes to (1) create an ActiveView and define the permissions scope (where permissions get applied), (2) define access roles, using built-in or custom roles, and (3) select users and assign them to the roles on the ActiveView that you have defined.
The GP Repository implements security inheritance. The following sections detail the rules that determine how security inheritance works.
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.
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.
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.