Suchfiltersyntax

Mit Suchfiltern können Sie Suchkriterien definieren und effizientere und effektivere Suchvorgänge bereitstellen.

ADSI unterstützt die LDAP-Suchfilter, wie in RFC2254 definiert. Diese Suchfilter werden durch Unicode-Zeichenfolgen dargestellt. In der folgenden Tabelle sind einige Beispiele für LDAP-Suchfilter aufgeführt.

Suchfilter	BESCHREIBUNG
"(objectClass=*)"	Alle Objekte.
"(&(objectCategory=person)(objectClass=user)(!( cn=andy)))"	Alle Benutzerobjekte außer "andy".
"(sn=sm*)"	Alle Objekte mit einem Nachnamen, der mit "sm" beginnt.
"(&(objectCategory=person)(objectClass=contact)(|( sn=Smith)(sn=Johnson)))"	Alle Kontakte mit einem Nachnamen gleich "Smith" oder "Johnson".

 

Diese Suchfilter verwenden eines der folgenden Formate.

<filter>=(<attribute><operator><value>)

oder

<filter>=(<operator><filter1><filter2>)

Die ADSI-Suchfilter werden auf zwei Arten verwendet. Sie sind Teil des LDAP-Dialekts zum Übermitteln von Abfragen über den OLE DB-Anbieter. Sie werden auch mit der IDirectorySearch-Schnittstelle verwendet.

Operatoren

In der folgenden Tabelle sind häufig verwendete Suchfilteroperatoren aufgeführt.

Logischer Operator	BESCHREIBUNG
=	Gleich
~=	Ungefähr gleich
<=	Lexikografisch kleiner oder gleich
>=	Lexikografisch größer als oder gleich
&	UND
|	oder
!	NICHT

 

Zusätzlich zu den oben genannten Operatoren definiert LDAP zwei übereinstimmende Regelobjektbezeichner (OIDs), die verwendet werden können, um bitweise Vergleiche numerischer Werte durchzuführen. Übereinstimmende Regeln weisen die folgende Syntax auf.

<attribute name>:<matching rule OID>:=<value>

"<Attributname>" ist der lDAPDisplayName des Attributs, "<Rule OID>" ist die OID für die übereinstimmende Regel, und "<value>" ist der Wert, der für den Vergleich verwendet werden soll. Beachten Sie, dass in dieser Zeichenfolge keine Leerzeichen verwendet werden können. "<value>" muss eine Dezimalzahl sein. Er darf keine Hexadezimalzahl oder ein konstanter Name wie ADS_GROUP_TYPE_SECURITY_ENABLED sein. Weitere Informationen zu den verfügbaren Active Directory-Attributen finden Sie unter Alle Attribute.

In der folgenden Tabelle sind die übereinstimmenden Regel-OIDs aufgeführt, die von LDAP implementiert werden.

Übereinstimmende Regel-OID	Zeichenfolgenbezeichner (von Ntldap.h)	BESCHREIBUNG
1.2.840.113556.1.4.803	LDAP_MATCHING_RULE_BIT_AND	Eine Übereinstimmung wird nur gefunden, wenn alle Bits aus dem Attribut mit dem Wert übereinstimmen. Diese Regel entspricht einem bitweisen AND-Operator .
1.2.840.113556.1.4.804	LDAP_MATCHING_RULE_BIT_OR	Eine Übereinstimmung wird gefunden, wenn Bits aus dem Attribut mit dem Wert übereinstimmen. Diese Regel entspricht einem bitweisen OR-Operator .
1.2.840.113556.1.4.1941	LDAP_MATCHING_RULE_IN_CHAIN	Diese Regel ist auf Filter beschränkt, die für den DN gelten. Dies ist ein spezieller "erweiterter" Übereinstimmungsoperator, der die Kette der Herkunft in Objekten bis zum Stamm durchläuft, bis eine Übereinstimmung gefunden wird.

 

Die folgende Beispielabfragezeichenfolge sucht nach Gruppenobjekten, für die das ADS_GROUP_TYPE_SECURITY_ENABLED-Flag festgelegt ist. Beachten Sie, dass der Dezimalwert von ADS_GROUP_TYPE_SECURITY_ENABLED (0x80000000 = 2147483648) für den Vergleichswert verwendet wird.

(&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))

Die LDAP_MATCHING_RULE_IN_CHAIN ist eine übereinstimmende Regel-OID, die eine Methode zum Suchen der Herkunft eines Objekts bereitstellt. Viele Anwendungen, die AD und AD LDS verwenden, arbeiten in der Regel mit hierarchischen Daten, die nach beziehungen zwischen übergeordnetem und untergeordnetem Element sortiert werden. Zuvor haben Anwendungen eine transitive Gruppenerweiterung durchgeführt, um die Gruppenmitgliedschaft zu ermitteln, die zu viel Netzwerkbandbreite beanspruchte. Anwendungen mussten mehrere Roundtrips machen, um herauszufinden, ob ein Objekt "in die Kette" fiel, wenn ein Link bis zum Ende durchquert wird.

Ein Beispiel für eine solche Abfrage ist, um zu überprüfen, ob ein Benutzer "user1" ein Mitglied der Gruppe "group1" ist. Sie würden die Basis auf den Benutzer-DN (cn=user1, cn=users, dc=x) und den Bereich auf basefestlegen und die folgende Abfrage verwenden.

(memberof:1.2.840.113556.1.4.1941:=cn=Group1,OU=groupsOU,DC=x)

Um alle Gruppen zu finden, in denen "user1" Mitglied ist, legen Sie die Basis auf den Gruppencontainer-DN fest. beispielsweise (OU=groupsOU, dc=x) und den Bereich für subtree, und verwenden Sie den folgenden Filter.

(member:1.2.840.113556.1.4.1941:=cn=user1,cn=users,DC=x)

Beachten Sie, dass bei Verwendung von LDAP_MATCHING_RULE_IN_CHAIN der Bereich nicht eingeschränkt ist– er kann , one-leveloder subtreeseinbase. Einige solcher Abfragen für Unterstrukturen können prozessorintensiver sein, z. B. das Verfolgen von Links mit einem hohen Fan-Out; Das heißt, alle Gruppen aufzulisten, denen ein Benutzer angehört. Ineffiziente Suchvorgänge protokollieren entsprechende Ereignisprotokollmeldungen, wie bei jeder anderen Art von Abfrage.

Platzhalter

Sie können einem LDAP-Suchfilter auch Feldhalter und Bedingungen hinzufügen. Die folgenden Beispiele zeigen Teilzeichenfolgen, die zum Durchsuchen des Verzeichnisses verwendet werden können.

Alle Einträge abrufen:

(objectClass=*)

Rufen Sie Einträge ab, die "bob" irgendwo im allgemeinen Namen enthalten:

(cn=*bob*)

Rufen Sie Einträge mit einem allgemeinen Namen ab, der größer oder gleich "bob" ist:

(cn>='bob')

Rufen Sie alle Benutzer mit einem E-Mail-Attribut ab:

(&(objectClass=user)(email=*))

Rufen Sie alle Benutzereinträge mit einem E-Mail-Attribut und einem Nachnamen ab, der "smith" entspricht:

(&(sn=smith)(objectClass=user)(email=*))

Rufen Sie alle Benutzereinträge mit einem allgemeinen Namen ab, der mit "andy", "steve" oder "margaret" beginnt:

(&(objectClass=user)(| (cn=andy*)(cn=steve*)(cn=margaret*)))

Rufen Sie alle Einträge ohne E-Mail-Attribut ab:

(!(email=*))

Die formale Definition des Suchfilters lautet wie folgt (aus RFC 2254):

<filter> ::= '(' <filtercomp> ')'
<filtercomp> ::= <and> | <or> | <not> | <item>
<and> ::= '&' <filterlist>
<or> ::= '|' <filterlist>
<not> ::= '!' <filter>
<filterlist> ::= <filter> | <filter> <filterlist>
<item>::= <simple> | <present> | <substring>
<simple> ::= <attr> <filtertype> <value>
<filtertype> ::= <equal> | <approx> | <ge> | <le>
<equal> ::= '='
<approx> ::= '~='
<ge> ::= '>='
<le> ::= '<='
<present> ::= <attr> '=*'
<substring> ::= <attr> '=' <initial> <any> <final>
<initial> ::= NULL | <value><any> ::= '*' <starval>
<starval> ::= NULL | <value>'*' <starval>
<final> ::= NULL | <value>

Das Token <attr> ist eine Zeichenfolge, die einen AttributeType darstellt. Der Tokenwert <> ist eine Zeichenfolge, die ein AttributWert darstellt, dessen Format vom zugrunde liegenden Verzeichnisdienst definiert wird.

Wenn ein <Wert> das Sternchen (*), die linke Klammer (() oder die rechte Klammer ()) enthalten muss, sollte dem Zeichen das umgekehrte Escapezeichen (\) vorangestellt werden.

Sonderzeichen

Wenn eines der folgenden Sonderzeichen im Suchfilter als Literale angezeigt werden muss, müssen sie durch die aufgeführte Escapesequenz ersetzt werden.

ASCII-Zeichen	Escapesequenzersatz
*	\2a
(	\28
)	\29
\	\5c
NUL	\00
/	\2f

 

Hinweis

In Fällen, in denen ein MultiByte-Zeichensatz verwendet wird, müssen die oben aufgeführten Escapesequenzen verwendet werden, wenn die Suche von ADO mit dem SQL-Dialekt ausgeführt wird.

 

Darüber hinaus können beliebige Binärdaten mithilfe der Escapesequenzsyntax dargestellt werden, indem jedes Byte binärer Daten mit dem umgekehrten Schrägstrich (\) gefolgt von zwei hexadezimalen Ziffern codiert wird. Beispielsweise ist der Vier-Byte-Wert 0x00000004 als \00\00\00\04 in einer Filterzeichenfolge codiert.

Zugehörige Themen

LDAP-Dialekt

SQL-Dialekt

Suchen mit der IDirectorySearch-Schnittstelle

Suchen mit ActiveX-Datenobjekten

Suchen mit OLE DB