LDAP-Abfragen erstellen

Vergleiche

Neben dem Gleichheitszeichen werden von LDAP auch andere Vergleiche unterstützt. <= und >= führen jeweils lexikographische Vergleiche durch. (sn<=M*) würde alle Anwender mit Nachnamen liefern, die mit Buchstaben bis einschließlich „M“ beginnen. Diese Vergleiche sind allerdings mit Vorsicht zu genießen. Es wird definitionsgemäß ein lexikographischer Vergleich durchgeführt. Dieser bezieht sich rein auf den Zeichencode an der jeweiligen Position des Strings. Es gilt in diesem Fall zwar „021“ < „201“, aber „21“ > „201“ („2“ gleich „2“ und „1“ > „0“).

LDAP sieht zudem noch einen Operator für ungefähre Vergleiche „~=“ vor, dessen genaue Funktion aber vom Standard nicht vorgegeben wird. Microsoft unterstützt diesen Operator zwar, aber das bedeutet nur, dass dessen Angabe nicht zu einem Fehler führt. Derzeit wird er nur wie ein normales Gleichheitszeichen ausgewertet.

Zudem werden vom Active Directory zwei Operatoren zu Vergleichen mit Bitfeldern unterstützt. Sie haben die Form Attribut:ruleOID:=Wert. Attribut ist der Name eines Bitfeld-Attributs, Wert ist eine Bitmaske. Mit dieser Bitmaske wird eine bitweise Auswertung durchgeführt. Je nach roleOID wird der Vergleich als wahr bewertet, wenn alle (UND) oder wenn irgendein Bit (ODER) des Attributswerts dessen Position in der Maske auf 1 gesetzt ist, auch 1 ist. Es werden also nur die Bits des Attributs betrachtet, die in der Maske auf 1 gesetzt sind. Für diese wird überprüft, ob ihr Wert 1 ist. Die zulässigen Angaben für roleOID sind:

  • 1.2.840.113556.1.4.803 (entspricht UND)

  • 1.2.840.113556.1.4.804 (entspricht ODER)

Ein Beispiel für die Anwendung des Bit-Vergleichs ist die Suche nach deaktivierten Konten und solchen, die ihre Kennwörter nicht ändern können. Das notwendige Attribut heißt in diesem Fall userAccountControl. Die Bitmasken sind 0x02 (Deaktiviert) und 0x0040 (Kennwort kann nicht geändert werden), also zusammen 0x0042 oder dezimal 66. Wenn nach Konten gesucht werden soll, die deaktiviert sind und ihre Kennwörter nicht ändern können, dann hilft folgender Filter weiter:

(userAccountControl:1.2.840.113556.1.4.803:=66)

Wenn Konten gesucht werden sollen, die entweder deaktiviert sind oder ihre Kennwörter nicht ändern können, muss der Filter entsprechend wie folgt lauten:

(userAccountControl:1.2.840.113556.1.4.803:=66)

Zudem unterstützt LDAP auch einen logischen Negations-Operator. Er wird dem Vergleich als Ausrufezeichen vorangestellt. Sind beispielsweise in einem Unternehmen die Anwender selbst dafür verantwortlich, Daten wie ihre Büronummer einzutragen, dann hilft der folgende Filter, all diejenigen zu finden, die dies noch nicht getan haben (!physicalDeliveryOfficeName=*). Die Negation in Verbindung mit dem Stern sucht nach leeren, also letztlich nicht existenten Attributwerten. Auch hier muss man bei den Attributbezeichnern etwas aufpassen: roomNumber entspricht nicht dem Feld Büro in der Eingabemaske von AD Benutzer und Computer.

Bild 1: ADSIEdit (hier in der Windows 2003 SP1-Version) hilft die verfügbaren Attribute anzuzeigen.
Bild 1: ADSIEdit (hier in der Windows 2003 SP1-Version) hilft die verfügbaren Attribute anzuzeigen.

Objekttypen

Im Active Directory befinden sich befinden sich eine ganze Reihe von Objektarten. Benutzerkonten sind genauso Objekte wie Gruppen und Verteilerlisten und eine Vielzahl von Systemobjekten. Wenn nun einfach nach E-Mail-Adressen gesucht wird, würden alle Objekte, denen eine EMail zugeordnet werden kann, als Ergebnis zurückgeliefert, neben Benutzern beispielsweise auch Verteilerlisten und öffentliche Ordner, was nicht immer gewünscht ist. Wenn nach der nicht vorhandenen Raumnummer ohne Einschränkung des Objekttyps gesucht würde, würde jede Objektart ohne festgelegte Raumnummer ausgegeben werden.

Die Objekttypen lassen sich aber leicht auswählen, da sie auch als Attribut (objectClass) beim Objekt gespeichert sind. Sie lassen sich deshalb genauso als Bedingung formulieren, wie auch nach Objekten mit bestimmten Nachnamen oder Raumnummer gesucht wird. Die folgende Abfrage sucht alle Kontakt-Objekte im Verzeichnis:

(objectClass=contact)

Allerdings ist ein Active Directory einer hierarchischen Liste von Objektklassen zugeordnet, die letztendlich den Typ ausmachen. Wenn beispielsweise nach der Klasse User gesucht wird, werden auch Typen wie Computerkonten gefunden, die eventuell nicht als Ergebnis gewünscht sind. Speziell bei der Suche nach Benutzerkonten wird deshalb üblicherweise noch als Bedingung (objectClass=person) hinzugefügt, um nur menschliche Anwender zu finden. Der folgende Filter liefert beispielsweise in einer Exchange-Umgebung alle regulären Benutzerobjekte, das heißt solche, die ein Postfach und damit eine definierte E-Mail-Adresse haben.

(&(objectCategory=person)(objectClass=user)(mail=*))