ADDS: Nicht suchen, sondern finden!

icon-11 Mir begegnen regelmäßig Situationen, in dem im ADDS und Eventlog bestimmte Dinge nachgeschaut werden müssen. Dabei gehen viele direkt ins Eventlog und suchen nach dem Namen des gesperrten Users oder ähnliches. Gerade in größeren Umgebungen ist diese Vorgehensweise sehr ineffizient und auch nicht präzise, da andere Ereignisse die Suchergebnisse beeinträchtigen können.

Daher sollte die Devise sein: Zuerst Zeitpunkt und Ort herausfinden und dann im Eventlog nachschauen.

Solange am Objekt nichts geändert wurde, ist der letzte Änderungszeitpunkt und Ort eigenschaftsgenau kontrollierbar.

Dazu ein kleines Beispiel: Ein Anwender beschwert sich, dass sein Konto ständig gesperrt wird. Er hat vor einigen Stunden sein Kennwort geändert.

Bevor das Konto zurückgesetzt wird, werden noch schnell wichtige Eigenschaften mittels repadmin extrahiert:

repadmin /showobjmeta * "CN=User1,OU=Benutzer,,DC=temp,DC=local" > user.txt

Dabei werden die Metadaten des per DN angegebenen Objektes (CN=…) auf allen Domänenkontrollern (*) ausgelesen und in eine Textdatei gespeichert.

In der Textdatei steht jetzt pro Domänencontroller eine Liste aller Attribute des Objektes und weitere wesentliche Parameter. Für dieses Beispiel relevant ist die LockoutTime:

153243532 Standardname-des-ersten-Standorts\dc1   1100175 2010-11-23 11:11:11   37 lockoutTime

Dieser Eintrag zeigt deutlich, dass das Attribut lockoutTime (also wann das Konto gesperrt wurde) auf dem Domänencontroller dc1 um 11:11 geändert wurde.

Somit kann man direkt diese Daten nutzen und ins Securitylog vom dc1 um 11:11 schauen.

 

Ereignistyp:    Fehlerüberw.

Ereignisquelle: Security

Ereigniskategorie:      (9)

Ereigniskennung:        675

Datum:          23.11.2010

Zeit:           11:11:11

Benutzer:               NT-AUTORITÄT\SYSTEM

Computer:       dc1

Beschreibung:

Fehlgeschlagene Vorbestätigung:

         Benutzername:   user1

         Benutzerkennung:                TEMP\user1

         Dienstname:     krbtgt/TEMP.LOCAL

         Vorauthentifizierungstyp:       0x2

         Fehlercode:     0x18

         Clientadresse:  192.2.0.10

Die Sperrung ging als vom Client 192.2.0.10 aus. Eine Rückfrage beim User ergibt direkt, dass er das Kennwort an einem anderen Client geändert hat, aber an dem oben angegebenen Client schon länger angemeldet ist.

Aufwand: 5 Minuten. Wilde Sucherei: Minimal. Präzision: Hoch

This entry was posted in Active Directory Domain Service, Deutsch, Windows and tagged , . Bookmark the permalink.

Leave a Reply