TFS 安全性 - 读者和贡献者组中的用户

Posted 2023-02-23

【中文标题】TFS 安全性 - 读者和贡献者组中的用户

【英文标题】：TFS security - users in both Readers and Contributors groups

【发布时间】：2013-09-14 15:18:09

【问题描述】：

我正在尝试在 TFS 中设置安全性并遇到问题。 我们有几个团队项目和大约 30 名开发人员。 我们希望所有开发人员都拥有对所有团队项目的读取权限。 然后是某些团队对一个或多个团队项目具有读/写访问权限。

我有一个包含所有 30 名开发人员的广告组和其他几个拥有适当开发人员的广告组。我将包含所有开发人员的 AD 组分配给每个团队项目中的 Readers 组。然后是其他特定组作为各自团队项目的贡献者。

问题在于，当用户同时在 Readers 和 Contributors 组中时 - 它看起来好像使用了 Readers 组权限（因为它们更具限制性）。根据文档，这似乎是 tfs 安全应该工作的方式。

但是我怎样才能正确设置呢？

【问题讨论】：

这让我感到惊讶——在我的（默认）TFS 配置中，读者和贡献者组当然具有不同的“允许”权限，但没有“拒绝”权限。因此，我希望通过两个组的成员资格获得的权限是附加的。您是否检查过哪些权限与设置中的“读者”和“贡献者”组相关联？是否有任何权限被拒绝？

Yes - 例如：用户 XYZ 位于附属于 Readers 组的 AD 组中，除读取权限外，所有权限均拒绝。同一个 XYZ 用户也在另一个 AD 组中，该组附加到每个权限都允许的贡献者组。

在这种情况下，您需要从 Readers 组的权限中删除“拒绝”。如果您明确拒绝一个组的权限，它不会被您所属的另一个组的允许覆盖。

组的权限是累加的，但拒绝比允许强。

【参考方案1】：

这有点旧，但也许你仍然会发现它很有用。

将所有开发人员分配到 Readers 组是一种捷径，在这种情况下您不应该采取这种捷径。

我会为每组开发人员创建一个单独的组（根据项目划分），然后为这些组分配权限 - 类似于他们自己项目的贡献者和所有其他项目的读者。

至于为什么它对您不起作用 - 如果用户同时拥有 Deny 权限，则Allow 权限将胜过这两个权限。

【讨论】：

您可以让开发人员位于多个组中，并将这些单独的 AD 组分配给他们需要成为贡献者的每个团队项目。关键是在您的安全设置中使用Not Set 而不是Deny。 Not Set 默认为 Deny，但它允许 Allow 覆盖组。这就是我过去做事的方式。