Suchfiltersyntax

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

ADSI unterstützt die LDAP-Suchfilter gemäß der Definition in RFC2254. 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, aber "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 entsprechen "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 bilden einen Teil des LDAP-Dialekts zum Übermitteln von Abfragen über den OLE DB-Anbieter. Sie werden auch mit der IDirectorySearch Schnittstelle verwendet.

Betriebspersonal

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

Logischer Operator	Beschreibung
=	Gleich
~=	Ungefähr gleich
<=	Lexikalisch kleiner oder gleich
>=	Lexikalisch 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 die lDAPDisplayName des Attributs, "<Regel OID>" ist das OID für die übereinstimmende Regel, und "<Wert>" ist der Wert, der für den Vergleich verwendet werden soll. Beachten Sie, dass Leerzeichen in dieser Zeichenfolge nicht verwendet werden können. "<Wert>" muss eine Dezimalzahl sein; es kann keine hexadezimale Zahl oder ein Konstantenname wie ADS_GROUP_TYPE_SECURITY_ENABLEDsein. 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 UND 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 ODER 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 zur Wurzel durchläuft, bis eine Übereinstimmung gefunden wird.

 

Im folgenden Beispiel sucht die Abfragezeichenfolge nach Gruppenobjekten, für die das attribut ADS_GROUP_TYPE_SECURITY_ENABLED 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 Nachschlagen der Herkunft eines Objekts bereitstellt. Viele Anwendungen, die AD und AD LDS verwenden, arbeiten in der Regel mit hierarchischen Daten, die nach Beziehungen zwischen übergeordneten und untergeordneten Elementen sortiert werden. Bisher haben Anwendungen transitive Gruppenerweiterungen durchgeführt, um die Gruppenmitgliedschaft zu ermitteln, die zu viel Netzwerkbandbreite verwendet hat; Anwendungen, die mehrere Roundtrips durchführen müssen, um herauszufinden, ob ein Objekt "in der Kette" fällt, wenn eine Verbindung bis zum Ende durchquert wird.

Ein Beispiel für eine solche Abfrage ist eine, die überprüft, ob ein Benutzer "user1" mitglied der Gruppe "group1" ist. Sie würden die Basis auf den DN-(cn=user1, cn=users, dc=x) des Benutzers 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, bei denen "user1" Mitglied ist, legen Sie die Basis auf den Gruppencontainer DN fest; Beispielsweise (OU=groupsOU, dc=x) und der Bereich zum subtreeund verwenden Sie den folgenden Filter.

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

Beachten Sie, dass der Bereich bei Verwendung von LDAP_MATCHING_RULE_IN_CHAINnicht beschränkt ist – es kann base, one-leveloder subtreesein. Einige solche Abfragen zu Unterstrukturen können prozessorintensiver sein, z. B. das Verjagt von Links mit einem hohen Fanout; d. h. alle Gruppen auflisten, in denen ein Benutzer Mitglied ist. Ineffiziente Suchvorgänge protokollieren entsprechende Ereignisprotokollmeldungen wie bei jedem anderen Abfragetyp.

Wildcards

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

Abrufen aller Einträge:

(objectClass=*)

Abrufen von Einträgen, die "bob" an einer beliebigen Stelle im allgemeinen Namen enthalten:

(cn=*bob*)

Abrufen von Einträgen mit einem gemeinsamen Namen größer oder gleich "bob":

(cn>='bob')

Abrufen aller Benutzer mit einem E-Mail-Attribut:

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

Abrufen aller Benutzereinträge mit einem E-Mail-Attribut und einem Nachnamen gleich "smith":

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

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

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

Abrufen aller Einträge ohne E-Mail-Attribut:

(!(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 Attributtyp darstellt. Das Token <Werts> ist eine Zeichenfolge, die einen Attributwert darstellt, dessen Format vom zugrunde liegenden Verzeichnisdienst definiert ist.

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

Sonderzeichen

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

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

 

Anmerkung

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äre Daten mithilfe der Escapesequenzsyntax dargestellt werden, indem jedes Byte von Binären Daten mit dem umgekehrten Schrägstrich (\) gefolgt von zwei hexadezimalen Ziffern codiert wird. Der Vier-Byte-Wert 0x00000004 beispielsweise als \00\00\00\00\04 in einer Filterzeichenfolge codiert ist.

Verwandte Themen

LDAP-Dialekt-

SQL-Dialekt-

Suchen mit der IDirectorySearch-Schnittstelle

Suche mit ActiveX-Datenobjekten

Suchen mit OLE DB-