Delen via

Using Release Management to deploy to untrusted target server

  • Artikel

Starting with Release Management 2013 Update 4, deployment to a target server which is in a one-way trust domain using vNext pipeline is now possible. Let’s see how we can deploy an application to such a server.

image

In this setup, Domains D1 does not trust D2. In such a case, vNext pipeline will not be able to deploy to T1. This happens because the way deployment happens is that T1 tries to connect to TFS drop server in D1 and copy application bits locally. Since D1 does not trust D2 this connection is not allowed.

To fix this problem, Release Management starting from 2013 Update 4 leverages on the concept of boundary machine. A boundary machine is a machine in domain D1 which is accessible across domains(this requires setting up proper IPsec policies). For deployment purpose, boundary machine B1 will act as a shared UNC path and will just host the build drop files. This will make sure that security of D1 is not compromised as neither RM server nor TFS drop server is exposed across domain.

When deployment starts, RM server identifies whether one of the target node is a un-trusted server and decides to use a shared UNC path(on boundary machine). It copies the required build drop files from TFS  drop server to a uniquely identified path on B1. R1 then asks T1 to get the deployment files from B1 instead of TFS drop server.

There are two kinds of security permissions which are required:

  1. RM server(R1) should be able to write to B1.
  2. Target server (T1) should have credential to copy from T1. Since T1 is not in B1’s domain, it cannot automatically do that. To make this happen RM passes this credential to T1.

To specify B1 shared path and credential for T1 to connect to it, Global configuration variables should be used:

image

Please note that user1 specified in above example does not need to be an user on T1. RMSharedUNCUser and RMSharedUNCPwd are domain D1 user credentials which will be passed onto T1 for accessing RMSharedUNCPath.

All three variables should have exact same matching case as shown above.

Also, as mentioned earlier, RM server needs to know that it has to use this boundary shared UNC path. For this purpose, we need to mark T1 appropriately in RM.

image

Use “Use Shared UNC Path” radio button to specify that this server needs a boundary machine to access drop. Also note that DNS name is using IP address as this server lies in different domain.

No other changes are required apart from the two mentioned above. The release template looks same.

image

Comments

  • Anonymous
    February 04, 2015
    Hi I'm not sure whether this quite applies to my scenario. Could I ask you take a look at my SO question here: stackoverflow.com/.../rm-dsc-to-node-in-untrusted-domain In my case, RM can copy the bits from the TFS drop location to the target node absolutely fine (because we have shadow accounts in both domains). However other than the initial copy of bits, nothing else is happening thanks