Archivi categoria: Sistemi Operativi

Rinominare un dominio di Active Directory

Facebooktwittergoogle_plusredditlinkedin

È possibile rinominare un dominio Active Directory? La risposta è affermativa ma spesso sottovalutata. A seconda delle dimensioni del dominio da rinominare, questa azione si può rivelare un incubo anche per il sysadmin più esperto: nel caso di procedura errata il rischio di bloccare un utente o di dover rifare le operazioni di join di una macchina al dominio è elevatissimo.

Contestualmente esistono numerosissime applicazioni incompatibili con tali attività.

Nel caso in cui foste costretti ad intraprendere questa strada, Microsoft ha rilasciato una lunga checklist che, se compresa e verificata attentamente, facilita di molto l’attività in oggetto.

Punti critici

Prima di prendere in considerazione l’azione di cambio nome, è necessario sapere che:

  • Il livello funzionale della foresta deve essere almeno Windows Server 2003;
  • Exchange Server 2003 è l’unico che supporta questa procedura;
  • Dopo aver rinominato il dominio è verranno rinominati anche i nomi degli host joinati;
  • In caso di foresta con domini figli, a seguito del cambio di nome e quindi di posizione del domain controller padre, sarà necessario ricreare le relazioni di trust affinché possano parlarsi nuovamente;
  • Le zone DNS dovranno essere create manualmente per il nuovo dominio;
  • Ogni membro del dominio deve essere riavviato due volte a seguito dell’aggiornamento del domain controller;
  • Il suffisso DNS dei membri del dominio rinominato potrebbe non essere corretto per un certo periodo di tempo. Di solito questa configurazione DNS viene aggiornata automaticamente in caso di modifiche al dominio. Il periodo di tempo per il quale potrebbe non essere corretto è proporzionale alle dimensioni del dominio.

Applicazioni non compatibili

  • Microsoft Exchange 2000
  • Microsoft Exchange 2007
  • Microsoft Exchange 2010
  • Microsoft Internet Security and Acceleration (ISA) Server 2004
  • Microsoft Live Communications Server 2005
  • Microsoft Operations Manager 2005
  • Microsoft SharePoint Portal Server 2003
  • Microsoft Systems Management Server (SMS) 2003
  • Microsoft Office Communications Server 2007

Preparazione ed esecuzione

Come prima cosa, assicuriamoci che la feature Remote Server Administration Tools sia installata.

Figura 1: Server Manager – Roles and features

Dobbiamo rinominare il dominio da contoso.local a laboratorio.local.

Predisponiamo, nel DNS primario, la nuova zona per il dominio:

Figura 2: DNS Manager – Creazione nuova zona

Figura 3: DNS Manager – Wizard – Tipo di zona

Figura 4: DNS Manager – Wizard – Replication scope

Figura 5: DNS Manager – Wizard – Nome zona

Figura 6: DNS Manager – Wizard – Gestione aggiornamenti

Figura 7: DNS Manager – Wizard – Riepilogo

Rimuoviamo l’associazione DNS con il vecchio dominio

Figura 8: DNS Manager – Rimozione zona

Figura 9: DNS Manager – Rimozione zona

Successivamente, da una macchina a dominio utilizzando il domain admin, eseguiamo una shell elevata ed eseguiamo il comando

rendom /list

Figura 10: Command line – Download XML

Il risultato sarà la generazione di un file xml, nel path dove viene eseguito il comando, che dovremo modificare

Figura 11: Modifica delle configurazioni

Modifichiamo ii nomi DNS e NetBios con quelli desiderati, nel mio caso:

Figura 12: XML – Modifica delle configurazioni

Verifichiamo le informazioni del dominio con il comando

rendom /showforest

Figura 13: Command line – Verifica configurazioni

Effettuiamo l’upload con il comando

rendom /upload

Figura 14: Command line – Upload

Verifichiamo che il dominio sia pronto ad effettuare il processo di ridenominazione con il comando

rendom /prepare

Figura 15: Command line – Preparazione ridenominazione

Eseguiamo la procedura con il comando

rendom /execute

Figura 16: Command line – Esecuzione

A questo punto il domain controller viene riavviato in maniera automatica.

A seguito del riavvio verifichiamo che la procedura sia andata a buon fine

Figura 17: Server Manager – Verifica dominio

Diverse configurazioni relative al nuovo nome dovranno essere eseguite a mano:

Figura 18: System Properties – Hostname errato

Il Full computer name del DC deve essere cambiato a mano. Per effettuare la ridenominazione, eseguire il comando

netdom computername LabDC.contoso.local /add:LabDC.laboratorio.local

Figura 19: Command line – Modifica hostname

Seguito dal comando

netdom computername LabDC.contoso.local /makeprimary:LabDC.laboratorio.local

Figura 20: Command line – Modifica hostname

Riavviamo il server, successivamente verifichiamo che sia stato rinominato correttamente

Figura 21: System Properties – Verifica hostname

Apriamo la console delle GPO

Cliccando sul nuovo nome configurato notiamo che punta ancora al vecchio dominio

Figura 22: Group Policy Management – Errore

Per correggere questo problema utilizziamo il comando

gpfixup /olddns:contoso.local /newdns:laboratorio.local

Figura 23: Command line – Fix GPO

seguito da

gpfixup /oldnb:CONTOSO /newnb:LABORATORIO

Figura 24: Command line – Fix GPO

A questo punto è necessario riavviare almeno due
volte tutti i server joinati al vecchio dominio in modo che recepiscano i cambiamenti avvenuti con la ridenominazione. Riavviare due volte assicura che ogni computer recepisca il cambio di dominio e propaghi a tutte le applicazioni le modifiche necessarie.

Attenzione: Il riavvio deve essere effettuato dopo aver fatto login sulla macchina. In caso di Power off e successivo avvio la procedura non funzionerà.

Una volta assicurati che tutti i membri del dominio siano allineati, proseguiamo con i comandi

rendom /clean

Figura 25: Command line – Pulizia dei riferimenti al vecchio dominio

infine

rendom /end

Figura 26: Command line – Termine delle configurazioni

In questo modo verranno rimossi i riferimenti al vecchio dominio.

Verifichiamo che lato DNS siano stati creati i record correttamente

Figura 27: DNS Manager – Verifica zona

Exchange

In caso di ridenominazione di AD con versioni di Exchange non supportate, sarà necessario creare una nuova foresta, installare nuovamente Exchange ed effettuare una migrazione dei contenuti esistenti.

Maggiori informazioni possono essere recuperate qui.

Una possibile soluzione in caso di Exchange incompatibile è registrare un nuovo dominio e creare delle regole di redirect in modo che le email inviate al vecchio dominio vengano inoltrate automaticamente ai nuovi indirizzi. In questo modo si evitano impatti agli utenti i quali utilizzeranno esclusivamente il nuovo indirizzo di posta.

Conclusioni

Con la dovuta attenzione ed una corretta analisi è possibile rinominare un dominio AD. In alcune situazioni attività del genere sono preferibili al rifacimento dell’intera infrastruttura ma se affrontate nel modo sbagliato possono diventare un incubo.

Per fortuna Microsoft fornisce tutte le informazioni necessarie per affrontare questa attività in sicurezza.

Creare rapidamente laboratori di test per Windows 10, Windows Server 2016 e Windows Server 2019 utilizzando PowerShell

Facebooktwittergoogle_plusredditlinkedin

Da qualche mese è presente su GitHub un progetto Microsoft gratuito che permette con una serie di script PowerShell di configurare rapidamente dei laboratori di test basati su Hyper-V (io ho utilizzato la mia macchina con Windows 10 e con Client Hyper-V per i lab), partendo soltanto dalla ISO di Windows Server 2016 e di Windows 10. È anche possibile testare la versione Insider dei due sistemi operativi ed il prossimo Windows Server 2019.

Si possono creare decine di scenari diversi, alcuni anche complessi, frutto dell’esperienza dei Premier Field Engineer di Microsoft, che li usano proprio per realizzare delle demo per i clienti.

Ho trovato particolarmente facile la creazione dei laboratori con gli script messi a disposizione, visto che in fin dei conti dovevo solo fornire la ISO del sistema operativo da utilizzare e attendere la creazione del lab!

Gli script sono stati realizzati solo per creare alcuni scenari, molti di questi dedicati alle funzioni di Storage di Windows Server, ma offrono la possibilità di essere modificati e quindi possono anche essere adattati alle nostre esigenze.

Collegandosi alla pagina https://github.com/Microsoft/WSLab/tree/master/Scenarios troverete un elenco di scenari che attualmente sono stati sviluppati, ma ne vengono creati sempre di nuovi.

Se invece volete testare le nuove funzionalità della prossima versione di Windows 10 e di Windows Server 2019 potete collegarvi alla pagina https://github.com/Microsoft/WSLab/tree/master/Insider , dove c’è il file di configurazione per creare le macchine del lab utilizzando la ISO del programma Insider.

Nella pagina dei progetti sono anche presenti dei video esplicativi che vi possono aiutare nelle prime fasi, raggiungibili direttamente al link https://github.com/Microsoft/WSLab/#videos

Download dei prerequisiti

Per cominciare abbiamo bisogno di scaricare alcuni prerequisiti fondamentali:

Estraete gli script in una cartella del vostro computer oppure di una macchina virtuale su Azure che supporti la Nested Virtualization, cioè della famiglia Dv3 ed Ev3. Ho già avuto modo in passato di scrivere l’articolo Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3 che citava proprio questa nuova ed utilissima funzionalità.

Figura 1: Estrazione degli script utili per la creazione del laboratorio

Eseguite quindi il file 1_Prereq.ps1 con privilegi amministrativi e scaricate i prerequisiti richiesti, come mostrato in figura, che verranno poi salvati nella cartella Tools:

Figura 2: Download dei prerequisiti richiesti

Al termine del download dei prerequisiti, eseguite con privilegi amministrativi il file 2_CreateParentDisks.ps1. Vi verrà richiesta la ISO di Windows Server 2016 e vi verranno chiesti i file MSU che volete utilizzare per l’aggiornamento dell’immagine. Verranno creati diversi VHDX, con l’installazione di Windows Server 2016 Datacenter Full, Core e Nano. L’operazione dura diversi minuti e i dischi saranno salvati nella sottocartella ParentDisks, che verrà creata dallo script.

Figura 3: Richiesta dei file MSU per aggiornare l’installazione di Windows Server

Figura 4: Creazione dei dischi che verranno utilizzati dalle VM completata

Dopo la creazione dei VHDX, lo script procede in automatico e crea una macchina virtuale dentro la quale verranno installati i ruoli di Domain Controller e di DHCP utilizzando PowerShell Desired State Configuration (DSC). L’operazione dura diversi minuti, quindi siate pazienti 😊
La macchina virtuale creata verrà poi eliminata dalla console di Hyper-V e sarà riutilizzata nel momento in cui creerete il laboratorio secondo lo scenario che avete scelto.

Per ingannare l’attesa potete leggere l’articolo Introduzione a PowerShell Desired State Configuration o gli altri articoli che trattano dello stesso argomento https://www.ictpower.it/?s=PowerShell+Desired+State+Configuration

Figura 5: Installazione del Domain Controller tramite PowerShell Desired State Configuration

Figura 6: esecuzione dello script 2_ CreateParentDisks.ps1 terminata

Figura 7: Il Domain Controller che verrà utilizzato nei laboratori

Terminata l’esecuzione dello script 2_CreateParentDisks.ps1 vi verrà chiesto se volete eliminare i primi 2 script. Rispondente come preferite perché la vostra scelta non inficerà sulla creazione del laboratorio e sui successivi passaggi.

Se volete creare un’immagine di Windows 10 vi basterà lanciare lo script che troverete nella cartella Tools e scegliere la ISO di Windows 10 oppure di Windows 10 Insider, con gli eventuali Update che volete installare (file .MSU). Vi verrà chiesto quale versione di Windows volete installare, come mostrato in figura:

Figura 8: Creazione di un VHDX con Windows 10

Figura 9: Installazione del sistema operativo nel VHDX

Al termine della creazione sarà necessario spostare il VHDX dalla cartella Tools alla cartella ParentDisks.

Figura 10: Spostamento del VHDX di Windows 10 nella cartella ParentDisks

Creazione di un laboratorio utilizzando uno Scenario

Come già anticipato, diversi sono gli scenari che possono essere utilizzati per la creazione dei laboratori e sono tutti visibili al link https://github.com/Microsoft/WSLab/tree/master/Scenarios

In questo articolo utilizzerò lo Scenario S2D and Windows Admin Center, che creerà 6 macchine virtuali. Copiate la configurazione presente nella pagina nella sezione LabConfig and Prerequisites e incollatela nel file LabConfig.ps1, come mostrato in figura. Salvate il file LabConfig.ps1

Figura 11: Modifica della configurazione del file LabConfig.ps1 per adattarlo allo scenario scelto

A questo punto, per creare le macchine virtuali, lanciate lo script Deploy.ps1 (o 3_Deploy.ps1 se non lo avete rinominato). Verrà prima creata la macchina virtuale che ospita il Domain Controller e lo script aspetterà che il servizio di Active Directory sia online prima di procedere alla creazione delle altre VM, che verranno tutte automaticamente joinate al dominio (corp.contoso.com). Nell’attesa che il DC sia online potrete ricevere nello script dei messaggi di errore, ma non preoccupatevene perché questi errori sono “by design”.

Figura 12: Creazione delle VM del laboratorio utilizzando lo script Deploy.ps1

Figura 13: Creazione delle VM completata

Figura 14: Macchine virtuali create in Hyper-V

Le macchine virtuali sono state create. Accendetele e procedete con la configurazione dello scenario scelto. La creazione dell’infrastruttura sarà completata in meno di 5 minuti!

Da questo momento in poi le altre operazioni saranno fatte dall’interno delle VM e potete procedere con la configurazione delle funzionalità di Windows Server. A me interessa, con questo articolo, solo farvi vedere come creare facilmente l’infrastruttura di test e quanto sia facile passare da uno scenario all’altro, seguendo le indicazioni presenti su GitHub https://github.com/Microsoft/WSLab/tree/master/Scenarios

Rimozioni del laboratorio

Se volete rimuovere il laboratorio e tutte le macchine virtuali create, compreso i virtual switch, vi basterà lanciare lo script Cleanup.ps1. Le VM vengono individuate tramite il prefisso che avete deciso nel file LabConfig.ps1 e quindi non c’è possibilità che vengano rimosse altre macchine virtuali presenti nella vostra infrastruttura.

Figura 15: La rimozione del laboratorio viene completata in pochissimi secondi

Conclusioni

Davvero interessante creare dei laboratori di test ed eseguire delle configurazioni particolarmente complesse soltanto lanciando pochissimi script PowerShell e partendo dalla ISO di Windows. Utilissimo per le demo da fare ai nostri clienti, utilissimo per lo studio delle nuove funzionalità, utilissimo per risparmiare tantissimo tempo per i nostri test. Grazie Microsoft!

Introduzione ai Cluster Sets in Windows Server 2019

Facebooktwittergoogle_plusredditlinkedin

I Cluster Sets sono una funzionalità che sarà disponibile il prossimo autunno nella nuova versione di Windows che si chiamerà Windows Server 2019. Si tratta di una tecnologia pensata per poter gestire diversi cluster contemporaneamente, al fine di aumentare la scalabilità orizzontale e di permettere di avere un numero maggiore di nodi del cluster in un singolo Datacenter. Da molti anni si parla infatti di Software Defined Datacenter (SDDC), che altro non sono che una serie di tecnologie che permettono di ottenere prestazioni e configurazioni migliorate grazie al fatto di non dipendere dall’hardware che gestiscono.

Attualmente Windows Server 2019 è in Preview ed è possibile partecipare al programma Insider per poterlo provare in anteprima. Coloro che volessero cimentarsi possono collegarsi all’indirizzo https://insider.windows.com/en-us/for-business-getting-started-server/ e dopo essersi registrati possono scaricare una copia Insider di Windows Server 2019 e di Windows 10.

Dopo aver scaricato la versione più recente di Windows Server Insider Preview dal link https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver potete cominciare fin da subito a testarne le nuove funzionalità.

Io utilizzerò in questo articolo la Build 17709 di Windows Server 2019 che è stata rilasciata un paio di giorni fa e mi servirò, per configurare il mio laboratorio, di una serie di script presenti al link https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

È presente su GitHub un progetto Microsoft che consiste in una serie di script utili a configurare dei laboratori di test basati su Hyper-V (io ho utilizzato la mia macchina con Windows 10 e con Client Hyper-V per i lab), partendo soltanto dalla ISO di Windows Server e di Windows 10 e creando decine di scenari diversi, alcuni anche complessi (come quello che descriverò in questo articolo).

Scenario

Poiché Windows Server 2019 Cluster Sets servirà a gestire diversi cluster di Windows Server e ad amministrare alcune VM che gireranno nei cluster, è necessario creare un ambiente di laboratorio complesso. In questo ambiente verranno creati tre cluster (Member Clusters) configurati con Storage Spaces Direct (S2D), di cui ho già parlato nell’articolo Implementare Storage Spaces Direct in Windows Server 2016 con Microsoft Azure, in cui verranno distribuite delle macchine virtuali ed un cluster di gestione (Management Cluster) che si occuperà di gestire il Cluster Set Namespace SOFS, uno Scale-Out File Server dove verranno ospitate le VM.

Figura 1: Schema di funzionamento di Windows Server 2019 Cluster Sets

Uno degli obiettivi di Windows Server 2019 Cluster Sets è infatti quello di aumentare la scalabilità dei cluster che ospitano le VM e di fare in modo che cluster piccoli vengano raggruppato in una infrastruttura più grande. Le VM potranno essere spostate da un cluster ad un altro se è necessario fare della manutenzione o addirittura dismettere alcuni cluster, perché alla fine del ciclo di vita dell’hardware.

Figura 2: Le VM vengono posizionate su uno dei nomi dei diversi cluster e vengono memorizzate in uno Scale-Out File Server

Figura 3: Effettuare la manutenzione e la rimozione di un intero cluster diventa un’operazione molto semplice

Creazione del laboratorio di test

Dopo aver scaricato l’ultima build di Windows Server 2019 da https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver (la funzionalità Cluster Sets funziona solo con Windows Server Insider Preview build 17650 e successive), collegatevi alla pagina https://github.com/Microsoft/WSLab e scaricate gli script per la creazione del lab. Seguite dettagliatamente tutte le istruzioni riportate (ci sono anche dei video esplicativi).

Estraete gli script in una cartella e procuratevi il file di configurazione che sarà necessario per il laboratorio dei Cluster Sets dal link https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

Figura 4: File necessari alla realizzazione del laboratorio

Modificate il file Labconfig.ps1 con il contenuto dello scenario che volete realizzare, come mostrato in figura:

Figura 5: Modifica del file Labconfig.ps1 con le configurazioni dello scenario da realizzare

Eseguite quindi il file 1_Prereq.ps1 con privilegi amministrativi e scaricate i prerequisiti richiesti, come mostrato in figura:

Figura 6: Download dei prerequisiti

Al termine del download dei prerequisiti eseguite con privilegi amministrativi il file 2_CreateParentDisks.ps1. Vi verrà richiesta la ISO di Windows Server 2019 e verranno creati due VHDX, uno con l’installazione di Windows Server 2019 Datacenter Full ed uno con l’installazione di Windows 2019 Datacenter Core. L’operazione dura diversi minuti e i due dischi si troveranno nella sottocartella ParentDisks, che verrà creata dallo script.

Figura 7: Esecuzione dello script 2_CreateParentDisks.ps1

Figura 8: Creazione dei due VHDX completata

Dopo la creazione dei VHDX, in automatico verrà creata una macchina virtuale dentro la quale verranno installati i ruoli di Domain Controller e di DHCP. L’operazione dura diversi minuti.

Figura 9: Creazione e configurazione della macchina virtuale che farà da Domain Controller

Alla fine della configurazione del Domain Controller sarà presente una cartella con la macchina virtuale creata. Il Domain controller potrà essere riutilizzato tutte le volte che volete, se desiderate provare scenari di laboratorio diversi, disponibili al link https://github.com/Microsoft/WSLab/tree/master/Scenarios .

Figura 10: Esecuzione dello script 2_CreateParentDisks.ps1 completata

Figura 11: Creazione del Domain Controller completata

Creazione delle VM da utilizzare nel laboratorio per Cluster Sets

Terminati i prerequisiti è ora possibile passare alla creazione delle VM che saranno utilizzate nel laboratorio. Eseguite lo script Deploy.ps1, che utilizzerà le configurazioni presenti nel file Labconfig.ps1. Modificate il file Labconfig.ps1 con il contenuto dello scenario che volete realizzare. Trovate lo scenario per la creazione e configurazione dei Cluster Sets al link https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

Figura 12: Esecuzione dello Script Deploy.ps1

Dopo qualche minuto, saranno automaticamente create le 10 VM necessarie al nostro lab! Avviatele e aspettale il completamento della prima accensione. Le macchine sono state aggiunte al dominio corp.contoso.com, creato dal lab.

Figura 13: Esecuzione dello Script Deploy.ps1 completata

Figura 14: Creazione delle VM necessarie al lab di Windows Server 2019 Cluster Sets

Collegatevi ora alla macchina WSLabInsider17709-DC (il Domain Controller del laboratorio) con le credenziali che si trovano nel file Labconfig.ps1 (corp\LabAdmin con relativa password LS1setup!) e dall’interno della VM eseguite lo script PowerShell che si trova alla pagina https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

Lo script provvederà ad installare sulle VM tutte le funzionalità richieste. Procuratevi un VHDX che verrà utilizzato per creare le macchine virtuali che gireranno nel Cluster (sotto forma di Nested VMs). Io ho usato Windows 2016 Nano Server, che non richiede troppe risorse. Durante l’esecuzione dello script vi verrà chiesto di fornire il percorso dove avete copiato il VHDX da usare come immagine master per le Nested VM e poi proseguirà tutto in maniera automatica. Verranno così creati i quattro Cluster richiesti dal nostro scenario (3 Member Cluster ed un Management Cluster). Fantastico!

Figura 15: Creazione dei Cluster dall’interno della VM WSLabInsider17709-DC

La creazione dei 3 cluster (Cluster1, Cluster2 e Cluster3) richiede diversi minuti e qualche riavvio, soprattutto a causa dell’installazione di Hyper-V all’interno delle VM del lab. Il quarto cluster, quello di Management, verrà creato in seguito.

Se dal Domain Controller lanciate la console del Failover Cluster Manager potrete amministrare i tre Cluster creati. Un avviso però vi consiglia di utilizzare Windows Admin Center, la console di management gratuita che è stata rilasciata qualche mese fa e di cui abbiamo parlato nell’articolo Windows Server 2019 e Windows Admin Center: le novità previste per il prossimo autunno

Figura 16: Console di Failover Cluster Manager e Windows Admin Center

Figura 17: Cluster creati dallo script di configurazione

Figura 18: Macchine virtuali creati nei nodi del Cluster

Potete scaricare Windows Admin Center dal link https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/understand/windows-admin-center. Io ho scaricato la versione Windows Admin Center Preview 1806, ma ho dovuto installarla su un’altra macchina perché non è possibile installarla su un Domain Controller.

Figura 19: Gestione del cluster effettuata dal Windows Admin Center

Creazione del Management Cluster

Il Management Cluster in un Cluster Set si occupa di rendere altamente disponibili le funzionalità che servono a gestire l’intero Cluster Set e il referral SOFS per il Cluster Storage Namespace. In più è completamente distinto dai diversi Member Server che si occupano di far girare le macchine virtuali. Per creare il Management Cluster (che chiameremo MgmtCluster) nel nostro laboratorio è sufficiente lanciare dal Domain Controller i seguenti comandi PowerShell:

$ClusterName=“MgmtCluster”
$ClusterIP=“10.0.0.220”
$ClusterNodes=1..3% {“Mgmt$_}
Invoke-Command -ComputerName $ClusterNodes -ScriptBlock {
Install-WindowsFeature -Name “Failover-Clustering”
}
New-Cluster -Name $ClusterName -Node $ClusterNodes -StaticAddress $ClusterIP

Successivamente eseguite il comando New-ClusterSet -name “MyClusterSet” -NamespaceRoot “MC-SOFS” -CimSession “MgmtCluster” -StaticAddress “10.0.0.221” per creare il Cluster Set Master su “MgmtCluster”.

Il Cluster Set Master si occuperà di coordinare le comunicazioni tra i diversi Member Cluster ed è anch’esso un ruolo altamente disponibile. In più verrà creato il Root Namespace chiamato MC-SOFS che sarà poi utilizzato per puntare alle condivisioni di rete SOFS offerte dai diversi nodi dei Member Cluster.

Figura 20: Management Cluster e relativi ruoli installati

A questo punto è necessario aggiungere i Member Cluster da gestire (Cluster1, Cluster2 e Cluster3) utilizzando il comando PowerShell

Add-ClusterSetMember -ClusterName Cluster1 -CimSession MyClusterSet -InfraSOFSName CL1-SOFS
Add-ClusterSetMember -ClusterName Cluster2 -CimSession MyClusterSet -InfraSOFSName CL2-SOFS
Add-ClusterSetMember -ClusterName Cluster3 -CimSession MyClusterSet -InfraSOFSName CL3-SOFS

Figura 21: Ruoli aggiunti al Cluster1 relativi al Cluster Set

In questo modo le condivisioni di rete sono tutte visibili dal percorso \\MC-SOFS

Figura 22: Tutte le condivisioni di rete offerte dal Member Cluster sono visibili dal percorso \\MC-SOFS

Spostamento delle VM nel Root Namespace

Adesso che abbiamo creato il Cluster Set è necessario spostare le VM che erano già ospitate dai Member Cluster, utilizzando la Storage Live Migration. Potete spostare tutte le VM con un semplice script ma nel nostro laboratorio la partenza e la destinazione dei dischi delle VM coincidono e per questo motivo utilizzeremo un workaround che semplicemente spegnerà le macchine, le rimuoverà mantenendo le configurazioni, cambierà il percorso dei dischi e ri-registrerà le VM nel Cluster.

$ClusterSet=“MyClusterSet”
$ClusterSetSOFS=“\\MC-SOFS”

#Grab all VMs from all nodes
$VMs=Get-VM -CimSession (Get-ClusterSetNode -CimSession $ClusterSet).Name

<# does not work
#perform storage migration to \\MC-SOFS
foreach ($VM in $VMs){
$NewPath=($vm.path).Replace(“c:\ClusterStorage”,$ClusterSetSOFS)
$VM | Move-VMStorage -DestinationStoragePath $NewPath
}
#>

#remove VMs and import again, but from \\MC-SOFS
#Shut down VMs

$VMs Stop-VM

#Remove VMs from cluster resources

Foreach ($VM in $VMs){
Remove-ClusterGroup -Cluster $VM.ComputerName -Name $VM.name -RemoveResources -Force
}

#remove VMs and keep VM config

Foreach ($VM in $VMs){
invoke-command -computername $VM.ComputerName -scriptblock {
$path=$using:VM.Path
Copy-Item -Path $path\Virtual Machines” -Destination $path\Virtual Machines Bak” -recurse
Get-VM -Id $Using:VM.id Remove-VM -force
Copy-Item -Path $path\Virtual Machines Bak\*” -Destination $path\Virtual Machines” -recurse
Remove-Item -Path $path\Virtual Machines Bak” -recurse
}
}

#Import again, but replace path to \\MC-SOFS

Invoke-Command -ComputerName (get-clustersetmember -CimSession $ClusterSet).ClusterName -ScriptBlock{
get-childitem c:\ClusterStorage -Recurse Where-Object {($_.extension -eq ‘.vmcx’ -and $_.directory -like ‘*Virtual Machines*’) -or ($_.extension -eq ‘.xml’ -and $_.directory -like ‘*Virtual Machines*’)} ForEach-Object -Process {
$Path=$_.FullName.Replace(“C:\ClusterStorage”,$using:ClusterSetSOFS)
Import-VM -Path $Path
}
}

#Add VMs as Highly available and Start

$ClusterSetNodes=Get-ClusterSetNode -CimSession $ClusterSet
foreach ($ClusterSetNode in $ClusterSetNodes){
$VMs=Get-VM -CimSession $ClusterSetNode.Name
$VMs.Name ForEach-Object {Add-ClusterVirtualMachineRole -VMName $_ -Cluster $ClusterSetNode.Member}
$VMs 
Start-VM
}

Figura 23: Posizione del disco PRIMA della Storage Migration

Figura 24: Posizione del disco DOPO la Storage Migration

Abilitazione della Kerberos Authentication per permettere la Live Migration

Per far in modo tale che le VM possano essere spostate accese da un nodo ad un altro è necessario abilitare la Kerberos Authentication su tutti i nodi dei Member Cluster, come ben documentato dall’articolo Set up hosts for live migration without Failover Clustering. È possibile farlo in maniera molto semplice lanciando lo script PowerShell:



#configure kerberos for shared-nothing live migration between all clusters
# https://technet.microsoft.com/en-us/windows-server-docs/compute/hyper-v/deploy/set-up-hosts-for-live-migration-without-failover-clustering

$ClusterSet=“MyClusterSet”
$Clusters=(get-clustersetmember -CimSession $ClusterSet).ClusterName
$Nodes=Get-ClusterSetNode -CimSession $ClusterSet
foreach ($Cluster in $Clusters){
$SourceNodes=($nodes where member -eq $Cluster).Name
$DestinationNodes=($nodes where member -ne $Cluster).Name

Foreach ($DestinationNode in $DestinationNodes){
$HostName $DestinationNode

$HostFQDN = (Resolve-DnsName $HostName).name Select-Object -First 1
Foreach ($SourceNode in $SourceNodes){
Get-ADComputer $SourceNode Set-ADObject -Add @{“msDS-AllowedToDelegateTo”=“Microsoft Virtual System Migration Service/$HostFQDN, “Microsoft Virtual System Migration Service/$HostName, “cifs/$HostFQDN, “cifs/$HostName}
}
}
}

#Switch to any authentication protocol https://blogs.technet.microsoft.com/virtualization/2017/02/01/live-migration-via-constrained-delegation-with-kerberos-in-windows-server-2016/

Foreach ($Node in $Nodes){
$GUID=(Get-ADComputer $Node.Name).ObjectGUID
$comp=Get-ADObject -identity $Guid -Properties “userAccountControl”

#Flip the ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION bit using powershell bitwise OR operation (-bor)

$Comp.userAccountControl = $Comp.userAccountControl -bor 16777216
Set-ADObject -Instance $Comp
}

#Switch to kerberos authentication for live migration

Set-VMHost -CimSession $Nodes.Name -VirtualMachineMigrationAuthenticationType Kerberos

Figura 25: Abilitazione della Kerberos Trusted Delegation su tutti i nodi dei Member Cluster

Come ultima operazione aggiungiamo l’account macchina di MyClusterSet al gruppo amministratori locali dei singoli nodi dei Member Cluster con il comando PowerShell

$ClusterSet=“MyClusterSet”
$MgmtClusterterName=(Get-ClusterSet -CimSession $ClusterSet).ClusterName
Invoke-Command -ComputerName (Get-ClusterSetNode -CimSession $ClusterSet).Name -ScriptBlock {
Add-LocalGroupMember -Group Administrators -Member $using:MgmtClusterterName$”
}

Figura 26: L’account macchina di MyClusterSet è stato aggiunto al gruppo amministratori locali dei singoli nodi dei Member Cluster

Registrazione delle VM al Cluster Set

Adesso è possibile registrare tutte le VM all’interno del Cluster Set in modo tale che possano essere gestite centralmente, eseguendo il comando PowerShell

#Register all existing VMs

$ClusterSet=“MyClusterSet”
Get-ClusterSetMember -CimSession $ClusterSet Register-ClusterSetVM -RegisterAll

Figura 27: registrazione delle VM nel Cluster Set completata

Conclusioni

I Cluster Sets permettono di scalare orizzontalmente il numero di nodi gestibili da un singolo cluster e permettono ai Datacenter di poter utilizzare migliaia di nodi, riducendo di fatto i punti di rottura e portando ad un nuovo livello il Software Defined Datacenter (SDDC), ottimizzando le risorse hardware e semplificandone di molto la gestione.

Come funziona la risoluzione DNS nei sistemi operativi Windows

Facebooktwittergoogle_plusredditlinkedin

Tutti sappiamo quanto sia importante la risoluzione dei nomi DNS. Il processo di tradurre un indirizzo IP assegnato ad un computer, difficile da ricordare, in un nome che gli utenti possano leggere e capire semplifica di molto l’utilizzo delle risorse di rete. Il DNS ci permette, come una rubrica telefonica, di recuperare gli indirizzi dei server web, dei file server e di tutti i dispositivi presenti nella rete aziendale o in Internet in maniera davvero semplice.

Abbiamo già parlato in altri articoli delle novità del servizio DNS in Windows Server 2016 oppure delle funzionalità avanzate relative al DNSSEC, ma in questo articolo mi voglio soffermare sul funzionamento del DNS LATO CLIENT e sulle configurazioni da fare sulle macchine. Durante i corsi che tengo mi è capitato spesso infatti di trovare gente, anche con una certa “anzianità di servizio”, che aveva difficoltà a comprendere bene come funzionasse la risoluzione lato client.

Risoluzione dei nomi DNS per Windows Server e Windows Client

Il set di protocolli TCP/IP identifica i computer sorgente e destinazione tramite i propri indirizzo IP. Tuttavia gli utenti trovano più facile ricordare i nomi piuttosto che i numeri e per questo motivo gli amministratori assegnano un nome ai computer. I nomi assegnati agli indirizzi IP vengono poi scritti nel DNS. Il formato tipico di questi nomi è dc1.demo.com, dove DC1 è il nome del computer (hostname) e DEMO.COM è il nome del dominio. L’unione dell’hostname e del dominio formano il Fully Qualified Domain Name (FQDN).

Figura 1: Fully Qualified Domain Name (FQDN)

Un hostname può essere lungo fino a 255 caratteri e può contenere lettere, numeri, punti e trattini.

Come i Client risolvono i nomi DNS interni

Tutti i sistemi operativi Windows utilizzano diversi metodi per risolvere i nomi dei computer: DNS, WINS e NETBIOS. WINS è un database centralizzato che serve a risolvere i nomi NETBIOS. I nomi NETBIOS sono fondamentalmente solo i nomi host, senza il suffisso DNS, limitati ai primi 15 caratteri del nome macchina.

Quando un’applicazione richiede di raggiungere un certo hostname, il TCP/IP utilizza la DNS Resolver Cache per cercare di risolvere il nome host. Se NETBIOS over TCP/IP è abilitato nella configurazione della scheda di rete, il protocollo TCP/IP utilizza la risoluzione NETBIOS per risolvere i nomi.

Figura 2: Configurazione del NETBIOS attiva in maniera predefinita in Windows

I sistemi operativi Windows risolvono gli hostname utilizzando le seguenti operazioni in questo specifico ordine:

  1. Controllano se l’hostname cercato è lo stesso del pc da cui facciamo la richiesta (loopback)
  2. Controllano se il nome sia già stato risolto verificando la presenza nella cache locale del computer / Controllano se ci sono dei nomi computer scritti nel file HOSTS
  3. Inviano una richiesta al server DNS che è configurato nella scheda di rete
  4. Utilizzano, se è abilitato, il protocollo Link-Local Multicast Name Resolution (LLMNR)
  5. Convertono il nome host in un nome NETBIOS e controllano la presenza del nome nella cache NETBIOS locale del computer
  6. Inviano una richiesta al server WINS che è configurato nella scheda di rete
  7. Mandano una richiesta in BROADCAST nella stessa sottorete dove si trova
  8. Controllano se ci sono dei nomi computer scritti nel file LMHOSTS

Figura 3: Risoluzione dei nomi da parte di un Client Windows

Pertanto, se sto cercando di risolvere il nome fileserver1 (NETBIOS) la risoluzione avverrà in maniera diversa se cerco di risolvere il nome fileserver1.demo.com (FQDN).

Risoluzione DNS di nomi pubblici

Se cerchiamo di risolvere nomi DNS che non siano presenti nel nostro server DNS interno, come ad esempio i nomi Internet, la risoluzione DNS si comporta in modo completamente diverso. In questo caso, poiché il server DNS interno della nostra rete non ospita lo spazio di nomi cercato si dice che non è autoritativo per la zona DNS. Deve quindi rivolgersi ad un server DNS esterno per la risoluzione dei nomi, comportandosi quindi come un client.

Se il server DNS interno
non è autoritativo allora la risoluzione dei nomi viene effettuata dal server in uno di questi 3 modi:

  • Controlla nella propria cache di aver già risolto il nome cercato
  • Inoltra la richiesta ad un server esterno che abbiamo configurato (Forwarder). In questo caso effettua una query ricorsiva
  • Usa i Root Hints per conoscere chi sono i server autoritativi per la zona da cercare. In questo caso effettua una query iterativa

Il DNS è organizzato in maniera gerarchica e alla radice c’è la zona (.) (punto), chiamata Root. I Root Hints sono i 13 server mondiali che ospitano il livello gerarchico delle zone Internet, cioè la radice.

Figura 4: I Root Hints contengono gli indirizzi IP dei DNS Root Server

NOTA: Sia che il server DNS interno sia configurato con o senza Forwarder, la risoluzione dei nomi DNS pubblici avviene sempre e comunque tramite i Root Hints, che sono gli unici a sapere quali sono i server autoritativi per la zona cercata (ad esempio ictpower.it).

Ci sarebbe davvero molto da dire sul funzionamento dei server DNS e sulle loro configurazioni. Consiglio quindi vivamente di partire dal documento DNS Physical Structure per cominciare ad approfondire l’argomento e successivamente di leggere il documento DNS Processes and Interactions

Figura 5: Query DNS ricorsiva e iterative effettuate dal server DNS interno

Figura 6: Query DNS ricorsiva e iterative effettuate dal server DNS interno configurato con un Forwarder

Come configurare correttamente la scheda di rete per la risoluzione DNS

Per configurare correttamente la scheda di rete per la risoluzione DNS bisogna inserire i parametri dei server DNS, che variano a seconda che la macchina stia lavorando in dominio o in workgroup. Supponendo che la macchina sia stata aggiunta al dominio, dovremo inserire come server DNS l’indirizzo (o meglio gli indirizzi) dei domain controller aziendali. I Domain controller aziendali saranno capaci di risolvere sia i nomi interni sia i nomi pubblici. Se abbiamo due server con indirizzi 192.168.11.10 e 192.168.11.11 la configurazione corretta sarà:

Figura 7: Configurazione di una scheda di rete di una macchina in DOMINIO con gli IP dei Domain Controller, che fanno anche da DNS Server

Se la macchina è invece in workgroup, non ci saranno domain controller né server DNS interni e quindi sarà necessario configurare la scheda di rete con un indirizzo IP di un server DNS pubblico, come nell’esempio mostrato nella figura sotto:

Figura 8: Configurazione di una scheda di rete di una macchina in WORKGROUP con IP di DNS pubblici

Quali sono gli errori più comuni che vengono commessi?

Uno degli errori più comuni che vengono commessi è mischiare tra di loro indirizzi IP di DNS interni (domain controller) e di DNS pubblici. Per fare un esempio, una delle configurazioni che vedo più spesso è quella mostrata nella figura sotto:

Figura 9: Configurazione DNS errata

Quando viene utilizzato il DNS alternativo?

Quando il server DNS Preferito non risponde (è SPENTO o NON RAGGIUNGIBILE, non quando non sa rispondere ad una query DNS). Quindi la giustificazione che mi viene data per questo tipo di configurazione è che se sto riavviando il Domain Controller (molto spesso nelle piccole aziende ce n’è solo uno!) o il Domain controller non è raggiungibile, viene utilizzato il DNS secondario, che è capace di risolvere i nomi Internet. Così gli utenti navigano e non mi creano problemi!

Per capire dopo quanto tempo viene utilizzato il DNS server secondario vi spiego in che modo avviene una query DNS:

  1. Se il server DNS primario è disponibile la query viene immediatamente risolta
  2. Se il DNS primario NON è disponibile, la query viene effettuata sul server DNS alternativo dopo un time-out di circa 1 secondo

La situazione si complica quando avete diverse schede di rete sulla stessa macchina. Un ottimo articolo che spiega l’ordine di ricerca dei DNS alternativi ed il time-out che ne consegue è DNS Clients and Timeouts (part 2)

Quando viene utilizzato nuovamente il server DNS preferito?

È importante saperlo perché nell’esempio sopra il Domain Controller è l’unico in grado di risolvere i nomi interni del dominio e assicura il corretto funzionamento di servizi che dipendono da Active Directory. Quindi se non posso contattare il domain controller e continuo ad utilizzare il DNS pubblico potrei non essere in grado di poter utilizzare tutti i servizi interni del mio dominio.

La risposta è che di default ci vogliono 15 minuti. Passati i 15 minuti il server DNS alternativo viene cancellato dalla DNS Cache e la successiva query potrà ricominciare a contattare il server DNS preferito.

È però possibile modificare questo time-out agendo sulla chiave di registro Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters e modificando il valore REG_DWORD chiamato ServerPriorityTimeLimit. Se impostate il valore a 0, le priorità nella scelta dei server vengono cancellate dalla cache del DNS Client e quindi l’ordine di utilizzo dei server DNS viene controllato ogni volta che effettuate una nuova query.

Figura 10: modifica della chiave di registro per il ServerPriorityTimeLimit

Quindi, se proprio volete mettere un DNS server esterno come DNS secondario, tenete ben presente il time-out di 15 minuti ed eventualmente modificate la chiave di registro indicata.

Conclusioni

Conoscere il funzionamento della risoluzione DNS e delle configurazioni da effettuare sulla scheda di rete ci permette di evitare grossolani errori e ci aiuta nel troubleshooting della risoluzione dei nomi, che è uno dei più importanti concetti da capire per la gestione di un’infrastruttura di rete.

Implementare Azure AD password protection per Windows Server Active Directory

Facebooktwittergoogle_plusredditlinkedin

Una delle problematiche relative alla sicurezza più evidenti nelle aziende è l’utilizzo di password troppo facili da parte degli utenti. Problemi legati alla memorizzazione, alla troppa lunghezza della password imposta a livello di dominio e alla complessità richiesta fanno si che gli utenti spesso si servano di password facilmente individuabili.

Abbiamo già avuto modo di parlare della modifica delle password policies In Active Directory nell’articolo Active Directory Password Policies: facciamo un po’ di chiarezza, soprattutto perché le aziende si sono dovute adeguare all’entrata in vigore delle sanzioni previste dal GDPR in merito alla sicurezza dei sistemi.

In questo articolo ci occuperemo invece di implementare Azure AD password protection per Windows Server Active Directory, sfruttando una funzionalità del Cloud per proteggere i nostri sistemi dall’utilizzo di password troppo semplici. Andremo cioè a migliorare le password policies previste on-premises sfruttando una funzionalità che è già presente in Azure AD, che ci permetterà di effettuare un controllo delle password sia on-premises che nel Cloud.

Azure AD password protection

Azure AD password protection è una funzionalità disponibile in Azure se avete sottoscritto il piano Azure AD P1 Premium, che vi permette di evitare che i vostri utenti utilizzino password prese da una lista di più di 500 password comunemente utilizzate ed oltre un milione di variazioni delle stesse password che utilizzano la sostituzione di alcuni caratteri. Un esempio eclatante è Pa$$w0rd1!, in cui la parola “password” viene resa più “difficile” da indovinare utilizzando maiuscole, minuscole, caratteri speciali e numeri. In realtà molte di queste password sono facilmente individuabili.

Quindi Azure AD password protection non è altro che un sistema che “banna” le password nel momento in cui gli utenti cercano di cambiarla (perché l’hanno dimenticata oppure perché è scaduta) e può essere anche personalizzato (immaginate quante persone in questo momento stanno utilizzando la password “Luglio2018!” ) 😊

Una volta che avete acquistato il piano Azure AD Premium 1 potete personalizzare la lista delle password “bannate” semplicemente andando in Azure Active Directory à Authentication Methods (attualmente ancora in Preview) dal portale di Azure, come mostrato in figura:

Figura 1: Personalizzazione delle configurazioni di Azure AD Password Protection

Dal portale sarà possibile inserire una lista di password che volete “bannare” e come si può vedere è abilitata di default la voce Enable password protection on Windows Server Active Directory. In maniera predefinita la funzionalità è in modalità Audit, per permettervi di testarla. Una volta terminate tutte le configurazioni potrete metterla in modalità Enforced ed iniziare ad utilizzarla.

Nella stessa finestra è anche possibile personalizzare Smart Lockout. Smart Lockout è una funzionalità abilitata di default per tutti gli utenti di Azure AD (è gratuita e non richiede un piano aggiuntivo) che utilizza l’intelligenza artificiale per bloccare tutti i tentativi di accesso malevoli ai nostri account di Azure AD. Ci sono circa 10 milioni di tentativi giornalieri registrati da Microsoft da parte di malintenzionati che usano combinazioni di username e password per indovinare l’accesso degli utenti. Con Smart Lockout è possibile riconoscere se l’accesso proviene da un utente valido (che magari in quel momento non ricorda la password) oppure proviene da una sorgete sconosciuta (ad esempio un indirizzo IP che generalmente non utilizziamo per connetterci).

Utilizzare Azure AD password protection in Windows Server Active Directory

È possibile utilizzare la funzionalità appena descritta anche per proteggere gli utenti di dominio dall’utilizzo di password troppo facili. Per poter controllare quindi che anche on-premises non vengano utilizzate le password “bannate” o le password troppo “riconoscibili” è necessario installare on-premises due componenti software diversi:

  1. Azure AD password protection proxy service, che serve ad inoltrare le richieste dal domain controller ad Azure AD
  2. Azure AD password protection DC agent service, che riceve le richieste di validazione delle password, le processa utilizzando le password policy scaricate localmente (ogni ora) da Azure AD password protection e accetta/rifiuta la password scelta dall’utente

Figura 2: Processo di validazione delle password utilizzando la password policy scaricata da Azure AD Password Protection

Nessuna connessione Internet è richiesta dai Domain Controller. L’unica macchina che si connetterà ad Internet sarà quella in cui avete installato Azure AD password protection proxy service. Non verranno apportate modifiche allo Schema di Active Directory né tantomeno è richiesto un livello minimo funzionale di foresta e/o di dominio per l’utilizzo di Azure AD password protection con Windows Server Active Directory. Non verrà creato nessun utente locale.

Installazione del software

Al link Azure AD password protection for Windows Server Active Directory (preview) troverete i due installer per i due componenti software già citati. Installate il componente AzureADPasswordProtectionProxy.msi su una macchina joinata al dominio locale di Active Directory, che abbia l’accesso ad Internet, mentre installate il componente AzureADPasswordDCAgent.msi su tutti i domain controller della vostra infrastruttura. Attenzione perché il componente AzureADPasswordDCAgent richiede il riavvio del domain controller.

Figura 3: Download dei due software richiesti per l’abilitazione di Azure AD password protection for Windows Server Active Directory

Procedete all’installazione, su tutti i Domain Controller della vostra infrastruttura di Active Directory on-premises, dell’ Azure AD Password Protection DC Agent

Figura 4: Azure AD password protection DC Agent – License Agreement

Figura 5: Azure AD password protection DC Agent – Installazione del servizio

Figura 6: Azure AD password protection DC Agent – Installazione completata

Figura 7: Azure AD password protection DC Agent – Riavvio del domain controller necessario

Procedete all’installazione, in una macchina joinata al dominio e connessa ad Internet, dell’ Azure AD Password Protection proxy

Figura 8: Azure AD password protection proxy – License Agreement

Figura 9: Azure AD password protection proxy – Avvio servizi

Figura 10: Azure AD password protection proxy – Installazione completata

Terminata la procedura di installazione dei due software è necessario registrare la foresta di Active Directory ed il Password Protection Proxy con Azure AD. Posizionatevi sul server dovete avete installato il Password Protection Proxy, lanciate un prompt di PowerShell con le credenziali di Domain Admin e lanciate le due cmdlet Register-AzureADPasswordProtectionForest e Register-AzureADPasswordProtectionProxy . Autenticatevi con i permessi di un Global Admininistrator della vostra istanza di Azure AD, ma accertatevi che non usi la Multi-Factor Authentication perché nella Preview non può essere utilizzata (MFA potrà essere utilizzata nella versione finale).

Figura 11: Registrazione della foresta e del proxy di Azure AD Password protection

Verifica della funzionalità di Azure AD Password protection

Se volete forzare l’utilizzo di Azure AD Password protection e quindi impedire l’uso di password comuni o che avete deciso di “bannare” è necessario mettere a Enforced la Password protection for Windows Server Active Directory.

Figura 12: Modalità Enforced per la Password protection for Windows Server Active Directory

Se un amministratore tenta di resettare la password dell’utente ed utilizza una password “bannata” oppure non rispetta i prerequisiti dettati dalla password policy di Azure AD Passsword protection riceverà un errore come quello in figura:

Figura 13: Reset della password utente da parte dell’amministratore

Se un utente tenta, al momento di cambiare la password, di immettere una password non consentita riceverà un messaggio di errore tipico in cui lo si avvisa che non sta rispettando i requisiti di cronologia, di lunghezza o di complessità della password

Figura 14: All’utente viene chiesto di cambiare la password

Figura 15: Inserimento di una password non consentita dalla policy di Aure AD Password Protection

Figura 16: Messaggio di errore ricevuto dall’utente che ha cercato di usare una password “bannata”

Nel Domain Controller on-premises utilizzato per l’autenticazione sarà anche possibile verificare che la richiesta di cambiamento password dell’utente è stata rifiutata perché non soddisfa i requisiti imposti dalla Azure AD Password Policy (che come abbiamo detto viene scaricata ogni ora) andando nel registro Eventi nel ramo Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin.

Figura 17: Evento di errore relativo al rifiuto del cambiamento della password dell’utente perché non soddisfa la Azure password policy

Con la cmdlet di PowerShell Get-AzureADPasswordProtectionSummaryReport è anche possibile ottenere un report minimale

Figura 18: Reportistica tramite PowerShell

Per ulteriori informazioni sul logging e sul troubleshooting vi invito a leggere l’articolo Azure AD password protection monitoring, reporting, and troubleshooting

Conclusioni

Azure AD password protection per Windows Server Active Directory ci aiuta, grazie al Cloud, ad evitare che gli utenti utilizzino delle password troppo semplici o, anche se complesse, troppo comuni e facilmente indovinabili. Sicuramente una funzionalità utilissima per combattere le password prevedibili, oppure per impedire i Password Spray Attack, grazie ad un copioso database (abbiamo parlato di circa 500 password ed 1 milione di varianti) e all’Intelligenza Artificiale che il Cloud ci mette a disposizione.

Configurare Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Facebooktwittergoogle_plusredditlinkedin

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio.

Tra le problematiche più note, infatti, si riscontra quella dovuta al blocco dell’account in Active Directory dopo che qualcuno ha tentato di indovinare la password e l’ha sbagliata diverse volte.

Figura 1: Numero massimo di tentativi di accesso falliti prima che l’account venga bloccato

Figura 2: Account bloccato dopo 10 tentativi di accesso falliti

Come avrete modo di leggere nell’articolo Azure AD and ADFS best practices: Defending against password spray attacks, utilizzare ADFS 2016 ed Azure MFA con sistema principale di autenticazione permette di ottenere un sistema passwordless, basato esclusivamente su un OTP.

Ho già avuto modo di farvi vedere come Configurare Active Directory Federation Services in Windows Server 2016 e come Configurare AD FS 2016 ed Office 365 con Azure AD Connect nei miei precedenti articoli. Oggi vi voglio mostrare quanto sia facile integrare ADFS 2016 con Azure MFA.

Registrazione degli utenti in Azure MFA

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup), ma gli utenti devono essersi già registrati e aver attivato l’MFA. Per farlo possono collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione, in cui possono inserire il numero di telefono a cui ricevere messaggi SMS, le chiamate oppure posso collegare l’App per il cellulare (Azure Authenticator)

Figura 3: Configurazione della Multi-factor authentication

Azure MFA come autenticazione principale

Se si utilizza Azure MFA come Primary Authentication in AD FS si può evitare di inserire la password durante il login ad Azure AD, ad Office365 oppure ad altre applicazioni SaaS ed utilizzare un codice temporaneo OTP. Se stiamo utilizzando un pc sconosciuto per autenticarci allora è il caso di prendere il massimo delle precauzioni (potrebbe esserci un keylogger sulla macchina oppure qualcuno potrebbe vedere la password che digitiamo).

Prerequisiti

Per poter connettere ADFS a Azure MFA dovete accertarvi di avere i seguenti prerequisiti:

  • Installazione on-premises di un’infrastruttura AD FS basa su Windows Server 2016
  • Federazione dell’infrastruttura con Azure AD
  • Aver installato il modulo PowerShell per Azure AD (Msoline)
  • Permessi di Global Administrator nella sottoscrizione di Azure AD
  • Credenziali di Enterprise Administrator per configurare la Farm ADFS per Azure MFA

Configurazioni dei server ADFS

Come prima operazione creeremo un certificato digitale da utilizzare per MFA. Il certificato dovrà essere creato su TUTTI i server AD FS della vostra Farm. Per creare un certificato relativo alla nostra Azure AD useremo la cmdlet di PowerShell

$certbase64=New-AdfsAzureMfaTenantCertificate -TenantIdnicolaferrini.onmicrosoft.com

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD

Figura 4: Creazione del certificato da utilizzare per Azure MFA

Il certificato verrà salvato nello store Local Computer

Figura 5: Certificato da utilizzare per Azure MFA creato

Connettetevi al vostro tenant di Azure AD con il comando Connect-MsolService e successivamente aggiungete le credenziali al Service Principal Name (SPN) del client di Azure Multi-Factor Auth utilizzando il comando PowerShell

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64

981f26a1-7f43-403b-a875-f8b09b8cd720 è il guid dell’ Azure Multi-Factor Auth Client

Figura 6: Aggiunta delle credenziali al Service Principal Name (SPN) del client di Azure Multi-factor Auth

Configurazione della Farm AD FS

Dopo aver completato i passaggi precedenti in ogni server della Farm ADFS, è necessario impostare il servizio Azure MFA come fattore di autenticazione. Lanciate, una sola volta e su un server ADFS qualsiasi, il comando PowerShell

Set-AdfsAzureMfaTenant -TenantId nicolaferrini.onmicrosoft.com -ClientId981f26a1-7f43-403b-a875-f8b09b8cd720

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD.

Riavviate il Servizio di Active Directory Federation Service su tutte le macchina ADFS della vostra Farm.

Figura 7: Impostazione del servizio Azure MFA come fattore di autenticazione

Verificate che il nuovo metodo di autenticazione Azure MFA sia presente ed abilitato nella console AD FS Management, come mostrato in figura:

Figura 8: Azure MFA è adesso un Primary Authentcation method per la nostra Farm ADFS

Nel mio caso ho abilitato Azure MFA solo per l’accesso dall’esterno e non dall’interno dell’infrastruttura.

Verifica della presenza di Azure MFA come Primary Authentication method

Per verificare che tutto funzioni perfettamente è possibile collegarsi alla pagina di login del vostro server ADFS (nel mio caso è https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm)

Poiché ho federato la mia ADFS con Office 365, vado sul portale di autenticazione https://portal.office.com ed inserisco le credenziali di un utente del dominio e testo l’autenticazione dall’ESTERNO della mia infrastruttura.

Figura 9: Connessione al portale di Office 365

Figura 10: Il dominio di Azure AD è federato e vengo reindirizzato al mio Federation Server

Nella pagina di login è apparso un nuovo link che mi permette di utilizzare la Azure Multi-Factor Authentication.

Figura 11: Nella pagina di login del Federation Server è presente il link per utilizzare la Azure Multi-Factor Authentication

Cliccando però sul link ricevo un messaggio di errore. L’utente che sta tentando di connettersi non ha infatti effettuato il ProofUp, cioè la registrazione di Azure MFA. Per poter accedere deve prima collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione. Successivamente potrà riprovare a loggarsi con ADFS e Azure MFA.

Figura 12: Pagina di errore se l’accesso viene effettuato da un utente che non si è registrato in Azure MFA

Se invece tento di accedere con un utente che si è precedentemente registrato in Azure MFA, mi viene presentata una pagina dove posso inserire il codice di verifica che ho sulla mia App Azure Auhtenticator oppure posso utilizzare altre opzioni (SMS, telefonata, notifica sull’App)

Figura 13: Inserimento della One-Time Password (OTP) per l’autenticazione

Personalizzazione del portale di accesso di AD FS

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup) e abbiamo visto che se un utente non si è precedentemente registrato non riuscirà ad utilizzare Azure MFA. È possibile però apportare delle modifiche alle pagine del portale di autenticazione ADFS e fare in modo di venire rediretti automaticamente alla pagina a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup per eseguire la procedura di registrazione.

Per poter personalizzare l’aspetto della pagina di Sign-In di ADFS è possibile seguire la procedura descritta nell’articolo Advanced Customization of AD FS Sign-in Pages

In questo esempio farò apparire un errore personalizzato, che avvisa gli utenti che devono prima registrarsi ad Azure MFA e successivamente provare a loggarsi al portale.

Come prima operazione clonerò il tema di default delle pagine di Sign-In (che chiamerò AzureMFA) e lo esporterò in modo tale da poterne modificare il file onload.js. La procedura deve essere effettuata da PowerShell su tutti i server ADFS della vostra Farm utilizzando i comandi:

#Creazione di un nuovo tema per il portale ADFS
New-AdfsWebTheme –Name AzureMFA –SourceName default

#Esportazione del tema per poter effettuare le modifiche
Export-AdfsWebTheme –Name AzureMFA –DirectoryPath c:\AzureMFAtheme

Figura 14: Creazione di un nuovo tema per la pagina di Sign-In di ADFS

Nella cartella C:\AzureMFATheme\script troverete il file onload.js, che dovrete modificare inserendo alla fine del file le seguenti righe:

// Se Azure MFA non è disponibile per l'utente si riceve un messaggio che fornisce la procedura corretta per la registrazione
if (document.getElementById('errorMessage').innerHTML.search("The selected authentication method is not available") ) { 
// Show message with redirect link
	errorMessage.innerHTML = 'E\' necessario prima registrarsi per la Multi-Factor Authentication. Collegarsi al portale <a href="https://aka.ms/mfasetup">https://aka.ms/mfasetup</a>, inserire per l\'autenticazione la propria password, registrarsi ad Azure MFA e riprovare successivamente a loggarsi a questa pagina utilizzando la Multi-Factor Authentication.';
}

Figura 15: Modifica del file onload.js con il messaggio di errore personalizzato

Terminata la modifica del file è necessario inserirlo nel tema che avete clonato (nel mio caso si chiama AzureMFA) eseguendo il comando PowerShell

#Aggiornamento del tema con il file onload.js personalizzato
Set-AdfsWebTheme -TargetName AzureMFA -AdditionalFileResource @{Uri=‘/adfs/portal/script/onload.js’;path=“c:\AzureMFAtheme\script\onload.js”}

Successivamente rendete il tema attivo, sostituendo quello di default, con il comando:

#Applicazione del tema personalizzato
Set-AdfsWebConfig -ActiveThemeName AzureMFA

Figura 16: Modifiche apportate al tema di ADFS

Adesso se un utente non ha effettuato il ProofUp, cioè non si è registrato ad Azure AD, invece che ricevere un messaggio di errore che gli indica la procedura corretta di registrazione ad Azure MFA.

Figura 17: Accesso al portale con le credenziali di un utente che non ha effettuato il ProofUp

Figura 18: Messaggio di errore che avvisa l’utente che non può usare la Azure MFA perché deve prima registrarsi (proofup)

Figura 19: L’utente si deve autenticare con la password per poter attivare Azure MFA

Figura 20: L’utente viene reindirizzato al portale di registrazione di Azure MFA

Conclusioni

Per rendere più sicura l’infrastruttura, per evitare che gli utenti vengano bloccati in Active Directory per troppi tentativi di indovinare la password e per stare più tranquilli quando si autenticano utilizzando AD FS da un computer che non è il loro, la soluzione di integrare AD FS 2016 con Azure MFA ed utilizzare un OTP per l’autenticazione è decisamente la migliore e vi permette di sfruttare al massimo le tecnologie disponibili per impedire attacchi di password spray o di password guessing.

Active Directory Federation Services in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Gli Active Directory Federation Services (ADFS) permettono di identificare, autenticare ed autorizzare gli utenti e di offrire il web single sign-on per applicazioni che non sono ospitate nei server del vostro dominio.

Supponete infatti di voler utilizzare un applicativo web creato da un’azienda esterna alla vostra organizzazione (Resource Partner) e di non voler comunicare a questa azienda username e password dei vostri utenti di dominio (Account Partner). ADFS vi permette di reindirizzare le autenticazioni per l’applicazione web verso il vostro Federation Server e di usare il vostro domain controller come database per le autenticazioni. Basta quindi installare due Federation Server ed aprire un’unica porta (il traffico tra i server è HTTPS) per poter avere la possibilità di loggarsi senza reinserire le credenziali e allo stesso tempo non doverle comunicare a nessuno.

Figura 1: Principio di funzionamento di ADFS

In questo articolo mi occuperò della configurazione di una nuova Farm ADFS in Windows Server 2016. Per conoscere tutte le novità della nuova versione di ADFS vi rimando alla lettura dell’articolo What’s new in Active Directory Federation Services per Windows Server 2016

Prima però di avventurarci nella configurazione vera e propria della nostra Farm ADFS vi consiglio di leggere l’articolo Checklist: Deploying a Federation Server Farm e l’articolo Best practices for securing Active Directory Federation Services

L’infrastruttura tipica di una Farm ADFS è quella presentata nella figura 2. All’interno della LAN abbiamo il domain controller e le macchine in dominio, tra cui i server ADFS, mentre nella DMZ abbiamo il Web Application Proxy, che rimarrà in workgroup e che si occuperà di proteggere le connessioni da Internet verso il server ADFS.

Figura 2: Infrastruttura di ADFS che verrà realizzata

Gestione dei certificati per il Namespace ADFS

Come prima operazione procuratevi un certificato digitale per il nome del vostro ADFS Namespace. Utilizzate le informazioni contenute alla pagina Requisiti del certificato per ADFS per conoscere le caratteristiche che deve avere il certificato da installare su tutti i server della vostra infrastruttura ADFS, compresi i Web Application Proxy.

NOTA: Tutti i server ADFS e i server Web Application Proxy necessitano di un certificato SSL per soddisfare le richieste HTTPS per il servizio federativo. Il certificato da installare deve essere esattamente
lo stesso su tutti i server dell’infrastruttura ADFS.

Nel mio caso utilizzerò il certificato con il nome sts.nicolaferrini.cloud. Dopo che avrete installato lo stesso certificato sia sulla macchina ADFS (in dominio) che sulla macchina Web Application Proxy (in workgroup) potete procedere con la configurazione del server ADFS

Requisiti per il dominio

ADFS 2016 richiede che il controller del dominio sia almeno Windows Server 2008 (il livello funzionale del dominio può invece essere ancora Windows Server 2003) e che tutte le macchine ADFS della Farm siano joinate allo stesso dominio. Per la creazione della Farm ADFS potete utilizzare uno standard service account oppure un Group Managed Service Account (gMSA). Per utilizzare un gMSA è necessario che i domain controller sia almeno Windows Server 2012 e uno dei vantaggi più evidenti del loro utilizzo è che la password dell’account viene aggiornata automaticamente.

Io preferisco utilizzare i Group Managed Service Account (gMSA),
e poiché sto usando un ambiente nuovo ed è la prima volta che ne creo uno devo prima creare la Key Distribution Services KDS Root Key, necessaria al domain controller per generare le password dei gMSA. Per poter creare la chiave è sufficiente eseguire, con privilegi elevati, in un domain controller il seguente comando PowerShell

Add-KdsRootKey –EffectiveImmediately

I domain controller aspetteranno fino a 10 ore dal momento della creazione della chiave prima di poter permettere la creazione di un Group Managed Service Account (gMSA), in modo tale da consentire a tutti i domain controller presenti nel dominio di poter replicare la chiave appena creata. In un ambiente di laboratorio potete accelerare questa operazione eseguendo con privilegi elevati in un domain controller il seguente comando PowerShell:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

Figura 3: Creazione della Key Distribution Services KDS Root Key per la generazione delle password dei Group Managed Service Account (gMSA).

Requisiti per il database di ADFS

Per l’installazione di ADFS è possibile utilizzare sia il Windows Internal Database (WID) che Microsoft SQL Server (sono supportate le versioni SQL Server 2008 e successive). Per maggiori informazioni vi rimando alla lettura dell’articolo Requisiti del database di configurazione di una Farm ADFS. In questo articolo utilizzerò il Windows Internal Database.

Installazione del primo server della Farm ADFS

Aprite il Server Manager in Windows Server 2016 e lanciate il wizard per l’aggiunta di un nuovo ruolo. Io sto utilizzando la macchina ADFS1.cloud. lab, che ho joinato al dominio, e procedo all’installazione del ruolo di Active Directory Federation Services, come mostrato in figura:

Figura 4: Installazione del ruolo Active Directory Federation Services

Figura 5: Riepilogo delle funzionalità offerte dal ruolo ADFS

Figura 6: Installazione del ruolo ADFS completata

Cliccando sul collegamento Configure the federation service in this server potrete lanciare il wizard che vi permetterà di creare il primo server della vostra Farm ADFS. Verificate anche dal link AD FS prerequisites di aver completato tutti i prerequisiti d’installazione e procedete cliccando su Next.

Figura 7: Creazione del primo Federation Server nella Farm

Figura 8: Account di dominio da utilizzare per la configurazione del server ADFS

Nella schermata successiva scegliete dal menù a tendina il certificato da utilizzare (che dovrete aver precedentemente installato) ed il Federation Service Name, che vi servirà successivamente per configurare il Web Application Proxy. Indicate anche il nome da visualizzare nella pagina di autenticazione di ADFS.

Figura 9: Certificato, Federation Service Name e nome della Farm ADFS da creare

Nella schermata successiva specificate il Service Account che farà girare i servizi ADFS. Utilizzerò, come già detto, un Group Managed Service Account chiamato ADFSservice

Figura 10: Creazione del Group Managed Service Account

Figura 11: Utilizzo del Windows Internal Database (WID)

Figura 12: Schermata riassuntiva delle configurazioni scelte

Figura 13: Controllo dei prerequisiti

Figura 14: Configurazione della Farm ADFS completata

La creazione della Farm ADFS è completata, ma è necessario riavviare la macchina. Notate alcuni warning che mi sono apparsi nella schermata finale. I warning si riferiscono ad alcuni nomi che mancano nel certificato (certauth.sts.nicolaferrini.cloud e enterpriseregistration.nicolaferrini.cloud). La mancanza di questi nomi non permetterà di registrare i dispositivi tramite ADFS e non permetterà l’autenticazione tramite certificato (novità della versione 4.0 di ADFS). Ricordatevi quindi di utilizzare certificati di tipo SAN con tutti i nomi. Il certificato corretto da utilizzare nel mio dominio avrebbe dovuto includere questi nomi:

  • Subject Name (CN): sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): certauth.sts.nicolaferrini.cloud
  • Subject Alternative Name (DNS): enterpriseregistration.nicolaferrini.cloud

Dopo il riavvio potete connettervi alla AD FS Management console e verificare le configurazioni del vostro server. Aprendo le proprietà potrete accertarvi di aver utilizzato i nomi corretti, come mostrato in figura:

Figura 15: ADFS Management console e Federation Service Properties

Creazione della zona DNS e record per il server ADFS

Per permettere la corretta risoluzione dei nomi del server ADFS ho creato nel domain controller una zona con il nome pubblico nicolaferrini.cloud e ho creato un record host per sts.nicolaferrini.cloud, in modo tale che le macchine interne sappiano come contattare il server ADFS. Il dominio interno ed il dominio esterno infatti differiscono ed è necessario configurare correttamente la risoluzione dei nomi.

Figura 16: Creazione della zona e del record DNS per il server ADFS

Verifica della funzionalità ed accesso alla pagina di Sign-In

ADFS in Windows Server 2016 disabilita di default la pagina idpinitiatedsignon, utile per testare se l’installazione è avvenuta correttamente. È possibile riabilitarla lanciando sul server ADFS il comando Powershell, eseguito con privilegi elevati

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Figura 17: Abilitazione della pagina idpinitiatedsignon

Collegatevi quindi all’indirizzo https://<FQDN DEL SERVER ADFS>/adfs/ls/idpinitiatedsignon.htm per verificare che tutto funzioni. Nel mio caso ho digitato l’indirizzo https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm e ho potuto verificare di avere accesso alla pagina di Sign-In

Figura 18: Verifica dell’accesso alla pagina di Sign-In

È anche possibile verificare che sia attivo l’url relativo ai Federation Service Metadata collegandosi a https://<FQDN DEL SERVER ADFS>/federationmetadata/2007-06/federationmetadata.xml. Nel mio caso ho utilizzato l’indirizzo https://sts.nicolaferrini.cloud/federationmetadata/2007-06/federationmetadata.xml

Figura 19: Verifica dell’accesso ai Federation Service Metadata

Aggiunta dei altri server ADFS alla Farm esistente

In caso il server ADFS non funzionasse i vostri utenti non potrebbero loggarsi. È quindi opportuno aggiungere un ulteriore server alla Farm ADFS che avete appena realizzato. La procedura è ben descritta nell’articolo Add a Federation Server to a Federation Server Farm. Dopo aver aggiunto il secondo server alla Farm sarà necessario anche utilizzare un bilanciatore di carico a monte dei due server per assicurarne l’alta disponibilità. Ulteriori informazioni sono disponibili alla pagina Load Balancer Requirements for ADFS 2016

Installazione del Web Application Proxy

Il Web Application Proxy (WAP), da installare in DMZ e da lasciare in Workgroup, è necessario per proteggere i server ADFS ed evitare di esporli direttamente ad Internet. Il WAP si comporta da Reverse Proxy e permette l’accesso sicuro alle applicazioni on-premises dall’esterno dell’infrastruttura aziendale. Maggiori dettagli sono disponibili nell’articolo Web Application Proxy in Windows Server 2016

Prerequisiti per la configurazione del proxy

  • Installare esattamente lo stesso certificato che avete installato sui server ADFS
  • Assicurarsi che il WAP possa risolvere il nome interno del vostro server ADFS o del VIP del vostro Load Balancer
  • Creare un record DNS pubblico per il WAP, in modo tale che possa essere contattato dall’esterno
  • Aprire le porte del firewall (la porta 443 per l’HTTPS deve essere aperta dall’esterno verso il WAP e dal WAP verso ADFS)

Installazione del Web Application Proxy

L’installazione del Web Application Proxy è molto semplice. Dal Server Manager lanciate il wizard per aggiungere un nuovo ruolo e scegliete il ruolo Remote Access, come mostrato in figura:

Figura 20: Aggiunta del ruolo Remote Access, necessario per l’installazione del Web Application Proxy

Figura 21: Descrizione delle funzionalità offerta dal ruolo Remote Access

Scegliete di installare il role service Web Application Proxy e aggiungete tutte le funzionalità richieste dal ruolo

Figura 22: Installazione del role service Web Application Proxy

Figura 23: Installazione del ruolo completata

Fate clic sul link Open the Web Application Proxy Wizard per lanciare la configurazione del WAP

Figura 24Web Application Proxy Configuration Wizard

Indicate quale sarà il server ADFS a cui dovrà puntare il WAP quando riceverà le richieste di autenticazione ed autorizzazione. Nel mio caso il server è sts.nicolaferrini.cloud

Figura 25: Configurazione del Federation Server da contattare

Figura 26: Scelta del certificato digitale

Figura 27: Comandi PowerShell che verranno eseguiti per la configurazione del WAP

Terminata la configurazione potrete aprire la Remote Access Management console e verificare che tutti i servizi siano perfettamente funzionanti, come mostrato in figura:

Figura 28: Remote Access Management console

Accesso dall’esterno dell’organizzazione

Per verificare che tutto funzioni perfettamente potete collegarvi da una macchina ESTERNA alla vostra infrastruttura e collegarvi al WAP. Modificate il DNS pubblico in modo tale che punti all’IP pubblico del WAP, controllate le configurazioni dei firewall e connettetevi al vostro server (nel mio caso sts.nicolaferrini.cloud) tentando di raggiungere la pagina idpinitiatedsignon, esattamente come avete fatto prima. Se avete configurato tutto correttamente vi collegherete al WAP che inoltrerà la richiesta al server ADFS (o al bilanciatore).

Figura 29: Connessione al server ADFS avvenuta dall’esterno dell’organizzazione, tramite WAP

Accesso dall’interno dell’organizzazione

Se provate a collegarvi da una macchina in dominio, usando qualsiasi browser, alla pagina di autenticazione https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm vi apparirà un messaggio che vi richiederà di inserire le credenziali. Per poter garantire l’accesso automatico dell’utente è prima necessario impostare nella Local Intranet l’url del Federation Server. Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per AD FS.

Figura 30: Richiesta di credenziali anche dalla macchina in dominio

Figura 31: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Figura 32: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

#Verifica dei client attualmente supportati
Get-ADFSProperties Select -ExpandProperty WIASupportedUserAgents

#Aggiunta dei browser Firefox, Chrome e Edge
Set-AdfsProperties –WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,“MSIE 6.0”,“MSIE 7.0”,“MSIE 8.0”,“MSIE 9.0”,“MSIE 10.0”,“Trident/7.0”, “MSIPC”,“Windows Rights Management Client”,“Mozilla/5.0”,“Edge/12”)

#Riavvio dei servizio Active Directory Federation Services
Restart-Service ADFSSRV

Figura 33: Modifica dei client che supportano la WIA in ADFS

Configurazione di Active Direcotry Federation Service con Office 365

Per configurare AD FS 2016 con Office 365 è possibile utilizzare il tool Azure AD Connect, che si occuperà di automatizzare la procedura. Alla pagina Configurare AD FS 2016 ed Office 365 con Azure AD Connect trovate tutti i passaggi necessari per eseguire l’integrazione di AD FS 2016 con Azure AD e Office 365.

Active Directory Federation Services 2016 e Azure Multi-Factor Authentication

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio. Alla pagina Active Directory Federation Services 2016 e Azure Multi-Factor Authentication troverete tutti gli step necessari ad integrare le due funzionalità.

Conclusioni

I vantaggi offerti dai Federation Services sono notevoli, perché permettono il Single Sign-On ed evitano che le password dei nostri utenti vengano memorizzate al di fuori della nostra organizzazione. Sia per motivi burocratici, che di privacy, sarebbe impossibile rivolgersi a fornitori di servizi esterni, che dovrebbero archiviare e gestire (e quindi mantenere aggiornate) le nostre credenziali. Con ADFS l’autenticazione avviene in azienda e i nostri dati sono al sicuro!

Storage Spaces Tiering in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Gli Storage Spaces sono una tecnologia introdotta in Windows Server 2012 ed in Windows 8 che permette di poter proteggere i nostri dati nel caso ci sia un’avaria di uno o più dischi fisici. Si tratta dell’implementazione software del concetto di RAID, il cui scopo è aumentare le performance, rendere il sistema resiliente alla perdita di uno o più dischi e poterli rimpiazzare senza interrompere il servizio.

Con gli Storage Spaces Microsoft introduce un tecnologia che permette di implementare quello che si chiama Software Defined Storage (SDS), che permette di poter collegare alla macchina una serie di dischi (JBOD) e di poter ottenere le stesse funzionalità di una SAN (Storage Area Network).

Si parte dalla creazione di uno Storage Pool (cioè un insieme di dischi fisici) e si crea lo Storage Space, sotto forma di disco virtuale. Il disco virtuale creato viene poi formattato e visualizzato come volume nel sistema operativo.

Figura 1: Principio di funzionamento degli Storage Spaces

In Windows Server 2012 R2 è stata introdotta una nuova tecnologia chiamata Storage Spaces Tiering, che permette di utilizzare dischi diversi (SSD e HDD) all’interno dello stesso Storage Pool. Il vantaggio principale offerto dagli Storage Spaces Tiers è quello di poter conservare i dati che vengono acceduti più frequentemente sui dischi SSD e di spostare i dati più “freddi” sui dischi meccanici HDD, più capienti e decisamente meno costosi.
In questo modo si aumentano di molto le performance offerte dallo storage e l’ottimizzazione avviene in maniera automatica e schedulata.

Creazione dello Storage Pool

Nel mio laboratorio ho utilizzato 4 dischi SSD da 512 GiB ed 8 dischi HDD da 2 TiB. Utilizzando il Server Manager mi sono spostato nel nodo File and Storage Services e ho selezionato Storage Pools. Come si vede dall’immagine sotto, i dischi sono virtuali (sto usando una VM) e vengono visti come dischi SAS. Per creare un nuovo Storage Pool basta cliccare sul pool Primordial e col tasto destro scegliere New Storage Pool

Figura 2: Wizard per la creazione di un nuovo Storage Pool

Date un nome al pool di dischi (nel mio caso si chiamerà Pool1) e cliccate su Next

Figura 3: Nome del Pool di dischi

Nel passaggio successivo verranno mostrati i dischi fisici collegati alla vostra macchina. Potete decidere di utilizzarli tutti o in parte (potete creare diversi Pool) e se saranno inseriti automaticamente nel Pool e quindi contribuiranno fin da subito. È anche possibile utilizzare alcuni dischi come Hot Spare, cioè verranno utilizzati per rimpiazzare dei dischi che eventualmente dovessero subire un guasto.

Figura 4: Allocazione dei dischi (Automatica, Manuale o Hot Spare)

Selezionate quindi i dischi da aggiungere al Pool. Io li ho aggiunti tutti e ho allocato un disco SSD ed un disco HDD di Hot Spare, come mostrato in figura:

Figura 5: Scelta dei dischi da aggiungere al Pool

Figura 6: Conferma delle configurazioni scelte per la creazione dello Storage Pool

Cliccando su Create verrà creato lo Storage Pool. Il processo di creazione dura una manciata di secondi.

Figura 7: Creazione dello Storage Pool

Creazione del Virtual Disk

Terminata la creazione dello Storage Pool, il passaggio successivo consiste nella creazione del Virtual Disk, che poi verrà trasformato in Volume. Dal Server Manager avviate il wizard per la creazione del virtual disk come mostrato in figura:

Figura 8: Wizard per la creazione del Virtual Disk

Poiché nel mio laboratorio sto utilizzando dei vhdx, questi non riescono a far capire a Windows Server il loro Media Type (viene visualizzato come Unknown) e nel momento in cui decido di creare il nuovo Virtual Disk mi accorgo che non è possibile abilitare gli Storage Tiers. È infatti necessario che nello Storage Pool sia disponibile almeno un disco SSD ed almeno un disco HDD.

Figura 9: Creazione degli Storage Tiers non disponibile

Per ovviare a questo problema sarà sufficiente utilizzare un paio di comandi Powershell per sistemare il Media Type dei dischi. Aprite un prompt di PowerShell con privilegi elevati per verificare il Media Type

Get-StoragePool Pool1 Get-PhysicalDisk FT FriendlyName, MediaType, Size

Lanciate il seguente comando per modificare il Media Type di tutti i dischi più piccoli di 1 TiB e configurarli come SSD (io ho 4 dischi da 512 GiB che simuleranno gli SSD)

Get-StoragePool Pool1 Get-PhysicalDisk Size -lt 1TB Set-PhysicalDisk –MediaType SSD

Lanciate il seguente comando per modificare il Media Type di tutti i dischi più grandi di 1 TiB e configurarli come HDD (io ho 8 dischi da 2 TiB che simuleranno gli HDD)

Get-StoragePool Pool1 Get-PhysicalDisk Size -gt 1TB Set-PhysicalDisk –MediaType HDD

Nella figura sotto sono mostrati i risultati dell’operazione:

Figura 10: Modifica degli Media Type dei dischi

A questo punto vi basterà effettuare il refresh nella console del Server Manager per verificare che il Media Type sia stato configurato correttamente

Figura 11: Media Type dei dischi configurato correttamente

Se rilanciate il wizard vedrete che adesso sarà possibile abilitare gli Storage Tiers.

Figura 12: Abilitazione degli Storage Tiers

Una novità introdotta in Windows Server 2016 è l’Enclosure Resiliency. Il sistema operativo si rende conto che i dischi fisici si trovano su Enclosures diversi e quindi quando verrà creato il virtual disk verranno utilizzati dischi fisici in modo che i dati sia presenti su enclosures diversi e che siano disponibili anche se dovesse subire un guasto l’intero enclosure.

Figura 13: Enclosure Awareness ed Enclosure Resiliency

Il volume che voglio creare è un volume di tipo Mirror (simile ai RAID1), che mi permette di avere molta affidabilità anche se a scapito di maggior spazio utilizzato.

Figura 14: Creazione di un virtual disk con funzionalità Mirror

Scelgo anche di creare il virtual disk in modalità There-way Mirror, in modo tale da avere 3 copie del dato ed potervi accedere anche nel caso in cui ci fosse il guato contemporaneo di due dischi fisici.

Figura 15: Configurazione Three-Way Mirror contro la perdita contemporanea di due dischi fisici

Figura 16: Quando di usano gli Storage Tiers è possibile usare solo il fixed provisioning

Scegliete, in base allo spazio a disposizione, la dimensione che avrà il virtual disk. Nel mio esempio voglio creare un disco da 1 TiB utilizzando 265 GiB per il Faster Tier (SSD) e 768 GiB per lo Standard Tier (HDD).

Figura 17: Dimensioni del Virtual Disk e relative specifiche per i Tiers

Confermate le configurazioni scelte e fate clic su Create.

Figura 18: Conifera delle configurazioni del Virtual Disk

La creazione del Virtual Disk dura pochissimi secondi.

Figura 19: Creazione del disco completata

Dalla console Disk Management potrete notare che adesso c’è un nuovo disco, da formattare, della dimensione di 1 TiB.

Figura 20: il Virtual Disk creato è visibile dalla console di Disk Management

Il volume potrà essere creato dalla stessa console di Disk Management oppure dal Server Manager. Se avete lasciato attivato il segno di spunta su Create a volume when this wizard closes nel wizard di creazione del Virtual Disk, vi si aprirà un nuovo wizard per la creazione del Volume.

Figura 21: Selezione del virtual disk su cui creare il Volume

Figura 22: Il Volume deve avere la stessa dimensione del Virtual Disk perché stiamo utilizzando gli Storage Tiers

Assegnate una lettera al Volume.

Figura 23: Assegnazione della lettera al nuovo Volume

Decidete l’etichetta per il nuovo Volume. Potrete formattare il nuovo Volume solo con il File System NTFS perché gli Storage Tiers non permettono di formattare utilizzando il File System REFS.

Figura 24: Etichetta del Volume e File System

Figura 25: Conferma delle configurazioni per la creazione del nuovo Volume

La creazione del nuovo Volume dura pochi secondi

Figura 26: Creazione del Volume completata

Figura 27: Il nuovo Volume è visibile in Esplora Risorse

Processo di ottimizzazione degli Storage Tiers

Windows Server si occupa di ottimizzare in maniera trasparente ed automatica le performance dello storage, spostando i dati che vengono acceduti più frequentemente nel Faster Tier, più veloce ma più costoso e spostando quelli meno utilizzati nello Standard Tier, più lento ma più economico. Durante la giornata gli Storage Spaces creano una heat map dei dati in base a quanto spesso ogni pezzo di dato viene acceduto. Il dato è mappato e spostato tra i diversi livelli, rendendo la fruizione dello stesso molto più perfomante.

Figura 28: Processo di ottimizzazione degli Storage Tiers

Dopo che il wizard è completato verrà automaticamente abilitata anche un’operazione pianificata che si occuperà di gestire ed ottimizzare gli Storage Tiers. L’operazione verrà ripetuta ogni 4 ore ed eseguirà il comando %windir%\system32\defrag.exe -c -h -g -# -m -i 13500

Figura 29: Operazione pianificata per l’ottimizzazione degli Storage Tiers

Conclusioni

Gli Storage Spaces in generale e gli Storage Spaces Tiers in particolare aggiungono a Windows Server le stesse funzionalità che sono tipiche di una SAN (Storage Area Network), riducendone però costi e vincoli all’utilizzo di particolari dischi. Uno degli investimenti maggiori che Microsoft ha fatto negli ultimi anni nello sviluppo di Windows Server è proprio sul Software Defined Datacenter, una serie di tecnologie che permette all’hardware ad al software di espandersi oltre il tradizionale rapporto uno a uno.