Managing security in TFS the easy way

The old way

Before the introduction of Teams in TFS 2012, managing Security was fairly easy, my recommendations to my customers was always the same, use AD-groups and let the TFS Administrator do all the work. Create three AD groups for every TFS project and add them to the TFS project groups.

TFS Group AD-group
Project Administrators TFS-MyProject-Administrators
Project Contributors TFS-MyProject-Contributors
Project Readers TFS-MyProject-Readers


Use the same groups and add them to SharePoint and Reporting Services according to this matrix:

TFS SharePoint Reporting Services
Project Administrators Project site-level Administrator Project site-level Content Manager
Project Contributors Project site-level Contributors Project site-level Browser
Project Readers Project site-level Readers Project site-level Browser


A great tool to help you do this is the Team Foundation Administration Tool in Codeplex

The new way

When Teams were introduced in TFS 2012 things changed, a Team Administrator could add users to a Team and they were automatically added to the project contributors group overriding the project contributor AD groups. I thought a lot about this and spoke to my colleagues at Solidify and my customers and the got the idea to try to skip the project AD groups and let the TFS project completely handle themselves and this way lighten the work load of the TFS Administrator.

Use the build in Security this way:

TFS Comment
Project Administrators The project administrator creates Teams and assigns Team Administrators
Team Administrator The Team administrator assigns members to his/her Teams and they are automatically added to the project contributor groups.
Project Contributors You might consider giving everyone in the Project Contributor group some or all of the following rights to make things easier:

  • Add/Change Areas
  • Add/Change Iterations
  • Create Shared Queries
  • Create builds
  • Create branches
Project Readers


Let the project administrator handle SharePoint and Reporting services the same way if you use them. You might even consider to give everyone read access to all project reporting sites to make thins easier.

Managing Access levels in TFS Web Access

Regardless if you chose the old way or the new way you also have to use the Access Levels in TFS Web Access to Access your users to the right Access Levels.

Acces Level Comment
Stakeholder This level is free and the user can add and change Work Items and se but not change the Agile planning
Basic This is the level for product owners, scrum masters and other people that are not developers but want to do Agile planning. Create the following AD-groups: TFS_CAL_Users and TFS_MSDN_Professional_Users
Advanced This level has access to all parts of TFS web access. Create the following AD-groups: TFS_MSDN_Enterprise_Users (former Ultimate and Premium), and TFS_MSDN_Test_Professional_Users


My recommendations here are that you set the default level to Stakeholder and create AD-Groups for the different MSDN licenses and add them to the Access Level groups. The reason to use AD groups here is that in my opinion that the AD groups are better for audit purposes and if Microsoft decide to change the license levels they are easier to move from one level to another.