Den ADFS-Token-Prozess auswerten

Herauszufinden, was bei ADFS genau passiert, ist gar nicht so einfach. Vor einiger Zeit haben wir vorgestellt, wie sich das Debug-Logging einsetzen lässt:

[ADFS: Debug-Logging einschalten und auswerten | faq-o-matic.net]
http://www.faq-o-matic.net/2016/06/29/adfs-debug-logging-einschalten-und-auswerten/

Leider fehlen bei dieser Protokollierung aber die Informationen, welche Eigenschaften ein User beim Anmeldeversuch mitbringt und welche Informationen ADFS in das SAML-Token schreibt. Näheren Aufschluss über diese Daten gibt die Sicherheitsüberwachung auf dem ADFS-Server. Wie alles im Zusammenhang mit ADFS ist aber auch dieser Weg ein steiniger.

Genau wie das Debug-Logging verlangt auch die Sicherheitsüberwachung, dass man sie zunächst einrichtet. Das ist etwas aufwändiger, und es erzeugt unter Umständen sehr viele Daten. Daher empfiehlt es sich auch hier, diese Überwachung nur gezielt zeitweise zu aktivieren und sie zügig wieder abzuschalten.

Die Schritte zum Aktivieren beschreibt der folgende TechNet-Artikel:

[Configuring Computers for Troubleshooting AD FS 2.0]
https://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(WS.10).aspx#bkmk_ConfigureAuditing

Die Überwachung muss man also gleich an drei Stellen einschalten:

• Auf Server-Ebene unter den Benutzerrechten (einmalig)
  Hier legt man fest, dass Windows Sicherheitsereignisse für bestimmte Benutzer protokollieren soll. Wichtig ist in diesem Fall der Dienstaccount für ADFS.
• In der Sicherheitsrichtlinie (pro Auswertungs-Session)
  Hier weist man Windows an, die Ereigniskategorie “Application generated” aufzuzeichnen.
• In der ADFS-Dienstkonfiguration (einmalig)
  Hier wiederum sagt man ADFS, dass es seine Sicherheitsereignisse an das Protokoll schicken soll.

Besonders der zweite Schritt mit der Sicherheitsrichtlinie ist nicht ganz einfach, denn schlauerweise hat Microsoft diesen Bereich in verschiedene Sprachen übersetzt. Eine universelle Lösung arbeitet daher nicht mit dem Namen der Ereigniskategorie, sondern mit der zugeordneten ID. Das folgende Kommando sorgt für die Aktivierung, man muss es mit Administratorrechten ausführen.

auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:enable /success:enable

Diese Einstellung kann man auch rückgängig machen. Führt man die beiden Schritte per Batch aus, dann hat man eine einfache Möglichkeit, bedarfsgesteuert die Protokollierung ein- und auszuschalten.

auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:disable /success:disable

Vorbereitete Batchdateien zum Ein- und Ausschalten finden sich im Download zu diesem Artikel.

Die relevanten Ereignisse finden sich dann im Sicherheits-Ereignisprotokoll, sie tragen die Event-IDs 299, 500 und 501. Die Zusammenhänge zwischen den Ereignissen hat John Craddock vor einiger Zeit in einem Vortrag dargestellt:

Quelle: http://www.slideshare.net/technetbelux/troubleshooting-federation-adfs-and-more

Nun hat man allerdings ein Problem. Die wichtigen Ereignisse verteilen sich nicht nur über drei Event-IDs, sondern pro Vorgang kann es eine ganze Reihe von Ereignissen geben. Die Informationen zum Token etwa finden sich in den IDs 500 (ausgehende Claims) und 501 (eingehende Claims) und verteilen sich dort meist über mehrere Einträge. Den Zusammenhang zwischen diesen Einträgen stellt eine Instance ID dar, die im Text des Event-Eintrags auftaucht. Diese Instance ID ist dabei rein intern, der Anwender und der Admin sehen sie (normalerweise) nirgends. Im Fall eines Fehlers bekommt der Anwender manchmal eine Activity ID angezeigt – die ist aber nicht mit der Instance ID identisch. Sie taucht allerdings ebenfalls in manchen Event-Einträgen auf, daher kann man sie zuordnen. Auf die Weise erhält man einen Überblick über die ein- und ausgehenden Daten, die für die Anmeldung eines Users verwendet werden. Das kann z.B. nützlich sein, um Anmeldefehlern auf die Spur zu kommen oder um zu prüfen, ob das Regelwerk wie gewünscht arbeitet.

An dieser Stelle ist ein Skript hilfreich, das die zusammengehörigen Einträge aus dem Sicherheits-Ereignisprotokoll sammelt und gemeinsam darstellt. Zu diesem Zweck habe ich ein PowerShell-Skript geschrieben, das genau dies tut. Man startet es direkt auf dem ADFS-Server, der die Ereignisse gesammelt hat. Am besten eignet sich dafür die PowerShell ISE, die man als Administrator starten sollte.

Das Skript ruft man ohne Parameter auf. Es fragt dann zunächst nach einer Auswahl der Rohdaten (Ereigniseinträge), die man betrachten will:

• die letzten 1000 Einträge (bezieht sich auf das gesamte Log, nicht nur auf die drei Event-IDs)
• die Einträge der letzten 24 Stunden
• die Einträge der letzten Stunde
• eine Auswahl nach Datum (Beginn und Ende)
• alle Ereignisse

Nach der Auswahl liest das Skript die betreffenden Einträge und filtert diejenigen mit den IDs 299, 500 und 501 heraus. Das kann einen Moment dauern.

In der Hauptschleife bietet das Skript die Auswertung der Ereignisse:

• alle Instance IDs anzeigen
• Instance IDs zu Activity IDs zuordnen
• die Instance ID(s) zu einer bestimmten Activity ID anzeigen
• alle Token-Ausgaben anzeigen (Event-ID 299)
• alle Details zu einer bestimmten Instance ID anzeigen (Event-IDs 299, 500 und 501)
• Token-Ausgabe für eine bestimmte Instance ID anzeigen (Event-ID 299)
• eingehende Claims für eine bestimmte Instance ID anzeigen (Event-ID 501)
• ausgehende Claims für eine bestimmte Instance ID anzeigen (Event-ID 500)
• einen Text in allen Meldungen suchen

Das Skript zeigt dann alle Ereignisse an, die zu der Auswahl passen. Die einzelnen Meldungen aus dem Eventlog fasst es dabei pro Instance ID zusammen, man sieht also immer alle Einträge, die zu einem Vorgang gehören, gemeinsam. Das ist die entscheidende Leistung des Skripts: Man muss die EInträge nicht manuell zuordnen.

Nach der Anzeige bietet das Skript sofort eine neue Auswahl auf Basis derselben Daten an. Da man meist länger an einem bestimmten Vorgang analysieren muss, hat man so die Möglichkeit, zügig weiter zu suchen, ohne jedes Mal das Skript neu zu starten und die Daten neu einzulesen.

Hier der Download:

  Get-ADFSSecurityLogEntry.ps1 (3,6 KiB, 1.085-mal heruntergeladen, letzte Änderung am 9. November 2016)