为什么不总是在 LDAP 搜索过滤器中使用 (objectClass=*)？答案

【问题标题】：Why not always use (objectClass=*) in the LDAP search filter?为什么不总是在 LDAP 搜索过滤器中使用 (objectClass=*)？
【发布时间】：2013-07-01 13:25:05
【问题描述】：

我为 Active Directory 中的搜索用户创建了以下过滤器：

(&(objectClass=*)(|(sAMAccountName=u)(userPrincipalName=u))

可以创建更多合格的过滤器：

(&(objectClass=person)(|(sAMAccountName=u)(userPrincipalName=u))

问题是为什么？

使用指定类person有什么好处？

同一目录是否可能包含objectClass 不是person 但以下为真(|(sAMAccountName=u)(userPrincipalName=u)) 的对象？

为什么不在 LDAP 搜索过滤器中始终使用 (objectClass=*)？

【问题讨论】：

为什么？每个对象都有一个objectClass。测试的意义何在？

标签： active-directory ldap ldap-query

【解决方案1】：

(objectClass=*) 是一个现有的过滤器，用于过滤掉没有填充objectClass 的对象...没有，因为所有 LDAP 对象都至少有一个结构对象类，因此第一个过滤器中的过滤器组件是不必要的甚至可能会减慢搜索速度，具体取决于服务器配置。

您问题中的第一个过滤器可能会导致服务器使用不必要的匹配规则进行比较。从性能的角度来看，第二个过滤器是一个更好的过滤器，假设已经在服务器上创建了 objectClass 相等的索引。

【讨论】：

感谢您的回答 (+1)。我们不仅要支持 Active Directory。我从您的回答和文章中得到以下信息，您将批准它：1）需要至少使用 (objectClass=*) 现有过滤器才能与所有 LDAP（例如 SUN LDAP）一起使用。 2) 带有(objectClass=*) present 过滤器的过滤器会为任何 LDAP（不仅是 Active Directory）返回正确的结果。 3) 使用(objectClass=person) 相等过滤器可以提高性能。
是的。但是，LDAP 客户端的编写不能偏向于服务器。 LDAP 客户端应该使用符合 LDAP 标准的代码来编写，并且应该像编码人员不知道使用哪个品牌的 LDAP 服务器一样编写它们。否则会导致脆弱、易碎的代码，当服务器供应商更改时可能必须更改这些代码 - 当供应商更改服务器响应 LDAP 请求的方式时。
或者代码应该尽可能地隔离任何依赖服务器的代码。

【解决方案2】：

这可能是通用 LDAP 服务的保留，原则上任何对象都可以共享具有相同值的相同属性，但属于不同的对象类。

但是，Active Directory 有一个限制，即 sAMAccountName 在域内，在所有对象类中必须是唯一的。并且只有 4 个对象类应该具有该属性？（我认为是用户、组、打印机和工作站）。

所以你很可能只是查询 (|(sAMAccountName=u)(userPrincipalName=u))

完全没有对象类过滤器。

【讨论】：