TFS 'Powershell on Target Machines' task for machines in different AD domain

0
votes

We want to utilize TFS release management for our deployments. We have several environments (dev, qa, staging, prod). Each of them in separate AD forest. Build machine also resides in separate forest. No trust between them.

I set up target machines to accept CredSSP authentications for PS remoting. I was able to enter PS session on target machine from build machine. But no luck from TFS task 'Powershell on Target Machines'.

Here how my tasks looks in TFS: TFS PS on Target Machines task

In logs: 2016-12-30T15:04:11.0279893Z System.Management.Automation.Remoting.PSRemotingTransportException: Connecting to remote server app.dev.local failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Negotiate authentication: An unknown security error occurred.

Is there any way to make TFS run PS on target machines that resides outside of build machine AD domain?

AD trust doesn't look like an option. And without proper PS remoting it doesn't look like release management can provide much value for us.

1
powershelltfspowershell-remotingms-release-management

1 Answers

2
votes

TL;DR;

No, you have two options.

  1. Setup one way trust between your primary domain ans all of your sub domains so that your production domain credentials can be used on all of your sub domains.
  2. use shadow accounts to allow cross domain authentication. These are local accounts with the same username and password across machines that allows auth. This is the official MSFT work around for non trust domain auth.

The long answer

Other than that, since you are well off the supported happy path, you would need to implement your own custom tasks that facilitated the cross domain authentication that you want. Should be a fairly simple task to implement your own tasks in PowerShell.

https://www.visualstudio.com/en-us/docs/integrate/extensions/develop/add-build-task

The reality is that there are only a few limited senarios that you need a "test AD" environment and it is never correct to have domains for Dev, QA, or Staging. AD is not designed that way and I have never seen it work for the benefit of the organisation or the development efforts. It is a product of over paranoid sysadmins and it is a lost cause.

The only reason to have a permanent additional domain is for your sysadmins to test their domain changes and configurations.

For software development projects that actively change AD, or require specific setups for testing, you would dynamically create your test domain along with the test machines required. That is how you create valid and repeatable tests against a Domain.