Team Foundation Server Default Groups, Permissions, and Roles
When you create a new project in Team Foundation Server, new project-level groups are created for that project, and are assigned permissions to access resources appropriate to that group. To customize projects to better suit your business needs, you must understand what permissions are assigned to which users and groups, and what permissions you might want to add to any users or groups you might add. Additionally, if you want to closely align users with the roles described for MSF for Agile Software Development or MSF for CMMI Process Improvement, you must understand how to align those roles with the default groups already assigned to the project. Alternatively, you can create groups that associate directly with each of those roles, and assign those groups the permissions appropriate to the role.
Default Groups and Permissions
Whenever you create a project in Team Foundation Server, groups are created at the project level. By default, each of those groups has certain permissions assigned to them. You can add permissions to these default groups in addition to any groups or users you want to add at the server or project level.
Server-Level Groups and Permissions
By default, the following groups exist at the server level when you install Team Foundation Server:
SERVER\Team Foundation Administrators Members of this group can perform all operations for Team Foundation Server. This group should be restricted to the smallest possible number of users who need total administrative control over Team Foundation Server. By default, this group contains the Local Administrators group (BUILTIN\Administrators) for the server and the SERVER\Service Accounts group.
SERVER\Team Foundation Valid Users Members of this group have access to Team Foundation Server. This group automatically contains all users and groups that have been added anywhere within Team Foundation Server. You cannot modify the membership of this group.
Important
Do not unset or deny the View server-level information permission for this group.
SERVER\Service Accounts Members of this group have service-level permissions for Team Foundation Server. By default this group contains the service account supplied during installation. If you want to add new accounts to this group, you must add them using the TFSSecurity command-line tool. This group should only contain service accounts and not user accounts or groups (unless that group only contains service accounts). By default, this group is a member of Team Foundation Administrators.
SERVER\Team Foundation Licensed Users (Team Foundation Server Workgroup Edition only) Members of this group can connect to the server installed with Team Foundation Server Workgroup Edition. Access to the server is permitted to members and no other permissions are explicitly set for this group. The group can have one to five user accounts but no group accounts as members. The user accounts can be domain accounts or members of a workgroup environment. The term "workgroup" in the product name refers to a group of the one to five users and not the workgroup environment. Only members of this group can connect to the server. By default, the user account used to install Team Foundation Server Workgroup Edition becomes a member of this group. If you upgrade to Team Foundation Server Standard Edition, you can remove this group.
By default, these groups have the following permissions set for them. For a full description of each permission in the following list, see Team Foundation Server Permissions.
Note
You can set server-level permissions for project-level groups by using the TFSSecurity command-line utility.
| Permission Name | By default, set for: | Consider adding to: |
|---|---|---|
Administer shelved changes |
Team Foundation Administrators, Service Accounts |
Manually-added users or groups who might or must delete shelvesets created by other users. |
Administer warehouse |
Team Foundation Administrators, Service Accounts |
Manually-added users or groups who might or must change warehouse settings through the WarehouseController.asmx Web service ChangeSetting Web method. |
Administer workspaces |
Team Foundation Administrators, Service Accounts |
Manually-added users or groups who might or must create workspaces for other users and delete workspaces created by other users. |
Create a workspace |
Team Foundation Administrators, Team Foundation Valid Users |
None. |
Create new projects |
Team Foundation Administrators |
Project administrators who will regularly be creating new projects. In order to successfully create new projects, users must be a member of the SharePoint Central Admins group in Windows SharePoint Server and have Content Manager permissions in SQL Reporting Services. |
Edit Server-Level information |
Team Foundation Administrators |
None. |
Alter Trace Settings |
Team Foundation Administrators |
Other server administrators who might or must change the trace settings for gathering more detailed diagnostic information about Team Foundation Server Web services. |
Trigger Events |
Team Foundation Administrators, Service Accounts |
None. Adding this permission to other users has the potential to cause denial of service attacks. |
Manage Process Template |
Team Foundation Administrators |
Project administrators and any manually-added users or groups, such as process specialists, who might or must create, edit, download, and upload process templates to Team Foundation Server. |
View Server-level information |
Team Foundation Administrators, Service Accounts, Team Foundation Valid Users |
None. |
View system synchronization information |
Team Foundation Administrators, Service Accounts |
None. |
Project-Level Groups and Permissions
By default, the following groups exist at the project level:
Project Name\Project Administrators Members of this group can administer all aspects of the team project, although they cannot create new projects.
Project Name\Contributors Members of this group can contribute to the project in multiple ways, such as add, modify, and delete code, create and modify work items, and so on.
Project Name\Readers Members of this group can view the project but not modify it.
Project Name\Build Services Members of this group have build service permissions for the project. This group should only contain build service accounts and not user accounts or groups (unless that group only contains build service accounts).
Besides these project-level accounts, two of the server-level accounts also appear in every Team Foundation Server project:
SERVER\Team Foundation Administrators
Note
You cannot change the permissions for this server-level group.
SERVER\Team Foundation Valid Users
Important
Do not remove or deny the View project-level information permission for this group.
By default, these groups have the following permissions set for them. For a full description of each permission in the following list, see Team Foundation Server Permissions.
Note
You can add project-level groups to server-level groups by using the TFSSecurity command-line utility.
| Permission Name | By default, set for: | Consider adding to: |
|---|---|---|
Administer a build |
Project Administrators, Team Foundation Administrators |
Manually added users or groups who might or must delete completed builds and terminate current builds in progress. |
Delete this project |
Project Administrators, Team Foundation Administrators |
None. |
Edit build quality |
Project Administrators, Team Foundation Administrators |
Any manually-added users or groups that might or must add information about the quality of the build through the Team Foundation Build user interface. |
Edit project-level information |
Project Administrators, Team Foundation Administrators |
None. |
Publish Test Results |
Project Administrators, Team Foundation Administrators, Build Services |
Any manually-added users or groups that might or must add and remove test results on the team project portal and add or remove test runs. |
Start a Build |
Project Administrators, Contributors, Team Foundation Administrators, Build Services |
Any manually-added users or groups that might or must start a build through the Team Foundation Build user interface or from the command line. |
View Project-level information |
Project Administrators, Contributors, Readers, Team Foundation Administrators, Build Services, Team Foundation Valid Users |
All manually-added users or groups. |
Write to Build Operational Store |
Build Services, Team Foundation Administrators |
This permission should only be assigned to service accounts and not to individual users. |
Area-Level Groups and Permissions
By default, the following groups exist at the area level:
Project Name\Project Administrators
Project Name\Contributors
Project Name\Readers
Project Name\Build Services
SERVER\Team Foundation Administrators
SERVER\Team Foundation Valid Users
By default, these groups have the following permissions set for them. For a full description of each permission in the following list, see Team Foundation Server Permissions.
| Permission Name | By default, set for: | Consider adding to: |
|---|---|---|
Create and order child nodes |
Project Administrators, Team Foundation Administrators |
None. |
Delete this node |
Project Administrators, Team Foundation Administrators |
Any manually-added users or groups that might or must delete area nodes. |
Edit this node |
Project Administrators, Team Foundation Administrators |
Any manually-added users or groups that might or must rename area nodes. |
Edit work items in this node |
Project Administrators, Contributors, Build Services, Team Foundation Administrators |
Any manually-added users or groups that might or must edit work items in this area node. |
View this node |
Project Administrators, Contributors, Readers, Build Services, Team Foundation Administrators, Team Foundation Valid Users |
None. |
View work items in this node |
Project Administrators, Contributors, Readers, Build Services, Team Foundation Administrators |
Any manually-added users or groups that might or must view, but not edit or change, work items in this area node. |
Source Control Groups and Permissions
By default, the following groups exist at the source control level:
Project Name\Project Administrators
Project Name\Contributors
Project Name\Readers
Project Name\Build Services
SERVER\Team Foundation Administrators
SERVER\Service Accounts
By default, these groups have the following permissions set for them. For a full description of each permission in the following list, see Team Foundation Server Permissions.
| Permission Name | By default, set for: | Consider adding to: |
|---|---|---|
Read |
Project Administrators, Contributors, Readers, Build Services, Team Foundation Administrators, Service Accounts |
Most manually-added users or groups; any that might or must read the contents of a file or folder. |
Check Out |
Project Administrators, Contributors, Build Services, Team Foundation Administrators, Service Accounts |
Any manually-added users or groups who might or must check out or make a pending change to items in a folder. |
Check In |
Project Administrators, Contributors, Build Services, Team Foundation Administrators, Service Accounts |
Any manually-added users or groups that might or must check in items or revise any committed changeset comments. |
Label |
Project Administrators, Contributors, Build Services, Team Foundation Administrators, Service Accounts |
Any manually-added users or groups that might or must label items. |
Lock |
Project Administrators, Contributors, Build Services, Team Foundation Administrators, Service Accounts |
Any manually-added users or groups that might or must lock or unlock folders or files. |
Revise Other User's Changes |
Project Administrators, Team Foundation Administrators, Service Accounts |
Manually-added users or groups responsible for supervising or monitoring the project that might or must change the comments on checked in files, even if another user checked in the file. |
Unlock Other User's Changes |
Project Administrators, Team Foundation Administrators, Service Accounts |
Manually-added users or groups that might or must unlock files locked by other users. |
Undo Other User's Changes |
Project Administrators, Team Foundation Administrators, Service Accounts |
Manually-added users or groups that might or must undo a pending change made by another user. |
Administer Labels |
Project Administrators, Team Foundation Administrators, Service Accounts |
Manually-added users or groups that might or must edit or delete labels created by another user. |
Manipulate Security Settings |
Project Administrators, Team Foundation Administrators, Service Accounts |
None. |
Check In Other User's Changes |
Project Administrators, Team Foundation Administrators, Service Accounts |
None. |
Permissions Associated With the MSF for Agile Software Development Roles
If you created your team project using the MSF for Agile Software Development process template, you might want to assign users to groups that correspond with the roles for MSF for Agile Software Development. You can do this in one of two ways. You can assign users to the default group that most closely aligns to the permissions that are required for each role. Alternatively, you can create groups for each role, assign the appropriate permissions to that group, and then add the users who perform that role.
Assigning Users to Default Groups Based On Their MSF for Agile Software Development Roles
You can assign users to default groups based on their MSF for Agile Software Development roles. Although these groups do not directly correspond to each role, it is relatively simple to add users to these groups, and you do not have to create new groups and add permissions for the groups at the server, project, area, and source control levels. The disadvantage to this approach is that you lose some of the fine granularity of permission and control that you can have by adding groups specifically based on each role.
The following table provides suggestions for which default group best aligns with each MSF for Agile Software Development role. For more information about MSF for Agile Software Development and its roles, see the MSF for Agile Software Development Web site at https://go.microsoft.com/fwlink/?linkid=55200.
| Agile Role | Add to Default Group |
|---|---|
Architect |
Contributor |
Business Analyst |
Contributor |
Developer |
Contributor |
Project Manager |
Project Administrator |
Release Manager |
Project Administrator |
Tester |
Contributor |
Creating Groups That Correspond to MSF for Agile Software Development Roles and Assigning Permissions
You can create custom groups based on each MSF for Agile Software Development role and assign users to these groups. An advantage of creating these groups instead of using the default groups gives is that you have you more control over roles and permissions. The disadvantage to this approach is that you must create new groups and add permissions for the groups at the server, project, area, and source control levels.
Note
If you create custom groups to correspond with roles, you must set appropriate permissions for each new group in Windows SharePoint Services, Reporting Services, and either in Active Directory or Local Users and Groups on the Team Foundation Server computers. This is in addition to setting Team Foundation Server permissions.
Important
You cannot manually create a custom group that has all the permissions of the Project Administrator or Team Foundation Administrator groups. For custom groups that require Project Administrator permissions, create custom groups in Active Directory or on the local computer and add those groups to the Project Administrators group.
The following table provides suggestions for which permissions are appropriate for each MSF for Agile Software Development role. For a full description of each permission, see Team Foundation Server Permissions.
| Agile Role | Server | Project | Area | Source Control |
|---|---|---|---|---|
Architect |
Start a build View project-level information |
Edit work items in this node View this node View work items in this node |
Read Check out Check in Label Lock |
|
Business Analyst |
View project-level information |
View this node View work items in this node |
None |
|
Developer |
View project-level information Start a build |
Edit work items in this node View this node View work items in this node |
Read Check out Check in Label Lock |
|
Project Manager |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Release Manager |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Tester |
View project-level information Edit build quality Publish test results |
Edit work items in this node View this node View work items in this node |
Read Check out Check in Label Lock |
Permissions Associated With the MSF for CMMI Process Improvement Roles
If you created your team project using the MSF for CMMI Process Improvement process template, you might want to assign users to groups that correspond with the roles for MSF for CMMI Process Improvement. You can do this in one of two ways. You can assign the users to the default group that most closely aligns to the permissions that are required for each role. Alternatively, you can create groups for each role, assign the appropriate permissions to that group, and then add the users who perform that role.
For more information about MSF for CMMI Process Improvement and its roles, see the MSF for CMMI Process Improvement Web site (https://go.microsoft.com/fwlink/?linkid=55203).
Assigning Users to Default Groups Based On Their MSF for CMMI Process Improvement Roles
You can assign users to default groups based on their MSF for CMMI Process Improvement roles. Although these groups do not directly correspond to each role, it is relatively simple to add users to these groups, and you do not have to create new groups and add permissions for the groups at the server, project, area, and source control levels. The disadvantage to this approach is that you lose some of the fine granularity of permission and control that you can have by adding groups specifically based on each role.
The following table provides suggestions for which default group best aligns with each MSF for CMMI Process Improvement role.
| CMMI Role | Add to Default Group |
|---|---|
Auditor |
Contributor |
Build Engineer |
Project Administrator |
Business Analyst |
Contributor |
Developer |
Contributor |
Development Manager |
Project Administrator |
Infrastructure Architect |
Contributor |
IPM Officer |
Contributor |
Lead Developer |
Project Administrator |
Product Manager |
Contributor |
Project Manager |
Project Administrator |
Release Manager |
Project Administrator |
Solution Architect |
Contributor |
Sponsor |
Reader |
Subject Matter Expert (SME) |
Reader |
Test Manager |
Project Administrator |
Tester |
Contributor |
User Education Architect |
Contributor |
User Experience Specialist |
Contributor |
Creating Groups That Correspond To MSF for CMMI Process Improvement Roles and Assigning Permissions
You can create custom groups based on each MSF for CMMI Process Improvement role and assign users to these groups. These groups have much more granularity and control than just using the default groups. The disadvantage to this approach is that you must create new groups and add permissions for the groups at the server, project, area, and source control levels. Because MSF for CMMI Process Improvement has many roles, you should carefully consider what level of auditing, granularity, and control you need for your project before investing the time to create groups for each role.
Note
If you create custom groups to correspond with roles, you must set appropriate permissions for each new group in Windows SharePoint Services, SQL Reporting Services, and either in Active Directory or Local Users and Groups on the Team Foundation Server computers. This is in addition to setting Team Foundation Server permissions.
Important
You cannot manually create a custom group that has all the permissions of the Project Administrator or Team Foundation Administrator groups. For custom groups that require Project Administrator permissions, create custom groups in Active Directory or on the local computer and add those groups to the Project Administrators group.
The following table provides suggestions for which permissions are appropriate for each MSF for CMMI Process Improvement role. For a full description of each permission, see Team Foundation Server Permissions.
| CMMI Role | Server | Project | Area | Source Control |
|---|---|---|---|---|
Auditor |
View project-level information |
View this node View work items in this node Edit work items in this node |
None |
|
Build Engineer |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
Business Analyst |
View project-level information |
View this node View work items in this node Edit work items in this node |
None |
|
Developer |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
Development Manager |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Infrastructure Architect |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
IPM Officer |
View project-level information |
View this node View work items in this node Edit work items in this node |
None. |
|
Lead Developer |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
Product Manager |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
Project Manager |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Release Manager |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Add group members to the Project Administrators group |
Solution Architect |
View project-level information Start a build |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
Sponsor |
View project-level information |
View this node View work items in this node |
None |
|
Subject Matter Expert (SME) |
View project-level information |
View this node View work items in this node |
None |
|
Test Manager |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
Tester |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
|
User Education Architect |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read |
|
User Experience Specialist |
View project-level information |
View this node View work items in this node Edit work items in this node |
Read Check out Check in Label Lock |
See Also
Tasks
How to: Create a Server-Level Group
How to: Create a Team Project Group
How to: Change Permissions for a Group or User
How to: View Permissions
Concepts
Adding and Removing Users from Groups
Team Foundation Server Permissions
Team Foundation Server Contributor Permissions
Other Resources
Managing Groups
Managing Users
Team Foundation Server Administrator Permissions
Team Foundation Server Project Lead Permissions
Viewing and Changing Permissions
TFSSecurity Command-Line Utility Commands