Verzeichnisdienste: Active Directory vs. Entra ID vs. LDAP

Was ist ein Verzeichnisdienst und warum ist er so wichtig?

Ein Verzeichnisdienst ist eine zentrale Datenbank, die Informationen über Benutzer, Computer, Gruppen und andere Objekte in einem Netzwerk speichert und verwaltet. Er beantwortet die fundamentale Frage jeder IT-Infrastruktur: Wer bist du, und was darfst du tun?

Ohne Verzeichnisdienst müsste jedes System seine eigene Benutzerverwaltung betreiben. Jeder Server, jede Anwendung und jeder Dienst hätte seine eigene Datenbank mit Benutzernamen und Passwörtern. Das Ergebnis wäre ein Chaos aus inkonsistenten Konten, verwaisten Zugängen und unkontrollierbaren Berechtigungen.

Der Verzeichnisdienst zentralisiert diese Aufgabe. Ein Benutzer wird einmal angelegt, einer oder mehreren Gruppen zugeordnet, und alle verbundenen Systeme nutzen diesen zentralen Datensatz für Authentifizierung und Autorisierung. Wenn der Benutzer das Unternehmen verlässt, wird sein Konto an einer Stelle deaktiviert, und der Zugang zu allen verbundenen Systemen wird gesperrt.

Für dein ISMS ist der Verzeichnisdienst ein kritisches System. Er steuert, wer Zugang zu welchen Ressourcen hat, und ist damit die technische Grundlage für dein Berechtigungskonzept, deine Zugangsrichtlinie und dein User Lifecycle Management. ISO 27001 adressiert Verzeichnisdienste nicht direkt, aber die Anforderungen aus Annex A.5.15 (Zugangssteuerung), A.5.16 (Identitätsmanagement), A.5.17 (Authentifizierungsinformationen) und A.5.18 (Zugangsrechte) sind ohne einen funktionierenden Verzeichnisdienst kaum umsetzbar.

Active Directory: Der On-Premise-Standard

Active Directory (AD) wurde 1999 mit Windows 2000 Server eingeführt und ist seitdem der De-facto-Standard für die Identitätsverwaltung in Windows-basierten Unternehmensnetzwerken. Nach über 25 Jahren nutzen weltweit über 90 Prozent der Fortune-1000-Unternehmen Active Directory, und auch im Mittelstand ist es die mit Abstand verbreitetste Lösung.

Architektur und Kernkonzepte

Active Directory basiert auf einer hierarchischen Struktur aus Forests, Domains und Organizational Units (OUs). Ein Forest ist die oberste Sicherheitsgrenze und umfasst eine oder mehrere Domains. Eine Domain ist ein administrativer Bereich mit eigenen Benutzern, Computern und Richtlinien. OUs sind Container innerhalb einer Domain, die der organisatorischen Gliederung dienen.

Jede Domain wird von mindestens einem Domain Controller (DC) bedient, einem Server, der die AD-Datenbank speichert und Authentifizierungsanfragen verarbeitet. Die Replikation zwischen mehreren Domain Controllern sorgt für Ausfallsicherheit und Lastverteilung. Wenn ein DC ausfällt, übernehmen die anderen DCs seine Funktion.

Authentifizierung: Kerberos und NTLM

AD nutzt primär das Kerberos-Protokoll für die Authentifizierung. Kerberos basiert auf einem Ticket-System: Der Benutzer authentifiziert sich einmal beim Key Distribution Center (KDC) auf dem Domain Controller und erhält ein Ticket-Granting Ticket (TGT). Mit diesem TGT kann er Service Tickets für den Zugriff auf andere Ressourcen anfordern, ohne sein Passwort erneut eingeben zu müssen. Das ist Single Sign-On auf Netzwerkebene.

NTLM ist das ältere Authentifizierungsprotokoll, das aus Kompatibilitätsgründen weiterhin unterstützt wird. NTLM ist deutlich weniger sicher als Kerberos und anfällig für Relay-Angriffe und Pass-the-Hash-Attacken. In einer gehärteten AD-Umgebung sollte NTLM so weit wie möglich deaktiviert werden.

Group Policies

Group Policies (Gruppenrichtlinien) sind eines der mächtigsten Features von Active Directory. Sie ermöglichen die zentrale Konfiguration von Sicherheitseinstellungen, Softwareverteilung und Benutzerumgebungen für tausende von Computern und Benutzern gleichzeitig.

Über Group Policies kannst du unter anderem die Passwort-Richtlinie durchsetzen (Mindestlänge, Komplexität, Ablauf), die lokale Firewall konfigurieren, die Installation von Software steuern, USB-Ports sperren, die BitLocker-Verschlüsselung erzwingen, die Windows-Update-Einstellungen festlegen und den Zugriff auf bestimmte Systemeinstellungen einschränken.

Group Policies werden an Domains, Sites oder OUs gebunden und vererben sich hierarchisch. Ein Gruppenrichtlinienobjekt (GPO), das an der Domain gebunden ist, gilt für alle Computer und Benutzer in der Domain. Ein GPO, das an einer OU gebunden ist, gilt nur für die Objekte in dieser OU und ihren Unter-OUs.

Stärken und Schwächen von AD

Die Stärken von Active Directory liegen in der tiefen Integration mit dem Windows-Ökosystem, dem leistungsstarken Group-Policy-System, der bewährten Kerberos-Authentifizierung und der umfangreichen Expertise, die am Markt verfügbar ist.

Die Schwächen zeigen sich bei modernen Anforderungen. AD erfordert On-Premise-Server, die gewartet, gepatcht und gesichert werden müssen. Die Anbindung von SaaS-Anwendungen erfordert zusätzliche Infrastruktur (ADFS oder Entra Connect). Die Verwaltung ist komplex und erfordert spezialisiertes Know-how. Und die Sicherheit hängt stark von der Härtung ab: Ein schlecht konfiguriertes AD ist ein leichtes Ziel für Angreifer.

Entra ID: Die Cloud-native Alternative

Microsoft Entra ID (bis 2023 als Azure Active Directory bekannt) ist Microsofts Cloud-basierter Identitätsdienst. Es ist wichtig zu verstehen, dass Entra ID kein "AD in der Cloud" ist. Es ist ein eigenständiger Dienst mit eigener Architektur, eigenen Protokollen und eigenem Feature-Set.

Architektur und Kernkonzepte

Entra ID organisiert Identitäten in Tenants. Jeder Tenant ist eine dedizierte Instanz des Entra-ID-Dienstes, die einer Organisation gehört. Innerhalb eines Tenants gibt es Benutzer, Gruppen, Anwendungen und Rollen, aber keine Forests, Domains oder OUs im AD-Sinne.

Die Struktur ist flacher als in AD. Statt einer hierarchischen OU-Struktur verwendet Entra ID Administrative Units, die aber weniger flexibel sind. Die Berechtigungsverwaltung erfolgt primär über Rollen (RBAC) und Conditional Access Policies, nicht über Group Policies.

Authentifizierung: OIDC und SAML

Entra ID verwendet moderne Authentifizierungsprotokolle: OpenID Connect (OIDC) für die Authentifizierung und OAuth 2.0 für die Autorisierung. SAML 2.0 wird für die Integration mit Enterprise-Anwendungen unterstützt. Kerberos und NTLM werden nicht nativ unterstützt, können aber über Entra Connect für hybride Szenarien bereitgestellt werden.

Die Unterstützung moderner Protokolle macht Entra ID zur natürlichen Wahl für Cloud-Anwendungen. Die Integration mit Microsoft 365, Azure-Diensten und tausenden SaaS-Anwendungen erfolgt über standardisierte Protokolle und ist in den meisten Fällen mit wenigen Klicks eingerichtet.

Conditional Access

Conditional Access ist das Äquivalent zu Group Policies in der Cloud-Welt, allerdings mit einem anderen Ansatz. Statt starre Konfigurationen auf Geräte zu verteilen, trifft Conditional Access Zugriffsentscheidungen in Echtzeit auf Basis von Kontext: Wer greift zu? Von welchem Gerät? Von welchem Standort? Wie hoch ist das Risiko?

Typische Conditional-Access-Policies können festlegen: MFA erforderlich bei Zugriff von außerhalb des Firmennetzwerks. Zugriff nur von verwalteten Geräten auf vertrauliche Anwendungen. Blockierung des Zugriffs aus Ländern, in denen das Unternehmen keine Standorte hat. Erzwungener Passwortwechsel bei Erkennung eines kompromittierten Accounts (Identity Protection).

Stärken und Schwächen von Entra ID

Die Stärken von Entra ID sind die nahtlose Cloud-Integration, Conditional Access, die native Unterstützung moderner Protokolle (OIDC, SAML, FIDO2), der geringe Betriebsaufwand (kein eigener Server) und die kontinuierliche Weiterentwicklung durch Microsoft.

Die Schwächen betreffen primär On-Premise-Szenarien. Entra ID kann nicht direkt mit lokalen Windows-Servern, Dateifreigaben oder Druckern interagieren. Dafür wird weiterhin ein lokales Active Directory oder Entra Domain Services (ein verwalteter AD-Dienst in Azure) benötigt. Die Abhängigkeit von der Cloud-Verfügbarkeit ist ein Risiko, auch wenn die SLAs hoch sind. Und die Lizenzierung kann komplex und teuer werden, besonders wenn fortgeschrittene Features wie Conditional Access, PIM oder Identity Protection benötigt werden.

LDAP: Das offene Protokoll

LDAP (Lightweight Directory Access Protocol) ist kein Verzeichnisdienst im engeren Sinne, sondern ein Protokoll für den Zugriff auf Verzeichnisdienste. Active Directory implementiert LDAP als eines seiner Zugriffsprotokolle. Aber LDAP existiert auch als eigenständige Lösung, insbesondere in Linux- und Unix-Umgebungen.

LDAP-Implementierungen

OpenLDAP ist die am weitesten verbreitete Open-Source-LDAP-Implementierung. Sie läuft auf Linux und bietet einen leistungsfähigen, skalierbaren Verzeichnisdienst ohne Lizenzkosten. Die Konfiguration erfolgt über Textdateien und LDIF-Dateien (LDAP Data Interchange Format), was eine steile Lernkurve bedeutet, aber auch maximale Flexibilität bietet.

389 Directory Server (früher Red Hat Directory Server) ist eine weitere Open-Source-Lösung, die besonders in Red-Hat-Umgebungen verbreitet ist. Sie bietet eine grafische Verwaltungsoberfläche und ist etwas einfacher zu administrieren als OpenLDAP.

FreeIPA ist eine integrierte Identitätsmanagement-Lösung für Linux, die 389 Directory Server als Backend nutzt, aber zusätzlich Kerberos-Authentifizierung, DNS-Management und eine Web-Oberfläche bietet. FreeIPA ist das Linux-Äquivalent zu Active Directory und eignet sich für Unternehmen mit einer überwiegend Linux-basierten Infrastruktur.

Wann ist LDAP die richtige Wahl?

LDAP als eigenständiger Verzeichnisdienst ist sinnvoll in reinen oder überwiegend Linux-Umgebungen, wenn die Lizenzkosten für Microsoft-Produkte vermieden werden sollen, wenn Anwendungen explizit LDAP-Authentifizierung erfordern und wenn maximale Kontrolle über den Verzeichnisdienst gewünscht ist.

Für Unternehmen mit einer gemischten Windows/Linux-Infrastruktur ist LDAP allein oft nicht ausreichend, weil die Integration mit Windows-Funktionen wie Group Policies, Kerberos für Windows-Dienste und die nahtlose Desktop-Integration fehlt. In diesen Fällen ist Active Directory (das LDAP als Protokoll unterstützt) oder eine hybride Lösung mit AD und FreeIPA die bessere Wahl.

Hybride Identitätsarchitektur: AD und Entra ID verbinden

Die Realität der meisten Unternehmen ist weder rein On-Premise noch rein Cloud, sondern hybrid. Server stehen im eigenen Rechenzentrum, Anwendungen laufen in der Cloud, und die Mitarbeiter arbeiten sowohl im Büro als auch remote. Diese hybride Realität erfordert eine hybride Identitätsarchitektur.

Entra Connect: Die Brücke

Microsoft Entra Connect (ehemals Azure AD Connect) ist das Werkzeug, das lokales Active Directory und Entra ID verbindet. Es synchronisiert Benutzer, Gruppen und Attribute vom lokalen AD nach Entra ID, sodass Mitarbeiter mit denselben Zugangsdaten sowohl auf lokale Ressourcen als auch auf Cloud-Dienste zugreifen können.

Entra Connect bietet drei Synchronisierungsmodi. Die Passwort-Hash-Synchronisation (PHS) synchronisiert einen Hash des Passwort-Hashes nach Entra ID. Die Authentifizierung gegen Cloud-Dienste erfolgt direkt in Entra ID, ohne den lokalen DC kontaktieren zu müssen. Das ist der einfachste und empfohlene Modus. Die Pass-Through-Authentifizierung (PTA) leitet die Authentifizierung an den lokalen DC weiter. Der Passwort-Hash wird nicht in die Cloud übertragen, was für Unternehmen mit strengen Compliance-Anforderungen relevant sein kann. Die Federation mit ADFS leitet die Authentifizierung an eine lokale ADFS-Infrastruktur weiter, die dann SAML-Tokens ausstellt. Dieser Modus ist der komplexeste und wird nur in speziellen Szenarien empfohlen.

Herausforderungen der hybriden Architektur

Die hybride Identitätsarchitektur bringt spezifische Herausforderungen mit sich. Die Synchronisierungsrichtung ist standardmäßig unidirektional: vom lokalen AD nach Entra ID. Wenn du einen Benutzer in Entra ID änderst, wird die Änderung nicht automatisch ins lokale AD zurückgeschrieben. Entra Connect Cloud Sync bietet mittlerweile bidirektionale Szenarien, aber die Konfiguration ist komplexer.

Konflikte können auftreten, wenn dasselbe Attribut an beiden Stellen geändert wird. Entra Connect löst Konflikte nach definierten Regeln, aber das Ergebnis ist nicht immer intuitiv. Eine klare Zuständigkeitsregelung (welche Attribute werden wo gepflegt?) ist unerlässlich.

Die Abhängigkeit von Entra Connect als Synchronisierungskomponente ist ein weiteres Risiko. Wenn Entra Connect ausfällt, werden Änderungen im lokalen AD nicht mehr in die Cloud synchronisiert, und neue Mitarbeiter erhalten keinen Zugang zu Cloud-Diensten. Monitoring und Alerting für Entra Connect sind daher Pflicht.

Entra Domain Services

Für Szenarien, in denen klassische AD-Funktionen (Kerberos, LDAP, Group Policies) in der Cloud benötigt werden, bietet Microsoft Entra Domain Services (ehemals Azure AD Domain Services). Dieser verwaltete Dienst stellt eine AD-kompatible Domain in Azure bereit, ohne dass du Domain Controller selbst betreiben musst.

Entra Domain Services ist nützlich für das Lift-and-Shift von On-Premise-Anwendungen nach Azure, die AD-Authentifizierung erfordern, für die Anbindung älterer Anwendungen an Entra ID über LDAP oder Kerberos und für Szenarien, in denen die On-Premise-AD-Infrastruktur abgelöst werden soll, aber nicht alle Anwendungen auf moderne Protokolle umgestellt werden können.

Migration und Transformationspfade

Viele Unternehmen stehen vor der Frage, ob und wie sie ihre Verzeichnisdienstarchitektur modernisieren sollen. Die Antwort hängt von der Ausgangssituation und den Zielen ab.

Von AD zu Entra ID (Cloud-Only)

Der vollständige Übergang von On-Premise-AD zu Entra ID (Cloud-Only) ist das langfristige Ziel vieler Unternehmen. Dieser Übergang bedeutet, dass die Domain Controller abgeschaltet werden und alle Identitäten ausschließlich in Entra ID verwaltet werden. Endgeräte werden Entra-ID-joined statt domain-joined, und Anwendungen authentifizieren über OIDC/SAML statt über Kerberos/LDAP. Single Sign-On wird zum zentralen Zugangsweg für alle Dienste.

Die Voraussetzungen sind anspruchsvoll: Alle Anwendungen müssen moderne Authentifizierung unterstützen. Dateifreigaben müssen in SharePoint Online oder Azure Files migriert werden. Drucker müssen über Universal Print verwaltet werden. Group Policies müssen durch Intune-Konfigurationsprofile ersetzt werden.

Für die meisten mittelständischen Unternehmen ist dieser Übergang ein mehrjähriger Prozess. Der pragmatische Weg führt über die hybride Phase, in der beide Systeme parallel betrieben werden, und die schrittweise Migration einzelner Workloads in die Cloud.

Von LDAP zu AD oder Entra ID

Unternehmen mit einer reinen LDAP-Umgebung, die Microsoft-Dienste einführen wollen, stehen vor der Entscheidung, ob sie AD on-premise aufbauen oder direkt auf Entra ID setzen. Wenn keine On-Premise-Windows-Server zu verwalten sind und die Endgeräte mit Intune verwaltet werden können, ist der direkte Weg zu Entra ID effizienter. Wenn On-Premise-Windows-Server weiterhin betrieben werden, ist der Aufbau eines lokalen AD mit Entra-Connect-Synchronisation der robustere Weg.

Sicherheitsaspekte der Verzeichnisdienste

Der Verzeichnisdienst ist eines der kritischsten Systeme in deiner Infrastruktur. Ein kompromittierter Verzeichnisdienst bedeutet, dass der Angreifer die Identitäten aller Benutzer kontrolliert und Zugang zu allen verbundenen Systemen hat.

Für Active Directory gelten die Härtungsmaßnahmen, die im Artikel zur AD-Absicherung beschrieben sind: Tiered Administration, LAPS, Kerberoasting-Schutz, NTLM-Einschränkung und regelmäßige Überprüfung der privilegierten Gruppen.

Für Entra ID sind Conditional Access Policies, PIM, Identity Protection und die regelmäßige Überprüfung der App-Registrierungen und Service Principals die wichtigsten Sicherheitsmaßnahmen. Besondere Aufmerksamkeit verdienen die Admin-Rollen: Global Administrator sollte maximal zwei bis drei Personen vorbehalten sein, und alle anderen administrativen Aufgaben sollten über spezialisierte Rollen (User Administrator, Exchange Administrator, Security Administrator) delegiert werden. Ein durchdachtes Privileged Access Management ist hier unerlässlich.

Für LDAP-Umgebungen sind die TLS-Verschlüsselung aller Verbindungen (LDAPS), starke Bind-Credentials, ACLs auf dem Directory und regelmäßige Backups die grundlegenden Sicherheitsmaßnahmen.

Entscheidungsmatrix

Die Wahl des Verzeichnisdienstes ist eine langfristige Architekturentscheidung. Hier eine Zusammenfassung der Entscheidungskriterien.

Wenn dein Unternehmen primär Windows-basiert ist, On-Premise-Server betreibt und Group Policies für die Geräteverwaltung benötigt, ist Active Directory mit Entra-Connect-Synchronisation die richtige Wahl.

Wenn dein Unternehmen primär Cloud-basiert ist, Microsoft 365 nutzt und Endgeräte über Intune verwaltet, ist Entra ID als primärer Verzeichnisdienst sinnvoll, ergänzt durch Entra Domain Services für Legacy-Anwendungen.

Wenn dein Unternehmen primär Linux-basiert ist und keine Microsoft-Produkte einsetzt, sind FreeIPA oder OpenLDAP die kosteneffizientesten Lösungen.

Wenn dein Unternehmen hybrid arbeitet, mit On-Premise-Servern und Cloud-Diensten, ist die Kombination aus AD und Entra ID über Entra Connect der Standard-Weg.

Unabhängig von der Wahl gilt: Dokumentiere deine Verzeichnisdienstarchitektur in deinem ISMS – in ISMS Lite lässt sich die gesamte Identitätsarchitektur mit Zugangsrichtlinien und Rezertifizierungszyklen zentral abbilden. Definiere klare Zuständigkeiten für die Administration, implementiere ein Monitoring für den Verzeichnisdienst und plane regelmäßige Rezertifizierungen der Berechtigungen. Der Verzeichnisdienst ist das Fundament deiner gesamten Zugangssteuerung, und dieses Fundament muss solide sein.

Weiterführende Artikel

• Active Directory absichern: Härtung, Tiering und Monitoring
• Berechtigungskonzept erstellen: Vom Rollenmodell bis zur Rezertifizierung
• Single Sign-On (SSO) einführen: SAML, OIDC und praktische Umsetzung
• User Lifecycle Management: Onboarding, Rollenänderung, Offboarding
• Service Accounts managen: Das vergessene Sicherheitsrisiko