About permissions and security groups

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

In this article, learn about access levels and permissions via 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 best practices.

Access levels

All Azure DevOps users have an access level, which grants or restricts access to specific web portal features.

There are three main access levels: Stakeholder, Basic, and Basic + Test Plans. Use the Stakeholder access level for users who don’t need paid access. Don't use Stakeholder access as a substitute for more limited permissions, as users with a Visual Studio subscription or a GitHub Enterprise license automatically get upgraded from Stakeholder when they sign in. For more information, see Stakeholder access quick reference.

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. Security groups get assigned permissions that either Allow or Deny access to features or tasks.

• Members inherit the permissions assigned to their security group.
• Permissions get defined at different levels: organization/collection, project, or object.
• Some permissions get managed 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.

For more information, see Security best practices.

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

Project Collection Administrators:

• Hold the highest authority within an organization or project collection.
• Perform all operations for the entire collection.
• Manage settings, policies, and processes for the organization.
• Create and manage all projects and extensions.

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

Members of the Project Collection Administrators or Team Foundation Administrators groups might always receive permissions even if denied in another group. The following examples explain this scenario further:

• A user might still access project settings or manage users. However, for tasks like work item deletion or pipeline management, being a member of the Project Collection Administrators group doesn't override Deny permissions set elsewhere.
• If a user is denied permission to delete work items in a specific project, they can't delete work items even if they're part of the Project Collection Administrators group. Similarly, if pipeline permissions are denied, they can't manage or run pipelines despite their administrative role.

Permission inheritance

Permissions follow a hierarchy, allowing inheritance from a parent node or overriding it.

Group inheritance:

• Users inherit permissions from the groups they belong to.
• If a user has an Allow permission directly or through group membership but also has a Deny permission through another group, the Deny permission takes precedence.
• Members of Project Collection Administrators or Team Foundation Administrators retain most allowed permissions, even if they belong to other groups that deny those permissions (except for work item operations).

Object-level inheritance:

Object-level permissions, assigned to nodes like areas, iterations, version control folders, and work item query folders, get inherited down the hierarchy.

Permission inheritance and specificity rules:

• Explicit permissions always take precedence over inherited ones.
• 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 a subnode, the parent’s permission isn't inherited, regardless of whether allowed or denied.

Specificity:

In the object hierarchy, specificity trumps inheritance. The most specific permission takes precedence if conflicting permissions exist.

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, you can pause over a permission setting, and then select Why? To open a Security page, see View permissions.

Security groups and membership

Security groups assign specific permissions to their members.

With the creation of an organization, collection, or project—Azure DevOps creates a set of default security groups, which are automatically assigned default permissions. More security groups are defined with the following actions:

• When you create custom security groups at the following levels:
  • Project-level
  • Organization- or collection-level
  • Server-level (on-premises only)
• When you add a team, a team security group gets created

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 get added to the Contributors security group and granted 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 require access to manage Azure Test Plans need to be granted Basic + Test Plans or Advanced access.

For users tasked with managing project-level features—such as, teams, area and iteration paths, repositories, service hooks, and service end points—add them to the Project Administrators group.

For users tasked with managing organization or collection-level features—such as, projects, policies, processes, retention policies, agent and deployment pools, and extensions—add them to the Project Collection Administrators group. 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 purchased for a user, administrators set the user's access level to Stakeholder, Basic, Basic + Test, or Visual Studio Enterprise (previously Advanced).

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 get 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 accounts of users directly to a security group, they automatically get added to 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.

All users you add to one project can view the objects in other projects within a collection. To restrict view access, you can set restrictions through the area path node.

If you remove or deny the View instance-level information permission for one of the Valid Users groups, no members of the group are able to access the project, collection, or deployment, depending on the group you set.

Role-based permissions

With Role-based permissions, you assign user accounts or security groups to a role, with each role assigned one or more permissions. Here are the primary roles and links to more information.

• Artifact or package feed security roles: Roles support various permission levels to edit and manage package feeds.
• Marketplace extension Manager role: Members of the Manager role can install extensions and respond to requests for extensions to be installed.
• Pipeline security roles: Several roles are used to manage library resources, project-level, and collection-level pipeline resources.
• Team administrator role Team administrators are able to manage all team tools.

For more information, see About security roles.

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

Preview features

Feature flags control access to new features. Azure DevOps periodically introduces new features behind a feature flag. Project members and organization owners can enable or disable preview features. For more information, see Manage or enable features.

Next steps

Related articles