LDAP筛选器中的Unicode Base64值

我正在尝试查找以下Active Directory用户：

memberOf::Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPXh4eCxEQz1pbnRlcm4=

（这个base64代表

CN=Domänen管理员，CN=Users，DC=xxx，DC=intern

）

直接搜索（通过API或ldapsearch）不会产生任何结果（因为它是unicode DN）：

以下过滤器也不起作用：

(memberof=Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPXh4eCxEQz1pbnRlcm4=)
(memberof=:Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPXh4eCxEQz1pbnRlcm4=)
(memberof=::Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPXh4eCxEQz1pbnRlcm4=)

除了在LDIF文件中指定base64编码的RFC之外，我找不到任何文档

更新上述ldapsearch命令仅为方便起见，它也不适用于LDAP API-使用：

ldap.search_s('dc=xxx,dc=intern', ldap.SCOPE_SUBTREE, filter, ['cn'])

带过滤器：

filter='(memberof=CN=Domänen-Benutzer,CN=Users,DC=xxx,DC=intern)'.encode('utf-8') # raw UTF
filter='(memberof=CN=Domänen-Benutzer,CN=Users,DC=xxx,DC=intern)'.encode('cp1252') # raw 1252
filter=b'(memberof=CN=Dom\\e4nen-Benutzer,CN=Users,DC=xxx,DC=intern)' # hex
filter=b'(memberof=CN=Dom\\xe4nen-Benutzer,CN=Users,DC=xxx,DC=intern)' # python repr

---

我还与Wireshark确认，过滤器确实是以UTF8传输的，为什么要尝试使用base64编码值？在LDAP筛选器中使用该值之前，必须先对其进行base64解码。在LDAP筛选器中使用时，它需要是值的字符串表示名称或字符串值的十六进制转义版本

---

编辑：从您的问题中翻译出一点群组名称后，我就更清楚您的问题是什么。默认的“域用户”组实际上是用户的主组。它不会显示在

成员的
列表中（因此搜索结果为空）。要检查用户是否是“域用户”的成员，必须检查用户的
primaryGroupId
值。在99%的情况下，这将始终是默认的“域用户”组。
为什么要尝试使用base64编码值？在LDAP筛选器中使用该值之前，必须先对其进行base64解码。在LDAP筛选器中使用时，它需要是值的字符串表示名称或字符串值的十六进制转义版本

编辑：从您的问题中翻译出一点群组名称后，我就更清楚您的问题是什么。默认的“域用户”组实际上是用户的主组。它不会显示在
成员的
列表中（因此搜索结果为空）。要检查用户是否是“域用户”的成员，必须检查用户的
primaryGroupId
值。在99%的情况下，这将始终是默认的“域用户”组。
属性类型
cn
具有符合标准的目录字符串语法。目录字符串使用UTF-8编码。说通过API进行搜索不会产生任何结果是不正确的。您只是使用了不正确的编码。
ldapsearch
工具（假设您使用的是OpenLDAP）可能不支持使用重音字符进行搜索

随附的
ldapsearch
实用程序很好地处理了这一问题。以下是我用于测试的LDIF：

dn:: Q049RG9tw4PCpG5lbi1BZG1pbnMsZGM9ZXhhbXBsZSxkYz1jb20=
objectclass: organizationalPerson
sn: person

dn: cn=mygroup,dc=example,dc=com
objectclass: groupofnames
member:: Q049RG9tw4PCpG5lbi1BZG1pbnMsZGM9ZXhhbXBsZSxkYz1jb20=

以下是我的命令行测试：

$ ldapsearch -b "dc=example,dc=com" "member=CN=Domänen-Admins,dc=example,dc=com"
dn: cn=mygroup,dc=example,dc=com
objectClass: top
objectClass: groupofnames
cn: mygroup
member:: Q049RG9tw4PCpG5lbi1BZG1pbnMsZGM9ZXhhbXBsZSxkYz1jb20=

此外，您可能需要阅读

更新

我设法使其与Active Directory（Windows Server 2012 R2，数据中心版）一起工作，并使用了未绑定数据存储附带的
ldapsearch
实用程序。这就是我所看到的：

$ ldapsearch --trustAll -Z -h <hostname> -p 636 -D "cn=administrator,cn=users,dc=dom-ad2,dc=local" -w <password> -b "cn=test,dc=dom-ad2,dc=local" "member=CN=Domänen-Benutzer,CN=test,DC=dom-ad2,DC=local"

dn: CN=mygroup,CN=test,DC=dom-ad2,DC=local
objectClass: top
objectClass: group
cn: mygroup
member:: Q049RG9tw4PCpG5lbi1CZW51dHplcixDTj10ZXN0LERDPWRvbS1hZDIsREM9bG9jYWw=
member: CN=Administrator,CN=Users,DC=dom-ad2,DC=local
distinguishedName: CN=mygroup,CN=test,DC=dom-ad2,DC=local
instanceType: 4
whenCreated: 20160514104531.0Z

根据标准，属性类型
cn
具有目录字符串语法。目录字符串使用UTF-8编码。说通过API进行搜索不会产生任何结果是不正确的。您只是使用了不正确的编码。
ldapsearch
工具（假设您使用的是OpenLDAP）可能不支持使用重音字符进行搜索

随附的
ldapsearch
实用程序很好地处理了这一问题。以下是我用于测试的LDIF：

dn:: Q049RG9tw4PCpG5lbi1BZG1pbnMsZGM9ZXhhbXBsZSxkYz1jb20=
objectclass: organizationalPerson
sn: person

dn: cn=mygroup,dc=example,dc=com
objectclass: groupofnames
member:: Q049RG9tw4PCpG5lbi1BZG1pbnMsZGM9ZXhhbXBsZSxkYz1jb20=

以下是我的命令行测试：

$ ldapsearch -b "dc=example,dc=com" "member=CN=Domänen-Admins,dc=example,dc=com"
dn: cn=mygroup,dc=example,dc=com
objectClass: top
objectClass: groupofnames
cn: mygroup
member:: Q049RG9tw4PCpG5lbi1BZG1pbnMsZGM9ZXhhbXBsZSxkYz1jb20=

此外，您可能需要阅读

更新

我设法使其与Active Directory（Windows Server 2012 R2，数据中心版）一起工作，并使用了未绑定数据存储附带的
ldapsearch
实用程序。这就是我所看到的：

$ ldapsearch --trustAll -Z -h <hostname> -p 636 -D "cn=administrator,cn=users,dc=dom-ad2,dc=local" -w <password> -b "cn=test,dc=dom-ad2,dc=local" "member=CN=Domänen-Benutzer,CN=test,DC=dom-ad2,DC=local"

dn: CN=mygroup,CN=test,DC=dom-ad2,DC=local
objectClass: top
objectClass: group
cn: mygroup
member:: Q049RG9tw4PCpG5lbi1CZW51dHplcixDTj10ZXN0LERDPWRvbS1hZDIsREM9bG9jYWw=
member: CN=Administrator,CN=Users,DC=dom-ad2,DC=local
distinguishedName: CN=mygroup,CN=test,DC=dom-ad2,DC=local
instanceType: 4
whenCreated: 20160514104531.0Z

事实证明，获取内置广告组的成员是不可能的（即
（isCriticalSystemObject=TRUE）
）
memberOf
对用户创建的组的查询工作正常，与使用的编码无关。不需要十六进制编码。
事实证明，只可能无法获取内置广告组的成员（即
（isCriticalSystemObject=TRUE）
）
memberOf
对用户创建的组的查询工作正常，与使用的编码无关。不需要十六进制编码。
请查看更新的问题。对于带有unicode字符的“普通”筛选器，AD不返回任何结果。Hex没有帮助。请查看更新的问题。对于带有unicode字符的“普通”筛选器，AD不返回任何结果。Hex没有帮助。请查看我的更新。它适用于我的另一个客户端。我已经尝试过了，它确实适用于
member=
过滤器。不幸的是，我需要的是
memberof=
，它不返回任何结果。但是我注意到，这只发生在系统组中，如“用户”和“域管理员”。用户创建的组处理MemberofJust fine！内置组不会显示在
memberOf
中。最好用另一种方法搜索（搜索用户组的成员属性）。我刚刚回答。使用这种特殊的过滤语法，它也可以搜索嵌套的组。也可以查看我的更新。它适用于我的另一个客户端。我已经尝试过了，它确实适用于
member=
过滤器。不幸的是，我需要的是
memberof=
，它不返回任何结果。但是我注意到，这只发生在系统组中，如“用户”和“域管理员”。用户创建的组处理MemberofJust fine！内置组不会显示在
memberOf
中。最好用另一种方法搜索（搜索用户组的成员属性）。我刚刚回答。使用这种特殊的过滤语法，它也会搜索嵌套的组。具体是什么内置组？请记住，像“域用户”这样的组实际上不是将显示在
memberOf
反向链接中的组。它真的出现了