About permissions and security groups

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

In this article, you learn about access levels and permissions through inheritance, security groups, roles, and more in Azure DevOps.

For an overview of default permissions, see Default permissions quick reference.

For more information, see Security overview.

Access levels

All Azure DevOps users have an access level, which grants or restricts access to specific web portal features. Three main access levels exist: Stakeholder, Basic, and Basic + Test Plans. To give a user access to Agile portfolio management or test case management features, change access levels, not permissions. For more information, see About access levels.

Permissions

All users in Azure DevOps belong to one or more default security groups. Assign permissions to security groups that either Allow or Deny access to features or tasks.

• Members inherit the permissions assigned to their security group.
• Define permissions at different levels: organization/collection, project, or object.
• Manage some permissions through role-based assignments (for example, team administrator, extension management, or pipeline resource roles).
• Administrators can define custom security groups to manage permissions for different functional areas.

Managing permissions in Azure DevOps involves two key groups: Project Collection Administrators and Project Administrators.

Project Collection Administrators:

• Have broad administrative permissions within an organization or project collection.
• Manage settings, policies, and processes for the organization.
• Create and manage projects.

Project Administrators:

• Operate at the project level.
• Manage security groups and permissions from the Project settings in the web portal.
• Handle permissions for specific objects contributors create within the project.

Permission states

Assign permissions to grant or restrict access:

User or group has permission:

• Allow
• Allow (inherited)
• Allow (system)

User or group doesn't have permission:

• Deny
• Deny (inherited)
• Deny (system)
• Not set

Azure DevOps calculates effective permissions from direct assignments, group memberships, and inherited assignments. When it combines assignments at the same scope, Deny generally takes precedence over Allow. In an object hierarchy, an explicit assignment on a child object can replace the value inherited from its parent for the same identity.

Permission inheritance

Permissions follow a hierarchy, so you can inherit permissions from a parent node or override them.

Group inheritance:

• Users receive the combined permissions of the groups they belong to.
• At the same scope, a Deny from one group generally takes precedence over an Allow from another group.
• Not set doesn't grant or deny a permission and doesn't override an assignment from another group.

Object-level inheritance:

You assign object-level permissions to nodes like areas, iterations, version control folders, and work item query folders. These permissions are inherited down the hierarchy.

Object hierarchy rules:

• Permissions set at a higher-level node get inherited by all subnodes unless explicitly overridden.
• If a permission isn't explicitly allowed or denied for a subnode, it inherits the permission from its parent.
• If a permission is explicitly set for an identity on a subnode, the value inherited from the parent for that identity doesn't apply on the subnode.
• After resolving the object hierarchy, Azure DevOps combines the applicable direct and group assignments. A Deny from another group at the resulting scope can still take precedence over an Allow.

Example:

• Explicitly Deny on area-1 (parent node).
• Explicitly Allow for area-1/sub-area-1 (child node).
• In this case, the user receives an Allow on area-1/sub-area-1, overriding the inherited Deny from the parent node.

To understand why a permission is inherited, select Why? for that permission. To open a Security page, see View permissions.

Security groups and membership

Security groups assign specific permissions to their members.

When you create an organization, collection, or project, Azure DevOps creates a set of default security groups and automatically assigns default permissions to these groups. You define more security groups by using the following actions:

• Creating custom security groups at the following levels:
  • Project-level
  • Organization- or collection-level
  • Server-level (on-premises only)
• Adding a team, which creates a team security group

You can't create an object-level security group, but you can assign a custom group to an object-level and assign permissions to that level. For more information, see Set object-level permissions.

Default security groups

Most Azure DevOps users are added to the Contributors security group and granted the Basic access level. The Contributors group provides read and write access to repositories, work tracking, pipelines, and more. Basic access provides access to all features and tasks for using Azure Boards, Azure Repos, Azure Pipelines, and Azure Artifacts. Users who need access to manage Azure Test Plans require Basic + Test Plans or an applicable Visual Studio subscription benefit.

Add users who manage project-level features to the Project Administrators group. These features include teams, area and iteration paths, repositories, service hooks, and service endpoints.

Add users who manage organization or collection-level features to the Project Collection Administrators group. These features include projects, policies, processes, retention policies, agent and deployment pools, and extensions. For more information, see About user, team, project, and organization-level settings.

Membership, permission, and access level management

Azure DevOps controls access through these three inter-connected functional areas:

• Membership management supports adding individual user accounts and groups to default security groups. Each default group is associated with a set of default permissions. All users added to any security group are added to the Valid Users group. A valid user is someone who can connect to a project, collection, or organization.
• Permission management controls access to specific functional tasks at different levels of the system. Object-level permissions set permissions on a file, folder, build pipeline, or a shared query. Permission settings correspond to Allow, Deny, Inherited allow, Inherited deny, System allow, System deny, and Not set.
• Access level management controls access to web portal features. Based on licensing and the user's role, administrators assign Stakeholder, Basic, Basic + Test Plans, or an applicable Visual Studio subscription access level.

Each functional area uses security groups to simplify management across the deployment. You add users and groups through the web administration context. Permissions are automatically set based on the security group that you add users to. Or permissions are based on the object, project, collection, or server level to which you add groups.

Active Directory and Microsoft Entra security groups

You can populate security groups by adding individual users. But, for ease of management, it's more efficient to populate these groups using Microsoft Entra ID for Azure DevOps Services and Active Directory (AD) or Windows user groups for Azure DevOps Server. This approach allows you to manage group membership and permissions more effectively across multiple computers.

If you only need to manage a small set of users, you can skip this step. But, if you anticipate that your organization might grow, consider setting up Active Directory or Microsoft Entra ID. Also, if you plan to use extra services, it's essential to configure Microsoft Entra ID for use with Azure DevOps to support billing.

Valid user groups

When you add user accounts directly to a security group, the users automatically become part of one of the following valid user groups.

The default permissions assigned to these groups primarily provide read access, such as View build resources, View project-level information, and View collection-level information.

To access project resources, a user needs View project-level information and any permissions required for the specific resource. Area path permissions control access to work items and test artifacts within a project; they don't control whether a user can access the project. Don't change the default permissions for a Valid Users group. Denying View project-level information, View collection-level information, or View instance-level information to one of these groups can block all its members from the corresponding scope.

Role-based permissions

With role-based permissions, you assign user accounts or security groups to a role, and each role has one or more permissions. The following resources support role-based permissions:

• Artifact or package feed security roles
• Marketplace extension Manager role
• Pipeline security roles
• Team administrator role

For more information, see About pipeline security roles.

Members of the Project Administrators or Project Collection Administrators groups manage all team tools for all teams.

Preview features

Preview features provide early access to functionality before it becomes generally available. Users can manage preview features offered at the user level. Members of the Project Collection Administrators group can manage organization-level preview features in Azure DevOps Services and collection-level preview features in Azure DevOps Server. For more information, see Manage or enable features.

Next step

Related content