Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Getting to know the different types of users and groups

· Understanding the new and interesting permissions

· Using tips for managing security

· Learning about useful tools

When you first start looking at security, groups, and permissions in Team Foundation Server, you might find it very daunting. This is a large system with many different features. A large part of the customer base also demands fine-grained controls in order to meet compliance goals. Combined, these two features make managing security a sometimes tricky task.

However, by understanding some basic principles and avoiding some of the traps, Team Foundation Server security can be corralled to achieve your security objectives. This chapter examines those principles and provides the information you'll need to avoid common pitfalls.

Security When Using Visual Studio Online

The Visual Studio Online service provides the same core Team Foundation Server capabilities as does its on-premises counterpart. Where it diverges is in the security realm. As you will see later in this chapter, Team Foundation Server can work with Domain and Workgroup user accounts. The problem encountered with a cloud-based service is that there is no common Domain or Workgroup that can be called upon to provide authentication. To resolve this, Microsoft built the service's security model around the Microsoft account system (formerly Windows Live ID). This means that anyone that wishes to use Visual Studio Online must have a Windows account. Fortunately, if you use an e-mail address and a password to sign in to Hotmail, Outlook.com, OneDrive, Windows Phone, Xbox LIVE, or other Microsoft services, you already have a Microsoft account.

Authorization using a Microsoft account isn't ideal in some situations because it requires an interactive web page login. When using non-browser–based tools such as the Team Explorer Everywhere command line, this becomes an issue. To mitigate this, Microsoft added the ability to log in with alternate credentials.

Basic Authentication for Visual Studio Online

Basic Authentication in Visual Studio Online is provided through a standard HTTP basic authentication implementation. If you need to access the system from a tool that works outside a browser, enable basic authentication by creating alternate credentials for your account.

To create alternate credentials, log in to Visual Studio Online, click on your name, and then select My Profile to open your User Profile dialog box. Now click on the Credentials tab and click the Enable alternate credentials link. You will see the e-mail address used in your Microsoft account as the primary user name along with a location to enter a password. You can simply set a password here and click the Save Changes button. This does not change your Microsoft account password, but rather, gives you a second password to use for basic authentication. Once you save these changes, you can log in with your e-mail address and basic authentication password when using applications that work outside a browser.

Having Trouble with That E-mail Address?

Some programs that use basic authentication have difficulty with special characters such as the @ sign, which makes it difficult to use an e-mail address as your user name. If you encounter this problem, you can set a secondary user name on the Credentials tab, which can be used in place of your e-mail address during login.

Users

A key concept to understand in Team Foundation Server security is that there are different types of users, including the following:

· Domain users

· Local users

Domain Users

A domain in a Windows network usually means an Active Directory (AD) domain. AD is a directory and authentication service that comes with Windows Server. User accounts created in the directory are called domain users. In the directory, each user object has a set of properties, including a unique identifier (called a security ID, or SID), a display name, and an e-mail address.

Note

Currently, the Visual Studio Online service is using Microsoft Accounts as its mechanism for authentication and identity management. However, because the product team is implementing identity using the Windows Azure Access Control Service, it could potentially support other identity providers in the future, such as Active Directory federation, with on-premises AD servers, Google ID, Yahoo, Facebook, and so on. This chapter primarily focuses on the on-premises version of Team Foundation Server and may not be completely applicable to the Visual Studio Online Service.

Service Accounts

A service account is nothing more than just another domain user. The main difference is that a domain user is usually a real person. A service account is a domain account created and used specifically to run a Windows service or other application.

It's generally considered a bad practice to run services as accounts that real people use for their day-to-day work. A service account usually has elevated privileges compared to a normal user. For this reason, the service account passwords are often randomly generated strong passwords, and they are kept a closely guarded secret by the owners.

Machine Accounts

Three accounts are built into a Windows computer:

· Local System

· Local Service

· Network Service

The first two accounts cannot be used to authenticate to other computers. Local System is an administrator on the system. Local Service has limited privileges, and it is designed for running Windows services. Similarly, Network Service has limited local privileges. However, it is capable of connecting to other computers on the domain.

When a computer is joined to a domain, a trust relationship is established between the computer and the domain. Once this trust is established, the computer is essentially under the control of the domain. This allows domain policies to be applied and enforced from the central directory service.

When the domain join occurs, a special domain account called a machine account is created with an automatically generated password. As long as the computer remains in contact with the domain, this password will change periodically, and the trust relationship will remain. If the computer does not connect to the domain controller for a period of time, the account will be disabled, and the trust relationship will be voided.

A machine account is represented as a domain user followed by $ in its account name, as shown in the following example:

MYDOMAIN\MYCOMPUTER$

To give the Network Service account permissions on the machine itself, you can use either the Network Service account or the machine account. To give the Network Service account permissions on a remote resource, you must use the machine account.

Local Users

If you install Team Foundation Server on a computer that isn't joined to a domain, it is considered to be running in workgroup mode. In workgroup mode, there is no domain, so the only users that exist are users on that local computer. These users are called local users.

Even if your computer is installed on a domain, you can still have local users. However, these local users cannot be added to domain groups or used for authenticating to other computers in the domain.

Shadow Accounts

If you have computers in different domains, or computers that are not part of any domain, there are cases where you want to be able to authenticate between them. When connecting to a remote machine, normally you must provide a user name and password to an account on that machine.

There is a trick called “shadow accounts” that you can use to avoid being prompted for credentials. To use shadow accounts, you establish a local account on both machines with a matching user name and password. When the user from one machine tries to connect to the other machine, the account first tries to connect using the current user name and password. Because the user names and passwords match on both machines, this works without prompting for credentials.

Identity Synchronization

Team Foundation Server synchronizes some properties of every user that is a member of a group in the system. This is so that domain group membership changes are reflected in the system, and other property changes (such as display names and e-mail addresses) are kept up to date.

Identity Synchronization Job

The Team Foundation Background job agent on each application tier server periodically executes the Identity Synchronization job. By default, it runs once per hour, and it is also triggered when a new domain group is added to Team Foundation Server.

The job agent runs as the Team Foundation Server service account. This will be either a domain user, Network Service, or a local user (in the case of a server running in workgroup mode).

Domains and Trusts

Because the Identity Synchronization job runs on the job agent, it accesses Active Directory using these credentials. If the appropriate domain trusts aren't in place, or the account doesn't have permissions to list users in the directory, those users will not be able to access Team Foundation Server. There are lots of different permutations on domain topologies, firewalls, and trust relationships.

Note

For more information on what is supported by Team Foundation Server, see “Trusts and Forests Considerations for Team Foundation Server” at http://aka.ms/TFSADTrusts.

Handling Display Name Changes

One of the big changes introduced in Team Foundation Server 2010 was server updates to your display name when it changed in AD. This is a fairly common scenario, similar to when people get married and change their names from their maiden names to married names.

In Team Foundation Server 2008, even though the change was made in AD, Team Foundation Server would keep using the old name. In all Team Foundation Server versions after 2008, the change is detected as part of the identity synchronization job and updated throughout the environment.

Display Name Disambiguation

Another change introduced in Team Foundation Server 2010 was something called display name disambiguation. In the 2008 version, if you had two different user accounts with the same display name, that display name would show only once in people fields such as the “Assigned To” field. There was no way to distinguish which user account was actually being referred to. Some people tried to solve this by changing the display name of one of the users in AD, but without the previously mentioned display name changes detection feature, this did not solve the problem.

With the disambiguation feature, if two user accounts with the same display name exist within the same team project collection, the identity synchronization job will append the domain and account name to the end. For example, imagine two users that have the same display name John Smith. One user's account is MYDOMAIN\JSmith, and the other user's account is MYDOMAIN\JohnS. Team Foundation Server 2013 will disambiguate these and show them as two separate entries in the “Assigned To” field, as shown here:

· John Smith (MYDOMAIN\JSmith)

· John Smith (MYDOMAIN\JohnS)

In a large organization where you have many domains and trusts, sometimes a user will be moved to or re-created in a different domain. Think of the example where someone moves from a position in Australia to a position in Seattle, and the organization has an AD domain for each region. If both users still exist (whether disabled or not) and continue to be members of a group in Team Foundation Server, this will also be disambiguated to the following:

· John Smith (AUSTRALIA\JSmith)

· John Smith (USA\JSmith)

If you want to remove this artifact of disambiguation in the display name, you have two options:

· Change the display name of one of the users in AD.

· Remove one of the users from all groups in that team project collection and remove all of the individual security access grants that exist in each of the team project collection(s).

Note

If you find yourself in the latter situation, it may be helpful to open a Microsoft product support case to assist with finding all of the artifacts and security permission entries that Team Foundation Server is using to keep the account active in its identity cache. The product support team can assist with removing everything that would cause the disambiguation to occur.

Customizing Display Name Options and Alias Mode

Some organizations don't set the display name field in AD to a useful value. Instead, they use it to store an employee ID or something like that. In these environments, it's not very easy to run a work item tracking query looking for bugs assigned to Grant Hollidaywhen you have to specify it as assigned to GH31337. Additionally, this becomes more important in Team Foundation Server 2012 because the display name is used in additional locations such as in the build system and in version control.

Fortunately, there are two options for customizing the user's display name. The first and preferred option is that each team member can log in to Team Web Access and customize their display name, e-mail address, and other preferences in the Manage Profile dialog box available by clicking on the user's name in the upper-right corner of any Team Web Access page. This is actually the primary method for display name updates when using the Team Foundation Service because the Identity Synchronization service does not import a display name with Windows Live ID accounts.

The second option is a privately supported feature called alias mode. When this feature is enabled, Team Foundation Server will use the user name for the “Assigned To” field instead of the display name. Of course, this is not useful if your account name is also meaningless, but it is useful in some environments. To enable alias mode, you will need to contact Microsoft Support. It also must be done before you install Team Foundation Server for the first time.

Groups

Another Team Foundation Server security concept that you should be familiar with involves the use of different types of groups. These include:

· Domain groups

· Distribution groups

· Local groups

· Team Foundation Server groups

Domain Groups

Like domain users, domain groups are groups that exist in AD. Sometimes they are also referred to as security groups. They can contain other domain users, groups, and machine accounts.

Distribution Groups

In an AD environment that also has Microsoft Exchange mail configured, you can create distribution groups. These distribution groups can be used to send mail to a list of recipients.

Distribution groups cannot be used to secure resources; only domain groups can be used for that. If you want a group that can be used to secure resources as well as receive mail, you can have a mail-enabled security group.

Local Groups

Like local users, local groups exist only on a single machine. These can be used only to secure resources that exist on that machine. One feature of local groups is that they can contain domain users and groups as members.

This is useful, for example, if you want to allow administrative access to your machine to members of a domain group. You can add a domain group called MYDOMAIN\MyGroup to the BUILTIN\Administrators local group on your computer.

Team Foundation Server Groups

Team Foundation Server also has its own application group structure. There are groups at three different levels within the system:

· Server groups

· Team project collection groups

· Team project groups

Server Groups

The default server groups (as shown in Table 24.1) have hard-coded names that cannot be changed or removed from the server. To modify the group memberships or permissions of server groups, you will need to use the Team Foundation Server Administration Console or the TFSSecurity.exe command-line tool.

Table 24.1 Built-In Team Foundation Server Groups

Team Project Collection Groups

The default team project collection groups are created as part of the collection-creation process. Table 24.2 shows each of the groups and their members.

Table 24.2 Default Team Project Collection Groups

To modify a team project collection group's memberships or permissions, you can use the Team Foundation Server Administration Console, Visual Studio Team Web Access, or the TFSSecurity.exe command-line tool.

Team Project Groups

Team project groups are initially defined in the process template and created as part of the team project creation wizard. Table 24.3 shows the default groups included with the Microsoft Solutions Framework (MSF) for Agile Software Development and MSF for Capability Maturity Model Integration (CMMI) Process Improvement process templates. You may additionally create security groups or use the team project groups created when defining teams to further define security inside a team project.

Table 24.3 Default Team Project Groups

Permissions

Rather than providing a listing of the more than 80 different permissions available in Team Foundation Server, this section focuses on the permissions that are new in the 2013 version, or are otherwise ambiguous or interesting. In particular, this discussion examines the following:

· Server permissions

· Team project collection permissions

· Team project permissions

· Team Room permissions

Note

For a comprehensive list of all the permissions available, refer to “Team Foundation Server Default Groups, Permissions, and Roles” at http://aka.ms/TFSDefaultSecurity.

Server Permissions

The Team Foundation Administrators group, along with the Team Foundation Service Accounts group, has hard-coded permissions. This is to prevent an administrator from being inadvertently locked out of the system. Table 24.4 shows some of the interesting server-level permissions.

Table 24.4 Server Permissions

Team Project Collection Permissions

Most of the permissions that used to be at the server level in Team Foundation Server 2008 have been moved to the team project collection level in Team Foundation Server 2010 to 2013. This is useful when you have many collections running on a single consolidated and shared server instance. In this kind of environment, you can delegate permissions that allow someone to create team projects within a collection without having to grant them full server administrator rights.

Table 24.5 shows some of the permissions available at the collection level.

Table 24.5 Team Project Collection Permissions

The ManageBuildResources permission can cause some angst for organizations using Team Foundation Build. There are three problems with this permission:

· It is very broad and powerful.

· It is required to be able to connect a build agent to a collection.

· When you configure a build server, if you do not have the “Edit collection-level information” permission, configuration will fail.

These three problems work against each other when you want to allow people to run their own build agents without making everybody a project collection administrator.

Fortunately, there is a reasonable solution. Before anyone runs the Team Foundation Build configuration wizard, the service account they want to run the build service as can be added to the Project Collection Build Services group. This avoids the second and third problems.

If you force people to use Network Service or a service account as the account for their build service, you can avoid the problem of having normal user accounts as project collection administrators.

Team Project Permissions

As shown in Table 24.6, Team Foundation Server 2010 introduced several new team project level permissions that control access to some of the Microsoft Test Manager assets.

Table 24.6 Team Project Permissions

Let's take a closer look at a couple of these permissions.

View Project-Level Information

When users have the “View project-level information” permission, they are able to see that the project exists in the collection, as well as list the project's group memberships and permissions. Before Team Foundation Server 2010, the Valid Users group was given this permission for every team project by default. This meant that users could see all the projects that existed on a server. It also made the list of projects in the team project connect dialog box quite long on a server with many projects.

Starting in the 2010 version, this was no longer the case. However, if your server was upgraded from an earlier version, these permissions will still exist. If you want to trim down the projects that users see when they connect to the server, you can remove this permission for them.

Edit Project-Level Information

The “Edit project-level information” permission is also very generic, and it's not very clear from the name what a user with this permission can do. To clarify, a user with this permission can do the following:

· Edit areas and iterations.

· Change the version control check-in policies enabled for a project.

· Create and modify team queries, team query folders (discussed later in this chapter), and the team query folder permissions.

· Modify group memberships and project-level permissions.

Work Item Tracking

Within the work item tracking components of Team Foundation Server are three different sets of permissions that can be managed. There are permissions on the following:

· Areas

· Iterations

· Team query folders

Areas

Area path permissions can be applied to any node in the tree. The permissions on a parent node can be inherited by the child nodes if inheritance is enabled. The available permissions fall into two categories:

· Permissions to modify work items in area paths

· Permissions to modify the area paths themselves

The permissions shown in Table 24.7 are particularly interesting because they can be used to hide or lock down parts of the tree for different sets of users.

Table 24.7 Selected Area Level Permissions

For example, say you had a large team project that your whole organization or product engineering department shared. You might do this if you wanted to do all work with one set of work items, instead of having projects in silos. If there was a super-secret product that a team was working on, and you didn't want anyone else in the organization to see those work items, you could remove the “View work items in this node” permission.

Another example might be a change request area path. Your team could have a set of area paths, and one of those area paths could be called \Change Requests. You could configure the permissions so that anyone on the server could create a work item in just that area path.

Iterations

The permissions for iterations are much the same as those for area paths. The notable difference though is the lack of the “View work items in this node” and “Edit work items in this node” permissions. This means that you cannot control who can move work items into iteration paths. You can control modifications only to the iteration path structure itself.

Team Query Folders

Team query folders is a new feature introduced in Team Foundation Server 2010. Before these folders, you could have only a flat list of queries. Some people tried to work around this by coming up with elaborate naming schemes. Others used a SharePoint document library with folders and *.WIQ files in each folder to achieve the same thing.

Team query folders were actually available before 2010 on an internal release of Team Foundation Server built especially for the Windows and Office organizations at Microsoft. The feedback from teams using the folders was that there needed to be permissions on them. Because of this feedback, the team added the permissions shown in Table 24.8 before including the feature in the final Team Foundation Server 2010 release.

Table 24.8 Team Query Folder Permissions

Team Web Access and Licensing Access Levels

The legacy Work Item Only View (WIOV) feature allows users in your organization to create and view work items that they created in Team Web Access without having a client access license (CAL). This is useful if you want to allow others to log bugs or feature requests for your product directly into Team Foundation Server.

Note

For more information, see the latest version of the “Visual Studio Licensing White Paper” at http://aka.ms/VisualStudioLicensing. This licensing white paper is updated regularly.

Bypass Rules and the Forcing Rollback Error

Team Foundation Server has a ClientService.asmx web service. This is the same web service that the Team Foundation object model uses.

If you are migrating work items from another system, you will likely need to save work items with invalid values. Team Foundation Server provides a mechanism for doing this, which is commonly called Bypass Rules.

By calling the web service directly from your own code (which is not recommended), you can set the BypassRules flag and submit an XML package that includes the values that you want to set. Only members of the Project Collection Service Accounts group are able to use this functionality because it can put a work item into an invalid state.

If you try to use this functionality and the account is not in the correct group, you'll receive a very cryptic SoapException:

Forcing rollback ---> Forcing rollback ---> Forcing rollback

This indicates that SQL was trying to apply your changes but found that you didn't have the required permissions.

There is an administration page in Team Web Access that was introduced in Team Foundation Server 2012 to help assist with the management of different features available to end users in Team Web Access, as shown in Figure 24.1. This tab is labeled “Access Levels.” Users can be a member of the following groups:

· Limited

· Standard

· Full

Figure 24.1 New feature access administration page.

The Limited access level allows user access similar to the legacy Work Item Only View feature. It allows them to view work items and is perfect for those users who do not have a CAL for Team Foundation Server. However, it does not provide them with the security rights necessary to perform these activities, so be sure to also add these users to either the Contributors default security group for projects or enable the “View work items in this node” and “Edit work items in this node” permissions. This access level also enables users to submit feedback using the new Feedback Client, as you learned in Chapter 14.

The great thing about this Limited access level is that you can create a linked work item from a bug submitted by an end user. The end user cannot see the linked work item and the discussion that happens for that linked bug. When the work is complete and the original bug is resolved, the end user can see that his or her feedback was addressed.

The Standard access level is designed for those users who have an individual Team Foundation Server CAL or for Visual Studio Professional with MSDN users. The members of this group will additionally have the standard Web Access features as well as the Agile Task Boards, Backlog and Sprint planning tools, and Chart viewing available to them. For upgraded or brand new instances of Team Foundation Server 2013, this is the default group for all users, as shown in Figure 24.1.

The Full access level is designed for those users that have any of the higher editions of Visual Studio such as the following:

· Visual Studio Test Professional 2013 with MSDN

· Visual Studio Premium 2013 with MSDN

· Visual Studio Ultimate 2013 with MSDN

The members of the Full access level receive all of the features in the Limited and Standard groups but are also able to use the web-based Test Management features, Team rooms, and Agile Portfolio Management tools, and will be able to create Charts for their teams.

Because the Standard access level is the default group, you will want to be sure to add any users with a higher edition of the Visual Studio products to the Full group because they will not see the advanced features of Team Web Access until that happens.

To assist organizations with ensuring license compliance, there is also an Export Audit Log feature from this page that will allow you to generate an Excel workbook that contains all of the users and their relevant licensing access to features.

Version Control Permissions

When we discuss Version Control Permissions here, we are talking about the centralized version control system that has been part of the system since Team Foundation Server 2005. These permissions haven't changed significantly since Team Foundation Server 2010, when the branching and merging permissions were separated from the check-in permission. This can be seen in Table 24.9. The Git (distributed version control) permissions will be discussed in the section “Managing Git Repository Security.”

Table 24.9 New and Interesting Version Control Permissions

When your server is upgraded from the 2008 version to the 2010 or higher versions, folders that were branches are detected and automatically converted to real branches. If you previously had Read and CheckIn permissions on that folder, you are grandfathered in and given the Merge and ManageBranch permissions.

Check-In on Behalf of Another User

In some scenarios, you may want to check in some changes using one account but record that another user actually made the changes. An example of this is a shared workstation used for generating hotfixes. Each user would log on to the machine and access the server using a shared user name. Then, after the user makes the fix, he or she checks it in and specifies that his or her user name is the actual author of the change.

To do this, you must specify the /author flag on the TF.exe checkin command line:

C:\Code\MyProject> tf checkin * /author:jsmith

Checking in add: MyFolder

Changeset #11 checked in.

If you want to see who checked in a changeset on behalf of another user, unfortunately, you will have to use the command-line tools. To do this, specify the /noprompt flag on the TF.exe changeset command:

C:\Code\MyProject> tf changeset 11 /noprompt

Changeset: 11

User: jsmith

Checked in by: Administrator

Check-In Policies

The check-in policy settings for a team project are stored as a version control annotation. Annotations aren't part of the public API and, in Team Foundation Server 2013, are superseded by the Properties API. Annotations are like properties in that they are extra metadata attached to a particular path in version control.

Because the annotation is on the root version control folder for each team project, users will need at least Read permissions on that folder. Without this permission, they will get an error message similar to “$/MyProject does not exist or you don't have access to it.” This can be quite confusing when the user is trying to check in to some other path that the user actually does have permission to.

Branching and Permissions

When you branch a folder, the permissions from the source folder are copied to the target. In most cases, this is acceptable. However, there are other cases (such as when creating a maintenance or release branch) that you don't want to copy the permissions to. In these cases, you'll have to lock down the permissions after creating the branch. Then, as people need to check in patches, you can grant them the PendChange and Checkin permissions.

The reverse is also true. For example, your Main branch might have very restrictive permissions to prevent people from making changes directly. When you create a branch of Main, those restrictive permissions will also be copied. In this case, you'll have to add the extra permissions after creating the branch.

How to Undo Changes from Another User

A very common question on the support forums and e-mail lists concerns when someone has a set of files checked out and locked, and the person goes on vacation or is otherwise unavailable. Until these locks are removed, no one else can check in these files.

Fortunately, it's fairly simple for someone with the “Administer workspaces” permission to undo changes for another user.

One option is to use the TF.exe command-line tool, as shown here:

tf undo "$/MyProject/VersionX/Utils/file.cs"

/workspace:MyWorkspace;Domain\User

/collection:http://server:8080/tfs/Collection

/recursive

Another option is to use the Team Foundation Power Tools. Follow these steps:

1. Open Source Control Explorer.

2. Right-click the item on which check-out is to be undone (or a parent folder of multiple files to be undone).

3. Select Find in Source Control Status.

4. In the Find in Source Control dialog box, leave the Status check box selected.

5. Optionally, enter a value for the Wildcard text box.

6. Optionally, enter a user name in the “Display files checked out to” text box and select that radio button.

7. Click Find. This will result in a list of files.

8. Select the items to undo.

9. Right-click and select Undo.

10.Click Yes when prompted with “Undo all selected changes?”

Destroy

When you delete a file in version control, it is just a “soft” delete. The file contents and all the previous revisions still exist, and anyone with Read permissions can still retrieve the file or undelete it.

To permanently delete a file from version control and remove all previous versions of it, you can use the TF.exe destroy command. Because this is a potentially very destructive operation, you must be a member of the Team Foundation Administrators server group.

Once a file is destroyed, the only way to recover it is to restore a backup of your server to a previous point in time. Each time a file is destroyed, a message is logged to the Application event log on the application tier that the destroy command ran on.

Managing Git Repository Security

Team Foundation Server 2013 introduced the ability to use the Git distributed version control repository instead of the standard centralized version control repository that has shipped with every version of the product. Git does not define any access control whatsoever but relies on third-party add-ins or the underlying storage and transport mechanisms to enforce read-only or read-write permissions.

The Visual Studio team has had a goal of providing an enterprise-grade Git solution. To support that goal, the team has provided a permission set that is specific to Git repositories hosted in Team Foundation Server.

The most notable permissions are around branch-level permissions. These give you the ability to control who has the capability to push certain branches to the server. With this model, team members still have full control over their local Git repositories while providing the Team Foundation Server administrators with a level of control over the central server.

Table 24.10 lists the permissions available when using a Git version control repository with Team Foundation Server.

Table 24.10 Git Repository Permissions

When you compare the permission set for a Git repository against the permission set for a standard, centralized version control repository, you can see that the Visual Studio team wanted to provide enough control over the “central” Git repository that enterprises need without impeding the usage patterns that Git users have come to rely on.

Note

Be aware that the Allow Force pushes in the Git repository permission will allow users to change the history or remove a commit from history. Any users given this permission will be able to delete a change and its history from the server. They can also modify the commit history of the server repository.

Build Permissions

Teams are also able to provide for permissions at the build definition level. Some of the more interesting permissions available are listed in Table 24.11.

Table 24.11 New and Interesting Build Permissions

Reporting

By default, users do not have access to query the relational warehouse database or the Analysis Services cube. If you want to allow users to use the Excel reporting features of Team Foundation Server, you must grant them access to at least the Analysis Services cube.

The Analysis Services cube contains aggregated and summarized data from all team projects in all team project collections in an environment. There is no security filtering based on your permissions within Team Foundation Server. If a user has Read access to the cube, then that user can query the summarized data from all projects. If this is a concern for you, you may want to consider limiting the users who have access to the cube and its data.

If you have a more relaxed security policy, and all users can see all work items, you should consider giving all users access to the warehouse and cube. This will allow them to leverage the useful metrics that the data warehouse provides. To do this, you must add the users (or a security group) to the roles shown in Table 24.12.

Table 24.12 Team Foundation Server Reporting Roles

For more information, see the following articles on MSDN:

· “Grant Access to the Databases of the Data Warehouse for Visual Studio ALM” at http://aka.ms/TFSGrantWarehouseAccess

· “Assigning Permissions to View and Manage Reports for Visual Studio ALM” at http://aka.ms/TFSReportsPermissions

Security Management

If you ever have to manage security and permissions in a Team Foundation Server environment, you'll want to follow a few general principles.

Deny, Allow, and Unset Permissions

A deny permission takes precedence over all other permission settings, including an allow permission. Consider the example where a user is a member of two groups. One group has a permission set to deny, and the other group has the same permission set to allow. In this case, the user will be denied that permission.

Because the deny permission takes precedence, a common practice is to not set any explicit permissions. If permissions are neither set to allow nor deny, an implicit permission of deny is applied. This setting is referred to as “unset.” This allows the user to gain that permission by inclusion in another group that has an allow for that permission.

Note

For more information, see “Team Foundation Server Permissions” at http://aka.ms/TFSPermissions.

Use Active Directory Groups

Before Team Foundation Server is introduced into an organization, there is usually a process (whether formal or informal) whereby people can be given access to different network resources. The easiest way to manage this is by creating security groups in AD and applying the permissions to the group.

Some organizations have self-service tools with built-in approval processes that allow users to join groups. One such example of a product that provides this service is Microsoft Forefront Identity Manager.

Some organizations have Help Desk processes that allow people to join groups. The Help Desk staff has training in the AD tools, and it can move users in and out of groups.

As discussed earlier, Team Foundation Server has its own concept of groups and tools for managing those groups. A lot of organizations keep the Team Foundation Server groups very simple and put a single AD group in each of them. This allows the existing group management processes to be used without having to train people on how Team Foundation Server groups work.

Avoid Granting Individual User Permissions

To make permission and security management easier, you should avoid setting explicit user permissions. Instead, identify the role of the user and create a group for that role. Then apply permissions to the role.

With this process, it's much easier to give other people the same permissions. For example, when someone changes roles within the organization or gets a promotion, that person can easily be added to the “Branch Admins” or “Build Masters” group to provide the required access for his or her new responsibilities.

With that said, though, you want to avoid a proliferation of groups and nesting of groups. If you want to find out how a user has access to a file, you don't want to be hunting through five different nested groups. Keep the nesting shallow.

Additionally, the teams you create in Team Foundation Server 2013 can also serve as team project groups for granting and managing security access.

Use Inheritance

Where possible, you should set permissions at a high level, and enable inheritance for the sub-items. This is especially true for version control because the files in every command must have their security permissions checked.

If you have many individually set permissions throughout your version control tree, that means lots of work for the application tier to validate them and trim the results. You will see increased CPU load on your application tiers and sometimes poor response times. By setting permissions higher in the tree, they can be cached and files can be transferred with very little overhead. You will see similar performance degradation each time you break the inheritance lower in the tree or when you use deny grants.

Tools

People use a few tools to manage permissions in Team Foundation Server. Visual Studio Team Explorer and the Team Foundation Server Administration Console are the most common. If you do a lot of security management in Team Foundation Server, you will want to become familiar with the command-line tools.

TFSSecurity.exe is included with a Visual Studio Team Explorer installation. If you're comfortable with the command line, you'll find it to be a very powerful tool that is much faster than clicking through menus and dialog boxes in Visual Studio.

Perhaps the most useful application of this tool is the /imx command. Using this option, you can list the expanded group memberships of any user or group within the system. This is great for working out how a user is nested in a group.

To run the command, you must specify a server to run it against and a user or group to look up.

TFSSecurity.exe /collection:http://server:8080/tfs/Collection

/imx n:DOMAIN\user

You can also use the tool with the /g+ command to add team project groups to server groups, which is something that you cannot do through Visual Studio.

Note

For more information, see “Changing Groups and Permissions with TFSSecurity” at http://aka.ms/TFSSecurityTool.

TFSSecurity.exe is not the only tool. Table 24.13 shows some other included command-line tools.

Table 24.13 Other Command-Line Tools

Summary

This chapter started with an overview of the security model used in Visual Studio Online as well as different types of users and groups that you'll encounter when managing a Team Foundation Server 2013 environment. Following this, you caught a glimpse into some of the new and interesting permissions available in Team Foundation Server. Some ambiguous permissions purposes were also clarified.

After taking a look at the different parts that make up security, the rest of the chapter covered some tips for managing security, along with some tools to make things easier, such as the Team Foundation Server Administration Tool.

Chapter 25 covers all things related to monitoring the server health and reporting on the performance of Team Foundation Server. The chapter will introduce you to the Best Practices Analyzer and the System Center Operations Manager management pack. It will also cover some of the rich activity logging details that the server collects over time.