LDAP-Grundlagen für Active Directory

Active Directory orientiert sich an dem Standardprotokoll LDAP v3 (Lightweight Directory Access Protocol, Version 3). Obwohl es daneben noch eine Reihe weiterer Standards und Techniken unterstützt und mit sehr leistungsfähigen grafischen Verwaltungswerkzeugen ausgeliefert wird, gibt es viele Situationen, die LDAP-Grundkenntnisse erfordern. Dazu gehören Automatisierungsaufgaben, die mit Skripten oder Kommandozeilenbefehlen arbeiten, aber auch typische administrative Tätigkeiten wie die Datensicherung oder das Suchen nach Objekten.

LDAP-Objektnamen

Jedes Objekt in Active Directory hat zahlreiche Namensattribute: Vor- und Nachname, Anzeigename, Windows-Anmeldename usw. Stets eindeutig ist aber der LDAP-Objektname, oft auch als LDAP-Pfad bezeichnet – im Fachjargon ist hier aber der Ausdruck „Distinguished Name“ korrekt. Dieser Name identifiziert das Objekt innerhalb der Hierarchie des Verzeichnisses, und zwar von der untersten Ebene (dem Objekt selbst) durch alle Container hindurch bis zum Ursprung des Verzeichnisses (was bei Active Directory die Domäne ist). Die Benutzerin „Ellen Bogen“, deren Konto in der Organisationseinheit (Organizational Unit, OU) „EDV“ gespeichert ist, welche eine Unter-OU von „Benutzer“ der Domäne faq-o-matic.net ist, hätte also folgenden Distinguished Name:

CN=Ellen Bogen, OU=EDV, OU=Benutzer, DC=faq-o-matic, DC=net

Der logische Aufbau dürfte recht deutlich sein: Von „ganz unten“ (das Objekt selbst) immer dem Speicherpfad nach bis „ganz oben“ (der Domänenname in LDAP-Notation). Die einzelnen Teile des Pfades werden dabei durch Kommas getrennt. Sollte im Objektnamen selbst bereits ein Komma vorkommen, so wird dies durch einen Backslash maskiert (CN=Bogen\, Ellen, OU=EDV …). In den meisten Programmen ist es egal, ob hinter dem Komma ein Leerzeichen folgt, ebenso ist die Groß- und Kleinschreibung meist nicht relevant.

Die jeweiligen Abschnitte werden mit Kürzeln eingeleitet, die den Typ des Abschnitts angeben. In Active Directory gibt es dabei nur drei Kürzel; andere LDAP-Verzeichnisse nutzen teils mehr oder andere Kürzel:

• CN= das ist der „Common Name“ (beste Übersetzung wäre „allgemeiner Name“; Microsoft hat das etwas ungünstig als „gemeinsamer Name“ übertragen). Mit CN= wird auf jeden Fall der Objektname selbst eingeleitet. In wenigen Spezialfällen wird auch ein Ordner in Active Directory so bezeichnet, allerdings nur dann, wenn es keine OU, sondern tatsächlich ein Ordner ist. Ein Beispiel ist der vordefinierte Ordner „Users“; der LDAP-Name des vordefinierten Administrator-Kontos ist also:
  CN=Administrator, CN=Users, DC=faq-o-matic, DC=net
• OU= dies steht für die „Organizational Unit“, also den Ordnertyp, der von Administratoren manuell angelegt werden kann. Diese Sorte Ordner ist in Active Directory bevorzugt, weil OUs mit Gruppenrichtlinien verknüpft werden können (was bei einfachen Ordnern nicht geht). Die OU-Angaben folgen immer strikt der Hierarchie von unten nach oben.
• DC= obwohl es sich um Active Directory handelt, steht DC hier nicht für „Domain Controller“, sondern für „Domain Component“. Gemeint sind die einzelnen Abschnitte des DNS-Namens der Domäne. Die Domäne „intern.contoso.com“ hätte also den LDAP-Namen DC=intern, DC=contoso, DC=com.

Leider zeigen die Windows-Administrationstools in der Regel den Distinguished Name eines Objekts nicht an. Um ihn sich nicht jedes Mal selbst zusammenreimen zu müssen, kann man aber das Programm Active Directory-Benutzer und -Computer mit folgender Methode um solch eine Funktion ergänzen:

[faq-o-matic.net » Den LDAP-Pfad eines AD-Objekts anzeigen]

http://www.faq-o-matic.net/2005/04/15/den-ldap-pfad-eines-ad-objekts-anzeigen/

LDAP-Suchabfragen

LDAP eignet sich nicht nur, um bekannte Objekte exakt ansprechen zu können. Das Protokoll bietet auch eine leistungsfähige Sprache, um im Verzeichnis nach Daten zu suchen. Die Syntax ist zunächst zwar etwas gewöhnungsbedürftig, aber durchaus logisch aufgebaut. LDAP-Suchstrings benötigt man z.B. bei der Arbeit mit Abfragen im Verwaltungsprogramm Active Directory-Benutzer und -Computer, aber auch beim Umgang mit Kommandozeilentools wie dsquery, AdFind, csvde oder NTDSUtil.

In einem LDAP-Verzeichnis sucht man in der Regel nach den Inhalten bestimmter Datenfelder. Möchte ich alle Benutzer finden, die in Hannover arbeiten, so suche ich zweckmäßigerweise nach Objekten vom Typ „Benutzer“ mit dem Wert „Hannover“ im Ortseintrag. Dabei tut sich ein Problem auf: Wie heißen denn die Felder in LDAP? Leider ist das nicht eindeutig definiert. LDAP gibt zwar ein paar Standards vor, aber nicht jeder Hersteller muss sich daran halten. So können die Felder durchaus unterschiedliche Namen tragen. Die Feldnamen, die für Active Directory am wichtigsten sind, finden sich in diesem Artikel:

[faq-o-matic.net » Active Directory: LDAP-Feldnamen]

http://www.faq-o-matic.net/2002/09/21/active-directory-ldap-feldnamen/

Die Notation folgt dabei einer üblichen Konvention, nach der ein Bezeichner mit einem Kleinbuchstaben begonnen und dann durch Großbuchstaben gegliedert wird. Die meisten Programme unterscheiden allerdings nicht nach Groß- und Kleinschreibung, sodass Tippfehler in diesem Bereich ohne Folgen bleiben sollten.

Das Suchbeispiel erfordert in Active Directory folgende Abfrage:

(&(objectClass=user)(objectCategory=person)(l=Hannover))

Das sieht auf den ersten Blick wild aus, ist aber nicht so schlimm. Üblicherweise werden Attributangaben in LDAP in Klammern eingefasst. Der obige String enthält also drei Attributangaben. Dabei sollen alle drei gleichzeitig erfüllt sein, damit die Suche einen Treffer hat. Dies gibt man ganz am Anfang der Suchabfrage mit dem &-Symbol an (ein logisches „UND“ – alles muss gleichzeitig wahr sein). Schließlich wird über ein weiteres Klammerpaar angegeben, worauf sich das & bezieht – hier der ganze Ausdruck, der deshalb eingeklammert wird.

Das Beispiel oben gab nur zwei Kriterien an: Objekte vom Typ Benutzer und Ortsangabe Hannover. Warum hat die Abfrage nun drei Attribute? Ganz einfach: Die Angabe (objectClass=user) ist für Active Directory leider nicht eindeutig, denn auch Computerkonten sind „User“. Um hier aber nicht auch alle Computer im Abfrageergebnis zu haben, die in Hannover stehen, wird die Abfrage durch (objectCategory=person) auf Personen eingegrenzt. Das ist eine Spezialität des Active Directory, die man einfach kennen muss, wenn man Stolperfallen vermeiden möchte. Siehe dazu auch:

[faq-o-matic.net » Wie frage ich gezielt Benutzerobjekte ab?]

http://www.faq-o-matic.net/2005/07/27/wie-frage-ich-gezielt-benutzerobjekte-ab/

Suchkriterien lassen sich natürlich nicht nur mit „und“ verküpfen. Es gibt auch das logische „ODER“, das mit dem Pipe-Symbol (|) angegeben wird, und das „NICHT“, das durch das Ausrufezeichen (!) angegeben wird. Alle Benutzer, die aus Hannover oder Reitimwinkl kommen, erhält man beispielsweise so:

(&(objectClass=user)(objectCategory=person)(|(l=Hannover)(l=Reitimwinkl)))

Heißt: Gib mir alle Objekte, auf die gleichzeitig zutrifft, dass sie „User“ und „Person“ sind und dass sie aus Hannover oder Reitimwinkl stammen. Alle Kontaktobjekte hingegen, die nicht „Haider“ heißen, sucht man so:

(&(objectClass=contact)(!(sn=Haider)))

LDAP akzeptiert auch Wildcards oder Jokerzeichen. Hierzu lässt sich an beliebiger Stelle im Suchstring das Sternchen * einsetzen. Vorsicht aber: Wenn das Sternchen nicht am Ende eines Werts steht, sondern vorne oder in der Mitte, wird die Suche sehr ineffektiv und performancelastig. Alle Kontakte, deren Vorname nicht mit N beginnt, findet dieses Kommando:

(&(objectClass=contact)(!(firstName=N*)))

Nach Gruppenmitgliedschaften suchen

Ein Spezialfall, der in der Administration des Active Directory oft vorkommt, ist die Suche nach Gruppenmitgliedschaften. Hier ist es wichtig, den Distinguished Name der Gruppe anzugeben und nicht nur den Anzeigenamen. Hierbei macht man sich dem Umstand zunutze, dass Gruppenmitglieder an zwei Stellen auszulesen sind: Direkt bei der Gruppe im Feld „member“, aber auch beim jeweiligen Mitglied im Feld „memberOf“. Alle Benutzer, die Mitglied der Gruppe „Domänen-Admins“ sind, gibt also folgende Suche zurück:

(&(objectClass=user)(objectCategory=person)(memberOf=CN=Domänen-Admins,CN=Users,DC=faq-o-matic,DC=net))