Manage users or groups in TFS

For users to have access to your team project in Team Foundation Server (TFS), you need to grant them access. If you're an administrator for a small team and restricting access isn’t important, simply add your team members to TFS.

However, if you need to grant access to a large number of users who perform different roles within the team, then the recommended practice is to create Windows or Active Directory groups, add these groups to TFS groups, and add the same groups to grant access to additional resources.

The last three steps are optional. You only have to grant permissions for reports or the project portal if your team project has been provisioned with SQL Server Reporting Services or a SharePoint site. Also, you only have to change access levels if you need to enable an entire group to access premium features or if you want to enable stakeholders or non-licensed users limited access.

Grant users and groups access to team projects and resources: Set up groups for use in TFS deployments Add users or groups to team projects Change access levels Limit access to functions for select users or groups: Restrict access to functions and tasks Grant non-licensed users limited access Give reviewers permissions to provide feedback Provide administrative access: Add a team administrator Add accounts to administer project collections Add accounts to administer TFS

How TFS manages access

If you need to make sure that the right users have the correct access or permissions to features and functions, it helps to understand that TFS controls access through three inter-connected functional areas:

• Access level management controls access only to features provided through TWA, the TFS web application. Based on their user license, administrators grant access to Basic, Advanced, or Stakeholder (previously labeled Standard, Full, and Limited) set of features. To learn more, see Change access levels.

• Membership management supports adding individual Windows user accounts and groups to default TFS groups. Also, you can create TFS groups. Each default TFS group is associated with a set of default permissions. All users added to any TFS group are added to the Valid Users group. A valid user is someone who can connect to the team project.

• Permission management controls access to specific functional tasks at different levels of the system. Object-level permissions set permissions on a file, folder, build definition, or a shared query. Permission settings correspond to Allow, Deny, Inherited allow, Inherited deny, and Not set.

Each functional area uses groups to simplify management across the deployment. You add users and groups through the TFS web service administration pages. Permissions are automatically set based on the TFS group that you add users to, or based on the object, project, collection, or server level to which you add groups. On the other hand, access level management controls access for all users and groups at the server level.

Notes:

• AD: Active Directory. You can create local groups or Active Directory groups to manage your users. If you decide to use groups, make sure that membership in those groups is limited to TFS users. Because group membership can be altered by their owners at any time, if those owners did not consider TFS when they created those groups, their changes to membership can cause unwanted side effects within TFS.

Here’s what you need to know about permission settings:

• Allow or Deny explicitly grants or restricts users from performing specific tasks, and are usually inherited from group membership.

• Not set implicitly denies users the ability to perform tasks that require that permission, but allows membership in a group that does have that permission set to take precedence, also known as Inherited allow and Inherited deny.

• For most groups and almost all permissions, Deny trumps Allow. If a user belongs to two groups, and one of them has a specific permission set to Deny, that user will not be able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.

  For members of the Project Collection Administrators or Team Foundation Administrators groups, Deny doesn’t trump Allow. Permissions assigned to these groups take precedent over any Deny set within any other group to which that member might belong.

• Changing a permission for a group changes that permission for all users who are granted that permission through their membership in that group. In other words, depending on the size of the group, you might affect the ability of hundreds of users to do their jobs by changing just one permission. So make sure you understand the impact before you make a change.

Two useful tips for understanding the effects of change: The Member of tab shows the groups that an individual user or group belongs to. You can also hover over an inherited permission, and a Why? icon will appear. If you choose it, a dialog box will open with more information.

Q & A

Q: I just want to access the code. How do I do that?

A: Once you’ve been added as a team member or contributor to TFS, see Team Foundation Version Control or Git.

Q: What permissions do I need before I can add users and manage permissions in TFS?

A: To add users or groups to your team project and manage permissions for you team project, you must belong to the Project Administrators group for that team project, or have Edit project-level permissions set to Allow. Project Administrators are granted the following default permissions.

To manage users, groups, or permissions for all team projects within a collection, you must belong to the Project Collection Administrators group, or have Edit collection-level permissions set to Allow.

Q: What kind of permissions do my users need?

A: You grant permissions to users based on the tasks they perform in TFS. In general, you'll want to grant the minimum set of permissions users need to do their job. You can use the following default groups and their associated permissions to manage most users and meet their needs.

Users	Team Foundation Server	SharePoint Foundation or SharePoint Server	SQL Server Reporting Services
Add accounts for people who need view-only access to the project.	Readers	Visitors	Browser
Add accounts for people who contribute to or manage the development of the software project.	Contributors	Members	Browser
Add accounts for people who manage user access to the project or need to configure or customize the project.	Project Administrators	Owners	Team Foundation Content Manager

To simplify management across the three systems, consider using the TFSAdmin tool from CodePlex.

Tip

Unlike Team Foundation Server and SharePoint Foundation, SQL Server Reporting Services does not distinguish between projects. Therefore, if you add a group to Reporting Services, that group will have the same permissions for reports across all the projects in the collection, regardless of their permissions in individual projects. Keep this in mind when choosing what groups to add.

Q: If I add team members to the Contributor role, will they have all the permissions they need?

A: The Contributor role grants the most common permissions developers need to contribute to a team project. However, it doesn’t allow users to create shared queries or to add area or iteration paths. You have to grant these permissions separately. Go here for queries, and here for area and iteration paths.

Q: How do I manage service account permissions?

A: See TFS service accounts and dependencies.

Q: What tasks are stakeholders with limited access able to perform?

A: See Work as a stakeholder.

Q: Is there a reference for all of the permissions in TFS?

A: Yes. See TFS permissions.

Q: Are their command line tools I can use to manage access and permissions?

A: Yes. You can use the TFSSecurity command-line utility to create, modify, and delete TFS users and groups, as well as modify permissions for users and groups.