Export (0) Print
Expand All

Trusts and Forests Considerations for Team Foundation Server

Visual Studio Team Foundation Server provides a foundation for cross-group collaboration across different domains or even across different forests. You can make sure that the security and stability of the server and your domain by following some important guidelines. Optimally, the Team Foundation application tier and data tiers will be in the same domain, but connecting clients may be in various domain locations.

Team Foundation Server is supported in the following Active Directory modes and functional levels:

  • Windows 2000 Active Directory in native mode.

  • Windows Server 2003 Active Directory in Windows 2000 native mode.

  • Windows Server 2003 Active Directory in Windows Server 2003 functional level.

  • Windows Server 2003 R2 in Windows Server 2003 R2 Active Directory forest functional level.

NoteNote

Team Foundation Server does not support any domain authentication modes or functional levels that support Windows NT Server 4.0.

In this topic

Team Foundation Server does not have any specific requirements in terms of supported domain trusts. The types of trust that can be employed depend on the forest and domain types that are deployed in your company’s network. Certain trust relationships might be required by Team Foundation Server depending on how Team Foundation components are deployed across your company’s network.

Generally, Team Foundation Server users and services must be authenticated so that they can access server components. From a trust relationship point of view, Team Foundation Server must trust the domain where the user or service account is defined.

This section describes the minimal trust relationships required between the various Team Foundation Server components. This section also describes the special implications that the trust relationship might have for your deployment configuration. When determining whether a trust relationship is sufficient between Team Foundation components, for example, if you want to verify a trust relationship between a potential Team Foundation client computer and Team Foundation Server, you can use a Web browser to verify whether that client can access a folder or share on the server hosting the logical Team Foundation application-tier components. If the client cannot access the share, the configuration will not be valid for Team Foundation Server.

In Team Foundation Server, you can manage group memberships and permissions for access (authorization) to the server and its resources either in Team Explorer, in the administration console for Team Foundation, or through the TFSSecurity and TF command-line utilities. This specified user is checked on the application-tier server to verify that the user is a member of a trusted domain.

Team Foundation Server synchronizes properties of users and groups from Active Directory. The critical trust requirement is that the service account that Team Foundation Server (TFSService) uses can authenticate with every domain that contributes users and groups to the deployment. Ideally, the service account must be trusted in all domains. In the absence of this trust, you can still add domain accounts that can be verified by Windows to Team Foundation Server. These user accounts can access Team Foundation Server, but detailed properties of users and group memberships cannot be synchronized unless the service account is trusted. The display names of these users will not appear; only the logon name will appear. In addition, if you add groups from domains that do not trust the service account for Team Foundation, the membership of those groups will not be synchronized, and changes to those groups or nested groups will not be picked up. This makes managing Team Foundation Server by using Active Directory groups much less effective.

Trusts Between Clients and the Team Foundation Application-Tier Server

When client applications, such as Team Explorer, connect to the Team Foundation application-tier server, the server tries to authenticate the user identity running the client application. If the domain to which the user belongs is trusted by the Team Foundation application-tier server's domain, the user is automatically authenticated as part of Windows Integrated Authentication. If that trust does not exist, the client application displays a username and password dialog box so that the user can supply alternative credentials to connect to the server. After authentication, Team Foundation Server checks to see whether the authenticated user is authorized to access the server. To do this, the user must be a member of the Team Foundation Valid User group. A user will automatically be added to that group when that user identity is added to an existing Team Foundation Server group or added to a server or project. For more information, see Configuring Users, Groups, and Permissions 

Team Foundation application-tier server services run under the TFSService account. Therefore, the Team Foundation application-tier server's domain must trust the domain to which the TFSService account belongs. Most of the time, the Team Foundation application-tier server and the TFSService account will belong to the same domain.

Component Domain

Trust

Component Domain

Team Foundation application-tier server's domain

one way trust to

Team Foundation user's domain

Team Foundation application-tier server's domain

one way trust to

TFSService account's domain

In order to avoid having to type a user name and password every time that a Team Foundation client application connects to Team Foundation Server, the Team Foundation client's domain must trust the Team Foundation application-tier server's domain.

Trusts Between Clients and the Team Foundation Server Proxy

The Team Foundation Server Proxy computer's domain must trust a user's domain for the proxy to work.

Component Domain

Trust

Component Domain

Team Foundation Server Proxy computer's domain

one way trust to

Team Foundation user's domain

Trusts Between Team Foundation Server Proxy and the Team Foundation Application-Tier Server

In the context of Active Directory, the Team Foundation Server Proxy is another client for Team Foundation Server.

Component Domain

Trust

Component Domain

Team Foundation application-tier server's domain

one way trust to

Team Foundation Server Proxy service account domain

Team Foundation Server Proxy computer's domain

one way trust to

Team Foundation Server Proxy user account domain

In order to avoid having to type a user name and password every time that a Team Foundation client application connects to Team Foundation Server, the Team Foundation client's domain must trust the Team Foundation application-tier server's domain.

Trusts Between the Team Foundation Application-Tier Server and the Team Foundation Data-Tier Server

The Team Foundation application-tier server connects to the Team Foundation data-tier server by using a service account, referred to generically as the TFSService account. The Team Foundation Server Web Services also run under this account. Therefore, the domain for the Team Foundation data-tier server must trust the domain for the TFSService account. In addition, every domain within your deployment of Team Foundation Server must trust the TFSService account itself, either through a domain trust relationship or explicit permissioning. The Team Foundation data-tier server's domain must also trust the TFSReports account's domain. The TFSReport account is the account used to access Team Foundation Server reporting data sources.

Additionally, Reporting Services runs on the Team Foundation application-tier server under the network service account. Therefore, the Team Foundation data-tier server's domain will trust the Team Foundation application-tier server's domain. If a trust relationship between the Team Foundation tiers is not desirable in your organization, you can reconfigure the system so that Reporting Services runs under a named service account that belongs to a different domain than the Team Foundation application-tier server. However, this is a fairly complex configuration that requires migration from single-server to dual-server deployments and manual reconfiguration of Report Server to run using a named service account.

Component Domain

Trust

Component Domain

Team Foundation data-tier server's domain

one way trust to

TFSService account's domain

Team Foundation data-tier server's domain

one way trust to

TFSReport account's domain

Team Foundation data-tier server's domain

one way trust to

Team Foundation application-tier server's domain

Trusts Between Team Foundation Build and the Team Foundation Application-Tier Server

Team Foundation Build runs under a Windows service account. Therefore, the Team Foundation Build computer's domain must trust this service account's domain. Typically this service account is the TFSService account, but it can be manually configured to run under another account. If Team Foundation Build is not running under the TFSService account, the service name must be added to the [Project]\Build Services application group.

NoteNote

When a build is created, the new build is put in the Build Drop shared folder. You must make sure that this folder is shared to all users, and that the TFSService account has full control to the folder. The "File and Printer Sharing" port must be opened in Windows Firewall on the Team Foundation Build computer to allow for file sharing.

Component Domain

Trust

Component Domain

Team Foundation Build computer's domain

one way trust to

Service account's domain (usually TFSService)

Team Foundation application-tier server's domain

one way trust to

Service account's domain (usually TFSService)

All other Active Directory domain configurations are unsupported and should not be used. You should make sure that the domain where you install Team Foundation Server supports Team Foundation Server, and that the individual computers on which Team Foundation Server is installed are in appropriate domain environments. If Team Foundation Server is supporting work across multiple forests, appropriate cross-forest trusts must be available.

For security considerations, install Team Foundation Server in a Windows Server 2003 domain environment. In order to avoid impersonation attacks, you should ban duplicate names and secure computer names by creator. For more information, see Windows Server 2003 Active Directory at http://go.microsoft.com/fwlink/?linkid=47541.

Domain configurations that support the functional modes of Windows NT Server 4.0 are unsupported. For example, the following domain configurations are not supported:

  • Windows 2000 mixed-mode domains

  • domain controllers that are running Windows Server 2003 and configured for Windows 2000 mixed-mode functional level

  • configuring the application tier in a domain and a data tier in a workgroup

  • configuring the application tier in a workgroup and a data tier in a domain

You can find examples of supported domain topologies in Examples of Simple Topology, Examples of Moderate Topology, and Examples of Complex Topology.

Concepts

Managing Team Foundation Server in a Workgroup

Other Resources

Community Additions

ADD
Show:
© 2014 Microsoft