1

I am using TFS 2017 Update 2 Release processing. I have a functioning deploy process that works within a domain (it runs successfully against 10 different deployment environments)... and now I need to deploy into a different environment, which lives in a different A/D domain.

Unfortunately, the domain trust is one way between the domains - and the destination domain ("Production") does not trust the domain I am installing from ("Dev")

The problem I'm seeing seems to be the infamous "double hop" credential problem.

My TFS app tier can see (and trigger activity on) the release server running TFS vNext Agent 2.117.2 Futher, I can execute inline PowerShell, and locally hosted PowerShell scripts on the release server just fine.

Howerver, as soon as I try to access a PowerShell script not on the release server (be it in the Production domain with the release server, or in the Dev domain) I get an error:

2018-02-13T19:03:32.6611149Z ##[error]. : AuthorizationManager check failed.
At line:1 char:3
+ . '\\unc\path\to\share\TFSScripts\Emit-Variables2. ...
+   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : SecurityError: (:) [], PSSecurityException
    + FullyQualifiedErrorId : UnauthorizedAccess

The account running the TFS release service has been confirmed to have access to the script file when running from the desktop of the release server, so access should not be an issue.

Further testing of the issue has identified that if we manually create a PSSession using -Authorization CredSSP and pass a credentials object we can successfully access the off server resources.

However, I can see no way to configure TFS to use CredSSP as the authorization mechanism.

The servers involved are W2K8R2 - so we cant use the constrained delegation functionality that W2K12 introduced. We have also tried SPNs with similar unsuccessful results. Kerberos has been forced to use TCP by setting the max packet size to 0 (thus also preventing fragmented UDP packets and related problems). Our max Kerberos packet size is set to 48000.

In the ultimate end state, The TFS App server, and all the TFS artifacts and release scripts will sit in the "dev" domain on one side of a firewall... and the production release server, and a set of servers to release to will exist in the "production" domain, on the other side of a firewall

CredSSP seems to be the only way to make this work - but I see no way for TFS to be configured for it.

This can't be a unique problem. Can someone provide some insight on how to get around this?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Scott Brown
  • 301
  • 2
  • 16
  • Could you TFS serve be accessible from the untrust domain machine without a firewall intervening? – PatrickLu-MSFT Feb 14 '18 at 12:20
  • No - the two domains live in two separate data centers are are physically separate with the public internet between them... firewalls are a must :) – Scott Brown Feb 14 '18 at 12:46

1 Answers1

0

Sorry it's not able to force TFS to use CredSSP when accessing network resources. And on configuration of TFS to use CredSSP as the authorization mechanism

You must manually enable CredSSP in powershell.

Another way take a look at this solution, which may do the trick: TFS2015 Release Management: Deploying to an untrusted domain by having the deployment agent run under a shadow account.

PatrickLu-MSFT
  • 49,478
  • 5
  • 35
  • 62
  • sorry, I should have mentioned we also went down the Enable-WSManCredSSP for client/server route with no luck. I believe my SysOps guy tried the shadow account trick, but I'll bring this article forward to him as I know we did not do any special magic with the production Agent. – Scott Brown Feb 14 '18 at 12:37
  • Shadow accounts did not work. We have done this from "dev"->"prod" but the other direction is failing. Very strange. – Scott Brown Feb 16 '18 at 23:55
  • Crossing from "prod" into "dev" is the problem even though "dev" trusts "prod". I have managed to get the process to work if all the resources are local to the "prod" domain however. This is not our ideal state as we are now (effectively) running a new process in the "prod" domain using different scripts than were used in the "dev" domain. This configuration also does not let me run scripts local to the TFS release server in "prod" in the same manner as I could in "dev" - the resources need to be referenced as local drive (C:\TFSScripts\...) ... so something is still askew... – Scott Brown Feb 16 '18 at 23:57