Microsoft 365 EntraID | Überwachung und Integrität

"Mein Login funktioniert nicht!" Wenn dieser Satz fällt, beginnt für dich als Administrator die Detektivarbeit. Liegt es am Passwort? Greift eine Conditional-Access-Richtlinie? Oder ist das Konto gesperrt? Monitoring & Health (Überwachung und Integrität) ist dein Cockpit für die Antworten. Hier konfigurierst du nicht, hier analysierst du.

Welche Lizenz im Tenant liegt, bestimmt, wie weit du in die Vergangenheit schauen kannst:

Tipp zur Langzeitarchivierung: Brauchst du für Audits oder ISO-Zertifizierungen Daten über 30 Tage hinaus, musst du sie exportieren (dazu unten mehr).

Du musst kein Globaler Administrator sein, um Logs zu lesen. Halte die Rechte minimal. Die geringste ausreichende Rolle zum Lesen von Audit- und Anmeldeprotokollen ist der Berichtsleseberechtigte (Reports Reader). Ergänzend eignen sich der Sicherheitsleseberechtigte (Security Reader) für das Security-Team und der Globale Leser (Global Reader) als Nur-Lese-Admin für fast alles.

Ein häufiges Ticket-Phänomen: Ein User meldet einen Fehler, du schaust sofort ins Log und siehst nichts. Die Protokolle sind nicht in Echtzeit. Als grobe Richtwerte gelten Verzögerungen von wenigen Minuten bei Anmeldeprotokollen, teils deutlich länger bei Bereitstellungsprotokollen und bis zu 24 Stunden bei komplexen Risiko-Events (Offline-Detection, etwa Leaked Credentials).

Microsoft nennt dafür keinen festen SLA-Wert mehr, die Latenz hängt von Datentyp und Last ab. Nach einem frischen Upgrade auf P1 oder P2 dauert es zudem rund 24 Stunden, bis die Premium-Berichte vollständig Daten zeigen.

Hier verbringst du den Großteil deiner Troubleshooting-Zeit. Microsoft unterteilt die Ansicht in mehrere Reiter, um die Masse an Daten beherrschbar zu machen.

Der häufigste Fehler ist wildes Scrollen durch die Liste. Nutze stattdessen Filter hinzufügen und prüfe gezielt Szenarien. Für fehlgeschlagene Anmeldungen setzt du den Filter auf Status gleich Fehler und blendest so das Rauschen der erfolgreichen Logins aus.

Willst du wissen, welche Richtlinie blockiert, öffnest du den Log-Eintrag und wechselst auf den Reiter Bedingter Zugriff. Dort siehst du den Status jeder Policy: "Greift nicht" (Not applied), "Erfolg" oder "Fehler".

Der Klassiker: Ein Benutzer sitzt vor dem Bildschirm und gibt Benutzername und Passwort ein oder bestätigt MFA. Du prüfst zuerst den Status (erfolgreich oder Fehler). Bei einer fehlgeschlagenen Anmeldung liefert dir der Reiter Grundlegende Informationen oft direkt den Grund (etwa "MFA required" oder "Account disabled").

Im Reiter Bedingter Zugriff erkennst du, ob eine Geoblocking-Regel oder eine Geräte-Compliance-Richtlinie den Zugriff verweigert hat.

Diese Logs werden oft übersehen, machen aber den Großteil des Traffics aus. Es sind Anmeldungen, die im Hintergrund laufen, ohne dass der User interagiert, etwa wenn eine App ein Refresh-Token nutzt, um die Sitzung zu verlängern.

Tipp: Sagt ein User "Es ging gestern noch, heute nicht mehr, ohne dass ich etwas gemacht habe", liegt der Fehler oft hier. Prüfe, ob Refresh-Tokens abgelehnt werden, beispielsweise weil das Passwort geändert wurde und die alten Tokens dadurch ungültig sind.

Nicht nur Menschen melden sich an. In modernen Umgebungen hast du oft mehr Maschinen-Identitäten als User. Dienstprinzipale sind Apps oder Skripte, die mit Client-Secrets oder Zertifikaten arbeiten. Verwaltete Identitäten (Managed Identities) sind Azure-Ressourcen, die sich gegenseitig authentifizieren.

Wenn nächtliche Backups, Automatisierungen oder Backend-Prozesse plötzlich fehlschlagen, findest du die Ursache nicht bei den User-Logs, sondern genau hier.

Während die Anmeldeprotokolle das "Wer greift zu?" beantworten, klären die Überwachungsprotokolle das "Wer hat was geändert?". Das ist dein Compliance-Log für das interne Change Management. Jeder Eintrag folgt einem klaren Schema: der Akteur (wer hat geändert, etwa Admin Max Mustermann oder ein Service-Principal), das Ziel (welches Objekt wurde manipuliert, etwa die Gruppe "Marketing" oder der User "Lisa Müller") und die Aktivität (was genau geschah, etwa "Gruppe aktualisieren" oder "Benutzerpasswort zurücksetzen").

Typischer Use-Case: Ein Benutzer beschwert sich, dass er plötzlich keinen Zugriff mehr auf eine wichtige App hat. Ein Blick ins Audit Log offenbart oft, dass ein Kollege oder ein Skript ihn am Vorabend versehentlich aus der berechtigenden Sicherheitsgruppe entfernt hat. Fall gelöst, ohne lange Fehlersuche in der App selbst.

Nutzt du die automatische Benutzerbereitstellung (SCIM) zu SaaS-Apps wie Salesforce, ServiceNow oder Dropbox, oder synchronisierst du User aus einem HR-System wie Workday (Inbound Provisioning)?

Hier prüfst du den Status dieser Hintergrund-Synchronisierungen. Die Einträge fallen in drei Kategorien.

Erfolgreich (Success) heißt, der User wurde im Zielsystem angelegt oder aktualisiert. Übersprungen (Skipped) ist meist kein Fehler, sondern bedeutet, dass der User bereits identisch existiert, dass notwendige Attribute fehlen oder dass er außerhalb des definierten Scope liegt. Fehler (Failure) heißt, die Synchronisierung ist gescheitert, meist weil die API der Ziel-App den Request abgelehnt hat, etwa wegen fehlender Lizenzen oder Verbindungsproblemen.

Hier stößt du auf eine der härtesten Grenzen von Entra ID: Die Aktivitätslogs werden je nach Lizenz nach 7 bis 30 Tagen gelöscht. Für eine professionelle Umgebung ist das zu wenig, denn Sicherheitsvorfälle werden im Schnitt erst nach über 200 Tagen entdeckt (Branchenwert aus dem IBM Cost of a Data Breach Report). Ohne externen Speicher stehst du dann ohne Beweise da.

Über den Menüpunkt Diagnoseeinstellungen (Diagnostic Settings) leitest du die Datenströme an drei Ziele aus. Der Log Analytics Workspace (Azure Monitor) ist das Analysetool von Microsoft und erlaubt komplexe Abfragen mit der Kusto Query Language (KQL), etwa "Alarmiere mich, wenn 50 fehlgeschlagene Logins innerhalb einer Minute passieren". Das Storage Account ist die kostengünstige Variante für reine Langzeitarchivierung (Cold Storage), die Daten landen als JSON-Dateien und eignen sich für gesetzliche Aufbewahrungsfristen. Über einen Event Hub schließlich übergibst du die Daten an Partner-Lösungen wie ein SIEM (etwa Microsoft Sentinel oder Splunk), das sie für das Management oder das SOC aufbereitet.

Zur Abgrenzung, damit du die Logs nicht verwechselst: Die hier behandelten Entra-ID-Aktivitätslogs (Anmeldung, Audit, Bereitstellung) liegen 7 bis 30 Tage vor. Das Purview Unified Audit Log ist ein separater, M365-weiter Speicher mit standardmäßig 180 Tagen Aufbewahrung (mit Audit Premium beziehungsweise E5 länger). Für tenantweite Forensik ziehst du beide Quellen heran.

Dieser Bereich hilft bei strategischen Entscheidungen und Security Assessments. Statt einzelne Fehler zu suchen, schaust du auf das große Ganze und erkennst Trends. Unter Authentifizierungsmethoden siehst du, wie viele User noch unsichere Verfahren wie SMS oder Sprachanruf für MFA nutzen, und steuerst damit deine Migrationskampagne auf Authenticator oder FIDO2 gezielt.

Unter Anwendungsaktivität erkennst du, welche registrierten Enterprise-Apps gar nicht mehr genutzt werden, bereinigst die Anwendungslandschaft (gegen App Sprawl) und sparst unnötige Lizenzkosten.

Erstellst du über die GUI per CSV-Upload viele User gleichzeitig oder fügst Gruppenmitglieder hinzu, laufen diese Jobs asynchron im Hintergrund. Stürzt dein Browser ab oder schließt du das Fenster, ist der Fortschritt nicht verloren.

Hier findest du den Status aller Massenvorgänge der letzten Tage und kannst die Ergebnis-Datei herunterladen. Darin siehst du Zeile für Zeile, welcher Eintrag aus deiner CSV erfolgreich verarbeitet wurde und welcher fehlgeschlagen ist, samt Fehlergrund.

Das Monitoring & Health Center ist der Pulsmesser deiner Umgebung. Gewöhne dir an, bei Problemen nicht wild an Einstellungen zu drehen, sondern zuerst in die Protokolle zu schauen.

Bei Login-Problemen sind das die Anmeldeprotokolle (besonders die Reiter Grundlegende Informationen und Bedingter Zugriff). Bei unerklärlichen Änderungen die Überwachungsprotokolle.

Und für die Sicherheit exportierst du die Logs in einen Workspace oder ein SIEM, um sie über 30 Tage hinaus zu behalten.

» Zum Hauptartikel: Datenschutz in Microsoft Entra