如何强制TFS访问网络资源时使用CredSSP？跨域部署遇双跳问题

嘿，我在处理TFS跨域部署时碰到过好多次这种单向信任下的双跳坑，给你几个经过验证的解决方案，适配你这个TFS 2017 Update 2的场景：

1. 在目标域（Production）部署本地TFS代理，用PAT注册 #

这是最直接的解决办法，核心思路是让部署操作完全在目标域的安全上下文里执行，避免跨域凭据传递：

• 操作步骤：
  • 到Production域的目标服务器上，从你的TFS服务器下载对应版本的部署代理安装包。
  • 安装时选择运行代理的账户为Production域的本地系统账户（如果仅部署到该机器），或者Production域的域账户（如果需要访问该域内其他资源）。
  • 注册代理时，跳过域凭据认证，改用个人访问令牌（PAT）：运行config.cmd --auth pat，输入你在TFS上生成的、拥有部署权限的PAT即可完成注册。这样代理就能绕过域信任问题，直接和TFS服务器建立连接。
• 优势：不需要修改任何域配置，部署流程和你现有域内的流程几乎一致，稳定性拉满。

2. 拆分部署流程：先传包再本地执行 #

如果没法在目标域安装代理，可以把部署拆成两步，全程用目标域账户操作：

• 第一步：用TFS的文件复制任务，使用Production域的账户作为凭据，把部署包直接复制到目标服务器的本地目录。
• 第二步：用PowerShell远程执行任务（或WinRM任务），同样使用Production域账户，远程触发目标服务器上的本地部署脚本。
• 优势：不需要额外安装代理，适合临时或小规模的跨域部署场景，每一步都没有凭据传递的双跳问题。

3. 配置Kerberos约束委派（需域管理员配合） #

如果Production域的管理员愿意配合，可以通过Kerberos委派来解决双跳：

• 让Production域的管理员在他们的域控制器上，配置约束委派，允许Dev域的TFS服务账户（或Dev域的部署代理账户）委派访问Production域内目标机器的特定服务（比如WinRM、SMB等）。
• 注意：因为是单向信任，Production域不信任Dev域，所以这个配置必须在Production域内完成，且需要较高的权限，适合长期稳定的跨域部署需求。

4. 用Production域的跳板机中转 #

找一台Production域内的机器作为跳板机，在上面安装TFS代理并使用Production域账户运行：

• 发布流程先把部署包传到跳板机，再通过跳板机的代理把包部署到目标环境。
• 优势：所有部署操作都在Production域内完成，不需要跨域传递凭据，适合需要部署到多个Production域机器的场景。

个人优先推荐方案1，它的适配性最强，也最符合你现有部署流程的架构，改造成本最低。

内容的提问来源于stack exchange，提问作者Scott Brown