我刚刚意识到objectClass将始终存在,因此将其设置为通配符应该填充search_filter以返回与基DN相关联的1项:ldap_conn.search(
search_base=my_dn,
search_filter= '(objectClass=*)', # required
search_scope=ldap3.BASE,
attributes='*'
)
然而,在ldap3中没有针对给定DN的连接执行查找操作的特殊情况,这似乎很愚蠢。在
编辑:@cannatag提到这是协议的一个限制,所以我决定检查RFC:(RFC 4511)。显然,ldapsearch和activedirectory模拟x.500样式的列表,或者通过设置objectClass状态过滤器进行读取:Note that an X.500 "list"-like operation can be emulated by the
client requesting a singleLevel Search operation with a filter
checking for the presence of the 'objectClass' attribute, and that an
X.500 "read"-like operation can be emulated by a baseObject Search
operation with the same filter. A server that provides a gateway to
X.500 is not required to use the Read or List operations, although it
may choose to do so, and if it does, it must provide the same
semantics as the X.500 Search operation.
博客围绕ldap3获取属性展开,提到将objectClass设为通配符可填充search_filter返回与基DN关联项。还指出ldap3中无针对给定DN连接执行查找操作的特殊情况,后经提示检查RFC,了解到ldapsearch和activedirectory模拟x.500样式的相关操作。
...&spm=1001.2101.3001.5002&articleId=111545124&d=1&t=3&u=24527a2ac1604b689d0871c71bc4fb77)
5953

被折叠的 条评论
为什么被折叠?



