LDAP 连接中的通配符

发布于 12-10 22:22 字数 725 浏览 1 评论 0原文

可能的重复:
有什么区别登录 LDAP 时使用带有 cn 或 uid 的专有名称?

我试图欺骗应用程序登录用户。我并不是想破解任何东西,我们购买了一个尝试连接一些严格设置的应用程序。我正在努力让它发挥作用。

基本上我必须定义搜索库:

  ou=employees,ou=Main,o=mycompany

如果我尝试以 johnsmith 身份登录,它会将用户名作为 uid 预先添加到搜索库中,如下

  uid=johnsmith,ou=employees,ou=Main,o=mycompany

所示:事实证明,Novell eDirectory 使用 cn 作为可分辨名称(而不是uid )。

有什么方法可以使用通配符欺骗应用程序吗?我希望这样的事情可能会起作用:

  uid=*,cn=johnsmith,ou=employees,ou=Main,o=mycompany 

但这不起作用。 ^

Possible Duplicate:
What's the difference in using distinguished name with cn or uid when logging into LDAP?

I'm trying to trick an application into logging in a user. I'm not trying to hack anything, we bought an application that tries to connect with some rigid settings. I'm trying to make it work.

Basically I have to define the Search Base:

  ou=employees,ou=Main,o=mycompany

And if I try to log in as johnsmith, it pre-prends the username as uid to the search base like this :

  uid=johnsmith,ou=employees,ou=Main,o=mycompany

Well it turns out that the Novell eDirectory uses cn as the distinguished name ( not uid ).

Is there any way I can trick the application using wildcards? I was hoping something like this might work :

  uid=*,cn=johnsmith,ou=employees,ou=Main,o=mycompany 

but this does not work. ^

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

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

发布评论

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

评论(2

夏尔2024-12-17 22:22:56

答案是否定的。搜索请求需要以下参数:

  • 基本对象
  • 范围(子树、一或基本)
  • 过滤器
  • 要检索的属性列表(可选)
  • 时间限制(可选)
  • 大小限制(可选)
  • 控件(可选)
  • 仅类型(可选)

服务器处理通过创建从基础对象开始并包含该基础对象的候选条目列表来响应请求。如果范围子树,则从属于基础对象的所有条目都可以是候选者,如果范围是< code>one,只有直接从属于基对象的条目才被视为候选,否则范围base并且候选是仅基础对象。过滤器用于过滤掉候选者,即只有 filter 断言评估为 true 的候选者才会返回到 LDAP 客户端。如果属性列表为空,则返回除操作属性之外的所有属性。如果属性列表包含@objectClassName,则返回条目中存在的指定 objectClass 中必需或允许的所有属性。如果属性列表为"1.1",则仅将条目的专有名称返回给 LDAP 客户端("1.1" 是任何属性都无法匹配的 OID),如果属性列表是"+",则所有操作属性都将返回到客户端,否则请求的属性将返回到 LDAP 客户端。仅当按名称明确请求时,符合 LDAP 的服务器才返回操作属性。 时间限制是一个可选的、客户端请求的对服务器处理请求的时间的限制。 大小限制是一个可选的、客户端请求的限制,用于限制服务器返回 LDAP 客户端所需的条目数。客户端请求的参数不能覆盖服务器设置。 控件是搜索请求中包含的可选数据片段。有关搜索请求的详细信息,请参阅“使用 ldapsearch”。

The answer is no. A search request requires the following parameters:

  • base object
  • scope (subtree, one, or base)
  • filter
  • list of attributes to retrieve (optional)
  • time limit (optional)
  • size limit (optional)
  • controls (optional)
  • types only (optional)

The server processes the request by creating a list of candidate entries starting at and including the base object. If the scope is subtree, all entries subordinate to the base object can be candidates, if the scope is one, only entries immediately subordinate to the base object are considered candidates, otherwise the scope is base and the candidate is the base object only. The filter is used to filter out candidates, that is, only candidates wherein the filter assertions evaluate to true are returned to the LDAP client. If the list of attributes is empty, all attributes except operational attributes are returned. If the list of attributes contains @objectClassName, then all attributes that are required or allowed in the named objectClass that are present in the entry are returned. If the list of attributes is "1.1" only the distinguished name of the entry is returned to the LDAP client ("1.1" is an OID that no attribute can match), if the list of attributes is "+", all operational attributes are returned to the client otherwise the attributes requested are returned to the LDAP client. LDAP-compliant servers return operational attributes only when explicitly requested by name. The time limit is an optional, client-requested limit on the amount of time the server should spend processing the request. The size limit is an optional, client-requested limit on the number of entries the server should spend return to the LDAP client. Client-requested parameters cannot override server settings. Controls are optional pieces of data included with a search request. For more information about search requests, see "Using ldapsearch".

妄断弥空2024-12-17 22:22:56

您的陈述“事实证明 Novell eDirectory 使用 cn 作为专有名称(而不是 uid )。”本身是不正确的。

默认情况下,它使用属性 CN 作为命名属性。您可以在 eDirectory 中创建命名属性为 uid= 的对象,但这不是默认值。

您可以通过 LDIF 将每个人的 modrdn 重命名为 uid= 他们当前的 CN 值。

我最初建议您将 uid 属性重新映射为 LDAP 服务器属性映射中的 CN 值。但转念一想,我不确定这是否有帮助。

因为您的应用程序并不是在搜索 uid=某个值的用户,而是基于假设构建 DN。

但您可以尝试看看它是否有帮助:

在您的 LDAP 服务器对象中(您应该使用 iManager 进行此更改,ConsoleOne 管理单元不再更新和支持)有一个用于指定 LDAP 属性映射的选项。

只需将 eDirectory CN 映射到 LDAP uid。

另外,您知道如何在 eDirectory 服务器端使用 DStrace 来监视通过 LDAP 查询传入的事件吗?

(对于 Netware,eDir 服务器 IP:8008,如果在 Linux 或 Windows/nds 上,则为:8028,然后跟踪配置,清除所有内容,启用 LDAP)。

Your statement that 'Well it turns out that the Novell eDirectory uses cn as the distinguished name ( not uid ).' is not per se correct.

By default it uses the attribute CN as the naming attribute. You can make objects whose naming attribute is uid= in eDirectory but it is not the default.

You could rename everybody via LDIF with a modrdn to uid= their current CN value.

I initially was going to suggest you remap the uid attribute to be the CN value in the LDAP Server attribute mapping. But on second thought I am not sure if that will help.

Because your app is not searching for a user whose uid= some value, rather it is building a DN based on an assumption.

But you could try and see if it helps:

In your LDAP Server object, (you should use iManager to make this change, the ConsoleOne snapins are no longer updated and supported) there is an option to specify LDAP Attribute mappings.

Just map eDirectory CN to LDAP uid.

Also, do you know how to use DStrace on the eDirectory server side to watch events as they come in via LDAP queries?

(eDir serverIP:8008 for Netware, :8028 if on Linux or Windows/nds and then trace config, clear all, enable LDAP).

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