Wir haben eine Domain mit ca. 15 Servern und ca. 30 Workstations. Server sind meistens 2008r2 und Workstations sind meistens Windows 7. Die beiden DCs sind 2012r2. Alle paar Wochen wird eines unserer Administratorkonten gesperrt. Ich versuche die Ursache einzugrenzen und habe eine Sackgasse erreicht.
Folgendes habe ich.
Das Ereignisprotokoll auf dem PDC zeigt Ereignis 4776 - Überwachungserfolg:
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: username
Source Workstation:
Error Code: 0x0
Alle für denselben Benutzernamen und mehrmals pro Sekunde.
Basierend auf den Ereignis-IDs handelt es sich eher um NTLM-Anmeldungen als um Kerberos. Obwohl die Art der verwendeten Authentifizierung für mich weniger besorgniserregend ist als die Schermenge. Dies geschieht mehrmals pro Sekunde und wiederholt sich alle paar Sekunden ad infinitum, alle Stunden Tag oder Nacht oder Wochenende.
Das Ereignisprotokoll zeigt auch die Überwachungserfolgsereignis-ID 4624 (Anmeldung) und 4634 (Abmeldung) für diesen Benutzernamen an, aber wie im obigen Ereignis ist das Feld "Arbeitsstation" leer.
Ich habe die ausführliche Netlogon-Protokollierung aktiviert und das netlogon.log wird angezeigt
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation1) Entered
02/28 17:11:03 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation1) Returns 0x0
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation2) Entered
02/28 17:11:04 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from (via server1) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from (via server1) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from (via server2) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from (via server2) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation3) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation3) Returns 0x0
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation2) Entered
02/28 17:11:19 [LOGON] [2044] domain: SamLogon: Transitive Network logon of domain\username from (via workstation2) Returns 0x0
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from (via workstation4) Entered
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from (via workstation5) Entered
02/28 17:11:19 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from (via workstation4) Returns 0x0
02/28 17:11:19 [LOGON] [8468] domain: SamLogon: Transitive Network logon of domain\username from (via workstation5) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from (via server3) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from (via server3) Returns 0x0
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from (via server4) Entered
02/28 17:11:20 [LOGON] [5476] domain: SamLogon: Transitive Network logon of domain\username from (via server4) Returns 0x0
Und so weiter und so fort. Die offensichtliche Quelle dieser Anmeldungen (über XYZ) können Workstations und Server aus dem gesamten Netzwerk sein.
Dies sieht eindeutig wie eine Automatisierung oder ein Skript aus. Da die Anmeldungen im Allgemeinen alle erfolgreich sind, glaube ich nicht, dass es sich um einen Angriffsversuch handelt. Einige der Anmeldungen schlagen jedoch von Zeit zu Zeit fehl, aber ich habe kein Muster für den Fehler identifiziert und sie treten so selten auf, dass sie (an den meisten Tagen) das Konto nicht sperren. Der Fehlercode, falls vorhanden, lautet normalerweise 0xc0000022 (Zugriff verweigert).
Ich habe unseren Fernüberwachungsagenten (derzeit Kaseya, aber wir wechseln endlich zu LabTech) von einem der Server deaktiviert und deinstalliert, aber immer noch neue Ereignisse von diesem Server gesehen, sodass Automatisierungsaufgaben ausgeschlossen sind. Ich habe auch den Taskplaner auf einigen Servern überprüft und nichts Außergewöhnliches gefunden. Ich habe Dienste überprüft, um Anmeldekonten zu überprüfen, und dieses Konto wird in keinem Dienst verwendet.
Ich habe Netstat lange Zeit ausgeführt und hauptsächlich Verbindungen zum PDC von "System" und "System Idle Process" gesehen. Ich habe gelegentlich Verbindungen von spoolsrv und lsass und ismserv gesehen (der Server, auf dem ich teste, ist ein Citrix XenApp-Server, aber andere "Quell" -Server befinden sich nicht in der XenApp-Farm, und natürlich auch keine "Quell" -Workstationen). Ich habe den Druckspooler-Dienst nur zum Testen gestoppt und er hatte keine Auswirkungen auf die Anmeldeereignisse.
Ich arbeite bei einem MSP und dies ist unser Hauptadministratorkonto für Techniker. Daher ist es von hoher Priorität, dass es funktioniert und sicher ist. Die letzte Idee, die ich noch habe, ist, das Passwort zu ändern und zu sehen, was kaputt geht, aber ohne zu wissen, wofür das Konto verwendet wird, könnte dies möglicherweise katastrophale Folgen haben. Mein Verdacht ist jedoch, dass dies möglicherweise nur eine falsch konfigurierte AD ist.
Hat jemand so etwas schon einmal erlebt und konnte die Quelle identifizieren?