Audit Account Logon vs. Logon/Logoff

Dieser Artikel erschien zuerst auf Ralfs Blog. Der Artikel basiert weitgehend auf dem (englischsprachigen) Artikel von Eric Fitzgerald.

Beim Einstellen einer Überwachungsrichtlinie auf einem DC kann man sowohl Anmeldeversuche als auch Anmeldeereignisse protokollieren lassen. Aber warum gibt es zwei Kategorien? Und was ist der Unterschied?

Anmeldeversuche Account Logon und Anmeldeereignisse (Logon/Logoff)

Nun, die Antwort auf die erste Frage ist recht einfach – die Namenswahl war schlecht.

“Anmeldeversuche” (“Account Logon”) meint eigentlich die Überprüfung von Logindaten (Credentials) und weniger das eigentliche “Anmeldeereignis” (“Logon”). Hier also nun der Unterschied zwischen Anmeldeveruschen und Anmeldeereignissen, und wie man die Ereignisse interpretiert.

“Anmeldeereignis” erzeugt Events beim Anlegen und Beenden einer Logon-Sitzung. Diese Events geschehen auf dem Server, auf den zugegriffen wird. Im Falle eines interaktiven Logon also auf der Maschine, an der man sich anmeldet. Bei einem Netzwerk-Logon (also zum Beispiel beim Zugriff auf eine Freigabe) entstehen diese Events auf der Maschine, die die angeforderten Ressourcen vorhält.

“Anmeldeversuche” erzeugt Events für die Überprüfung der Logon-Informationen. Diese Events entstehen auf der Maschine, die für die Überprüfung autorisiert ist. Bei Domänenkonten ist dies der Domaincontroller (DC), bei lokalen Konten die jeweilige Maschine selbst. Da in Enterprise-Umgebungen mehr Domänenkonten verwendet werden als lokale Konten, treten die meisten Account Logon Events auf den Domaincontrollern auf. Trotzdem könnne diese Events auf beliebigen Servern auftreten, mit oder ohne Zusammenhang mit Logon/Logoff-Events.

Das interaktive Einloggen an einer Workstation mit einem Domänenkonto löst jede Menge Ereignisse auf dem DC aus, mehr als man vermuten würde. Dieser komplexe Prozess beinhaltet mehrere Schritte. Typischerweise passiert vom Einschalten der Workstation bis zum Erscheinen des Desktops Folgendes:

– Der Client baut eine Vertrauensstellung mit der Domäne auf: Kerberos AS Anfragen (Event 672 ( auf dem DC), Kerberos TGS Anfragen für das AD (DC, 673)

– Client bekommt seine Policy: Kerberos TGS ANfrage für den Zugriff auf das NETLOGON-Share auf dem DC [Gruppenrichtlinien] (DC, 673)(DC, 540,538, evtl. mehrmals)

– Benutzer meldet sich an: Kerberos AS Anfrage (DC, 672), Kerberos TGS Anfrage für AD (DC, 673), Logon Sitzung wird gestartet (workstation, 528, 576)

– Benutzer bekommt Policy: Kerberos TGS Anfrage für DC\Netlogon [Logon Scripts, Gruppenrichtlinien] (DC, 673), Network Logon (DC, 540, 538, oft 2-3 Wiederholungen)

Bei Account Logon Fehlern für Kerberos muß der KDC eine AS Antwort mit einem Fehler nach RFC 1510 erzeugen. Da die RFC 1510 Codes nicht den windows-spezifischen Fehlern entsprechen, der KDC aber eine RFC-Antwort liefern muß, benötigt man ein Mapping zwischen den Kerberos Fehlercodes und den Windows Fehlermeldungen. Dieses Mapping ist beschrieben im Kerberos Troubleshooting Dokument.

Hier ein paar Fragen, die sich für Account Logon Ereignisse stellen:

F: Waum sehe ich nur IP Adressen im Account Logon Event und nicht den Computernamen?

A: Dafür gibt es drei Gründe: 1) Zu diesem Zeitpunkt im Login Prozess gibt es noch keine zuverlässige Methode für den KDC, den Namen zu ermitteln. Übermittelt der Client den Namen (wie in NTLM), dann ist das nicht vertrauenswürdig und kann gefälscht sein.

2) DNS und NetBIOS reverse Lookups sind nicht sicher und nicht vertrauenswürdig, und nebenbei würde sich auch die performance verschlechtern.

3) Auch wenn der Name trotzdem einfach mitgeliefert werden soll, gibt es dennoch kein Feld dafür in Kerbers AS REQ und TGS REQ Paketen, man müßte also ein anderes Feld überladen oder mißbrauchen und läuft damit Gefahr, nicht mehr kompatibel zu sein mit der MIT Referenzimplementierung von Kerberos.

F: Wie korreliere ich das Account Logoin Event auf dem DC mit dem Logon/Logoff Event der Maschine, auf die zugegriffen wurde?

A: Ganz einfach! Ab Windows Server 2003 enthalten beide Events ein Feld namens Logon GUID. Stimmen beide überein, handelt es sich um das selbe Kerberos-Ticket. Dummerweise funktioniert das nur bei Kerberos, andere Logon Events enthalten eine GUID, die aus lauter Nullen besteht.

F: Gibt es sowas wie ein Account Logoff Event?

A: Nein. Der DC bekommt nur die Logons mit, nicht die Logoffs.

F: Reicht es, wenn ich nur die DC Eventlogs monitore?

A: Nun, der DC hat eine entwas eingeschränkte Sicht auf das Logon wie oben schon beschrieben. Außerdem weiß der DC nur, von wo die letzte Anfrage kommt. Bei einem IIS entsteht zum Beispiel die Logon-Anfrage irgendwo im Internet. Der IIS empfängt die Anfrage und sendet seinerseits eine Logon ANfrage an den DC. Aus Sicht des DC ist die Quelle der Anfrage der IIS. Protokolliert man also nur die DC Anfragen, verliert man die information, wo die Anfrage iegentlich herstammt. Gleiches gilt für jede Art von Netzanfragen – RPC, Dateifreigaben, Remote Desktop etc. Lediglich in den Events 673 (Kerberos Service Ticket granted) steht der Servicename drin – man weiß also wenigstens, warum der Benutzer sich angemeldet hat.