Come mostrato negli articoli precedenti, quando si installa il sistema operativo Windows, il computer viene automaticamente aggiunto ad un gruppo di lavoro chiamato WORKGROUP (o HOME). Sebbene i gruppi di lavoro funzionino bene per ambienti piccoli con pochi dispositivi, non sono scalabili in ambienti aziendali. Nella maggior parte degli ambienti aziendali, si utilizzerà un dominio.
I computer connessi ad una rete possono essere parte di un gruppo di lavoro o di un dominio. La principale differenza tra un gruppo di lavoro e un dominio è data da come le risorse di rete vengono gestite. Generalmente i computer connessi a reti di piccole dimensioni, come quelle all'interno della propria abitazione, fanno parte di un gruppo di lavoro mentre i computer connessi a reti di grande dimensioni o di un'azienda fanno solitamente parte di un dominio.
Per capire meglio la differenza tra un gruppo di lavoro e un dominio supponiamo di voler inibire l'accesso al Pannello di Controllo agli utenti su tutte le postazioni di una rete.
In un gruppo di lavoro dovremmo connetterci, come amministratore, su ciascuna postazione e procedere all'impostazione manualmente.
In un dominio tutte le impostazioni possono essere gestite centralmente attraverso un software, presente sui server, chiamato Active Directory. Tramite Active Directory è possibile, ad esempio, fare anche in modo che un determinato utente possa eseguire il logon solo su una determinata workstation dell'azienda, specificare a che ora l'utente può effettuare il login sulle postazioni, personalizzare lo sfondo delle postazioni di un particolare dipartimento dell'azienda, ecc. Un altro caso in cui è utile utilizzare il dominio è nella distribuzione del software. Supponiamo di dover installare MS Office su tutti i computer dell'azienda. Possiamo effettuare tale operazione attraverso le group policy e utilizzando un dominio (in un prossimo articolo mostrerò come effettuare tale operazione).
Prima di procedere con la creazione di un Dominio facciamo un po' di chiarezza su alcuni termini.
Prima di passare alla creazione di un controller di dominio, è importante fare un po' di chiarezza su alcuni termini e capire cos'è un dominio Active Directory, come è strutturato e alcuni dei gruppi predefiniti che vengono creati quando si crea un dominio Active Directory.
Workgroup
Un gruppo di lavoro è un'insieme composto da uno o più computer su una stessa rete locale o subnet che non appartengono ad un dominio. Tutti i computer sono alla pari e indipendenti e non esiste un computer che ha il controllo sugli altri. Ciascun computer dispone di un insieme di account utente e, per poter utilizzare tutti i computer di un gruppo di lavoro, è necessario disporre di un account utente su ciascun computer.
Dominio
Un dominio è la massima unità amministrativa su una rete di computer e può essere considerato come un insieme di oggetti (account utente, computer, unità organizzative, stampanti, ecc) che condividono lo stesso database consentendo notevoli vantaggi nella gestione delle risorse IT. La stessa Microsoft definisce il dominio come un insieme di computer che condividono un database di risorse di rete e che vengono amministrati come un'unità con regole e procedure comuni.
Uno o più computer della rete sono server. Gli amministratori del dominio utilizzano i server per gestire la sicurezza e i permessi di tutti i computer/account/risorse del dominio (gestione centralizzata tramite Active Directory).
Gli utenti che dispongono di un account di dominio possono eseguire l'accesso su tutti i computer del dominio (salvo eventuali restrizioni imposte dagli amministratori) senza che sia già presente un account locale sulla postazione. I computer possono essere su reti diverse e un dominio può a sua volta far parte di un dominio di livello superiore.
Domain Controller
Il Domain Controller è un server con installato Windows Server e Active Directory Domain Services che, all'interno del dominio, gestisce le richieste di autenticazione relative alla sicurezza (login, controllo permessi, abilitazioni, ecc) e permette l'organizzazione della struttura del dominio gestendo utenti, gruppi, computer, unità organizzative, risorse di rete, ecc. Il server su cui è installato Active Directory che gestisce il dominio di livello superiore è definito Primary Domain Controller.
Servizi di dominio Active Directory
Active Directory Domain Services (AD DS) è un servizio integrato nei sistemi operativi Windows Server ma non viene installato di default. Affinché un server possa essere promosso a Domain Controller è necessario installare Active Directory Domain Services, il relativo database e altre funzionalità necessarie al suo corretto funzionamento. Ciascun controller di dominio dispone di una copia locale del database Active Directory che viene aggiornata dinamicamente dagli stessi domain controller. Dato che tutti i sistemi di un dominio fanno riferimento ad Active Directory è opportuno avere almeno due controller di dominio a fini di ridondanza; in questo modo se un controller di dominio presenta problemi o non si avvia, l'intera infrastruttura continuerà a funzionare.
Foresta
Una Foresta è una singola istanza di Active Directory. All'interno di una Foresta è possibile avere uno o più domini che condividono lo stesso schema. Un singolo dominio su un singolo Domain Controller rappresenta la più piccola Foresta che è possibile creare. La Foresta è indicata anche come recinto di sicurezza in cui gli utenti, i computer e altri oggetti sono accessibili.
L'utilizzo di più foreste può rivelarsi utile in un ambiente in cui la separazione dei confini della sicurezza è fondamentale ad esempio per la separazione della rete aziendale dalla rete di produzione. La foresta aziendale viene utilizzata per gestire le workstation aziendali da cui si accede alla posta elettronica e a Internet. La foresta di produzione viene utilizzata solo per gestire il traffico di autenticazione verso i server o i dispositivi di rete. Separando le foreste e, per estensione, i confini di sicurezza di queste due reti, si salvaguarda l'ambiente di produzione da quello aziendale potenzialmente infetto da malware.
Catalogo Globale (Global Catalog)
Un catalogo globale contiene tutte le informazioni relative al suo dominio più le informazioni relative agli altri domini della foresta. Risiede sui controller di dominio che sono stati abilitati come server del catalogo globale e i dati sono distribuiti attraverso la replica di Active Directory. Un Domain Controller configurato come Global Catalog conserva, oltre alla intera partizione del suo dominio, alle partizioni schema e configuration della foresta anche una replica parziale e di sola lettura delle partizioni degli altri domini. Esiste un unico Global Catalog all'interno di una Foresta ma ci sono più copie distribuite tra i domain controller. Un Global Catalog oltre ad essere usato dai client per le ricerche in Active Directory, fornisce anche altri servizi come ad esempio fornire riferimenti ad altri oggetti in diversi domini, la risoluzione dei nomi principali degli utenti (UPN) e l'universal group membership caching.
Unità Organizzative (UO)
Le unità organizzative sono una sorta di contenitori di oggetti memorizzati in Active Directory e utilizzati per la loro organizzazione. Le unità organizzative vengono utilizzate principalmente per formare una gerarchia di contenitori all'interno di un dominio a scopo amministrativo come ad esempio per l'applicazione dei Criteri di gruppo o per delegare il controllo. Il controllo su un'unità organizzativa e sugli oggetti in essa contenuti viene fornita tramite liste di controllo degli accessi (access control list o ACL). La delega del controllo supportata in Active Directory consente di trasferire il controllo amministrativo completo o limitato sugli oggetti ad altri utenti o gruppi. In questo modo è possibile distribuire la gestione di un numero elevato di oggetti ad una serie di utenti ritenuti attendibli.
Schema
Lo schema di Microsoft Active Directory è simile a un dizionario in quanto contiene definizioni formali di ogni classe oggetto che può essere creata in una foresta di Active Directory. Lo schema contiene anche definizioni formali di ogni attributo che può esistere in un oggetto Active Directory.
Gruppi di dominio predefiniti
Quando si crea un dominio Active Directory, per impostazione predefinita vengono creati diversi gruppi amministrativi. In qualità di amministratori di sistema, bisogna fare attenzione ad applicare il concetto di minimo privilegio, ovvero che gli utenti devono avere i permessi minimi necessari per svolgere il proprio lavoro, ma niente di più. Il gruppo Enterprise Admins è un gruppo molto privilegiato e non dovrebbe essere la soluzione a tutti i problemi di autorizzazioni.
Tra i gruppi predefiniti troviamo:
- Enterprise Admins
Questo gruppo si trova nel dominio radice della foresta. È un membro degli amministratori incorporati in ogni dominio della foresta. I membri del gruppo Enterprise Admins possono apportare modifiche alla foresta, aggiungere o rimuovere domini, stabilire trust della foresta e aumentare i livelli funzionali della foresta. Questo gruppo deve essere usato solo se necessario (ad esempio quando si costruisce una foresta per la prima volta o quando si apportano modifiche all'intera foresta) perché è un gruppo altamente privilegiato. - Domain Admins
I membri del gruppo Domain Admins sono membri del gruppo Built-in Administrators del dominio. Vengono aggiunti automaticamente al gruppo Amministratore locale su ogni sistema unito al loro dominio. - Administrator
Gli amministratori di dominio (Domain Admins) sono membri del gruppo Administrator del dominio in cui risiede il loro account. Gli Enterprise Admins sono membri di questo gruppo in tutti i domini della loro foresta. Questo gruppo garantisce l'accesso al gruppo degli amministratori locali su tutti i sistemi collegati al dominio. Il gruppo Administrator ha la possibilità di gestire la maggior parte degli oggetti del dominio con autorizzazioni complete e può assumere la proprietà di quasi tutti gli oggetti del dominio. - Schema Admins
Schema Admins è un gruppo speciale. Esiste nel dominio radice della foresta, come il gruppo Enterprise Admins. Gli amministratori di schema hanno il permesso di gestire lo schema in Active Directory, ma nient'altro. Questo rende gli amministratori di schema un gruppo meno privilegiato, ma bisogna fare attenzione a chi viene assegnato tale gruppo. Le modifiche allo schema che non vanno a buon fine possono danneggiare Active Directory. Questo gruppo dovrebbe essere assegnato solo nei casi rari in cui è necessario apportare modifiche allo schema. - Gruppi amministrativi aggiuntivi
I gruppi amministrativi aggiuntivi vengono creati man mano che si installano ruoli e applicazioni. DHCP, DNS e Exchange Server sono solo alcuni esempi di ruoli o applicazioni che creano nuovi gruppi amministrativi in Active Directory.
|
FIG 1 - Gruppi di dominio predefiniti |
Ruoli FSMO (Flexible Single Master Operation)
Qualsiasi controller di dominio autorevole (DC) in Active Directory (AD) può eseguire la creazione, l'aggiornamento e la cancellazione degli oggetti. Questo è possibile perché ogni DC (tranne quelli di sola lettura) mantiene una copia scrivibile della partizione del proprio dominio. Una volta che una modifica viene applicata, essa viene automaticamente comunicata agli altri DC attraverso un processo chiamato replica multi-master. Questo comportamento consente alla maggior parte delle operazioni di essere elaborate in modo affidabile da più controller di dominio fornendo alti livelli di ridondanza, disponibilità e accessibilità in Active Directory.
Tuttavia ci sono alcune operazioni sensibili la cui esecuzione è limitata ad uno specifico controller di dominio, in questi casi Active Directory indirizza tali operazioni a server con una serie speciali di ruoli. Microsoft chiama tali ruoli "ruoli operativi" ma sono più comunemente noti con il loro nome originale: ruoli FSMO (Flexible Single Master Operation).
In Active Directory sono presenti 5 ruoli FSMO assegnati a uno o più controller di dominio:
- Schema Master
- Domain Naming Master
- Infrastructure Master
- Relative ID (RID) Master
- PDC Emulator
Schema Master
Schema Master (o Master dello schema) è un ruolo FSMO di livello enterprise. In una foresta Active Directory esiste un solo Schema Master. Il Domain Controller in Active Directory che ricopre il ruolo di Schema Master è l'unico DC, all'interno della foresta, che contiene una partizione di schema scrivibile e controlla tutti gli aggiornamenti e le modifiche dello schema. Di conseguenza per aggiornare lo schema di una foresta, è necessario avere accesso allo Schema Master. Esempi di azioni che aggiornano lo schema sono l'innalzamento del livello funzionale della foresta e l'aggiornamento del sistema operativo di un DC a una versione superiore a quella presente nella foresta.
Se il Domain Controller con il ruolo di Schema Master dovesse andare offline, l'impatto immediato sarà minimo o nullo. Infatti, a meno che non siano necessarie modifiche allo schema, il ruolo può rimanere offline senza effetti rilevanti. Se il Domain Controller con il ruolo di Schema Master non può essere riportato online è possibile trasferire il ruolo ad altro Domain Controller.
Domain Naming Master
Domain Naming Master (Master per la denominazione dei domini) è un ruolo FSMO di livello enterprise. Nell'intera foresta può essere presente un solo master per la denominazione dei domini. Il controller di dominio master per la denominazione dei domini è l'unico controller di dominio, in una foresta Active Directory, in grado di aggiungere e rimuovere domini nella foresta. Nel caso in cui il Domain Controller che ricopre tale ruolo dovesse andare offline, l'impatto operativo sarebbe minimo o nullo, poiché l'aggiunta e la rimozione di domini e partizioni sono operazioni eseguite di rado e sono raramente critiche dal punto di vista temporale.
Infrastructure Master
L'Infrastructure Master (Master dell'infrastruttura) è un ruolo a livello di dominio; in ogni dominio può essere presente un solo controller di dominio che funge da master dell'infrastruttura. Il master dell'infrastruttura sincronizza gli oggetti con i server del catalogo globale (global catalog) ed è responsabile dell'aggiornamento dei riferimenti da oggetti nel relativo dominio a oggetti in altri domini. L'Infrastructure Master confronta i propri dati con quelli di un server del catalogo globale e riceve dal server del catalogo globale tutti i dati non presenti nel proprio database. Se tutti i DC di un dominio sono anche server del catalogo globale, tutti i DC disporranno di informazioni aggiornate (supponendo che la replica sia funzionale). In questo scenario, la posizione del ruolo Infrastructure Master è irrilevante, poiché non ha alcun lavoro da svolgere.
Il ruolo Infrastructure Master è anche responsabile della gestione degli oggetti fantasma. Gli oggetti fantasma sono utilizzati per tracciare e gestire i riferimenti persistenti agli oggetti eliminati e agli attributi con valore di collegamento che si riferiscono a oggetti in un altro dominio della foresta (ad esempio, un gruppo di sicurezza del dominio locale con un utente membro di un altro dominio).
Il ruolo può essere installato su qualsiasi controller di dominio in un dominio. Nel caso in cui la foresta Active Directory includa DC che non siano global catalog allora il ruolo va installato su uno di questi DC. La perdita del DC che possiede il ruolo di Infrastructure Master sarà probabilmente percepita solo dagli amministratori e potrà essere tollerata per un periodo prolungato. Sebbene la sua assenza comporti la mancata risoluzione corretta dei nomi dei collegamenti di oggetti cross-domain, la capacità di utilizzare le appartenenze di gruppo cross-domain non sarà compromessa.
RID Master
Il Relative Identifier Master (RID Master) è un ruolo a livello di dominio; in ogni dominio può essere presente un solo controller di dominio che funge da RID Master. Il RID Master è responsabile dell'elaborazione delle richieste del pool RID da tutti i controller di dominio in un determinato dominio. I pool di RID sono costituiti da un intervallo contiguo univoco di RID, che vengono utilizzati durante la creazione dell'oggetto per generare l'identificativo di sicurezza (SID) unico del nuovo oggetto. Il RID Master è anche responsabile dello spostamento degli oggetti da un dominio all'altro all'interno della foresta.
La perdita del RID Master di un dominio finirà per causare l'impossibilità di creare nuovi oggetti nel dominio, man mano che i pool di RID nei DC rimanenti si esauriscono. Sebbene possa sembrare che l'indisponibilità del DC che detiene il ruolo di RID Master possa causare un'interruzione significativa dell'operatività, negli ambienti maturi l'impatto è solitamente tollerabile per un periodo di tempo considerevole, a causa di un volume relativamente basso di eventi di creazione di oggetti.
PDC Emulator
L'emulatore del controller di dominio primario (PDC Emulator o PDCE) è un ruolo a livello di dominio; può essere presente un solo controller di dominio che funge da master dell'emulatore PDC in ogni dominio della foresta. L'emulatore PDC è un controller di dominio che si annuncia come controller di dominio primario (PDC) per workstation, server membri e controller di dominio che eseguono versioni precedenti di Windows. L'emulatore PDC controlla l'autenticazione all'interno di un dominio, sia Kerberos v5 che NTLM. Quando un utente cambia la password, la modifica viene elaborata dall'emulatore PDC.
PDC Emulator è responsabile di diverse operazioni cruciali:
Retrocompatibilità. Il PDCE imita il comportamento single-master di un controller di dominio primario di Windows NT. Per risolvere i problemi di retrocompatibilità, il PDCE si registra come DC di destinazione per le applicazioni legacy che eseguono operazioni scrivibili e per alcuni strumenti amministrativi che non conoscono il comportamento multi-master dei DC di Active Directory.
Sincronizzazione dell'ora. Ogni PDCE funge da sorgente temporale master all'interno del proprio dominio. Il PDCE nel dominio radice della foresta funge da server NTP (Network Time Protocol) preferito nella foresta. Il PDCE di ogni altro dominio della foresta sincronizza il suo orologio con il PDCE radice della foresta; i DC non PDCE sincronizzano i loro orologi con il PDCE del loro dominio e gli host collegati al dominio sincronizzano i loro orologi con il DC preferito. Un esempio dell'importanza della sincronizzazione temporale è l'autenticazione Kerberos: l'autenticazione Kerberos fallisce se la differenza tra l'orologio di un host richiedente e l'orologio del DC di autenticazione supera il massimo specificato (5 minuti per impostazione predefinita); questo aiuta a contrastare alcune attività dannose, come gli attacchi replay.
Aggiornamenti delle password. Quando le password di computer e utenti vengono modificate o reimpostate da un controller di dominio non PDCE, l'aggiornamento impegnato viene immediatamente replicato al PDCE del dominio. Se un account tenta di autenticarsi in un DC che non ha ancora ricevuto una modifica recente della password tramite la replica programmata, la richiesta viene passata al PDCE del dominio, che la elabora e indica al DC richiedente di accettarla o rifiutarla. Questo comportamento garantisce che le password possano essere elaborate in modo affidabile anche se le modifiche recenti non si sono propagate completamente attraverso la replica programmata. Il PDCE è anche responsabile dell'elaborazione dei blocchi degli account, poiché tutte le autenticazioni di password fallite vengono passate al PDCE.
Aggiornamenti dei Criteri di gruppo. Tutti gli aggiornamenti degli oggetti Criteri di gruppo (GPO) sono assegnate al PDCE del dominio. In questo modo si evitano i conflitti di versione che potrebbero verificarsi se una GPO venisse modificata su due DC nello stesso momento.
File system distribuito. Per impostazione predefinita, i server root del file system distribuito (DFS) richiedono periodicamente informazioni aggiornate sullo spazio dei nomi DFS al PDCE. Sebbene questo comportamento possa causare colli di bottiglia nelle risorse, l'attivazione del parametro Dfsutil.exe Root Scalability consentirà ai server root DFS di richiedere gli aggiornamenti dal DC più vicino.
Il PDCE deve essere collocato su un DC ad alta accessibilità, ben collegato e ad alte prestazioni. La perdita del DC che possiede il ruolo PDC Emulator può avere un impatto immediato e significativo sulle operazioni.
Identificare i DC con ruoli FSMO
Per identificare i controller di dominio con ruolo FSMO è possibile procedere tramite il prompt dei comandi o tramite PowerShell.
Dal prompt dei comandi è possibile eseguire il comando
netdom query fsmo /domain:<DomainName>
Ad esempio
netdom query fsmo /domain:mycompany.local
|
FIG 2 - Visualizzare i server DC con ruoli FSMO da prompt dei comandi |
Da PowerShell il comando da eseguire è
(Get-ADForest).Domains | ForEach-Object{Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | Select-Object Domain, HostName, OperationMasterRoles
|
FIG 3 - Visualizzare i server DC con ruoli FSMO da PowerShell |