Question

我创建了一个服务帐户来模拟组织中的用户，以便更改用户名下的工作项。我已经将该服务帐户添加到“项目收集服务帐户”组中，该组的“代表他人发出请求”设置为“允许”。该服务帐户具有Visual Studio订阅。

然后，我使用与本地TFS一起工作的代码来执行模拟，并且出现错误500，提示“访问被拒绝：X需要以下权限才能执行此操作：发出请求代表他人”

我应该怎么做才能使其起作用？这是我正在使用的代码：

        var credential = new VssAadCredential("X@myoganization", "password");
        var collection = new TfsTeamProjectCollection(new Uri("my_devops_uri"), credential);
        MyTfsConnection.ProjectCollection = collection;

        MyTfsConnection.IdentityService = collection.GetService<IIdentityManagementService>();
        MyTfsConnection.WIStore = collection.GetService<WorkItemStore>();

        var adAccount = "someone@myoganization";
        var identity = MyTfsConnection.IdentityService.ReadIdentity(IdentitySearchFactor.AccountName, adAccount, MembershipQuery.None, ReadIdentityOptions.None);
        using (var impersonatedCollection = new TfsTeamProjectCollection(new Uri("my_devops_uri"), credential, identity.Descriptor))
        {

            var impersonatedWIStore = impersonatedCollection.GetService<WorkItemStore>();
        }

Answer 1

无法执行此操作，服务帐户无意将客户端与服务器连接，无法签入代码或更改工作项。

服务帐户用于运行与TFS相关的各种服务。它应该在计算机上具有最低权限。

客户端不应使用服务帐户连接到服务器，它们应使用自己的帐户，您可以将其授予对TFS中相关存储库的访问权限。例如，如果您将所有客户与服务帐户建立联系，您将如何知道谁签入了每个变更集，谁应该将工作项分配给谁？

您也将无法将工作项目分配给服务帐户。

Answer 2

我一直在尝试将代码迁移到使用模拟来更改另一个用户名中的工作项的DevOps Services。怪异的与您的相似。就像我们所有人都从此old post on TFS impersonation中抢了过来一样。像您的代码一样，此代码可与本地DevOps Server 2019.1.1一起使用，但在尝试使其与DevOps Services一起使用时遇到了相同的问题。

在寻找适用于TFS / DevOps（SOAP）客户端API和DevOps Services的答案时，我遇到了this SO question，其中的问题引用了以下内容。

“出于安全原因（以及合规性和许多其他原因）， Visual Studio Online不支持模拟标题”

我还没有在文档的任何地方找到相同的信息。但是，这似乎是事实。在Azure DevOps Services中禁用了模拟。德拉特！

不遗余力，我的搜索还从the November 2017 release notes中获得了以下内容，这似乎很有希望。

向特定用户授予旁路规则权限

通常，从其他来源迁移工作项时，组织想要保留工作项的所有原始属性。对于例如，您可能想创建一个保留原始错误的错误创建日期并通过系统中的值创建日期起源。

用于更新工作项的API具有绕过规则标志，以启用该标志场景。以前发出该API请求的身份必须是 Project Collection Administrators组的成员。有了这个部署中，我们在项目级别添加了执行权限带有旁路规则标志的API。

但是，我在DevOps Server或DevOps Services的集合/组织或项目权限中找不到此类权限。德拉特！这导致我进入this SO answer，在那里直接使用REST API在JSON中制作工作项更新。因此，绕过规则选项必须仍然有效，只是不能作为可设置的权限公开。

因此，我再次开始查看TFS / DevOps（SOAP）客户端API，并发现WorkItemStoreFlags.BypassRules标志在创建时传递给WorkItemStore。下面应该提供基本的机制。

// Use a personal access token with Work Items scope
var credentials = new VssBasicCredential(String.Empty, "Your PAT");

// Connect with TFS / DevOps client libs.
// Older SOAP based client but still works with DevOps Services.
var teamProjectCollection = new TfsTeamProjectCollection(new Uri("https://dev.azure.com/your-org"), credentials);

// Don't use teamProjectCollection.GetService<WorkItemStore>().  
// New up WorkItemStore using the collection and explicitly specify the BypassRules flag.
// This allows you to set the CreatedBy field later.
var workItemStore = new WorkItemStore(teamProjectCollection, WorkItemStoreFlags.BypassRules);

// Get the project, work item type, and create the new work item.
var project = workItemStore.Projects["YourProject"];
var workItemType = project.WorkItemTypes["Product Backlog Item"];
var workItem = new WorkItem(workItemType);

// Set the work item fields
workItem.Title = "The Title";
// Without the BypassRules flag the CreatedBy value set here will be ignored on
// Save() and replaced with the user account attached to the PAT used to authenticate.
workItem.Fields[CoreField.CreatedBy].Value = "NotYourUser@yourdomain.com";
workItem.Fields[CoreField.AssignedTo].Value = "NotYourUser@yourdomain.com";
workItem.Save();

如何使用服务帐户模拟Azure Devops中的用户

2 个答案: