Last Interactive Logon
Hallo zusammen – hier ist Florian, einer der deutschen MVPs aus den Microsoft Communities mit einem neuen Gastbeitrag (*) . Diesmal erneut mit einem AD-Thema, das auch Gruppenrichtlinien ein wenig thematisiert.
Heute geht es um ein Feature, das Unix-Nutzer schon des Längeren kennen, Windows-Admins aber bislang in dieser Form verborgen blieb: die Anzeige der letzten interaktiven Anmeldeinformationen für Anwender. Das Feature kann ab Windows Vista und Windows Server 2008 (und natürlich auch mit den beiden kommenden Systemen Windows 7 und Windows Server 2008 R2) beim Upgrade der Active Directory-Domäne auf den „Windows Server 2008“-Domänenfunktionslevel eingesetzt werden und heißt: Last Interactive Logon (LIL).
Last Interactive Logon ermöglicht zwei Dinge:
- Administratoren können nun endlich (exakt!) nachvollziehen, wann ein Benutzer zuletzt interaktiv an einem Client angemeldet wurde.
- Der Benutzer kann bei seiner Anmeldung über seine letzte erfolgreiche interaktive Anmeldung informiert werden und sieht zugleich, ob es seit der letzen Anmeldung Fehlversuche durch falsche Passworteingaben gab.
Die bisherige Implementierung von Active Directory lies nur mit Aufwand das Sammeln von Logon-Daten und deren Auswertung zu und machte somit die Prüfung, wann sich ein Benutzer zuletzt an einem Client angemeldet hat, nicht gerade trivial. Das, obwohl das Verzeichnis geeignete Attribute für die Aufzeichnung der Daten bereitstellt.
Bevor wir uns aber mit den bisherigen Implementierungen und den Neuheiten von LIL beschäftigen, stellen wir erst einmal fest, was ein „interactive logon“ (also eine interaktive Anmeldung) ist. Microsoft bezeichnet im Kern folgende Anmeldungen als „interaktiv“:
- Anmeldungen mit „STRG+ALT+ENTF“
- Remoteanmeldungen über Terminal- oder Remote Desktop Services
- Sessions, die per „Anmelden als“ bzw. “Runas“ geöffnet wurden
Webanwendungen, wie etwa Outlook Web Access, sowie Netzwerkanmeldungen per NTLM erzeugen keine interaktive Anmeldung. Somit sind auch Zugriffe über Dateifreigaben keine „interaktive“ Anmeldung.
Seit jeher kennt Active Directory das Attribut „lastLogon“, das den Zeitstempel der letzten Anmeldung in einem Zeitstempel abspeichert. Der Nachteil des Attributs ist, dass es nicht repliziert wird – jeder Domänencontroller führt seinen eigenen Wert von „lastLogon“, sodass ein Administrator oder ein automatisiertes Skript alle Domänencontroller nach „ihrem“ lastLogon-Zeitstempel fragen muss, um den tatsächlich letzten interaktiven Logon eines Benutzers zu erfahren. Der größte gefundene Zeitstempel ist offensichtlich der aktuellste und zeigt das letzte Anmeldedatum an.
Mit Windows Server 2003 wurde ein neues Attribut eingeführt: lastLogonTimeStamp. LastLogonTimeStamp wurde im Schema für die Replikation zwischen Domänencontrollern konfiguriert, hat aber einen entscheidenden Nachteil: aus Respekt vor der möglichen Flut von Replikationsdaten, die der Abgleich des Attributs zwischen den DCs bedeuten würde, hat Microsoft entschieden, das Attribut an eine Latenz zu binden. Der Zeitstempel wird beim Anmelden eines Benutzers oder Computers nur aktualisiert, wenn eine Wartezeit, per Vorgabe 14 Tage (minus einer zufällig gewählten Zeit von maximal 5 Tagen), verstrichen sind und innerhalb dieser Wartezeit nicht aktualisiert wurde. Das bedeutet eine Ungenauigkeit bei der Verwendung des Attributes von schlechtestenfalls etwa 14 Tagen, da der Zeitstempel nicht öfter aktualisiert wird. Die Latenz, die Domänencontroller warten, bevor sie lastLogonTimeStamp aktualisieren, wird durch das Attribut msDS-LogonTimeSyncInterval des Domänen-NC-Objektes (DC=domain,DC=tld) bestimmt und zeigt die Tage an, die bis zur nächsten Aktualisierung verstreichen sollen. Ein Setzen des Wertes auf „0“ hilft in diesem Fall nicht, da lastLogonTimeStamp dann gar nicht mehr aktualisiert wird. Somit ist der Mindestwert für die Latenz 1 Tag, was die Brauchbarkeit des Wertes auf Grund seiner Genauigkeit auf einen Tag legt. Das mag für Reporting-Zwecke ausreichend sein, wer jedoch wissen will, ob sich Lieschen Schmidt im Laufe des heutigen Tages angemeldet hat, wird enttäuscht werden.
Ab Domänen Modus Windows Server 2008 stellt das Last Interactive Logon-Feature nun eine exaktere und einfacher auszulesende Lösung dar, da das Attribut zwischen den Domänencontrollern repliziert und bei interaktiven Anmeldungen aktualisiert wird.
Die im gezeigten Screenshot bereitgestellten Informationen werden in insgesamt vier neuen Attributen gespeichert:
- msDS-FailedInteractiveLogonCount
- msDS-FailedInteractiveLogonCountAtLastSuccessfulLogon
- msDS-LastFailedInteractiveLogonTime
- msDS-LastSuccessfulInteractiveLogonTime
Last Interactive Logon kann als Feature in zwei Stufen aktiviert werden.
Stufe 1: Anweisen der Domänencontroller, dass die Protokollierung der Anmeldedaten stattfinden soll.
Stufe 2: Aktivieren der Anzeige der letzten Logondaten, nachdem sich der Benutzer erfolgreich mit einer der oben genannten Methoden interaktiv angemeldet hat.
Die zweite Stufe der Aktivierung, das Einblenden der Logon-Daten nach beim Anmelden des Benutzers, ist optional und wird nicht für das erfolgreiche Füllen der Active Directory-Attribute benötigt. Die Anzeige dient nur zur Information für anmeldende Benutzer. Geschulte Benutzer könnten aus dieser Anzeige beispielsweise erkennen, dass sich ein anderer Mitarbeiter mehrfach eine Anmeldung mit einem falschen Passwort versucht hat, wenn der Falschanmeldungen-Zähler unerwartet hoch ist oder der Benutzer selbst in letzter Zeit keine Falschanmeldungen versucht hat.
Eine geschickte Auswertung der Daten über alle Benutzer hinweg lässt sich auch für die Analyse der Sicherheit der Benutzerkonten verwenden. Steigende Falschanmeldungszahlen und ein Vergleich der Anmeldungen zwischen Wochen und Monaten kann auf böswillige Individuen hinweisen, die Passworte erraten möchten. Passwortangriffe, die mit Methoden der interaktiven Anmeldung gefahren werden, könnten so erkannt werden.
Sowohl Stufe 1 und Stufe 2 des Last Interactive Logon-Features werden über eine einzige Gruppenrichtlinie gesteuert. Abhängig davon, welche Zielsysteme die Gruppenrichtlinie erhält, wird entweder die zweite Variante des Features oder beide aktiviert.
Wird die Gruppenrichtlinie Computerkonfiguration\Richtlinien\Administrative Vorlagen\Windows-Komponenten\Windows Anmeldeinformationen – „Informationen zu vorherigen Anmeldungen bei der Benutzeranmeldung anzeigen“ an eine OU verknüpft, die Domänencontroller enthält, wird die Protokollierung der Anmeldedaten aktiviert. Domänencontroller werden daraufhin zusätzlich damit beginnen, letzte Anmeldeereignisse anzuzeigen. Man aktiviert mit einer Richtlinie auf Domänencontrollern sozusagen zwei Features.
Wird die Richtlinie an eine OU mit Computerkonten verknüpft, werden die Computer dieser OU die Anmeldeinformationen beim nächsten Anmelden des Benutzers anzeigen.
Vorsicht ist geboten bei der Reihenfolge der Richtlinienerstellung: es scheint fast logisch zu sein, dass Anmeldedaten zuerst von Domänencontrollern aufgezeichnet werden müssen, bevor sie an Clients angezeigt werden können. Es sollte jedoch dringend vermieden werden, die Richtlinie gleichzeitig für Domänencontroller und Clients, nur für Clients oder in Domänen mit Domänenfunktionsmodus vor Server 2008 zu aktivieren, da Benutzer in diesen Fällen mit folgender Fehlermeldung konfrontiert werden:
Warum die Fehlermeldung erscheint, ist simpel: Der Client arbeitet die Gruppenrichtlinie ab und wird angewiesen, Anmeldeinformationen des Benutzers von einem Domänencontroller abzurufen. Da der Domänencontroller in den oben geschilderten Fällen keine Informationen über Benutzeranmeldungen in den genannten Attributen sammelt, weil entweder die entsprechende Richtlinie noch nicht angewendet wurde, die DCs gar nicht Ziel der Richtlinie sind oder die DCs schlicht nichts von den Attributen wissen, scheitern Clients beim Abfragen der Anmeldeinformationen. Die Folge ist die im Screenshot gezeigte Fehlermeldung und die Verweigerung des Systems, den Benutzer anzumelden. Ein Klick auf den „OK“-Button erlaubt dem Benutzer ein erneuter Anmeldeversuch – mit dem gleichen Ergebnis.
Das Spiel kann je nach Größe des Unternehmen und der Anzahl der Ziele der Richtlinie zu einem echten Ärgernis werden. Neben der „hardcore“-Lösung, für die Anmeldung den Netzwerkstecker zu ziehen und das System am Kontaktieren des Domänencontrollers zu hindern, gibt es für eine schnelle Behebung des Problems nur eine Lösung: die Deaktivierung der Richtlinie für die Clientsysteme. Zielcomputer versuchen dann nicht mehr, die letzten Anmeldeergebnisse des Domänencontrollers abzufragen und führen die Anmeldung wieder wie gewohnt durch. Andernfalls schafft natürlich das Aktivieren der Richtlinie auf den Domänencontrollern Abhilfe.
Aus eigenem Interesse sollten also folgende Konstellationen vermieden werden:
- Aktivieren der Richtlinie in Domänen, die einen Domänenfunktionslevel kleiner als „Windows Server 2008“ besitzen.
- Aktivieren der Richtlinie für Zielcomputer, nicht aber für Domänencontroller
- Aktivieren der Richtlinie für Zielcomputer und Domänencontroller zum gleichen Zeitpunkt – Clients könnten die Richtlinie vor den Domänencontrollern oder der Replikation der aktivierten Richtlinie aktualisieren.
Bemerkenswert ist an dieser Stelle das Verhalten von Falschanmeldungen, die durch „NET USE“ vom Benutzer oder in Anmeldeskripten abgesetzt werden. Domänencontroller bemerken Falschanmeldungen über „NET USE“ und protokollieren diese entsprechend – erfolgreiche Anmeldungen werden allerdings nur im Zusammenhang mit vorangegangenen Fehlanmeldungen protokolliert. Das geschieht, obwohl NET USE eigentlich keine interaktive Anmeldung ist.
Anmeldungen mit Cached Credentials werden, obwohl sie eigentlich auch zu den interaktiven Anmeldungen gehören, nicht geloggt. Der Grund ist klar: zum Zeitpunkt der Authentifizierung ist keine Verbindung zu einem DC verfügbar.
Ein kleiner weiterer Hinweis aus der Praxis: das Aktivieren der Richtlinie auf Arbeitsstationen kostet in der Regel ein paar Sekunden und kann zu einem gewissen „Nerv“-Faktor führen, da sich Benutzer nicht nur mehr anmelden, sondern die Anmeldeinformationen per „OK“-Klick bestätigen müssen, um den Anmeldeprozess fortzuführen. Ist kein DC verfügbar, etwa weil der Client offline ist oder keine Verbindung zum Netz besitzt, erscheint ein Informationsballon in der Systray, dass gerade kein Anmeldeserver erreicht werden konnte – auch das kann mobile Benutzer nerven. Evenuell sollte man vorher also ausloten, wie hoch die Toleranz der Benutzer bzw. der erwartete Nutzen des angezeigten Meldungen auf den Zielsystem ist – oder das Feature nur auf gezielt ausgesuchten Machinen aktivieren.
Macht’s gut!
Florian
* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfaßt wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.
Comments
- Anonymous
January 01, 2003
Hallo Florian, vielen Dank für diesen genialen Beitrag.. Schöne Grüße Peter Forster MVP Virtual Machine Austria