可能重复：
What's the difference in using distinguished name with cn or uid when logging into LDAP?
我正试图欺骗应用程序登录用户。我不是想破解任何东西，我们买了一个试图连接一些严格设置的应用程序。我正努力让它发挥作用。
基本上我必须定义搜索库：
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
但这不起作用。 ^
答案 0 :(得分：2)
您的陈述“事实证明，Novell eDirectory使用cn作为专有名称（而不是uid）。”本身并不正确。
默认情况下，它使用属性CN作为命名属性。您可以在eDirectory中创建其命名属性为uid =的对象，但它不是默认值。
您可以通过LDIF将每个人重命名为moddn to uid =当前的CN值。
我最初建议您将uid属性重新映射为LDAP Server属性映射中的CN值。但第二个想法我不确定这是否会有所帮助。
因为您的应用不是在搜索uid =某个值的用户，而是根据假设构建DN。
但你可以试试看它是否有帮助：
在LDAP服务器对象中，（您应该使用iManager进行此更改，不再更新和支持ConsoleOne管理单元），可以选择指定LDAP属性映射。
只需将eDirectory CN映射到LDAP uid即可。
另外，您是否知道如何在eDirectory服务器端使用DStrace来监视通过LDAP查询进入的事件？
（eDir serverIP：8008用于Netware，：8028，如果在Linux或Windows / nds上，然后跟踪配置，清除所有，启用LDAP）。
答案 1 :(得分：2)
答案是否定的。搜索请求需要以下参数：
服务器通过创建从base object开始并包括scope的候选条目列表来处理请求。如果subtree为base object，那么从属于scope的所有条目都可以成为候选者，如果one为base object，则只有条目才会立即从属于scope 1}}被视为候选人，否则base为base object且候选人仅为filter。过滤器用于过滤候选者，即只有true断言评估为@objectClassName的候选者才会返回到LDAP客户端。如果属性列表为空，则返回除操作属性之外的所有属性。如果属性列表包含"1.1"，则返回条目中存在的命名objectClass中所需或允许的所有属性。如果属性列表为"1.1"，则仅将条目的可分辨名称返回给LDAP客户端（"+"是一个没有属性可匹配的OID），如果属性列表为{{1} }，所有操作属性都返回给客户端，否则请求的属性将返回给LDAP客户端。 LDAP兼容服务器仅在名称明确请求时才返回操作属性。 time limit是服务器处理请求所花费的时间量的客户端请求的可选限制。 size limit是服务器应返回LDAP客户端的条目数的客户端请求的可选限制。客户端请求的参数不能覆盖服务器设置。 Controls是搜索请求中包含的可选数据。有关搜索请求的详细信息，请参阅“Using ldapsearch”。