Distribuisci e configura le Best Practices del Domain Controller

Gli amministratori IT lavorano con e intorno a Active Directory dalla presentazione della tecnologia in Windows 2000 Server. Windows 2000 Server è stato rilasciato il 17 febbraio 2000, ma molti amministratori hanno iniziato a lavorare con Active Directory alla fine del 1999, quando è stato rilasciato per la produzione (RTM) il 15 dicembre 1999.

Ci sono alcune buone pratiche da seguire quando si distribuiscono i DCs. Molte di queste pratiche sono documentate. Ma non molte organizzazioni stanno implementando queste pratiche.

Come distribuire e configurare Domain Controller

Ignoreremo le buone pratiche ben note come mantenere il Active Directory database su un set di dischi, i file di log su un set separato di dischi e il sistema operativo sul proprio set di dischi.

Alcune delle buone pratiche meno implementate per i controller di dominio sono:

Esegui l'installazione di Server Core del sistema operativo.

Molti amministratori evitano i cambiamenti, specialmente per sistemi come AD DS che sono incredibilmente stabili. Quindi, quando un nuovo amministratore propone di passare all'installazione di Server Core, spesso si trova di fronte a sguardi gelidi. Ma la realtà è che la maggior parte degli amministratori gestisce AD DS da remoto avviando ADUC o PowerShell sul proprio computer client o amministrativo. Tutti gli strumenti di gestione principali, inclusi il Centro amministrativo di Active Directory (ADAC) e Windows PowerShell, funzionano quasi identicamente sia che vengano utilizzati localmente su un DC sia che vengano usati da remoto da un computer client o amministrativo. Pertanto, passando all'installazione di Server Core, l'esperienza amministrativa non viene degradata. E, si ottengono miglioramenti della sicurezza e alcuni piccoli miglioramenti delle prestazioni.

Non eseguire altri software o servizi su un DC.

Ai vecchi tempi, come 10 anni fa, la maggior parte delle organizzazioni utilizzava server fisici perché la virtualizzazione era ancora agli inizi. Quindi, quando era il momento di provvedere a un nuovo file server, server DHCP o server di stampa, gli amministratori spesso sfruttavano un server esistente. Spesso veniva utilizzato anche un DC. Avanziamo velocemente al 2015 quando la virtualizzazione è lo standard de facto e il provisioning automatizzato aiuta a consegnare una nuova VM in pochi minuti e il vecchio metodo di fare le cose non è quasi più convincente. Ora, quando hai bisogno di uno spazio per un file server, server DHCP, server di stampa o qualche altro server di applicazioni, puoi provvedere a una nuova VM. O, ancora meglio, puoi provvedere a una nuova VM come server di utilità. Un server di utilità è un server che ospita tutte le applicazioni e i servizi che sono troppo piccoli per giustificare un server dedicato. Questo permette ai tuoi DC di attenersi a un servizio dedicato che porta più stabilità.

Regola l'ordine di avvio e imposta una password del BIOS.

Mentre tutti i vostri DC in lettura-scrittura dovrebbero trovarsi in un data center sicuro, ci sono molti addetti IT e non IT che hanno accesso al data center. Ad esempio, gli elettricisti sotto contratto che lavorano al sistema di raffreddamento hanno accesso al data center. Inoltre, probabilmente ci sono tecnici di rete, addetti ai cavi e la gestione IT con accesso al data center. Chiunque abbia accesso fisico a un DC può ottenere l'accesso a un DC fisico in soli un paio di minuti tramite una console nel data center. Esistono immagini di boot freeware specializzate che puoi utilizzare per avviare e reimpostare le password, installare malware o accedere ai dati del disco, assumendo che il disco non sia criptato. Per evitarlo, esegui le seguenti configurazioni:

• Assicurati che nessun supporto rimovibile faccia parte dell'ordine di avvio del BIOS. Invece, solo l'hard disk dove è installato il sistema operativo dovrebbe essere incluso nell'ordine di avvio. Questo vale anche per i tuoi server host di virtualizzazione, se hai DC virtuali.
• Imposta una password BIOS robusta. Se non imposti una password BIOS, qualcuno potrebbe aggiornare l'ordine di avvio, avviare i media di installazione di Windows Server o molti toolkit freeware, eseguire una riparazione per arrivare a un prompt dei comandi. Una volta al prompt dei comandi, possono causare svariati danni e reimpostare rapidamente le password per gli account di dominio.
• Conservate i DC in un armadio chiuso a chiave. Anche se una password del BIOS rappresenta un livello di sicurezza, se l'attaccante è almeno parzialmente capace, probabilmente saprà come resettare il BIOS in modo che la configurazione venga ripristinata e la password rimossa. Spesso, ciò richiede l'accesso alla scheda madre. È possibile ridurre il rischio di un tale attacco conservando i DC in un armadio chiuso a chiave. Alcuni server consentono anche l'installazione di serrature sul telaio. In ambienti ad alta sicurezza, si dovrebbe optare per entrambe le soluzioni.

Standardizzare la configurazione di tutti i controller di dominio.

Dovresti cercare di far corrispondere le impostazioni di configurazione per ogni DC. Puoi realizzare parte di ciò utilizzando l'automazione della build tramite strumenti di distribuzione come System Center Configuration Manager. Gli elementi di interesse per i DC sono le impostazioni delle dimensioni del registro eventi per garantire che tu abbia dimensioni grandi per catturare informazioni relative all'auditing e alla sicurezza, impostazioni di avvio come il tempo di attesa per la selezione del sistema operativo sui server fisici, versioni e impostazioni del firmware e del BIOS, e configurazione hardware. Naturalmente, ci sono molti altri elementi di configurazione da standardizzare utilizzando Group Policy. L'obiettivo principale è configurare i DC in modo identico.

Troverai maggiori informazioni sui fondamenti di Active Directory nel nostro AD tutorial for beginners.