C# active-directory .net-3.5 directoryservices

Active Directory 服务：PrincipalContext——“容器”的 DN 是什么？目的？

发布于 2024-08-26 23:01:33 字数 848 浏览 10 评论 0原文

我目前正在尝试使用PrincipalContext 类通过Active Directory 服务进行身份验证。我想让我的应用程序使用密封和 SSL 上下文对域进行身份验证。为了做到这一点，我必须使用 PrincipalContext 的以下构造函数（链接到 MSDN）页）：

public PrincipalContext(
    ContextType contextType,
    string name,
    string container,
    ContextOptions options
)

具体来说，我这样使用构造函数：

PrincipalContext domainContext = new PrincipalContext(
    ContextType.Domain, 
    domain, 
    container, 
    ContextOptions.Sealing | ContextOptions.SecureSocketLayer);

MSDN 关于“容器”的说法：

商店中用作的容器上下文的根。所有查询都是在这个根下执行的，并且所有插入执行到此容器。对于域和 ApplicationDirectory 上下文类型，这个参数是区分的容器对象的名称（DN）。

容器对象的 DN 是什么？如何找出我的容器对象是什么？我可以查询 Active Directory（或 LDAP）服务器吗？

原文

I'm currently trying to authenticate via Active Directory Services using the PrincipalContext class. I would like to have my application authenticate to the Domain using Sealed and SSL contexts. In order to do this, I have to use the following constructor of PrincipalContext (link to MSDN page):

public PrincipalContext(
    ContextType contextType,
    string name,
    string container,
    ContextOptions options
)

Specifically, I'm using the constructor as so:

PrincipalContext domainContext = new PrincipalContext(
    ContextType.Domain, 
    domain, 
    container, 
    ContextOptions.Sealing | ContextOptions.SecureSocketLayer);

MSDN says about "container":

The container on the store to use as
the root of the context. All queries
are performed under this root, and all
inserts are performed into this
container. For Domain and
ApplicationDirectory context types,
this parameter is the distinguished
name (DN) of a container object.

What is the DN of a container object? How do I find out what my container object is? Can I query the Active Directory (or LDAP) server for this?

分享到QQ

分享到微博

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

发布评论

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

叶落知秋 2024-09-02 23:01:33

好吧，我设法解决了这个问题：

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain);

domainContext.ValidateCredentials(userName, password, 
    ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

通过在 ValidateCredentials 方法中（而不是在构造函数中）指定 ContextOptions，这使我能够避免为容器对象指定 DN。

更新：

尽管我应该澄清，经过进一步的实验，我发现从该PrincipalContext对象派生的任何查询都是未加密的。

显然，当在 ValidateCredentials 中设置 ContextOptions 时，这些选项仅用于 ValidateCredentials 的特定调用。但这就是奇怪的地方......

所以，我希望对 AD 服务器的查询也进行加密。示例查询：

UserPrincipal p = UserPrincipal.FindByIdentity(
    domainContext, IdentityType.SamAccountName, userName);
var groups = p.GetGroups();
foreach (GroupPrincipal g in groups) { /* do something */ }

上面的代码获取用户所属的所有组的列表，但它是明文（未加密）发生的。经过一番摆弄，我发现 DN 永远不需要设置。

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain,
    null,ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

我发现我可以将容器对象 (DN) 设置为 null。这很好用。将其设置为空字符串 ("") 会导致某种未知类型的异常，因此不要认为可以给它一个空字符串。

这是奇怪的部分。您可能认为在PrincipalContext 中设置SecureSocketLayer 选项意味着您在使用VerifyCredentials 时不必显式设置它。但我发现，如果我没有在VerifyCredentials部分中设置它，身份验证将失败，但查询（如组的示例中）仍然以加密方式进行。

也许我还没有完全理解 AD 身份验证和查询，但这对我来说似乎很奇怪。

Well, I managed to figure out the issue:

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain);

domainContext.ValidateCredentials(userName, password, 
    ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

By specifying the ContextOptions in the ValidateCredentials method (instead of in the constructor), this allowed me to avoid having to specify a DN for a container object.

UPDATE:

Although I should clarify that after further experimentation, I found that any queries derived from this PrincipalContext object takes place UN-encrypted.

Apparently, when the ContextOptions are set in ValidateCredentials, those options are only used for that specific call of ValidateCredentials. But here's where it gets strange...

So, I wanted to have my queries to the AD server take place encrypted as well. Example query:

UserPrincipal p = UserPrincipal.FindByIdentity(
    domainContext, IdentityType.SamAccountName, userName);
var groups = p.GetGroups();
foreach (GroupPrincipal g in groups) { /* do something */ }

The above code gets a list of all the Groups that the user belongs to, but it happens in the clear (unencrypted). So after much fiddling, I discovered that the DN never needs to be set.

PrincipalContext domainContext = new PrincipalContext(ContextType.Domain,domain,
    null,ContextOptions.Negotiate | ContextOptions.SecureSocketLayer);

I found that I could set the container object (DN) to null. And this works fine. Setting it to an empty string ("") results in an exception of some unknown type, so don't think you can give it an empty string.

And here's the weird part. You'd think that setting the SecureSocketLayer option in the PrincipalContext would mean that you don't have to explicitly set it when you use VerifyCredentials. But I found that if I didn't set it in the VerifyCredentials part, the authentication would fail, but the queries (like in the example to the Groups) still takes place encrypted.

Maybe I just don't fully understand AD authentication and queries yet, but that seems like odd behavior to me.

回复收藏 0 原文