I’ve been meaning to write this up for a while now, and a recent Twitter exchange with @thiago_bagua prompted me to finally get around to it. This post will describe a way of getting a TFS 2008 build server up and running in an Active Directory domain that has no trust relationship with its associated TFS server.
CAVEAT: Whilst the approach I going to describe below worked for me, your mileage may vary and I doubt that it is an officially supported configuration.
- You have a working instance of TFS
- You have already installed the TFS Build Agent (aka Team Build) on your build server
The diagram below illustrates the basic scenario, with the TFS Application-Tier (AT) and TFS Build Agent residing in separate domains with no trust relationships.
With the above configuration there are basically two problems we need to overcome:
- The Build Agent that runs as a Windows service called ‘Visual Studio Team Foundation Build’, will need to authenticate with the TFS AT in order to consume the various web services (e.g. source control, work item tracking, publishing build results etc.)
- The TFS AT will need to authenticate with the Build Agent service in order to be allowed to start a build
Build Agent to TFS Authentication
Solving the first problem involves storing a saved password in the profile of the Build Agent’s service account, in this scenario ‘DOMAINB\TFSBuild’, and ensuring that the server will use that credential automatically.
TFS-to-Build Agent Authentication
Having completed the above, we now just need to solve the second problem. My approach was to create a local account on the Build Agent with the same username and password as the account used as the identity of the ‘Microsoft Team Foundation Server Application Pool’ on the TFS Application Tier. This has the effect of allowing the TFS Application Tier to authenticate to the build server using it credentials.
As an alternative to this, you could setup a saved password, this time on the TFS server, in the profile of the ‘DOMAINA\TFSService’ account for the build agent server that use a domain account in ‘DOMAINB’ or local account on the build server.
At this point you should be able to register the new build agent in your Team Project and queue a build to it.
If you have hit problems whilst trying the queue the build, then this indicates that the TFS Application Tier had a problem connecting to the build agent. This is typically caused by TFS not being able to authenticate to the build agent or some kind of firewalling preventing the network connection, usually via TCP port 9191.
If the build starts but quickly fails, then this generally points to either or both of the following:
- The Build Agent service account cannot authenticate to the TFS Application Tier (i.e. a problem with its saved username/password).
- The saved username/password has not been added to the ‘Build Services’ application group in the relevant Team Project.
Anyway, if you find yourself in this sort of edge case scenario then hopefully the steps detailed here will be helpful. I'm now wondering whether a similar approach could be used to workaround the issue of not being able to add users, from a Trusting domain, to TFS application groups when there isn't a 2-way trust in place...?