Team Foundation Build Quick Start

  • 12/24/2010
Contents

Team Build Security

Securing Team Build is a critical part of configuring Team Foundation Server and installing new build agents. Even if your Team Foundation Server environment is safely contained within your corporate firewall, this is still important to prevent inadvertent changes to your build agents and the builds that they produce.

Service Accounts

The first consideration when installing Team Build is to decide under what account to run the Team Build service. There are two options:

  • NT AUTHORITY\NETWORK SERVICE This built-in Windows account is a limited-privilege account that can access network resources using the computer account’s credentials. The account does not have a password and cannot be used to log on to the computer interactively or remotely. For more information about the NETWORK SERVICE account, refer to http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/sspgch02.mspx#EBH.

  • Domain Account Team Build can also run as an arbitrary domain account. Using a domain account allows you to log on to the build machine using this account to install or configure applications that use per-user settings (which you can’t do with the NETWORK SERVICE account because you can’t log on interactively with it). This can also be useful to debug build problems related to permissions on the build machine or other network resources.

To change the service account used by a build agent or build controller, you should use the Team Foundation Server Administration Console rather than the Services MMC snap-in because it will correctly configure the permissions required by Team Build. The steps are as follows:

  1. Log on to the build agent or controller for which you want to change the service account.

  2. Open the Team Foundation Server Administration Console (shown in Figure 13-31).

  3. Click Stop at the top of the console to stop the build service.

  4. Click Properties (shown in Figure 13-32).

  5. Enter new credentials for the build service.

  6. Click Start.

NOTE

The Team Build service account should not need to be a member of the build machine’s Administrators security group. The account should be granted the specific permissions needed by your build processes rather than granting it administrator access to the build machine. This is to minimize the damage of malicious or badly written build scripts.

Figure 13-31

Figure 13-31 Team Foundation Server Administration Console

Figure 13-32

Figure 13-32 Configure Team Build service account

The account also needs to be added to the Project Collection Build Service Accounts group for the Team Project Collection for which it will execute builds, as shown in Figure 13-33. This group grants Team Build access to the source, as well as the Team Project Collection permissions required to execute builds. To do this, perform the following steps:

  1. Open Visual Studio 2010.

  2. Open Team Explorer.

  3. Right-click the Team Project Collection.

  4. Click Team Project Collection Settings.

  5. Click Group Membership.

  6. Select the Project Collection Build Service Accounts security group.

  7. Click Properties.

  8. Click Windows User Or Group.

  9. Click Add.

  10. Select the domain account that the Team Build service is running as, or the build machine’s computer account if it is running as NT AUTHORITY\NETWORK SERVICE.

  11. Click OK.

  12. Click OK.

  13. Click Close.

Figure 13-33

Figure 13-33 Build Services Security Group Properties dialog

NOTE

The Team Build service account should not be the Team Foundation Server service account or a member of the Project Collection Administrators, Project Collection Service Accounts, or [Team Project]\Project Administrators security groups. If the Team Build service account is a member of any of these groups, then malicious or badly written build scripts could cause irreparable damage to the Team Foundation Server.

The Team Build service account also requires Full Control file system permission to the drop location.

Permissions

Permissions to both Team Foundation Server or Windows users and groups can be allowed or denied (or left unset). When there is a conflict between allow and deny permissions for a user, deny will take precedence. For more information about how permissions are granted and evaluated in Team Foundation Server, refer to http://msdn.microsoft.com/en-us/library/ms252587.aspx.

Team Build provides a number of Team Project Collection–level permissions for controlling access to Team Build functionality. These permissions are detailed in Table 13-10.

Table 13-10 Team Project Collection–Level Permissions

Permission

Description

Granted by Default To

Manage Build Resources

Permits the user to manage the build controllers and build agents associated with the Team Project Collection, as well as managing the Use Build Resources and View Build Resources permissions.

Project Collection Administrators; Project Collection Build Administrators; Project Collection Build Service Accounts

Use Build Resources

Permits the user to reserve and allocate build agents. This permission should be granted only to build service accounts.

Project Collection Administrators; Project Collection Build Service Accounts

View Build Resources

Permits the user to see the build controllers and build agents associated with the Team Project Collection.

Project Collection Administrators; Project Collection Build Administrators; Project Collection Build Service Accounts; Project Collection Valid Users

The permissions in Table 13-11 can be managed at either the Team Project level (by right-clicking Builds in Team Explorer and clicking Security) or at the build definition level (by right-clicking the build definition in Team Explorer and clicking Security). Permissions that haven’t been overridden at the build definition level will inherit the Team Project level permissions.

Certain Team Build operations (such as creating build definitions and modifying permissions) are limited to users that have the Destroy Builds, Manage Build Queue, and Delete Build Definition permissions.

Table 13-11 Team Project– and Build Definition–Level Permissions

Permission

Description

Granted by Default To

Delete Build Definition

Permits the user to delete build definitions.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Delete Builds

Permits the user to delete completed builds.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Destroy Builds

Permits the user to permanently delete completed builds.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Edit Build Definition

Permits the user to create new build definitions (only if applied at the Team Project level) or to edit existing build definitions.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Edit Build Quality

Permits the user to set or change the build quality for an individual build.

Project Collection Administrators; Project Collection Build Service Accounts; [Team Project]\Builders; [Team Project]\Contributors; [Team Project]\Project Administrators

Manage Build Qualities

Permits the user to maintain the list of build qualities.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Manage Build Queue

Permits the user to cancel, postpone, or change the priority of queued builds. Users without this permission can still cancel their own builds, but they won’t be able to postpone or change the priority of any builds, including their own.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Override Check-In Validation By Build

Permits the user to bypass gated check-in by checking changes in directly without running a gated check-in build.

Project Collection Administrators; Project Collection Build Service Accounts

Queue Builds

Permits the user to queue a new build.

Project Collection Administrators; Project Collection Build Service Accounts; [Team Project]\Builders; [Team Project]\Contributors; [Team Project]\Project Administrators

Retain Indefinitely

Permits the user to exclude builds from the retention policy.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Stop Builds

Permits the user to stop a build that’s in progress. Users without this permission can still stop their own builds.

Project Collection Administrators; [Team Project]\Builders; [Team Project]\Project Administrators

Update Build Information

Permits the user to add arbitrary information to the build. This permission should be granted only to build service accounts.

Project Collection Build Service Accounts

View Build Definition

Permits the user to view the details of a build definition.

Project Collection Administrators; Project Collection Build Service Accounts; Project Collection Test Service Accounts; [Team Project]\Builders; [Team Project]\Contributors; [Team Project]\Project Administrators; [Team Project]\Readers

View Builds

Permits the user to view queued and completed builds.

Project Collection Administrators; Project Collection Build Service Accounts; Project Collection Test Service Accounts; [Team Project]\Builders; [Team Project]\Contributors; [Team Project]\Project Administrators; [Team Project]\Readers

The Team Project–level permissions in Table 13-12 are not specific to Team Build but are granted to build service accounts by default.

Table 13-12 Other Build-Related Permissions

Permission

Description

Granted By Default To

Create Test Runs

Permits the user to publish test results against any build. Also permits the user to modify test runs or remove test results from any build. Note that this permission can be set only at the Team Project level.

Project Collection Administrators; Project Collection Build Service Accounts; Project Collection Test Service Accounts; [Team Project]\Builders; [Team Project]\Contributors; [Team Project]\Project Administrators

View Project-Level Information

Permits the user to view Team Project–level group membership and permissions.

Project Collection Administrators; Project Collection Build Service Accounts; Project Collection Test Service Accounts; [Team Project]\Builders; [Team Project]\Contributors; [Team Project]\Project Administrators; [Team Project]\Readers;

View Test Runs

Permits the user to view test runs for the Team Project.

Project Collection Administrators; Project Collection Build Service Accounts; Project Collection Test Service Accounts; [Team Project]\Builders; [Team Project]\Contributors; [Team Project]\Project Administrators; [Team Project]\Readers
Save to your account

This chapter is from the book