Entra Domain Services | Wann Sie eine verwaltete Domäne wirklich brauchen und wann Sie sich die sparen können

Alt-Anwendung → braucht Kerberos oder LDAP → verwaltete Domäne → Ausstieg von Tag eins mitplanen

Ein lokales Active Directory macht zwei Dinge gleichzeitig, die eigentlich nichts miteinander zu tun haben. Wer das einmal getrennt betrachtet, versteht auf Anhieb, warum es in der Cloud kein Produkt gibt, das ein AD einfach ersetzt.

Das Erste ist die Identität. Das Verzeichnis weiß, wer wer ist, prüft Kennwörter und stellt die Tickets aus, mit denen sich Maschinen und Dienste im Netz gegenseitig vertrauen. Das Zweite ist die Verwaltung dieser Maschinen, über Computerkonten und Gruppenrichtlinien.

In der Cloud sind diese beiden Aufgaben auf verschiedene Produkte verteilt. Entra ID kümmert sich um Benutzer und authentifiziert sie mit Tokens gegen Web-Endpunkte. Die Geräteverwaltung läuft über Intune, bei Servern über Azure Arc und die Azure-Bordmittel.

Entra ID ist kein abgespecktes AD

Das ist der Satz, an dem die meisten Missverständnisse hängen. Entra ID kennt zwar Geräte, sonst würde Intune nicht funktionieren. Daran hängen aber bedingter Zugriff und Geräteverwaltung, keine Maschinenauthentifizierung über Kerberos und keine Gruppenrichtlinien.

Microsoft formuliert das in der eigenen Architekturdokumentation ungewöhnlich klar. AD DS ist für lokale Umgebungen gebaut, Entra ID für die Cloud, und eine Eins-zu-eins-Entsprechung zwischen beiden gibt es nicht. Es sind zwei getrennte Produkte für zwei verschiedene Welten, kein Nachfolger und Vorgänger.

Für die Anmeldung an Cloud-Diensten brauchen Sie damit kein AD mehr. Für klassischen Domänenbeitritt und LDAP-Abfragen schon.

Die Restmenge, um die es geht

Übrig bleibt alles, was noch die alten Protokolle spricht. Kerberos, NTLM, oder eine Anwendung, die eine LDAP-Anbindung braucht.

In der Praxis ist das meistens ein Branchenprogramm, das seit Jahren im eigenen Rechenzentrum läuft und jetzt nach Azure soll. Dann kommt der Punkt, an dem die Anwendung eine LDAP-Bindung gegen einen Domänencontroller machen will, oder der Server schlicht Mitglied einer Domäne sein muss, weil die Software sonst nicht startet.

Genau diese Restmenge braucht weiterhin eine echte Domäne. Daran führt kein Weg vorbei. Die Frage ist nur, wer sie betreibt.

Was Entra Domain Services ist

Eine verwaltete Domäne. Microsoft stellt zwei Windows-Server-Domänencontroller in Ihr virtuelles Netzwerk in Azure und kümmert sich um Aktualisierung, Sicherung und Verfügbarkeit. Auf die Maschinen selbst kommen Sie dafür nicht.

Aus Sicht Ihrer Server ist das eine ganz normale Domäne. Domänenbeitritt funktioniert, Kerberos und NTLM ebenfalls, LDAP gibt es und auf Wunsch auch verschlüsselt als LDAPS. Gruppenrichtlinien sind da, eigene Organisationseinheiten dürfen Sie anlegen, und das DNS für die Domäne bringt der Dienst mit.

Das größte Missverständnis

Man könnte annehmen, Entra Domain Services verlängere das bestehende AD in die Cloud. Gleiche Domäne, gleiche Objekte, gleiche Rechte. Genau das tut es nicht.

Was Sie bekommen, ist eine komplett neue Domäne in einem eigenen Wald mit eigenem Namensraum. Die Benutzer kommen dort nur als Kopien an und erhalten neue Sicherheitskennungen, weil der Namensraum für diese Kennungen ein anderer ist.

Eine Sache rettet dabei erstaunlich viel Arbeit. Die ursprüngliche lokale Kennung wandert in einem eigenen Attribut mit. Deshalb funktionieren Dateiberechtigungen auf mitgezogenen Dateiservern in aller Regel weiter, ohne dass Sie alles neu berechtigen müssen.

Was nicht mitkommt

• Computerkonten aus dem lokalen AD werden nicht übernommen. In der verwalteten Domäne sehen Sie nur die Maschinen, die dort selbst beigetreten sind.
• Ihre Struktur aus Organisationseinheiten kommt nicht mit. Es gibt vorgegebene Container, und darin dürfen Sie eigene anlegen.
• Gruppenrichtlinien werden nicht mitgezogen.
• Eine Vertrauensstellung zu Ihrem lokalen AD gibt es im Standard nicht. Einrichten lässt sie sich, aber erst ab der mittleren Stufe.
• Das Schema lässt sich nicht erweitern wie in einem selbst betriebenen AD.

Sie sind dort nicht Domänen-Administrator

Sie landen in einer Gruppe, die eigene Organisationseinheiten anlegen und Gruppenrichtlinien verwalten darf, und damit hat es sich weitgehend. Auf die Domänencontroller selbst kommen Sie nicht, weder per Remotedesktop noch über eine Konsole.

Verwaltet wird ausschließlich von einem Mitgliedsserver aus mit den gewohnten Verwaltungswerkzeugen. Daran merkt man am deutlichsten, dass das kein AD ist, das einem gehört.

Die Benutzer kommen über eine automatische Synchronisierung direkt aus Entra ID. Das läuft nur in eine Richtung. Objekte, die von dort kommen, sind in der verwalteten Domäne schreibgeschützt. Änderungen wandern nie zurück.

In hybriden Umgebungen wird die Kette entsprechend länger.

Lokales AD  →  Entra Connect  →  Entra ID  →  verwaltete Domäne
                                                    (nur in diese Richtung)

Die Voraussetzung, an der es tatsächlich scheitert

Hier liegt der Punkt, der Projekte kippt, und er wird gern zu spät entdeckt.

Entra ID hält im Normalbetrieb nicht die Art von Kennwort-Prüfsummen vor, die NTLM und Kerberos brauchen. Klartextkennwörter speichert es aus gutem Grund ohnehin nicht, und aus den vorhandenen Anmeldedaten lassen sich diese Prüfsummen nicht nachträglich errechnen. Sie müssen erst erzeugt und dorthin übertragen werden.

Was das praktisch heißt, hängt daran, woher Ihre Konten kommen.

• Reine Cloud-Konten müssen ihr Kennwort einmal ändern, bevor die nötigen Prüfsummen überhaupt entstehen. Vorher wird das Konto gar nicht erst in die verwaltete Domäne übernommen. Bei ein paar hundert Benutzern ist das kein Detail mehr, sondern ein eigener Projektschritt mit Ankündigung.
• Aus dem lokalen AD synchronisierte Konten brauchen eine zusätzliche Konfiguration in Entra Connect. Im Standard überträgt das Werkzeug diese alten Prüfsummen nicht.
• Entra Cloud Sync reicht nicht. Das schlankere Werkzeug wird für diesen Fall nicht unterstützt. Es muss die vollständige Entra-Connect-Synchronisierung sein. Wer gerade dabei ist, in die andere Richtung zu vereinfachen, sollte das wissen, bevor er anfängt.

Und noch eine Kleinigkeit mit großer Wirkung. Löschen Sie die verwaltete Domäne, sind die dort gespeicherten Prüfsummen ebenfalls weg. Legen Sie später eine neue an, müssen Sie das Ganze noch einmal einrichten. Vorher beigetretene Maschinen und Benutzer können sich bis dahin nicht anmelden.

Was beim Anlegen festgelegt wird und sich nicht mehr ändern lässt

Drei Entscheidungen fallen ganz am Anfang und sind später teuer.

1. Es gibt genau eine verwaltete Domäne pro Mandant. Nicht eine pro Abteilung, nicht eine zum Testen daneben.
2. Sie hängt an der Region und dem virtuellen Netzwerk, in dem Sie sie anlegen. Nachträglich woanders hinschieben geht nicht. Es empfiehlt sich, dieses Netzwerk als Mittelpunkt zu planen und weitere Netze über Kopplung anzubinden.
3. Der Namensraum wird beim Anlegen festgelegt.

In weitere Regionen ausweiten geht über zusätzliche Replikate, insgesamt bis zu fünf. Das setzt allerdings mindestens die mittlere Stufe voraus, und jedes Replikat wird einzeln abgerechnet.

Die Stufen

Die Stufen unterscheiden sich nicht in erster Linie im Funktionsumfang, sondern in Kapazität, Durchsatz und darin, wie oft gesichert wird.

Vertrauensstellungen gibt es ab Enterprise, ebenso zusätzliche Replikate. Wechseln können Sie in beide Richtungen, allerdings nicht auf eine Stufe herunter, deren Höchstzahl an Vertrauensstellungen Sie bereits überschritten haben.

Zu den Kosten nur die Größenordnung, weil Preise sich ändern und an Region und Währung hängen. Die kleinste Stufe liegt im niedrigen dreistelligen Bereich pro Monat, die größte grob beim Zehnfachen. Abgerechnet wird stundengenau nach Verbrauch.

Einen Pausenknopf gibt es nicht. Anders als bei einer virtuellen Maschine können Sie eine verwaltete Domäne nicht anhalten. Entweder sie läuft und kostet, oder Sie löschen sie ganz. Wer sich am Freitag eine Testumgebung baut und am Montag weitermacht, zahlt das Wochenende mit.

Zwei Dinge, die regelmäßig übersehen werden

Configuration Manager läuft dort nicht. Wenn Sie Ihre Anwendungsserver damit verwalten, ist das ein Ausschlusskriterium. Der Betrieb von Configuration Manager in einer verwalteten Domäne wird nicht unterstützt. Dann brauchen Sie eigene Domänencontroller.

Die Anmeldung sollte über den Benutzerprinzipalnamen laufen. Der klassische kurze Anmeldename wird aus einem anderen Feld abgeleitet und teilweise automatisch erzeugt, etwa wenn er zu lang wäre oder doppelt vorkäme. Er kann sich also von dem unterscheiden, was Ihre Leute erwarten. Der lange Name in Mailadressform ist der verlässliche Weg.

Wann Sie es brauchen und wann nicht

Die Entscheidung hat drei Ausgänge, und der häufigste ist der, an den zuerst niemand denkt.

Wenn Ihre Anwendung moderne Authentifizierung kann, nehmen Sie Entra ID und lassen Entra Domain Services komplett bleiben. Darauf läuft es in der Praxis am häufigsten hinaus.

Wenn Sie die volle Kontrolle brauchen, eine gewachsene Struktur mit mehreren Domänen haben, das Schema erweitern müssen oder eine bestehende Vertrauensstellung erhalten wollen, kommen Sie um eigene Domänencontroller auf virtuellen Maschinen nicht herum. Das ist deutlich mehr Arbeit, dafür entscheiden Sie alles selbst.

Entra Domain Services liegt genau dazwischen. Bestandsanwendungen in Azure, die eine Domäne wollen, und Sie haben keine Lust, dafür selbst Domänencontroller zu betreiben.

Bevor Sie anfangen, lohnt eine ehrliche Prüfung, ob es wirklich eine Domäne sein muss. Für einiges, was früher zwingend eine gebraucht hat, gibt es inzwischen Wege ohne. Am häufigsten sieht man das bei Dateiablagen. Wenn bei Ihnen eine verwaltete Domäne läuft, die im Grunde nur eine Dateifreigabe bedient, lohnt der Blick, ob es sie überhaupt noch braucht.

Den Ausstieg von Anfang an mitplanen

Das ist kein guter Rat von außen, sondern die Linie des Herstellers selbst. Im eigenen Migrationsleitfaden steht die verwaltete Domäne ausdrücklich als Zwischenschritt.

1. Verwaltete Domäne bereitstellen
2. Alt-Anwendungen auf Azure-Maschinen ziehen, die dieser Domäne beitreten
3. Von außen erreichbar machen, etwa über einen Anwendungsproxy
4. Domäne wieder abbauen, sobald die Alt-Anwendungen wegfallen

Schritt vier ist der, der in der Praxis nie stattfindet. Das Ding läuft, es tut, was es soll, und irgendwann weiß niemand mehr, für welche Anwendung es einmal aufgesetzt wurde und wer zuständig ist.

Dagegen hilft eine Maßnahme, die zehn Minuten kostet. Schreiben Sie vom ersten Tag an auf, welche Anwendung warum in dieser Domäne liegt. Daraus wird eine Liste, die Sie einmal im Jahr durchgehen. Sie werden sehen, dass die Notwendigkeit von ganz allein weniger wird.

Selbstprüfung

1. Welche zwei Aufgaben eines lokalen AD sind in der Cloud auf verschiedene Produkte verteilt?
2. Warum funktionieren Dateiberechtigungen nach dem Umzug meistens weiter, obwohl die Benutzer neue Sicherheitskennungen bekommen?
3. Was muss passieren, bevor ein reines Cloud-Konto überhaupt in der verwalteten Domäne ankommt?
4. Welche drei Entscheidungen lassen sich nach dem Anlegen nicht mehr ändern?
5. Welcher Schritt im Migrationsleitfaden des Herstellers wird in der Praxis fast nie ausgeführt?