Security Changes

Build machine configuration

This post relates to the general series of posts on configuring an MSbuild farm using Powershell.

So that my build agents can delegate build tasks to the workstations, I need to make a few slight configuration changes to all the participants.

Let's get a few terms sorted

For the avoidance of doubt, here's a few key terms that I'll be using throughout this series of posts.

Build agents

When I say build agents, I am referring to the PC's that are running the TFS build agent service. These are the machines that TFS relies upon to orchestrate the builds.

In terms of CredSSP, the build agents act only as a client (originators).

Workstations

When I say workstations, I am referring to the desktop computers that I'll be pushing remote jobs too.

In terms of CredSSP, the workstations are both clients (originators) and servers (receivers). 

CredSSP

CredSSP is a multi-hop security mechanism, it's full name is "Credential Security Service Provider".
Essentially, CredSSP works like a passport in that it permits scripts to make multiple hops across a network from their point of origin. Without CredSSP, scripts could only make one hop from the originator and would be subject to strict sand-boxing on the remote host.

To give a more real world example, CredSSP will allow a build agent to run a PSJob that will go on to invoke a remote session on one or more build workstations. And these remote sessions are able to access network locations beyond the workstation host.

Just FYI, but CredSSP doesn't work on XP, 2003 or earlier incarnations of Windows. This is only for Vista, Windows 7, 2008 and beyond. 

Getting started

These are basic steps, just enough to allow my pool of machines to talk to each other. I am by no means claiming that this is secure, or even best practice. I strongly suggest reading this in-depth article about setting up WinRM and CredSSP from Microsoft.

With the disclaimer and warnings out of the way, I'm going to quickly configure our developer workstations to accept remote connections using CredSSP.

Configuring the "build agents"

The build agents are configured to work both-ways.

• They make outbound connections to the developer workstations
• They receive inbound connections from the workstations for file access.

In an Powershell console running with elevated permissions:

Configuring the "workstations" in my nascent build farm

The workstations are also configured to work both-ways.

• They receive inbound connections from the build agent.
• They will make outbound connections to other network resources for access to files
• In my case, this will be the build agent which will have the TFS workspace.

In an Powershell console running with elevated permissions, type:
The CredSSP services can be disabled any time

Testing

From my own computer (acting as build agent), I should now be able to connect to one of my new build workstations, and then inspect the file system back on my local computer.

What really happened?

Well, nothing ever goes quite to plan, does it? :) The information in my post above got me 90% there, but there were a few extra steps I'd kind of skipped over, and/or forgotten. Fortunately, someone invented the Internet, and here's what else I had to do.

So, the new developers PC wasn't configured at all for any form of Powershell Remoting, and it's likely that most PCs won't be.

The first 4 lines simply setup the machine for remoting, which includes opening port 5985 in your firewall. The 6th line is a critical step that modifies the computers policy settings.

Job Done! Next up, job scheduling. How I'm going to orchestrate my jobs for remote execution on the developer PC's. I have already started this, but it needs a bit of refining before I embarras myself any further in a public forum :)