Microsoft Azure AD Domain Services: Verwaltete Domänendienste für kleine Unternehmen in Berlin

Microsoft Azure Active Directory Domain Services (Azure ADDS, jetzt Teil von Microsoft Entra Domain Services) bietet verwaltete Active Directory Domain Services in Azure ohne Domänencontroller-VMs. Für kleine Unternehmen in Berlin mit Legacy-Windows-Anwendungen, die Kerberos-Authentifizierung, LDAP-Verzeichnisabfragen, NTLM-Authentifizierung oder Domänen-Computerrichtlinien benötigen, bietet Azure ADDS AD-Kompatibilität ohne den betrieblichen Aufwand der Verwaltung lokaler oder IaaS-Domänencontroller.

Welches Problem Azure AD Domain Services löst

Pures Azure AD (jetzt Microsoft Entra ID) verwendet moderne Authentifizierungsprotokolle: OAuth 2.0, OpenID Connect und SAML. Diese Protokolle funktionieren perfekt für Microsoft 365, Cloud-native SaaS-Anwendungen und moderne Geschäftsanwendungen. Sie funktionieren nicht für Anwendungen, die Legacy-AD-Protokolle benötigen: Kerberos-Tickets für Windows-Dateifreigaben, LDAP-Abfragen für Verzeichnissuchen, NTLM-Authentifizierung für ältere Webanwendungen oder Gruppenrichtlinienobjekte für die Windows-Computerkonfiguration.

Azure ADDS erstellt eine verwaltete Domäne in Azure, die diese Legacy-Protokolle unterstützt, während Identitäten aus Microsoft Entra ID synchronisiert werden. Benutzer können sich gegen die Azure ADDS-Domäne mit ihren vorhandenen Entra ID-Anmeldeinformationen authentifizieren. Das bedeutet, dass ein kleines Berliner Unternehmen seine lokale Serverinfrastruktur zu Azure IaaS migrieren, diese VMs mit Azure ADDS verbinden und Gruppenrichtlinien anwenden kann, ohne Domänencontroller-VMs, Patching, Replikation und Backup verwalten zu müssen.

Architektur: Wie Azure ADDS funktioniert

Wenn Sie Azure ADDS für Ihren Entra ID-Mandanten aktivieren, stellt Microsoft zwei verwaltete Domänencontroller-Replikate in Ihrer gewählten Azure-Region bereit (Frankfurt für europäische Bereitstellungen). Diese Domänencontroller sind vollständig verwaltet — Microsoft übernimmt OS-Patching, Backup, Replikation und Verfügbarkeit. Sie können sich nicht per RDP in die verwalteten Domänencontroller einloggen oder Software darauf installieren. Administrativer Zugriff auf die Domäne wird über LDAP, Gruppenrichtlinie und die Gruppe „AAD DC Administrators“ bereitgestellt.

Die Identitätssynchronisierung verläuft in einer Richtung: von Entra ID zu Azure ADDS, nicht umgekehrt. Benutzerkonten, Gruppenmitgliedschaften und Passwort-Hashes werden aus Entra ID synchronisiert. Änderungen, die direkt in Azure ADDS vorgenommen werden, werden nicht an Entra ID zurückgegeben. Dieses einseitige Synchronisierungsmodell behält Entra ID als autoritären Identitätsspeicher bei und bietet gleichzeitig AD-Protokollkompatibilität für Workloads, die diese benötigen.

Die Passwort-Hash-Synchronisierung muss aktiviert sein, damit Azure ADDS-Benutzer sich gegen Kerberos authentifizieren können. Benutzer, die sich nur über moderne Protokolle gegen Entra ID authentifizieren, verfügen über einen anderen Credential-Hash als für Kerberos erforderlich. Wenn die Passwort-Hash-Synchronisierung aktiviert ist (für Azure ADDS erforderlich), werden sowohl moderne Protokoll-Hashes als auch Kerberos-kompatible NTLM/Kerberos-Hashes mit Azure ADDS synchronisiert. Dies ist eine wichtige architektonische Überlegung: Die Aktivierung der Passwort-Hash-Synchronisierung bedeutet, dass Credential-Hash-Daten in Azure gespeichert werden, was einige Organisationen aus Datensouveränitätsperspektive bewerten müssen.

Domänen-Mitglieds-VMs und Gruppenrichtlinie

Azure IaaS-VMs können der verwalteten Azure ADDS-Domäne beitreten, genau wie physische Maschinen einer lokalen Domäne beitreten. Nach dem Beitritt erhalten die VMs Gruppenrichtlinien von Azure ADDS, können Benutzer mit Kerberos authentifizieren und können auf domänenbeigetretene Ressourcen mit der integrierten Windows-Authentifizierung zugreifen. Für Berliner Unternehmen, die Legacy-Windows-Anwendungen (ERP-Systeme, Geschäftsanwendungen, die Windows-Authentifizierung erfordern, RDS-Sitzungshosts) zu Azure IaaS migrieren, ermöglicht Azure ADDS die Migration ohne Refactoring der Anwendungen zur Verwendung moderner Authentifizierung.

Gruppenrichtlinienobjekte können erstellt und mit der Azure ADDS-Domäne verknüpft werden. Benutzerdefinierte OUs können zur Segmentierung von Computerkonten und Anwendung unterschiedlicher GPO-Konfigurationen auf verschiedene Workload-Gruppen erstellt werden. Die integrierte OU „AADDC Computers“ empfängt standardmäßig alle domänenbeigetretenen Maschinen. Best Practice ist es, Maschinen in benutzerdefinierte OUs zu verschieben und gezielte GPOs anzuwenden, anstatt die integrierte OU-Struktur zu ändern.

LDAP und Kerberos für Anwendungen

Anwendungen, die LDAP für Verzeichnissuchen verwenden (lokale Webanwendungen, Überwachungstools, ältere SaaS-Konnektoren), können für Abfragen an Azure ADDS über Secure LDAP (LDAPS) auf Port 636 konfiguriert werden. Azure ADDS unterstützt sowohl Standard-LDAP als auch LDAPS; Microsoft empfiehlt LDAPS für alle Produktionsanwendungen. Die LDAPS-Konfiguration erfordert die Erstellung eines Zertifikats und seinen Upload zu Azure ADDS — Azure ADDS verwaltet den Zertifikatslebenszyklus für die verwalteten Domänencontroller, sobald das Zertifikat bereitgestellt wurde.

Kerberos-basiertes Single Sign-On für IIS-gehostete Anwendungen, lokales SharePoint oder andere Kerberos-bewusste Dienste funktioniert gegen Azure ADDS, wenn die Anwendungsserver domänenbeigetreten sind. Benutzer authentifizieren sich mit ihren Entra ID-Anmeldeinformationen (die mit Azure ADDS gespiegelt werden) und erhalten Kerberos-Tickets für den Dienstzugriff ohne zusätzliche Credential-Abfragen. Dies bietet eine nahtlose Authentifizierungserfahrung für Legacy-Anwendungen, während die Identitätsverwaltung in Entra ID verbleibt.

Azure ADDS vs. Entra ID: Wann was verwenden

Azure ADDS ist geeignet, wenn Sie Workloads haben, die speziell Legacy-AD-Protokolle benötigen und nicht für moderne Authentifizierung refaktoriert werden können. Dazu gehören: Lift-and-Shift lokaler AD-abhängiger Anwendungen zu Azure IaaS, Unterstützung von Azure Virtual Desktop-Sitzungshosts, die Domänenbeitritt für Anwendungskompatibilität benötigen, Bereitstellung von LDAP-Verzeichnisdiensten für lokale Anwendungen, die zu Azure migriert wurden, ohne Codeänderungen, und Ausführen von RDS-Workloads auf Azure IaaS, die domänenbeigetretene Sitzungshosts erfordern.

Entra ID deckt alle modernen Authentifizierungsszenarien ab und sollte die Identitätsgrundlage für alle neue Entwicklung und Cloud-First-Workloads sein. Die Unterscheidung ist kein Entweder-oder: Die meisten kleinen Berliner Unternehmen, die Azure ADDS einsetzen, verwenden es neben Entra ID, wobei Entra ID der primäre Identitätsspeicher ist und Azure ADDS Rückwärtskompatibilität für eine bestimmte Teilmenge von Legacy-Workloads bereitstellt. Wenn Legacy-Anwendungen modernisiert oder ersetzt werden, schrumpft der Umfang der Azure ADDS-Nutzung natürlich.

Kosten und Lizenzierung für Berliner KMU

Azure ADDS wird stündlich basierend auf der SKU (Standard oder Enterprise) und der Azure-Region berechnet. Für Bereitstellungen in der Frankfurt-Region kostet die Standard-SKU ungefähr 0,15–0,20 EUR pro Stunde, was für eine dauerhaft laufende Instanz insgesamt etwa 110–150 EUR pro Monat entspricht. Die Enterprise-SKU fügt Funktionen wie Forest Trusts und differenzierte Passwortrichtlinien hinzu. Für kleine Berliner Unternehmen sind die Kosten gerechtfertigt, wenn die Alternative die Wartung von einer oder zwei IaaS-Domänencontroller-VMs mit den damit verbundenen Compute-, Speicher- und Betriebskosten wäre. Azure ADDS eliminiert den DC-Verwaltungsaufwand vollständig und kostet typischerweise weniger als zwei immer laufende Domänencontroller-VMs.