我正在使用TFS 2017 Update 2发布处理。我有一个在域内工作的有效部署流程（它在10个不同的部署环境中成功运行）......现在我需要部署到不同的A / D域中的不同环境中。
不幸的是，域信任是域之间的一种方式 - 目标域（“生产”）不信任我正在安装的域（“开发”）
我看到的问题似乎是臭名昭着的“双跳”凭证问题。
我的TFS应用层可以看到（并触发活动）运行TFS vNext Agent 2.117.2的发布服务器。我可以在发布服务器上执行内联PowerShell和本地托管的PowerShell脚本。
Howerver，一旦我尝试访问不在发布服务器上的PowerShell脚本（无论是在发布服务器的生产域中，还是在Dev域中），我都会收到错误：
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
从发布服务器的桌面运行时，已确认运行TFS发布服务的帐户可以访问脚本文件，因此访问不应成为问题。
对该问题的进一步测试表明，如果我们使用 -Authorization CredSSP 手动创建PSSession并传递凭证对象，我们就可以成功访问关闭服务器资源。
但是，我看不到配置TFS使用CredSSP作为授权机制的方法。
涉及的服务器是W2K8R2 - 因此我们无法使用W2K12引入的约束委派功能。我们也尝试过类似的不成功的SPN。 Kerberos通过将max packet size设置为0来强制使用TCP（因此也防止了碎片UDP数据包和相关问题）。我们的最大Kerberos数据包大小设置为48000。
在最终结束状态下，TFS App服务器以及所有TFS工件和发布脚本将位于防火墙一侧的“dev”域中......以及生产版本服务器和一组服务器释放到将存在于防火墙另一侧的“生产”域中
CredSSP似乎是实现这项工作的唯一方法 - 但我认为没有办法为它配置TFS。
这不是一个独特的问题。有人可以提供一些有关如何解决这个问题的见解吗？
答案 0 :(得分：0)
很抱歉，在访问网络资源时，它无法强制TFS使用CredSSP。并且在配置TFS时使用CredSSP作为授权机制
您必须手动在powershell中启用CredSSP。
另一种方法是看看这个解决方案，它可以解决这个问题：TFS2015 Release Management: Deploying to an untrusted domain让部署代理在影子账户下运行。