Team Foundation Server Permissions

You can control access to the team projects and team project collections in your deployment of Visual Studio Team Foundation Server by understanding and configuring the permissions that are assigned to the users and groups in that deployment.

Permissions determine the authorization for user actions such as workspace administration and project creation. When you create a project in Team Foundation Server, four default groups are created for that project regardless of your choice of process template. By default, each of these groups has a set of permissions that are defined for them and that govern what members of those groups are authorized to do.

• Project Administrators

• Contributors

• Readers

• Builders

In addition to the default groups that are created for each team project, when you create a team project collection, seven default groups are created for that collection regardless of your choice of process template. Each of those groups also has a set of permissions that are defined for them.

• Project Collection Administrators

• Project Collection Service Accounts

• Project Collection Build Administrators

• Project Collection Build Service Accounts

• Project Collection Valid Users

• Collection Proxy Service Accounts

• Project Collection Test Service Accounts

Five default groups are created at the server level when you install Team Foundation Server. Each of these groups has a set of permissions that are defined for them.

• Team Foundation Administrators

• Team Foundation Service Accounts

• Team Foundation Valid Users

• SharePoint Web Application Services

• Work Item Only View Users

To effectively manage user membership in these default groups and to create custom groups, administrators must first understand the meaning of the permissions and the security implications for explicitly setting permissions.

Permission Settings

You can specify two explicit authorization settings for permissions in Team Foundation Server: Deny and Allow. There is also an implicit authorization that neither sets the permission to Allow nor sets the permission to Deny. This authorization is an implicit Deny setting that is referred to as Unset.

Deny

Deny denies authorization for the user or group to perform the actions that are stated in the permission description. Deny is the most powerful permission state in TFS. If a user belongs to a TFS group that has a specific permission set to deny, that user cannot perform that function, even if he or she belongs to another group that has that permission set to allow. The only exception to this rule occurs when the user is a member of the Project Collection Administrators group for a team project collection, or the Team Foundation Administrators group, unless otherwise stated in the description of the permission. By default, if a user is a member of an administrators group, the permissions of that group override an explicit deny for that user in Team Foundation Server. If a permission setting overrides the default administrative permission, that override is noted in the description of the permission in the tables below.

Allow

Allow grants authorization for the user or group to perform the actions that are stated in the permission description. Allow is the second-most powerful permission setting in Team Foundation Server and is set most frequently. If you do not explicitly set a permission to Allow, a user or group cannot perform that action in Team Foundation Server.

Unset

By default, most permissions in Team Foundation Server are not set to either Deny or Allow. The permissions are left unset, which implicitly denies both users and groups authorization to perform the actions that are specified in the permission description. However, because the permission is neither explicitly set to Deny nor explicitly set to Allow, authorization for that permission can be inherited from other groups of which the user or group is a member.

Inheritance

When permission is unset for a user or group, the user or group can be affected by the explicit setting for the permission for groups to which they belong because permissions in Team Foundation Server are inherited. For example, a user might belong to two custom groups in a project. If one of those groups has a permission that is explicitly set to Deny and the other group has the same permission unset, the user will not have permission to perform the actions that are controlled by that permission. The user inherits permissions from both groups, and the Deny permission takes precedence over the unset permission.

Certain authorization settings take precedence over other authorization settings. In Team Foundation Server, the Deny permission takes precedence over all other permission settings, including Allow, for that explicit structure. The Deny permission does not take precedence if it is inherited from a hierarchical parent, such as in version control. For example, a user might belong to two groups in a project. For one group, Publish test results permission is set to Deny; the other group has that permission set to Allow. The Deny setting takes precedence and the user is not authorized to publish test results. The only exceptions to this rule occur when either the explicit Deny is inherited from a hierarchical parent or the user is a member of one of the following groups:

• Project Administrators

• Project Collection Administrators

• Team Foundation Administrators

In hierarchical structures such as version control and work item tracking, the explicit permissions that are set on a particular object override those that are inherited from the parent objects.

Permissions Set Through the Team Foundation Server User Interface and Through the Command Line

Many of the permissions that you might want to set for Team Foundation Server are controlled through the Team Foundation Server user interface. You can set these permissions on a server basis (server-level permissions), a collection basis (collection-level permissions), or on a project basis (project-level permissions). You can also set area-level and iteration-level permissions for viewing and interacting with work items on a project basis. For more information about how to set permissions for users and groups, see Configuring Users, Groups, and Permissions and Managing Permissions.

Server-Level Permissions

Server-level permissions are not specific to a single team project or team project collection. They are set on a deployment-wide basis, and they grant permissions that can affect every project and collection in the deployment.

You can set these permissions for only two categories of users:

• Server-level users and groups, such as Team Foundation Administrators

• Custom groups that you create and add to the server level

You can set these permissions by opening the administration console for Team Foundation. You can also set these permissions by using the TFSSecurity command-line tool. For more information, see Configuring Your Server Using the Team Foundation Administration Console and Changing Groups and Permissions with TFSSecurity.

The following table lists each server-level permission and provides a brief description of its purpose.

Permission Name	Name at command line	Description
Administer warehouse	ADMINISTER_WAREHOUSE	Users who have this permission can change warehouse settings by using the ChangeSetting Web method of the WarehouseController.asmx Web service. For example, you could allow users to set the update interval for calculating the OLAP cubes.
Create team project collection	CreateCollection	Users who have this permission can create and administer team project collections in Team Foundation Server.
Delete team project collection	DeleteCollection	Users who have this permission can delete a team project collection from the deployment. Note Deleting a team project collection will not delete the database for the collection from SQL Server.
Edit instance-level information	GENERIC_WRITE tf: AdminConfiguration tf: AdminConnections	Users who have this permission can edit server-level permissions for users and groups in Team Foundation Server. They can add or remove server-level application groups from the collection. When set through the menus, the Edit instance-level information permission also implicitly allows the user to modify version control permissions. To grant all these permissions at a command prompt, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions in addition to GENERIC_WRITE. Note   Default server-level groups such as Team Foundation Administrators cannot be removed.
Make requests on behalf of others	Impersonate	Users who have this permission can perform operations on behalf of other users or services. This permission should be assigned only to service accounts.
Trigger Events	TRIGGER_EVENT	Users who have this permission can trigger alert events within Team Foundation Server. This permission should be assigned only to service accounts and members of the Team Foundation Administrators group.
Use full Web Access features	FullAccess	Users who have this permission can use all of the features of Team Web Access. If this permission is set to Deny, the user will not be able to see any Team Web Access features except those permitted to members of the Work Item Only View Users group. A Deny will override any implicit allow, even for accounts that are members of administrative groups such as Team Foundation Administrators.
View instance-level information	GENERIC_READ	Users who have this permission can view server-level group membership and the permissions of those users.

Collection-Level Permissions

Collection-level permissions are not specific to a single project. Instead, they are set on a collection-wide basis. You can set these permissions for only three categories of users:

• Collection-level users and groups, such as Project Collection Administrators

• Project-level groups that have been added to the collection level on your server that is running Team Foundation

• Custom groups that you create and add to the collection level

You can set these permissions by right-clicking the server in Team Explorer and then clicking Security, or you can set them in the administration console for Team Foundation. You can also set these permissions by using the TFSSecurity command-line tool, except for those command-line tools that have a tf: designation. For those tools with the tf: designation, use the Permission command of the tf command-line utility for version control to set the permissions. For more information, see Collection-Level Groups, Changing Groups and Permissions with TFSSecurity, and Permission Command.

Permission Name	Name at Command Line	Description
Administer shelved changes	tf: AdminShelvesets	Users who have this permission can delete shelvesets created by other users.
Administer workspaces	tf: AdminWorkspaces	Users who have this permission can create workspaces for other users and delete workspaces created by other users.
Alter trace settings	DIAGNOSTIC_TRACE	Users who have this permission can change the trace settings for gathering more detailed diagnostic information about Web services for Team Foundation Server.
Create a workspace	tf: CreateWorkspace	Users who have this permission can create a version control workspace.
Create new projects	CREATE_PROJECTS	Users who have this permission can create projects in the team project collection. Note You must not only have this permission but also run Visual Studio as an administrator to successfully complete the Create a New Team Project Wizard. For more information, see Create a Team Project.
Delete team project	Delete	Users who have this permission can delete team projects in the team project collection. Important Deleting a team project will delete all data that is associated with the project. You cannot undo the deletion of a team project except by restoring the collection to a point before the project was deleted.
Delete team project collection	DeleteCollection	Users who have this permission can remove a team project collection.
Edit collection-level information	GENERIC_WRITE tf: AdminConfiguration tf: AdminConnections	Users who have this permission can edit collection-level permissions for users and groups in the team project collection. They can add or remove collection-level Team Foundation Server application groups from the collection. When set through the menus, the Edit collection-level information permission also implicitly allows the user to modify version control permissions. To grant all these permissions at a command prompt, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions, in addition to GENERIC_WRITE. Note Default collection-level groups such as Project Collection Administrators cannot be removed.
Make requests on behalf of others	Impersonate	Users who have this permission can perform operations on behalf of other users or services. This permission should be assigned only to service accounts.
Manage build resources	ManageBuildResources	Users who have this permission can manage the build computers, build agents, and build controllers for the team project collection. These users can also grant or deny the View build resources and Use build resources permissions for other users.
Manage process template	MANAGE_TEMPLATE	Users who have this permission can download, create, edit, and upload process templates to the team project collection.
Manage test controllers	MANAGE_TEST_CONTROLLERS	Users who have this permission can register and de-register test controllers for the team project collection.
Manage work item link types	WORK_ITEM_WRITE	Users who have this permission can add, remove, and change the types of links for work items.
Trigger Events	TRIGGER_EVENT	Users who have this permission can trigger project alert events within the team project collection. This permission should be assigned only to service accounts.
Use build resources	UseBuildResources	Users who have this permission can reserve and allocate build agents. This permission should be assigned only to service accounts for build services.
View build resources	ViewBuildResources	Users who have this permission can view build controllers and build agents that are configured for the collection. To use those resources, you need additional permissions.
View collection-level information	GENERIC_READ	Users who have this permission can view collection-level group membership and the permissions of those users.
View system synchronization information	SYNCHRONIZE_READ	Users who have this permission can call the synchronization application programming interfaces. This permission should be assigned only to service accounts.
View test runs	VIEW_TEST_RESULTS	Users who have this permission can view test plans in this node.

Project-Level Permissions

Project-level permissions are specific to a single project's users and groups. You can set these permissions in Team Foundation Server by right-clicking the project in Team Explorer, clicking Team Project Settings, and then clicking Security. You can also set these permissions by using the TFSSecurity command-line tool.

Build-Level Permissions

Build-level permissions are specific to a single project's users and groups. You can set build permissions at the team project level, and you can also set permissions for specific build definitions. You can set these permissions by opening the project in Team Explorer, right-clicking Builds, and then clicking Security. You can apply permissions to a specific build definition by right-clicking the build definition and then clicking Security. If you want to apply permissions to a build folder, right-click that folder, and click Security. Additionally, you can set these permissions by using the TFSSecurity command-line tool.

Work item query permissions

Work item query permissions are specific to the queries and query folders that you create. You can set permissions on queries and folders that are created under Team Queries to enable or restrict access. You can set these permissions by choosing the project in Team Explorer, opening Work Items, opening the sub-menu for the query or folder for which you want to set permissions, and then choosing Security. Additionally, you can set these permissions by using the TFSSecurity command-line tool.

Area-Level Permissions for Work Item Tracking

Area-level permissions are specific to a single project's users and groups. You can set these permissions by right-clicking the project in Team Explorer, clicking Areas and Iterations, and on the Area tab, clicking Security. Additionally, you can set these permissions by using the TFSSecurity command-line tool.

Iteration-Level Permissions for Work Item Tracking

Iteration-level permissions are specific to a single project's users and groups. You can set these permissions by right-clicking the project in Team Explorer, clicking Areas and Iterations, and on the Iterations tab, clicking Security. Additionally, you can set these permissions by using the TFSSecurity command-line tool.

Version Control Permissions

Version control permissions are specific to source code files and folders. You can set these permissions by right-clicking the folder or file in Source Control Explorer, clicking Properties, and clicking the Security tab. On that tab, you can click the user or group for which you want to change permissions and then edit the permissions that are listed in Permissions. You can also set these permissions by using the tf command-line tool for version control.

Lab Management Permissions

Visual Studio Lab Management permissions are specific to virtual machines, environments, and other resources. You can set these permissions by using the TFSLabConfig command-line tool.

See Also

Tasks

Open the Team Foundation Administration Console

Reference

Permission Command

Concepts

Configuring Users, Groups, and Permissions

Server-Level Groups

Configuring Lab Management with TFSLabConfig

Defining Your Testing Effort Using Test Plans

Other Resources

Changing Groups and Permissions with TFSSecurity

Team Foundation Version Control Command-Line Reference

Managing Permissions

Collection-Level Groups

Project-Level Groups

Changing Groups and Permissions with TFSSecurity