2016-05-13 11 views
1

Ich versuche, Active Directory-Benutzer zu finden, sind:Unicode Base64-Werte in einem LDAP-Filter

memberOf:: Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPWVsZW1lbnRzLERDPWludGVybg= 

=

(diese base64 steht für CN=Domänen-Admins,CN=Users,DC=elements,DC=intern)

für sie suche direkt (via API oder ldapsearch) ergibt kein Ergebnis (da es eine Unicode-DN) ist:

ldapsearch -h ... -D [email protected] -x -w '...' -b dc=elements,dc=intern '(memberof=CN=Domänen-Benutzer,CN=Users,DC=elements,DC=intern)' 

Nach Filter funktionieren nicht entweder:

(memberof=Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPWVsZW1lbnRzLERDPWludGVybg=) 
(memberof=:Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPWVsZW1lbnRzLERDPWludGVybg=) 
(memberof=::Q049RG9tw6RuZW4tQWRtaW5zLENOPVVzZXJzLERDPWVsZW1lbnRzLERDPWludGVybg=) 

Ich kann keine Dokumentation finden, außer für RFC Angabe Base64-Codierung in LDIF-Dateien.

UPDATE die oben ldapsearch-Befehle nur für Bequemlichkeit, es doesn‘arbeitet mit LDAP-API entweder - mit:

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

mit Filter:

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

Ich habe auch mit bestätigter Wireshark, dass der Filter tatsächlich in UTF8 übertragen wird

Antwort

1

Warum versuchen Sie, den Base64-codierten Wert zu verwenden? Sie müssen base64 den Wert dekodieren, bevor Sie ihn in einem LDAP-Filter verwenden. Es muss entweder der Zeichenfolgendarstellungsname des Werts oder eine hexadezimierte Version des Zeichenfolgenwerts sein, wenn es in einem LDAP-Filter verwendet wird.

Bearbeiten: Nach der Übersetzung der Gruppennamen ein wenig von Ihrer Frage wurde mir mehr offensichtlich, was Ihr Problem tatsächlich ist. Die Standardgruppe "Domänenbenutzer" ist eigentlich eine primäre Gruppe für einen Benutzer. Es wird nicht in der memberOf Liste angezeigt (daher die leeren Ergebnisse bei einer Suche). Um zu überprüfen, ob ein Benutzer Mitglied von "Domain Users" ist, müssen Sie den Wert primaryGroupId für einen Benutzer überprüfen. In 99% aller Fälle wird dies immer die Standardgruppe "Domain Users" sein.

+0

Bitte beachten Sie die aktualisierte Frage. AD gibt keine Ergebnisse für einen "normalen" Filter mit Unicode-Zeichen zurück. Hex hilft nicht. –

2

Der Attributtyp cn hat eine Directory String-Syntax gemäß dem Standard. Verzeichniszeichenfolgen werden mit UTF-8 codiert. Die Suche über die API führt zu keinen falschen Ergebnissen. Sie verwenden nur die falsche Codierung. Das Tool ldapsearch (vorausgesetzt, Sie verwenden OpenLDAP) unterstützt möglicherweise keine Suche mit Akzentzeichen.

Das ldapsearch Dienstprogramm, das mit der UnboundID Data Store geliefert wird, handhabt das ziemlich gut. Hier ist die LDIF, die ich für den Test verwendet:

dn:: Q049RG9tw4PCpG5lbi1BZG1pbnMsZGM9ZXhhbXBsZSxkYz1jb20= 
objectclass: organizationalPerson 
sn: person 

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

Hier ist meine Befehlszeile Test:

$ 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= 

Auch Sie können die Directory String syntax from RFC 4517 lesen möchten.

UPDATE

ich es geschafft, dies mit dem UnboundID Data Store ausgeliefert Active Directory (Windows Server 2012 R2 Datacenter Edition) und mit dem ldapsearch Dienstprogramm arbeiten zu machen.Das ist, was ich sehe:

$ 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 

Sie auch die LDAPSearch Beispiel-Klasse aus dem UnboundID LDAP SDK (jar herunterladen link) dies zu tun verwenden kann. Hier die entsprechenden Befehlszeile ich mit dem LDAP-SDK verwendet:

$ java -cp unboundid-ldapsdk-3.1.1.jar com.unboundid.ldap.sdk.examples.LDAPSearch --trustAll -Z -h <host> -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" 
+0

Siehe auch meine Updates. Es funktioniert für mich mit einem anderen Kunden. –

+0

Ich habe das versucht und es funktioniert tatsächlich mit dem '' member = '' Filter. Leider brauche ich '' memberof = '' und es gibt keine Ergebnisse zurück. –

+0

Ich habe jedoch festgestellt, dass dies nur für die Systemgruppen wie "Benutzer" und "Domain-Administratoren" passiert. Vom Benutzer erstellte Gruppen handhaben memberOf ganz gut! –

1

Es stellte sich heraus, dass es nur unmöglich ist, Mitglieder für eingebauten AD-Gruppen (d (isCriticalSystemObject=TRUE)) zu holen. memberOf Abfragen für vom Benutzer erstellte Gruppen funktionieren problemlos, unabhängig von der verwendeten Codierung. Es war keine Hex-Codierung erforderlich.

+0

Speziell was verbaute Gruppen? Denken Sie daran, dass eine Gruppe wie "Domain Users" nicht wirklich eine Gruppe ist, die im "memberOf" Backlink angezeigt wird. Es wird tatsächlich im 'primaryGroupId'-Attribut angezeigt (und in einem Formular, das Sie dekodieren/analysieren müssen, da Sie wirklich nur die RID der Gruppe erhalten, nicht den Namen). – ChadSikorra