10Active Directory Lightweight Directory Services (AD LDS)

Drauf am zehnten berief des Volks Versammlung Achilleus,
Dem in die Seel’ es legte die lilienarmige Here;
Denn sie sorgt’ um der Danaer Volk, die Sterbenden schauend.
Als sie nunmehr sich versammelt, und voll gedrängt die Versammlung;
Trat hervor und begann der mutige Renner Achilleus:
Atreus Sohn, nun denk’ ich, wir ziehn den vorigen Irrweg
Ein LDAP-kompatibler Verzeichnisdienst wie das Active Directory ist eine praktische Angelegenheit, um Daten aller Art, wie Benutzerdaten, Applikationsdaten und dergleichen mehr zu speichern. Grundsätzlich wäre es möglich, alle Daten im Active Directory abzulegen und diesen Verzeichnisdienst, der ja eher infrastrukturelle Aufgaben übernimmt (z. B. Benutzer authentifizieren) um einen breiten Applikationssupport zu erweitern. Exchange macht im Grunde genommen vor, wie man das Active Directory nutzt:
- Jede Menge Objekte und Attribute werden dem Verzeichnisdienst hinzugefügt, damit die Exchange-spezifischen Daten bei den Benutzerobjekten gespeichert werden können.
- Exchange hat keine eigene Benutzerverwaltung, sondern nutzt AD-Konten.
- Alle Informationen (vom Routing über die Information, in welchen Pfaden die Datenbanken gespeichert sind) liegen im Active Directory.
Das könnten natürlich auch andere Anwendungen so machen. Der Haken dabei ist, dass jedes Mal eine Schemaerweiterung notwendig wäre. Eine Schemaerweiterung, die für die komplette, unter Umständen weltweite Umgebung gilt, führt man nicht »mal eben so« durch, sondern sie will gut überlegt sein – insbesondere, weil sie nicht spurlos rückgängig gemacht werden kann.
Da die Active Directory-Technologie alle notwendigen Komponenten beinhaltet und sich als stabil und zuverlässig erwiesen hat, führte Microsoft mit Windows Server 2003 ADAM ein. ADAM ist die Abkürzung für Active Directory Application Mode . Es handelte sich um einen separat zu installierenden und vom Active Directory unabhängigen Verzeichnisdienst, der auf Active Directory-Technologie basiert. Mit Windows Server 2008 ist ADAM umbenannt worden. Es heißt nun Active Directory Lightweight Directory Services (AD LDS), basiert aber auf den bisherigen Konzepten.
Tabelle 10.1 fasst die Unterschiede zwischen ADDS (Active Directory-Domänendienste) und AD LDS (Active Directory Lightweight Directory Services) zusammen:
Feature |
AD LDS/ ADAM |
ADDS |
Mehrere Schemas pro Server |
Ja |
Nein |
Mehrere Instanzen mit unterschiedlichen Verzeichnissen pro Server |
Ja |
Nein |
Kann auf XP professional betrieben werden (nur für Test- und Entwicklungszwecke!) |
Ja |
Nein |
Kann auf Mitgliedsservern betrieben werden |
Ja |
Nein |
Kann ohne Neustart installiert werden |
Ja |
Nein |
X.500-Namen auf oberster Ebene |
Ja |
Nein |
Gruppenrichtlinien |
Nein |
Ja |
Globaler Katalog |
Nein |
Ja |
Desktop-Management mit IntelliMirror-Technologie |
Nein |
Ja |
Automatisierte Softwareverteilung |
Nein |
Ja |
Vertrauensbeziehungen zwischen Domains und Forests |
Nein |
Ja |
Public Key Infrastructure (PKI)/X.509 |
Nein |
Ja |
DNS Service Resource Records (SRV) |
Nein |
Ja |
LDAP API |
Ja |
Ja |
Zugriff über Active Directory Service Interfaces (ADSI) API |
Ja |
Ja |
Zugriff über Messaging API (MAPI) |
Nein |
Ja |
Delegierbare Administration |
Ja |
Ja |
Multimaster-Replikation |
Ja |
Ja |
InetOrgPerson |
Ja |
Ja |
LDAP over Secure Sockets Layer (SSL) |
Ja |
Ja |
Sicherheit auf Attribut-Ebene |
Ja |
Ja |
LDAP Access Control List (ACL) |
Ja |
Ja |
Kompatibilität mit Microsoft Identity Integration Server 2003 |
Ja |
Ja |
Erweiterbares Schema |
Ja |
Ja |
Application Directory Partitions |
Ja |
Ja |
Läuft auf 64-Bit-Servern |
Ja |
Ja |
Unterstützt Concurrent LDAP Binding |
Ja |
Ja |
Das Fazit der Tabelle ist, dass AD LDS ein vollwertiger LDAP-kompatibler Verzeichnisdienst ist, dem die Infrastrukturkomponenten von ADDS fehlen, wie beispielsweise die Unterstützung für globale Katalogserver, Gruppenrichtlinien etc.
Das Thema AD LDS ist für einen IT-Professional nur sehr begrenzt interessant, solange nicht Anwendungen auf diesen Dienst aufsetzen. AD LDS hat keine »nativen Infrastrukturfunktionen« und bringt – salopp gesagt – die Umgebung nicht durch bloße Anwesenheit weiter.
Da davon auszugehen ist, dass künftig mehr Anwendungsentwickler entdecken, dass die Nutzung eines Verzeichnisses für sie (bzw. die Anwendungen) von Vorteil ist, wird die Wahrscheinlichkeit steigen, mit AD LDS in Berührung zu kommen.
Zum Ende dieser kurzen Einführung möchte ich Ihnen noch ein paar Ideen mitgeben, was mit AD LDS alles machbar ist:
- Autarkes LDAP-Verzeichnis: AD LDS kann auch ohne die Integration mit einem bestehenden AD als alleinstehendes Directory betrieben werden.
- Informationsspeicher für AD-Benutzerkonten: Häufig genügen die standardmäßigen Attribute im Active Directory nicht, um die von einer Applikation benötigten Benutzerinformationen zu speichern. AD LDS kann die zusätzlichen Informationen aufnehmen, sodass keine Schemaerweiterung im AD notwendig wird. Man würde zu diesem Zweck eine Replikationsbeziehung zwischen dem AD und AD LDS aufbauen und in Letzterem ein entsprechend erweitertes Schema für Benutzerobjekte verwenden. Die Replikation kann mittels Identity Integration Server, Identity Integration Feature Pack oder ADAM Synchronizer (als Download erhältlich, siehe Microsoft Download Center) durchgeführt werden.
- Externe Benutzer integrieren: Weiterhin kann AD LDS für die Authentifizierung externer Benutzer verwendet werden.
Es gibt übrigens auch bekannte Beispiele aus der Welt der Microsoft-Standardprodukte, in denen die ADAM bzw. die Lightweight Directory Services genutzt werden:
- Die Rolle Edge-Server des Exchange Server 2007/2010/2013 benötigt einen eigenen kleinen Verzeichnisdienst, auf den ein Teil der Informationen aus dem Active Directory repliziert wird.
- Ein TMG Server 2010 Enterprise Edition verwendet ADAM, um einen serverübergreifenden Informationsspeicher zu realisieren. Das heißt, mehrere TMG Server des Verbunds erhalten die Konfigurationsinformationen von dem Verzeichnisdienst.
10.1
Installation

Active Directory Lightweight Directory Services (AD LDS) können auf einem beliebigen Windows Server 2012 installiert werden. Dieser muss kein Domänencontroller sein.
Konflikte
Bei der Installation auf einem Domänencontroller müssen Sie auf Konflikte mit Portnummern achten.
Sie fügen AD LDS über den Server-Manager hinzu. Dort wählen Sie das Hinzufügen einer Rolle aus (Abbildung 10.1). Kurze Zeit später ist die Installation abgeschlossen, und der Server-Manager zeigt eine weitere installierte Rolle.
Abbildung 10.1 Zur Installation von AD LDS fügen Sie dem Server die entsprechende Rolle hinzu.
Im Grunde genommen ist die einzige mögliche Aktion das Erstellen einer neuen Instanz, ansonsten ist das frisch installierte AD LDS funktionslos (Abbildung 10.2).
Abbildung 10.2 AD LDS sind fertig installiert – zunächst herrscht gähnende Leere, und man kann nichts Spannenderes tun, als eine neue AD LDS-Instanz zu erstellen.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.