Setting up a TFS demo environment with SSL
In order to demonstrate the features of TFS, I use the ALM Virtual Machine from Brian Keller, designed for the Microsoft Hands on Labs of TFS.
It’s a virtual machine pre-installed with Visual Studio Enterprise 2017 (15.5), Visual Studio Team Foundation Server 2018, Office and pre-configured with sample projects, users and data.
You can download the VM as instructed here and configure it as instructed here. It’s a 18 GB download, you’ll need Hyper-V enabled and a minimun of 8GB of RAM available for use.
After it’s configured, I edit my hosts file for making it easier to access the TFS Portal on the host machine. I configured a Virtual Switch between the host and the VM on Hyper-V Virtual Switch Manager, and then selected it on the Network Adapter settings of the VM. Then I identified the IP Address and included it on the hosts file on the C:\Windows\System32\drivers\etc folder.
This way you can access the VM through the browser by the url http://vsalm:8080/tfs.
I found a really good explanation about the default settings of TFS from this article:
For many releases, the default web site settings for Team Foundation Server have been:
- A single HTTP binding for the TFS web site on port 8080, with no host name or IP address specified.
- A public URL (previously referred to as the Notification URL) of the form http://machine-name:8080/tfs.
The primary benefit of these settings is that they are very simple to set up and convenient for end users in most scenarios. In particular:
- Using HTTP rather than HTTPS avoids the need to obtain and install certificates.
- Using 8080 rather than 80 avoids potential conflicts with other sites on the same machine.
- Using “tfs” as the virtual directory for the site makes it easier to host Team Foundation Server and other web sites on the same port on the same server.
- Using the machine name, rather than the fully-qualified-domain-name (FQDN), in the public URL saves a lot of typing.
- Leaving the host name in the binding unspecified allows for flexibility in connecting — machine name, FQDN, or IP address will all work when users try to connect to their servers.
These settings are not, however, secure by default. In particular, by not using an HTTPS binding, communication to and from Team Foundation Server is not encrypted in transit unless other solutions like IPSec are used. They are thus potentially vulnerable to malicious actors monitoring or even modifying the contents of the communication. These issues are mitigated to some extent when TFS is deployed on an intranet behind a corporate firewall, as the vast majority of TFS instances are. But even in these scenarios, data sent to and from TFS includes source code, work item data, and other information which could often benefit from additional security.
Additionally, since TFS 2017 new authentication scenarios exist (build/release agent service account authentication, personal access tokens) which send bearer tokens over the wire. If these tokens are obtained by malicious users, they can then be used to impersonate the users to whom they belong.
In a real life scenario, you’ll probably have a dedicated server, configured with SSL. So, in order to make this demo environment more realistic and to be able to use features that consume Person Access Tokens, let’s generate a self-signed certificate and create a HTTPS binding on the TFS Web Site.
Self-signed certificates are useful for trial deployments of Team Foundation Server, since they are very easy to provision and use. They are less appropriate for production deployments of Team Foundation Server, or exposed to the public internet. Generally, self-signed certificates are susceptible to man-in-the-middle attacks. They also cause problems for users, since they will cause certificate warnings and errors until their root certificates are installed on each client machine.
To be able to use TFS with a self-signed certificate without errors or warnings, the certificate has to have a subject alternative name, the subject has to mach the URL that you want to access the TFS Portal, and it has to be installed in the Local Machine Trusted Root Certification Authorities on all the clients. In our case, in the VM itself and in the host machine.
It is possible to generate a self-signed certificate directly from IIS, but it is not valid on Chrome, since it doesn’t have the the subject alternative name, causing the “NET::ERR_CERT_COMMON_NAME_INVALID” error. To avoid this, I prefer to use the New-SelfSignedCertificate cmdlet of the pkiclient module on powershell:
New-SelfSignedCertificate -FriendlyName “vsalm” -DnsName “vsalm”, “vsalm-alt” -CertStoreLocation “cert:\LocalMachine\My”
This example creates a self-signed SSL server certificate in the computer MY store named “vsalm”, with the subject alternative name set to “vsalm, vsalm-alt” and Subject and Issuer name set to “vsalm”.
The next step is to create a new binding on IIS as the example bellow. The SSL certificate created before will be available.
Still, when you try to access the https://vsalm/tfs URL you’ll get a security error:
This is because the certificate has to be installed on the Trusted Root CA store. The easiest way is to follow the instructions of this article.
The last step is to configure the public URL of TFS. Access the Team Foundation Server Administration Console, click on Application Tier, then in Change Public URL. Type the HTTPS URL and click on Test. If the certificate was installed successfully on the Trusted Root CA, the URL will be valid. Click OK to finish the setup.
A good practice is to create a checkpoint on the Hyper-V Manager, to save the state of the configured TFS.
After that, the VM will be ready not only to the Hands on Labs, but to validate other features on TFS, like configuring external build Agents and other features that uses Personal Access Tokens.
