ASP.NET - 获取 DirectoryEntry / SID 的主体 / 相对标识符 (RID)

发布于 2024-07-30 08:44:30 字数 1429 浏览 11 评论 0原文

我在自定义 MembershipProvider 类中使用 Active Directory 对 ASP.NET 2.0 Intranet 应用程序中的用户进行身份验证,并将其 sid 与该应用程序的配置文件相关联。

当使用ActiveDirectoryMembershipProvider时,MembershipUserProviderUserKey对象如下

SecurityIdentifier sid = (SecurityIdentifier)Membership.GetUser().ProviderUserKey;
string sidValue = sid.ToString();

/* sidValue = "S-1-5-21-XXXX-XXXX-XXXX-YY"  */

据我所知,YY是命名空间(也称为组/域)内的主体。

使用自定义 MembershipProvider 时,我可以使用 DirectoryEntry 对象的 objectSid 属性获取 sid。

DirectoryEntry entry = new DirectoryEntry(path, username, password);
SecurityIdentifier sid = new SecurityIdentifier((byte[])entry.Properties["objectSid"].Value, 0);
string sidValue = sid.ToString();

/* sidValue = "S-1-5-21-XXXX-XXXX-XXXX"  */

本例中的 sidValue 是相同的,只是它不包含主体 YY 。

我的问题有两个:

  1. 为了唯一地识别一个人是否需要委托人?
  2. 是否可以从 DirectoryEntry 对象(或通过 System.DirectoryServices 中可用的任何其他类)获取主体?

编辑:

做了一些进一步的阅读({1} {2}),我现在知道如果用户移动,sid 可以更改从一个组/域到另一个组/域。 鉴于此,使用 DirectoryEntry Properties["objectGUID"] 中定义的 GUID 是否是唯一标识用户的更好选择?

I am using Active Directory in a custom MembershipProvider class to authenticate users in an ASP.NET 2.0 intranet application and associate their sid with a profile for the application.

When the ActiveDirectoryMembershipProvider is used, the ProviderUserKey object for the MembershipUser is as follows

SecurityIdentifier sid = (SecurityIdentifier)Membership.GetUser().ProviderUserKey;
string sidValue = sid.ToString();

/* sidValue = "S-1-5-21-XXXX-XXXX-XXXX-YY"  */

As I understand it, YY is the principal within the namespace (also referred to as a group/domain).

When using the custom MembershipProvider, I can get the sid using the objectSid property of a DirectoryEntry object

DirectoryEntry entry = new DirectoryEntry(path, username, password);
SecurityIdentifier sid = new SecurityIdentifier((byte[])entry.Properties["objectSid"].Value, 0);
string sidValue = sid.ToString();

/* sidValue = "S-1-5-21-XXXX-XXXX-XXXX"  */

The sidValue in this case is identical, except it does not contain the principal YY.

My question is two-fold

  1. Is the principal required in order to uniquely identify an individual?
  2. Is it possible to obtain the principal from the DirectoryEntry object (or through any other classes available in System.DirectoryServices)?

EDIT:

Having done some further reading ({1} {2}), I now know that the sid can change if the user is moved from one group/domain to another. In light of this, would using the GUID defined in the DirectoryEntry Properties["objectGUID"] be a better choice for uniquely identifying a user?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

怪我鬧 2024-08-06 08:44:30

objectGUID 是识别用户帐户的最佳选择。 我强调这一点是因为 objectGUID 对于帐户实例来说是唯一且固定的。 如果您删除并重新创建具有相同专有名称的帐户,您将获得不同的 objectGUID。 因此,objectGUID 并不识别用户,而是识别帐户。

因此,如果您想识别帐户,请使用 objectGUID。

有时,管理员可以删除并重新创建帐户来解决问题。 如果即使在发生这种情况后您仍需要识别用户,则需要在帐户对象上选择其他内容。 这可能取决于您的帐户定义策略。 也许您的 sAMAccountNames 不基于用户名? 也许管理员会填充employeeid 或employeeNumber? 也许他们强制显示名称的唯一性?

以下是 AD 属性信息的链接。
以下是DirectoryEntry 属性的链接。

The objectGUID is the best choice for identifying a user account. I highlight this because the objectGUID is unique and fixed for an instance of an account. If you delete and recreate the account with the same distinguishedName you'll get a different objectGUID. So, objectGUID doesn't identify the user, it identifies the account.

So, if you want to identify the account, use objectGUID.

Sometimes, accounts can be deleted and recreated by admins to solve problems. If you need to identify the user even after this has happened, you need to pick something else on the account object. That will probably have to depend on your account definition policies. Maybe you have sAMAccountNames that are not based on the user's name? Maybe the admins populate employeeid or employeeNumber? Maybe they enforce uniqueness for displayNames?

Here's a link to AD attribute info.
Here's a link to DirectoryEntry Properties.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文