针对不同 AD 域中的机器的 TFS“目标机器上的 Powershell"任务 [英] TFS 'Powershell on Target Machines' task for machines in different AD domain
问题描述
我们希望在我们的部署中使用 TFS 发布管理.我们有几个环境(dev、qa、staging、prod).他们每个人都在单独的 AD 林中.构建机器也驻留在单独的森林中.他们之间没有信任.
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.
我将目标机器设置为接受用于 PS 远程处理的 CredSSP 身份验证.我能够从构建机器进入目标机器上的 PS 会话.但是 TFS 任务目标机器上的 Powershell"没有运气.
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'.
这里是我的任务在 TFS 中的样子:目标机器上的 TFS PS 任务
Here how my tasks looks in TFS: TFS PS on Target Machines task
在日志中:2016-12-30T15:04:11.0279893Z System.Management.Automation.Remoting.PSRemotingTransportException:连接到远程服务器 app.dev.local 失败，错误消息如下:WinRM 无法处理请求.使用协商身份验证时出现错误代码 0x80090322 的以下错误:发生未知安全错误.
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.
有没有办法让 TFS 在位于构建机器 AD 域之外的目标机器上运行 PS?
Is there any way to make TFS run PS on target machines that resides outside of build machine AD domain?
AD 信任看起来不是一种选择.如果没有适当的 PS 远程处理，发布管理似乎无法为我们提供太多价值.
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.
推荐答案
TL;DR;
不，你有两个选择.
- 在您的主域和所有子域之间设置单向信任，以便您的生产域凭据可用于所有子域.
- 使用影子帐户来允许跨域身份验证.这些是在允许身份验证的机器上具有相同用户名和密码的本地帐户.这是针对非信任域身份验证的 MSFT 官方解决方法.
- 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.
- 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.
长答案
除此之外，由于您远离受支持的快乐路径，您需要实现自己的自定义任务，以促进您想要的跨域身份验证.在 PowerShell 中实现您自己的任务应该是一项相当简单的任务.
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
现实情况是，您需要测试 AD"的场景非常有限.环境，并且为 Dev、QA 或 Staging 设置域永远是不正确的.AD 不是这样设计的，我从未见过它为组织或开发工作带来好处.这是过度偏执的系统管理员的产物，它是一个失败的原因.
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.
拥有永久附加域的唯一原因是让您的系统管理员测试他们的域更改和配置.
对于主动更改 AD 或需要特定设置进行测试的软件开发项目，您将动态创建测试域以及所需的测试机器.这就是您针对域创建有效且可重复的测试的方式.
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.
这篇关于针对不同 AD 域中的机器的 TFS“目标机器上的 Powershell"任务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
