I servizi di dominio di Active Directory (AD DS) sono diventati un componente centrale dell'infrastruttura IT aziendale meravigliosamente affidabile, altamente scalabile e con tolleranza agli errori. In genere funziona abbastanza bene senza richiedere molta attenzione. Tuttavia, l'amministratore di AD DS deve fare del lavoro supplementare per portare il servizio da un livello di "buon funzionamento quotidiano" a un livello di "affidabilità a prova di bomba quando si verifica una situazione insolita". Quando si verifica questa situazione insolita (e notate che ho detto "quando", non "se"), ci sono una serie di configurazioni e pratiche scorrette che mettono il dominio o la foresta AD DS a rischio di perdita di dati, guasto del controller di dominio (DC) o addirittura guasto del dominio o della foresta. Alcuni di questi elementi possono sembrare elementari, ma sarete sorpresi di sapere quanto siano comuni.
Lettura correlata
Avete ancora i DC di Windows Server 2003. Windows Server 2003 era un sistema operativo eccellente a suo tempo... ma il suo tempo è passato. E soprattutto, è un sistema operativo vulnerabile e non aggiornabile. Perché mettere a rischio la vostra azienda? Passate ad altro!
Tutti i DC e i backup si trovano in un'unica sede fisica. Molte cose brutte possono accadere in un'unica sede. È positivo che abbiate più di un DC, ma se si trovano tutti nello stesso data center, la vostra foresta è ancora vulnerabile a qualsiasi cosa possa mettere fuori uso quel data center. E questo vale ovviamente anche per i backup della foresta. Non ci sono scuse per non essere preparati a una calamità naturale in lento movimento come l'uragano Sandy sulla costa orientale degli Stati Uniti. Ma so anche che incendi esterni in rapida evoluzione possono causare danni significativi a un data center e renderlo almeno non disponibile, se non fortemente danneggiato. Morale: cercate tutti i singoli punti di vulnerabilità nel vostro ambiente AD DS.
Il cestino non è abilitato. Tutti noi amministratori abbiamo tirato un sospiro di sollievo quando il Cestino di Active Directory è diventato disponibile in Windows Server 2008 R2. Tuttavia, c'è voluto un po' di tempo prima che questa indispensabile utility di ripristino degli oggetti fosse ampiamente utilizzata, perché richiede un livello funzionale minimo della foresta di Windows Server 2008 R2. E per ottenerlo è necessario aggiornare tutti i DC della foresta da versioni precedenti, in particolare Windows Server 2003. Poiché un numero imbarazzante di organizzazioni ha messo a riposo i propri DC Windows Server 2003 solo di recente, molte di queste aziende non hanno nemmeno attivato il Cestino. Sapete chi siete; dateci dentro!
Non state seguendo le best practice di virtualizzazione. Se i DC sono più vecchi di Windows Server 2012, non comprendono gli ambienti virtualizzati. In particolare, si riprendono male dai ripristini basati su immagini in cui il database AD è stato ripristinato a un momento precedente senza trigger. Assicuratevi (e soprattutto gli amministratori della virtualizzazione) di seguire le best practice di Microsoft per la virtualizzazione di AD DS.
Non si monitora regolarmente lo stato di salute di DC e DNS. Uno dei modi più comuni in cui Active Directory ha problemi è perché nessuno vi presta attenzione. Se siete una piccola organizzazione, capisco che non abbiate i fondi per una soluzione di monitoraggio estesa (anche se esistono eccellenti soluzioni gratuite per le piccole e medie imprese, come SpiceWorks). Per eseguire un monitoraggio di base è sufficiente uno script pianificato che esegua DCDIAG /s: /E e lo scrive in un file. Guardatelo ogni mattina. Se si verificano errori di replica, ad esempio, è disponibile lo strumento gratuito ADREPLSTATUS.
Si stanno eseguendo più ruoli su un DC. L'esecuzione di più ruoli su un DC compromette sia la sicurezza che il ripristino. Nell'era delle macchine virtuali facili da creare, non c'è motivo di non avere server dedicati a questo compito.
Non cambiate mai le password degli account di servizio. Questo è un piccolo sporco segreto che la maggior parte dei reparti IT non vuole ammettere: gli account di servizio per molti dei principali servizi di infrastruttura non vengono aggiornati da anni. Prima di Windows Server 2008 R2, cambiare la password di un account di servizio significava incorrere in tempi di inattività del servizio (ad esempio un database SQL Server in un'applicazione line of business multitier). Quindi, non veniva mai cambiata. In una grande organizzazione che conoscevo, la password dell'account di servizio SMS era conosciuta da almeno tre generazioni di sysadmin! Questa vulnerabilità è stata corretta, prima con gli account di servizio gestiti (MSA) in Windows Server 2008 R2 e poi con gli MSA di gruppo in Windows Server 2012. Avete fatto qualcosa?
Troppi amministratori. Questo dovrebbe tenervi svegli la notte. Molte, moltissime organizzazioni hanno un numero eccessivo di account amministrativi perché chi ha costruito il loro AD DS non ha mai dedicato il tempo necessario a creare un modello di amministrazione delegata. Di conseguenza, concedere ampi diritti è il modo più veloce per chiudere un ticket di assistenza. È il modo più rapido che conosco per far finire la vostra azienda in prima pagina sul notiziario della sicurezza di SC Magazine o peggio.
Non illudetevi. Se nel vostro ambiente AD DS è presente una di queste condizioni, è vostra responsabilità dimostrare al management perché la loro correzione deve essere una priorità per la sicurezza della vostra azienda.
