Microsoft Entra Domain Services einfach erklärt: Legacy-Apps in Azure ohne eigene Domain-Controller (KI-Synchronfassung)

Sie verschieben eine alte Unternehmensanwendung vom Server im Büro auf eine Azure-VM. Die App läuft jetzt in der Cloud, verlangt aber weiterhin nach einer Windows-Domäne. Sie will beitreten, Personen per LDAP suchen, Benutzer per Kerberos anmelden und Gruppenrichtlinien anwenden. Viele nehmen an, Entra ID ersetze alle Aufgaben von Active Directory. Das stimmt nicht.

Dieser Artikel zeigt, wo Entra ID, Active Directory und Microsoft Entra Domain Services jeweils hingehören, wann der verwaltete Domänendienst passt und welche Grenzen er hat. Außerdem erfahren Sie, warum Identitätsinformationen nur in eine Richtung fließen und wie das Ihre Verwaltung verändert.

Warum Entra ID allein nicht jede Legacy-App ausführen kann

Entra ID ist der Empfangstresen für Ihre Cloud-Dienste. Es weiß, wer Sie sind, prüft die Anmeldung und entscheidet, ob Sie auf Microsoft 365, Teams, SharePoint oder eine Business-App in der Cloud zugreifen dürfen. Dank Single Sign-On melden Sie sich einmal an und wechseln zwischen Diensten, ohne das Passwort erneut einzugeben. Zusätzlich kann Entra ID eine Multifaktor-Authentifizierung verlangen, das verwendete Gerät prüfen sowie Standort und Zugriffsregeln des Unternehmens berücksichtigen.

Für moderne Apps funktioniert dieses Muster hervorragend. Die App leitet Sie zu Entra ID weiter, Sie melden sich an und bestätigen vielleicht eine Aufforderung auf dem Handy. Danach schickt Entra ID der App im Hintergrund eine sichere Anmeldebestätigung, und die App gewährt den Zugriff. Ein Domain-Beitritt ist dafür nicht nötig, alte Windows-Server sind nicht beteiligt, und die App muss kein klassisches Firmenverzeichnis durchsuchen.

Ältere Anwendungen stammen aus einer anderen Welt. Denken Sie an eine Finanz-App, die seit Jahren auf einem Windows-Server läuft, mit Anmeldungen von domänenverbundenen PCs. Sie sucht Mitarbeiterdaten per LDAP und nutzt womöglich Kerberos, ein älteres Windows-Anmeldeverfahren, bei dem sich Systeme gegenseitig vertrauen. Möglicherweise stützt sie sich auch auf Gruppenrichtlinien, also Unternehmensregeln zur Steuerung von Windows-Computern. Solche Apps können eine moderne Cloud-Anmeldenachricht nicht lesen. Sie erwarten, im Netzwerk eine klassische Windows-Domäne zu finden. Gelingt das nicht, melden sie keine Benutzer an, finden ihr Dienstkonto nicht oder starten gar nicht erst.

Es ist wie bei einer neuen Steckdose, in die der alte Stecker nicht passt: Der Strom ist da, aber die Verbindung stimmt nicht.

Die klassischen Wege: VPN oder eigene Domain-Controller in Azure

Bevor es einen verwalteten Dienst gab, hatten Unternehmen zwei Optionen, wenn sie eine solche App nach Azure verschieben wollten.

Option 1: Active Directory im Büro behalten und per VPN anbinden

Die App in Azure sendet ihre Domänenanfragen über einen privaten Netzwerktunnel ins Büro. Das kann funktionieren, doch die Cloud-App hängt nun von der Netzwerkverbindung und dem lokalen Domain-Controller ab. Gibt es ein Problem mit der Verbindung, hat auch die App ein Problem.

Option 2: Eigene virtuelle Domain-Controller in Azure betreiben

Ein Domain-Controller ist der Server, der die traditionelle Active-Directory-Domäne betreibt und Verzeichnis, Anmeldungen und weitere Domänenaufgaben verwaltet. Läuft er als VM in Azure, besitzt Ihr Team mehr Server. Jemand muss sie patchen und überwachen. Dazu kommen Backups, Wiederherstellungspläne, ein Konzept für die Synchronisierung der Controller und der Schutz der mächtigen Administrator-Konten. Für manche Unternehmen ist diese Kontrolle sinnvoll. Für andere ist es zusätzliche Arbeit, nur um eine ältere App zufriedenzustellen.

Die Lücke ist schmal, aber real: Eine App lebt in Azure und spricht noch die alte Active-Directory-Sprache.

Was Microsoft Entra Domain Services ist

Microsoft Entra Domain Services ist eine verwaltete Windows-Domäne, die in Ihrem Azure-Netzwerk läuft. Die Domain-Controller arbeiten im Hintergrund und werden vollständig von Microsoft betrieben. Ihre Azure-VMs und älteren Apps nutzen die gewohnten Domänendienste.

Im Bild eines Bürogebäudes ist Entra ID die Rezeption, die bei der Anmeldung in Microsoft 365 oder anderen Cloud-Apps prüft, wer Sie sind. Entra Domain Services ist das verschlossene Büro dahinter: ein Verzeichnis im alten Stil, das die Sprache älterer Systeme versteht und ihre Anfragen beantwortet.

Sie bauen die Domain-Controller nicht selbst, melden sich nicht per Remote-Desktop darauf an, entscheiden nicht über deren Anzahl, patchen kein Windows und verwalten keine Verbindung zwischen ihnen. Ihre Aufgabe ist es, die richtigen Azure-VMs und Apps mit der verwalteten Domäne zu verbinden. Danach stehen Ihnen vertraute Funktionen zur Verfügung:

• Windows-VMs können der Domäne beitreten.
• Ältere Apps können per LDAP Personen, Gruppen und Verzeichnisdetails abrufen.
• Kerberos steht bereit, die Anmeldemethode, die ältere Geschäftsanwendungen oft erwarten.
• NTLM steht für Apps zur Verfügung, die diese ältere Windows-Anmeldemethode noch benötigen.
• DNS hilft Systemen, Server über Namen statt über Zahlenfolgen zu finden.
• Gruppenrichtlinien wenden bestimmte Windows-Einstellungen auf Computer und Benutzer der verwalteten Domäne an.

Man kann sich den Dienst als Dolmetscherbüro vorstellen. Die App fragt in alter Windows-Sprache, wer ein Benutzer ist, ob ein Server einem anderen vertrauen darf, wo die Datenbank liegt oder welche Einstellung ein Computer nutzen soll. Entra Domain Services versteht diese Fragen und liefert die erwartete Antwort.

Identitäten, Passwörter und Netzwerk: so funktioniert die Einbahnstraße

Entra Domain Services ist keine zweite Hauptliste Ihrer Mitarbeiter. Der primäre Identitätsdatensatz bleibt in Entra ID. Benutzer und Gruppen werden in die verwaltete Domäne kopiert, damit ältere Apps sie in verständlicher Form nutzen können. Hat Ihr Unternehmen zusätzlich ein lokales Active Directory, gelangen die Identitäten von dort möglicherweise zuerst nach Entra ID und dann in Domain Services.

Identitätsdetails fließen also in Entra Domain Services hinein, aber nicht zurück. Die Konsequenz:

• Stammt ein Benutzer aus Entra ID, verwalten Sie ihn dort.
• Stammt er aus dem lokalen Active Directory, verwalten Sie ihn dort.
• Die verwaltete Domäne ist kein Ort, an dem der Haupteintrag eines Mitarbeiters bearbeitet wird.

So wird die verwaltete Domäne nicht zu einem zweiten Aktenschrank mit abweichenden Versionen derselben Person.

Der Stolperstein Passwort

Cloud-Anmeldung und ältere Windows-Anmeldung verarbeiten Passwörter im Hintergrund unterschiedlich. Damit Kerberos und NTLM funktionieren, benötigt Domain Services eine geschützte Form der Passwortdaten, die diese Methoden unterstützt. Microsoft speichert dabei kein Passwort im Klartext. Für Cloud-Benutzer heißt das oft: Sie müssen ihr Passwort ändern, nachdem Domain Services aktiviert wurde. Erst diese Änderung erzeugt die geschützte Form, die die verwaltete Domäne braucht.

Bis dahin kann sich der Benutzer zwar problemlos bei Microsoft 365 anmelden, scheitert aber an der Domäne im alten Stil. Das verwirrt zunächst, denn das Konto existiert und das Passwort funktioniert. Es fehlt nicht das Benutzerkonto, sondern die geschützte Passwortform für die älteren Anmeldemethoden.

Der Rahmen: ein privates Azure-Netzwerk

Domain Services läuft innerhalb eines virtuellen Azure-Netzwerks, oft VNet genannt. Ihre Azure-VMs brauchen Netzwerkzugriff auf dieses VNet und müssen die DNS-Einstellungen der verwalteten Domäne verwenden, um sie zu finden. Es ist kein öffentliches Verzeichnis, das jedes Gerät im Internet erreichen kann, sondern ein privater Domänendienst für Workloads im richtigen Azure-Netzwerk.

Entra ID, Active Directory und Domain Services im Vergleich

Die Namen klingen ähnlich, doch es sind keine Versionen desselben Produkts. Jedes deckt einen anderen Teil des Identitätsbildes ab.

Entra ID: Cloud-Identität

Entra ID prüft Anmeldungen bei Microsoft 365, Teams, SharePoint und modernen Geschäftsanwendungen und steuert den Zugriff. Dazu gehören Multifaktor-Authentifizierung und Zugriffsregeln, etwa eine strengere Prüfung auf einem unbekannten Gerät. Moderne Apps müssen nicht im selben Netzwerk liegen, weil sie webbasierte Anmeldemethoden nutzen.

Active Directory: die eigene Windows-Domäne

Das klassische Active Directory betreiben viele Unternehmen in Büros, Rechenzentren oder Serverräumen. Das Unternehmen besitzt die Domain-Controller, legt ihre Einrichtung fest und verwaltet alles von Grund auf. Es steuert Windows-PCs, unterstützt lokale Server und stellt die älteren Anmeldemethoden bereit. Diese Kontrolle bringt Verantwortung mit sich: Das IT-Team betreibt Domäne und Server und entscheidet über die Funktionsweise des Verzeichnisses.

Entra Domain Services: die Brücke dazwischen

Entra Domain Services liegt zwischen beiden Welten. Azure-Workloads erhalten eine verwaltete Windows-Domäne, wenn sie älteres Active-Directory-Verhalten brauchen, und Microsoft übernimmt den Betrieb der Domain-Controller. Sie nutzen die Domäne für Azure-VMs und ältere Apps, ohne die komplette Aufgabe einer eigenen Active-Directory-Domäne zu stemmen.

Als Aktenschrank-Bild: Entra ID enthält die Haupteinträge der Mitarbeiter für die Cloud-Arbeit. Domain Services stellt älteren Azure-Apps eine kompatible Kopie bereit, in der sie Benutzer, Gruppen und Anmeldedaten im vertrauten Format finden. Die App muss nicht neu gebaut werden, nur weil sie nach Azure umgezogen ist.

Reine Cloud-Unternehmen und Hybrid-Unternehmen

Ein Unternehmen, das nie lokale Domain-Controller betrieben hat, muss keine lokale Domäne aufbauen, nur weil eine ältere Windows-App auf Azure-VMs läuft. Es nutzt Entra Domain Services für die VMs mit Domänenbedarf, und der Rest bleibt bei Entra ID.

Ein hybrides Unternehmen betreibt dagegen möglicherweise schon Active Directory im Büro, dessen Benutzer und Gruppen mit Entra ID synchronisiert werden. Von dort erscheinen sie in Entra Domain Services für Azure-Workloads. Der Ablauf lautet: lokales Active Directory, dann Entra ID, dann die kompatible Kopie in Domain Services. Das ersetzt die lokale Domäne nicht, die weiterhin für lokale PCs, Server, Fabriksysteme oder vor Ort verbleibende Anwendungen nötig sein kann. Und Entra ID wird dadurch kein vollständiges Active Directory.

Wann Entra Domain Services passt und wann nicht

Beginnen Sie mit der Anwendung, nicht mit dem Produkt.

Typische Einsatzszenarien

• Legacy-Apps mit LDAP: Eine ältere App, die per LDAP Benutzer und Kennwörter prüft, zieht nach Azure um. Das ist besonders wertvoll, wenn die App noch funktioniert, gebraucht wird und eine Neuentwicklung zu viel Zeit oder Geld kosten würde.
• Azure-VMs als Domänencomputer: Mitarbeiter melden sich mit dem Arbeitskonto an, Dienstkonten verbinden Anwendungen mit Datenbanken, und Gruppenrichtlinien wenden Unternehmenseinstellungen an.
• Remote Desktop Services: Gemeinsam genutzte Windows-Desktops oder Apps in Azure brauchen meist eine Domäne für Anmeldung und Computerverwaltung, ohne dass virtuelle Domain-Controller von Grund auf entstehen müssen.
• Mehrschichtige Anwendungen: Webserver, App-Server und Datenbank vertrauen sich über Windows-Dienstkonten. Domain Services sorgt dafür, dass dieses Vertrauen nach dem Umzug weiter funktioniert.

Wann Sie etwas anderes wählen sollten

Wählen Sie Domain Services nicht nur, weil Sie Azure nutzen. Eine neue Cloud-App sollte sich direkt über Entra ID anmelden. Sie profitiert dann von Cloud-Zugriffsregeln und Multifaktor-Authentifizierung, und das ist der sauberere Weg für neue Software. Domain Services helfen einer App, die die alte Sprache spricht, sind aber kein Grund, neuen Apps diese Sprache beizubringen.

Dazu kommen feste Grenzen:

• Die App braucht LDAP-Schreibzugriff.
• Die App muss das Active-Directory-Schema ändern, also die Felder, die festlegen, was das Verzeichnis speichern kann.
• Ihr Team benötigt direkten Zugriff auf Domain-Controller oder Domain-Administrator-Rechte.
• Sie wollen ein kompliziertes Verzeichnisdesign nach eigenen Vorstellungen aufbauen und betreiben.

In diesen Fällen ist es besser, Active Directory selbst zu betreiben, lokal oder auf virtuellen Maschinen in Azure.

Stolpersteine und Kompromisse beim verwalteten Dienst

Der verwaltete Ansatz spart Arbeit, verändert aber, was Ihr IT-Team steuern kann. Microsoft betreibt die Domain-Controller, hält sie synchron, spielt Patches ein und kümmert sich um die Verfügbarkeit. Sie müssen weder Standorte planen noch einen Controller nach einem Serverausfall wiederherstellen. Im Gegenzug gibt es keinen Remote-Desktop-Zugang zu den Controllern und keine Domain- oder Unternehmensadministrator-Rechte.

Stattdessen stellt Microsoft eine eigene Administratorengruppe für Domain Services bereit. Fügen Sie die zuständigen Personen dort hinzu und nutzen Sie eine mit der Domäne verbundene virtuelle Verwaltungsmaschine. Von dort aus verwalten Sie mit bekannten Active-Directory-Tools die freigegebenen Bereiche:

• eigene Organisationseinheiten (OUs), vergleichbar mit Ordnern für Computer oder Dienstkonten,
• DNS-Einträge,
• Gruppenrichtlinien für unterstützte Einstellungen,
• die Computer, die der Domäne beitreten.

Die Einschränkungen sind gewollt: Sie können keine weiteren Domain-Controller hinzufügen, das Schema nicht ändern und die verwaltete Domäne nicht als Quelle für Änderungen zurück nach Entra ID nutzen.

Der häufigste Fehler

Jemand sieht einen Benutzer in der verwalteten Domäne und ändert ihn dort, in der Annahme, die Änderung bleibe bestehen. Sie wird aber nie zum Unternehmensdatensatz in Entra ID oder im lokalen Active Directory. Pflegen Sie Benutzer und Gruppen deshalb immer im Quellverzeichnis. Das ist bei reinen Cloud-Unternehmen Entra ID, bei Hybrid-Unternehmen das lokale Active Directory.

Halten Sie die verwaltete Domäne außerdem schlank. Sie sollte nur die benötigten Workloads unterstützen und kein allgemeines Unternehmensverzeichnis werden. Begrenzen Sie den Netzwerkzugriff, schützen Sie die Verwaltungsmaschine und vergeben Sie Admin-Zugriff nur an Personen, die ihn brauchen. Sie entscheiden sich für einen Dienst mit Leitplanken, die Arbeit abnehmen, aber Änderungen an den von Microsoft verwalteten Bereichen verhindern.

Ein Migrationsbeispiel aus der Praxis

Ein Finanzunternehmen betreibt eine alte Anwendung auf Servern im eigenen Büro. Sie nutzt LDAP, verwendet Kerberos für die Anmeldung, und ihr Server authentifiziert sich per Dienstkonto an der Finanzdatenbank. Anwendung und Datenbank sollen auf Azure-VMs umziehen.

Die erste Option wäre die VPN-Anbindung an die Bürodomäne, doch dann hängt die Azure-App täglich von dieser Verbindung und den lokalen Domain-Controllern ab. Die zweite Option wären neue virtuelle Domain-Controller in Azure. Dann bliebe mehr Datenverkehr in Azure, aber das IT-Team müsste zusätzliche Windows-Server patchen, überwachen, sichern und wiederherstellen.

Das Team wählt einen dritten Weg. Benutzer und Gruppen werden bereits mit Entra ID synchronisiert, also aktiviert es Entra Domain Services und verbindet das virtuelle Azure-Netzwerk.

Praktische Takeaways

• Fragen Sie zuerst: Kann die Workload moderne Anmeldung über Entra ID, oder braucht sie die alte Active-Directory-Sprache wie LDAP, Kerberos, NTLM oder Gruppenrichtlinien?
• Neue Cloud-Apps gehören direkt an Entra ID, mit Single Sign-On, Multifaktor-Authentifizierung und Zugriffsregeln.
• Für Legacy-Workloads in Azure, die Domänenverhalten brauchen, aber keine volle Domänenkontrolle, passt Entra Domain Services gut.
• Prüfen Sie die Ausschlusskriterien: LDAP-Schreibzugriff, Schemaänderungen, Zugriff auf Domain-Controller oder Domain-Administrator-Rechte sprechen für ein selbst betriebenes Active Directory.
• Verwalten Sie Benutzer und Gruppen immer im Quellverzeichnis, nie in der verwalteten Domäne. Identitätsdaten fließen nur in eine Richtung.
• Planen Sie nach der Aktivierung Passwortänderungen für Cloud-Benutzer ein, damit die geschützte Passwortform für Kerberos und NTLM entsteht.
• Stellen Sie sicher, dass VMs Zugriff auf das richtige VNet haben und die DNS-Einstellungen der verwalteten Domäne nutzen.
• Begrenzen Sie Netzwerkzugriff und Admin-Rechte, und schützen Sie die Verwaltungsmaschine.

Fazit

Entra ID, Active Directory und Entra Domain Services ergänzen sich, sie ersetzen sich nicht. Entra ID regelt moderne Cloud-Anmeldungen, Active Directory ist die Windows-Domäne in Ihrer eigenen Verantwortung, und Entra Domain Services bedient Azure-Legacy-Workloads, die noch eine Windows-Domäne brauchen. Dabei müssen Sie keine Domain-Controller betreiben. Der Preis dafür ist ein Stück weniger Kontrolle. Wer das akzeptiert und die Einbahnstraße der Identitäten beachtet, kann ältere Anwendungen nach Azure bringen, ohne sie neu zu schreiben.