mercoledì 26 luglio 2023

Windows Server 2022: Installazione ruolo Server DNS (Domain Name System)

Il Server DNS (Domain Name System) fornisce funzionalità di risoluzione dei nomi per le reti TCP/IP. Generalmente viene installato nello stesso server di Servizi di dominio Active Directory (AD DS), ma può essere installato anche su uno o più server separati ed è fondamentale per il funzionamento di Active Directory Domain Services (AD DS).

Il ruolo Server DNS, se non presente all'interno dell'infrastruttura esistente, può essere installato automaticamente insieme al ruolo Servizi di dominio Active Directory oppure è possibile installarlo manualmente da solo.
In quest'articolo verrà illustrato proprio questo secondo caso.
Prima di installare il ruolo Server DNS, assicurarsi che il server abbia un indirizzo IP statico. In caso contrario, verrà visualizzato un avviso durante l'installazione del ruolo. Sarà possibile comunque continuare l'installazione, ma i client potrebbero perdere la connessione al server DNS se l'indirizzo IP cambia.

Installazione ruolo Server DNS tramite GUI

  • Da Server Manager, nella sezione Dashboard, cliccare sul link Aggiungi ruoli e funzionalità.
    Server Manager
    FIG 1 - Server Manager

  • Verrà avviato il Wizard che ci guiderà nell'installazione del ruolo. Nella finestra Prima di iniziare vengono fornite alcune informazioni preliminari sull'installazione/rimozione dei ruoli e funzionalità. Cliccare su Avanti.
    Aggiunta guidata ruoli e funzionalità
    FIG 2 - Aggiunta guidata ruoli e funzionalità

  • Nel passaggio successivo ci viene chiesto di selezionare il tipo di installazione desiderato: è possibile installare ruoli e funzionalità in un computer fisico o una macchina virtuale in esecuzione oppure in un disco rigido virtuale offline. In questa fase possiamo scegliere tra installare ruoli e funzionalità su un server oppure installare una specifica risorsa sull'infrastruttura VDI. Selezionare l'opzione Installazione basata su ruoli o basata su funzionalità e cliccare su Avanti per proseguire.
    Selezione tipo di installazione
    FIG 3 - Selezione tipo di installazione

  • Nella schermata Selezione server di destinazione possiamo selezionare su quale server installare i ruoli e le funzionalità. Selezionare il server desiderato quindi proseguire cliccando su Avanti.
    Selezione server di destinazione
    FIG 4 - Selezione server di destinazione

  • Nella schermata Selezione ruoli server, selezionare Server DNS.
    Selezione ruoli server
    FIG 5 - Selezione ruoli server

  • Apparirà una nuova finestra di dialogo in cui l'utente viene avvisato sulla necessità di installare, se non presenti, ulteriori funzionalità per il corretto funzionamento del ruolo selezionato. Cliccare su Aggiungi funzionalità.
    Aggiungere le funzionalità necessarie per Server DNS
    FIG 6 - Aggiungere le funzionalità necessarie per Server DNS

  • Se non è stato configurato un indirizzo IP statico, verrà visualizzata la finestra di dialogo mostrata in FIG 7. Cliccare su Continua.
    Risultati convalida
    FIG 7 - Risultati convalida

  • Si ritorna alla schermata precedente. Cliccare su Avanti per proseguire.
    Selezione ruoli server
    FIG 8 - Selezione ruoli server

  • Nella finestra Selezione funzionalità ci viene data la possibilità di installare, se necessario, ulteriori funzionalità ma al momento possiamo passare oltre cliccando su Avanti.
    Selezione funzionalità
    FIG 9 - Selezione funzionalità

  • Nella nuova schermata vengono visualizzate informazioni sul ruolo Server DNS. Cliccare su Avanti.
    Server DNS
    FIG 10 - Server DNS

  • Ci viene mostrato un resoconto su tutte le funzionalità che verranno installate. É possibile selezionare la casella Riavvia automaticamente il server di destinazione se necessario. In questo modo se dopo l'installazione del ruolo e delle funzionalità dovesse essere necessario un riavvio del sistema, questo verrà eseguito automaticamente. Cliccare sul pulsante Installa per proseguire e attendere che l'installazione venga portata a termine.
    Conferma selezioni per l'installazione
    FIG 11 - Conferma selezioni per l'installazione

  • Al termine dell'installazione, fare clic su Chiudi.

    Stato installazione
    FIG 12 - Stato installazione


Installazione ruolo Server DNS tramite PowerShell

Tramite il cmdlet Get-WindowsFeature andiamo a cercare il nome del ruolo relativo al Server DNS con il comando
 Get-WindowsFeature *DNS*  
Get-WindowsFeature
FIG 13 - Get-WindowsFeature

Individuato il nome (DNS) è possibile avviare l'installazione mediante il comando
 Install-WindowsFeature –Name DNS -Restart     
Utilizzando l'opzione -Restart, al termine dell'installazione il server verrà automaticamente riavviato se necessario.
Install-WindowsFeature
FIG 14 - Install-WindowsFeature





domenica 23 luglio 2023

Windows Server 2022: Preparazione alla creazione di un dominio

Una fase importante nella creazione di un dominio che viene spesso ignorata o trascurata (a dire il vero capita anche per le altre attività) è la pianificazione. Dedicare del tempo per pianificare in anticipo l'installazione e la configurazione di un dominio potrà sembrare una perdita di tempo ma si rivelerà fondamentale per ottenere un risultato migliore e agevolare modifiche future o ulteriori implementazioni. In questo modo si evita anche di dover reinstallare/riconfigurare il tutto a causa di una configurazione errata o non adeguata alle proprie esigenze.

Per iniziare, è fondamentale definire con chiarezza quali sono gli obiettivi e le azioni che si desidera intraprendere: Aggiungere un nuovo controller di dominio ad un'infrastruttura già esistente o creare da zero l'infrastruttura Active Directory.

Aggiungere un nuovo controller di dominio ad un'infrastruttura già esistente

In questo caso ci ritroveremo dinanzi ad un ambiente Active Directory esistente ed è fondamentale verificare quanto segue:
  • Capire se il controller di dominio che andremo ad aggiungere dovrà ospitare uno o più ruoli FSMO e, in caso affermativo, individuare quali.
  • Individuare se il domain controller che stiamo aggiungendo andrà a sostituire uno meno recente o se verrà semplicemente aggiunto all'infrastruttura.
  • Individuare l'attuale livello funzionale della foresta e del dominio.

Creare da zero l'infrastruttura Active Directory

Se stiamo creando da zero la nostra infrastruttura, è necessario:
  • Decidere se l'infrastruttura Active Directory avrà più domini e progettare la sua struttura.
  • Stabilire il tipo si struttura da utilizzare per le UO
La decisione su quanti domini creare dipenderà dalle esigenze specifiche dell'organizzazione. La scelta tra un singolo dominio o una struttura multi-dominio può essere influenzata da fattori come la dimensione dell'organizzazione, la geografia, le politiche di sicurezza e la complessità delle relazioni aziendali.

Un singolo dominio può essere adeguato per organizzazioni di piccole o medie dimensioni con una struttura organizzativa semplice e requisiti di sicurezza relativamente lineari. In questo caso, tutti gli utenti, i gruppi e gli oggetti di dominio sarebbero inclusi nello stesso dominio, semplificando la gestione e l'amministrazione.

Tuttavia, per organizzazioni più grandi o complesse, potrebbe essere preferibile una struttura multi-dominio. Ciò consente di suddividere l'organizzazione in domini più piccoli, in modo da ottenere una maggiore flessibilità nella gestione, nella delega delle autorizzazioni e nell'isolamento dei problemi. Ad esempio, si potrebbero creare domini separati per le diverse unità aziendali, le filiali geografiche o i team specifici. Ogni dominio avrebbe il proprio set di controlli di sicurezza e di amministrazione indipendente.

Per quanto riguarda la struttura delle Unità Organizzative (OU), dipenderà dalle esigenze dell'organizzazione e dalla logica di organizzazione dei suoi oggetti di dominio. Le OU sono contenitori logici all'interno di un dominio che consentono di organizzare e gestire gli oggetti di dominio in modo gerarchico. La struttura delle OU dovrebbe essere progettata in base alle esigenze di gestione, amministrazione e delega delle autorizzazioni.

Un'approccio comune consiste nell'organizzare le OU in modo che riflettano la struttura organizzativa dell'azienda. Ad esempio, si potrebbero creare OU per i dipartimenti, le funzioni aziendali o le sedi geografiche. All'interno di queste OU principali, potrebbero essere create ulteriori OU per suddividere gli oggetti di dominio in base a criteri specifici, come i gruppi di utenti, i ruoli o le posizioni.



Una volta pianificata la struttura di Active Directory è possibile proseguire nella creazione del Domain Controller ma non prima di aver installato Windows Server 2022 e tutti gli aggiornamenti del sistema operativo, in particolare quelli di sicurezza, e aver valutato l'installazione di un buon antivirus aggiornato. 


Livelli funzionali

I livelli funzionali sono utilizzati per indicare ai controller di dominio quali funzioni possono essere abilitate a livello di foresta o di dominio. Con ogni nuova versione di Active Directory, vengono aggiunte nuove funzionalità. Se si sta creando una nuova installazione di Active Directory, è opportuno utilizzare il livello funzionale più alto disponibile. I livelli funzionali possono impedire a un server di diventare un controller di dominio se il suo livello funzionale è troppo basso. I livelli funzionali possono essere impostati a livello di foresta o di dominio. I domini possono funzionare con un livello funzionale superiore a quello della foresta in cui si trovano, ma non possono funzionare con un livello funzionale inferiore a quello della foresta.
Quando si aumenta il livello funzionale, non è possibile aggiungere controller di dominio impostati su un livello funzionale inferiore. È importante notare che il livello funzionale del dominio può essere uguale o superiore al livello funzionale della foresta, ma non può essere inferiore.

Nei sistemi operativi server più vecchi, l'aumento del livello funzionale era un'operazione una tantum. Non c'era un modo semplice per annullare la modifica se questa causava problemi. Oggi non è più così. È possibile tornare a una versione precedente con PowerShell, a condizione che il rollback sia supportato e che non sia stata attivata nessuna delle nuove funzionalità che richiedono il nuovo livello funzionale. Se sono state abilitate, è necessario disabilitarle prima di poter eseguire il rollback.



Rolling back del livello funzionale della foresta

Per impostare il livello funzionale della foresta (o eseguire il rollback) da PowerSHell si utilizza il cmdlet Set-AdForestMode
Set-ADForestMode –ForestMode <livello_funzionale_desiderato>
I valori accettati per il parametro ForestMode sono
  • Windows2000Forest o 0 (Windows Server 2000)
  • Windows2003InterimForest o 1 (Windows Server 2003 Interim Forest)
  • Windows2003Forest o 2 (Windows Server 2003)
  • Windows2008Forest o 3 (Windows Server 2008)
  • Windows2008R2Forest o 4 (Windows Server 2008 R2)
  • Windows2012Forest o 5 (Windows Server 2012)
  • Windows2012R2Forest o 6 (Windows Server 2012 R2)
  • Windows2016Forest o 7 (Windows Server 2016)


Rolling back del livello funzionale del dominio

Per impostare il livello funzionale del dominio (o eseguire il rollback) da PowerSHell si utilizza il cmdlet Set-ADDomainMode
Set-ADDomainMode –DomainMode <livello_funzionale_desiderato>
I valori accettati per il parametro ForestMode sono
  • Windows2000Domain o 0 (Windows Server 2000)
  • Windows2003InterimDomain o 1 (Windows Server 2003 Interim Domain)
  • Windows2003Domain o 2 (Windows Server 2003)
  • Windows2008Domain o 3 (Windows Server 2008)
  • Windows2008R2Domain o 4 (Windows Server 2008 R2)
  • Windows2012Domain o 5 (Windows Server 2012)
  • Windows2012R2Domain o 6 (Windows Server 2012 R2)
  • Windows2016Domain o 7 (Windows Server 2016)



Livello funzionale della foresta

Per aumentare il livello funzionale della foresta, è necessario essere membri del gruppo Enterprise Admin. È necessario aumentare il livello funzionale della foresta dal controller di dominio che gestisce il ruolo Schema Master. Non è possibile farlo dagli altri controller di dominio.
Per verificare il livello funzionale attuale della foresta, aprire PowerShell ed eseguire il comando
Get-ADForest

Livello funzionale Foresta
FIG 1 - Livello funzionale Foresta


Livello funzionale del dominio

Per aumentare il livello funzionale del dominio, è necessario essere membri del gruppo Domain Admin. È necessario aumentare il livello funzionale del dominio sul controller di dominio che esegue il ruolo PDC Emulator. Non è possibile farlo dagli altri controller di dominio.
Per verificare il livello funzionale di dominio attuale, aprire PowerShell ed eseguire il comando
Get-ADDomain

Livello funzionale Dominio
FIG 2 - Livello funzionale Dominio




giovedì 13 luglio 2023

Windows Server 2022: Gruppo di lavoro, Dominio, Foresta e ruoli FSMO

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.
Gruppi di dominio predefiniti
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
Visualizzare i server DC con ruoli FSMO da prompt dei comandi
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


Visualizzare i server DC con ruoli FSMO da PowerShell
FIG 3 - Visualizzare i server DC con ruoli FSMO da PowerShell








martedì 11 luglio 2023

Posta elettronica: Visualizzare il contenuto dell'allegato Winmail.dat

Il problema dell’allegato Winmail.dat è una questione ben nota agli utenti che da anni utilizzano i servizi di posta elettronica. Nell'articolo Outlook: i destinatari non visualizzano gli allegati o questi vengono sostituiti dal file winmail.dat sono state illustrate le cause che provocano la creazione dell'allegato Winmail.dat: generalmente questo si verifica quando si invia un'email utilizzando il formato RTF (Microsoft Outlook Rich text Format) o il Transport Neutral Encapsulation Format (TNEF). Si tratta di due formati proprietari di Microsoft che non andrebbero usati quando si invia un messaggio all'esterno della propria infrastruttura.

Se abbiamo ricevuto un'email con l'allegato Winmail.dat e non possiamo (o non vogliamo) contattare il mittente per farci inviare l'email nel formato corretto possiamo:
  • Inoltrare l'email ad un nostro account gmail. Google ha implementato su Gmail il motore di decodifica per il formato TNEF pertanto l'allegato verrà decodificato e visualizzato in maniera corretta.
  • Utilizzare servizi di terze parti come l'ottimo sito web Winmaildat.com. Sulla pagina web sarà possibile fare l'upload del file Winmail.dat o ATT0001.dat (con dimensione non superiore ai 50MB) e, cliccando sul pulsante Start, visualizzare il suo contenuto. I file contenuti nell'allegato verranno estratti e sarà possibile scaricarli sul PC. Sono disponibili anche le app per dispositivi iPhone, iPad, Android, Mac e Windows
Winmaildat.com


domenica 9 luglio 2023

Windows Server 2022: Gruppi di lavoro. Peer Name Resolution Protocol (PNRP)

Il Peer Name Resolution Protocol (PNRP) è un protocollo peer-to-peer progettato da Microsoft e introdotto per la prima volta in Windows XP. Consente la pubblicazione e la risoluzione dei nomi nelle reti peer-to-peer e richiede IPv6.

Negli ambienti peer-to-peer, i peer usano sistemi di risoluzione dei nomi specifici per dedurre l'ubicazione di rete reciproca (indirizzi, protocolli e porte) dai nomi o altri tipi di identificatori. A differenza del DNS, il PNRP non richiede un server per essere implementato. Per la risoluzione dei nomi il PNRP utilizza UDP 3540.

PNRP utilizza un modello di distribuzione di dati basato su query per la risoluzione dei nomi. Ogni dispositivo partecipante alla rete PNRP mantiene una cache locale contenente informazioni sui nomi dei dispositivi disponibili. Quando un dispositivo richiede la risoluzione di un nome specifico, invia una query PNRP alla rete. La query viene propagata attraverso i dispositivi partecipanti fino a raggiungere il dispositivo con il nome richiesto. Una volta trovato il dispositivo, le informazioni di risoluzione dei nomi vengono restituite al dispositivo richiedente.

Il protocollo PNRP ha le proprietà seguenti:
  • È un protocollo distribuito e quasi del tutto senza server. I server sono necessari solo per il processo di bootstrap.
  • Protezione della pubblicazione dei nomi senza il coinvolgimento di terze parti. Diversamente dalla pubblicazione dei nomi DNS, la pubblicazione dei nomi PNRP è istantanea e non comporta costi finanziari. Eliminando la necessità di un server DNS centralizzato per la risoluzione dei nomi, si riduce la complessità e i punti di guasto potenziali nella rete.
  • PNRP implementa gli aggiornamenti in tempo reale e ciò impedisce la risoluzione di indirizzi non aggiornati. Tale caratteristica rendere il PNRP altamente scalabile in quanto il carico di risoluzione dei nomi viene distribuito tra i dispositivi partecipanti. L'aggiunta di nuovi dispositivi alla rete non richiede modifiche complesse alla configurazione.
  • La risoluzione dei nomi tramite PNRP si estende oltre i computer, consentendo anche la risoluzione dei nomi per i servizi.
  • Tolleranza ai guasti. PNRP è progettato per essere resiliente ai guasti di rete o ai dispositivi non disponibili.
  • Sicurezza. PNRP offre meccanismi di sicurezza integrati per proteggere la risoluzione dei nomi e prevenire attacchi malevoli. I dispositivi partecipanti possono autenticarsi e crittografare le comunicazioni per garantire l'integrità dei dati di risoluzione dei nomi.


lunedì 3 luglio 2023

Windows Server 2022: Gestione dei gruppi di lavoro

In qualità di amministratore di un gruppo di lavoro è necessario occuparsi di diverse attività di gestione tra cui, le più comuni, troviamo la reimpostazione delle password e la modifica del ruolo dell'utente. In quest'articolo verranno illustrati alcuni metodi per la gestione degli account utente e dei gruppi di lavoro.

Gestione computer

La console Gestione computer è un ottimo punto di partenza per la gestione degli utenti e dei gruppi locali. Ad esempio, dalla console è possibile modificare la password di un account utente e/o visualizzarne e modificarne le proprietà:
  • In Server Manager, cliccare sul menu Strumenti e selezionare Gestione computer.
    Server manager, Gestione computer
    FIG 1 - Server manager, Gestione computer

  • Fate doppio clic su Utenti e gruppi locali per espanderlo quindi selezionare Utenti per visualizzare l'elenco degli utenti.
    Gestione computer, Utenti
    FIG 2 - Gestione computer, Utenti

  • Se si desidera solo reimpostare la password, fare clic con il pulsante destro del mouse sull'account utente e scegliere Impostazione password.
    Impostazione password
    FIG 3 - Impostazione password

  • Una finestra di dialogo ci avvisa che alcune informazioni potrebbero non essere più accessibili a seguito reimpostazione della password (ad es. per le informazioni cifrate). Cliccare su Continua per proseguire.
    Avviso reimpostazione password
    FIG 4 - Avviso reimpostazione password

  • Digitare, due volte, la nuova password e confermare cliccando su OK.
    Nuova password
    FIG 5 - Nuova password

  • Per visualizzare le proprietà di un account utente, cliccarci su con il tasto destro del mouse e selezionare la voce Proprietà.
  • Nella finestra di dialogo Proprietà sono presenti diverse schede. Di seguito le vediamo in dettaglio.
    Generale
    In questa scheda è possibile obbligare l'utente a modificare la password all'accesso successivo, impedire che l'utente possa cambiare la password, disabilitare la scadenza della password e disabilitare l'account.
    Proprietà, Generale
    FIG 6 - Proprietà, Generale
    Membro di
    Consente di visualizzare e modificare l'appartenenza ai gruppi dell'utente.
    Proprietà, Membro di
    FIG 7 - Proprietà, Membro di

    Profilo
    Nella scheda Profilo è possibile impostare il percorso del profilo utente, script di logon e la home directory.
    Proprietà, Profilo
    FIG 8 - Proprietà, Profilo

    Ambiente
    Nella scheda Ambiente è possibile specificare un programma da avviare al logon dell'utente e impostare il comportamento desiderato per i dispositivi client.
    Proprietà, Ambiente
    FIG 9 - Proprietà, Ambiente

    Sessioni
    Consente di configurare il timeout e le impostazioni di riconnessione di Servizi Desktop remoto.
    Proprietà, Sessioni
    FIG 10 - Proprietà, Sessioni

    Controllo remoto
    Permette di abilitare/disabilitare il controllo remoto della sessione di un utente. Utile per connettersi alla macchina da remoto per la risoluzione di problemi.
    Proprietà, Controllo remoto
    FIG 11 - Proprietà, Controllo remoto


    Profilo Servizi Desktop remoto
    Simile alla scheda Profilo, ma si applica solo alle sessioni di Remote Desktop.
    Proprietà, Profilo Servizi Desktop Remoto
    FIG 12 - Proprietà, Profilo Servizi Desktop Remoto

    Chiamate in ingresso
    Controlla le opzioni di connessione alternative.
    Proprietà, Chiamate in ingresso
    FIG 13 - Proprietà, Chiamate in ingresso

Finestra Account

La finestra Account consente di eseguire le stesse funzioni di gestione degli utenti della console Gestione computer, ma con un'interfaccia più semplice.
Per accedere alla finestra Account:
  • Accedere alle Impostazioni di Windows tramite il menu Start oppure tramite la combinazione di tasti WIN+I.
  • Cliccare su Account.
    Impostazioni
    FIG 14 - Impostazioni

  • Selezionare Altri utenti. Da qui è possibile modificare il tipo di account, rimuovere o aggiungere un account locale.
    Account
    FIG 15 - Account


PowerShell

Per la gestione dei gruppi di lavoro è possibile utilizzare PowerShell. Alcune operazioni amministrative non possono essere eseguite tramite GUI ma esclusivamente tramite PowerShell.

Avviare PowerShell come amministratore:cliccare con il tasto destro del mouse su Start e selezionare Windows PowerShell (amministratore)

Tramite l'utilizzo del cmdlet Get-LocalUser è possibile interrogare il sistema per ottenere informazioni sull'account corrente specificato. Ad esempio, per visualizzare le impostazioni correnti dell'account Utente1, digitare quanto segue:
Get-LocalUser -Name "Utente1"

Per modificare la password dell'utente e possibile eseguire i seguenti comandi:
$Password = Read-Host -Prompt 'Inserisci Password' -AsSecureString
Get-LocalUser -Name "Utente1" | Set-LocalUser -Password $Password


In PowerShell le variabili sono rappresentate da stringhe di testo che iniziano con un segno di dollaro ($) e possono essere considerate come contenitori di oggetti. 
Per esempio, il primo comando (Read-Host -Prompt 'Inserisci Password' 
-AsSecureString) richiede la digitazione di una password che viene salvata nella variabile $Password come stringa sicura. Il cmdlet Get-LocalUser recupera le informazioni relative all'account utente Utente1 a cui, tramite il cmdlet Set-LocalUser, viene assegnata la password memorizzata in precedenza.
PowerShell, Nuova password account locale
FIG 16 - PowerShell, Nuova password account locale