Backup und Restore in Entra ID
An der Sicherungsleine
Veröffentlicht in Ausgabe 11/2025 - SCHWERPUNKT
Auf den ersten Blick wirkt Microsoft Entra ID nicht wie ein klassisches System zur Datenhaltung und scheint daher oberflächlich gesehen auch kein Backup zu benötigen. Zunächst ist jedoch zu klären, was heute überhaupt unter "Daten" zu verstehen ist. Im herkömmlichen Sinn umfasst der Begriff all jene Inhalte, die Benutzer tagtäglich erzeugen und verändern. Mit Blick auf Entra ID und Datensicherung bekommt dieser Begriff eine andere Bedeutung: Hierbei handelt es sich vor allem um Benutzerkonten, Gruppenkonten sowie Richtlinien. Damit wird deutlich, dass es auch in Entra ID wertvolle Inhalte gibt, die Sie regelmäßig sichern sollten.
Wie sicher sind Objekte in Entra ID?
Die Frage, wie sicher Objekte in Microsoft Entra ID sind, lässt sich nicht pauschal beantworten. Microsoft unterscheidet deutlich zwischen verschiedenen Objekttypen, etwa bei der Löschung von Benutzern oder Gruppen. Ein wesentlicher Faktor ist dabei die sogenannte "Source of Truth", also die ursprüngliche Herkunft eines Objekts. Liegt der User-Lifecycle beispielsweise im lokalen Active Directory, ist das Verhalten klar definiert: Löschen Sie einen synchronisierten Benutzer in Entra ID, landet er zunächst im Papierkorb für Benutzerobjekte. Dort bleibt er 30 Tage, bevor er endgültig entfernt wird.
Innerhalb dieses Zeitraums können Sie das Benutzerobjekt entweder manuell wiederherstellen oder es wird automatisch bei der nächsten Synchronisation erneut angelegt, sofern es weiterhin im Scope der Synchronisierung liegt. Wichtig ist hierbei, dass bei der automatischen Wiederherstellung die Objekt-ID unverändert bleibt. Dadurch erscheint das Benutzerkonto wieder an allen Stellen, an denen es zuvor verwendet wurde, beispielsweise in Conditional Access Policies (CA-Policies). Wird das Objekt gelöscht, entfernt Microsoft es zunächst aus diesen Konfigurationen. Nach der nächsten Synchronisation ist es jedoch wieder verfügbar.
Auf den ersten Blick wirkt Microsoft Entra ID nicht wie ein klassisches System zur Datenhaltung und scheint daher oberflächlich gesehen auch kein Backup zu benötigen. Zunächst ist jedoch zu klären, was heute überhaupt unter "Daten" zu verstehen ist. Im herkömmlichen Sinn umfasst der Begriff all jene Inhalte, die Benutzer tagtäglich erzeugen und verändern. Mit Blick auf Entra ID und Datensicherung bekommt dieser Begriff eine andere Bedeutung: Hierbei handelt es sich vor allem um Benutzerkonten, Gruppenkonten sowie Richtlinien. Damit wird deutlich, dass es auch in Entra ID wertvolle Inhalte gibt, die Sie regelmäßig sichern sollten.
Wie sicher sind Objekte in Entra ID?
Die Frage, wie sicher Objekte in Microsoft Entra ID sind, lässt sich nicht pauschal beantworten. Microsoft unterscheidet deutlich zwischen verschiedenen Objekttypen, etwa bei der Löschung von Benutzern oder Gruppen. Ein wesentlicher Faktor ist dabei die sogenannte "Source of Truth", also die ursprüngliche Herkunft eines Objekts. Liegt der User-Lifecycle beispielsweise im lokalen Active Directory, ist das Verhalten klar definiert: Löschen Sie einen synchronisierten Benutzer in Entra ID, landet er zunächst im Papierkorb für Benutzerobjekte. Dort bleibt er 30 Tage, bevor er endgültig entfernt wird.
Innerhalb dieses Zeitraums können Sie das Benutzerobjekt entweder manuell wiederherstellen oder es wird automatisch bei der nächsten Synchronisation erneut angelegt, sofern es weiterhin im Scope der Synchronisierung liegt. Wichtig ist hierbei, dass bei der automatischen Wiederherstellung die Objekt-ID unverändert bleibt. Dadurch erscheint das Benutzerkonto wieder an allen Stellen, an denen es zuvor verwendet wurde, beispielsweise in Conditional Access Policies (CA-Policies). Wird das Objekt gelöscht, entfernt Microsoft es zunächst aus diesen Konfigurationen. Nach der nächsten Synchronisation ist es jedoch wieder verfügbar.
Der gesamte Vorgang funktioniert auch in umgekehrter Richtung: Entfernen Sie einen Benutzer aus dem Synchronisationsbereich, verschiebt Entra ID ihn zunächst in den Papierkorb. Nehmen Sie das Benutzerkonto später wieder in den Scope auf, wird es nicht neu erstellt, sondern mit der ursprünglichen Objekt-ID wiederhergestellt. Das ist insbesondere dann relevant, wenn bei Änderungen an den Filterregeln versehentlich eine größere Anzahl von Benutzerkonten entfernt wird. Nach Korrektur der Regeln und erneuter Synchronisation stehen die Benutzer wieder wie zuvor zur Verfügung, inklusive aller bestehenden Referenzen, zum Beispiel in CA-Policies.
Ein vergleichbares Verhalten gilt auch für Cloud-only-Konten. Auch hier werden gelöschte Benutzer zunächst in den Papierkorb verschoben. Eine Wiederherstellung erfolgt ebenfalls mit identischer Objekt-ID, sodass Zuweisungen und Konfigurationen erhalten bleiben. Wichtig ist jedoch: Nach Ablauf der 30-tägigen Aufbewahrungsfrist wird das Objekt endgültig gelöscht. Legen Sie anschließend einen Benutzer mit dem gleichen UserPrincipalName neu an, handelt es sich technisch um ein neues Objekt mit einer anderen Objekt-ID. Für Entra ID ist das dann ein komplett neues Konto. Entsprechend müssen Sie Conditional Access Policies, Gruppenmitgliedschaften und Rollenbeziehungen manuell neu setzen.
Solange gelöschte Objekte in einem Papierkorb landen oder ihre "Source of Truth" im lokalen Active Directory liegt, ist das Thema Datensicherung in Entra ID vergleichsweise unkritisch. Komplexer wird es jedoch bei Cloud-only-Gruppen. Hier unterscheidet Microsoft zwischen Microsoft-365-Gruppen und Sicherheitsgruppen – und beide verhalten sich beim Löschen sehr unterschiedlich.
Verschiedenes Verhalten je nach Objekttyp
Microsoft-365-Gruppen verhalten sich beim Löschen ähnlich wie Benutzerkonten: Sie landen im Papierkorb und lassen sich innerhalb von 30 Tagen vollständig wiederherstellen – inklusive ihrer Objekt-ID und natürlich ihrer Mitglieder.
Anders sieht es bei Sicherheitsgruppen aus: Wird eine solche Gruppe gelöscht, ist sie unwiderruflich entfernt. Eine native Wiederherstellungsmöglichkeit existiert nicht. Das ist besonders kritisch, da auch hier die Objekt-ID als zentrale Referenz für Rollen, Conditional Access Policies und Lizenzierungen dient. Legen Sie eine Sicherheitsgruppe manuell neu an, erhält sie eine neue Objekt-ID. Bestehende Zuweisungen gehen dabei verloren.
Die Objekt-ID wird von Entra ID verwaltet und lässt sich nicht manuell setzen oder überschreiben. Daher sind klassische Backups in diesem Fall nur eingeschränkt hilfreich: Ein Restore mit derselben Objekt-ID ist technisch nicht möglich.
Absicherung kritischer Gruppen
Gruppen können Sie zwar exportieren und bei Bedarf in großen Mengen per PowerShell wiederherstellen, beispielsweise auf Basis eines früheren Exports. Bedenken Sie jedoch: Auch hier entstehen dabei vollständig neue Objekte mit neuen Objekt-IDs. Alle Referenzen zur ursprünglichen Gruppe, etwa in Conditional Access Policies, gehen dadurch verloren. Im schlimmsten Fall kann dies gravierende Auswirkungen auf den gesamten Entra-Tenant haben. Planen Sie also sorgfältig, welche Gruppen kritisch sind und besonders geschützt werden müssen.
Ein weiteres Risiko ergibt sich aus den Standardberechtigungen vieler Administratorrollen: Nicht nur der "Groups Administrator", sondern auch Rollen wie der "Intune Administrator" dürfen Gruppen löschen. Weitere Rollen mit ähnlichen Rechten erhöhen die Gefahr versehentlicher Änderungen zusätzlich. Um kritische Gruppenobjekte proaktiv abzusichern, bieten sich mehrere Maßnahmen an:
- Eindeutige Benennung: Verwenden Sie beispielsweise das Präfix "DO-NOT-DELETE" in der Beschreibung.
- Integration in PIM (Privileged Identity Management): So dürfen nur privilegierte Administratoren wie "Privileged Role Administrators" Änderungen vornehmen. Diese Maßnahme eignet sich vor allem für Gruppen, die Rollen zugewiesen bekommen, und weniger für große Mengen von Gruppen.
- Zuweisung zu einer Administrative Unit (AU): Damit lässt sich der Zugriff gezielt einschränken. Selbst ein "Global Administrator" hat standardmäßig keinen Zugriff. Zwar kann er sich diese Rechte zurückholen, doch das Risiko menschlicher Fehler im Tagesgeschäft wird deutlich reduziert.
Soft-Delete und Wiederherstellung von AUs
Administrative Units sind ein leistungsstarkes Konzept, mit dem Sie Benutzer, Gruppen und Geräte gezielt verwalten und administrative Aufgaben delegieren können. Rollen wie der "User Administrator" lassen sich AU-spezifisch vergeben, die damit verbundenen Rechte gelten dann ausschließlich für die Objekte innerhalb dieser AU.
Wird eine AU gelöscht, ist das zunächst ärgerlich, etwa wegen des Aufwands für definierte dynamische Mitgliedschaftsregeln. Im Entra Admin Center gibt es jedoch keinen sichtbaren Papierkorb wie bei Benutzerkonten. Stattdessen bleiben gelöschte AUs 30 Tage im Soft-Delete-Zustand. Zugriff auf diese Objekte haben Sie ausschließlich über die Deleted-Items-API, mit der Sie gelöschte AUs auflisten und wiederherstellen können.
Der einfachste Weg zur API führt über den Graph Explorer und den Endpunkt "https://graph.microsoft.com/v1.0/direc-tory/deletedItems/microsoft.graph.administrativeUnit". Als Ergebnis eines GET-Befehls erhalten Sie eine JSON-Liste aller gelöschten AUs der letzten 30 Tage.
Wichtig: Für die Wiederherstellung benötigen Sie die jeweilige ID des Objekts. Der Endpunkt lautet "https://graph.microsoft.com/v1.0/directory/deletedItems/ <Objekt-ID>/ zrestore#". Nutzen Sie hierfür das HTTP-Kommando POST.
Ist die Wiederherstellung erfolgreich, bestätigt das API dies mit einem "200 OK". Anschließend sehen Sie die wiederhergestellte AU im Entra Admin Center – mit allen Eigenschaften, die sie zum Zeitpunkt der Löschung hatte.
Dokumentation und Backup von AUs
Die Wiederherstellung ist nur 30 Tage möglich. Danach sind gelöschte AUs endgültig verloren. Deshalb sollten Sie wichtige AUs frühzeitig dokumentieren. Ein praktikabler Ansatz ist ein PowerShell-Skript, das alle relevanten AU-Informationen in ein beliebiges Format exportiert. Zusätzlich sollten Sie ein zweites Skript vorbereiten, mit dem sich die AU bei Bedarf neu anlegen lässt.
Das ist in diesem Kontext der passende Begriff: Bei AUs spielt die Objekt-ID im Gegensatz zu Gruppen eine untergeordnete Rolle. Entscheidend sind die enthaltenen Mitglieder, dynamischen Regeln, Rollen und weitere Konfigurationen. Solange diese Informationen dokumentiert oder exportiert vorliegen, können Sie eine AU problemlos wiederherstellen, indem Sie sie neu anlegen.
Export und Sicherung von CA-Policies
Conditional Access Policies gehören zu den kritischsten Elementen in Microsoft Entra ID. Über diese steuern Sie zentral, wer auf welche Ressourcen zugreifen darf, ob Multifaktor-Authentifizierung erforderlich ist und von welchen Standorten der Zugriff erlaubt wird. Eine durchdachte Sicherungs- und Wiederherstellungsstrategie ist daher unverzichtbar.
Leider macht es Microsoft Administratoren nicht leicht, diese Richtlinien zu sichern. Im Conditional Access Dashboard finden Sie weder eine Backup- noch eine Exportfunktion. Auch eine Änderungshistorie fehlt, die nachvollziehbar macht, welcher Administrator wann welche Änderungen vorgenommen hat. Angesichts der hohen Kritikalität dieser Richtlinien ist das ein Nachteil. Zwar existieren Audit-Logs, um Änderungen nachzuvollziehen, doch deren Auswertung ist oft aufwendig und wenig komfortabel.
Es gibt dennoch praktikable Möglichkeiten, CA-Policies zu sichern. Direkt im Dashboard können Sie JSON-Exporte erstellen und so einzelne Richtlinien gezielt wiederherstellen. Wichtig ist, dass Sie regelmäßig Exporte durchführen und diese sicher ablegen. Den Export können Sie mit PowerShell automatisieren. Alternativ können Sie den Graph Explorer nutzen, um Richtlinien auszulesen.
Eine besonders komfortable Lösung bietet das Entra-Exporter-Modul für die PowerShell. Damit exportieren Sie nicht nur Conditional Access Policies, sondern auch viele weitere Entra-Objekte – beispielsweise Administrative Units. Das Modul erzeugt eine übersichtliche Verzeichnisstruktur, in der die exportierten JSON-Dateien für alle gesicherten Objekte abgelegt werden.
Eine vollständige Wiederherstellung direkt im Entra Admin Center ist zwar derzeit nicht möglich, aber die exportierten Konfigurationsdateien stellen sicher, dass Sie im Ernstfall alle notwendigen Daten zur Hand haben. Seit Oktober werden Conditional Access Policies derweil nicht mehr hart gelöscht, sondern wandern zunächst in den Papierkorb. Aktuell befindet sich diese Funktion noch in der Public Preview.
Unterschiede beim Wiederherstellungsprozess
Die vom Entra Exporter erzeugten Dateien liegen überwiegend im JSON-Format vor. Die Wiederherstellung kann sich jedoch je nach Objekttyp unterscheiden:
- Administrative Units: Eine AU müssen Sie zunächst manuell neu anlegen. Danach nutzen Sie deren neue Objekt-ID, um die exportierten JSON-Dateien mit den einzelnen Inhalten zu importieren. Je nach Umfang und Komplexität der ursprünglichen Konfiguration kann dies mehrere Schritte erfordern.
- Conditional Access Policies: Hier ist der Vorgang einfacher. Die mit dem Entra Exporter erstellten JSON-Dateien liegen bereits im korrekten Format für den Import vor. Dennoch gibt es im Entra Admin Center ein paar Details zu beachten.
Um Conditional Access Policies wiederherzustellen, navigieren Sie im Dashboard der Conditional Access Policies in den Bereich "Policies". Oben finden Sie die Schaltfläche "Upload policy file". Darüber öffnet sich ein Dialog, in dem Sie die gewünschte JSON-Datei auswählen können. Die Dateien lassen sich ohne Anpassungen importieren, die darin enthaltene Richtlinie wird sofort wiederhergestellt.
Achten Sie jedoch darauf, nicht den Befehl "Save" zu verwenden. Dieser speichert den JSON-Inhalt einschließlich schreibgeschützter Attribute wie "Id" oder "createdDateTime" und führt unweigerlich zu einem Fehler. Wählen Sie stattdessen "Review + Create": Damit legen Sie eine neue CA-Policy an, wobei die Read-Only-Werte automatisch neu generiert werden. Alle relevanten Konfigurationen wie inkludierte oder exkludierte Elemente werden korrekt übernommen.
Der Entra Exporter legt für jede CA-Policy ein eigenes Verzeichnis an, dessen Name der jeweiligen Policy-ID entspricht. Bei einer großen Anzahl von Richtlinien kann das Auffinden einer gelöschten Policy dadurch etwas mühsam werden. In der Praxis erleichtert jedoch eine Textsuche im Explorer das gezielte Finden der passenden Richtlinie. Wichtig ist in diesem Zusammenhang vor allem, dass Sie die Inhalte verfügbar haben und bei Bedarf schnell wiederherstellen können.
Versionierter Export mit Historie
Der Entra Exporter speichert seine Dateien standardmäßig im gleichen Verzeichnis und überschreibt damit den vorherigen Export. Eine Historie fehlt jedoch – dabei ist sie oft entscheidend, wenn Sie Inhalte von einem bestimmten Tag gezielt wiederherstellen müssen.
Eine Historie ermöglicht es Ihnen, auf ein konkretes Backup zuzugreifen und gezielt bestimmte Versionen zu verwenden. Eine Option ist die Ablage der Exporte in GitHub. Oft reicht jedoch eine einfachere Variante: Sie können ein lokales Git-Repository auf Ihrer eigenen Workstation nutzen. Zwei kurze Beispielskripte [1] zeigen, wie sich dies umsetzen lässt und dienen als Ausgangspunkt für individuelle Erweiterungen.
Gute Dokumentation bleibt unerlässlich
Sie müssen je nach Kritikalität Ihrer Umgebung selbst entscheiden, wo Backups unverzichtbar sind und wo eine gute Dokumentation genügt. Die Conditional Access Policies gehören in jedem Fall zu den Elementen, die Sie sichern sollten.
Allerdings gibt es in Entra ID zahlreiche weitere Konfigurationsbereiche, die der Entra Exporter entweder gar nicht oder nur teilweise abdeckt. Ein Beispiel sind die Einstellungen von Entra Cloud Sync: Anders als beim Vorgänger Entra Connect Sync, der sämtliche Konfigurationsdaten lokal speichert, liegen diese Informationen bei Cloud Sync vollständig in Entra ID. Eine Exportmöglichkeit – insbesondere für Attribute-Mappings oder Filterregeln – gibt es derzeit nicht.
Zwar ändern sich diese Einstellungen im Synchronisations-Setup selten, sie sind jedoch oft umfangreich und komplex. Hier ist eine detaillierte Dokumentation unverzichtbar. Weitere Beispiele für wichtige, aber weniger komfortabel sicherbare Elemente sind:
- Global Secure Access
- Konfigurationen aus dem Bereich Identity-Governance & -Compliance, beispielsweise Access-Reviews oder Lifecycle-Workflows.
Eine gute Einstiegshilfe bietet die Microsoft-Dokumentation unter [2]. Sie verdeutlicht klar die Grenze zwischen den Aufgaben, die Microsoft übernimmt, und der Verantwortung, die beim Administrator liegt. Zudem beschreibt sie die relevanten APIs, die zuvor behandelten Konzepte von Soft-Delete und Hard-Delete sowie weitere wichtige Aspekte.
Sicherheitsvorkehrungen vermeiden Risiken
Noch besser als ein gutes Backup ist es, den Verlust von Objekten oder Konfigurationen von vornherein zu verhindern. Zwar bietet Microsoft in Entra ID bisher nur begrenzte Funktionen für Backups und Exporte, doch die Absicherung administrativer Tätigkeiten ist bereits sehr gut gelöst.
Der konsequente Einsatz von PIM (Privileged Identity Management) schützt nicht nur vor böswilligen Angriffen, sondern reduziert auch das Risiko menschlicher Fehler (Human Error). Mit einer klaren JIT- (Just-In-Time)- und JEA-Strategie (Just-Enough-Access) arbeiten Sie im Tagesgeschäft beispielsweise nur mit der Rolle "Global Reader". Erst wenn Sie konkrete Änderungen vornehmen müssen, beantragen Sie kurzzeitig die erforderlichen Rechte. Nach Abschluss der Arbeiten werden diese automatisch wieder entzogen. Das schützt sowohl vor externen Angriffen als auch vor versehentlichen Fehlkonfigurationen.
Darüber hinaus stellt Microsoft die Funktion der "Protected Actions" bereit. Damit können Sie besonders kritische Vorgänge mit einer zusätzlichen Sicherheitsebene versehen. Dazu gehören unter anderem:
- Änderungen an den Conditional Access Policies
- Das Hard-Delete von Objekten über das Deleted-Item-API
Microsoft bietet hierzu unter [3] einen guten Einstieg in der Dokumentation.
Praxisbeispiel: Protected Actions konfigurieren
In der Praxis konfigurieren Sie geschützte Aktionen in mehreren Schritten: Im Dashboard der Conditional Access Policies legen Sie zunächst einen Authentication Context an. Dabei handelt es sich um einen eindeutigen Bezeichner, der sowohl in Protected Actions als auch innerhalb einer CA-Policy als Referenz dient.
Navigieren Sie danach im Entra Admin Center zu "Roles & Admins" und wählen Sie dort "Protected Actions". Fügen Sie eine neue geschützte Aktion hinzu, indem Sie eine der vordefinierten Aktivitäten auswählen. Anschließend verknüpfen Sie den entsprechenden Authentication Context mit dieser Aktion.
Erstellen Sie nun eine neue CA-Policy. Wählen Sie unter "Target resources" nicht wie üblich Applikationen, sondern den zuvor definierten Authentication Context. Sobald die geschützte Aktion ausgeführt werden soll, löst die CA-Policy automatisch aus. Ob die Aktion durchgeführt werden darf, hängt von den in der Policy definierten Bedingungen ab. Dabei können Sie alle bekannten Signale der Conditional Access Policies nutzen – etwa das Erzwingen einer stärkeren MFA oder die Prüfung, ob das verwendete Gerät compliant ist.
Fazit
In Microsoft Entra ID gibt es zahlreiche Objekte, Richtlinien und Konfigurationen, die Sie sichern oder dokumentieren müssen. Manche Bereiche lassen sich relativ einfach exportieren und wiederherstellen, andere erfordern deutlich mehr Aufwand. Die unterschiedlichen Verhaltensweisen bei Löschung und Wiederherstellung machen das Thema aber komplex. Mit einer klaren Backupstrategie, ergänzender Dokumentation und den richtigen Tools stellen Sie sicher, dass Sie auch im Ernstfall handlungsfähig bleiben.
(ln)
Links
[1] Beispielskripte für CA-Export: https://github.com/KlaBier/Powershell/tree/main/BackupCAs_Examples%20-%20ExpertsLive2025
[2] Bewährte Methoden zur Wiederherstellbarkeit: https://learn.microsoft.com/de-de/entra/architecture/recoverability-overview
[3] Geschützte Aktionen in Entra ID: https://learn.microsoft.com/de-de/entra/identity/role-based-access-control/protected-actions-overview