Cosa sta causando al mio controller di dominio la registrazione di decine di tentativi di autenticazione riusciti al secondo?

Abbiamo un dominio con circa 15 server e circa 30 workstation. I server sono principalmente 2008r2 e le workstation sono principalmente Windows 7. I due controller di dominio sono 2012r2. Ogni poche settimane, uno dei nostri account di amministratore viene bloccato. Sto cercando di restringere la causa e ho raggiunto un vicolo cieco.

Ecco cosa ho.

Il registro eventi sul PDC mostra l'evento 4776 - verifica riuscita:

Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account:  username
Source Workstation: 
Error Code: 0x0

Tutto per lo stesso nome utente e ricorrendo più volte al secondo.

In base agli ID evento, si tratta di accessi NTLM anziché Kerberos. Sebbene il tipo di autenticazione utilizzato sia meno preoccupante per me rispetto alla quantità di taglio. Ciò accade più volte al secondo e si ripete ogni paio di secondi all'infinito, tutte le ore del giorno o della notte o del fine settimana.

Il registro eventi mostra anche l'ID evento di esito positivo del controllo 4624 (accesso) e 4634 (disconnessione) per questo nome utente, ma come nell'evento sopra il campo "workstation" è vuoto.

Ho abilitato la registrazione dettagliata di netlogon e il netlogon.log mostra

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

E così via e così via. La fonte apparente di questi accessi (tramite XYZ) può includere workstation e server da tutta la rete.

Chiaramente questo sembra un'automazione o uno script. Dato che gli accessi hanno generalmente successo, non credo sia un tentativo di intrusione. Alcuni accessi, tuttavia, non riescono di tanto in tanto, ma non ho identificato alcun modello per l'errore e si verificano così raramente che (quasi tutti i giorni) non bloccano l'account. Il codice di errore quando ce n'è uno è in genere 0xc0000022 (accesso negato)

Ho disabilitato e disinstallato il nostro agente di monitoraggio remoto (attualmente Kaseya, ma stiamo finalmente passando a LabTech) da uno dei server, ma ho ancora visto nuovi eventi provenienti da quel server, quindi questo esclude le attività di automazione. Ho anche controllato l'utilità di pianificazione su un paio di server e non ho trovato nulla di straordinario. Ho controllato i servizi per verificare gli account di accesso e questo account non è utilizzato in nessun servizio.

Ho usato Netstat per un bel po 'di tempo e ho visto principalmente le connessioni al PDC da "Sistema" e "Processo inattivo del sistema". Ho visto connessioni occasionali da spoolsrv, lsass e ismserv (il server su cui sto testando è un server Citrix XenApp, ma altri server "sorgente" non si trovano nella farm XenApp, e ovviamente non lo sono nemmeno le workstation "sorgente"). Ho interrotto il servizio di spooler di stampa solo per testarlo e non ha avuto alcun impatto sugli eventi di accesso.

Lavoro in un MSP e questo è il nostro account amministratore dom principale tecnico, quindi è prioritario che funzioni e sia sicuro. L'ultima idea che mi rimane è quella di cambiare la password e vedere cosa si rompe, ma senza sapere a cosa serve l'account potrebbe avere conseguenze potenzialmente catastrofiche. Tuttavia, il mio sospetto è che questo potrebbe essere solo un annuncio non configurato correttamente.

Qualcuno ha sperimentato qualcosa di simile prima ed è stato in grado di identificare la fonte?

active-directory windows-server-2008-r2 windows-server-2012-r2

— Tommaso
fonte

Per chiunque sia curioso dell'elevato numero di server, hanno i server XenApp con SharePoint pubblico per una forza lavoro altamente mobile con BYOD. Avevano anche un precedente personale IT che era andato un po 'fuori bordo nella loro infrastruttura per le dimensioni della loro attività. Da quando ci hanno contratto, abbiamo cercato di ridurli un po 'a qualcosa di più adeguato alle loro esigenze.

— Thomas

Qualcosa che potresti provare è installare Microsoft Network Monitor su uno dei server, avviare un'acquisizione, attendere una voce dal server per accedere al registro di netlogon e quindi guardare l'acquisizione e vedere se riesci a trovare la conversazione in Network Monitor . Network Monitor dovrebbe mostrarti il processo responsabile della conversazione. Se ciò non lo restringe abbastanza, è possibile utilizzare Network Monitor insieme a Process Monitor per identificare il processo responsabile.

— joeqwerty,

Microsoft Network Monitor è obsoleto e sostituito da Microsoft Message Analyzer. Lo stesso affare di Wireshark. Ho eseguito un'acquisizione di pacchetti e non ho trovato assolutamente nulla di utile. Gli unici eventi che sono strettamente correlati agli eventi NetLogon sono le connessioni WMI e RPC.

— Thomas

Bene, NetMon è deprecato ma è ancora un buon strumento. Se non hai mai usato Message Analyzer prima che possa essere un po 'travolgente. NetMon è abbastanza semplice e intuitivo. Di solito lo uso prima di ogni altra cosa. - Per quanto riguarda l'acquisizione, il traffico RPC potrebbe contenere alcuni indizi.

— joeqwerty,

Sì, niente. C'è un bind MSRPC inviato e Ack ricevuto per creare una sessione crittografata seguito da un pacchetto NRPC inviato e ricevuto contenente una richiesta e risposta NetrLogonSamLogonEx, le ultime due crittografate. Il processo di chiamata sul computer di origine è LSASS, che esegue il servizio Netlogon. Non ci sono dettagli utili nei dati dei pacchetti del traffico Bind e ovviamente i pacchetti crittografati sono inutili per me.

— Thomas

Consiglio di abilitare ulteriormente il controllo NTLM sui controller di dominio. Utilizzando i criteri predefiniti del controller di dominio, abilitare le seguenti impostazioni dei criteri:

Sicurezza di rete: Limita NTLM: Controlla traffico in entrata = Abilita controllo per tutti gli account Sicurezza di rete: Limita NTLM: Controlla autenticazione NTLM in questo dominio = Abilita tutto Sicurezza di rete: Limita NTLM: Traffico NTLM in uscita su server remoti = Controlla tutto

https://support.symantec.com/en_US/article.HOWTO79508.html

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/jj865682(v=ws.10)

Una volta abilitato, navigare nel Visualizzatore eventi su: Registri applicazioni e servizi> Microsoft> Windows> NTLM> Operativo

Ci saranno eventi con timestamp corrispondenti ai timestamp dell'evento netlogon. Questo registro rivelerà il nome effettivo della workstation.

E in particolare per aiutarti a identificare ulteriormente la fonte, il nome del canale protetto in questo registro contribuirebbe a restringere l'origine del processo.

— Luppolo per l'homebrew
fonte

Grazie per la risposta. Purtroppo questo particolare cliente non è più un nostro cliente, quindi non sono in grado di provare le tue istruzioni. Sono andato avanti e ho accettato la tua risposta, anche se la mia comprensione di AD mi dice che dovrebbe darmi i dettagli di cui ho bisogno. (Non sono sicuro del motivo per cui non ho pensato di modificare la politica di revisione, ma tu mi scusi per averlo suggerito.)

— Thomas