Trusts and Forests Considerations for Team Foundation Server
[This documentation is for preview only, and is subject to change in later releases. Blank topics are included as placeholders.]
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.
Note
Team Foundation Server does not support any domain authentication modes or functional levels that support Windows NT Server 4.0.
In this topic
Domain Trusts
Trust Relationship Requirements Between Team Foundation Server Components
Trusts Between Clients and the Team Foundation Application-Tier Server
Trusts Between Clients and the Team Foundation Server Proxy
Trusts Between Team Foundation Server Proxy and the Team Foundation Application-Tier Server
Trusts Between the Team Foundation Application-Tier Server and the Team Foundation Data-Tier Server
Trusts Between Team Foundation Build and the Team Foundation Application-Tier Server
Other Domain Configurations and Considerations
Unsupported Domain Configurations
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. 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.
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.
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) |
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 https://go.microsoft.com/fwlink/?linkid=47541.
Unsupported Domain Configurations
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.
See Also
Concepts
Managing Team Foundation Server in a Workgroup
Other Resources
Managing Team Foundation Server in an Active Directory Domain