【问题标题】:Recommendation on AD organization关于 AD 组织的建议
【发布时间】:2014-10-14 15:39:46
【问题描述】:

我有一个场景要求在 Active Directory 中处理安全性。

我有成千上万的用户。 我有数十万份合同。 我有 6 个不同的角色,任何用户都可以在任何给定的合同中拥有。

最初的实现(别怪我,我刚到这里!)为每个合约角色创建了一个新的安全组。一旦用户被分配到适当的组(在某些情况下超过 1800 个)登录,这些用户的 LDAP 查询性能就会变得难以忍受(登录超过 11 分钟)。

所以我正在寻找更好的选择,您将如何处理这种关联?其他构建关系的方法?自定义类/属性?想法?

【问题讨论】:

  • 这些组是否真的提供了对任何东西的权限,还是只是为了保存记录?
  • 实际上是权限。有问题的代码检查用户是否是由用户尝试执行的合同和角色标识的组的成员。

标签: performance security active-directory ldap


【解决方案1】:

看起来您需要重新考虑,在 Active Directory 可扩展性限制文档中快速搜索显示:

http://technet.microsoft.com/en-us/library/active-directory-maximum-limits-scalability(v=ws.10).aspx#BKMK_Groups

安全主体(即用户、组和计算机帐户)最多可以是大约 1,015 个组的成员。此限制是由于为每个安全主体创建的访问令牌的大小限制。该限制不受组嵌套或不嵌套方式的影响。

【讨论】:

  • 是的,我看到了,这让我更深入地挖掘。似乎几年前创建了一个指向单独目录服务 (EDIR) 的 API,该目录服务能够扩展到比 AD 大得多的卷。从理论上讲,按照 API 开发人员的预期,性能影响很可能是 API 实施不佳。编码员无意中尝试进行数千次不必要的 API 调用。需要更多调查才能确定这是否是实际问题。但是我仍然很想知道是否有更好的方法来处理目录服务中的这种关系
  • @ThatRickGuy 需要特别注意的是,如果您有一个应用程序直接查询 AD 以检查组成员身份,则可以使用通讯组而不是安全组。它们基本上是无限的。根据应用程序的实现方式,您甚至可能不需要更改它(或者您可能需要,但应该很简单),并且分发组不会影响登录或 Windows 中的任何其他内容,因为只有安全组作为一部分返回登录令牌。
  • @ThatRickGuy 如果做不到这一点,请将您的 AD 身份验证系统替换为在 SQL 上运行的自定义系统。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-02-06
  • 1970-01-01
  • 2010-12-28
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多