无法在 SearchRequest 中查询没有专有名称的 AD?

发布于 2024-11-18 18:21:23 字数 201 浏览 4 评论 0原文

我正在运行测试 Active Directory,并尝试使用 ldap 进行查询。我创建了一个可分辨名称为空的 searchrequest 对象和一个过滤器,该过滤器抛出 noSuchObject 错误代码并显示“对象不存在”消息。我只是从我的测试 AD 中得到这个,如果我使用我公司的生产 AD 我不会得到异常,只是没有命中的响应。我需要在测试 AD 中更改哪些内容才能看到类似的行为?

I am running a test Active directory and am trying to query with ldap. I created a searchrequest object with distingueshed name empty and a filter this is throwing noSuchObject error code with "object does not exist" message. I am only getting this from my test AD , if I use my company's production AD I am not getting exception, just a response with no hit. What do I need to change in my test AD to see similar behaviour ?

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

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

发布评论

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

评论(3

聆听风音 2024-11-25 18:21:23

您可以使用 PrincipalSearcher 和“按示例查询”主体进行搜索:

// create your domain context
PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

// define a "query-by-example" principal - here, we search for a UserPrincipal 
// and with specified last name (surname)
UserPrincipal qbeUser = new UserPrincipal(ctx);
qbeUser.Surname = "Willis";

// create your principal searcher passing in the QBE principal    
PrincipalSearcher srch = new PrincipalSearcher(qbeUser);

// find all matches
foreach(var found in srch.FindAll())
{
    // do whatever here - "found" is of type "Principal" - it could be user, group, computer.....          
}

如果您还没有 - 请务必阅读 MSDN 文章 管理 .NET Framework 3.5 中的目录安全主体 很好地展示了如何充分利用新功能

当然,根据您的需要,您可能希望在您创建的“按示例查询”用户主体上指定其他属性:

  • Surname (或姓氏)
  • DisplayName(通常:名字 + 空格 + 姓氏)
  • SAM 帐户名称 - 您的 Windows/AD 帐户名称
  • 用户主体名称 - 你的“[email protected]" 样式名称

您可以指定UserPrincipal 并将它们用作 PrincipalSearcher 的“示例查询”。

You can use a PrincipalSearcher and a "query-by-example" principal to do your searching:

// create your domain context
PrincipalContext ctx = new PrincipalContext(ContextType.Domain);

// define a "query-by-example" principal - here, we search for a UserPrincipal 
// and with specified last name (surname)
UserPrincipal qbeUser = new UserPrincipal(ctx);
qbeUser.Surname = "Willis";

// create your principal searcher passing in the QBE principal    
PrincipalSearcher srch = new PrincipalSearcher(qbeUser);

// find all matches
foreach(var found in srch.FindAll())
{
    // do whatever here - "found" is of type "Principal" - it could be user, group, computer.....          
}

If you haven't already - absolutely read the MSDN article Managing Directory Security Principals in the .NET Framework 3.5 which shows nicely how to make the best use of the new features in System.DirectoryServices.AccountManagement

Of course, depending on your need, you might want to specify other properties on that "query-by-example" user principal you create:

  • Surname (or last name)
  • DisplayName (typically: first name + space + last name)
  • SAM Account Name - your Windows/AD account name
  • User Principal Name - your "[email protected]" style name

You can specify any of the properties on the UserPrincipal and use those as "query-by-example" for your PrincipalSearcher.

沙与沫 2024-11-25 18:21:23

@marc_s 的回答是为您提供一种搜索方式

回到您的问题,回想一下:

LDAP 搜索是

  1. 您要求开始搜索的点头(在您的情况下是 OU 的 DN)
  2. 您的搜索范围(基本) ,onelevel,子树)
  3. 您的搜索过滤器((objectClass = group))
  4. 您想要检索的属性

在您的情况下,当您的ADSI层能够找到默认域时,它就可以工作。因此,我认为您必须创建一个真正的 LDAP-SEARCH 请求,也许还需要提供凭据。

@marc_s answered by giving you a way of searching

Back to your question, just a recall :

A LDAP search is

  1. The nod from which you ask to begin the search (in your case the DN of your OU)
  2. The scope of your search (base, onelevel, subtree)
  3. The filter of your search ((objectClass=group))
  4. The attributes you want to retreive

In you case it works when your ADSI layer is able to find a default Domain. So I think that you have to create a real LDAP-SEARCH request en perhaps also give credentials.

少女情怀诗 2024-11-25 18:21:23

感谢其他答案。我通过在连接中使用 GC 端口 3268 而不是 DC 端口 389 解决了我的问题。

Thanks for the other answers. I solved my problem by using GC port 3268 instead of DC port 389 in the connection.

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