Active Directory (AD) ist das Herzstück vieler Unternehmensnetzwerke. Es verwaltet Identitäten, Berechtigungen und Ressourcen und sorgt dafür, dass Benutzer, Computer und Dienste sicher miteinander kommunizieren können. Doch AD ist nur ein Teil eines größeren Ökosystems, zu dem das LDAP‑Protokoll, die Lightweight Directory Services (AD LDS) und zunehmend Cloud‑Dienste wie Microsoft Entra ID (früher Azure AD) und Microsoft Entra Domain Services gehören. In diesem Beitrag beleuchten wir die Funktionsweise dieser Komponenten im Detail, zeigen ihre Unterschiede und erläutern, wie sie zusammenarbeiten.

1. Grundlagen von Active Directory

Active Directory ist ein hierarchisches Verzeichnisdienstsystem, das von Microsoft entwickelt wurde. Es speichert Informationen über Objekte – Benutzer, Gruppen, Computer, Drucker und mehr – in einer strukturierten Datenbank. Die Grundbausteine von AD sind:

• Domänen: Logische Gruppierungen von Objekten, die einen gemeinsamen Sicherheitsbereich bilden. Jede Domäne hat einen eindeutigen Namen.
• Bäume und Wälder: Mehrere Domänen können zu einem Baum verbunden werden, der wiederum Teil eines Waldes ist. Der Wald bildet die höchste Ebene und definiert die globale Katalogstruktur.
• Organisationseinheiten (OUs): Logische Container innerhalb einer Domäne, die zur Delegierung von Verwaltungsrechten und zur Anwendung von Gruppenrichtlinien verwendet werden.
• Sicherheitsgruppen: Gruppen von Benutzern oder Computern, die gemeinsam Berechtigungen erhalten. AD kennt drei Gruppenbereiche: lokal (in der Domäne) für Berechtigungen auf Ressourcen einer Domäne, global für Mitglieder aus der eigenen Domäne und universell für Mitglieder aus dem gesamten Wald.

Für Verzeichnisabfragen nutzt AD das Lightweight Directory Access Protocol (LDAP, TCP‑Port 389 bzw. 636 für LDAPS). Für die Authentifizierung setzt es auf Kerberos, mit NTLM als älterem Fallback‑Mechanismus. Hinzu kommen DNS für die Namensauflösung und das Auffinden von Domänencontrollern sowie Gruppenrichtlinien für die zentrale Konfiguration von Clients.

2. LDAP – das Protokoll

LDAP (Lightweight Directory Access Protocol) ist ein offenes, plattformunabhängiges Protokoll, das den Zugriff auf Verzeichnisdienste ermöglicht. Es definiert einen Satz von Operationen, die Clients ausführen können:

• Bind: Authentifizierung des Clients beim Server.
• Search: Abfrage von Objekten anhand von Filtern und Attributen.
• Add/Modify/Delete: Verwaltung von Objekten im Verzeichnis.
• Compare: Überprüfung, ob ein bestimmtes Attribut einen bestimmten Wert hat.

LDAP organisiert Einträge in einer Baumstruktur, dem Directory Information Tree. Jeder Eintrag wird eindeutig durch seinen Distinguished Name (DN) identifiziert, der aus Attribut‑Wert‑Paaren besteht und – von links nach rechts gelesen – vom Objekt selbst bis zur Wurzel des Verzeichnisses führt. Beispiel: cn=John Doe,ou=Users,dc=contoso,dc=com

Ein wichtiger Aspekt von LDAP ist die Unterstützung von SASL (Simple Authentication and Security Layer), das verschiedene Authentifizierungsmechanismen wie Kerberos, DIGEST-MD5 oder PLAIN ermöglicht. In AD wird LDAP in Kombination mit Kerberos verwendet, um sichere, verschlüsselte Verbindungen zu gewährleisten.

LDAP ist nicht auf Windows beschränkt; es wird von vielen Plattformen unterstützt, darunter OpenLDAP, 389 Directory Server, Apache Directory Server und eDirectory (ursprünglich von Novell). Diese Interoperabilität macht LDAP zu einem zentralen Protokoll für die Integration von Identitätsdiensten über unterschiedliche Betriebssysteme hinweg.

3. AD LDS – Lightweight Directory Services

Active Directory Lightweight Directory Services (AD LDS) ist ein eigenständiger LDAP‑Verzeichnisdienst, der ohne Domäne und ohne Domänencontroller auskommt. Er bietet die LDAP‑Funktionen von AD, aber keine Kerberos‑Authentifizierung, keine Gruppenrichtlinien und keine Domänenmitgliedschaft von Computern. Auf einem Server können mehrere unabhängige AD‑LDS‑Instanzen mit jeweils eigenem Schema laufen. Typische Einsatzszenarien sind:

• Anwendungs‑Back‑Ends: Anwendungen, die ihre eigenen Benutzer‑ und Konfigurationsdaten verwalten, ohne sich an die zentrale AD‑Domäne anzuschließen.
• Sicherheits‑ und Compliance‑Anforderungen: Szenarien, in denen Daten in einer isolierten Umgebung gespeichert werden müssen, z. B. in einer Sandbox oder in einer Cloud‑Umgebung.
• Legacy‑Systemintegration: Ältere Anwendungen, die LDAP‑Zugriff benötigen, aber nicht für die Integration in ein bestehendes AD‑Domänenmodell ausgelegt sind.

AD LDS läuft als Rolle auf Windows Server, auch in virtuellen Maschinen. Benutzer werden per LDAP‑Bind authentifiziert – entweder mit eigenen AD‑LDS‑Konten oder, wenn der Server Mitglied einer Domäne ist, auch mit Windows‑Konten. Durch die Trennung von AD LDS und AD können Unternehmen anwendungsspezifische Verzeichnisdaten auslagern, ohne das Schema der zentralen Domäne zu verändern.

4. Microsoft Entra Domain Services (früher Azure AD Domain Services)

Microsoft Entra ID (bis 2023 Azure Active Directory) ist der Cloud‑Identitätsdienst von Microsoft. Er nutzt moderne Protokolle wie OAuth 2.0, OpenID Connect und SAML – LDAP und Kerberos spricht Entra ID von sich aus nicht. Für Anwendungen, die genau das brauchen, bietet Microsoft Microsoft Entra Domain Services (früher Azure AD Domain Services) an: eine verwaltete Domäne in Azure, die Domänenbeitritt, Gruppenrichtlinien, LDAP (auch Secure LDAP), Kerberos und NTLM bereitstellt, ohne dass man eigene Domänencontroller betreiben muss. Hauptmerkmale:

• Verwalteter Dienst: Microsoft betreibt, patcht und sichert die Domänencontroller; Administratoren erhalten dafür keine Domänen-Admin-Rechte.
• Kompatibilität: Unterstützt bestehende LDAP-Clients und Anwendungen, die auf Kerberos oder NTLM angewiesen sind – etwa bei der Migration älterer Serveranwendungen nach Azure.
• Hybrid‑Szenarien: Benutzer und Gruppen werden in eine Richtung aus Entra ID übernommen; stammen sie aus einem lokalen AD, gelangen sie über Entra Connect Sync dorthin. Damit sich synchronisierte Benutzer anmelden können, muss die Kennwort‑Hash‑Synchronisation aktiviert sein.

Entra Domain Services eignet sich besonders für Unternehmen, die Anwendungen in die Cloud verlagern, die weiterhin LDAP‑ oder Kerberos‑basierte Authentifizierung benötigen. Einschränkungen gibt es bei Schema‑Erweiterungen und Vertrauensstellungen; wer diese braucht, betreibt stattdessen eigene Domänencontroller in Azure‑VMs.

5. Integration und Einsatzszenarien

Die Kombination aus AD, LDAP, AD LDS, Entra ID und Entra Domain Services ermöglicht vielfältige Architekturoptionen:

Ein typisches Beispiel ist ein Unternehmen, das seine internen Anwendungen in Azure migriert, aber weiterhin LDAP‑basierte Authentifizierung für Legacy‑Software benötigt. Mit Entra Domain Services können diese Anwendungen in Azure ihre gewohnte Authentifizierung behalten, während die Identitäten weiterhin zentral im lokalen AD gepflegt und über Entra Connect Sync in die Cloud übernommen werden.

Fazit

Active Directory, LDAP, AD LDS und die Cloud-Dienste Entra ID und Entra Domain Services bilden ein umfassendes Ökosystem für Identitäts- und Zugriffsmanagement. Während AD die Basis vieler Unternehmensnetzwerke bildet, ermöglicht LDAP die plattformunabhängige Verzeichniskommunikation. AD LDS bietet ein schlankes Verzeichnis für Anwendungen, Entra ID verbindet Identitäten mit Cloud-Diensten, und Entra Domain Services schließt die Lücke für Altanwendungen, die LDAP und Kerberos in Azure benötigen. Durch die richtige Kombination dieser Komponenten können Unternehmen eine flexible und sichere Identitätsinfrastruktur schaffen.