Anwender denken häufig, dass die Administratoren einen perfekten Überblick über jede noch so geringe Aktivität besitzen, die sie auf ihrem PC ausführen. Das gilt besonders für Nutzer, die in einem Firmennetzwerk mit Active Directory arbeiten: Gerade die vielfältigen Möglichkeiten, die den Systembetreuern mit den mächtigen Gruppenrichtlinien-Objekten (GPO - Group Policy Object) zur Verfügung stehen, erwecken den Eindruck der Allmacht der IT.
Doch die Komplexität moderner Systeme fordert auch hier ihren Tribut: So sind Administratoren in Windows-Netzwerken weit davon entfernt, alle Tätigkeiten ihrer Nutzer komplett überwachen zu können. Manchmal ist es für die Systemverwalter schon schwer festzustellen, wann und wo ein Nutzer sich angemeldet hat, und vor allen Dingen auch, wie lange er an einem System gearbeitet hat.
Bei unseren Recherchen haben wir festgestellt, dass es viele Ereignisse gibt, die das Windows-System rund um das An- und Abmelden protokollieren. Wir versuchen, einen Überblick darüber zu geben, und geben Tipps, die bei den Nachforschungen im Bereich An- und Abmeldung hilfreich sein können. Dazu ist es allerdings erforderlich, sich eingehender mit den unterschiedlichen Anmeldevorgängen unter Windows auseinanderzusetzen. Wir beziehen uns hierbei auf die derzeit gängigen Windows-Systeme; etwaige Unterschiede sind jeweils vermerkt.
Der "normale Fall": Anmeldung am PC
Meldet sich ein Anwender an einem Desktop-System an - also einem "normalen" Windows-Rechner, der sich nicht in einer Windows-Domäne befindet -, so funktioniert dies ausschließlich mit einem lokalen Konto. Es handelt es sich dabei um ein Konto, das beispielsweise auf einem Windows-7-System in der Systemsteuerung unter Benutzerkonten und Jugendschutz/Benutzerkonten angelegt wurde.
Abgelegt werden die Benutzerinformationen (Name/Kennwort) als Hash-Wert in einer Datenbank, die bei den Windows-Systemen von der Sicherheitskontenverwaltung (SAM - Security Accounts Manager) bearbeitet wird. Sie ist normalerweise unter dem Pfad %windir%\system32\config\SAM zu finden.
Der Systemdienst lsass.exe (Local Security Authority Subsystem Service) ist für das Durchsetzen der Sicherheitsrichtlinien auf den Windows-Systemen zuständig: Er überprüft die Benutzerinformation sowohl bei einer lokalen Anmeldung an einer Workstation als auch bei einer Anmeldung an einem Server, schreibt die entsprechenden Informationen in die Sicherheitsprotokolle (Log-Dateien), stellt ein Access Token zur Verfügung und verarbeitet beispielsweise auch Änderungen eines Passwortes.
Verwirrung mit System: die Ereignis-IDs
Bei der Arbeit mit einer lokalen Workstation finden Authentifizierung und Anmeldung natürlich auf dem gleichen Windows-System statt. Deshalb tauchen auf diesen Systemen auch zwei Ereignisse auf: ein Logon/Logoff-Event (4624/ 528) und ein sogenannter Account-Logon-Event (4776/ 680).
Leider kommt für die Ereignis-IDs auf Systemen ab der Generation Windows Server 2008 (und damit auch auf den Client-Systemen ab Windows Vista) ein anderes System bei der Nummerierung zum Einsatz, als es bei den Windows-Versionen XP und Windows Server 2003 der Fall war: So ist beispielsweise ein Logon/Logoff-Ereignis auf den Servern unter Windows 2000 und Windows 2003 noch mit der ID 528 in das Sicherheitsprotoll eingetragen, während die neuen Windows-Systeme ab Windows Server 2008 dafür die ID 4624 vermerken.
Glücklicherweise hat Microsoft dieses System mit den ganz aktuellen Releases Windows Server 2012 und Windows nicht noch einmal überarbeitet, sodass wir hier für jede Ereignis-ID zwei Werte angeben: aktuell (ab Windows Server 2008/Windows Vista) und die ältere Version für die Windows-Systeme dafür. Wer eine umfassendere Übersicht über die Security-Audit -vents ab Windows Server 2008 R2/Windows 7 benötigt, kann sich eine Excel-Tabelle mit einer entsprechenden Auflistung in englischer Sprache bei Microsoft herunterladen. Dort finden sich dann auch alle Account-Logon- sowie Logon/Logoff-Events aufgelistet.
Wenn ein PC gleichzeitig Mitglied einer Domäne ist, kann bei der Anmeldung eine Entscheidung getroffen werden: Der Computer kann mittels eines lokalen Kontos, wie zuvor beschrieben, oder mit einem Domäne-Konto am Server angemeldet werden. Zudem ist es möglich, den Rechner an jeder anderen Domäne anzumelden, der die eigene Domäne vertraut. Was ändert sich dabei im Vergleich zum "normalen" Anmelden an einem Windows-Rechner? Wenn der Anwender sich für die Anmeldung mittels eines Domänen-Kontos entscheidet, ist das lokale Windows-System nicht mehr in der Lage, die Authentifizierung durchzuführen - es besitzt schließlich keinen weiteren Zugriff auf die benötigten Daten als auf die Hash-Werte von Benutzerdaten und Passwort.
Anmeldung an einer Domäne
Bei der Anmeldung an einer Domäne wird aus den oben beschriebenen Gründen via Kerberos eine Anfrage an den Domänen-Controller der Domäne geschickt, an der sich der Anwender anzumelden versucht. Auf dem Domänen-Controller, der diese Anfrage bearbeitet, wird ein Authentifizierungs-Event bei den Sicherheitsereignissen eingetragen. Dabei handelt es dann um ein Ereignis mit der ID 4768/ 672 mit der Bezeichnung "A Kerberos Authentification Ticket (TGT) was requested".
Hat der Domänen-Controller die Anfrage positiv beantwortet und dem PC die Rückmeldung gegeben, dass der fragliche Nutzer authentifiziert wurde, so kann die Workstation nun damit fortfahren, die Anmeldesitzung anzulegen. Dabei wird auf diesem Client-System dann das entsprechende Anmeldeereignis mit der ID 4624/ 528 in das Ereignisprotokoll für die Sicherheit eingetragen.
Meldet sich der Benutzer des Windows-PCs mit einem Konto an, das zu einer anderen Domäne gehört, der aber von der eigenen Domäne vertraut wird, so muss der Domänen-Controller in dieser anderen Domäne die Authentifizierung durchführen. In seinem Sicherheitsprotokoll wird dann das Kerberos-Ereignis mit der ID 4769/ 672 auftauchen, wohingegen weiterhin auch in diesem Fall die ID 4624/ 528 in das entsprechende Log des Client-Rechners geschrieben wird. So kann anhand der reinen ID auf dem Client-System auch nur festgestellt werden, dass sich der Client erfolgreich authentifizieren konnte; erst ein Blick in die Ereignisanzeige und die Ereigniseigenschaften gibt dann den Namen der entsprechenden Domäne preis.
Bei allen interaktiven Anmeldeaktionen schreibt das System auch ein Ereignis mit der Bezeichnung "Benutzerinitiierte Abmeldung" und der ID 4647/ 551 in das Protokoll. Hier findet sich zudem eine hexadezimale Anmelde-ID, die ein Administrator mit der entsprechenden ID in einem Anmeldeereignis korrelieren kann und somit einen Überblick über die Sitzung des Anwenders erhält. Allerdings sind die Anmelde-IDs nur zwischen den Neustarts auf dem gleichen System eindeutig.
Dateifreigaben und die verschiedenen Typen einer Anmeldung
Anwender, die sich im Netzwerk an ihrem PC angemeldet werden, möchten in der Regel danach wieder die Verbindung zu den Dateifreigaben auf den verschiedenen Dateiservern vorfinden. Auch für diese Verbindung ist eine Anmeldung an dem entsprechenden Serversystem mit den richtigen Berechtigungen selbstverständlich notwendig.
Dabei ist interessant, welche Daten bei dieser Form der Anmeldung aufgezeichnet und in den Sicherheitsprotokollen ablegt werden. In diesem Fall handelt es sich bei der Anmeldung um eine "Netzwerkanmeldung" an dem Dateiserver. Wie geht der Server mit einer derartigen Anmeldung um? Jeder Anwender wird annehmen, dass ein solcher Vorgang auf die gleiche Art und Weise abläuft wie bei der interaktiven Anmeldung eines Nutzers: Die Sitzung beginnt, wenn der Anwender eine Verbindung zur Dateifreigabe aufbaut, und endet erst dann, wenn er diese wieder trennt. Diese Trennung von der Dateifreigabe wird dabei - so die Vermutung - automatisch erfolgen, sobald sich der Nutzer von seinem lokalen PC abmeldet, der diese Verbindung aufgebaut hat.
Das ist aber in der Praxis nicht der Fall: Die Windows-Server halten die Netzwerksitzungen nur so lange offen, wie der Anwender, der darauf zugreift, auf dem Server eine Datei geöffnet hat. Dadurch finden sich im Ereignisprotokoll des Dateiservers in der Regel sehr viele An- und Abmeldevorgänge eines Nutzers während eine einzigen Tages: Jedes Mal, wenn er die Datei wieder öffnet, meldet sich seine Workstation an dem Server mittels Netzwerkanmeldung dort an und nach dem Schließen der Datei auch wieder ab. Bis zu Windows Server 2003 waren diese Anmeldeereignisse noch leicht zu unterscheiden, da sie dort mit der ID 540 im Gegensatz zur interaktiven Anmeldung mit der ID 528 protokolliert wurden: Seit Windows Server 2008 werden alle Anmeldereignisse mit der ID 4624 ins Protokoll geschrieben.
Genauso sieht es aus, wenn sich der Administrator direkt an einem Server anmeldet: In den meisten Fällen wird dies in der Praxis über eine Remote-Desktop-Sitzung geschehen. Aber diese wird ebenso wie die normale Anmeldung via Tastatur und Bildschirm am Server ebenfalls mit der ID 4624/ 528 protokolliert. Wer an dieser Stelle mehr über die Art der Anmeldung erfahren will, muss nun die Eigenschaften des Ereignisse wechseln und sich dort den Typ der Anmeldung anschauen, die dort vermerkt sind. Sie werden an dieser Stelle ebenfalls durch eine eindeutigen ID und eine kurze Beschreibung angezeigt. Wir haben zudem eine Tabelle zusammengestellt, die einen Überblick über die häufig auftretenden Typen der Anmeldung auf einem Windows-System gibt - deren Identifikationen wurden zum Glück auch nicht geändert und finden sich einheitlich sowohl auf Windows-XP- als auch auf Windows-8- und Windows-Server-2012-Systemen wieder.
Unterschiede: Ereignisse auf Domänen-Controller und Workstation
Geht es um die Einordnung von Anmeldeinformationen und Authentifizierung, dann tauchen immer wieder Missverständnisse auf: Wenn sich ein Anwender mittels eines Domänen-Controllers (DC) anmeldet oder auf einen freigegebenen Ordner in der Domäne zugreift, dann meldet er sich streng genommen nicht bei der Domäne an - der DC authentifiziert den Anwender nur, legt also fest, dass dieser die richtigen Zugriffsrechte besitzt, um auf die Ressourcen in der Domäne zugreifen zu können.
Der DC ist in keinem Fall die zentrale Stelle im Windows-Netzwerk, die festhält, wer gerade irgendwo in der Domäne an irgendeiner Arbeitsstation angemeldet ist oder wann er sich wieder abgemeldet hat. Jeder Windows-Rechner verwaltet seine eigenen Anmeldesitzungen, und so protokolliert der Domänen-Controller auch nicht, ob ein Nutzer über eine Remote-Sitzung oder über eine Netzwerkfreigabe in der Domäne aktiv ist.
Administratoren, die sich die entsprechenden Ereignisprotokolle auf ihren Domänen-Controller genauer ansehen, finden dabei häufig Paare von An- und Abmeldungen, auf die direkt Ereignisse zur Authentifizierung folgen und den gleichen Nutzer betreffen. Dabei handelt es sich in der Regel um Ereignisse, die vom entsprechenden Client für die Gruppenrichtlinien auf dem lokalen System verursacht werden, der in diesen Fällen die Gruppenrichtlinien-Objekte vom Domänen-Controller herunterlädt, damit sie auf dem Client-System eingesetzt werden können. Wenn es die Systemverwalter nicht anders konfiguriert haben, holen die Windows-Systeme alle 90 Minuten die Gruppenrichtlinien vom Domänen-Controller ab und erzeugen dabei jeweils ein Netzwerk-An- und -Abmeldeereignis im Sicherheitsprotokoll des Servers. Durch diese Regelmäßigkeit werden diese Ereignisse manchmal bei forensischen Untersuchungen mit herangezogen, um eine ungefähre Vorstellung davon zu erlangen, wie lange ein Anwender wohl angemeldet gewesen ist-- immer davon ausgehend, dass diese Ereignisse mit einer zuvor stattgefundenen interaktiven oder Remote-Anmeldung des Anwenders in Einklang zu bringen sind. Für den täglichen Betrieb ist diese Methode aber in der Regel zu aufwendig und zu ungenau.
Was kann man aus Ereignissen ablesen?
Wer unseren Ausführungen bis hierher gefolgt ist, mag nun vielleicht zu dem Schluss gekommen sein, dass die Ereignis-IDs ihm wenig oder überhaupt nicht nützen. Das ist sicher so nicht richtig, und wir wollen hier auf keinen Fall in Abrede stellen, dass diese Einträge in den Windows-Protokollen wichtig sind. Allerdings gibt es für Administratoren, die diese Ereignisse zur Kontrolle verwenden wollen, einige einschränkende Fakten, die sie beachten sollten, wenn sie auf diese Daten zurückgreifen:
• Wollen Sie sicher feststellen, auf welche Art und Weise sich ein Anwender angemeldet hat, so finden Sie diese Daten nur auf dem System, auf dem er sich angemeldet haben. Sie müssen also das entsprechenden Anmeldeereignis im Protokoll des entsprechenden Client-Rechners finden.
• Entsprechende Daten auf dem Domänen-Controller zu finden ist nur sehr schwer oder gar nicht möglich und beinhaltet sehr viele Vermutungen beziehungsweise sehr umfangreiche Nachforschungen (Stichwort: Forensische Untersuchungen).
• Das Gleiche gilt für die Abmeldung und damit für den Zeitraum, den ein Anwender an einem System verbracht hat: Sie müssen das Ereignis 4647/ 551 (Benutzerinitiierte Abmeldung) auf dem entsprechenden Windows-Client finden.
• Leider besteht keine direkte Verbindung zwischen Authentifizierungsereignissen auf einem Domänen-Controller und den entsprechenden Anmeldeereignissen auf einem Client oder einem Member-Server. Wer im Internet recherchiert, wird immer wieder Hinweise auf das Feld Anmelde-GUID auf dem Domänenserver finden: Leider stimmen diese nach unseren Erfahrungen nicht immer überein oder werden überhaupt nicht angezeigt
|
Logon-Typ |
Bezeichnung |
Beschreibung |
|
2 |
Interaktiv |
Die "normale" interaktive Anmeldung via Tastatur/Bildschirm. Hinweis: Anmeldungen via KVM oder KVM über IP werden von Windows auch unter diesem Typ abgespeichert. |
|
3 |
Netzwerk |
Wenn von einem anderen Standort über das Netz, beispielsweise einem Netzwerk-Share, auf das System zugegriffen wird. |
|
4 |
Batch |
Wenn Windows eine geplante Aufgabe (scheduled task) ausführt, führt der entsprechende Dienst (Scheduled Task Service) eine solche Anmeldung mit den benötigten Berechtigungen am System durch. |
|
5 |
Service |
Das gleiche Vorgehen wie bei "Batch" für andere Systemdienste, die sich anmelden |
|
7 |
Unlock |
Tritt auf, wenn ein mit Screen-Saver abgesperrtes Konto wieder freigeschaltet wird. |
|
8 |
Netzwerk(Klartext) |
Wird nur sehr selten auftauchen, da Windows-Server bei Dateifreigaben und Druckern keine Netzwerkverbindung erlauben, bei denen die Authentifizierung im Klartext erfolgt. |
|
9 |
NewCredentials |
Tritt auf, wenn zum Beispiel ein "runas"-Kommando verwendet wird, um ein Programm mit den Rechten eines anderen Kontos zu starten (Schalter /netonly) |
|
10 |
Remote Interactive |
Wenn ein Anwender über Terminal-Dienste, Remote-Desktop oder Remote-Unterstützung auf das System zugreift. |
|
11 |
Cached Interactive |
Ein spezielles Feature, das die Windows-Systeme für die Anmeldung von mobilen Anwendern bereitstellen. Ermöglicht die Anmeldung am System mit einem Domänenkonto, wenn gerade kein Zugriff auf den Domänen-Controller möglich ist. Windows bewahrt dabei die Hash-Werte der letzten zehn interaktiven Anmeldungen am DC auf. |
Praxistipp: Überwachungsrichtlinien einschalten
Zum Abschluss wollen wir noch einen kleinen Ausflug in die Praxis unternehmen und das Einschalten der Sicherheitsrichtlinien erläutern, die eine entsprechende Verfolgung der zuvor geschilderten Ereignisse bei der An- und Abmeldung ermöglichen. Während auf einigen Domänen-Controllern diese Sicherheitsrichtlinien automatisch "scharf" geschaltet sind, müssen diese beispielsweise auf Member-Serven vom Administrator eingeschaltet werden. Mithilfe dieser Richtlinien ist es zudem ebenso gut möglich, entsprechende Protokollierungen auszuschalten, wenn sie aus den zuvor geschilderten Gründen zu viel "Rauschen" auf dem System durch viele protokollierte Ereignisse erzeugen.
Um diese Überwachungsrichtlinien zu bearbeiten, muss der Administrator die Gruppenrichtlinienverwaltung (GPMC - Group Policy Management Console) verwenden. Dies geschieht ausschließlich mit einem Domänen-Konto beziehungsweise einem Computer, der dieser Domäne beigetreten ist und dort administrative Rechte besitzt. Aufgerufen wird diese in der MMC bereitgestellte Konsole mittels Eingabe von Windows-Taste +R und gpmc.msc. Während diese Konsole auf den Serversystemen bereits vorhanden ist, müssen für den Einsatz auf einem Client-System die entsprechenden Remoteserver-Verwaltungstools (RSAT) installiert werden, damit die GPMC beispielsweise auch auf einem Windows-7-Rechner zum Einsatz kommen kann.
Wichtig: Die Remoteserver-Verwaltungstools stehen jeweils in spezifischen Versionen für die betreffenden Windows-Systeme zur Verfügung. So steht auf den Microsoft-Webseiten beispielsweise eine spezielle Version für Windows 7 SP1 zum Download bereit, mit der es möglich ist, Windows Server 2003, Windows Server 2008 und Windows Server 2008 R2 zu verwalten. Durch die vielen Veränderungen bei der aktuellen Servergeneration, die mit ebenso vielen Neuerungen auf der Client-Seite mit Windows 8 einhergehen, können diese bisherigen Versionen von RSAT aber nicht mehr zusammen mit den Windows-8-Clients eingesetzt werden. Microsoft stellt aber eine neue Version der Remoteserver-Verwaltungstools für Windows 8 und Windows 8 Pro ebenfalls zum Download in der Version 1.0 bereit. Diese kann aber leider nicht auf Windows-7-Rechnern zum Einsatz kommen.
Nach der Installation von RSAT kann dann die GMPC auf dem Client-Rechner in der Domäne gestartet werden. Dort sieht der Administrator alle Organisationseinheiten (OU - Organizational Units) seines Active Directory ebenso wie bereits existierende GPOs (Group Policy Objects). Diese kann er nun mithilfe des Gruppenrichtlinienverwaltungs-Editors bearbeiten. Der Editor steht nach einem Rechtsklick auf ein Gruppenrichtlinienobjekt und Auswahl von Bearbeiten zur Verfügung. In dem ausgewählten oder auch neu angelegten Gruppenrichtlinienobjekt hat er dann die Möglichkeit, in den Zweig:
Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\
Lokale Richtlinien\Überwachungsrichtlinien
zu wechseln. Dort finden sich die Richtlinien zur Überwachung von Anmeldeereignissen ebenso wie die zur Überwachung der Kontenverwaltung. Diese können dann so konfiguriert werden, dass sie beispielsweise erfolgreiche Versuche oder auftretende Fehler überwachen. Bei diesen Einstellungen finden sich auch weitere Erläuterungen, die helfen können zu entscheiden, welche Einstellungen für die eigenen Überwachungs-/Kontrollzwecke die richtigen sind. (mje)