Windows Server: Active Directory Best Practice

Active Directory

Active Directory è il cuore, a livello di infrastruttura IT, della maggior parte delle aziende in giro per il mondo ed è sicuramente il primo strato su cui costruire la parte di sicurezza, compliance ed automazione per utenti e computer. Per creare la giusta infrastruttura, non è necessario essere un mago ma è importante conoscere alcuni piccoli trucchi per evitare problemi di configurazione e di sicurezza.

Active Directory in Breve

Active Directory è nato oltre 18 anni fa, con l’arrivo di Windows 2000 Server, per consolidare un modello introdotto in Windows NT4. L’idea di AD è quella di avere un database con tutte le informazioni relative agli oggetti dell’infrastruttura (utenti, computer, gruppi, etc) al fine di semplificarne l’accesso e lo scambio di dati. Come ogni database, anche altri prodotti possono leggerne il suo contenuto per valutare l’accesso alle varie risorse.

La caratteristica più importante di Active Directory è quella di poter estendere il proprio schema per aggiungere colonne, proprietà e valori. Alcune applicazioni, come Exchange Server, utilizzano AD per aggiungere i loro elementi e funzionalità; questo consente di consolidare ed evitare di inventarsi altri metodi per gestire i permessi e le proprietà delle cassette postali.

Prima di capire come si configura una foresta Active Directory, è necessario conoscere i termini chiave perché sapere a cosa servono, aiuta a capire anche come affrontare il troubleshooting, nel caso ci siano dei problemi.

Forest

Quando create il primo Domain Controller, è necessario scegliere il nome della Foresta che è anche il primo Domain Name (es. contoso.com). Il nome di foresta è univoco e non dovrebbe essere mai cambiato in corso d’opera, a meno che non abbiate un modello semplice (mono dominio) e che non abbiate software che non supportano questa operazione (es. Exchange Server).

Ogni foresta vive di vita propria e non può parlare con le altre a meno che non si crei un Trust: questa modalità consente di mettere in comunicazioni due entità separate per consentire l’accesso alle risorse in modo incrociato; ad esempio è una pratica usata quando due aziende vengono fuse, dato che il trust consente all’utente del dominio A ad accedere al file server del dominio B con le sue credenziali.

Domain

Il domain name è il cuore di tutto. Quando viene creato il primo Domain Controller, sceglierete il nome di dominio e con esso l’etichetta da applicare ad ogni oggetto della vostra infrastruttura.

Nella maggior parte dei modelli AD, foresta e dominio coincidono con lo stesso nome perché riduce la complessità dell’infrastruttura.

Esiste la possibilità di dividere il modello infrastrutturale in Child Domain Name (es. it.contoso.com), ovvero entità logiche separate dal dominio principale che consentono di essere gestite in modo diverso. Alcune grandi realtà utilizzano il dominio di primo livello per posizionare le risorse (es. i server) ed usano i sub-domain per posizionare utenti e gruppi).

Ogni sub-domain richiede un Domain Controller dedicato ed il Trust viene configurato automaticamente con il dominio principale, per consentire il passaggio delle informazioni.

FSMO

Il Flexible Single Master Operation è l’insieme di cinque ruoli su cui ruota l’entità Active Directory. Quando si vuole aggiungere un nuovo dominio, un nuovo Domain Controller, sincronizzare l’orario o aggiungere un nuovo oggetto (utente o gruppo), viene chiamato in causa. Di default i ruoli FSMO vengono assegnati al primo DC creato, ma possono essere separati su due o più macchine. I 5 ruoli sono così chiamati:

  • Schema Master (Forest)
  • Domain Naming Master (Forest)
  • Primary Domain Controller (Domain)
  • Infrastructure Master (Domain)
  • RID (Domain)

La perdita di un Domain Controller con uno di questi ruoli può ridurre alcune funzionalità. Ad esempio, la perdita del ruolo Primary Domain Controller impedisce di ricevere l’aggiornamento delle password quando vengono modificate. Per capire meglio i ruoli FSMO e come posizionarli al meglio, potete fare riferimento all’articolo Microsoft: FSMO placement and optimization on Active Directory domain controllers.

Global Catalog

Il global catalog è un catalogo multi-dominio che consente una ricerca rapida degli oggetti senza dover fare l’interrogazione all’interno di ogni singolo dominio. Il suo scopo è di usare informazioni parziali o set di attributi per trovare velocemente utenti, computer ed altre risorse di Active Directory. Necessario in qualsiasi infrastruttura, questo ruolo diventa cruciale in scenari complessi (es. multi dominio).

Il ruolo di GC è assegnato automaticamente al primo Domain Controller creato e viene mantenuto dal sistema di replica di ADDS. È possibile assegnare questo ruolo anche agli altri DC ma, in alcuni casi, è una cosa sconsigliata.

DNS

Non esiste Active Directory senza un Domain Name System, ovvero l’albero che consente la trasposizione tra nome ed indirizzo IP. Il server DNS si occupa di gestire tutti gli oggetti fisici che fanno parte dell’infrastruttura AD e ne mantiene gli aggiornamenti quando gli oggetti hanno il trust (solitamente quando le macchine appartengono al dominio).

Senza una corretta configurazione DNS, tutto Active Directory non funzionerebbe nel modo corretto; non a caso, nella maggior parte dei problemi riscontrati nella risoluzione di oggetti, o di autenticazione, troviamo come primo indiziato il DNS server.

Ad esempio, l’errata rimozione di un Domain Controller può portare all’errata rimozione nei DNS, cosa che porta errori nelle repliche, client che non riescono a contattare gli oggetti o che non riescono a fare più l’autenticazione.

Creare un’infrastruttura Active Directory

Dopo aver visto un po’ la terminologia necessaria, è tempo di vedere come creare un’infrastruttura Active Directory all’interno di Windows Server. E’ bene ricordare che bisogna sempre partire da un server nuovo, non clonato, totalmente aggiornato e senza nessun software extra a bordo.

Aprite il Server Manager ed aggiungete i ruoli chiamati Active Directory Domain Server e DNS Server – figura 1.

Una volta terminato il wizard, sarà possibile promuovere la macchina come Domain Controller – figura 2. Per i più “anziani”, avrete notato che non esiste più la possibilità di usare il comando dcpromo, in quanto deprecato da Windows Server 2012.

Selezionate Add a New Forest – figura 3 – ed inserite il Root Domain Name. Quest’ultimo sarà il primo nome di dominio della vostra infrastruttura e probabilmente sarà anche l’unico.

Il secondo step è quello di selezionare il Forest/Domain Functional Level: questo è molto importante perché non può essere portato verso il basso ma può essere aumentato. Il livello minimo da usare è sicuramente Windows Server 2012, questo perché 2008 e 2008 R2 sono ormai a fine ciclo di vita, inoltre ci sono applicativi che richiedono un livello ben specifico. Ad esempio, Exchange Server 2019 richiede un livello pari a Windows Server 2012 R2.

Modificare il livello di funzionalità verso l’alto è un’operazione, il più delle volte, che si può fare a caldo e senza impatti sui prodotti. Bisogna fare più attenzione quando si ha a che fare con infrastrutture complesse, o in trust, o con software datati.

Come si può vedere, il primo Domain Controller deve avere per forza il ruolo di Global Catalog e DNS server. Prima di proseguire, inserite la password di Directory Services Restore Mode, che potrebbe servirvi nel caso il servizio di AD abbia un problema critico.

Il wizard continua con la scelta del nome NETBIOS, che di solito è uguale al nome di dominio oppure ne è la versione abbreviata. Il nome NETBIOS ormai non viene più utilizzato, dato che l’autenticazione andrebbe sempre fatta tramite FQDN (utente@dominio.xx) e non con il modello legacy NETBIOS\utente.

Il path – figura 6 – è un altro aspetto importante quando si configura il Domain Controller, perché impedisce problemi di sicurezza e performance. Quando si usa una macchina virtuale, può essere comodo usare un disco separato per posizionare i database; tale disco può essere fisso o dinamico (dipende dal numero di scritture effettuate) e deve essere almeno di 5GB (oltre potrebbe non avere senso).

La formattazione deve essere NTFS in quanto ReFS non è supportato! Se pianificate l’installazione di un antivirus, assicuratevi di escludere tutte le cartelle relative al ruolo, per evitare la corruzione del dato.

Verificate che tutti i parametri impostati siano corretti, perché poi non sarà possibile tornare indietro facilmente. All’interno della Review Options è anche possibile visualizzare lo script in PowerShell di quanto fatto, in modo da salvarlo ed utilizzarlo in futuro.

L’ultima schermata è dedicata al controllo dei prerequisiti, che verificherà la presenza di errori prima di iniziare il wizard. Durante la creazione del primo DC, potrebbero essere mostrati dei warning che possono essere ignorati. Cliccare sul pulsante Install per avviare la procedura di configurazione; il tempo di esecuzione sarà di pochi minuti, al termine sarà fatto automaticamente il riavvio.

Una volta che la macchina sarà pronta, potrete accedere al vostro Domain Controller nuovo fiammante.

Best Practice

Quando pianificate la costruzione di un’infrastruttura Active Directory, è bene conoscere alcuni trucchi per evitare problemi di sicurezza e configurazione:

Rinominare il Domain Admin – Tutti gli attacchi partono con il cercare di forzare l’account administrator. Il vostro primo step deve essere quello di rinominarlo, scegliendo un nome diverso dagli standard. Ad esempio potrebbe chiamarsi come la vostra azienda: AdminContosoAD.

Password Forte per il Domain Admin – Sicurezza, sicurezza, sicurezza! Il Domain Admin deve avere una password complessa e riservata. Ricordate che questo account ha accesso a tutto e quindi una volta perso, non ci sarà modo di fermarlo e qualsiasi oggetto sarebbe a rischio.

Credenziali Dedicate per gli IT – Ogni figura del reparto IT deve avere credenziali separate, una per le operazioni ordinarie (uso del PC) ed una per le operazioni di amministrazione. In caso di attacco, l’account classico non avrà accesso a niente se non il proprio PC e questo eviterà l’escalation dal punto di vista della sicurezza.

Assegnare i Giusti Permessi – Se avete più amministratori, è bene assegnare permessi ben definiti ad ognuno di essi. Le credenziali nominali, oltre ad essere richieste per legge, sono utili per capire chi fa cosa. Nessun utente dovrebbe mai andare oltre il ruolo di Domain Admin, per evitare la modifica dello schema o di altre aree di Active Directory.

Configurare le GPO – La configurazione delle Group Policy per utenti e computer è al capitolo 2. Il modello da adottare è un po’ soggettivo: evitate l’uso di centinaia di GPO ma non accorpate tutto in una sola policy. Sicuramente non dovete usare la Default Domain Policy!

Password Forte per gli Utenti – Non solo il Domain Admin, ma anche tutti gli utenti (account di servizio inclusi) devono rispettare un criterio di password forte. Nel caso usiate Windows 10, può essere comodo implementare Windows Hello for Business, per semplificare il modello di autenticazione, mantenendo uno standard di sicurezza molto elevato.

Attivate AD Recycle Bin – Il cestino di Active Directory è stato implementato in Windows Server 2008 R2 e serve per recuperare gli oggetti eliminate per errore, in pochi click e senza l’uso delle procedure di restore.

Almeno Due Domain Controller – Non importa la dimensione della vostra infrastruttura, avere due DC può essere un grande paracadute perché la perdita dell’unico Domain Controller potrebbe significare il fermo forzato di tutta la vostra azienda.

Rimuovere gli Oggetti Obsoleti – Ricordate di fare pulizia, di tanto in tanto, della vostra foresta, eliminando computer ed utenti non più presenti e disattivando quelli che per periodo di tempo non dovranno fare più accesso. Questo ridurrà i rischi di sicurezza.

Il Domain Controller non è un Computer – Il Domain Controller deve essere trattato come un santuario. Nessun software di terze parti, nessun ruolo aggiuntivo di Windows, nessun tool! Il Domain Controller fa solo il Domain Controller!

Naming Convention – Definire una naming convention può aiutarvi a costruire un’infrastruttura pulita e parlante. Questa metodologia dovrebbe essere applicata per i client, i server ma anche i network device.

Aggiornare i DC – La sicurezza passa anche dall’applicazione degli aggiornamenti di Windows e tenere allineati i Domain Controller aiuta la vostra azienda a non essere soggetta agli ultimi exploit e falle di sicurezza.

Best Practice Virtual Machine

Volete implementare Active Directory tramite delle macchine virtuali? Nessun problema, ma è bene tenere a mente le seguenti considerazioni:

I DC Virtuali sono Supportati – A partire da Windows Server 2012, grazie all’introduzione di un componente chiamato VM Generation-ID, è possibile usare una macchina virtuale come Domain Controller. Con Windows Server 2008 e 2008 R2, era possibile ma non supportato da Microsoft. Ricordate sempre di impostare l’avvio automatico della VM con un Start-Time di 0 secondi.

No Checkpoint – Benchè supportati, è meglio evitare la creazione dei checkpoint per i Domain Controller.

Disattivate il Time Synchronization – Un Domain Controller si aspetta sempre di essere a monte della catena, per quanto riguarda la gestione del tempo. Per questo motivo è necessario disattivare la sincronizzazione tra il vostro Host di virtualizzazione e la macchina virtuale.

Non Mettere il Domain Controller in Saved State – Quando una macchina virtuale viene richiamata dal saved state, o richiamata da un checkpoint, il suo orario non sarà allineato e questo potrebbe generare problemi con le repliche oltre che con l’interrogazione con gli altri server.

Non Convertire un Domain Controller – Fisico o virtuale non importa, la conversione non è supportata. Se dovete migrare un Domain Controller, dovete reinstallarlo da zero e migrare i ruoli di FSMO per poi fare il demote in modo corretto.

Upgrade in Place – Anche il salto di sistema operativo non è supportato ed il criterio da applicare è lo stesso della conversione, ovvero creare un nuovo server.

VM Replica – La replica non dovrebbe essere mai usata. Se avete un sito di Disaster Recovery, è bene configurare un Domain Controller ed usare gli strumenti di Active Directory per effettuare la replica, che è sicuramente più funzionale.

Considerazioni

Come visto, avere tutte le informazioni su come configurare Active Directory può aiutarci a decidere come implementare al meglio l’infrastruttura per evitare errori di configurazione. Come al solito però, leggete bene la documentazione ufficiale per verificare che quello che volete fare è supportato da Microsoft o dal vendor.