用于搜索的通用 LDAP 库？

发布于 2024-07-15 18:14:41 字数 498 浏览 9 评论 0原文

我正在编写一些 C++/Win32 代码来在 LDAP 目录中搜索用户（实际上我需要验证用户名/密码是否正确，然后验证组成员身份）。我有用户名，所以我希望类似下面的内容能够工作：

(&(objectCategory=person)(objectClass=user)(uid={username}))

当我使用此搜索/过滤器调用 ldap_search 时，我必须提供一个起始基（节点/OU/其他）来搜索。但我不知道从哪里开始搜索——我只有用户名。是否有办法指定与 OpenLDAP、Active Directory、Netscape LDAP 等一起使用的树的根？

另外，任何可以回答的人都可能对此有所帮助：uid 属性是否得到普遍支持，或者我是否需要根据我正在使用的 LDAP 服务器品牌来搜索不同的属性？（我看到有人需要搜索 uid、CN 甚至 SAMAccountName）。

原文

I'm writing some C++/Win32 code to search for a user in an LDAP directory (really I need to validate a username/password is correct, and then verify group membership). I have the username, so I'm hoping something like the following will work:

(&(objectCategory=person)(objectClass=user)(uid={username}))

When I call ldap_search with this search/filter, I have to provide a starting base (node/OU/whatever) to search. But I don't know where to start the search -- all I have is the username. Is there anyway to specify the root of the tree that will work with OpenLDAP, Active Directory, Netscape LDAP, etc, etc?

Also, anyone that can answer that could probably help with this: Is the uid attribute universally supported, or do I need to search on a different attribute depending on what brand of LDAP server I'm talking to? (I've seen references to people needing to search on uid, CN and even SAMAccountName).

分享到QQ

分享到微博

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

发布评论

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

攀登最高峰 2024-07-22 18:14:41

关于一般检索搜索库的第一个问题：

每个 LDAP 目录服务器（我认为符合 LDAP 协议）都会在名为 RootDSE 的节点下公开一些操作事物。您可以通过RootDSE检索的内容之一是namingContexts，它本质上可以告诉您此服务器上托管的不同树。

因此，您可以检索用户名搜索的顶级搜索库。 请注意：某些 LDAP（例如 OpenLDAP）服务器可以托管多个树，因此当找到多个命名上下文时，您必须想出一个解决方案。

RootDSE 可以是通过向服务器查询 DN“”（空字符串）并指定您想要获取所有操作属性来检索。只是 OpenLDAP 服务器的一些示例：

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +
# note the + returns operational attributes

这应该返回类似于下面所示的内容（来自 OpenLDAP 2.4.8） - 括号中的值被添加解释，并且不会由服务器返回：（

dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=example,dc=com
namingContexts: dc=example,dc=net
monitorContext: cn=Monitor
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 (Contentsync RFC 4530)
[...]
supportedExtension: 1.3.6.1.4.1.4203.1.11.1 (ModifyPassword RFC3088)
[...]
supportedFeatures: 1.3.6.1.1.14 (Modify-Increment RFC4525)
[...]
supportedLDAPVersion: 3
supportedSASLMechanisms: NTLM
[...]
entryDN:
subschemaSubentry: cn=Subschema

来自 http://www.zytrax.com/books/ldap/ch3/#operational）

关于关于 uid 属性可用性的第二个问题：

我认为您不应该依赖这个属性，因为它强烈依赖于用于存储用户数据的架构（尽管大多数用户-我认为 schema-classes 将有一个 uid 属性）。但这取决于您想要在程序中加入的灵活性。也许最好的方法是让最终用户配置用户过滤器字符串（您甚至可以使用搜索库来执行此操作，这将具有一些性能优势（当用户仅位于一个小子树，不需要查询 RootDSE））。

Regarding your first question about generically retrieving a search base:

Every LDAP directory server (conforming to the LDAP protocol I think) exposes some operational thingies under a node called RootDSE. One of the things you can retrieve through RootDSE are the namingContexts which essentially can tell you what the different trees are hosted on this server.

So you can retrieve a top-level search base for your username-search. Please be aware: some LDAP (OpenLDAP for example) servers can host multiple trees so you have to come up with a solution when multiple naming contexts are found.

The RootDSE can be retrieved by querying the server for the DN "" (empty string) and specifiyng that you want to get all the operational attributes as well. Just some example for an OpenLDAP server:

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +
# note the + returns operational attributes

This should return something similar to that shown below (from OpenLDAP 2.4.8) - the values in parentheses are added explanations and are not returned by the server:

dn:
structuralObjectClass: OpenLDAProotDSE
configContext: cn=config
namingContexts: dc=example,dc=com
namingContexts: dc=example,dc=net
monitorContext: cn=Monitor
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 (Contentsync RFC 4530)
[...]
supportedExtension: 1.3.6.1.4.1.4203.1.11.1 (ModifyPassword RFC3088)
[...]
supportedFeatures: 1.3.6.1.1.14 (Modify-Increment RFC4525)
[...]
supportedLDAPVersion: 3
supportedSASLMechanisms: NTLM
[...]
entryDN:
subschemaSubentry: cn=Subschema

(from http://www.zytrax.com/books/ldap/ch3/#operational)

Regarding your second question about the availability of the uid attribute:

I don't think that you should rely on this one as it strongly depends on the schema used for storing user data (although most user-schema-classes will have a uid attribute I think). But that depends on the flexibility you want to put into your program. Perhaps the best way would be to make the user-filter-string configurable by the end-user (you could even do this with the search base which would have some performance advantages (no need to search the whole tree when users are only located in a small subtree and no need to query the RootDSE)).

回复收藏 0 原文

地狱即天堂 2024-07-22 18:14:41

我不会依赖 uid 作为 LDAP 中用户条目的正确搜索属性。许多公司只保证employeeID 在LDAP DIT 中是唯一的。

回复收藏 0 原文

不奢求什么 2024-07-22 18:14:41

您需要定义开始搜索的容器。因此，这类似于

"LDAP://" + _ADSPath + ":" + _ADSPort + "/" + _ADSRootContainer

其中 _ADSPath 是服务器主机名/ip； _ADSPort为端口号（一般默认为389）； _ADSRootContainer 是容器路径的其余部分（例如 ou=Users.
该路径取决于您正在搜索的实现。您可以启动高于容纳用户的容器并在搜索对象上设置参数以使用多级搜索。但速度会慢很多。

You need to define what container to start searching in. So this would be something like

"LDAP://" + _ADSPath + ":" + _ADSPort + "/" + _ADSRootContainer

where _ADSPath is the server hostname/ip; _ADSPort is the port number (usually 389 by default); and _ADSRootContainer is the rest of the path to the container (like ou=Users.
The path would depend on the implementation you are searching against. You can start up higher than the container holding the users and set the parameters on the search object to use a multi-level search. But it will be much slower.

回复收藏 0 原文

~没有更多了~