Von Active Directory zu Entra ID
Identitätswechsel
Veröffentlicht in Ausgabe 07/2026 - PRAXIS
Wer heute ein Active Directory betreibt und Microsoft 365 oder Azure nutzt, hat mit hoher Wahrscheinlichkeit bereits Entra Connect installiert. Benutzer synchronisieren, Password Hash Sync aktivieren, fertig – so verlaufen viele Cloudmigrationen. Hand aufs Herz: In der Praxis bleibt es oft genau dabei. Doch diese Sichtweise greift zu kurz. Die Synchronisation von Identitäten ist nicht das Ende, sondern der Anfang.
Wer Entra ID wie ein Active Directory in der Cloud betreibt – mit dauerhaften Admin-Rollen, ohne Conditional Access und ohne klare Gerätestrategie – schafft hybride Identitäten, aber keine belastbare Sicherheit. Der Weg zu Entra ID ist damit keine einmalige Migration, sondern eine kontinuierliche Transformation. Er erfordert klare Architekturentscheidungen, einen bewussten Umgang mit der hybriden Zwischenwelt und ein Umdenken hin zu Conditional Access als zentralem Steuerungsinstrument.
Entra ID ist nicht "AD in der Cloud"
Der häufigste Denkfehler bei der Einführung von Entra ID lautet: "Das ist doch im Grunde dasselbe wie unser Active Directory, nur in der Cloud." Diese Annahme zieht sich als roter Faden durch viele Fehlentscheidungen.
Wer heute ein Active Directory betreibt und Microsoft 365 oder Azure nutzt, hat mit hoher Wahrscheinlichkeit bereits Entra Connect installiert. Benutzer synchronisieren, Password Hash Sync aktivieren, fertig – so verlaufen viele Cloudmigrationen. Hand aufs Herz: In der Praxis bleibt es oft genau dabei. Doch diese Sichtweise greift zu kurz. Die Synchronisation von Identitäten ist nicht das Ende, sondern der Anfang.
Wer Entra ID wie ein Active Directory in der Cloud betreibt – mit dauerhaften Admin-Rollen, ohne Conditional Access und ohne klare Gerätestrategie – schafft hybride Identitäten, aber keine belastbare Sicherheit. Der Weg zu Entra ID ist damit keine einmalige Migration, sondern eine kontinuierliche Transformation. Er erfordert klare Architekturentscheidungen, einen bewussten Umgang mit der hybriden Zwischenwelt und ein Umdenken hin zu Conditional Access als zentralem Steuerungsinstrument.
Entra ID ist nicht "AD in der Cloud"
Der häufigste Denkfehler bei der Einführung von Entra ID lautet: "Das ist doch im Grunde dasselbe wie unser Active Directory, nur in der Cloud." Diese Annahme zieht sich als roter Faden durch viele Fehlentscheidungen.
Das Active Directory ist hierarchisch organisiert. Forests, Domains, Organizational Units (OUs) und Group Policy Objects (GPOs) bilden eine verschachtelte Struktur, in der Vererbung das zentrale Steuerungsprinzip ist. Entra ID hingegen ist flach: keine OUs, keine GPO-Vererbung, keine Forest Trusts. Stattdessen steht die Identität im Mittelpunkt. Benutzer, Gruppen und Anwendungen existieren in einem gemeinsamen Verzeichnis, gesteuert über Richtlinien, Rollen und Conditional Access.
Für viele Administratoren ist das Fehlen von Gruppenrichtlinien der größte Einschnitt. GPOs sind seit über zwei Jahrzehnten das zentrale Werkzeug zur Gerätekonfiguration – von Kennwort- richtlinien bis hin zu scheinbaren Details wie der Taskleistenkonfiguration. In Entra ID gibt es dieses Konzept nicht. Die Rolle übernimmt Microsoft Intune mit dem Settings Catalog, dem Gegenstück zu den administrativen Vorlagen (ADMX). Einstellungen werden hier über Configuration Service Provider (CSP) an Windows-Geräte verteilt.
Für die Migration bestehender GPOs stellt Microsoft das Tool "Group Policy Analytics" innerhalb von Intune bereit. Es analysiert exportierte GPOs und zeigt, welche Einstellungen sich in Intune abbilden lassen. Für kompatible Konfigurationen lassen sich direkt Settings-Catalog-Profile erzeugen. Eine vollständige Übersicht bietet die entsprechende Community-Dokumentation [1].
Achtung: Migrieren Sie GPOs dabei nicht blind per Lift-and-Shift. Viele Umgebungen enthalten Altlasten, etwa Richtlinien für längst entfernte Software oder veraltete Komponenten wie den Internet Explorer. Nutzen Sie die Umstellung, um aufzuräumen und nur noch tatsächlich benötigte Einstellungen zu übernehmen.
Auch die Werkzeuge ändern sich. Wer lange mit Active Directory Users and Computers (ADUC) gearbeitet hat, sucht die gewohnte MMC-Konsole vergeblich. Die Verwaltung erfolgt im Entra Admin Center unter "entra.microsoft.com". Benutzer, Gruppen, Rollen, Geräte und Conditional-Access-Richtlinien lassen sich hier zentral steuern. Für Automatisierung steht Microsoft Graph bereit, inklusive PowerShell-Modulen. Das frühere AzureAD-Modul ist seit März 2025 abgekündigt.
Damit geht es nicht nur um neue Tools, sondern um einen grundlegenden Wechsel: weg von lokalen Konsolen, hin zu einer zentralen, webbasierten Steuerung. Für viele Administratoren bedeutet das auch, gewohnte Arbeitsweisen aufzugeben und sich von etablierten Denkmustern zu lösen. Das entspricht dem Zero-Trust-Ansatz, bei dem nicht mehr das Netzwerk, sondern die Identität die zentrale Kontrollinstanz ist.
Synchronisation und Authentifizierung
Die Brücke zwischen Active Directory und Entra ID bilden heute zwei Werkzeuge: Microsoft Entra Connect Sync und Microsoft Entra Cloud Sync. Beide synchronisieren Benutzer, Gruppen und Kontakte von on-premises nach Entra ID, unterscheiden sich jedoch grundlegend in ihrer Architektur.
Entra Connect Sync ist der etablierte Ansatz. Er basiert auf einer dedizierten Serverinstallation on-premises mit lokaler Sync-Engine und SQL-Datenbank. Standardmäßig erfolgt die Synchronisation alle 30 Minuten. Connect Sync unterstützt komplexe Szenarien wie Exchange Hybrid, Device Writeback, Pass-Through Authentication und benutzerdefinierte Synchronisationsregeln. Der Nachteil: Der Server ist ein Single Point of Failure. Fällt er aus, stoppt die Synchronisation. Ein Staging-Server für manuelles Fail-over gilt als Best Practice, ersetzt aber keine echte Hochverfügbarkeit.
Entra Cloud Sync ist Microsofts strategische Richtung. Statt einer umfangreichen On-Premises-Installation kommt ein leichtgewichtiger Provisioning Agent auf einem domänenverbundenen Server zum Einsatz. Die eigentliche Synchronisationslogik läuft in der Cloud. Mehrere Agents können parallel aktiv sein – fällt einer aus, übernehmen die anderen. Die Konfiguration erfolgt zentral im Entra Admin Center. Cloud Sync synchronisiert standardmäßig alle zwei Minuten und eignet sich besonders für Szenarien mit getrennten Forests. Neue Funktionen stellt Microsoft bevorzugt auf dieser Plattform bereit.
In der Praxis bedeutet das: Für neue, weniger komplexe Umgebungen ist Cloud Sync meist die bessere Wahl. Bestehende Szenarien mit Exchange Hybrid, Device Writeback oder komplexen Regeln sprechen weiterhin für Connect Sync. Beide Ansätze lassen sich parallel betreiben – allerdings dürfen sie niemals dieselben Objekte synchronisieren. Zu beachten ist außerdem die aktuelle Grenze von 150.000 Objekten pro AD-Domain bei Cloud Sync. Unabhängig vom gewählten Ansatz gilt: Ein Entra-Connect-Server ist ein Tier-0-Asset und sollte entsprechend wie ein Domaincontroller gehärtet werden.
Authentifizierung: Die richtige Methode wählen
Neben der Synchronisation ist die Wahl der Authentifizierungsmethode eine zentrale Architekturentscheidung. Password Hash Synchronization (PHS) überträgt einen mehrfach gehashten Wert des Benutzerkennworts nach Entra ID, die Authentifizierung erfolgt vollständig in der Cloud. Der Ansatz ist einfach, benötigt keine zusätzliche Infrastruktur und ermöglicht Funktionen wie die Erkennung kompromittierter Anmeldeinformationen. Microsoft empfiehlt PHS als Standard und nutzt es auch intern.
Pass-Through Authentication (PTA) prüft Kennwörter in Echtzeit gegen das lokale Active Directory. Dabei verlässt kein Passwort-Hash die eigene Infrastruktur. PTA eignet sich vor allem für Szenarien mit regulatorischen Vorgaben. Allerdings sind mindestens drei Agents für Hochverfügbarkeit erforderlich, und bei einem Ausfall der On-Premises-Umgebung ist keine Cloudauthentifizierung mehr möglich. In der Praxis wird daher häufig PHS als Fallback kombiniert.
Federation mit AD FS war lange der Standard, gilt heute aber als Auslaufmodell. Die notwendige Infrastruktur ist komplex und aufwendig zu betreiben. Microsoft empfiehlt, bestehende AD-FS-Umgebungen schrittweise durch PHS oder PTA zu ersetzen – in Kombination mit Conditional Access als zentraler Richtlinieninstanz.
Unabhängig vom gewählten Verfahren sollte das langfristige Ziel eine passwortlose Authentifizierung sein. Entra ID unterstützt dafür Windows Hello for Business, FIDO2-Sicherheitsschlüssel und die Microsoft Authenticator App als Phishing-resistente Methoden. Laut Microsoft sinkt das Risiko einer Kontoübernahme mit aktivierter MFA um 99,9 Prozent. Passwordless geht noch einen Schritt weiter und eliminiert das Passwort als Angriffsvektor vollständig.
Geräte: Hybrid Join vs. Entra Join
Neben Benutzeridentitäten spielt die Geräteidentität eine zentrale Rolle in hybriden Umgebungen. Microsoft unterscheidet vier Join-Modelle, die den Grad der Cloudintegration bestimmen: Domain Join ist der klassische Beitritt zum lokalen Active Directory und bleibt rein on-premises. Entra Registered adressiert vor allem BYOD-Szenarien: Das Gerät wird in Entra ID registriert, bleibt aber unter Kontrolle des Benutzers. Hybrid Join verbindet beide Welten, das Gerät ist sowohl im lokalen AD als auch in Entra ID verankert. Entra Join schließlich ist der cloudnative Ansatz: Das Gerät wird ausschließlich über Entra ID verwaltet, in der Regel mit Intune.
Die Praxis sieht meist anders aus: Viele Unternehmen verharren im Hy- brid-Join-Status. Geräte sind domänenverbunden, werden per GPO gesteuert und zusätzlich in Entra ID registriert. Das funktioniert, hat aber einen entscheidenden Nachteil: Hybrid-Join-Geräte benötigen regelmäßig Kontakt zu einem Domaincontroller. Ohne diese Verbindung geraten Anmeldung und Richtlinienverarbeitung ins Stocken. In Zeiten von Remote Work wird das schnell zur architektonischen Bremse.
Microsoft empfiehlt deshalb für neue Geräte klar Entra Join. Geräte authentifizieren direkt gegen Entra ID, lassen sich über Intune verwalten und benötigen keinen Domaincontroller mehr. Mit Kerberos Cloud Trust bleibt dennoch der Zugriff auf On-Premises-Ressourcen wie Dateifreigaben möglich.
Wann ist Hybrid Join weiterhin sinnvoll? Etwa bei Win32-Anwendungen, die AD-Maschinenkonten voraussetzen, bei bestehenden Imaging-Prozessen oder wenn GPO-Abhängigkeiten noch nicht nach Intune migriert wurden. In solchen Szenarien ist Hybrid Join eine praktikable Übergangslösung – aber kein Zielzustand.
In der Praxis zeigt sich häufig ein anderes Bild: Unternehmen bleiben jahrelang im Hybrid-Join-Modell, ohne klare Exit-Strategie. Genau hier entsteht ein schleichendes Risiko. Legen Sie früh fest, welche Gerätegruppen wann auf Entra Join wechseln. Werkzeuge wie Windows Autopilot und Intune helfen, den Übergang planbar umzusetzen.
Legacy-Anwendungen in der hybriden Welt
Die unangenehme Wahrheit jeder AD-zu-Entra-ID-Transformation: Active Directory verschwindet nicht über Nacht. Viele Unternehmen bleiben über Jahre in einem hybriden Zustand. Diese Zwischenwelt muss bewusst gesteuert werden, statt sie als Provisorium laufen zu lassen.
Die größte Hürde sind Legacy-Anwendungen, die auf LDAP oder Kerberos angewiesen sind – etwa ERP-Systeme, Line-of-Business-Anwendungen, Druckserver oder Dateifreigaben. Diese Systeme kennen weder OAuth 2.0 noch SAML, sondern sprechen ausschließlich die Sprache des klassischen Active Directory. Eine universelle Lösung gibt es nicht, sondern nur einen Werkzeugkasten, der je nach Szenario zum Einsatz kommt.
Entra Application Proxy ermöglicht den sicheren Zugriff auf On-Premises-Webanwendungen, die Kerberos Constrained Delegation (KCD) oder Header-basierte Authentifizierung nutzen. Die Verbindung wird ausgehend aufgebaut, eingehende Firewallports sind nicht erforderlich. Anwendungen lassen sich so über Conditional Access absichern und um MFA ergänzen, ohne sie selbst anzupassen.
Entra Kerberos (Cloud Trust) ist eine neuere Brückentechnologie. Dabei wird Entra ID als schreibgeschützter Domaincontroller (RODC) im Active Directory registriert. Entra ID stellt daraufhin partielle Kerberos-Tickets aus, die am lokalen Domaincontroller in vollständige Tickets umgewandelt werden. Das ermöglicht Single Sign-on zu On-Premises-Ressourcen für Benutzer, die sich mit Windows Hello oder FIDO2 anmelden – ohne Passwort. Cloud Trust ersetzt die älteren Key-Trust- und Certificate-Trust-Modelle.
Entra Domain Services (ehemals Azure AD DS) stellt eine verwaltete AD-DS-Instanz in Azure bereit, die LDAP, NTLM und Kerberos unterstützt. Für Anwendungen, die ein klassisches Active Directory benötigen, aber nicht mehr lokal betrieben werden sollen, kann das eine sinnvolle Option sein.
Für eine Übergangszeit existieren damit zwei Welten parallel. Active Directory für Legacy-Anwendungen und Kerberos-basierte Ressourcen, Entra ID für Cloudanwendungen, Conditional Access und moderne Authentifizierung. Diese Koexistenz erfordert klare Governance: Welche Anwendungen laufen wo? Welche Protokolle sind noch im Einsatz? Und gibt es für jede Abhängigkeit einen konkreten Ablöseplan? Ohne diese Klarheit entsteht keine Hybrid Identity, sondern zwei getrennte Welten mit einer Synchronisationsbrücke dazwischen.
Conditional Access: Das Sicherheitsnetz richtig spannen
Conditional Access ist das Herzstück von Entra ID und setzt den Zero-Trust-Ansatz zentral um. Greift ein Benutzer auf eine Ressource zu, müssen definierte Bedingungen erfüllt sein. Conditional Access bewertet dazu verschiedene Signale – etwa Benutzeridentität, Gerätestatus, Standort oder Anmelderisiko – und trifft auf dieser Basis eine Entscheidung: Zugriff gewähren, zusätzliche Faktoren anfordern oder blockieren. Eine detaillierte Übersicht der Funktionsweise bietet die Microsoft-Dokumentation zu Conditional Access [2].
In der Praxis zeigt sich jedoch ein anderes Bild. Viele Umgebungen arbeiten ganz ohne Conditional-Access-Policys – oder mit einem unübersichtlichen Regelwerk aus zahlreichen Einzelrichtlinien. Beides ist riskant. Stattdessen empfiehlt sich ein klarer Einstieg mit wenigen, gezielten Basisrichtlinien.
An erster Stelle steht Multifaktor-Authentifizierung für Administratoren. Kein privilegiertes Konto sollte ohne MFA auskommen – ohne Ausnahme. Die Policy richtet sich an alle Benutzer mit administrativen Rollen wie Global Administrator oder Security Administrator. Setzen Sie dabei auf Phishing-resistente Verfahren wie FIDO2-Sicherheitsschlüssel oder Windows Hello for Business statt auf SMS. Ein Beispiel für die Umsetzung per Microsoft Graph zeigt das Listing "Conditional Access per PowerShell".
Listing: Conditional Access per PowerShell – MFA für Admins erzwingen
$params = @{
displayName = "CA001 - MFA für Admins"
state = "enabledForReportingButNotEnforced"
conditions = @{
users = @{
includeRoles = @(
"62e90394-69f5-4237-9190- 012177145e10" # Global Admin
"194ae4cb-b126-40b2-bd5b- 6091b380977d" # Security Admin
"f28a1f50-f6e7-4571-818b- 6a12f2af6b6c" # SharePoint Admin
)
}
applications = @{
includeApplications = @("All")
}
}
grantControls = @{
operator = "OR"
builtInControls = @("mfa")
}
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params
Wichtig ist zudem, neue Richtlinien zunächst im Report-Only-Modus zu betreiben. So lassen sich Auswirkungen und mögliche Seiteneffekte prüfen, bevor der Zugriff tatsächlich eingeschränkt wird.
Ein zweiter zentraler Schritt ist das Blockieren von Legacy Authentication. Ältere Protokolle wie POP3, IMAP oder SMTP Auth unterstützen kein MFA und stellen damit ein erhebliches Risiko dar. Eine entsprechende Policy sollte diese Zugriffswege konsequent unterbinden.
Ergänzend dazu sollten Sie die Risikobewertung von Anmeldungen nutzen. Entra ID Protection analysiert Anmeldeversuche in Echtzeit und bewertet sie anhand verschiedener Faktoren – etwa ungewöhnlicher Ortswechsel, bekannte Angreifer-Infrastrukturen oder verdächtige Zugriffsmuster. Auf dieser Basis lassen sich Richtlinien definieren, die bei erhöhtem Risiko automatisch zusätzliche Authentifizierungsschritte erzwingen. Voraussetzung dafür ist eine Entra-ID-P2-Lizenz.
Neben Conditional Access gehört auch Privileged Identity Management (PIM) zur Grundausstattung. Während Administratoren im klassischen Active Directory dauerhaft privilegierte Rechte besitzen, setzt Entra ID auf Just-in-Time-Zugriff. Rollen werden nur bei Bedarf aktiviert und sind zeitlich begrenzt. Die Aktivierung erfordert in der Regel MFA und eine Begründung, danach werden die Rechte automatisch wieder entzogen.
Für besonders kritische Rollen empfiehlt Microsoft eine Begrenzung: maximal fünf dauerhaft berechtigte Global-Administrator-Konten, darunter zwei sogenannte Break-Glass-Accounts. Diese Notfallkonten sind von Conditional-Access-Policys ausgenommen, verwenden besonders starke Authentifizierungsmethoden und kommen nur im Ausnahmefall zum Einsatz.
Best Practices: Conditional Access einführen
- Jede Anwendung sollte durch mindestens eine Policy geschützt sein.
- "All resources" statt einzelner Anwendungen verwenden.
- Anwendungen mit ähnlichen Anfor-derungen in gemeinsamen Policys bündeln.
- Einführung in Phasen: zuerst Administratoren, dann Pilotgruppen, dann alle Benutzer.
- Policys zunächst im Report-Only-Modus testen und erst danach aktiv schalten.
Stolperfallen vermeiden
Die Transformation von Active Directory zu Entra ID ist kein Projekt mit klarem Enddatum, sondern ein Prozess über Monate und Jahre. In dieser Zeit treten immer wieder typische Fehler auf – meist nicht aus Unwissen, sondern weil sie in der Planung unterschätzt werden.
Eine der häufigsten Ursachen sind unterschätzte Anwendungsabhängigkeiten. Viele Umgebungen hängen stärker am Active Directory, als zunächst sichtbar ist: Fileserver, Druckdienste, ERP-Systeme oder selbst entwickelte Anwendungen nutzen LDAP oder Kerberos. Erstellen Sie daher vor der Migration eine vollständige Inventur. Hilfreich sind Werkzeuge wie Microsoft Defender for Identity, das LDAP- und NTLM-Authentifizierungen im Netzwerk sichtbar macht, das Open-Source-Tool PingCastle [3] zur Analyse der AD-Sicherheitslage sowie die Entra-ID-Sign-in-Logs.
Ein weiterer typischer Fehler ist, Conditional Access erst nachträglich einzuführen. Wer Identitäten synchronisiert und Sicherheitsrichtlinien erst später definiert, schafft eine Phase ohne wirksame Zugriffskontrolle. Planen Sie Conditional Access daher von Anfang an mit ein. Ebenso häufig wird die Gerätestrategie vernachlässigt. Ein synchronisiertes Benutzerkonto allein reicht nicht aus, wenn das Gerät weiterhin rein domänengebunden ist und keine moderne Authentifizierung unterstützt. Identitäts- und Gerätemigration müssen parallel gedacht werden.
Auch das Festhalten an permanenten Administratorrechten ist ein Risiko. Während dies im klassischen Active Directory üblich war, widerspricht es dem Sicherheitsmodell von Entra ID. Setzen Sie von Beginn an auf Just-in-Time-Ansätze wie Privileged Identity Management. Schließlich fehlt in vielen Projekten eine Governance für die hybride Koexistenz. Ohne definierte Zuständigkeiten und konkrete Ablösepläne bleibt die Umgebung dauerhaft im Übergangszustand – mit erhöhtem Verwaltungsaufwand und einer unnötig großen Angriffsfläche.
Ausblick: Unified Tenant Configuration Management
Ein Thema für die nahe Zukunft ist das Unified Tenant Configuration Management (UTCM). Seit Januar 2026 als Pub-lic Preview über das Microsoft Graph API verfügbar, adressiert es ein alltägliches Problem: Konfigurationsdrift. Sie setzen eine Conditional-Access-Policy auf – und Wochen später wurde eine Einstellung verändert, absichtlich oder versehentlich.
UTCM ermöglicht es, den Konfigurationszustand eines Microsoft-365-Tenants als Baseline zu erfassen und auf Abweichungen zu prüfen. Unterstützt werden derzeit unter anderem Entra ID, Ex- change, Teams, Intune, Defender und Purview. Microsoft positioniert UTCM als Nachfolger des Community-Projekts Microsoft 365 DSC und löst damit den bisherigen skriptbasierten Ansatz durch ein cloudnatives API ab.
Noch ist UTCM auf Monitoring beschränkt, eine automatische Korrektur fehlt, und die Abdeckung ist nicht vollständig. Dennoch lohnt sich eine frühe Evaluierung. Gerade in hybriden Umgebungen, in denen Conditional Access und Intune das Sicherheitsfundament bilden, wird die kontinuierliche Kontrolle von Konfigurationsänderungen zunehmend zur Notwendigkeit.
Fazit
Der Weg von Active Directory zu Entra ID ist kein einfaches Upgrade, sondern ein Paradigmenwechsel: weg von der hierarchischen, netzwerkzentrierten Welt des On-Premises-AD hin zu einer flachen, identitätszentrierten Cloudarchitektur, in der Conditional Access die zentrale Kontrollinstanz bildet. Die größte Herausforderung liegt dabei weniger in der Technik als im Umdenken, etwa beim Verzicht auf OUs und GPOs, beim Abschied von permanenten Administratorrechten oder bei der Einordnung von Active Directory als angebundene Legacy-Komponente.
Wer diesen Wandel aktiv gestaltet und die hybride Zwischenwelt sauber organisiert – mit klarer Governance, einer durchdachten Conditional-Access-Strategie, einer definierten Gerätestrategie und einem Plan für jede Legacy-Abhängigkeit – schafft eine Identitätsinfrastruktur, die in Sicherheit und Flexibilität klassischen AD-Umgebungen deutlich überlegen ist. Der Identitätswechsel ist kein Sprint, sondern ein langfristiger Prozess, den Sie bewusst steuern müssen, statt ihn einfach geschehen zu lassen.
(ln)
Links
[1] Intune Settings Catalog: https://it-a.eu/q6z41
[2] Microsoft Learn: Conditional Access: https://it-a.eu/q6z42
[3] PingCastle von Netwrix: https://it-a.eu/q6z43