← Zurück zur Startseite

Produkt

Kontosperrungen: warum ein Active-Directory-Konto immer wieder gesperrt wird

Das Modul Kontosperrungen beantwortet aus der Konsole heraus und ohne RDP-Sitzung auf dem Domänencontroller, warum ein Active-Directory-Konto immer wieder gesperrt wird: welches Gerät die letzte Sperrung ausgelöst hat, woher die fehlgeschlagenen Authentifizierungsversuche kommen und was weiterhin mit dem alten Passwort arbeitet. Die Erhebung läuft über den Agent, der auf dem Domänencontroller bereits installiert ist, und endet in einer Diagnose mit kodierten Befunden und einem PDF-Bericht unter Ihrer Marke.

Das Modul öffnet sich aus dem Datensatz des Domänencontrollers, und die Benutzersuche akzeptiert Vor- und Nachnamen, einen Kontonamen, einen UPN oder eine E-Mail-Adresse. Passt der Suchbegriff auf mehrere Konten, listet der Bildschirm die Treffer mit ihrem jeweiligen Status auf, und der Techniker wählt aus, welches erhoben wird: Ein Konto, das der Techniker nicht ausgewählt hat, wird nie erhoben.

Das Gerät hinter der Sperrung: Event 4740 auf dem PDC-Emulator

Windows schreibt Event 4740, das eine Kontosperrung festhält, domänenweit an einer einzigen Stelle: auf dem PDC-Emulator. KairosLink liest es dort und zeigt das Quellgerät und den genauen Zeitpunkt der letzten Sperrung. Lief die Erhebung gegen einen Domänencontroller, der nicht der PDC-Emulator ist, sagt die Diagnose das, nennt den PDC der Domäne und bietet an, die Abfrage erneut gegen ihn auszuführen.

Ist die Überwachung von Kontosperrungen auf dem Domänencontroller deaktiviert, wird Event 4740 nie geschrieben, und die Quelle der Sperrung lässt sich nicht bestimmen. KairosLink erkennt diese Situation und lässt Sie die Überwachung aus der Konsole aktivieren, mit einer verpflichtenden schriftlichen Begründung und einem Eintrag im Sicherheits-Audit-Log. Es ist die einzige Aktion des Moduls, die den Domänencontroller verändert. Verwaltet eine GPO der Domäne diese Richtlinie, warnt die Diagnose, dass die GPO die lokale Änderung überschreiben wird.

Woher die fehlgeschlagenen Anmeldungen kommen: Events 4771 und 4625

Die Erhebung deckt ein Fenster von 72 Stunden ab und gruppiert die fehlgeschlagenen Authentifizierungsversuche (Event 4771 für Kerberos und 4625 für NTLM) nach Quellgerät, mit der Anzahl der Versuche und dem Zeitpunkt des letzten. Genau dort zeigt sich das tatsächliche Muster: ein einzelnes Gerät mit Dutzenden Fehlversuchen oder mehrere verschiedene Quellen, die gleichzeitig scheitern.

Kommen die Fehlversuche von einem Domänencontroller, weist die Diagnose das gesondert aus. Es bedeutet, dass ein zwischengeschalteter Dienst im Namen des Benutzers authentifiziert und dass das Gerät, an dem die Person tatsächlich arbeitet, nicht schuld ist.

Drei oder mehr Fehlversuche derselben Quelle innerhalb derselben Sekunde werden als automatisierter Burst gemeldet. Niemand vertippt sich dreimal in einer Sekunde beim Passwort: Dieses Muster ist ein Gerät oder ein Dienst, der mit veralteten Zugangsdaten in einer Schleife weiterprobiert.

Dieselbe Erhebung liefert die Passwortrichtlinie der Domäne und die fein abgestufte Passwortrichtlinie (FGPP) für dieses Konto, die den Schwellenwert für die Sperrung und das Beobachtungsfenster festlegt, denen der Benutzer tatsächlich unterliegt.

Was es weiterhin mit dem alten Passwort versucht

Zu wissen, welches Gerät die Sperrung ausgelöst hat, reicht nicht: Sie müssen finden, was auf diesem Gerät mit den veralteten Zugangsdaten läuft. Mit einem Klick analysiert KairosLink das Quellgerät und meldet offene oder getrennte Sitzungen, geplante Aufgaben, Dienste, gespeicherte Zugangsdaten, verbundene Netzlaufwerke und auf dem Datenträger liegende Profile, die zu diesem Konto gehören.

Die Suche läuft über die SID genauso wie über den Kontonamen. Wird ein Benutzerprofil von einem Gerät gelöscht, werden die geplanten Aufgaben nicht mitgelöscht: Sie verweisen weiterhin auf die SID, weil es keinen Namen mehr zum Auflösen gibt. Über den Namen tauchen sie nicht auf, über die SID schon. Dieser Fall, ein gelöschtes Profil mit weiterhin aktiven Aufgaben, wird als eigener Befund ausgewiesen.

Kommen die Fehlversuche von einem Domänencontroller, läuft die entsprechende Analyse auf diesem DC, um den Dienst zu identifizieren, der die Authentifizierung vermittelt. Beide Analysen sind rein lesend: Sie erheben und beschreiben, sie löschen keine Aufgaben, stoppen keine Dienste und fassen keine Zugangsdaten an.

Am Konto selbst kann der Techniker es entsperren, aktivieren und einen Passwortwechsel bei der nächsten Anmeldung erzwingen. Jede dieser Aktionen landet im Verlauf der Active-Directory-Aktionen, zusammen mit dem Techniker, der sie ausgeführt hat.

Wo der Benutzer angemeldet ist: jedes Gerät wird gefragt

Windows führt kein zentrales Verzeichnis darüber, wo ein Domänenbenutzer angemeldet ist. Die einzige verlässliche Quelle ist, die Geräte selbst zu fragen, und genau das tut die Konsole: Sie fragt jedes Online-Gerät des Kunden per quser, ob dieses Konto eine offene Sitzung hat, und zeigt, was jedes geantwortet hat.

Das Ergebnis vermischt nie drei verschiedene Dinge: die Geräte mit einer Sitzung, die Geräte, die geantwortet haben, dass das Konto keine Sitzung hat, und die Geräte, die nicht gefragt werden konnten, jeweils mit einer ausformulierten Begründung (es war offline, es hat keinen Agent, es hat nicht rechtzeitig geantwortet). Ein Gerät, das nicht geantwortet hat, ist kein Gerät ohne Sitzung, und der Bildschirm zählt es nie als eines.

Für jede gefundene Sitzung meldet die Konsole, ob sie aktiv oder getrennt ist. Der Unterschied zählt bei der Untersuchung einer Sperrung: Eine getrennte Sitzung, die vor Wochen mit dem alten Passwort offen geblieben ist, probiert von allein weiter, und niemand schaut ihr zu.

Die Abfrage ist rein lesend: Sie sagt Ihnen, wo eine Sitzung besteht, und schließt keine. Eine Remote-Abmeldung gibt es in diesem Modul nicht.

Anmeldeverlauf: was jeder Domänencontroller tatsächlich gesehen hat

Das Active-Directory-Attribut lastLogon repliziert nicht zwischen Domänencontrollern: Jeder behält den Wert, den er selbst authentifiziert hat. Einen einzelnen DC zu fragen liefert eine Teilantwort, und das ist die klassische Falle bei diesem Attribut. KairosLink fragt jeden Domänencontroller der Domäne und zeigt jede Antwort, mit dem Namen des DC daneben und den nicht antwortenden in einer eigenen Liste.

Daneben zeigt die Konsole lastLogonTimestamp, das sehr wohl repliziert, mit dem Hinweis, dass es in Active Directory konstruktionsbedingt bis zu 14 Tage nachhängt. Es sagt Ihnen, ob ein Konto in Gebrauch ist; es sagt Ihnen nicht, ob es heute Morgen benutzt wurde.

Außerdem summiert sie die Anmeldungen, die der Domänencontroller gesehen hat (Event 4624 über dasselbe Fenster), gruppiert nach Quellgerät, mit Anmeldetyp, Anzahl und der jüngsten Anmeldung. Die Zahl kommt mit ihrer Grenze daneben: Ein Domänencontroller sieht nur die Anmeldungen, die über ihn liefen, was die Person an ihrer eigenen Workstation getan hat, steht dort also nicht.

Dieser Unterschied gehört zur Diagnose, er ist keine versteckte Einschränkung. Ein Gerät zu fragen, ob das Konto eine offene Sitzung hat, ist harte Tatsache. Was Active Directory über Anmeldungen meldet, ist eine Schlussfolgerung darüber, was ein einzelner Domänencontroller mitbekommen hat. Beides wird getrennt gezeigt, und jeder Bildschirm nennt die Herkunft seiner Zahl.

FSMO-Rollen: welches Gerät wirklich der PDC-Emulator ist

Die Diagnose zeigt die fünf FSMO-Rollen der Domäne und welcher Domänencontroller jede davon hält. Das zählt aus einem konkreten Grund: Event 4740 wird nur auf dem PDC-Emulator geschrieben, wer also den falschen Domänencontroller erhebt, sieht die Quelle der Sperrung nicht.

Der Inhaber der Rolle PDC-Emulator wird gegen zwei verschiedene Quellen innerhalb der Domäne selbst gegengeprüft. Widersprechen sich die beiden, meldet die Diagnose das als Befund, statt auf eigene Faust eine auszuwählen. Wenn sich eine Domäne darüber widerspricht, welches Gerät ihr PDC ist, ist das eine Information für den Techniker und kein Rauschen, das man übertüncht.

Feste Kriterien, keine KI in der Analyse

Die Bewertung steckt im Code der Konsole, nicht in einem Sprachmodell: Dieselben Daten ergeben immer dieselben Befunde, jeder mit seinem Code, seiner Ursache und der empfohlenen Maßnahme. An der Analyse einer Sperrung ist keine KI beteiligt.

Die Diagnose trennt immer "es gibt kein Problem" von "ich kann es nicht sehen". Fehlt ein Datenpunkt, sagt der Bildschirm, was fehlt und warum, statt eine Leerstelle zu zeigen, die sich wie ein Ergebnis liest: Kein Event 4740 zu finden, während die Überwachung aus ist, heißt nicht, dass das Konto nie gesperrt wurde.

Die vollständige Diagnose kommt als PDF-Bericht mit Logo und Kopfzeile Ihres Unternehmens heraus, fertig zur Übergabe an den Kunden.

Kontosperrungen sind in den Plänen KairosBusiness, KairosEnterprise und KairosEnterpriseFlex verfügbar.

Häufige Fragen

Warum wird ein Active-Directory-Konto gesperrt, obwohl der Benutzer nichts getan hat?
Weil sich etwas anderes als die Person weiterhin mit dem vorherigen Passwort authentifiziert. Die üblichen Verdächtigen sind eine geplante Aufgabe oder ein Dienst mit diesem Konto, ein verbundenes Netzlaufwerk, in der Windows-Anmeldeinformationsverwaltung gespeicherte Zugangsdaten oder ein Gerät, das noch das alte Passwort hält. Jeder Versuch fügt einen Fehlversuch hinzu, und sobald der Schwellenwert der Domänenrichtlinie erreicht ist, sperrt sich das Konto selbst, auch wenn der Benutzer weit weg von seinem Gerät ist.
Was ist Event 4740 und warum gibt es das nur auf dem PDC-Emulator?
Event 4740 ist das Windows-Sicherheitsereignis, das eine Kontosperrung festhält und das auslösende Gerät meldet. Jeder Domänencontroller leitet Fehlversuche bei der Passworteingabe an den PDC-Emulator weiter, der die Zählung führt und die Sperrung entscheidet, deshalb wird 4740 nur in dessen Protokoll geschrieben. Wer einen anderen Domänencontroller erhebt, sieht die Quelle der Sperrung nicht: KairosLink erkennt das, warnt davor und lässt Sie die Abfrage erneut gegen den PDC ausführen.
Was passiert, wenn die Überwachung von Kontosperrungen auf dem Domänencontroller deaktiviert ist?
Ohne diese Überwachung wird Event 4740 nicht geschrieben, und die Quelle der Sperrung lässt sich nicht bestimmen. KairosLink meldet das als Befund, statt einen leeren Bildschirm zu zeigen, der wie ein Ergebnis aussieht. Aus derselben Diagnose aktivieren Sie die Überwachung für den Domänencontroller, mit schriftlicher Begründung und einem Eintrag im Sicherheits-Audit-Log, und ab da wird die nächste Sperrung aufgezeichnet. Verwaltet eine GPO der Domäne diese Richtlinie, warnt die Diagnose Sie: Die GPO wird die lokale Änderung überschreiben.
Warum meldet das Event manchmal kein Quellgerät?
Das passiert, wenn die Sperrung über Kerberos entsteht: Das 4740 wird mit dem Zeitpunkt der Sperrung aufgezeichnet, aber ohne Gerätenamen. In diesem Fall sagt die Diagnose das klar, und die Untersuchung geht über die Herkunft der Fehlversuche weiter, die Events 4771 und 4625, die sehr wohl nach Gerät gruppiert ankommen, mit der Anzahl der Versuche und dem Zeitpunkt des letzten.
Welche Überbleibsel eines gelöschten Profils können ein Konto weiter sperren?
Geplante Aufgaben und Dienste überleben das Profil: Sie verweisen weiterhin auf die SID des Kontos, nicht auf seinen Namen. Deshalb sucht die Analyse des Quellgeräts über die SID genauso wie über den Kontonamen und findet Aufgaben eines Benutzers, dessen Profil nicht mehr auf dem Datenträger liegt. Derselbe Durchlauf meldet gespeicherte Zugangsdaten und verbundene Netzlaufwerke, die bei jeder Nutzung des Geräts von allein mit dem alten Passwort weiterprobieren.
Wie unterscheidet man einen menschlichen Versuch von einem automatisierten?
An der zeitlichen Dichte. Eine Person, die sich beim Passwort vertippt, erzeugt Versuche im Abstand von Sekunden oder Minuten. Drei oder mehr Fehlversuche derselben Quelle innerhalb derselben Sekunde sind typisch für ein Gerät oder einen Dienst, der in einer Schleife weiterprobiert, und KairosLink meldet sie als automatisierten Burst, mit den Versuchen pro Sekunde und dem Gerät, von dem sie kommen.
Wie findet man heraus, an welchen Geräten ein Benutzer angemeldet ist?
Indem man die Geräte fragt, denn das ist die einzige verlässliche Quelle: Windows führt kein zentrales Verzeichnis der Sitzungen eines Domänenbenutzers. Die Konsole fragt jedes Online-Gerät des Kunden per quser ab und baut das Ergebnis aus den Antworten, immer getrennt nach den Geräten mit einer Sitzung, denen, die keine Sitzung gemeldet haben, und denen, die nicht erreichbar waren, jeweils mit Begründung. Für jede gefundene Sitzung meldet sie, ob sie aktiv oder getrennt ist. Die Abfrage ist rein lesend: Sie schließt keine Sitzungen und führt keine Remote-Abmeldung aus.
Warum stimmt die von Active Directory gemeldete letzte Anmeldung nicht immer?
Weil das Attribut lastLogon nicht zwischen Domänencontrollern repliziert: Jeder behält den Wert, den er selbst authentifiziert hat, eine Abfrage an einen einzelnen DC liefert also eine Teilantwort. KairosLink fragt jeden Domänencontroller der Domäne und zeigt jede Antwort getrennt. lastLogonTimestamp repliziert sehr wohl, hängt aber konstruktionsbedingt bis zu 14 Tage nach, und der Bildschirm sagt das direkt neben dem Wert. All das ist eine Schlussfolgerung darüber, was jeder Domänencontroller mitbekommen hat, und es steht getrennt von den bei den Geräten abgefragten Sitzungen, die harte Tatsache sind.
Wofür sind FSMO-Rollen bei der Untersuchung einer Sperrung gut?
Sie sagen Ihnen, welchen Domänencontroller Sie fragen müssen. Event 4740 wird nur auf dem PDC-Emulator geschrieben, eine Erhebung gegen einen anderen Domänencontroller kann das Quellgerät also nicht ermitteln. Die Diagnose zeigt die fünf Rollen der Domäne mit ihrem Inhaber und prüft den PDC-Emulator gegen zwei verschiedene Quellen: Widersprechen sie sich, meldet sie das als Befund, statt auf eigene Faust eine auszuwählen.
KairosLink 14 Tage kostenlos testen

Standard-Softwaremodule inklusive. Keine Kreditkarte.