Tutti gli articoli di Nicola Ferrini

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.

Utilizzare certificati gratuiti di Let’s Encrypt in una Azure Web App

Facebooktwittergoogle_plusredditlinkedin

Da quando è nata, il 12 aprile 2016, abbiamo avuto modo di parlare in diversi articoli della Certification Authority gratuita Let’s Encrypt. In questo articolo voglio far vedere come ottenere un certificato digitale gratuito generato da Let’s Encrypt da utilizzare con una Web App di Azure.

È infatti disponibile nelle Azure Web App un’estensione, creata da Simon J.K. Pedersen, che permette di ottenere e di rinnovare i certificati digitali da utilizzare con i Custom Domains delle Azure Web App.

Darò per scontato che abbiate già creato una Azure Web App e vi farò vedere come attivare l’estensione per Let’s Encrypt.

Creazione del Service Principal (Registered App)

La prima operazione che faremo sarà quella di creare un Service Principal in Azure AD. Si tratta fondamentalmente di un service account che viene utilizzato per ottenere un accesso alle risorse di Azure e che ci permetterà di richiedere e rinnovare il certificato digitale di Let’s Encrypt senza che sia necessario alcun intervento manuale. La creazione del Service Principal può essere effettuata dal portale di Azure selezionando la directory dentro la quale lo volete creare, scegliendo il nodo App Registrations e cliccando su + New application registration, come mostrato in figura:

Figure 1: Creazione di un nuovo Service Principal in Azure AD

Nel blade che si aprirà digitate il nome che volete dare al Service Principal (io ho scelto nicferr) e l’url della Web App, come mostrato in figura:

Figure 2: configurazione di un nuovo Service Principal in Azure AD

Una volta che avrete creato la Registered App sarà necessario creare una Secret Key (password). Infatti, per le autenticazioni utilizzeremo la combinazione Application ID e Secret Key per permettere all’estensione di Let’S Encrypt di potersi autenticare ed effettuare le operazioni di richiesta e rinnovo del certificato. Cliccate quindi su Settings e scegliete il nodo Keys. Creare una nuova password semplicemente scrivendo la description e la data di scadenza, come mostrato in figura. Quando cliccherete su Save la chiave verrà generata automaticamente.

Figure 3: Creazione di una nuova chiave di accesso per la Registered App

Dopo il salvataggio sarà possibile copiare la chiave generata automaticamente. Ricordatevi di salvarla perché non sarà successivamente visibile, come avrà modo di suggerirvi il banner mostrato in figura:

Figure 4: Generazione della chiave completata

Terminata la creazione del Service Principal (Registered App) sarà necessario assegnargli i giusti permessi per poter eseguire l’estensione. Andate nel Resource Group che ospita la vostra Web App e dal nodo Access Control (IAM), cliccate su Add e date il ruolo di Contributor alla Registered App che avete creato. La Registered App non sarà visibile nell’elenco, ma vi basterà scriverla nel campo Select e sarà subito trovata, come mostrato in figura

Figure 5: Aggiunta dei privilegi al Service Principal (Registered App)

ATTENZIONE: Se la Web App e l’App Service Plan si trovano in due Resource Group differenti, sarà necessario dare il permesso di Contributor ad ENTRAMBI

Installazione dell’estensione Let’s Encrypt

Terminata la fase preparatoria, siamo pronti per installare le due estensioni necessarie a far funzionare Let’S Encrypt con una Azure Web App. Dal portale di Azure, selezionate la Web App e dal nodo Extensions cliccate su Add per aggiungere l’estensione, come mostrato in figura:

Figure 6: Aggiunta di una estensione alla Web App di Azure

Scegliete l’estensione Azure Let’s Encrypt dalla lista delle estensioni disponibili e procedete all’installazione

Figure 7: Scelta dell’estensione Azure LEt’s Encrypt

Questa estensione NON è supportata da Microsoft. È bene tenerne conto nel caso ci siano malfunzionamenti, perché l’autore non da garanzie, come esplicitamente dichiarato nei termini legali.

Figure 8: Accettazione dei termini legali di utilizzo

L’estensione sarà subito visibile tra quelle installate

Figure 9: Installazione dell’estensione completata

Aggiungete anche l’estensione Azure Let’s Encrypt (no Web Jobs)

Figure 10: Aggiunta dell’estensione Azure Let’s Encrypt (no Web Jobs)

Se vi spostate nel modo WebJobs della vostra Web App potrete notare che sarà stata installato un nuovo webjobs, che servirà a rinnovare il certificato prima della scadenza.

Figure 11: Creazione del WebJob nella Web App

Configurazione dell’estensione di Azure Let’s Encrypt

Siamo ora pronti per configurare l’estensione. Cliccate sul tasto Browse dell’estensione Azure Let’s Encrypt per aprire la pagina di configurazione, come mostrato in figura:

Figure 12: Configurazione dell’estensione

Nella nuova pagina del browser vi apparirà la possibilità di configurare in maniera completamente automatica la richiesta e il rinnovo del certificato. Completate tutti i campi come richiesto. Maggiori dettagli su quello che deve essere inserito nei diversi campi sono anche disponibili alla pagina https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install

Figure 13: inserimento delle informazioni necessarie per configurare l’estensione

Cliccando su Next si avvierà il processo di richiesta del certificato. Se non avete aggiunto dei Custom Domain alla vostra Web App vi apparirà l’errore mostrato in figura 15:

Figure 14: Prima richiesta del certificato

Figure 15: Errore relativo alla mancanza di un Custom Domain per cui richiedere il certificato

Aggiunta di un host name per il Custom Domain

Aggiungere un Custom Domain alla Web App richiede pochi semplici passaggi, ben descritti nell’esercitazione Eseguire il mapping di un nome DNS personalizzato esistente ad una Web App di Azure

Figure 16: Aggiunta di un host name personalizzato alla Web App

Una volta che avrete aggiunto il Custom Domain, rilanciando la configurazione dell’estensione di Let’s Encrypt, vedrete che il wizard potrà proseguire e vi chiederà per quale hostname volete generare il certificato, come mostrato in figura:

Figure 17: Il wizard ha riconosciuto gli hostname personalizzati

Figure 18: Scelta del nome host per cui richiedereil certificato

Dopo qualche secondo, il certificato sarà stato creato e associato (binding) all’hostname che avete scelto nel wizard.

Figure 19: Creazione del certificato completata

Se provate a caricare la vostra Web App infatti vedrete che starà utilizzando un certificato emesso da Let’s Encrypt, come mostrato in figura:

Figure 20: La Web App utilizza il certificato emesso da Let’s Encrypt

Conclusioni

Sono decisamente notevoli I vantaggi offerti da Let’s Encrypt, che ci permette di avere certificati digitali gratuiti ed automaticamente rinnovati. Poterli integrare con le Azure Web App ed avere la possibilità di utilizzare il protocollo HTTPS anche per gli hostname personalizzati garantisce i migliori livelli di sicurezza per la navigazione web.

Creare VM in Azure utilizzando VHD personalizzati

Facebooktwittergoogle_plusredditlinkedin

Oltre ad utilizzare I template delle macchine virtuali presenti nel Marketplace di Azure è possibile anche utilizzare le proprie immagini personalizzate per creare delle nuove VM. L’operazione è abbastanza semplice, ma richiede degli accorgimenti importanti, soprattutto per quanto riguarda la preparazione dei dischi VHD prima di caricarli in uno Storage Account di Azure.

Preparazione del disco della macchina virtuale

In Azure l’unico formato dei dischi virtuali che è attualmente accettato è il formato VHD. Pertanto, se avete creato la macchina on-premises con un disco con un formato diverso (ad esempio VHDX o VMDK) sarà necessario convertirlo prima di poterlo caricare in uno Storage Account.

Inoltre, è assolutamente necessario preparare la macchina prima di caricare il disco. I passaggi sono molteplici e sono tutti ben descritti alla pagina Prepare a Windows VHD or VHDX to upload to Azure

Figura 1: Preparazione della macchina virtuale per essere utilizzabile in Azure

Dopo aver preparato la VM per essere utilizzata in Azure e dopo aver installato tutto il software che volete mettere nella vostra immagine personalizzata, è necessario generalizzare il disco con il comando SYSPREP. Infatti, se il disco non è generalizzato non sarà possibile utilizzarlo per creare delle nuove Azure VM.

Figura 2: Generalizzazione dell’immagine con il comando SYSPREP

Upload del disco VHD in uno Storage Account di Azure

Dopo aver generalizzato il disco è possibile caricarlo in uno Storage Account. Potete utilizzare uno Storage Account esistente o crearne uno dedicato. Nel mio caso ho creato un nuovo Storage Account.

Figura 3: Creazione di un nuovo Storage Account

All’interno dello Storage Account ho poi provveduto a creare un nuovo Blob Container che ospiterà i miei VHD personalizzati

Figura 4: Creazione di un nuovo Blob Container che ospiterà i VHD personalizzati

Per poter caricare i dischi all’interno dello Storage Account potete utilizzare Microsoft Azure Storage Explorer, un tool gratuito ad interfaccia grafica che vi permette di gestire con facilità i contenuti dell’account di archiviazione, come ad esempio BLOB, file, code, tabelle, ecc.

Il tool è disponibile per Windows, Per Linux e per macOS ed è scaricabile dalla pagina https://azure.microsoft.com/it-it/features/storage-explorer/

L’installazione è molto rapida e la configurazione lo è ancora di più. Vi basterà inserire le credenziali del vostro Azure Account e potrete amministrare tutti gli Storage Account a cui l’utente ha accesso

Figura 5: Connessione ad Azure Storage

Una volta che vi siete connessi potete caricare il vostro VHD nel Container che preferite, come mostrato in figura:

Figura 6: Caricamento del VHD nel BLOB Container

L’operazione di caricamento può essere visualizzata direttamente dalla console di Microsoft Azure Storage Explorer

Figura 7: Caricamento del file VHD all’interno dello Storage Account

È anche possibile caricare un disco rigido virtuale nell’account di archiviazione tramite uno dei seguenti modi:

È consigliabile usare il servizio di importazione/esportazione se il tempo di caricamento stimato è maggiore di 7 giorni. È possibile usare DataTransferSpeedCalculator per stimare il tempo in base alla dimensione dei dati e alla velocità di trasferimento.

Terminato il trasferimento, dal portale sarà possibile verificare che il VHD è stato caricato nel container.

Figura 8: VHD personalizzato caricato nell’account di archiviazione

Creazione di una Managed Image utilizzando un VHD personalizzato

Azure Managed Disks semplifica la gestione dei dischi per le macchine virtuali di Azure grazie alla gestione degli Storage Account associati ai dischi delle VM. Specificando il tipo (HDD Standard, SSD Standard o SSD Premium) e le dimensioni del disco di cui avete bisogno, Azure crea e gestisce automaticamente il disco. Affidando a Managed Disks la gestione delle risorse di archiviazione non è più necessario preoccuparsi dei limiti degli Storage Account, cioè 20.000 IOPS per account. E non è più necessario copiare le immagini personalizzate (i file VHD) in diversi Storage Account. È possibile gestire tali immagini in una posizione centralizzata, un unico account di archiviazione per ogni area di Azure ed usarle per creare centinaia di macchine virtuali in una sottoscrizione.

Abbiamo anche visto in un precedente articolo Migrazione dei dischi delle macchine virtuali in Azure a Managed Disks che da qualche giorno nella pagina Overview delle macchine virtuali in Azure appare un messaggio che invita a migrare i dischi della VM da Unmanaged a Managed.

La creazione dell’immagine utilizzando un VHD personalizzato è possibile sia dal portale di Azure sia da PowerShell.

Dal portale di Azure vi basterà semplicemente cercare Images tra le diverse risorse disponibili e successivamente selezionare l’immagine che volete utilizzare per creare la nuova VM

Figura 9: Ricerca delle immagini disponibile nella nostra sottoscrizione dal portale di Azure

Cliccate sul pulsante Create Image e inserite di dati richiesti, come mostrato in figura:

Figura 10: Creazione di un’immagine personalizzata utilizzando il portale di Azure

Figura 11: Creazione dell’immagine completata

La stessa operazione può essere effettuata da PowerShell, creando come prima cosa la configurazione che avrà la VM con il comando New-AzureRmImageConfig e successivamente creando l’immagine con il comando New-AzureRmImage

Per eseguire queste operazioni è necessario che abbiate installato il modulo AzureRM versione 5.6 o successiva. Per verificare la versione installata utilizzate il comando Get-Module -ListAvailable AzureRM.Compute, mentre se volete installare il modulo AzureRM o aggiornarlo potete seguire le indicazioni presenti alla pagina Install Azure PowerShell on Windows with PowerShellGet

#Connessione all’Azure Account

Connect-AzureRmAccount

#Creazione del file di configurazione della VM utilizzando il VHD caricato

$imageConfig New-AzureRmImageConfig -Location “West Europe”

$imageConfig Set-AzureRmImageOsDisk -Image $imageConfig -OsType Windows -OsState Generalized -BlobUri “https://nicferrcustomimages.blob.core.windows.net/win2016/Win2016Custom.vhd” -DiskSizeGB 50

New-AzureRmImage -ImageName Win2016CustomImage2 -ResourceGroupName DEMORG -Image $imageConfig

Figura 12: Creazione dell’immagine personalizzata da PowerShell

Creazione della VM utilizzando un’immagine personalizzata

La creazione di una nuova VM può essere fatta utilizzando il portale di Azure oppure utilizzando la cmdlet PowerShell New-AzureRmVm. Nel portale di Azure dal nodo Images selezionate l’immagine che volete utilizzare e cliccate sul pulsante + Create VM. Vi si aprirà il blade che vi cheiderà le caratteristiche che deve avere la VM, come mostrato in figura:

Figura 13: Creazione di una nuova VM partendo da un’immagine personalizzata

Da PowerShell la creazione della nuova VM partendo dall’immagine personalizzata può essere fatta semplicemente lanciando il comando:

#Creazione della VM

New-AzureRmVm -ResourceGroupName DEMORG -Name “CustomVM02” -ImageName Win2016CustomImage -Location “West Europe” -VirtualNetworkName “DEMO-Vnet” -SubnetName “default” -SecurityGroupName “DEMO-NSG” -PublicIpAddressName “DEMO-PIP” -OpenPorts 3389

Figura 14: Creazione della Azure VM da PowerShell comletata

Conclusioni

L’utilizzo di immagini personalizzate per la creazione delle macchine virtuali in Azure rappresenta un notevole vantaggio, perché ci permette di crearle on-premises e di poterle distribuire online. Invece che usare le immagini presenti nel Marketplace abbiamo la possibilità di creare un nostro Template da riutilizzare poi facilmente per la creazione delle VM.

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.

Aumentare l’alta affidabilità delle VM in Azure utilizzando le Availability Zones

Facebooktwittergoogle_plusredditlinkedin

Tutti sappiamo quanto sia importante che le macchine virtuali che fanno girare il nostro workload siano sempre disponibili e non ci siano disservizi. La migrazione delle VM in Azure ci ha permesso di aumentare di molto il livello di prestazioni e di affidabilità delle VM, ma in alcuni casi è necessario, anche per ottemperare ad alcuni regolamenti, assicurarsi che le VM siano protette da un piano di disaster recovery, come ho già avuto modo di farvi vedere nell’articolo Configurare il disaster recovery delle Azure VM in una regione secondaria di Azure

Azure opera in diverse Region nel mondo. Ogni Region può contenere diversi datacenter ed è sempre gemellata con un’altra Region , distante diverse centinaia di Km, con lo scopo di ottenere ridondanza delle funzionalità e strategie di disaster recovery. Se volete conoscere in che modo sono “gemellate” le diverse Region di Azure potete leggere l’articolo Business continuity and disaster recovery (BCDR): Azure Paired Regions

Figura 1: Principio di funzionamento delle Region di Azure

Nel caso delle macchine virtuali, abbiamo già avuto modo di vedere come sia possibile ospitare i VHD utilizzando i Managed Disks nell’articolo Migrazione dei dischi delle macchine virtuali in Azure a Managed Disks ma in ogni caso è bene considerare che la scelta del tipo di archiviazione dei dischi influisce sulle opzioni di replica tra le diverse Region di Azure ed in particolar modo:

Azure Managed Disks

  • Archiviazione con ridondanza locale (LRS)
    • I dati vengono replicati tre volte all’interno dell’area in cui è stato creato l’account di archiviazione.

Dischi basati su Storage Account

  • Archiviazione con ridondanza locale (LRS)
    • I dati vengono replicati tre volte all’interno dell’area in cui è stato creato l’account di archiviazione.
  • Archiviazione con ridondanza della zona (ZRS)
    • I dati vengono replicati tre volte in due o tre strutture distribuite in un’area sola o in due aree.
  • Archiviazione con ridondanza geografica (GRS)
    • I dati vengono replicati in un’area secondaria a centinaia di chilometri di distanza dall’area primaria.
  • Archiviazione con ridondanza geografica e accesso in lettura (RA-GRS).
    • I dati vengono replicati in un’area secondaria, come con la ridondanza geografica, ma risultano anche accessibili in sola lettura nell’area secondaria.

Ovviamente i prezzi variano a seconda del tipo di archiviazione e della disponibilità selezionata.

Availability Zones

Le Availability Zones, un’alternativa agli Availability Sets delle macchine virtuali, permettono di creare le macchine virtuali in una zona fisicamente separata nella Region di Azure. Esistono tre Availability Zones (zone di disponibilità) per ogni area di Azure e ogni Availability Zone può contare su risorse di alimentazione, rete e raffreddamento autonome. Se le VM vengono create su Availability Zones diverse è possibile proteggere applicazioni e dati anche in caso di perdita di un intero data center. Se una zona è compromessa, le applicazioni e i dati replicati delle nostre VM diventano immediatamente disponibili in un’altra zona.

Figura 2: Availabily Zones nelle Region di Azure

Attualmente la funzionalità di Availability Zone è offerta solo in queste aree:

  • Stati Uniti centrali
  • Francia centrale
  • Stati Uniti orientali 2
  • Europa occidentale
  • Asia sud-orientale

E solo per questi servizi:

  • Macchine virtuali Linux
  • Macchine virtuali Windows
  • Set di scalabilità di macchine virtuali
  • Managed Disks
  • Load Balancer
  • Indirizzo IP pubblico
  • Archiviazione con ridondanza della zona
  • Database SQL
  • Hub eventi
  • Bus di servizio
  • Gateway VPN
  • ExpressRoute

Creazione di una macchina virtuale in una Availability Zone

Per creare una VM in Azure in una Availability Zone è sufficiente collegarsi al portale di Azure e seguire il wizard per la creazione di una nuova macchina virtuale.

Figura 3: Creazione di una nuova VM in Azure

Nel momento in cui vi verrà chiesto quale dimensione volete assegnare alla VM sarà possibile anche verificare se quel tipo di VM è disponibile in più zone. Nella figura sotto ho evidenziato la colonna relativa al numero di zone in cui è disponibile ogni taglio di dimensionamento della macchina virtuale.

Figura 4: Numero di zone in cui è disponibile ogni singola dimensione della VM

Dopo aver scelto la dimensione della VM sarà possibile scegliere se vogliamo utilizzare le Availability Zones. Nel momento in cui sceglierete se utilizzare la funzionalità, dal menù a tendina potrete scegliere in quale zona mettere la VM (zona 1, zona 2 o zona 3).

Figura 5: Spiegazione sulle funzionalità offerte dalla Availability Zone

Se scegliete di utilizzare le Availability Zones allora dovrete necessariamente utilizzare anche i Managed Disks, che verranno creati nella stessa zona dove avete deciso di creare la VM e nel caso vogliate assegnare un indirizzo IP pubblico alla vostra VM questo verrà creato nella stessa zona.

Figura 6: Scelta della Availabilty Zone

Figura 7: Creazione della VM completata

Figura 8: Indirizzo IP pubblico creato nella stessa Availability Zone della VM

Creazione di una macchina virtuale in una Availability Zone utilizzando PowerShell

Creare una VM in una Availability Zone utilizzando comandi PowerShell è molto semplice. Prima di tutto assicuratevi che nella vostra Region siano disponibili le Availability Zones. Per farlo, dopo esservi connessi ad Azure con il comando Connect-AzureRmAccount potete lanciare il comando Get-AzureRmComputeResourceSku where {$_.Locations.Contains(“westeurope”)}

Figura 9: verifica delle Availability Zone nella Region scelta

Una volta effettuata la verifica potete creare una nuova VM. Per creare la VM potete usare il comando PowerShell New-AzureRmVM e nei parametri per la creazione della VM potete indicare lo switch -Zone seguito dal numero della zona.

New-AzureRmVM `
-ResourceGroupName “AVZ-RG” `
-Name “VM01-AVZ” `
-Location “West Europe” `
-Size Standard_D4s_v3 `
-Zone 2 `
-Image UbuntuLTS `
-VirtualNetworkName “AVZ-vnet” `
-SubnetName “default” `
-SecurityGroupName “AVZ-nsg” `
-PublicIpAddressName “VM01-AVZ-ip” `
-OpenPorts 22

Figura 10: Creazione di una VM in una Availability Zone con PowerShell

Figura 11: Creazione della VM completata

Conclusioni

Le Availability Zones offrono una soluzione a disponibilità elevata che consente di proteggere le applicazioni e i dati da eventuali guasti del data center. Le Availability Zones sono località fisiche esclusive all’interno di un’area di Azure ed ogni zona è costituita da uno o più data center dotati di impianti indipendenti per l’alimentazione, il raffreddamento e la connettività di rete. Per garantire la resilienza, sono presenti almeno tre zone separate in tutte le aree abilitate. La separazione fisica delle zone di disponibilità all’interno di un’area consente di proteggere le applicazioni e i dati da eventuali guasti del data center. I servizi con ridondanza della zona replicano le applicazioni e i dati tra Availability Zones per garantire la protezione da singoli punti di failure. In questo modo Azure riesce a garantire un uptime ed una garanzia della continuità del servizio delle VM del 99,99%.

Migrazione dei dischi delle macchine virtuali in Azure a Managed Disks

Facebooktwittergoogle_plusredditlinkedin

Da qualche giorno ho notato che nella pagina Overview delle macchine virtuali in Azure appare un messaggio che invita a migrare i dischi della VM da Unmanaged a Managed. Le macchine virtuali interessate in effetti sono state create diversi anni fa, quando gli Azure Managed Disks non esistevano. I dischi delle diverse macchine virtuali sono infatti conservati in uno Storage Account e sono stati progettati per il 99,999% di disponibilità. Per maggiori informazioni sui dischi che vengono collegati alle Azure VM vi rimando alla lettura dell’articolo Informazioni sull’archiviazione su dischi per le VM Windows di Azure

Se create una nuova VM dal portale di Azure vi viene chiesto se volete che i dischi siano Managed o Unmanaged e a dirla tutta la selezione su Managed Disk è attiva di default.

Il vantaggio dell’uso dei Managed Disk è offerto dalla gestione automatica che Azure fa dei dischi, senza necessariamente associarli ad uno Storage Account e senza subirne i limiti. Infatti i dischi avranno la massima tolleranza ai guasti offerta da Azure e saranno disponibili in modalità ridondata, esattamente come avviene per tutte le funzionalità offerte da Azure. I dischi verranno inseriti in differenti Storage Scale Units (stamps) che servono a limitare l’impatto che si avrebbe sulle VM nel momento in cui avvenisse un guasto hardware o software sullo storage.

Figura 1: Durante la creazione di una nuova Azure VM vengono utilizzati di default i Managed Disks

Migrazione dei dischi delle VM esistenti

È possibile eseguire la migrazione delle macchine virtuali di Azure esistenti a Managed Disks per trarre vantaggio dalla maggiore affidabilità delle macchine virtuali in un set di disponibilità. Dalla pagina Overview della VM sarà infatti sufficiente cliccare sul link Migrate to Managed Disks to get more benefits, come mostrato in figura:

Figura 2: Invito alla migrazione ai Managed Disks nella pagina di Overview della Azure VM

È importante notare che la conversione degli Unmanaged Disks a Managed Disks NON sarà reversibile e che una volta completata la conversione non sarà più possibile collegare dischi Unmanaged alla VM. Se la macchina non è accesa, verranno prima convertiti i dischi e successivamente la VM verrà automaticamente avviata per completare la migrazione e successivamente sarà possibile spegnerla. Se la Azure VM fa parte di un set di disponibilità, sarà necessario prima convertire il Virtual Machine Availability Set a Managed Availability Set e successivamente sarà possibile migrare i dischi, come mostrato in figura:

Figura 3: Conversione dell’Availabilty Set esistente a Managed Availability Set

Completata la migrazione dell’Availability Set basterà cliccare sul pulsante Migrate per migrare i dischi della VM. Terminata la migrazione dei dischi la macchina virtuale verrà automaticamente accesa.

Figura 4: Migrazione dei dischi della VM a Managed Disks

Figura 5: Operazione di migrazione dei dischi in corso

Figura 6: Migrazione dei dischi completata

Considerate che i dischi originali della VM NON verranno cancellati dallo Storage Account e che quindi continuerete a pagarli. Dopo la conversione vi conviene quindi cancellare i VHD originali dallo Storage Account.

Conversione tramite Azure Powershell

È possibile eseguire la procedura di conversione dei dischi di una singola VM utilizzando un paio di comandi di Azure PowerShell. Assicuratevi di avere almeno la versione 6.0.0 del modulo Azure PowerShell (verificatelo con il comando Get-Module -ListAvailable AzureRM) e se necessario aggiornate il modulo con il comando Update-Module AzureRM , come mostrato in figura:

Figura 7: Aggiornamento del modulo PowerShell di AzureRM

Connettetevi a Microsoft Azure con il comando Connect-AzureRmAccount e lanciate i seguenti comandi:

#Spegnimento della VM con deallocazione del disco
$rgName “mioResourceGroup” $vmName “miaVM”

Stop-AzureRmVM -ResourceGroupName $rgName -Name $vmName -Force

#Conversione dei dischi e successiva riaccensione della VM
ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $rgName -VMName $vmName

Figura 8: Conversione dei dischi tramite PowerShell

Se volete convertire tutte le VM all’interno di un Availability Set allora potete usare i seguenti comandi:

#Aggiornamento dell’Availability Set a Managed Availiability Set
$rgName ‘mioResourceGroup’

$avSetName ‘mioAvailabilitySet’

$avSet Get-AzureRmAvailabilitySet -ResourceGroupName $rgName -Name $avSetName

Update-AzureRmAvailabilitySet -AvailabilitySet $avSet -Sku Aligned

#Migrazione di tutte le VM contenute nell’Availability Set
foreach($vmInfo in $avSet.VirtualMachinesReferences)

{

$vm Get-AzureRmVM -ResourceGroupName $rgName Where-Object {$_.Id -eq $vmInfo.id}

Stop-AzureRmVM -ResourceGroupName $rgName -Name $vm.Name -Force

ConvertTo-AzureRmVMManagedDisk -ResourceGroupName $rgName -VMName $vm.Name

}

Figura 9: Conversione di tutte le VM di un Availability Set

Problematiche nella migrazione

Durante la migrazione di una delle VM ho riscontrato un errore, che indicava che l’operazione di conversione a Managed Disks non era possibile a causa di una problematica relativa ad un’estensione della VM. Nel mio caso l’estensione era IaaSDiagnostics. Ho provveduto quindi a rimuovere l’estensione direttamente dal portale di Azure, cliccando sul nodo Extensions della VM e scegliendo la voce Uninstall, e a rilanciare la migrazione dei dischi, che si è svolta senza ulteriori intoppi. Successivamente ho reinstallato l’estensione che avevo rimosso.

Figura 10: l’estensione IaaSDiagnostics è in failed state ed impedisce la migrazione a Managed Disks

Figura 11: Rimozione dell’estensione effettuata a macchina accesa

Conclusioni

La migrazione dei dischi a Managed Disks è un’operazione molto semplice, che però richiede un certo downtime in quanto le macchine devono essere arrestate. Prima di iniziare vi consiglio di leggere due articoli: Plan for the migration to Managed Disks e the FAQ about migration to Managed Disks. Avete ancora macchine virtuali con Azure Service Manager (ASM) create con il vecchio portale? Allora seguite la guida Eseguire manualmente la migrazione di una macchina virtuale classica a una nuova macchina virtuale con disco gestito ARM

Buon lavoro!

Nic