Introduction

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.

Note   Team Foundation Server does not support the authentication modes and functional levels of Windows NT Server 4.0 or functional levels that support the functional levels of Windows NT Server 4.0, such as Windows 2000 mixed-mode. Additionally, installation of Team Foundation Server on any server configured as a domain controller is not supported.

Domain Trusts

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.

Trust Relationship Requirements Between Team Foundation Server Components

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.

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

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 Managing Users and Groups.

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.

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.

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.

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 Team Foundation data-tier server’s domain must trust the TFSService account’s domain. 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.

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.

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

Other Domain Configurations and Considerations

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.