Introduction to Microsoft Team Foundation Server

Built-in TFS Groups and Permission Assignement

There are three categories of built-in groups, four permissions levels, and five permission states. Each user's access to a functional task depends on the explicit or inherited permission state assigned to them or to a group to which they belong.

Built-in TFS Groups

When you install TFS, four groups are defined at the server level. When you create a project collection, seven groups are created at the collection-level, and for each team project that you create, six groups are created that are scoped to the team project. Each of these groups is associated with a set of default permissions. You can't remove or delete a default server-level groups, such as the Team Foundation Administrators group.

Server-level	Collection-level	Project-level
SharePoint Web Application Services Team Foundation Administrators Team Foundation Service Accounts Team Foundation Valid Users	Project Collection Administrators Project Collection Build Administrators Project Collection Build Service Accounts Project Collection Service Accounts Project Collection Proxy Service Accounts Project Collection Test Service Accounts Project Collection Valid Users	Build Administrators Contributors Project Administrators Project Valid Users Readers TeamProject group (Note 1)

Notes:

1. A team group is created with the name of the team project. For example, if you create a team project named "Code Sample," a team group will also be created with the name "Code Sample Team." You can rename this team.

   In addition, when you create additional teams, a team group is created for each team.

 

Four Permissions Levels

Server-level groups are assigned server-level permissions. Collection-level groups are assigned permissions defined for the collection, project, and objects. And, permissions assigned to project-level groups include both project-level and object-level.

 

Allow, Deny, Not set, and other permission states

TFS uses a least-permissive model for security permissions. What that means is that if a user belongs to two groups and the same permission is assigned Allow for one group and Deny for another group, Deny takes precedence over Allow. There are a few exceptions to this rule for those who belong to the Project Collection Administrator and Team Foundation Server Administrator groups. 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.

You can specify two explicit authorization states for permissions: Deny and Allow. In addition, there are three other states: Inherited allow, Inherited deny, and Not set. Not set is an implicit Deny state.

Permission	Authorizatio
Allow	Explicitly grants users to perform the task associated with the specific permission. Allow is usually inherited from group membership. For users to access a task, the associated permission must be set to Allow or Inherited allow.
Deny	Explicitly prevents users from performing the task associated with the specific permission. Deny is usually inherited from group membership.
Inherited allow/Inherited deny	Allows or denies a user to perform the task associated with the permission based on the permission set for a group to which the user belongs.
Not set	Implicitly prevents users from performing the action associated with the permission. 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. By default, most permissions are not set to either Deny or Allow. The permissions are left Not set.

Permission states follow these precedence settings

The Deny permission takes precedence over all other permission settings, including Allow. 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. Exceptions to this rule are:

• The Deny permission does not take precedence if it is inherited from a hierarchical parent. These functions support hierarchical permission setting:
  • Source control folders for Team Foundation version control
  • Git repositories
  • Area and iteration nodes for work item tracking
  • Work item shared queries and query folders

The explicit permissions that are set on a particular object─such as a source control folder, a repository, or an area child node─override those that are inherited from the parent objects. For example, the Deny set for a source control folder doesn't override an Allow set for one of its sub-folders.

• When a user belongs to an administrators group, such as the Project Collection Administrators or Team Foundation Administrators groups, unless otherwise stated in the description of the permission.

Inherited allow takes precedence over Not set.