Partager via


Syntaxe du filtre de recherche

Les filtres de recherche vous permettent de définir des critères de recherche et de fournir des recherches plus efficaces et plus efficaces.

ADSI prend en charge les filtres de recherche LDAP tels que définis dans RFC2254. Ces filtres de recherche sont représentés par des chaînes Unicode. Le tableau suivant répertorie quelques exemples de filtres de recherche LDAP.

Filtre de recherche Description
« (objectClass=*) » Tous les objets.
« (&objectCategory=person)(objectClass=user)(!( cn=andy))) » Tous les objets utilisateur, sauf « andy ».
« (sn=sm*) » Tous les objets dont le nom commence par « sm ».
« (&objectCategory=person)(objectClass=contact)(|( sn=Smith)(sn=Johnson))) » Tous les contacts avec un nom de famille égal à « Smith » ou « Johnson ».

 

Ces filtres de recherche utilisent l’un des formats suivants.

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

or

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

Les filtres de recherche ADSI sont utilisés de deux façons. Ils font partie du dialecte LDAP pour l’envoi de requêtes via le fournisseur OLE DB. Ils sont également utilisés avec l’interface IDirectorySearch .

Opérateurs

Le tableau suivant répertorie les opérateurs de filtre de recherche fréquemment utilisés.

Opérateur logique Description
= Égal à
~= Approximativement égal à
<= Lexicographiquement inférieur ou égal à
>= Lexicographiquement supérieur ou égal à
& AND
| OR
! NOT

 

En plus des opérateurs ci-dessus, LDAP définit deux identificateurs d’objets de règle correspondants qui peuvent être utilisés pour effectuer des comparaisons au niveau du bit des valeurs numériques. Les règles de correspondance ont la syntaxe suivante.

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

«< nom de l’attribut> » est le lDAPDisplayName de l’attribut, «< rule OID> » est l’OID de la règle correspondante et «< value> » est la valeur à utiliser pour la comparaison. N’oubliez pas que les espaces ne peuvent pas être utilisés dans cette chaîne. « <value> » doit être un nombre décimal ; il ne peut pas s’agir d’un nombre hexadécimal ou d’un nom constant tel que ADS_GROUP_TYPE_SECURITY_ENABLED. Pour plus d’informations sur les attributs Active Directory disponibles, consultez Tous les attributs.

Le tableau suivant répertorie les OID de règle correspondantes implémentés par LDAP.

OID de règle de correspondance Identificateur de chaîne (à partir de Ntldap.h) Description
1.2.840.113556.1.4.803 LDAP_MATCHING_RULE_BIT_AND Une correspondance est trouvée uniquement si tous les bits de l’attribut correspondent à la valeur. Cette règle équivaut à un opérateur AND au niveau du bit.
1.2.840.113556.1.4.804 LDAP_MATCHING_RULE_BIT_OR Une correspondance est trouvée si des bits de l’attribut correspondent à la valeur. Cette règle équivaut à un opérateur OR au niveau du bit.
1.2.840.113556.1.4.1941 LDAP_MATCHING_RULE_IN_CHAIN Cette règle est limitée aux filtres qui s’appliquent au nom de domaine. Il s’agit d’un opérateur de correspondance « étendu » spécial qui guide la chaîne d’ancêtres dans les objets jusqu’à la racine jusqu’à ce qu’il trouve une correspondance.

 

L’exemple de chaîne de requête suivant recherche des objets de groupe dont l’indicateur ADS_GROUP_TYPE_SECURITY_ENABLED est défini. N’oubliez pas que la valeur décimale de ADS_GROUP_TYPE_SECURITY_ENABLED (0x80000000 = 2147483648) est utilisée pour la valeur de comparaison.

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

Le LDAP_MATCHING_RULE_IN_CHAIN est un OID de règle de correspondance conçu pour fournir une méthode permettant de rechercher l’origine d’un objet. De nombreuses applications utilisant AD et AD LDS fonctionnent généralement avec des données hiérarchiques, qui sont ordonnées en fonction des relations parent-enfant. Auparavant, les applications effectuaient une expansion de groupe transitive pour déterminer l’appartenance au groupe, qui utilisait trop de bande passante réseau ; les applications devaient effectuer plusieurs allers-retours pour déterminer si un objet est tombé « dans la chaîne » si un lien est parcouru jusqu’à la fin.

Un exemple d’une telle requête est conçu pour case activée si un utilisateur « user1 » est membre du groupe « group1 ». Vous devez définir la base sur le nom de l’utilisateur (cn=user1, cn=users, dc=x) et l’étendue sur base, et utiliser la requête suivante.

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

De même, pour rechercher tous les groupes dont « user1 » est membre, définissez la base sur le nom de domaine du conteneur de groupes ; par exemple (OU=groupsOU, dc=x) et l’étendue de subtree, et utilisez le filtre suivant.

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

Notez que lors de l’utilisation de LDAP_MATCHING_RULE_IN_CHAIN, l’étendue n’est pas limitée: elle peut être base, one-levelou subtree. Certaines requêtes de ce type sur les sous-arborescences peuvent être plus gourmandes en processeur, telles que la recherche de liens avec un ventilateur élevé ; c’est-à-dire la liste de tous les groupes dont un utilisateur est membre. Les recherches inefficaces consignent les messages de journal des événements appropriés, comme avec tout autre type de requête.

Caractères génériques

Vous pouvez également ajouter des caractères génériques et des conditions à un filtre de recherche LDAP. Les exemples suivants montrent des sous-chaînes qui peuvent être utilisées pour effectuer une recherche dans le répertoire.

Obtenir toutes les entrées :

(objectClass=*)

Obtenez des entrées contenant « bob » quelque part dans le nom commun :

(cn=*bob*)

Obtenez des entrées dont le nom commun est supérieur ou égal à « bob » :

(cn>='bob')

Obtenez tous les utilisateurs avec un attribut d’e-mail :

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

Obtenez toutes les entrées utilisateur avec un attribut d’e-mail et un nom égal à « smith » :

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

Obtenez toutes les entrées utilisateur avec un nom commun qui commence par « andy », « steve » ou « margaret » :

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

Obtenez toutes les entrées sans attribut d’e-mail :

(!(email=*))

La définition formelle du filtre de recherche est la suivante (à partir de la 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>

Le jeton <attr> est une chaîne qui représente un AttributeType. La valeur> du jeton <est une chaîne qui représente un AttributeValue dont le format est défini par le service d’annuaire sous-jacent.

Si une <valeur> doit contenir l’astérisque (*), la parenthèse gauche (() ou la parenthèse droite ()), le caractère doit être précédé de la barre oblique inverse (\).

Caractères spéciaux

Si l’un des caractères spéciaux suivants doit apparaître dans le filtre de recherche en tant que littéraux, il doit être remplacé par la séquence d’échappement répertoriée.

Caractère ASCII Remplacement de séquence d’échappement
* \2a
( \28
) \29
\ \5c
NUL \00
/ \2f

 

Notes

Dans les cas où un jeu de caractères multioctets est utilisé, les séquences d’échappement répertoriées ci-dessus doivent être utilisées si la recherche est effectuée par ADO avec le dialecte SQL.

 

En outre, les données binaires arbitraires peuvent être représentées à l’aide de la syntaxe de séquence d’échappement en encodant chaque octet de données binaires avec la barre oblique inverse (\) suivie de deux chiffres hexadécimaux. Par exemple, la valeur de quatre octets 0x00000004 est encodée en \00\00\00\04 dans une chaîne de filtre.

Dialecte LDAP

Dialecte SQL

Recherche avec l’interface IDirectorySearch

Recherche avec des objets de données ActiveX

Recherche avec OLE DB