Anmeldeprotokolle und Diagnose

Zwei Protokolle, zwei verschiedene Fragen

Wenn im Tenant etwas nicht funktioniert, führt der Weg über die Aktivitätsprotokolle. Sie beantworten aber nicht dieselbe Frage, und die Fehlersuche beginnt damit, die richtige zu stellen.

Anmeldeprotokolle

Wer hat sich wann von wo an welcher Anwendung angemeldet — und was ist dabei passiert. Die Frage lautet: Wer kam herein?

Überwachungsprotokolle

Ein Bericht über jedes protokollierte Ereignis im Verzeichnis: Änderungen an Anwendungen, Gruppen, Benutzern und Lizenzen. Die Frage lautet: Was wurde geändert?

Die meisten Störungen brauchen beide. Eine Anmeldung, die seit gestern scheitert, ist ein Fall für das Anmeldeprotokoll — aber die Ursache steht fast immer im Überwachungsprotokoll, denn irgendwer hat gestern etwas geändert. Wer nur eines von beiden ansieht, findet entweder das Symptom ohne Ursache oder eine Änderung ohne Wirkung.

Vier Arten von Anmeldungen — und eine Ansicht, die drei davon verbirgt

Was umgangssprachlich „das Anmeldeprotokoll“ heißt, sind laut Dokumentation vier Protokolle:

• Interaktive Benutzeranmeldungen — ein Mensch gibt etwas ein.
• Nicht-interaktive Benutzeranmeldungen — im Namen einer Person, aber ohne ihr Zutun; etwa ein Client, der ein Token erneuert.
• Dienstprinzipal-Anmeldungen — eine Anwendung meldet sich als sie selbst an.
• Anmeldungen verwalteter Identitäten — dasselbe für verwaltete Identitäten aus dem Modul zu Workload-Identitäten.

Dazu steht ein Satz in der Dokumentation, der in der Fehlersuche Stunden kosten kann: Die ältere Ansicht der Anmeldeprotokolle enthält nur die interaktiven Benutzeranmeldungen. Wer dort nachsieht und nichts findet, hat nicht bewiesen, dass keine Anmeldung stattfand — er hat drei von vier Protokollen nicht angesehen.

Die Trennung ist zugleich der Grund, warum sich das Modul zu Workload-Identitäten hier fortsetzt. Ein Dienstprinzipal mit einem Geheimnis und eine verwaltete Identität erscheinen in verschiedenen Protokollen — wer den Bestand seiner Automatisierung prüfen will, muss beide ansehen. Und ein Zugriff, der weder unter den Dienstprinzipalen noch unter den verwalteten Identitäten auftaucht, aber Daten liest, läuft vermutlich unter einem Benutzerkonto: genau das Muster, das im Workload-Modul als Ausgangsproblem stand.

Umgekehrt hilft die Unterscheidung bei der Suche nach ungenutzten Objekten. Eine Anwendungsregistrierung, für die es seit Monaten keinen einzigen Eintrag unter den Dienstprinzipal-Anmeldungen gibt, ist ein Kandidat für den Rückbau — mit derselben Vorsicht wie bei den veralteten Geräteobjekten aus dem Gerätemodul: erst deaktivieren, beobachten, dann entfernen.

Was im Anmeldeprotokoll steht

Ein Eintrag beantwortet mehr als Erfolg oder Misserfolg. Die Angaben, die für eine Diagnose zählen:

Identität und Anwendung

Wer hat sich woran angemeldet — und bei nicht-interaktiven Anmeldungen auch, welcher Client es ausgelöst hat.

Registerkarte Conditional Access

Welche Zugriffsregeln auf diese Anmeldung zutrafen und mit welchem Ergebnis. Bei Regeln im Berichtsmodus gibt es dafür eine eigene Registerkarte.

Fehlercode

Ein AADSTS-Code samt Fehlergrund — die genaueste Angabe im ganzen Eintrag.

Korrelations-ID

Verbindet die Teilschritte eines Vorgangs. Der Bezug, den man beim Nachfragen mitgibt.

Die Registerkarte für Conditional Access ist der wichtigste Teil, weil sie die Frage aus dem entsprechenden Modul beantwortet: Alle zutreffenden Regeln müssen erfüllt sein — hier steht, welche das waren. Ohne sie bleibt nur Raten, welche der zwanzig Regeln gegriffen hat.

Korrelations-ID — Eine Kennung, die zusammengehörige Protokolleinträge eines Vorgangs verbindet. Sie gehört in jede Rückfrage an den Hersteller und in jedes Ticket — sie ist eindeutiger als jede Beschreibung des Zeitpunkts.

Für die Praxis lohnt eine kleine Disziplin: Wer Betroffene um Angaben bittet, fragt nicht nach der Uhrzeit und der Fehlermeldung, sondern nach dem Fehlercode und — sofern die Oberfläche ihn zeigt — nach der Kennung des Vorgangs. Beides ist eindeutig, während „heute Vormittag, es ging nicht“ in einem Protokoll mit tausenden Einträgen keine brauchbare Eingrenzung ist.

Fehlercodes lesen statt raten

Der AADSTS-Code ist die präziseste Angabe eines gescheiterten Anmeldeversuchs. Einige lohnt es auswendig zu kennen, weil sie im Alltag ständig vorkommen:

AADSTS50126

Falscher Benutzername oder falsches Kennwort. Die Dokumentation merkt ausdrücklich an, dass eine gewisse Zahl davon normal ist — Menschen vertippen sich.

AADSTS50076

Eine mehrstufige Authentifizierung ist nötig, etwa wegen einer Zugriffsregel oder eines neuen Standorts.

AADSTS53003

Durch Conditional Access blockiert. Die Regel erlaubt die Tokenausstellung nicht.

AADSTS530035

Durch Sicherheitsstandards blockiert — nicht dasselbe wie eine Zugriffsregel, und an einer anderen Stelle zu ändern.

AADSTS50053

Konto gesperrt. Zwei mögliche Ursachen: zu viele Fehlversuche, oder die Anmeldung kam von einer als bösartig eingestuften Adresse. Welche zutrifft, steht im Fehlergrund.

Daraus folgt eine Regel für jede Auswertung, die Zahlen liefern soll: Ein Anmeldeversuch mit Zwischenschritten erzeugt mehrere Einträge, von denen nur der letzte das Ergebnis trägt. Wer alle Einträge mit einem Code als Fehlschläge zählt, misst die Zahl der Zwischenschritte und nennt sie Fehlerquote. Ein Anstieg dieser Zahl kann dann sogar bedeuten, dass eine neue Prüfung eingeführt wurde und funktioniert.

Ähnlich verhält es sich mit AADSTS50126: Eine gewisse Grundmenge falscher Kennwörter ist normal und kein Befund. Interessant wird sie erst im Muster — viele Fehlversuche auf viele verschiedene Konten in kurzer Zeit sehen anders aus als die üblichen Vertipper, und AADSTS50053 unterscheidet in seinem Fehlergrund sogar ausdrücklich zwischen zu vielen Fehlversuchen und einer als bösartig eingestuften Herkunft.

Das Überwachungsprotokoll beantwortet die andere Hälfte

Während das Anmeldeprotokoll den Zugriff zeigt, zeigt das Überwachungsprotokoll die Veränderung. Es umfasst laut Dokumentation jedes protokollierte Ereignis im Verzeichnis — Änderungen an Anwendungen, Gruppen, Benutzern und Lizenzen.

Für die Fehlersuche ist es das erste Werkzeug bei jeder Störung, die einen Anfangszeitpunkt hat. Die Frage lautet nicht „Was ist kaputt?“, sondern „Was wurde in den Stunden vor der ersten Beschwerde geändert?“ — und diese Frage ist beantwortbar, während die erste es meist nicht ist.

Neben den beiden gibt es weitere Aktivitätsprotokolle, darunter das Bereitstellungsprotokoll. Für den Anfang genügt die Zweiteilung: Zugriff und Änderung.

Bemerkenswert am Überwachungsprotokoll ist, wie breit es ist. Es erfasst nicht nur die offensichtlich sicherheitsrelevanten Vorgänge, sondern auch Lizenzzuweisungen, Gruppenänderungen und Änderungen an Anwendungen — also genau die Ereignisse, die in den vorigen Modulen jeweils die Ursache eines rätselhaften Verhaltens waren. Die verschwundene Lizenz aus dem Gruppenmodul, die geänderte Zugriffsregel, die neu erteilte Anwendungsberechtigung: Alle drei haben hier einen Eintrag mit Zeitpunkt und Urheber.

Die Aufbewahrung ist die härteste Grenze

Hier steht die Zahl, die jede Untersuchung begrenzt und die man kennen muss, bevor man sie braucht.

Microsoft Entra ID Free

Sieben Tage.

Microsoft Entra ID P1

30 Tage.

Microsoft Entra ID P2

30 Tage.

Das ist keine Einstellung, die sich hochdrehen lässt. Ein Vorfall, der sechs Wochen zurückliegt, ist in den Entra-eigenen Protokollen nicht mehr untersuchbar — unabhängig davon, wie wichtig er ist und welche Lizenz man hat.

Zwei weitere Feinheiten stehen in derselben Dokumentation und sind bei einer Umstellung wichtig. Erstens beginnt die Sammlung je nach Edition zu verschiedenen Zeitpunkten: mit der kostenpflichtigen Edition ab Abschluss des Abonnements, mit der kostenlosen erst beim ersten Öffnen des Portals oder der Nutzung der Berichts-Schnittstellen. Zweitens dauert es nach einer Höherstufung bis zu drei Tage, bis Daten in den Berichten erscheinen, wenn zuvor keine vorhanden waren.

Für die Praxis heißt das: Wer heute höherstuft, hat morgen noch keinen 30-Tage-Rückblick. Die längere Aufbewahrung gilt ab jetzt, nicht rückwirkend — genau wie beim Export. Beides sind Entscheidungen, deren Nutzen erst in der Zukunft entsteht, und beide werden erfahrungsgemäß erst nach dem ersten Vorfall getroffen, für den sie gebraucht worden wären.

Nicht dasselbe Protokoll

Eine Verwechslung kostet regelmäßig eine halbe Untersuchung: Die Entra-Überwachungs- und Anmeldeprotokolle sind laut Dokumentation getrennt vom einheitlichen Überwachungsprotokoll von Microsoft 365.

Dessen Aufbewahrung wird über Microsoft Purview verwaltet und ist von Lizenzänderungen in Entra nicht betroffen. Wer im falschen Protokoll sucht, findet je nach Fragestellung entweder nichts oder etwas, das eine andere Frage beantwortet.

• Postfachzugriffe, Dateizugriffe und Aktivitäten in den Diensten stehen im Protokoll von Microsoft 365.
• Anmeldungen, Rollenzuweisungen, Gruppenänderungen und Anwendungszustimmungen stehen in den Entra-Protokollen.
• Ein Vorfall, bei dem jemand fremde Postfächer gelesen hat, braucht beide: die Entra-Seite für den Zugang, die Microsoft-365-Seite für die Zugriffe.

Nicht-interaktive Anmeldungen: viel Volumen, wenig Beachtung

Die nicht-interaktiven Anmeldungen sind in fast jedem Tenant die mit Abstand größte Gruppe — jeder Client, der still ein Token erneuert, erzeugt Einträge. Genau deshalb werden sie übersehen.

Für zwei Fragen sind sie trotzdem die richtige Quelle. Erstens: Nutzt ein Zugriff noch ein Verfahren, das abgelöst werden soll? Zweitens: Ist eine Anmeldung, die als Benutzeranmeldung erscheint, tatsächlich von einem Menschen ausgelöst worden? Bei einer ortsbezogenen Auffälligkeit — dem Fall aus dem Modul zum Identitätsschutz — beantwortet diese Unterscheidung die Frage, ob überhaupt ein Mensch beteiligt war.

Die Diagnose einer blockierten Anmeldung

Für den häufigsten Fall — jemand kommt nicht hinein — gibt es eine Reihenfolge, die zuverlässig zur Ursache führt.

Der letzte Schritt ist der, der am häufigsten fehlt. Ein Fehlercode sagt, was blockiert hat — nicht, warum es gestern noch ging. Diese Antwort steht im Überwachungsprotokoll, und sie ist meist die eigentlich gesuchte.

Was die Protokolle nicht beantworten

Zur ehrlichen Einordnung gehören die Grenzen.

• Sie sagen nicht, ob eine erfolgreiche Anmeldung berechtigt war. Ein Angreifer mit gültigem Nachweis erzeugt einen unauffälligen Eintrag.
• Sie sagen nichts über Vorgänge außerhalb ihres Aufbewahrungszeitraums — und dieser Zeitraum ist kurz.
• Sie decken die Dienste von Microsoft 365 nicht ab; dafür gibt es ein eigenes Protokoll an anderer Stelle.
• Sie ersetzen keine Alarmierung. Ein Protokoll, in das niemand sieht, meldet nichts.

Der letzte Punkt ist der, an dem dieses Modul an den Nachbartrack übergibt: Aus einem Protokoll wird erst dann Betrieb, wenn jemand definiert hat, welches Ereignis eine Reaktion auslöst und wer sie durchführt.

Durchgerechnet: Zugriff seit heute Morgen blockiert

Der Preis dieses Vorgehens sind zehn bis zwanzig Minuten, während Betroffene warten — und der Druck, stattdessen die zuletzt geänderte Regel einfach abzuschalten. Das würde funktionieren und hinterlässt einen Tenant, in dem niemand mehr weiß, welcher Schutz warum fehlt. Die Diagnose ist der Unterschied zwischen einer Behebung und einer Beseitigung des Symptoms.

Die Reihenfolge, die alles zusammenhält

Die wichtigste Entscheidung dieses Moduls fällt nicht während einer Störung, sondern lange davor: ob die Protokolle über ihre sieben oder dreißig Tage hinaus aufbewahrt werden. Alles andere lässt sich im Ernstfall nachholen — diese eine Entscheidung nicht.