Wir haben ein Domain-Konto, das über 1 von 2 Servern gesperrt wird. Die eingebaute Prüfung sagt uns nur so viel (gesperrt von SERVER1, SERVER2).

Das Konto wird innerhalb von 5 Minuten gesperrt, ungefähr 1 Anfrage pro Minute, wie es scheint.

Ich habe zunächst versucht, procmon (von sysinternals) auszuführen, um festzustellen, ob nach dem Entsperren des Kontos ein neuer PROCESS START erzeugt wird. Es kommt nichts Verdächtiges auf. Procmon auf meinem Arbeitsplatz und erhebend zu einem UAC - Shell (conscent.exe) scheint es , wie aus dem Stapel nach dem Laufen , dass ntdll.dllund rpct4.dllaufgerufen werden , wenn Sie versuchen , gegen AD auth (nicht sicher).

Gibt es überhaupt eine Einschränkung, welcher Prozess eine Authentifizierungsanforderung an unseren DC verursacht? Es ist immer derselbe DC, daher wissen wir, dass es sich um einen Server auf dieser Site handeln muss. Ich könnte versuchen, nach den Anrufen in Wireshark zu suchen, bin mir aber nicht sicher, ob dies eingrenzen würde, welcher Prozess sie tatsächlich auslöst.

Dieses Domain-Konto wird auch nicht von Diensten, Laufwerkszuordnungen oder geplanten Aufgaben verwendet. Daher muss es sich um etwas handeln, in dem die Domain-Creds gespeichert sind. Es gibt auch keine offenen RDP-Sitzungen mit diesem Domänenkonto auf einem Server (wir haben dies überprüft).

Weitere Hinweise

Ja, "Erfolg / Fehler" -Anmeldeprüfungen sind auf dem betreffenden Domänencontroller aktiviert. Es werden keine Fehlerereignisse protokolliert, bis das Konto tatsächlich gesperrt ist.

Weitere Gräben zeigen , dass LSASS.exeein macht KERBEROSAufruf an den DC in Frage , wenn der Account freigeschaltet wird. Davor steht (im Allgemeinen) Java, das anscheinend vpxd.exeals vCenter-Prozess bezeichnet wird. ABER wenn ich mir den anderen "Server2" ansehe, von dem aus die Kontosperrung (auch) erfolgen kann, sehe ich nie einen Aufruf von lsass.exeund es werden nur Apache-Prozesse erzeugt. Die einzige Beziehung, die die beiden haben, besteht darin, dass SERVER2 Teil des vSphere-Clusters von SERVER1 ist (Server1 ist ein vSphere-Betriebssystem).

Fehler bei DC

Es scheint also alles, was AD mir sagen wird, dass es sich um einen Kerberos-Fehler vor der Authentifizierung handelt. Ich habe nachgesehen und es gab keine Tickets mit klistund habe trotzdem einen Flush für alle Fälle gemacht. Ich habe immer noch keine Ahnung, was diesen Kerberos-Fehler verursacht.

Index              : 202500597
EntryType          : FailureAudit
InstanceId         : 4771
Message            : Kerberos pre-authentication failed.

                     Account Information:
                         Security ID:        S-1-5-21-3381590919-2827822839-3002869273-5848
                         Account Name:        USER

                     Service Information:
                         Service Name:        krbtgt/DOMAIN

                     Network Information:
                         Client Address:        ::ffff:x.x.x.x
                         Client Port:        61450

                     Additional Information:
                         Ticket Options:        0x40810010
                         Failure Code:        0x18
                         Pre-Authentication Type:    2

                     Certificate Information:
                         Certificate Issuer Name:
                         Certificate Serial Number:
                         Certificate Thumbprint:

                     Certificate information is only provided if a certificate was used for pre-authentication.

                     Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

                     If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
                      in this event might not be present.

Anmeldeereignisse zeichnen den Anmeldeversuch auf. Aktivieren Sie die fehlgeschlagene Anmeldeüberwachung (Sicherheitseinstellungen> Lokale Richtlinien> Überwachungsrichtlinie> Anmeldeereignisse überwachen) in der lokalen Sicherheitsrichtlinie (secpol.msc) und suchen Sie im Sicherheitsereignisprotokoll nach einem Ereignis. Sie können es auch über Gruppenrichtlinien aktivieren, wenn dies vorzuziehen ist.

Es wird einen Abschnitt mit Prozessinformationen geben, in dem sowohl der ausführbare Pfad als auch die Prozess-ID aufgezeichnet werden.

Beispiel:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe

Ich habe diese alte Frage gefunden, als ich ein anderes Problem untersucht habe, aber für alle, die ein ähnliches Problem haben:

Der Fehlercode 0x18 bedeutet, dass das Konto bereits deaktiviert oder gesperrt wurde, als der Client versuchte, sich zu authentifizieren.

Sie müssen dieselbe Ereignis-ID mit dem Fehlercode 0x24 finden , mit der die fehlgeschlagenen Anmeldeversuche identifiziert werden, durch die das Konto gesperrt wurde. (Dies setzt voraus, dass es aufgrund eines fehlerhaften zwischengespeicherten Kennworts irgendwo auftritt.)

Sie können dann anhand der Clientadresse bei diesen Ereignissen feststellen, auf welchem ​​System die fehlerhaften Anmeldeinformationen übergeben werden. Von dort aus müssten Sie herausfinden, ob es sich um einen Dienst mit einem alten Kennwort, einem zugeordneten Netzlaufwerk usw. handelt.

Es gibt eine Vielzahl von Fehlercodes. Sie sollten daher nach 0x18 suchen, um festzustellen, was die Kontosperrung verursacht hat, wenn keine Ereignisse mit 0x24-Codes vorliegen. Ich glaube, die einzige Art von Fehler, die zu einer Sperrung führt, ist 0x24 (falsches Passwort), aber ich könnte mich irren.

Kerberos 0x18 ist in der Tat ein falscher Passwortversuch.

Kerberos 0x12 ist für das Konto deaktiviert, abgelaufen, gesperrt oder die Anmeldezeit ist eingeschränkt.

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771

Ich habe heute viel Zeit verbracht und die Ursache herausgefunden. Ich bin falsch gelaufen - von erfassten Informationen mit dem Netzwerk-Sniffer (Kerberos-Fehlerprozess-ID war 566 = lsass.exe). Lassen Sie mich die Informationen zusammenfassen.

1. Melden Sie sich am Problem-PC an und führen Sie Powershell mit erhöhten Rechten aus

2. Aktivieren Sie die Überwachungsanmeldung

   auditpol /set /subcategory:"logon" /failure:enable

3. Überprüfen Sie die Quelle

   Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

Wenn du siehst:

Prozessinformationen:

Anrufer-Prozess-ID: 0x140

Name des Anruferprozesses: C: \ Windows \ System32 \ services.exe

Dies bedeutet, dass ein Dienst vom Problemkonto mit dem alten Kennwort ausgeführt wird

Dies ist aus den obigen Anmerkungen. Sieht aus wie der Initiator dieses Beitrags in seinem letzten Kommentar angegeben. Java ruft den Prozess vpxd.exe auf.

Weitere Hinweise Ja, "Erfolg / Fehler" -Anmeldeprüfungen sind auf dem betreffenden Domänencontroller aktiviert. Es werden keine Fehlerereignisse protokolliert, bis das Konto tatsächlich gesperrt ist.

Weitere Ausgrabungen zeigen, dass LSASS.exe einen KERBEROS-Aufruf an den betreffenden DC ausführt, sobald das Konto entsperrt ist. Davor steht (im Allgemeinen) Java, das anscheinend von vpxd.exe aufgerufen wird, einem vCenter-Prozess. ABER wenn ich mir den anderen "Server2" ansehe, von dem aus die Kontosperrung (auch) erfolgen kann, sehe ich nie einen Aufruf von lsass.exe und es werden nur Apache-Prozesse erzeugt. Die einzige Beziehung, die die beiden haben, besteht darin, dass SERVER2 Teil des vSphere-Clusters von SERVER1 ist (Server1 ist ein vSphere-Betriebssystem).