将 Windows SID 存储在数据库中以进行查找答案

【问题标题】：Storing a Windows SID in a Database for Lookup将 Windows SID 存储在数据库中以进行查找
【发布时间】：2010-12-10 08:37:22
【问题描述】：

我有一个 ASP.NET MVC 应用程序，我需要允许客户根据他们的环境配置 MembershipProviders，但仍然能够将该 MembershipUser 映射到我们数据库中的具体用户模型。

Membership.GetUser() 将允许我访问登录用户的Membership.ProviderUserKey。我可以使用它来关联用户记录。我们的自定义 SQL 提供程序将只返回 User.Id，但 AD 是另一回事。在这种情况下，ProviderUserKey 是 IdentityReference。

您可以想象，这些查找会非常频繁地发生（尽管缓存可以帮助减少数据库级别的查找）。

我无法决定哪条路线更好：将 SID 存储为 varbinary 或 varchar 列。该列不是主键，也没有聚集索引。知道我可以很好地索引字符串，并且以字符串格式读取 SID 肯定比二进制更好。有人愿意分享他们是如何解决这种情况的吗？

更新

我不知道我在发帖前搜索时错过了this SO question，但很明显ActiveDirectoryMembershipProvider 和ActiveDirectoryMembershipUser 并不完全适合手头的任务，因为它们今天存在.

在那个 SO 问题 linked the following article 中的答案，其中陈述了以下内容：

a 的相对标识符部分 SID 相对于域是唯一的，因此，如果域发生变化，则相对标识符也会改变。

因此当一个用户对象从一个移动域到另一个，新的 SID 必须是为用户帐户生成和存储在 Object-SID 属性中。

但是，每个组和用户都有一个 Object-GUID，即使帐户被移动，它也永远不会改变。因此，我应该在我的 User 类中使用 Object-GUID，而不是 Object-SID。否则，如果某人的用户记录被移动，从而破坏了他们的主体与他们创建的数据之间的关系，他们的用户记录将被放弃。

不幸的是，ActiveDirectoryMembershipUser 不允许我使用 Object-GUID。因此，我要么必须在 ActiveDirectoryMembershipUser 完成工作后将 SID 转换为 GUID，要么创建我自己的 MembershipProvider 来完成我需要的一切。不幸的是，这意味着我可能不得不重复 ActiveDirectoryMembershipProvider 已经为我完成的工作。

【问题讨论】：

感谢更新信息 - 非常重要，值得了解。

标签： sql database-design asp.net-membership

【解决方案1】：

Microsoft 将 SID 作为 varbinary(85) 存储在 sys.server_principals

这也是一个唯一的列，所以它必须有一个索引...

【讨论】：

这是我原始帖子的一个很好的答案，所以我会给你信用。不幸的是，在对此进行了更多研究之后，看起来我根本不需要 SID（请参阅更新）。谢谢。

【解决方案2】：

用户名是您要索引的最后一项。

仅当您将用户从一个域更改为另一个域时，AD 中的 SID 才会发生变化。 RID 分为 2 组 - 内置 (

如果你想处理用户的移动等，那么 GUID 是要走的路。

可以在用户和组管理中随时更改用户名。

这与对象名称不同，对象名称是不变的，但我不认为它在整个森林中是唯一的。您可以拥有任意数量的 John Smith 用户。

我会研究 ADSI 对象。这些是应该可以从 ASP 访问的 COM 对象。 MSDN解释得很好。 ADSearch 对象可用于从 GUID 返回用户属性（例如，包括 DN）。

【讨论】：

感谢您的评论。我绝对对 Object-GUID 感兴趣，我只是对使用内置 AD 成员资格提供程序无法使用它感到沮丧。我最终创建了一个衍生提供程序，将 SID 替换为 GUID。

【解决方案3】：

听起来你让这件事变得比实际需要的困难得多。您需要 SID 或 GUID 做什么？对于 ActiveDirectory 中维护的用户帐户，您已经拥有一个唯一的、完全可读的标识符。

它被称为“用户名”。希望它与您的应用“用户”表中存储的用户名相同。

您的应用只需要知道该用户名是否成功通过 ActiveDirectory 进行身份验证。因此，如果他们成功登录 - 您只需将他们经过身份验证的事实存储在您的 Session 变量中。

如果他们被配置为使用 db 用户登录，如果成功设置相同的 Session 变量表明他们成功登录。

没有花哨的 GUID 或 SID ...简单。

【讨论】：

用户名可以而且确实会改变（想想结婚后用户的姓氏会改变）。
是的，他们会这样做，并且根据他们在 Active Directory 中处理的方式，您的 SID 和/或 GUID 也会发生变化。不要仅仅因为涉及一些维护而避免使用简单的解决方案——因为总会有一些维护。您的解决方案越简单 - 维护就越简单。
因此我的更新。 Object-SID 可以更改，因此我不会使用它。 Object-GUID 不会更改，除非管理员更改它或重新创建帐户。对于这种特殊情况，我可以将其留给维护任务，因为它比重命名帐户要少得多。但是，如果我使用该名称，它会更改，并且他们登录系统将创建一个新的用户记录，现在我有重复/孤立的数据。如果我们可以提前避免，我们无法在每次发生这种情况时都修复或清理数据。相信我，我不是故意回避简单的。
@RonSavage GUID 永远不会改变，并且 SID 仅在帐户在域之间移动时才会改变。 technet.microsoft.com/en-us/library/cc961625.aspx 用户名不仅会发生变化，而且新员工有时会获得曾经属于以前员工的用户名。如果他们因此而继承了旧的员工历史，那将是一个真正的问题。
GUID 永远不会改变，所以它是最好的选择。您还应该将用户名保存在单独的位置（列或表）。因为在 ActiveDirectory 中删除用户帐户后，您将无法再识别用户。能够直接使用 SQL Server 获得人类可读的描述也更加方便和快捷。请记住，此描述可能不是最新的。