– EntraID Monitoring: Protokolle, Diagnose & Health im Detail
„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 Policy? Oder ist das Konto gesperrt?
Das Monitoring & Health (Überwachung und Integrität) in Microsoft Entra ist dein Cockpit für Antworten. Es ist der Ort, an dem du nicht konfigurierst, sondern analysierst. In diesem Artikel gehen wir die wichtigsten Menüpunkte durch, damit du im Ernstfall sofort weißt, wo du klicken musst.


Voraussetzungen: Lizenzen, Rollen und Latenzen
Der Lizenz-Faktor (Free vs. P1 vs. P2)
Bevor wir in die Logs abtauchen, ein Blick auf die Lizenzen, denn diese bestimmen, wie weit du in die Vergangenheit schauen kannst.
- Entra ID Free: Speichert Berichte und Logs nur für 7 Tage. Sicherheitsberichte sind oft gar nicht verfügbar.
- Entra ID P1: Speichert Logs für 30 Tage. Du siehst Anmeldungen und Audits, aber keine detaillierten Risiko-Events.
- Entra ID P2: Speichert ebenfalls 30 Tage, schaltet aber die Identity Protection Logs frei. Nur mit P2 siehst du Details zu „Risikobasierten Anmeldungen“ (z. B. Unmöglicher Ortswechsel) und „Risikobenutzern“.
Profi-Tipp zur Langzeitarchivierung: Wenn du (z. B. für Audits oder ISO-Zertifizierungen) Daten länger als 30 Tage brauchst, musst du sie exportieren (dazu später mehr).
Rollen (Least Privilege)
Du musst kein Globaler Administrator sein, um Logs zu lesen. Halte die Rechte minimal:
- Sicherheitsleseberechtigter (Security Reader): Ideal für das Security-Team.
- Globaler Leser (Global Reader): Der „Nur-Lesen“-Admin für fast alles.
- Berichtsleseberechtigter (Reports Reader): Granularer Zugriff nur auf Berichte.
Geduld ist gefragt: Die Latenz
Ein häufiges Ticket-Phänomen: Ein User meldet einen Fehler, du schaust sofort ins Log und siehst … nichts. Die Protokolle sind nicht Echtzeit.
- Anmeldeprotokolle: Können 2 bis 5 Minuten Verzögerung haben.
- Bereitstellungsprotokolle: Manchmal bis zu 2 Stunden.
- Risiko-Events (P2): Die Erkennung komplexer Muster (z. B. Leaked Credentials) kann bis zu 24 Stunden dauern (Offline-Detection).
Anmeldeprotokolle (Sign-in Logs)
Hier wirst du vermutlich 90 % deiner Zeit im Troubleshooting verbringen. Microsoft unterteilt diese Ansicht in verschiedene Reiter, um die schiere Masse an Daten beherrschbar zu machen.
Szenario-Monitoring: Richtig filtern
Der häufigste Fehler: Einfach wild durch die Liste scrollen. Nutze stattdessen die Funktion Filter hinzufügen, um Szenarien gezielt zu prüfen:
- Szenario „Fehlgeschlagene Anmeldungen“: Setze den Filter auf Status = Fehler. So blendest du das „Rauschen“ der erfolgreichen Logins aus.
- Szenario „Bedingter Zugriff“: Wenn du wissen willst, welche Policy blockiert, klicke auf den entsprechenden Log-Eintrag und wähle den Reiter Bedingter Zugriff. Hier siehst du sofort den Status jeder Policy: „Greift nicht“ (Not applied), „Erfolg“ oder „Fehler“.
Interaktive Benutzeranmeldungen
Das ist der Klassiker: Ein Benutzer sitzt vor dem Bildschirm und gibt Benutzername/Passwort ein oder nutzt MFA. Wonach du hier suchst:
- Status: Erfolgreich oder Fehler?
- Fehlercode: Klicke auf eine fehlgeschlagene Anmeldung. Der Reiter Grundlegende Informationen liefert dir oft direkt den Grund (z. B. „MFA required“ oder „Account disabled“).
- Fehlerdiagnose: Prüfe im Reiter Bedingter Zugriff, ob eine Geoblocking-Regel oder eine Geräte-Compliance-Richtlinie den Zugriff verweigert hat.

Nicht interaktive Benutzeranmeldungen
Diese Logs werden oft übersehen, machen aber oft den Großteil des Traffics aus. Hierbei handelt es sich um Anmeldungen, die im Hintergrund passieren, ohne dass der User interagiert (z. B. wenn eine App ein Refresh-Token nutzt, um die Sitzung zu verlängern).
Praxis-Tipp: Wenn ein User sagt: „Es ging gestern noch, heute nicht mehr (ohne dass ich was 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 wurden.

Dienstprinzipale & Verwaltete Identitäten
Nicht nur Menschen melden sich an. In modernen Umgebungen hast du oft mehr Maschinen-Identitäten als User:
- Dienstprinzipale: Apps oder Skripte, die mit Client-Secrets oder Zertifikaten arbeiten.
- Verwaltete Identitäten (Managed Identities): Azure-Ressourcen, die sich gegenseitig authentifizieren.
- Warum das wichtig ist: Wenn nächtliche Backups, Automatisierungen oder Backend-Prozesse plötzlich fehlschlagen, findest du die Ursache nicht bei den User-Logs, sondern genau hier.


Überwachungsprotokolle (Audit Logs)
Während die Anmeldeprotokolle das „Wer greift zu?“ beantworten, klären die Überwachungsprotokolle das „Wer hat was geändert?“. Dies ist dein Compliance-Log für das interne Change Management. Jeder Eintrag folgt einem klaren Schema, das dir bei der Rekonstruktion von Ereignissen hilft:
- Akteur (Actor): Wer hat die Änderung durchgeführt? (z. B. Admin Max Mustermann oder ein automatisierter Service-Principal).
- Ziel (Target): Welches Objekt wurde manipuliert? (z. B. die Sicherheitsgruppe „Marketing“ oder der User „Lisa Müller“).
- Aktivität: Was genau wurde getan? (z. B. „Gruppe aktualisieren“, „Benutzerpasswort zurücksetzen“ oder „Anwendungsrolle zuweisen“).
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: Ein Kollege (oder ein Skript) hat den User gestern Abend versehentlich aus der berechtigenden Sicherheitsgruppe entfernt. Fall gelöst, ohne lange Fehlersuche in der App selbst.


Bereitstellungsprotokolle (Provisioning Logs)
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 sind in drei Kategorien unterteilt, die du kennen musst:
- Erfolgreich (Success): Der User wurde in der Ziel-App erfolgreich angelegt oder aktualisiert.
- Übersprungen (Skipped): Hier wurde keine Änderung vorgenommen. Das ist oft kein Fehler, sondern bedeutet: Der User existiert bereits identisch im Zielsystem, es fehlen notwendige Attribute für die Erstellung, oder der User befindet sich nicht im definierten Scope (Geltungsbereich) der Synchronisierung.
- Fehler (Failure): Die Synchronisierung ist gescheitert. Meistens hat die API der Ziel-App den Request abgelehnt – etwa wegen fehlender Lizenzen in der Zielanwendung oder Verbindungsproblemen.

Log Analytics & Export
Hier stößt du auf eine der härtesten Grenzen von Entra ID: Die Daten werden standardmäßig nach maximal 30 Tagen gelöscht. Für eine professionelle Umgebung ist das zu wenig. Sicherheitsvorfälle werden oft erst nach Monaten entdeckt (durchschnittlich nach über 200 Tagen!). Ohne externen Speicher stehst du dann ohne Beweise da.
Über den Menüpunkt Diagnoseeinstellungen (Diagnostic Settings) kannst du die Datenströme deshalb an drei verschiedene Ziele ausleiten:
- Log Analytics Workspace (Azure Monitor): Das Analysetool von Microsoft. Es ermöglicht dir komplexe Abfragen mit der KQL (Kusto Query Language).
- Use-Case: Analyse und Alerting. Hier baust du Abfragen wie: „Alarmiere mich sofort, wenn 50 fehlgeschlagene Logins innerhalb von 1 Minute passieren.“
- Use-Case: Analyse und Alerting. Hier baust du Abfragen wie: „Alarmiere mich sofort, wenn 50 fehlgeschlagene Logins innerhalb von 1 Minute passieren.“
- Storage Account: Die kostengünstige Variante für die reine Langzeitarchivierung (Cold Storage). Die Daten landen hier als JSON-Dateien.
- Use-Case: Compliance. Ideal, um gesetzliche Aufbewahrungsfristen (z. B. 6 oder 12 Monate) zu erfüllen, ohne viel Geld für teuren Analysespeicher auszugeben.
- Use-Case: Compliance. Ideal, um gesetzliche Aufbewahrungsfristen (z. B. 6 oder 12 Monate) zu erfüllen, ohne viel Geld für teuren Analysespeicher auszugeben.
- Partner-Lösungen (via Event Hub): Viele Unternehmen nutzen spezialisierte Tools wie AdminDroid oder SIEM-Systeme wie Splunk.
- Use-Case: Zentrales Monitoring. Diese Tools importieren die Daten (oft via Azure Event Hub) und bereiten sie grafisch für das Management oder das SOC auf.


Nutzung & Erkenntnisse (Usage & Insights)
Dieser Bereich hilft dir bei strategischen Entscheidungen und Security Assessments. Anstatt einzelne Fehler zu suchen, schaust du hier auf das große Ganze und erkennst Trends in deiner Organisation.
Hier findest du Antworten auf Fragen, die dir der CFO oder der CISO stellen:
- Authentifizierungsmethoden: Wie viele User nutzen noch unsichere Methoden wie SMS oder Sprachanruf für MFA? Nutze diese Daten, um deine Kampagnen für die Umstellung auf sicherere Methoden (Microsoft Authenticator App oder FIDO2-Keys) gezielt zu steuern.
- Anwendungsaktivität: Welche registrierten Enterprise-Apps werden gar nicht mehr genutzt? Dies hilft dir massiv dabei, die Anwendungslandschaft zu bereinigen („App Sprawl“ verhindern) und gegebenenfalls unnötige Lizenzkosten für Drittanbieter-Tools einzusparen.



Massenvorgänge (Bulk Operations)
Wenn du über die GUI (z. B. per CSV-Upload) viele User gleichzeitig erstellst oder Gruppenmitglieder hinzufügst, laufen diese Jobs asynchron im Hintergrund.
Sollte dein Browser abstürzen oder du das Fenster versehentlich schließen, ist der Fortschritt nicht verloren. In diesem Menüpunkt findest du den Status aller Massenvorgänge der letzten Tage. Der wichtigste Punkt hier: Du kannst die Ergebnis-Datei herunterladen. Darin siehst du Zeile für Zeile, welcher Eintrag aus deiner CSV erfolgreich verarbeitet wurde und welcher fehlgeschlagen ist (inklusive Fehlergrund).

Fazit: Erst schauen, dann schrauben
Das Monitoring & Health Center ist der Pulsmesser deiner Umgebung. Gewöhne dir an, bei Problemen Erst schauen, dann schrauben
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: Anmeldeprotokolle (besonders die Reiter Fehlerursache & Bedingter Zugriff).
- Bei unerklärlichen Änderungen: Überwachungsprotokolle (Audit Logs).
- Für die Sicherheit: Exportiere die Logs in einen Workspace, um sie länger als 30 Tage zu behalten.
» Zum Hauptartikel: Datenschutz in Microsoft Entra
weitere Links
| Thema / Abschnitt im Artikel | Quelle / Link | Relevanz & Beschreibung |
| Allgemeine Übersicht | Microsoft Learn: Überwachung und Integrität | Die offizielle Übersicht von Microsoft. Ideal als primäre Referenz für den Einstieg. |
| Latenzen & FAQs | Microsoft Learn: Berichte – Häufig gestellte Fragen | Wichtig: Bestätigt die im Artikel genannten Latenzzeiten (2-5 Min. vs. 24 Std.) offiziell. |
| Lizenzen (P1 vs. P2) | Dynamic Group: Entra ID Lizenzen verstehen | Sehr guter, verständlicher Vergleich der Lizenzfeatures (Free, P1, P2) aus Administratorensicht. |
| Anmeldeprotokolle | AdminDroid: Scenario Monitoring | Vertieft das Thema „Szenario-Monitoring“ und Filtern, das im Artikel angesprochen wurde. Praxisnah. |
| Fehlercodes & Details | Microsoft Learn: Anmeldeprotokolle | Die „Bibel“ für Fehlercodes. Nützlich für Leser, die spezifische Fehlercodes nachschlagen müssen. |
| Log Analytics & Export | Microsoft Learn: Logs in Azure Monitor integrieren | Technische Anleitung für den Abschnitt 5 (Export), falls Leser die Einrichtung Schritt-für-Schritt nachbauen wollen. |
| Security Assessment | Conova: Active Directory Security Assessment | Beispiel für professionelle Sicherheitsüberprüfungen, passend zum Abschnitt „Nutzung & Erkenntnisse“. |


Hinterlasse jetzt einen Kommentar