Export (0) Print
Expand All

Manage users in TFS

Team Foundation security is based on permissions granted to individual users and groups of users. The easiest way to manage users in Team Foundation Server (TFS) is to add user groups (or in some cases, individual user accounts) to the default groups in TFS so that they have the access they need.

Choose to add Windows accounts or a TFS group

A: 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.

A: The kinds of permissions your users will need depend on what kind of work they do. In general, you'll want to grant user accounts or groups the least amount of permissions required to get their jobs done. You can use default groups and their associated permissions in TFS to manage most users and meet their needs.

The range of needed permissions depends on role

Administrators and the service accounts used to run the system require the highest level of permissions. Users who use TFS to manage their work, check in code, and work collaboratively as a team require fewer permissions.

You can even restrict users to viewing only work items, or otherwise limit their access to the system. You can use the default groups and their associated permissions in TFS to manage most users and their needs. In special cases, you might need to grant or deny specific permissions to a user or group of users.

A: There's a lot to learn about permissions, but here's some things you should understand before you change any permissions for users in TFS:

  • Permissions Allow or Deny users the ability to perform specific tasks, and are usually inherited from group membership.

  • A permission that is 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 almost all permissions, Deny trumps Allow, so 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.

  • 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.

A: Yes, you'll need to perform extra configuration steps.

Here's a handy table that will help you understand what permissions groups you might need to add them to depending on their level of contribution to your project:




Project Leads

Team Foundation Server



Project Administrators

SharePoint Foundation or SharePoint Server




SQL Server Reporting Services



Team Foundation Content Manager

Tip 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. You can also consider using the TFSAdmin tool from CodePlex to manage permissions across these three systems.

© 2014 Microsoft