Come trovare la causa dell'account utente bloccato nel dominio Windows AD

Dopo un recente incidente con Outlook, mi chiedevo come avrei risolto in modo più efficiente il seguente problema:

Supponiamo un'infrastruttura AD di dimensioni medio-piccole piuttosto tipica: diversi controller di dominio, un numero di server interni e client Windows, diversi servizi che utilizzano AD e LDAP per l'autenticazione dell'utente all'interno della DMZ (relay SMTP, VPN, Citrix, ecc.) E diversi interni tutti i servizi che fanno affidamento su AD per l'autenticazione (Exchange, server SQL, server di file e stampa, server di servizi terminal). Hai pieno accesso a tutti i sistemi ma sono un po 'troppo numerosi (contando i client) per controllare individualmente.

Ora supponiamo che, per qualche motivo sconosciuto, uno (o più) account utente venga bloccato a causa della politica di blocco della password ogni pochi minuti.

• Quale sarebbe il modo migliore per trovare il servizio / macchina responsabile per questo?
• Supponendo che l'infrastruttura sia pura, Windows standard senza alcuno strumento di gestione aggiuntivo e poche modifiche rispetto all'impostazione predefinita, esiste un modo per accelerare o migliorare il processo di ricerca della causa di tale blocco?
• Che cosa si potrebbe fare per migliorare la resilienza del sistema contro un tale blocco dell'account DOS? La disabilitazione del blocco degli account è una risposta ovvia, ma poi ti imbatti nel problema degli utenti che hanno modo di sfruttare facilmente le password, anche con la complessità applicata.

Aggiungendo qualcosa che non vedo nelle risposte fornite.

Quale sarebbe il modo migliore per trovare il servizio / macchina responsabile per questo?

Non puoi semplicemente guardare il registro di sicurezza sul PDCe, perché, sebbene il PDCe abbia le informazioni più aggiornate sui blocchi degli account per l'intero dominio, non ha le informazioni su quale client (IP o nome host) provengono i tentativi di accesso non riusciti, presupponendo che i tentativi di accesso non riusciti si siano verificati su un altro controller di dominio oltre al PDCe. Il PDCe dirà che "Account xyz era bloccato", ma non dirà da dove, se gli accessi non riusciti si stavano verificando su un altro controller di dominio nel dominio. Solo il controller di dominio che ha effettivamente convalidato l'accesso registrerà l'errore di accesso, incluso l'indirizzo del client. (Inoltre, non portare i RODC in questa discussione.)

Esistono due buoni modi per scoprire da dove provengono i tentativi di accesso non riusciti quando si hanno diversi controller di dominio. Inoltro di eventi e strumenti di blocco dell'account Microsoft .

Preferisco l'inoltro di eventi in una posizione centrale. Inoltra i tentativi di accesso non riusciti da tutti i controller di dominio a un server di registrazione centrale. Quindi hai solo un posto dove andare per cercare accessi non riusciti in tutto il tuo dominio. In effetti, personalmente non amo molto gli strumenti di blocco degli account di Microsoft, quindi ora c'è un buon modo.

Inoltro di eventi. Ti piacerà.

Supponendo che l'infrastruttura sia pura, Windows standard senza alcuno strumento di gestione aggiuntivo e poche modifiche rispetto all'impostazione predefinita, esiste un modo per accelerare o migliorare il processo di ricerca della causa di tale blocco?

Vedi sopra. Puoi quindi avere il tuo sistema di monitoraggio, come SCOM o Nagios o qualunque cosa tu usi, pettinare quel singolo registro eventi e far esplodere il tuo cellulare con messaggi di testo o altro. Non è più accelerato di così.

Che cosa si potrebbe fare per migliorare la resilienza del sistema contro un tale blocco dell'account DOS?

1. Formazione dell'utente. Dì loro di interrompere la configurazione dei servizi Windows per l'esecuzione con i loro account utente di dominio, disconnettersi dalle sessioni RDP al termine, insegnare loro come cancellare il Windows Credential Vault dalle password memorizzate nella cache per Outlook, ecc.
2. Utilizzare gli account dei servizi gestiti dove è possibile in modo che gli utenti non debbano più gestire le password per tali account utente. Gli utenti muck tutto. Se si dà a un utente una scelta, lui o lei farà sempre la scelta sbagliata. Quindi non dare loro una scelta.
3. Applicazione dei timeout della sessione remota tramite GPO. Se un utente rimane inattivo in una sessione RDP per 6 ore, avvialo.

Abbiamo avuto lo stesso problema durante la pulizia degli account amministratore in un ambiente più grande qualche tempo fa. Sebbene i registri di controllo dei controller di dominio forniscano tecnicamente le informazioni necessarie, abbiamo deciso di implementare il prodotto ADAudit Plus di ManageEngine, che analizza questi registri e cerca i tentativi di accesso, insieme a eventuali modifiche in AD. Utilizzando una funzionalità di reportistica integrata e un po 'di lavoro di Excel, siamo riusciti a rintracciare (abbastanza facilmente) da dove provenivano gli accessi. Nel nostro caso era principalmente legato agli amministratori che avevano usato account admin anziché account di servizio durante l'implementazione di varie applicazioni.

Che cosa si potrebbe fare per migliorare la resilienza del sistema contro un tale blocco dell'account DOS?

Non puoi.

Ci sono molte cose che possono bruciare la tua casa. Come un semplice codice per richiedere ripetutamente indirizzi IP fino a quando l'ambito DHCP è esaurito. O un semplice codice che crea directory fino a quando la MFT è piena e devi riformattare la partizione per ripristinarla. Non puoi proteggerti da tutto.

Uno scenario più comune con i blocchi è rappresentato dalle persone che inseriscono le proprie credenziali in una varietà di dispositivi molto più ampia di quanto fosse comune solo pochi anni fa. Come stampanti (per scansioni e-mail) o uno smartphone o un tablet. Se dimenticano dove hanno inserito le loro credenziali o se non hanno più accesso al dispositivo, è possibile che il dispositivo continui a tentare l'autenticazione per sempre. L'autorizzazione e-mail è un vettore difficile da rintracciare questi dispositivi e, anche se lo fai, l'utente potrebbe non avere accesso ad esso o sapere dove si trova. IP 10.4.5.27? Conosco un utente che ha dovuto chiamare l'help desk ogni giorno per sbloccare il proprio account, quindi avrebbero immediatamente effettuato l'accesso e quindi il loro account si sarebbe bloccato nuovamente. Lo hanno fatto per mesi. Ho detto loro di rinominare il loro account.

La vita ha disincentivi, non possiamo rimuoverli tutti.