Introduction to Microsoft Team Foundation Server Options

codeling 1264 - 5430
@2020-02-12 22:18:09

Team Foundation Server (TFS) is a Microsoft product that provides source code management (either via Team Foundation Version Control or Git), reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds and lab management, testing and release management capabilities. It covers the entire application lifecycle.


codeling 1264 - 5430
@2020-02-12 22:26:44

Team Foundation Server includes a set of Web services and databases that you install and configure separately on the server or servers that host the logical application, data, and client tiers for Team Foundation. Some features, such as the task board, and backlog team-based features, are entirely web-based and accessed solely through Team Web Access, a client-side web based service. Others, such as the version control features, can be accessed through either Team Web Access or through a client application. The following illustrations provide a high-level view of web services, applications, and databases for local deployments of TFS.


codeling 1264 - 5430
@2020-02-12 22:37:46

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.


codeling 1264 - 5430
@2020-02-12 22:54:04

What is a Valid User? How are Valid User groups populated?

When you add accounts of users directly to a TFS group or through a Windows group, they are automatically added to one of the valid user groups.

  • Server\Team Foundation Valid Users: All members added to server-level groups.
  • ProjectCollectionName\Project Collection Valid Users: All members added to project-collection level groups.
  • TeamProjectName\Project Valid Users: All members added to project-level groups.

The default permissions assigned to these groups are primarily limited to read access, such as View build resources, View project-level information, and View collection-level information.

This means that all users that you add to one team project can view the objects in other team projects within a collection. If you need to restrict view access, then you can set restrictions through the area path node. 

If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group will be able to access the team project, collection, or deployment, depending on the group you set.

Users browsing this topic
Guest