Local Administrator Password Solution (LAPS) è un software Microsoft che permette di gestire le password degli amministratori locali in Windows. Quando installate il sistema operativo vi viene chiesto di inserire la password per l’utente amministratore locale del computer e spesso utilizzate questo account e la password impostata per potervi loggare localmente alla macchina se non riuscite a loggarvi al dominio. Gestire manualmente queste password, ammesso e non concesso che non sia un’unica password per tutti i vostri computer, è un’impresa non da poco quando si devono gestire centinaia se non migliaia di macchine. Immaginate cosa potrebbe succedere se la password venisse rivelata a persone indesiderate.

Local Administrator Password Solution (LAPS) permette di creare un repository centralizzato dove conservare le password per gli amministratori locali delle macchine (utenti che hanno il SID che finisce con .500) che sono collegate al dominio e vi permette di:

• Avere una password univoca e quindi diversa su ogni computer che LAPS gestisce
• Cambiare regolarmente la password dell’amministratore locale
• Conservare le password in un attributo del computer in Active Directory
• Configurare e controllare gli accessi alle password
• Trasmettere in maniera sicura le password ai computer gestiti

LAPS funziona sia sulle versioni a 32 bit che a 64 bit di Windows 10, Windows 8, Windows 8.1, Windows 7, Windows Vista, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 e richiede che il livello funzionale del dominio sia almeno Windows Server 2003 o successivo.

Prima di utilizzare il tool sarà necessario aggiornare lo schema di Active Directory con la cmdlet Update-AdmPwdADSchema (inclusa nel modulo PowerShell che verrà installato insieme al tool) e distribuire il client MSI (magari utilizzando le Group Policy client-side extension).

Il tool è scaricabile dall’indirizzo https://www.microsoft.com/en-us/download/details.aspx?id=46899

Come funziona LAPS

Dopo aver distribuito il client sulle macchine da amministrare, ogni volta che avviene il refresh delle Group Policy, vengono effettuate le seguenti operazioni:

• LAPS controlla se la password dell’amministratore è scaduta
• Se la password è scaduta allora viene generata dinamicamente una nuova password, che viene conservata in un particolare attributo di AD del computer, e viene trasmessa al computer e quindi assegnata all’account amministrativo

Installazione di LAPS

Prima di poter configurare i computer, sarà necessario spostarli in una OU dedicata, a cui verranno successivamente associate le Group Policy per la gestione.

Scaricate LAPS e installate solo i tool di gestione. Nel mio caso l’ho installato sul domain controller. Disabilitate l’AdmPwd GPO Extension ed abilitate tutti management Tools, come mostrato in figura:

Figura 1: Schermata iniziale del tool Local Administrator Password Solution

Figura 2: Configurazione dei parametri del tool

Figura 3: Completamento dell’installazione

Terminata l’installazione del tool, lanciate un prompt di PowerShell con privilegi elevati ed eseguite i seguenti comandi:

Import-Module admpwd.ps

Update-AdmPwdADSchema

Set-AdmPwdComputerSelfPermission -Identity “Roma_Computers” (Roma_Computers è l’organizational unit dentro la quale ci sono i computer da gestire)

Ricordatevi che per poter aggiornare lo schema dovete eseguire la cmdlet Update-AdmPwdADSchema con privilegi di Enterprise Admin o di Schema Admin.

Figura 4: Configurazione e aggiornamento dello Schema

A questo punto create una nuova GPO e collegatela alla OU che volete gestire. Io ho chiamato la GPO con il nome LAPS e l’ho collegata alla OU chiamata Roma_Computers. Editate la GPO e dopo esservi spostati nel ramo Computer ConfigurationàPoliciesàAdministrative TemplatesàLAPS, modificate il parametro Enable local admin password management mettendolo su Enabled e il parametro Password Settings scegliendo lunghezza e durata della password, come mostrato in figura:

Figura 5: Configurazione dei parametri della Group Policy per il LAPS

Distribuzione del client LAPS

Per distribuire il client potete utilizzare i metodi che preferite, sia con l’installazione manuale che con la distribuzione tramite Group Policy client-side extension o con altri metodi ESD (Electronic Software Distribution).

Procedete quindi all’installazione del software e, nel caso l’abbiate fatta manualmente, ricordatevi di aggiornare le policy con il comando gpupdate /force.

Figura 6: Distribuzione del client LAPS tramite GPO

Figura 7: Applicazione della GPO sui pc client

Dopo aver riavviato il client per permettere l’installazione dell’agent di LAPS, potete tornare sul vostro server di amministrazione (nel mio caso il domain controller) e da Start aprite LAPS UI.

Digitate il nome del computer da ricercare e fate clic su Search. Vi apparirà la password dell’amministratore locale e la scadenza, come mostrato in figura:

Figura 8: Verifica della password tramite LAPS UI

In alternativa all’interfaccia grafica è anche possibile utilizzare la cmdlet Get-AdmPwdPassword CL1 | Out-Gridview

Figura 9: Utilizzo di PowerShell per la visualizzazione della password

Oppure è possibile visualizzare il valore dell’attributo ms-Mcs-AdmPwd del Computer Account in modalità visualizzazione avanzata della console di Active Directory Users and Computers.

Figura 10: Attibuto ms-Mcs-AdmPwd del computer account in AD

Per permettere ai computer di poter aggiornare la password dell’amministratore locale quando scade è sufficiente eseguire con privilegi elevati la cmdlet di Powershell Set-AdmPwdComputerSelfPermission -Identity “Roma_Computers“

Figura 11: Abilitazione per l’autoaggiornamento della password

Per impostazione predefinita i gruppi Domain Admins ed Enterprise Admins possono visualizzare le password gestite tramite LAPS. Se volete delegare ad un gruppo specifico la possibilità di vedere le password dell’amministratore locale allora sarà necessario eseguire con privilegi elevati la cmdlet di Powershell Set-AdmPwdReadPasswordPermission -Identity “Roma_Computers” -AllowedPrincipals “Roma_ITOps”

Figura 12: Delega amministrativa per LAPS

Conclusioni

Local Administrator Password Solution (LAPS) permette di semplificare enormemente la gestione delle password degli amministratori locali e soprattutto aumenta il livello di sicurezza delle postazioni di lavoro. Molto spesso l’utilizzo della stessa password, che si ripete da diversi anni, è una vulnerabilità sensibile delle nostre macchine e le espone alla possibilità di essere facilmente attaccate o di essere amministrate da utenti non autorizzati.

Maggiori informazioni le trovate al link https://technet.microsoft.com/it-it/mt227395.aspx

Il 22 novembre a Villorba (TV) si è svolta la conferenza tecnica gratuita Cloud Conference Italia 4.0, organizzata da walk2talk srl, dedicata alle maggiori novità in ambito IT e indirizzata a professionisti del settore quali CIO, IT Manager, Sistemisti ed Architetti IT. La conferenza giunta alla quarta edizione ha visto un grade successo di pubblico che ha dimostrato di aver apprezzato i temi trattati durante la conferenza.

ICTPower è stata invitata a partecipare con una sessione tenuta Ermanno Goletto e Roberto Massa dal titolo Security Best Practices e novità in Windows Server 2016 dedicata all’analisi dell’attuali minacce informatiche, all’applicazione delle best practices per la protezione e il monitoraggio e alle novità contenute in Windows Server 2016. La sessione è stata seguita da un pubblico numeroso che ha dimostrato vivo interesse per i temi e le problematiche trattate e ha voluto premiare i nostri relatori con feedback estremamente positivi.

• Active Directory – Tecniche di attacco e di difesa
• Limitare i privilegi amministrativi utilizzando la Just Enough Administration (JEA)
• Implementare Local Administrator Password Solution
• Tecniche di attacco e difesa contro l’utilizzo di dispositivi USB
• Microsoft Security Intelligence Report Volume 22
• Ransomware protection in Windows 10 Anniversary Update
• Cisco 2017 Midyear Cybersecurity Report
• Sicurezza e stampanti multifunzione

Desideriamo ringraziare walk2talk srl per aver dato alla community ICTPower la possibilità di collaborare alla realizzazione di una conferenza che ha riscosso un così grande successo e di aprire una piacevole collaborazione. Per gentile concessione di walk2talk srl rendiamo disponibile la registrazione della sessione sul nostro canale YouTube e vi ricordiamo che tutte registrazioni saranno presto disponibili anche sul sito della conferenza.

La Just Enough Administration (JEA) è una delle novità di sicurezza del Windows Management Framework 5.0 che permette di limitare le sessioni amministrative solo ad un particolare set di comandi e aumenta di fatto la sicurezza nella gestione dei nostri sistemi.

Questo tipo di funzionalità, basata sull’amministrazione PowerShell remota (Windows PowerShell Remoting), permette di configurare degli endpoint in modo tale che quando un utente si connette per eseguire delle cmdlet di PowerShell remote, gli venga concesso l’utilizzo di solo alcuni script e di alcuni comandi. Ad esempio, potreste limitare per un utente la possibilità di amministrare il DNS e di eseguire solo alcune delle cmdlet relative alla sua gestione. Se il ruolo DNS è installato sul controller di dominio Active Directory (come di regola avviene), gli amministratori DNS richiedono privilegi di amministratore locale per risolvere problemi con il server DNS, e per fare ciò è necessario che siano membri del gruppo di sicurezza con privilegi elevati “Domain Admins”.

JEA permette di evitare l’uso di account privilegiati. L’utente si connette all’endpoint remoto JEA utilizzando uno speciale virtual account privilegiato invece che il proprio account utente. I vantaggi di questo tipo di approccio sono molteplici:

• Le credenziali dell’utente non verranno memorizzate nel sistema remoto e nel caso questo venga compromesso non sarà possibile rubare le credenziali
• L’utente che utilizzate per l’amministrazione remota non dovrà essere privilegiato e potrà essere un normale utente di dominio
• Il virtual account è valido solo nell’host dove si trova e non può essere riutilizzato per connettersi ad altri sistemi remoti
• Il virtual account ha privilegi amministrativi sull’host, ma limitati alle attività che saranno stabilite per la JEA

La funzionalità di Just Enough Administration (JEA) è disponibile di default in:

• Windows Server 2016
• Windows 10, version 1511 or later

Ma funziona anche se avete installato Windows Management Framework 5.0 in:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2
• Windows 8.1
• Windows 8
• Windows 7

In realtà Windows Server 2008 R2 ed Windows 7 non supportano i virtual accounts JEA e tutte le attività vengono eseguite dall’utente che si connette al JEA Endpoint.

Configurare JEA non è semplicissimo, perché bisogna sapere esattamente quali sono le attività che verranno svolte e quali sono i comandi che dovranno essere eseguiti. In ogni caso se avete attività da svolgere spesso o script da eseguire, JEA è un ottimo modo per ridurre la superficie di attacco ed implementare RBAC (Role Based Access Control). Un altro limite evidente è sicuramente quello che JEA funziona SOLO con PowerShell.

Per mostrarvi come funziona JEA, darò la possibilità ad un semplice utente di dominio di effettuare alcune operazioni sul server DNS (nel mio caso il domain controller DC1). Ho creato un utente di dominio e l’ho aggiunto ad un gruppo chiamato DNSOps.Il gruppo DNSOps è anch’esso un gruppo che non ha privilegi amministrativi.

Figura 1: Creazione dell’utente limitato ed aggiunta al gruppo DNSOps

Creazione del Role-Capability file

Il Role-Capability file permette di specificare cosa potrà essere fatto nelle sessioni remote di PowerShell. È possibile creare un nuovo file, che avrà estensione .psrc, e aggiungere le cmdlet, le funzioni e tutti i comandi necessari. Per avere una lista completa dei parametri utilizzabili e delle diverse parti del file .psrc vi rimando alla lettura dell’articolo https://docs.microsoft.com/en-us/powershell/jea/role-capabilities e dell’articolo https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/new-psrolecapabilityfile?view=powershell-5.1

Per creare un nuovo Role-Capability File è sufficiente eseguire sul domain controller o sul server DNS (nel mio caso si chiama DC1) PowerShell ISE, con privilegi elevati, e lanciare le seguenti cmdlet di PowerShell:

Cd ‘c:\Program Files\WindowsPowerShell\Modules’
Mkdir DNSOps
Cd DNSOps
New-ModuleManifest .\DNSOps.psd1
Mkdir RoleCapabilities
Cd RoleCapabilities
New-PSRoleCapabilityFile -Path .\DNSOps.psrc
Ise DNSOps.psrc

In questo modo verrà creato un nuovo file chiamato DNSOps.psrc che utilizzeremo per poter gestire il DNS.

Figura 2: Creazione di un Role-capability file DNSOps.psrc

Configurazione del Role-Capability file

Dopo aver creato il Role-Capability file DNSOps.psrc, è necessario configurarlo per i nostri scopi. Se avete eseguito la cmdlet Ise DNSOps.psrc nel passaggio precedente potrete già modificare il file. Come prima operazione consentiamo di riavviare solo il servizio DNS. Posizionatevi quindi sotto la riga che inizia per # VisibleCmdlets = e digitate:

VisibleCmdlets = @{ Name = 'Restart-Service'; Parameters = @{ Name='Name'; ValidateSet = 'DNS'}}

Per consentire l’utilizzo di solo alcune cmdlet riferite alla gestione del DNS posizionatevi sotto la riga che inizia per # VisibleFunctions = e digitate:

VisibleFunctions = 'Add-DNSServerResourceRecord', 'Clear-DNSServerCache', 'GetDNSServerCache', 'Get-DNSServerResourceRecord' , 'Remove-DNSServerResourceRecord'

Per consentire l’utilizzo di solo alcuni eseguibili (nel mio caso whoami.exe) posizionatevi sotto la riga che inizia per # VisibleExternalCommands = e digitate:

VisibleExternalCommands = 'C:\Windows\System32\whoami.exe'

Salvate il file DNSOps.psrc. Il risultato è quello mostrato nella figura sotto:

Figura 3: Modifica del Role-capabilty file DNSOps.psrc

Creazione del Session-configuration file

Il Session-configuration file serve a definire cosa può essere fatto in una sessione JEA. Se una cmdlet, un parametro, il valore di un determinato parametro, un alias, uno script esterno o un eseguibile non sono presenti nel session-configuration file, allora non potranno essere utilizzati in una sessione JEA configurata per utilizzare quel session-configuration file.

Per creare un nuovo file, che avrà l’estensione .pssc, è sufficiente utilizzare la cmdlet New-PSSessionConfigurationFile. Per avere una lista completa dei parametri utilizzabili e delle diverse parti del file .pssc vi rimando alla lettura dell’articolo https://docs.microsoft.com/en-us/powershell/jea/session-configurations e dell’articolo https://docs.microsoft.com/it-it/powershell/module/Microsoft.PowerShell.Core/New-PSSessionConfigurationFile?view=powershell-5.1

Creiamo un nuovo file eseguendo sul nostro server DNS (nel mio caso si chiama DC1) da PowerShell ISE con privilegi elevati le seguenti cmdlet:

Cd ‘c:\Program Files\WindowsPowerShell\Modules\DNSOps’
New-PSSessionConfigurationFile -Path .\DNSOps.pssc -Full
Ise DNSOps.pssc

Dopo aver creato il file è possibile modificarlo. Da PowerShell ISE, nella scheda DNSOps.pssc, modificate il valore SessionType = ‘Default‘ in

SessionType = 'RestrictedRemoteServer'

Navigate fino alla linea #RunAsVirtualAccount = $true e rimuovete il comment # in modo tale che ci sia solo

RunAsVirtualAccount = $true

Spostatevi quindi alla linea che comincia con #RoleDefinitions e subito sotto scrivete il nome del gruppo di AD che volete usare per la gestione (nel mio caso DEMO\DNSOps):

RoleDefinitions = @{ 'DEMO\DNSOps' = @{ RoleCapabilities = 'DNSOps' };}

Salvate il file DNSOps.pssc. Il risultato è quello mostrato nella figura sotto:

Figura 4: Modifica del session-configuration file DNSOps.pssc

Creazione del JEA Endpoint

Un JEA Endpoint è un endpoint PowerShell che è configurato in modo tale che solo alcuni utenti possano connettersi e abbiano accesso alle cmdlet, ai parametri e ai valori definiti dal session-configuration file. Un server può avere diversi JEA Endpoint ed ognuno di loro può essere utilizzato per diversi scopi amministrativi. Una volta che un utente si collega al JEA Endpoint avrà i privilegi assegnati al virtual account che è stato definito nel session-configuration file. Per approfondimenti sui JEA Endpoint vi rimando all’articolo https://docs.microsoft.com/en-us/powershell/jea/register-jea

Per creare un JEA Endpoint è possibile utilizzare la cmdlet Register-PSSessionConfiguration. Sul vostro server DNS da PowerShell ISE lanciate le seguenti cmdlet:

Register-PSSessionConfiguration -Name DNSOps -Path .\DNSOps.pssc
Restart-Service WinRM
Get-PSSessionConfiguration

Il risultato è quello mostrato in figura:

Figura 5: Creazione del JEA Endpoint

Verificate che DNSOps sia elencato tra gli Endpoint disponibili.

Se avete sbagliato a configurare un Endpoint potete sempre eliminarlo utilizzando la cmdlet Unregister-PSSessionConfiguration

Creazione di una sessione amministrativa

Per verificare che tutto funzioni correttamente utilizzerò una macchina remota per effettuare l’amministrazione. Da una macchina del dominio che voglio usare come postazione di amministrazione, dopo essermi loggato come Domain Admin (demo\administrator), mi collego con una sessione PowerShell remota a DC1 e verifico quali sono i permessi che ho a disposizione usando le seguenti cmdlet:

Enter-PSSession -ComputerName DC1
(Get-Command).count
Whoami.exe

Come si può notare dalla figura sotto, ho la possibilità come domain admin di usare 2006 cmdlet diverse:

Figura 6: Sessione remota PowerShell con privilegi da domain admin

Creazione di una sessione di Just Enough Administration (JEA)

Dalla stessa macchina di dominio che voglio utilizzare come postazione di amministrazione mi loggo questa volta come domain user (demo\nicferr) che fa parte del gruppo DEMO\DNSOps (che ho autorizzato nel Session-configuration file) e mi collego con una sessione PowerShell remota a DC1. Se lanciassi la cmdlet Enter-PSSession -ComputerName DC1 riceverei un messaggio di errore perché essendo un domain user non ho privilegi amministrativi su DC1. Ma se lancio Enter-PSSession -ComputerName DC1 -ConfigurationName DNSOps (dichiarando quindi di voler utilizzare una configurazione JEA) riesco a connettermi. Verifico quali sono i permessi che ho a disposizione usando le seguenti cmdlet:

Enter-PSSession -ComputerName DC1 -ConfigurationName DNSOps
(Get-Command).count
Whoami.exe

Figura 7: Connessione alla macchina DC! utilizzando la configurazione JEA

Come si può vedere dalla figura 7, il comando Whoami.exe non restituisce il logon name dell’utente (demo\nicferr) bensì quello del virtual account utilizzato da JEA (winrm virtual users\winrm va_1_demo_nicferr).

Provo quindi ad eseguire alcuni comandi per la gestione del DNS (ovviamente saranno concesse solo le cmdlet che ho definito nel role-capability file):

Get-DNSServerResourceRecord -zonename demo.lab
Add-DNSServerResourceRecord -zonename ‘demo.lab’ -A -Name ‘SVR1’ -IPv4Address ‘10.0.0.101’
Add-DNSServerResourceRecord -zonename ‘demo.lab’ -A -Name ‘SVR2’ -IPv4Address ‘10.0.0.102’
Remove-DNSServerResourceRecord -zonename ‘demo.lab’ -RRTYPE ‘A’ -Name ‘SVR2’ -Confirm

I risultati sono mostrati in figura:

Figura 8: Esecuzione dei comandi abilitati nel role-capability file

Provo anche a riavviare il servizio DNS utilizzando la cmdlet Restart-Service DNS ed in effetti il servizio viene riavviato. Se invece provo a riavviare un altro servizio non consentito nel role-capability file (ad esempio utilizzando la cmdlet Restart-Service WinRM) ricevo un messaggio di errore, come mostrato in figura:

Figura 9: Errore dovuto all’esecuzione di un comando non contenuto nel role-capability file

Distribuzione della configurazione JEA ad un altro computer

Una volta che avete validato la vostra configurazione JEA, sarà possibile distribuirla su tutti i computer che volete amministrare. Per poter riutilizzare la configurazione JEA che avete creato su vostro server DNS (nel mio caso DC1), potete copiare tutto il contenuto della cartella C:\Program Files\WindowsPowerShell\Modules\DNSOps del vostro server e incollarla nel nuovo server da gestire nello percorso C:\Program Files\WindowsPowerShell\Modules. Successivamente potete creare il nuovo JEA Endpoint utilizzando i comandi PowerShell:

Cd ‘c:\Program Files\WindowsPowerShell\Modules\DNSOps\RoleCapabilities’
Register-PSSessionConfiguration -Name DNSOps -Path .\DNSOps.pssc
Restart-Service WinRM

Figura 10: Copia della configurazione JEA sul nuovo server da gestire

Verificate con la cmdlet Get-PSSessionConfiguration che DNSOps sia disponibile come Endpoint.

Figura 11: Creazione del JEA Endpoint sul nuovo server da gestire

Conclusioni

La Just Enough Administration (JEA) consente di migliorare le condizioni di sicurezza, riducendo di fatto il numero di amministratori nei computer. Ciò avviene tramite la creazione per gli utenti di un Endpoint per eseguire attività amministrative in maniera limitata, per prevenire usi impropri. Poiché JEA consente di eseguire i comandi di amministratore senza avere accesso come amministratore, è possibile rimuovere gli utenti dai gruppi di sicurezza con privilegi elevati e renderli quindi utenti standard, adottando il principio di privilegio minimo.

Utilizzando la Search Service Application in SharePoint è possibile indicizzare diverse tipologie di dati. Gli approcci sono spesso specifici per tipologia e basati sulle singole esigenze. Come fare se ciò che dobbiamo indicizzare persiste esclusivamente su DB?

In questa guida vedremo come creare un content source relativo a dati contenuti in una tabella (o una vista) SQL Server, utilizzando Business Data Connectivity Service e Secure Store Service.

Prerequisiti:

• SharePoint 2016
• Business Data Connectivity Service Application
• Secure Store Service Application
• Search Service Application
• SQL Server
• SharePoint Designer 2013

Secure Store Service Application

Dopo aver aperto la Central Administration Console di SharePoint, clicchiamo su “Manage Service Applications”. Selezioniamo la nostra Secure Store Service Application e clicchiamo, nella ribbon bar, sul pulsante “Manage”:

Figura 1: Central Administration Console – Service Applications

Generiamo una nuova chiave cliccando su “Generate New Key”:

Figura 2: Secure Store Service Application

Inseriamo una pass phrase e clicchiamo su OK.

Figura 3: Secure Store Service Application – Nuova Chiave

L’obbiettivo è indicizzare il contenuto della tabella SQL “Utenti” senza lavorare direttamente su SQL Server. La tabella è la seguente:

Figura 4: SQL Server Management Studio – Tabella

Per fare ciò clicchiamo su “NEW” e seguiamo il wizard per la creazione di una nuova Secure Store Target Application.

Figura 5: Secure Store Service Target Application

Clicchiamo su Next per continuare.

In questa fase possiamo scegliere di configurare le modalità di visualizzazione dei campi Username e Password. Questa configurazione non potrà essere modificata successivamente quindi è necessario prestare attenzione. Lasciando tutto di default la password sarà mascherata come da standard. Clicchiamo su Next per continuare.

Figura 6: Secure Store Service Target Application

Configuriamo l’amministratore (o gli amministratori) della Target Application ed i membri che potranno utilizzarla.

Figura 7: Secure Store Service Target Application

Figura 8: Secure Store Service Target Application – Gestione Utenti

Cliccando su OK terminiamo la prima configurazione.

Figura 9: Secure Store Service Target Application

Selezioniamo l’applicazione appena creata e clicchiamo sul pulsante Set:

Figura 10: Secure Store Service Target Application

Configuriamo le credenziali che verranno utilizzate dal gruppo configurato.

Figura 11: Secure Store Service Target Application – Credenziali

Clicchiamo su OK per confermare.

Business Data Connectivity Service Application

Con lo strumento SharePoint Designer 2013 colleghiamoci alla farm e clicchiamo su “Tipi di contenuto esterno”:

Figura 12: SharePoint Designer – Menu

Clicchiamo sull’omonimo pulsante nella ribbon bar “Tipi di contenuto esterno”.

Figura 13: SharePoint Designer – Creazione External Content Type

Inseriamo un nome e configuriamo il Sistema esterno collegato a questo elenco:

Figura 14: SharePoint Designer – Configurazione External Content Type

Clicchiamo su “Aggiungi connessione” configurare la connessione al nostro DB.

Figura 15: SharePoint Designer – Configurazione Connessione

Selezioniamo SQL Server e clicchiamo OK

Figura 16: SharePoint Designer – Selezione Fonte Dati

Configuriamo la connessione inserendo i dati relativi. Per poter utilizzare la secure target application creata in precedenza utilizziamo la configurazione “Connetti con identità di Windows rappresentata”.

Nel mio caso:

Figura 17: SharePoint Designer – Configurazione Fonte Dati

Clicchiamo su OK per confermare.

Dopo aver inserito le credenziali richieste la connessione viene effettuata.

Figura 18: SharePoint Designer – Selezione Tabella

Selezioniamo la tabella desiderata, clicchiamo con il tasto destro del mouse e selezioniamo “Crea tutte le operazioni“.

Figura 19: SharePoint Designer – Selezione Operazioni di CRUD

Con questa configurazione potremmo effettuare tutte le operazioni di CRUD operando solo sulla lista. Le modifiche verranno riportate sulla tabella direttamente da SharePoint.

Seguendo il wizard ottengo un errore: la tabella non ha chiavi primarie.

Figura 20: SharePoint Designer – Configurazioni Parametri Operazioni

Selezioniamo il campo ID in modo da poter configurare il mapping a identificatore e forzare questa configurazione sulla lista.

Figura 21: SharePoint Designer – Configurazioni Parametri Operazioni

Clicchiamo su Fine.

Per salvare la configurazione effettuata, clicchiamo sul tab DBUtenti con il tasto destro, successivamente su Salva.

Figura 22: SharePoint Designer – Configurazione Connessione

Clicchiamo con il tasto destro sul nuovo Tipo di contenuto esterno creato e selezioniamo Elenco esterno:

Figura 23: SharePoint Designer – Creazione Elenco Esterno

Inseriamo un nome ed eventualmente una descrizione

Figura 24: SharePoint Designer – Configurazione Elenco Esterno

Clicchiamo su OK per terminare.

La lista è stata creata, non ci resta che cliccare sulla URL per verificarne il funzionamento.

Figura 25: SharePoint Designer – Configurazione Elenco Esterno

Il risultato sarà il seguente:

Figura 26: SharePoint – Lista

Assicuriamoci di essere loggati per non incappare nell’errore “Permission Denied”.

Da questo momento è possibile utilizzare questa lista con tutti gli strumenti messi a disposizione da SharePoint.

Figura 27: SharePoint – Dettaglio Elemento Lista

Search Service Application

Apriamo la Search Administration console e clicchiamo su “Content Sources“.

Creiamo un nuovo Content Source che punta alla nuova lista:

Figura 28: Search Service Application – Creazione Content Source

Clicchiamo su OK per confermare.

Figura 29: Search Service Application – Elenco Content Source

Lanciamo il comando Full Crawl per eseguire l’indicizzazione cliccando su “Start Full Crawl“:

Figura 30: Search Service Application – Full Crawl

Terminata l’operazione dobbiamo creare un mapping tra i titoli delle colonne della tabella e delle managed properties ricercabili. Dobbiamo creare tre variabili per mappare:

• Nome;
• Cognome;
• Città.

Per fare ciò, clicchiamo su Search Schema

Figura 31: Search Service Application – Menu

Successivamente su “New Managed Property“:

Figura 32: Search Service Application – Search Schema

Compiliamo il campo Property name, nel mio caso “nome” ed abilitiamo i flag Searchable, Queryable e Retrivable

Figura 33: Search Service Application – Creazione Managed Property

Figura 34: Search Service Application – Configurazione Managed Property

Scorrendo verso il basso, clicchiamo su Add a Mapping

Selezioniamo il filtro “Business Data” e cerchiamo “nome”, ovvero il titolo della specifica colonna della tabella e clicchiamo su Find.

Figura 35: Search Service Application – Configurazione Mapping

Clicchiamo su OK per confermare il mapping e nuovamente su OK per completare la creazione della nuova managed property.

Ripetiamo l’operazione creando “cognome” e “città”.

Il risultato atteso è il seguente:

Figura 36: Search Service Application – Elenco Managed Properties 1

Figura 37: Search Service Application – Elenco Managed Properties 2

Rilanciamo nuovamente l’azione di full crawl ed attendiamo il termine dell’operazione.

Per interpretare meglio i risultati, utilizziamo lo SharePoint Search Query Tool disponibile al link https://github.com/SharePoint/PnP-Tools/tree/master/Solutions/SharePoint.Search.QueryTool

Una volta eseguito il programma, nel campo “Query Text” cerchiamo, ad esempio, Scarlet ed inseriamo tra le Selected Properties le managed properties configurate in precedenza “nome, cognome, città”:

Figura 38: Search Service Application – Search Query Tool – Chiamata API

Tra i Primary Results saranno visibili le colonne della nostra tabella.

Come ulteriore test, effettuiamo una chiamata alle API utilizzando il browser e puntando alla seguente URL:

http://localhost/_api/search/query?querytext=’scarlet’&selectproperties=’nome%2c+cognome%2c+città’&clienttype=’ContentSearchRegular’

Figura 39: Search Service Application – Chiamata API

Conclusioni

Indicizzare una fonte dati esterna è spesso un’operazione problematica, soprattutto in grandi infrastrutture. Il metodo descritto in questa guida è molto comodo quando la base dati è gestita da altri gruppi di lavoro e, di conseguenza, non si hanno (o non si devono avere!) responsabilità sui contenuti.

Questo è solo un tipo di approccio: Microsoft ha reso la Search Service Application molto versatile ed estremamente personalizzabile!

IIn Windows Server 2012 R2 sono stati introdotti gli Shared Disk (che avevano l’estensione .VHDX), pensati per poter condividere uno o più hard disk tra più macchine virtuali e semplificare la creazione dei Guest Cluster. In questo modo è infatti possibile proteggere i servizi e le applicazioni all’interno delle VM ed in particolar modo gli Shared Disk si prestano ad ospitare i file dei database SQL Server e i dati dei File Server creati all’interno delle VM. Gli Shared VHDX avevano però tutta una serie di limitazioni (no resize, no host level backup, no ckeckpoint, no Hyper-V Replica support, no storage live migration) che di fatto ne hanno limitato fortemente l’adozione.

In Windows Server 2016 gli Shared Disk sono stati sostituiti dai VHD Set (hanno l’estensione .VHDS), che hanno il vantaggio di poter essere ridimensionati online, di poter essere replicati utilizzando Hyper-V Replica e di poter essere salvati durante le normali procedure di backup con Backup Host based. Rimane in ogni caso ancora non disponibile la possibilità di fare Storage Live Migration e la creazione dei Checkpoint.

I VHD Set devono necessariamente essere salvati all’interno dei Cluster Shared Volumes (CSVs) o dei Clustered Storage Spaces e possono essere a dimensione fissa o ad espansione dinamica.

Figura 1: Creazione dei VHD Set utilizzando i Cluster Shared Volumes (CSVs)

In alternativa è anche possibile salvarli in cartelle di rete ospitate da Scale-Out File Server che utilizzano il protocollo SMB 3.0

Figura 2: Salvataggio dei VHD Set in uno Scale Out File Server con SMB 3.0

Creazione di un VHD Set

Per creare un nuovo Shared Drive in Windows Server 2016 è sufficiente lanciare il wizard di creazione di un nuovo disco virtuale oppure modificare le impostazioni di una VM e creare il disco collegandolo al Controller SCSI. Gli Shared Drive infatti utilizzano SCSI-persistent reservations e vengono esposti alle VM come virtual disk SAS. Le SCSI-persistent reservations permettono alle diverse VM di coordinare l’ownership dello storage e quindi è possibile trasferire lo storage da un nodo all’altro, se uno dei due smette di funzionare.

Figura 3: Aggiunta di un nuovo Shared Drive alla VM

Figura 4: Wizard per la creazione del nuovo VHD Set

Figura 5: Creazione del disco virtuale condiviso all’interno di una cartella contenuta in un Cluster Shared Volume (CSV)

Figura 6: Scelta della dimensione dello Shared Drive

Terminato il wizard di creazione, potrete notare che nella cartella che avete scelto sono presenti due file, uno con estensione .VHDS (molto piccolo) che contiene i metadati necessari a permettere a tutte le VM che lo utilizzeranno di poter accedere contemporaneamente al disco virtuale e uno con estensione .AVHDX (Automatic VHDX) che conterrà i dati che saranno memorizzati dalle VM. Il file .AVHDX associato al file .VHDS è un hard disk virtuale (fisso o dinamico) gestito automaticamente. Se provate a rinominare il file .AVHDX in .VHDX (quando non è in uso) potrete anche collegarlo alla macchina Host e verificare che al suo interno ci sono i dati che avete memorizzato. ATTENZIONE: questa procedura non va fatta in produzione, ma solo in un ambiente di test al solo scopo di verifica.

Figura 7: File creati durante la creazione dello Shared Drive

È possibile aggiungere il disco virtuale creato anche alle altre VM, collegandolo al controller SCSI ed effettuando la ricerca del file .VHDS come mostrato in figura:

Figura 8: Aggiunta di un disco condiviso esistente ad una VM

Figura 9: Il disco condiviso viene correttamente collegato alla seconda VM

Il disco condiviso viene visto, come già scritto prima, come virtual disk SAS e può essere inizializzato e formattato dal sistema operativo della VM.

È anche possibile salvare i VHD Set all’interno di Scale-Out File Server cluster. Il wizard per la creazione del disco è identico, basta solo scegliere la condivisione di rete ospitata sullo Scale-Out File Server, come mostrato in figura:

Figura 10: Creazione del VHD Set in uno Scale-Out File Server cluster

Nel caso in cui cerchiate di salvare il file in una normale Share di rete invece che in uno Scale-Out File Server oppure all’interno di una cartella che non sia in un Cluster Shared Volume riceverete un messaggio di errore come quello in figura:

Figura 11: Errore nella creazione dello Share Drive a causa della posizione di salvataggio non supportata

Una valida alternativa all’interfaccia grafica è l’utilizzo dei comandi PowerShell. Per creare un VHD Set è infatti sufficiente utilizzare il comando:

New-VHD -path C:\ClusterStorage\VMs\SharedVHDX\Shared01.vhds -Dynamic -SizeBytes 500GB

Mentre per collegarlo alle VM è sufficiente utilizzare il comando:

Add-VMHardDiskDrive -VMName VM01 -ControllerNumber 0 -ControllerLocation 1 -Path C:\ClusterStorage\VMs\SharedVHDX\Shared01.vhd -ShareVirtualDisk

Add-VMHardDiskDrive -VMName VM02 -ControllerNumber 0 -ControllerLocation 1 -Path C:\ClusterStorage\VMs\SharedVHDX\Shared01.vhd -ShareVirtualDisk

Conclusioni

I VHD Set e gli Shared Drive semplificano di molto la creazione di Guest Cluster senza l’utilizzo di storage condiviso che richiederebbe configurazioni più complesse all’interno delle VM, come ad esempio connessioni iSCSI oppure l’utilizzo di Virtual Fiber Channel. In questo modo non siete più vincolati al tipo di storage e alla sua tecnologia e potete utilizzare dischi virtuali.

Introduzione

Spesso nei Datacenter il ruolo dei diversi amministratori è ben definito e le mansioni sono ben separate: ci sono gli Storage Administrator, i Network Administrator, i Backup Operator e i Virtualiztion-host Administrator. Ognuno di loro ha privilegi limitati quando lavora sui diversi server fisici. Nelle infrastrutture virtuali, in contrasto con quanto appena affermato, può capitare che spesso questi amministratori abbiano privilegi maggiori rispetto a quelli che gli dovrebbero essere permessi.

Scopo di questo articolo è mostrarvi come rendere più sicura l’infrastruttura virtuale e come creare un Guarded Fabric, cioè l’insieme degli host di virtualizzazione Hyper-V ed il loro Host Guardian Service (HGS), che può gestire e far girare macchine virtuali protette (Shielded VM)

Guarded Fabric

Con il rilascio di Windows Server 2016, Microsoft ha introdotto un nuovo modello di sicurezza per la virtualizzazione che è progettato per proteggere gli Hosts e le loro VM. Poiché una VM è un insieme di file, è necessario proteggerla da tutti quegli attacchi che possono avvenire via rete, sullo storage o mentre vengono salvate durante il backup. Questa è una necessità che prescinde dalla piattaforma di virtualizzazione utilizzata, sia che si tratti di Hyper-V, VMware o altre tecnologie di virtualizzazione. Se una macchina dovesse essere spostata fuori dall’azienda (sia accidentalmente che intenzionalmente), questa VM potrebbe essere eseguita in qualsiasi altro sistema non aziendale e quindi si potrebbe avere accesso ai dati contenuti nella VM.

Per proteggersi dalla possibilità che l’infrastruttura (Fabric) possa essere compromessa e si possa accedere ai file delle VM, Windows Server 2016 ha introdotto le Hyper-V Shielded VM, macchine virtuali (Generation 2) che hanno un virtual TPM (Trusted Platform Module), cifrate utilizzando Bitlocker Drive Encryption e che possono essere eseguite solo su alcuni Host di virtualizzazione approvati all’interno del Fabric.

Un Guarded Fabric è formato da un Host Guardian Service (HGS), che generalmente è un cluster a tre nodi, uno o più guarded hosts e una serie di Shielded VM. Vi consiglio prima di cominciare illaboratorio di dare un’occhiata all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2017/03/14/shielded-vms-a-conceptual-review-of-the-components-and-steps-necessary-to-deploy-a-guarded-fabric/

Attestation Modes nei Guarded Fabric

L’Host Guardian Service (HGS) supporta due tipi differenti di deployment (attestation modes) di un guarded fabric: TPM-Trusted Attestation (Hardware based) e Admin-Trusted Attestation (Active Directory based). Il TPM-Trusted Attestation è la modalità che offre la protezione migliore, ma richiede che gli Host Hyper-V utilizzino UEFI 2.3.1 e TPM 2.0. L’Admin-Trusted Attestation è pensato per supportare gli Host che non hanno un TPM 2.0. I Guarded Hosts che fanno girare le Shielded VM vengono approvati dall’HGS in base alla loro appartenenza a un gruppo di sicurezza di Active Directory.

Figura 1: Infrastruttura Guarded Fabric che utilizza Admin-Trusted Attestation (Active Directory based)

Host Guardian Service (HGS)

Il nuovo ruolo server HGS introdotto in Windows Server 2016 è composto dall’Attestation Service e dai Key Protection Services, che permettono ad Hyper v di far girare le Shielded VM. L’Attestation Service verifica l’identità e la configurazione dell’Host Hyper-V (Guarded Host) e il Key Protection Services (KPS) genera la transport key che è necessaria a sbloccare e a far girare le shielded VM. Le Shielded VM proteggono i dati delle macchine virtuali supportando il Virtual TPM che permette di abilitare Bitlocker Encryption sui dischi delle macchine virtuali.

Figura 2: Funzionamento dell’Host Guardian Service

Per i requisiti hardware e software di un server HGS si faccia riferimento all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs

Installazione del Server HGS

In questo articolo verrà mostrato come configurare un server HGS per supportare Admin-Trusted attestation.

Per installare il Server HGS (che nel mio caso è una macchina chiamata LON-SRV1 che è in workgroup) è sufficiente lanciare con privilegi elevati la cmdlet

Install-WindowsFeature –Name HostGuardianServiceRole –IncludeManagementTools –Restart

Figura 3: Schema di funzionamento del laboratorio

Dopo il riavvio, aprite un command prompt di PowerShell con privilegi elevati e digitate i seguenti comandi:

$adminPassword = ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

Install-HgsServer -HgsDomainName ‘contoso.com’ -SafeModeAdministratorPassword $adminPassword –Restart

Verrà a questo punto installato l’Host Guardian Service, che prevede l’installazione di una nuova foresta chiamata Contoso.com.

Figura 4: Installazione dell’Host Guardian Service, con relativa creazione del dominio

Figura 5: Installazione del Server HGS completata

NOTA: In ambiente di produzione, L’HGS dovrebbe essere installato in un cluster per assicurarsi che l’accesso alle Shielded VM sia mantenuto anche nel caso in cui uno dei nodi HGS non sia disponibile. Pertanto installate il ruolo Server HGS sul primo nodo, che sarà anche il domain controller del dominio HGS di gestione, e successivamente aggiungete gli altri nodi per dominio HGS esistente. Per aggiungere gli altri nodi al Cluster HGS seguite le istruzioni contenute nell’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-configure-additional-hgs-nodes

Guardian

Guardian è il termine che viene utilizzato per descrivere la copia di certificati (uno per il signing, l’altro per l’encryption) che protegge la chiave di cifratura simmetrica che viene utilzizata per cifrare il virtual TPM (vTMP) delle Shielded VM. I Guardians contengono solo le chiavi pubbliche, mentre le chiavi private vengono conservate dall’Host Guardian Service (HGS).

Dopo aver nuovamente riavviato il Server HGS, loggatevi come amministratore di dominio (contoso\administrator). Avete bisogno di due certificati per poter inizializzare il vostro server HGS: uno per la firma ed uno per la crittografia. Come prima operazione dovrete creare un certificato (signing.contoso.com) che utilizzerete per la firma. Da un prompt di PowerShell con privilegi elevati digitate i seguenti comandi:

md c:\HGS

$certificatePassword = ConvertTo-SecureString -AsPlainText ‘Pa55w.rd’ –Force

$signingCert = New-SelfSignedCertificate -DnsName “signing.contoso.com”

Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath ‘C:\HGS\signingCert.pfx’

Figura 6: Creazione ed esportazione del certificato per la firma completata

A questo punto create ed esportate il certificato che userete per la crittografia (encryption.contoso.com) utilizzando i seguenti comandi:

$encryptionCert = New-SelfSignedCertificate -DnsName “encryption.contoso.com”

Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath ‘C:\HGS\encryptionCert.pfx

Figura 7: Creazione ed esportazione del certificato per la cifratura completata

Per visualizzare i certificati appena creati potete utilizzare il comando certutil -viewstore “Shielded VM Local Certificates” oppure utilizzare una MMC vuota e lo snap-in dei certificati Computer, come mostrato in figura:

Figura 8: Visualizzazione dei certificati creati utilizzando il comando certutil

Figura 9 Visualizzazione dei certificati creati utilizzando lo snap-in dei certificati Computer

Inizializzazione dell’Host Guardian Service (HGS)

Il passaggio successivo consiste nell’inizializzazione del server HGS. Inizializzate il server HGS con la modalità Admin-Trusted attestation usando il comando PowerShell

Initialize-HGSServer -HgsServiceName ‘hgs’ -SigningCertificatePath ‘C:\HGS\signingCert.pfx’ -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath ‘C:\HGS\encryptionCert.pfx’ -EncryptionCertificatePassword $certificatePassword -TrustActiveDirectory

Figura 10: Inizializzazione del server HGS con la modalità Admin-trusted attestation

Terminata l’operazione di inizializzazione siete pronti ad utilizzare il vostro Server HGS! Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/en-us/windows-server/virtualization/guarded-fabric-shielded-vm/guarded-fabric-initialize-hgs-ad-mode-default

Per verificare che tutto sia stato configurato correttamente potete lanciare il comando PowerShell Get-HgsTrace -RunDiagnostics

Figura 11: Inizializzazione del server HGS completata correttamente

Creazione del trust tra il dominio HGS ed il dominio in cui sono attestati gli Host Hyper-V

Per poter utilizzare la Admin-Trusted attestation (Active directory based) è necessario creare un trust unidirezionale tra il dominio del Fabric (nel mio caso Adatum.com) ed il dominio HGS (nel mio caso Contoso.com).

Figura 12: Trust unidirezionale tra il dominio del Fabric (Adatum.com) ed il dominio HGS (Contoso.com)

Configurate il DNS sul LON-SVR1 in modo tale da creare un conditional forwarder che possa risolvere il dominio adatum.com e create un trust di foresta unidirezionale dal dominio HGS verso il dominio fabric utilizzando i due comandi:

Add-DnsServerConditionalForwarderZone -Name “adatum.com” -ReplicationScope “Forest” -MasterServers 172.16.0.10

netdom trust contoso.com /domain:adatum.com /userD:adatum.com\Administrator /passwordD:Pa55w.rd /add

Figura 13: Crazione del trust tra il dominio del fabric ed il dominio HGS

Configurazione del Fabric Domain Server

Aggiungete sul domain controller del fabric (adatum.com) un conditional forwarder che possa risolvere il dominio contoso.com utilizzando il comando PowerShell

Add-DnsServerConditionalForwarderZone -Name ‘contoso.com’ -ReplicationScope “Forest” -MasterServers 172.16.0.11

Create nel dominio Adatum.com un nuovo gruppo chiamato HGSHosts e inserite nel gruppo gli Host di virtualizzazione Hyper-V che ospiteranno le Shielded VM (nel mio caso ho aggiunto LON-HOST1).

Figura 14: Creazione del gruppo che conterrà gli Host di virtualizzazione

Verificate con il comando Get-ADGroup HGShosts qual è il SID del gruppo appena creato. Il SID verrà utilizzato per configurare poi sul Server HGS (LON-SVR1) l’Attestation Host Group ed individuerà tutti gli Host autorizzati a far girare le Shielded VM.

Figura 15: Verifica del gruppo appena creato

Spostatevi quindi sul computer LON-SVR1 e digitate il comando Add-HgsAttestationHostGroup -Name HGSHosts –Identifier <SID>, sostituendo il paramento <SID> con il valore del SID del gruppo che avete precedentemente visualizzato.

Figura 16: aggionta dell’Host Attestation Group al Server HGS

Lanciate il comando Get-HgsTrace -RunDiagnostics per verificare che tutto sia stato configurato correttamente e dopo qualche minuto ricevere lo status di Pass in verde, come mostrato in figura:

Figura 17: Verifica della configurazione del Server HGS

A questo punto avrete terminato la creazione del server HGS e la creazione di un Fabric Domain Server con un Attestation Host Group.

Configurazione dei server Hyper-V (Guarded Host)

Per configurare Hyper-V all’utilizzo di un server HGS e trasformarlo in un Guarded Host in modo tale che possa ospitare Shielded VM, è sufficiente aggiungere ad una macchina Windows Server 2016 il ruolo di Host Guardian Service, sia utilizzando PowerShell con il comando Install-WindowsFeature HostGuardian –IncludeManagementTools –Restart sia utilizzando l’interfaccia grafica di aggiunta e rimozione dei ruoli.

Figura 18: Aggiunta del Ruolo di Host Guardian Service

Figura 19: Installazione del ruolo di Host Guardian Service e di tutti i prerequisiti

Terminata l’installazione ed il successivo riavvio, possiamo configurare il nostro Host Hyper-V come client HGS (Guarded Host) utilizzando il comando PowerShell

Set-HgsClientConfiguration -AttestationServerUrl ‘http://LON-SVR1.Contoso.com/Attestation’ -KeyProtectionServerUrl ‘http://LON-SVR1.Contoso.com/KeyProtection’

Figura 20: Aggiunta del client HGS

È possibile visualizzare in qualsiasi momento la configurazione eseguendo la cmdlet Get-HgsClientConfiguration

Creazione di una Shielded VM

Per creare una Shielded VM è necessario creare una macchina virtuale Generation 2. Nel mio caso la macchina si chiamerà ShieldedVM01

Figura 21: Creazione di una nuova VM Generation 2

Terminata la creazione della macchina procedete all’installazione del Sistema operativo

Figura 22: Installazione del Sistema operativo

Terminata l’installazione della VM ricordatevi di abilitare il Desktop Remoto, in quanto dopo che avremo reso la VM “shielded” non sarà più possibile utilizzare la console di Hyper-V per potervi accedere.

Figura 23: Abilitazione del Desktop remoto nella VM da proteggere

A questo punto arrestate la macchina virtuale, che potrà essere protetta solo se è spenta.

Protezione della VM

Dall’Host di virtualizzazione LON-HOST1 collegatevi al Key Protection Web Service ospitato sul Server HGS (LON-SVR1) e salvate la configurazione localmente utilizzando il comando:

MD C:\HGS

Invoke-WebRequest http://LON-SVR1.contoso.com/Keyprotection/service/metadata/2014-07/metadata.xml -OutFile ‘C:\HGS\HGSGuardian.xml’

Rendete a questo punto LON-HOST1 un local HGS Guardian, utilizzando il file xml che avete generato, digitando il comando PowerShell

$Owner =  New-HgsGuardian –Name ‘Owner’ –GenerateCertificates

$Guardian = Import-HgsGuardian -Path ‘C:\HGS\HGSGuardian.xml’ -Name ‘TestFabric’ –AllowUntrustedRoot

Figura 24: Creazione dell’Host Guardian

Create un Key Protector, che definisce quale Fabric è autorizzato ad eseguire la macchina virtuale protetta con il comando:

# Creazione di un Key Portector, che stabilisce quale fabric potrà avviare la VM

$KP = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot

# Abilitazione dello shielding della VM

Set-VMKeyProtector –VMName ShieldedVM01 –KeyProtector $KP.RawData

Il passaggio finale consiste nell’abilitare la Security Policy sulla VM e di fatto trasformarla in una Shielded VM.

# Configura la policy di sicurezza della VM

Set-VMSecurityPolicy -VMName ShieldedVM01 -Shielded $true

Figura 25: Configurazione della VM e trasformazione in una Shielded VM

Per abilitare il virtual TPM sulla macchina virtuale è invece sufficiente eseguire il comando Enable-VMTPM -VMName ShieldedVM01.

Adesso la macchina virtuale ShieldedVM01 può essere avviata e se aprite il Virtual Machine Connector riceverete una schermata come quella mostrata in figura, che vi avvisa che d’ora in poi potrete connettervi alla VM utilizzando solo il Desktop remoto.

Figura 26: La connessione in console è proibita sulle Shielded VM

Da questo momento la macchina è protetta e potrà essere eseguita solo sugli Host autorizzati. Infatti se provate ad avviare la macchina su un Host non autorizzato riceverete il seguente messaggio di errore:

Figura 27: Esecuzione di una Shielded VM su un Host non autorizzato e relativo messaggio di errore

Se provate a montare il disco di una VM che è stata protetta riceverete invece il seguente messaggio di errore

Figura 28: Il tentativo di montare il VHD di una Shielded VM fallisce con un errore

Shielded VM in Windows 10 Client Hyper-V

Da Windows 10, versione 1709, anche Client Hyper-V può ospitare le Shielded VM utilizzando l’Attestation con un Server HGS remoto, mentre prima di questa versione era possibile farlo solo utilizzando il local mode, cioè facendo in modo che le encryption key del vTPM venissero salvate localmente. Per approfondimenti vi rimando all’articolo https://blogs.technet.microsoft.com/datacentersecurity/2018/01/05/shielded-vm-local-mode-and-hgs-mode/

Conclusioni

Windows Server 2016 è la versione più sicura tra i sistemi operativi server rilasciati da Microsoft e nell’era dell’Hybrid Cloud la sicurezza rappresenta la sfida maggiore proprio per la natura distribuita dei worloads su diverse piattaforme. Host Guardian Service e le Hyper-V Shielded VM rappresentano un’ottima soluzione per proteggere le macchine virtuali dagli attacchi esterni e dagli accessi non autorizzati da parte degli Hyper-V Administrators.

Mai come in questo periodo il tema della sicurezza informatica sta monopolizzando gli articoli e gli avvisi che ci arrivano dai diversi vendor hardware e software e gli attacchi si stanno non solo evolvendo come complessità, ma soprattutto stanno aumentando. Difendersi dagli attacchi è sempre impegnativo e non bisogna mai sottovalutare nulla, ma io sono dell’idea che prevenire sia meglio che curare e quindi nell’approccio alla sicurezza la cosa più importante è ridurre la superficie di attacco.

Avevo già parlato in un precedente articolo di una funzionalità di sicurezza introdotta in Windows Server 2016 e chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server. In questo articolo invece vi parlo di una funzionalità di Microsoft Azure, attualmente in PREVIEW e che si chiama Just in time VM Access, che può essere usata per bloccare il traffico in ingresso verso le porte dei protocolli di amministrazione (RDP per Windows oppure SSH per Linux) delle macchine virtuali di Azure, riducendo l’esposizione agli attacchi.

Figura 1: Attivazione della funzionalità di Just in time VM Access in Azure Security Center

Questo tipo di funzionalità non è pero disponibile gratuitamente e fa parte del piano Standard del Centro Sicurezza di Azure (Security Center), che offre la gestione unificata della sicurezza e la protezione avanzata dalle minacce per tutti i workload in esecuzione in Azure, in locale nella propria rete aziendale e in altri cloud. È possibile aggiornare tutta la sottoscrizione di Azure al piano Standard, che viene ereditato da tutte le risorse all’interno della sottoscrizione oppure è possibile aggiornare a un solo gruppo specifico di risorse (Resource Group). Per poterlo fare è sufficiente modificare la Security Policy del Security Center come mostrato in figura:

Figura 2: Modifica delle Security Policy e del Pricing Tier in Azure Security Center

Nel momento in cui attivate la funzionalità di Just in time VM Access, Il Security Center protegge il traffico in ingresso verso le macchine virtuali creando una regola nel Network Security Group (NSG) utilizzato dalle schede di rete della VM, che blocca le porte di gestione. Quando avrete necessità di accedere in modalità amministrativa alla VM, vi basterà richiedere l’accesso e indicare per quanto tempo necessitate di amministrare la macchina. Il Security Center provvederà a modificare le regole sul Netowrk Security Group consentendo il traffico in entrata verso le porte di gestione per il periodo di tempo specificato. Al termine di questo periodo, il Security Center ripristinerà le regole preesistenti.

Attivazione del Just in time VM Access

La prima volta che vorrete usare la funzionalità di Just in time VM Access vi verrà chiesto di attivare (in prova gratuita per i primi 60 giorni) il piano Standard, come mostrato in figura:

Figura 3: Attivazione del Piano Standard per Azure Security Center

Una volta che avrete attivato il piano Standard potrete tornare nella console del Just in time VM access e visualizzare le informazioni per ogni macchina virtuale, divise in 3 categorie:

• Configured – Macchine virtuali che sono state configurate per supportare l’accesso Just-In-Time. I dati visualizzati sono relativi all’ultima settimana e includono, per ogni macchina virtuale, il numero di richieste approvate, la data dell’ultimo accesso e l’ultimo utente che ha effettuato l’accesso.
• Recommended – Macchine virtuali che possono supportare l’accesso Just-In-Time, ma che non sono state ancora configurate.
• No Recommandation – I motivi per cui una macchina virtuale può risultare non raccomandata sono:
  • Network Security Group mancante – La soluzione Just-In-Time richiede la presenza di un gruppo di sicurezza di rete.
  • Macchina virtuale classica – L’accesso Just-in-Time alle macchine virtuali attualmente supporta solo VM distribuite tramite Azure Resource Manager.
  • Endpoint Protection non installato – Il Centro sicurezza di Azure monitora lo stato della protezione antimalware e verifica che nella VM sia installato Endpoint Protection

Figura 4: Macchine virtuali su cui non può essere abilitata il Just in time VM access

Per abilitare la funzionalità è sufficiente selezionare la VM, cliccare sul pulsante Enable JIT on VM e nel blade che si apre cliccare su Save, come mostrato in figura:

Figura 5: Abilitazione della funzionalità di Just in time VM access

Richiedere l’accesso a una macchina virtuale

Per richiedere l’accesso ad una macchina virtuale è sufficiente selezionare la VM nella scheda Configured e cliccare sul pulsante Request Access. Nel blade che verrà aperto definite quale porta aprire, a quali indirizzi IP permettere la connessione, per quanto tempo permettere la connessione. Al termine della scelta dei criteri cliccate sul pulsante Open Ports, come mostrato in figura:

Figura 6: richiesta di apertura delle porte di amministrazione

In qualsiasi momento potete modificare la configurazione dell’accesso JIT alla VM, visualizzarne le proprietà e i log delle attività, come mostrato in figura:

Figura 7: Modifica della configurazione dell’accesso JIT alla VM

È sempre possibile aggiungere altre porte alla configurazione dell’accesso JIT alla VM e per ognuna di loro stabilirne anche la durata, che in ogni caso non potrà superare le 24 ore.

Figura 8: Aggiunta di una nuova regola alla configurazione dell’accesso JIT alla VM

Visualizzando la scheda Networking della macchina virtuale potrete visualizzare quali regole sono state applicate al Network Security Group della VM. Sono state inserire le regole di SecurityCenter-JIT che hanno una priorità più bassa e quindi hanno precedenza rispetto alle altre regole create.

Figura 9: Regole di SecurityCenter-JIT applicate al Network Security Group della VM

Conclusioni

La semplicità con cui è possibile configurare l’accesso Just in Time alle VM di Azure permette di poter ridurre drasticamente la superfice d’attacco verso le VM esposte, come ad esempio le Jump Box con IP pubblico, ed impedisce di fatto tutti gli attacchi verso il Desktop Remoto o verso Secure Shell che cercano di indovinare le credenziali amministrative. Un modo semplice ed efficace per proteggerci e per mitigare gli attacchi di forza bruta aprendo le porte solo durante la connessione per eseguire attività di gestione o manutenzione sulle VM.

Azure Site Recovery è un servizio che permette di proteggere le nostre macchine virtuali automatizzandone la replica verso il Cloud. Le macchine che possono essere protette da Azure Site Recovery (ASR) possono essere fisiche, macchine virtuali VMware oppure macchine virtuali Hyper-V. Il compito di ASR è quello di coordinare e gestire la replica continua dei dati e automatizzare il ripristino dei servizi nel caso di un’interruzione nel data center primario.

Abbiamo visto nel precedente articolo Migrazione delle macchine virtuali VMware verso Microsoft Azure con l’utilizzo di Azure Migrate come il servizio Azure Migrate semplifica la migrazione delle macchine virtuali VMware vSphere verso il cloud Microsoft Azure e può fornirvi assistenza attraverso tutti passaggi necessari per poterla effettuare, dall’assessment alla migrazione vera e propria. Compito di questo articolo sarà quello di mostrarvi il passaggio successivo al discovery e all’assessment, cioè la migrazione vera e propria delle VM.

Utilizzeremo quindi Azure Site Recovery per migrare le nostre macchine virtuali VMware verso Azure.

Figura 1: Architettura della migrazione da VMware ad Azure

Figura 2: Processo di replica di macchine VMware verso Azure

Creazione del Recovery Service Vault

Il Recovery Service Vault è un’entità di archiviazione di Azure che ospita i dati e le configurazioni delle macchine virtuali. Per maggiori informazioni potete leggere l’articolo https://docs.microsoft.com/it-it/azure/backup/backup-azure-recovery-services-vault-overview

Per creare un nuovo Recovery Service Vault è sufficiente aprire il portale di Azure e, facendo clic su New, cercare Backup and Site Recovery (OMS). Inserite quindi il nome del vostro Vault, il Resource group da utilizzare e la location dove volete che venga creato, come mostrato in figura:

Figura 3: Creazione di n nuovo Azure Recovery Service Vault

Al termine della creazione del Vault vi apparirà la schermata mostrata in figura:

Figura 4: Creazione del Vault completata

Cliccate su Site
Recovery e successivamente su Prepare Infrastructure, indicando come primo passaggio qual è il vostro Protection Goal. Nel mio caso, voglio proteggere alcune macchine virtuali VMware in Azure.

Figura 5: Creazione del Protection Goal

Nel secondo passaggio vi verrà chiesto di scaricare e testare il Deployment Planner, che verificherà che abbiate banda a sufficienza e quanto storage servirà per soddisfare le vostre necessità. Questo strumento consente di profilare le virtual machine VMware senza alcun impatto sulla produzione e di determinare i requisiti di larghezza di banda e archiviazione di Azure per operazioni di replica e failover. Vi consiglio di approfondire questo argomento leggendo l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-deployment-planner

Figura 6: Deployment Planning

Installazione del Configuration Server

Il terzo passaggio consiste nel dichiarare quale Configuration Server volete utilizzare in Site Recovery. Il Configuration Server funge da coordinatore tra i servizi di Site Recovery e l’infrastruttura locale (on-premises). Per i requisiti hardware e software del Configuration Server vi rimando all’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server. Provvedete a scaricare la virtual appliance del server di configurazione (sono circa 16,5 GB) e ad importarla nella vostra infrastruttura VMware. Seguite tutte le istruzioni indicate nel blade del portale Azure:

Figura 7: Download della virtual appliance del Configuration Server

Figura 8: importazione della virtual appliance del Configuration Server

Dopo aver avviato il Configuration Server e configurato un account amministrativo, la virtual appliance verificherà la presenza della connessione Internet e vi chiederà di loggarvi con le credenziali per amministrare il Tenant Azure.

Figura 9: Connessione al Tenant di Azure

Dopo pochi minuti, il server si configurerà in Azure Active Directory e sarà necessario il riavvio della VM.

Figura 10: Configurazione del Server in Azure Active Directory

Dopo il riavvio potete loggarvi alla macchina ed in automatico vi si aprirà una pagina web per la gestione del Configuration Server. Nel caso non dovesse aprirsi, potete utilizzare il collegamento presente sul Desktop. Seguite le istruzioni riportate nella pagina web e configurate la scheda di rete che volete utilizzare per collegarvi ad Azure. Subito dopo vi verrà chiesto di selezionare il Recovery Services Vault da utilizzare.

Figura 11: Selezione del Recovery Services Vault

Il passaggio successivo consiste nell’installazione del software MySQL Community Server e VMware PowerCLI. Procedete all’installazione dei due software e confermate cliccando sul pulsante Continue.

Figura 12: Installazione del software aggiuntivo MySQL e PowerCLI

A questo punto l’appliance verifica che le proprie configurazioni siano corrette (spazio libero sul disco, IP statico, memoria del sistema, ecc.), come mostrato in figura:

Figura 13: Verifica della configurazione della virtual appliance

Per poter effettuare la connessione al vCenter è necessario fornire le credenziali di accesso, che dovrete aggiungere a questo punto della configurazione, come mostrato in figura:

Figura 14: Aggiunta delle credenziali di accesso al vCenter

Per installare Azure Site Recovery mobility service all’interno delle VM è necessario fornire delle credenziali amministrative. Il servizio mobility di Azure Site Recovery acquisisce i dati da una macchina virtuale VMware o da un server fisico e le inoltra al Process Server (che è installato nella stessa macchina del Configuration Server). Per maggior informazioni su questo servizio vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc

Figura 15: Inserimento delle credenziali amministrative delle VM da proteggere

A questo punto non resta altro da fare che cliccare sul pulsante Finalize configuration. La configurazione dura alcuni minuti.

Figura 16: Configurazione del server completata

Completamento della preparazione dell’infrastruttura

Tornate nel pannello di Microsoft Azure Site Recovery e continuate la configurazione del Source. Vi appariranno sia il Configuration Server che avete appena installato e configurato, sia il vCenter che avete indicato nel wizard di configurazione, come mostrato in figura:

Figura 17: Selezione del Configuration Server e del vCenter

Il passaggio 4 consiste nel configurare il Target, cioè lo Storage Account dove volete replicare le VM e la Network a cui volete collegarle. È possibile anche creare di nuovi, se quelli già esistenti non soddisfano le vostre esigenze.

Figura 18: Preparazione del Target

Completate la parte di preparazione dell’infrastruttura creando una nuova Replication policy e associandola al vostro Configuration Server. La Replication Policy stabilisce la frequenza di replica delle vostre VM on-premises. Maggiori informazioni sono disponibili al link https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-setup-replication-settings-vmware

Figura 19: Creazione ed associazione delle Replication Policy

Dopo pochi minuti, vedrete apparire nel portale di Azure le diverse policy che vengono create. Terminate la configurazione cliccando su OK.

Figura 20: Preparazione dell’infrastruttura completata

Abilitare la replica delle VM

Per abilitare la replica delle VM è sufficiente fare clic su Step1: Replicate Application e seguire le indicazioni contenute nel blade che si aprirà. Configurate come prima cosa il Source Environment, completando le informazioni come mostrato in figura:

Figura 21: Definizione del Source Environment

Nel Target Setting for Recovery inserite la sottoscrizione da utilizzare, lo storage account in cui inserire le VM replicate, la virtual network da utilizzare e gli altri parametri richiesti.

Figura 22: Configurazione dei Target Settings per la replica delle VM

Selezionate nel passaggio 3 le macchine virtuali on-premises da replicare, come mostrato in figura:

Figura 23: Selezione delle VM da replicare

Indicate quali credenziali utilizzare per l’installazione degli agent di Azure e, se la VM ha più dischi, decidete quali dischi escludere dalla replica.

Figura 24: Configurazione delle proprietà delle VM

Terminate a questo punto l’abilitazione della replica configurando nell’ultimo passaggio la Replication Policy da utilizzare e scegliendo se volete raggruppare le macchine, in modo tale che vengano replicate tutte insieme, per assicurare la consistenza delle applicazioni nel caso in cui queste utilizzino macchine diverse. Nel mio caso ho una webapp che usa due webserver di frontend ed un database server di backend e quindi voglio che siano replicati insieme verso Azure.

Figura 25: Configurazione del Replication Settings e dei Replication Groups

Non vi resta a questo punto che monitorare la prima replica delle vostre VM on-premises. Selezionate il nodo Replicated Items dal portale di Azure e controllate lo stato di sincronizzazione delle macchine virtuali.

Figura 26: Monitoraggio delle repliche delle VM

Nel caso di errori cliccate sulla VM e cercate di individuarne i motivi. Nella schermata sotto è indicato uno dei probabili avvisi o errori che vi possono apparire:

Figura 27: Warning sulla Replica di una VM

Creazione del Recovery Plan

Il Recovery Plan (o piano di ripristino) permette di stabilire quali macchine devono essere avviate ed in quale ordine. Cliccate su Step 2: Recovery Plans e aggiungetene uno nuovo, configurandolo con i parametri richiesti:

Figura 28: Creazione di un Recovery Plan

Una volta che il Recovery Plan è stato creato potete personalizzarlo a vostro piacimento, raggruppando le macchine virtuali da avviare insieme, come mostrato in figura:

Figura 29: Personalizzazione del Recovery Plan

Test del Failover

Una volta che avete terminato la replica di tutte le macchine virtuali potrete provare a testare il Failover delle VM in Azure. Cliccando su Overview nel Recovery Service Vault dal portale di Azure, potrete avere un’idea di come sia configurata la vostra infrastruttura e informazioni sullo stato di replica delle vostre VM.

Figura 30: Overview della vostra infrastruttura di replica in Azure

Cliccate sul vostro Recovery Plan e successivamente sul pulsante Test failover. Dal blade che vi si aprirà scegliete il Recovery Point da testare e scegliete la virtual network Azure a cui collegare le VM di test che verranno create. Vi consiglio di utilizzare una VNET di test, in modo tale da non avere problemi.

Figura 31: Failover Test del Recovery Plan

A questo punto verranno create delle macchine di test nel vostro Tenant Azure. Collegatevi alle macchine in Desktop remoto e verificate che tutto funzioni correttamente.

Figura 32: Failover test avviato per il Recovery Plan scelto

Figura 33: Site recovery job e dettagli delle operazioni

Al termine di tutte le procedure di controllo, sarà possibile effettuare il Cleanup test failover, che distruggerà tutte le VM Azure di test che sono state create.

Figura 34: Lancio del Cleanup test failover

Figura 35: Dettaglio delle operazioni del Cleanup test failover

A questo punto avete completato tutte le operazioni per la protezione delle VM on-premises in Azure. Con questo tipo di configurazione Azure è diventato il vostro sito di Disaster Recovery e lo potrete utilizzare nel caso non sia possibile utilizzare il Datacenter principale.

Migrazione

Se il vostro obiettivo è invece migrare le macchine VMware on-premises, allora basterà dichiarare il Failover e lasciare che le macchine vengano avviate in Azure. Prima di effettuare questa operazione assicuratevi che ogni macchina sia configurata con le dimensioni corrette, con la VNET corretta e, nel caso ne abbiate i diritti, attivate l’Hybrid Use Benefit, che vi permette un risparmio considerevole sulle licenze del sistema operativo.

Figura 36: Configurazione di ogni singola macchina virtuale

Cliccate sul vostro Recovery Plan e dichiarate il Failover, come mostrato in figura:

Figura 37: Failover dei Recovery Plan

Scegliete il Recovery Point da utilizzare per il Failover e, nel caso, selezionate la casella per spegnere le macchine virtuali on-premise prima del Failover, in modo tale da avere una situazione consistente. Se scegliete Latest (lowest RPO) verrà scelto il Recovery Point più recente e verranno sincronizzate le ultime modifiche apportate alla VM on-premises.

Figura 38: Scelta del Recovery Point del Failover

Il processo di Failover creerà le nuove macchine virtuali nel vostro tenant Azure, secondo le caratteristiche che avete definito precedentemente.

Figura 39: Esecuzione del Failover e dettaglio delle operazioni

Terminate tutte le operazioni, le macchine virtuali saranno create nel vostro Tenant Azure e saranno visibili nel Resource Group di destinazione che avete scelto.

Figura 40: Macchine virtuali accese nel Resource Group di Azure di destinazione

Effettuate l’ultima operazione, che consiste nell’eseguire, per ogni singola VM, il Complete Migration. Nella finestra che vi si aprirà confermate con OK. Dopo alcuni minuti la migrazione sarà terminata!

Figura 41: Esecuzione del comando Complete migration su ogni VM

Figura 42: Conferma della migrazione per ogni singola VM da migrare ad Azure

NOTA: la macchina virtuale in Azure avrà un indirizzo IP dinamico nella VNET che avete scelto. Assicuratevi, nel caso ne abbiate bisogno, di mettere un indirizzo IP statico. Per maggiori informazioni sulla procedura corretta vi rimando all’articolo https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-network-interface-addresses

Per completare la migrazione potete cancellare il Recovery Service Vault. Seguire tutte le indicazioni contenute nell’articolo https://docs.microsoft.com/en-us/azure/site-recovery/delete-vault

Figura 43: Cancellazione dell’Azure Recovery Vault

Conclusioni

Azure Site Recovery è sicuramente uno strumento potente per effettuare il Disaster Recovery delle nostre macchine virtuali VMware o dei nostri server fisici e può essere facilmente utilizzato per poter effettuare una migrazione verso il cloud Azure. Microsoft si è impegnata molto per fornire alle aziende strumenti utili a valutare la migrazione delle VM on-premises con lo strumento Azure Migrate https://www.ictpower.it/sistemi-operativi/migrazione-delle-macchine-virtuali-vmware-verso-microsoft-azure-con-lutilizzo-di-azure-migrate.htm e offrire la possibilità di migrarle facilmente con Azure Site Recovery.

Anche se ormai gran parte delle nostre infrastrutture sono virtualizzate, potrebbe capitare che in alcune aziende ci siano ancora delle macchine fisiche. Azure Site Recovery è una funzionalità offerta da Microsoft Azure per poter effettuare il disaster recovery dei nostri server fisici oppure per poterli definitivamente migrare verso il Cloud.

In questo articolo ci occuperemo della migrazione dei server fisici, ma se siete interessati alla migrazione di macchine virtuali vi invito a leggere l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-di-macchine-virtuali-vmware-verso-microsoft-azure-con-azure-site-recovery.htm e l’articolo https://www.ictpower.it/sistemi-operativi/migrazione-delle-macchine-virtuali-vmware-verso-microsoft-azure-con-lutilizzo-di-azure-migrate.htm

Per eseguire la migrazione di un server fisico è necessario abilitare la replica del server ed eseguirne il failover in Azure.

Creazione del Recovery Service Vault

Il Recovery Service Vault è un servizio di Azure che ospita i dati e le configurazioni delle macchine virtuali. Per sapere nel dettaglio le caratteristiche del servizio potete leggere l’articolo https://docs.microsoft.com/it-it/azure/backup/backup-azure-recovery-services-vault-overview

Per creare un nuovo Recovery Service Vault è sufficiente aprire il portale di Azure e, facendo clic su New, cercare Backup and Site Recovery (OMS). Inserite quindi il nome del vostro Vault, il Resource group da utilizzare e la location dove volete che venga creato, come mostrato in figura:

Figura 1: Creazione di un nuovo Azure Recovery Vault

Terminata la creazione del Vault ne potete visualizzare le caratteristiche utilizzando la scheda Overview. Cliccate sulla scheda Site Recovery e iniziate la preparazione dell’infrastruttura, indicando cosa volete proteggere (Protection Goal). Nel mio caso, visto che voglio proteggere delle macchine fisiche on-premises, ho dichiarato che le macchine non sono virtualizzate, come indicato in figura:

Figura 2: Preparazione del Protection Goal

Nel secondo passaggio vi verrà chiesto di scaricare e testare il Deployment Planner, uno strumento gratuito che vi consente di profilare i vostri server fisici senza alcun impatto sulla produzione e di determinare i requisiti di larghezza di banda e spazio di archiviazione di Azure per le operazioni di replica e failover. Vi consiglio di leggere l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-deployment-planner per conoscere le potenzialità di questo strumento.

Figura 3: Deployment Planning

Nel passaggio successivo dovrete selezionare il Configuration Server da utilizzare per la replica dei dati della vostra macchina fisica. Il Configuration Server funge da coordinatore tra i servizi di Site Recovery e l’infrastruttura locale (on-premises). Per i requisiti hardware e software del Configuration Server vi rimando all’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server. Provvedete a scaricare il Microsoft Azure Site Recovery Unified Setup (sono circa 1,5 GB) e ad installarlo nella vostra infrastruttura in una macchina Windows Server 2012 R2 (va bene anche la versione Evaluation e la macchina può essere anche in workgroup). Seguite tutte le istruzioni indicate nel blade del portale Azure, come mostrato in figura:

Figura 4: Aggiunta del Configuration Server e procedura di installazione

Installazione di Microsoft Azure Site Recovery Unified Setup

L’installazione del software che provvederà a creare il nostro Configuration Server è molto semplice ed è descritta nelle immagini che seguono. Assicuratevi di rispettare i Requisiti di dimensione per un server di configurazione e, dopo aver installato un server con Windows Server 2012 R2, dategli un IP statico e lanciate il setup di configurazione.

Figura 5: Prima schermata di installazione del Configuration Server

Figura 6: Inserimento della Site Recovery Registration Key che avete precedentemente scaricato dal portale di Azure

Figura 7: Verifica dei prerequisiti per l’installazione del Configuration Server

Figura 8: Inserimento della password di root e di svsystems user per il database MySQL

Figura 9: Indicazione che vogliamo proteggere server fisici e non macchine virtuali

Figura 10: Schermata riassuntiva del Setup del Configuration Server

Figura 11: Installazione del Configuration Server completata

A questo punto vi verrà chiesto di riavviare. Terminato il riavvio del server, subito dopo il login, vi apparirà il messaggio che vi indica quale sarà la passphrase da utilizzare per collegare l’agent del Mobility Service al vostro Configuration Server. Il Mobility Service è un servizio che si occupa di trasferire i file generati dal vostro server fisico verso il Configuration Server, che si occuperà poi di inoltrarli Ad Azure Site Recovery. Salvate la passphrase in un file di testo, perché potrebbe esservi richiesta se vorrete installare manualmente l’agent di Azure Site Recovery Mobility Service. In ogni caso è sempre possibile rigenerarla seguendo le indicazioni contenute nell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server

Figura 12: Passpharse per il collegamento degli agent di Azure Site Recovery al Connection Server

Lanciate dal Desktop il collegamento al Cspsconfigtool, che vi darà la possibilità di aggiungere le credenziali per installare il Mobility Service sulle vostre macchine fisiche. Esistono diverse modalità di installazione di questo servizio e per approfondimenti vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc

Figura 13: Aggiunta dell’account necessario all’installazione del Mobility Service sulle macchine fisiche

Terminata l’installazione del Configuration Server potete tornare nel portale Azure e dal blade dello Step 3 adesso sarà possibile selezionare il server appena installato, come mostrato in figura:

Figura 14: Selezione del Connection Server appena installato

Proseguite con lo Step 4, indicando la Subscription Azure da utilizzare, il Deployment model e assicurandovi di avere uno storage account ed una virtual network dove migrare i vostri server fisici on-premises.

Figura 15: Individuazione del target Azure dove replicare le macchine fisiche on-premises

L’ultimo passaggio di preparazione dell’infrastruttura consiste nella creazione di una Replication Policy da associare al vostro Configuration Server. La Replication Policy stabilisce la frequenza di replica delle vostre macchine fisiche on-premises. Maggiori informazioni sono disponibili al link https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-setup-replication-settings-vmware

Figura 16: Creazione di una Replication Policy da associare al Configuration Server

Verranno create ed associate due Replication Policy: una per il Failover ed un’altra per il Failback, come mostrato in figura:

Figura 17: Creazione ed associazione delle Replication Policy

Completate la preparazione della vostra infrastruttura facendo clic sul pulsante OK.

Figura 18: Completamento della preparazione dell’infrastruttura

Replica dei server fisici

Per dichiarare quali sono i server fisici da replicare con Azure Site Recovery fate clic sulla scheda Step 1: Replicate Application e configurate il Source con i parametri inseriti in figura:

Figura 19: Configurazione del Source per la Replica

Configurate nel secondo passaggio il Target del Recovery, in particolar modo indicando lo Storage Account dove verranno salvati i dati dei server fisici e la rete virtuale dove collegare le macchine replicate in Azure.

Figura 20: Configurazione del Target in Azure Site Recovery

Nel terzo passaggio indicate quali sono i server fisici da replicare in Azure, indicando un nome, l’indirizzo IP e il tipo di sistema operativo, come mostrato in figura:

Figura 21: Scelta dei server fisici da replicare in Azure

Figura 22: Aggiunta dei server fisici da replicare in Azure

Dichiarate quale sarà l’account (che avete precedentemente creato sul Configuration Server) da utilizzare per l’installazione dell’agent di Mobility Service sulle macchine fisiche, e quali dischi del server fisico volete escludere dalla replica, come mostrato in figura:

Figura 23: Configurazione delle proprietà della replica, scelta dell’account per l’installazione del Mobility Service

L’ultimo passaggio vi chiede di confermare quale Replication Policy utilizzare per la replica dei server fisici scelti.

Figura 24: Replication Policy da utilizzare per la replica dei server fisici scelti

Completate lo Step 1: Replicate Application cliccando sul pulsante Enable Replication.

Figura 25; Completamento dello Step 1: Replicate Application e abilitazione della replica

Lo Step 2: Manage Recovery Plans consiste nella creazione di un Recovery Plan (o piano di ripristino), che permette di stabilire quali macchine devono essere avviate ed in quale ordine. Aggiungetene un nuovo Recovery Plan e configuratelo con i parametri richiesti, come mostrato in figura:

Figura 26: Creazione di un nuovo Recovery Plan

A questo punto il Configuration Server installerà il Mobility Service sui server fisici che avete deciso di migrare e abiliterà la replica della macchina. Potete anche installare manualmente il Mobility Service usando la procedura indicata dall’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc#install-mobility-service-manually-by-using-the-gui. Il file di installazione dell’agent si trova nel percorso C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository del Configuration Server.

Figura 27: Abilitazione della replica

Dopo circa 20 minuti dall’abilitazione, inizierà la replica dei dati verso Azure Site Recovery. Attendete che tutti i dati siano stati replicati visualizzando la scheda Replicated Items del vostro Azure Site Recovery Vault.

Figura 28: replica dei dati del server fisico completata

Failover Test

Per verificare che tutto funzioni correttamente è necessario testare il Failover della macchina virtuale presente in Azure. Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure, selezionate la macchina virtuale da testare e dal menù scegliete Test Failover, come mostrato in figura:

Figura 29: Test failover della macchina virtuale in Azure

Nel blade che vi si aprirà scegliete il Recovery Point da testare e la rete virtuale a cui collegare la VM di test. Cliccate su OK e attendete alcuni minuti fino a quando la VM di test non sarà stata creata.

Figura 30: Scelta del Recovery Point e della rete virtuale per il test del Failover

Collegatevi alla VM di test che è stata creata in Azure ed effettuate tutte le verifiche che ritenete necessarie per assicurarvi che la vostra macchina abbia tutti i dati e che funzioni correttamente. Al termine di tutte le procedure di controllo, sarà possibile effettuare il Cleanup test failover, che distruggerà la VM Azure di test che è stata creata.

Figura 31: Test failover Cleanup

Cliccando su Replicated Items nel Recovery Service Vault dal portale di Azure è possibile configurare le proprietà della macchina replicata. Potete scegliere il nome che verrà visualizzato in Azure, il Resource Group dove metterla, la dimensione della VM, la virtual network ed anche dargli un IP statico. Nel caso ne abbiate i diritti, attivate l’Hybrid Use Benefit, che vi permette un risparmio considerevole sulle licenze del sistema operativo. Maggiori informazioni sull’Hybrid Use benefit le trovate leggendo l’articolo https://docs.microsoft.com/it-it/azure/virtual-machines/windows/hybrid-use-benefit-licensing

Figura 32: Configurazione dei parametri della VM

Migrazione della macchina fisica in Azure

Per completare la migrazione della macchina fisica è necessario effettuare due passaggi: Failover e Complete Migration. Prima di eseguire un failover, eseguite sempre un failover di test per verificare che tutto funzioni come previsto. Maggiori dettagli sono disponibili leggendo l’articolo https://docs.microsoft.com/it-it/azure/site-recovery/site-recovery-failover

Figura 33: Failover della macchina fisica

Terminata la procedura di Failover ed dopo esservi accertati che tutto funzioni perfettamente, potete effettuare la procedura di Complete Migration. Il processo di migrazione viene completato, viene arrestata la replica della macchina virtuale e viene arrestata la fatturazione di Site Recovery per la macchina virtuale. D’ora in poi pagherete però l’esecuzione delle VM in Azure.

Figura 34: Completamento della migrazione

Conclusioni

Migrare i server fisici verso Azure è un’operazione molto semplice se viene effettuata con Azure Site Recovery. Per eseguire la migrazione di un server è sufficiente abilitare la replica del server ed eseguirne il failover in Azure. In questo modo l’intera macchina, con tutti i dati, viene migrata con un minimo downtime e senza impatto sull’infrastruttura e sulla produzione. Migrare i server fisici verso il Cloud non è mai stato così facile!

E’ passato più di un anno e mezzo da quando il progetto PowerShell 6 è arrivato su GitHub (https://github.com/powershell/powershell). Per la prima volta PowerShell non è solo OpenSource, ma addirittura Cross-Platform. La nuova shell, con l’obiettivo principale di creare un ambiente leggero mantenendo una buona compatibilità con le versioni precedenti, è ormai stata rilasciata in versione stabile su una moltitudine di sistemi operativi. E’ infatti possibile installare la nuova release su tutti i sistemi operativi Windows client a partire da Windows 7 e su Windows Server a partire da 2008 R2, oltre che su molteplici distribuzioni Linux (CentOS, RedHat. Debian, Fedora, OpenSuse) ed addirittura MacOS dalla versione 10.12.

L’installazione è molto semplice e va effettuata a partire dal Setup scaricato direttamente dalla pagina download del progetto (https://github.com/PowerShell/PowerShell/releases), selezionando la versione relativa al proprio sistema operativo. Il setup della versione per Windows x64 ha una dimensione di circa 50MB.

Dopo aver accettato le condizioni e confermato il path per l’installazione possiamo aprire PowerShell 6 mettendo un segno di spunta su “Launch PowerShell”

Per avviare PowerShell successivamente è possibile richiamare pwsh.exe dal prompt dei comandi se siamo su Windows, o avviare pwsh se siamo su Linux o MacOS.

Come possiamo notare stiamo utilizzando l’edizione Core di PowerShell 6, che come abbiamo anticipato è molto leggera ed ha caratteristiche di compatibilità elevate, ma non è possibile utilizzare gli stessi CmdLet dell’edizione Desktop. E’ importante notare che le due edizioni possono coesistere su uno stesso sistema. Se proviamo ad eseguire sulla stessa macchina il comando powershell vediamo che è possibile utilizzare la PowerShell completa.

Potrebbe capitare di leggere della documentazione su questi due componenti, e li vediamo spesso indicati come FullCLR (Windows PowerShell) e CoreCLR (PowerShell Core)

Aiutiamoci con Windows Subsystem for Linux e scopriamo quanti moduli sono disponibili nelle due edizioni di PowerShell. Proviamo a lanciare su entrambe il comando Get-Module -ListAvailable , che ci restituisce l’elenco dei moduli utilizzabili, redirezionando l’output al comando Linux wc -l, che ci indica il numero di righe di cui questo elenco è composto. Il comando completo è quindi:

Get-Module -ListAvailable | bash -c “wc -l”

Proviamo ad eseguirlo su PowerShell Core

E successivamente su PowerShell

La differenza è notevole, 22 moduli contro 100, ma come al solito parliamo di progetti nati da pochissimo tempo e sui quali viene investito un gran numero di risorse, quindi ci aspettiamo delle grosse novità in tempi brevi.

Ricordiamo ovviamente che sui sistemi operativi non Windows è utilizzabile unicamente l’edizione Core, ed a questo proposito indichiamo che su alcune distribuzioni Linux si rilevano problemi nell’ottenimento dell’ultima release utilizzando l’opzione update dei vari package manager. Se vi trovate in questa situazione è sufficiente disinstallare e reinstallare il componente utilizzando:

Sulle distribuzioni Debian/Ubuntu:

sudo apt remove powershell && sudo apt-get install powershell

Sulle distribuzioni RedHat/CentOS:

sudo yum remove powershell && sudo yum install powershell

Sul futuro di PowerShell Core, quindi, sappiamo che la direzione su cui il team di sviluppo si sta muovendo è quella di aumentare il numero dei comandi supportati in modo da avere sistemi, anche eterogenei, sempre più in simbiosi ed in grado di scambiarsi il maggior numero di informazioni possibili, così da permettere un management sempre più centralizzato.

Nel frattempo Windows PowerShell continua ad essere supportato ma probabilmente non ci saranno grossi sviluppi futuri.

Per permettere l’accesso alle nostre reti wireless molto spesso utilizziamo delle chiavi di cifratura WPA2, che rimangono le stesse per diverso tempo, e che spesso vengono anche consegnate ad utenti ospiti delle nostre reti. Chiunque disponga della chiave può quindi accedere alla WLAN e non sempre nelle nostre infrastrutture ci preoccupiamo di cambiarla periodicamente, considerando anche che dovremmo farlo su tutti gli access point e su tutti i client.

Per garantire un metodo più affidabile di autenticazione e autorizzazione, da anni è possibile implementare una struttura di protezione delle reti basata sul protocollo 802.1x, uno standard IEEE per l’autenticazione dell’accesso alla rete che può anche essere utilizzato per la gestione delle chiavi di protezione WPA2. Il suo utilizzo non è limitato alle reti senza fili, ma può essere implementato in numerosi switch di fascia alta nelle reti cablate. Per approfondimenti sul funzionamento del protocollo 802.1x vi rimando alla pagina https://it.wikipedia.org/wiki/IEEE_802.1x

In questa guida vedremo come implementare l’uso del protocollo 802.1x per le reti wireless (ma analogo ragionamento può essere fatto per le reti cablate), utilizzando un server di autenticazione RADIUS creato con Windows Server 2016 ed EAP-TLS.
EAP-TLS offre un processo di autenticazione molto sicuro, che sostituisce le semplici password con certificati digitali (sia lato client che lato server), tramite l’utilizzo di una Certification Authority (PKI), creando di fatto quella che viene chiamata Mutual Authentication.

EAP-TLS con Mutual Authentication è attualmente l’implementazione più sicura per l’accesso alle reti wireless o alle reti cablate. I client autenticano il server RADIUS ed il server RADIUS chiede ai client di autenticarsi, richiedendo loro un certificato digitale.

Pertanto questo tipo di autenticazione, basato su certificati digitali sia computer che utente, permette l’accesso solo a chi possiede il certificato corretto e, nel caso la connessione avvenga tramite rete wireless, subito dopo l’autenticazione viene rilasciata una chiave WPA2 unica per utente (o per computer) ed unica per ogni sessione di connessione!

Per creare una infrastruttura di accesso che supporti questo protocollo affronteremo diversi passaggi:

1. Creazione della Certification Authority e relativa configurazione
2. Configurazione dei gruppi di accesso in Active Directory
3. Creazione del server RADIUS di autenticazione utilizzando il ruolo Network Policy Services (NPS)
4. Rilascio dei certificati per i client
5. Configurazione degli Access Point per il supporto all’802.1x
6. Configurazione dei client per il supporto all’EAP-TLS nelle reti wireless

Figura 1: Schema dell’infrastruttura necessaria all’implementazione del protocollo 802.1 con EAP-TLS

Creazione della Certification Authority (CA)

Per creare una certification authority si utilizza il ruolo Active Directory Certificate Services. Procedete all’installazione del ruolo in una macchina Windows Server.

Figura 2: Installazione del ruolo Active Directory Certificate Services in Windows Server 2016

Aggiungete il Role Services di Certification Authority e di Certification Authority Web Enrollment, che vi darà la possibilità di rilasciare i certificati per i vostri client anche attraverso un’interfaccia web.

Figura 3: Aggiunta dei Role Services per il ruolo di CA

Terminata l’installazione sarà necessario configurare la nostra Certification Authority. Cliccate quindi sul link Configure Active Directory Certificate Services in the destination computer.

Figura 4: Installazione del ruolo completata. È necessario però configurarlo

Dopo aver cliccato sul link si aprirà un wizard di configurazione. Configurare entrambi i Role Services che avete appena installato, come mostrato in figura:

Figura 5: Scelta dei Role Services da configurare

Il primo passaggio consiste nell’indicare se volete creare una CA di tipo Enterprise o Standalone. Nel nostro ambiente di dominio utilizzeremo una CA di tipo Enterprise.

Figura 6: Scelta del tipo di Certification Authority da installare

Poiché si tratta del primo server che installiamo, scegliamo di creare una Root CA. Per chi è poco pratico di Certification Authority e vuole conoscere nel dettaglio le differenze, consiglio la lettura dell’articolo Types of Certification Authorities

Figura 7: Scelta del tipo di Certification Authority da utilizzare

Per poter rilasciare i certificati, la vostra Root CA deve avere una chiave privata. Scegliete di creare una nuova Private Key e proseguite con il wizard.

Figura 8: Creazione della nuova chiave privata per la Root CA

La scelta del provider per la crittografia può avere un impatto determinante per la sicurezza, le performance e la compatibilità dei certificati rilasciati dalla vostra CA. Lasciate le impostazioni predefinite e proseguite nel wizard. Poiché le Cryptographic Options sono molto importanti, vi rimando alla lettura dell’articolo Cryptographic Options for CAs

Figura 9: Scelta del provider per la crittografia

Scegliete il nome della vostra CA, in modo che sia facilmente riconoscibile.

Figura 10: Scelta del nome della Certification Autority

Scegliete il periodo di validità del certificato della Root CA

Figura 11: Scelta del periodo di validità del certificato della Root CA

Specificate dove volete che venga salvato il database ed il file di log della CA

Figura 12: Percorsi di installazione del database del file di log della CA

Confermate tutte le configurazioni che avete inserito nel wizard e cliccate sul pulsante Configure:

Figura 13: Conferma delle configurazioni degli Active Directory Certificate Services

Dopo pochi istanti avrete creato e configurato la vostra Certification Authority!

Figura 14: Creazione della CA completata

Configurazione del Network Policy Service (NPS)

Per implementare la nostra infrastruttura basata su RADIUS e protocollo 802.1x ci serviremo di un server Windows in cui installeremo il ruolo di Network Policy Service (NPS). Indipendentemente dal metodo di autenticazione che utilizzerete per le vostre reti wireless (EAP-TLS, PEAP-TLS oppure PEAP-MS-CHAP v2), sarà obbligatorio installare sul Server NPS un certificato digitale che ne permetta il riconoscimento come server di autenticazione.

Per questo motivo sarà necessario distribuire tramite la nostra CA il certificato corretto, creato dal template RAS and IAS Server. Un certificate template viene utilizzato dalla CA per definire il formato ed il contenuto del certificato, per specificare quale utente o quale computer potranno richiederlo e per definirne tutte le caratteristiche e gli usi. Per maggiori informazioni potete leggere l’articolo Certificate Templates Overview

Aprite quindi la console della Certification Authority e dal nodo Certificate Template fate clic col tasto destro scegliendo New –> Certificate Template to Issue

Figura 15: Scelta del nuovo certificate template da distribuire

Per permettere al vostro server NPS di ottenere il certificato valido per poter essere utilizzato con RADIUS server, aggiungetelo in Active Directory al gruppo RAS and IAS Servers. Il gruppo infatti ha la possibilità, di default, di ottenere il certificato dal template RAS and IAS Server che abbiamo appena distribuito.

Figura 16:Aggiunta del server NPS01 al al gruppo RAS and IAS Servers in Active Directory

Riavviate il server NPS in modo tale che possa ottenere nel proprio token Kerberos il SID del gruppo RAS and IAS Servers e, dopo esservi autenticati, aprite una nuova console MMC, aggiungete lo snap-in dei Certificati Computer e procedete alla richiesta del certificato per il server NPS01, come mostrato in figura:

Figura 17: Richiesta di un nuovo certificato sul server NPS01

Se avrete effettuato correttamente tutte le operazioni, vedrete tra le opzioni disponibili la possibilità di richiedere il certificato dal template RAS and IAS Server.

Figura 18: Richiesta del certificato dal template RAS and IAS Server

Installazione del ruolo di Network Policy and Access Services sul server RADIUS

Procedete all’installazione del ruolo Network Policy and Access Services sul server NPS01, come mostrato nelle due figure:

Figura 19: Aggiunta del ruolo Network Policy and Access Services

Figura 20: Aggiunta del ruolo NPS completata

Lanciate la console del Network Policy Server e dalla scheda Getting Started scegliete dal menù a tendina che volete implementare lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections. Cliccate sul link Configure 802.1x, come mostrato in figura:

Figura 21: Scelta dello lo scenario di RADIUS Server for 802.1x Wireless or Wired Connections nella scheda Getting Started

Partirà un wizard che vi guiderà nella configurazione. Nella prima schermata scegliete lo scenario. Nel nostro caso vogliamo rendere sicura una rete wireless.

Figura 22: Scelta del tipo di connessione per l’802.1x

Nella seconda schermata aggiungere il vostro RADIUS Client, cioè l’Access Point che invierà le richieste di connessione al vostro server NPS. Indicate anche uno Shared Secret, che dovrete successivamente inserire nel pannello di configurazione dell’Access Point.

Figura 23: Aggiunta del RADIUS Client (Wireless Access Point)

Figura 24: Potete aggiungere tutti i RADIUS Client che volete utilizzare nella vostra rete wireless sicura

Nella terza schermata scegliete il metodo di autenticazione. Nel nostro caso utilizzeremo i certificati digitali da installare sui pc client che vogliono accedere alla rete wireless (protetta con 802.1x ed EAP-TLS). Scegliete Microsoft: Smart Card or other certifcate e dal pulsante Configure assicuratevi di selezionare il certificato corretto per il vostro server NPS (cioè il certificato generato dal template RAS and IAS Server della vostra CA):

Figura 25: Scelta del metodo di autenticazione

Nella quarta schermata scegliete il gruppo di utenti o di computer di Active Directory che sarà autorizzato ad accedere alla rete wireless. Io ho aggiunto il gruppo Domain Computers

Figura 26: Scelta del gruppo di Active Directory che sarà autorizzato ad accedere alla rete wireless

Se utilizzate le VLAN nella vostra infrastruttura, sarà necessario effettuare ulteriori configurazioni. Maggiori informazioni sono contenute nell’articolo Configure Network Policies

Figura 27: Configurazioni relative alle VLAN

A questo punto il vostro wizard sarà terminato e verranno create una Connection Request Policy ed una Network Policy, entrambe chiamate Secure Wireless Connections.

Figura 28: Configurazione del server NPS completata

Configurazione dei computer client

Terminata la configurazione del server RADIUS è necessario configurare i client. Come prima operazione ci occuperemo di distribuire i certificati ai client che saranno autorizzati ad accedere alla rete wireless. Per poterlo fare ci serviremo di un template e delle group policy. Per poter distribuire i certificati utilizzando le GPO dovremo creare un template adatto a tale scopo.

Creazione del template per la distribuzione dei certificati ai computer del dominio

Dalla console Certificate Templates duplicate il template chiamato Computer per poterne generare uno nuovo, come mostrato in figura:

Figura 29: Duplicazione del template Computer

Dalle proprietà del nuovo template, provvedete a configurare un nuovo nome, ad indicare una durata per i certificati emessi e ad aggiungere alla scheda Security il gruppo di Computer di Active Directory che potrà richiederne i certificati che verranno da esso generati. Se volete utilizzare le GPO per la distribuzione dei certificati non dimenticatevi di selezionare l’opzione AutoEnroll, come mostrato nelle figure seguenti:

Figura 30: Definizione del nome del nuovo template certificati

Figura 31: Permesso di esportare la chiave privata

Figura 32: Aggiunta del gruppo di Active Directory autorizzato e selezione dell’AutoEnroll

Figura 33: Scelta delle informazioni da inserire nei certificati emessi

Terminata la creazione del template, collegatevi alla console di gestione della Certification Authority e distribuite il nuovo template certificato che avete creato, come mostrato nelle figure seguenti:

Figura 34: Aggiunta del nuovo certificate template alla CA

Figura 35: I due certificate template creati e distribuiti dalla nostra CA

Distribuzione del certificato computer utilizzando le Group Policy

Per distribuire il certificato Computer nel nostro dominio tramite le Group Policy vi basta creare una nuova GPO, collegarla alla OU dove si troveranno i computer autorizzati ad utilizzare la rete wireless e da Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies modificare la voce Certificate Services Client – Auto-Enrollment come mostrato in figura:

Figura 36: Auto-Enrollment dei certificati tramite GPO

Tutti i template certificato che saranno configurati per l’Auto-Enrollment per i gruppi di computer di Active Directory verranno distribuiti tramite questo metodo. Nessuno ovviamente vi vieta di installare manualmente i certificati sui vostri computer.

Effettuate un gpupdate sui vostri computer, magari utilizzando la PowerShell Invoke-GPUpdate e assicuratevi che abbiano ricevuto un certificato digitale

Figura 37: Certificati digitali emessi dalla CA e distribuiti tramite Group Policy

Figura 38: Certificato ricevuto dal client tramite la GPO

Configurazione degli Access Point per il supporto all’802.1x

La configurazione dei Wireless Access Point per il supporto all’802.1x varia da modello a modello. In genere trovate la configurazione sotto la voce Wireless
Security, scegliendo WPA2-Enterprise, WPA-Enterprise oppure Open with 802.1X. Nel mio caso ho scelto di utilizzare una chiave WPA2, che verrà data al computer solo dopo che sarà avvenuta l’autenticazione. Ho ovviamente dichiarato qual è il server RADIUS da utilizzare (NPS01) e lo Shared Secret che avevo precedentemente impostato nel wizard di creazione della Network Policy.

Figura 39: Configurazione del Wireless Access Point per l’utilizzo di WPA2-Enterprise

Configurazione dei client per la connessione alla rete wireless

Per configurare manualmente il client a connettersi alla rete protetta con il protocollo 802.1x è necessario effettuare delle operazioni. Spostatevi nel pannello di controllo del vostro client (Io sto usando Windows 10 versione 1709), andate in Network and Sharing Center e scegliete di configurare una connessione manuale verso una rete wireless, come mostrato in figura:

Figura 40: Connessione manuale ad una rete wireless in Windows 10

Inserite il nome della rete wireless a cui volete collegarvi e scegliete come Security type la voce WPA2-Enterprise

Figura 41: Scelta del nome della rete wireless e del metodo di autenticazione

Nel passaggio successivo cliccate sul pulsante Change Connection setting

Figura 42: Modifica delle opzioni della connessione

Spostatevi nella scheda Security e assicuratevi che nel Security type ci sia WPA2-Enterprise, nell’Encryption type ci sia AES e in Authentication method ci sia Microsoft: Smart Card or other certificate. Cliccate sul pulsante Settings per selezionare se volete utilizzare una Smart Card oppure un certificato presente sul computer e controllate di aver selezionato Use Simple Certificate Selection, nel caso sul vostro computer siano installati diversi certificati.

Figura 43: Modifica delle configurazioni di Security per la rete wireless

Cliccando sul pulsante Advanced settings potrete anche forzare come metodo di autenticazione la Computer Authentication, come mostrato in figura:

Figura 44: Opzioni avanzate della scheda Security

Confermate le impostazioni cliccando su OK e provate a collegarvi alla rete wireless. Se tutto sarà stato configurato correttamente vi riuscirete a collegare in pochissimi istanti.

È possibile verificare le configurazioni della rete wireless in qualsiasi momento accedendo al Network and Sharing Center, cliccando sul nome della rete wireless e scegliendo Wireless Properties dalla scheda Wi-Fi status, come mostrato in figura:

Figura 45: Modifica delle configurazioni della rete Wi-Fi

Configurazione dei client per la connessione alla rete wireless tramite Group Policy

Per semplificare la connessione alla rete wireless protetta con 802.1x è possibile anche utilizzare le Group Policy. In effetti la connessione manuale è alquanto impegnativa, non alla portata di tutti gli utenti ed è necessario collegarsi a tutti i pc client per poterla effettuare. Con le GPO, esattamente come abbiamo fatto con i certificati digitali per i computer, l’operazione diventa invece molto semplice.

Create una Group Policy e collegatela alla OU dove si trovano i computer che volete configurare. Spostatevi nel ramo Computer Configuration\Policies\Windows Settings\Security Settings\Wireless Network (IEEE 802.11) Policies e cliccando con il tasto destro scegliete Create a New Wireless Network Policy for Windows Vista and Later Releases, come mostrato in figura:

Figura 46: Creazione di una nuova Wireless Network Policy

Nella scheda che si aprirà, scegliete un nome per la vostra policy e cliccate su Add per aggiungere le configurazioni di una nuova rete wireless di tipo Infrastruttura, come mostrato in figura:

Figura 47: Aggiunta della nuova rete wireless

Nelle proprietà del nuovo profilo della rete wireless che volete aggiungere, inserite il nome dell’SSID della rete e cliccate sul pulsante Add

Figura 48: Aggiunta dell’SSID della rete wireless

Cliccate sulla scheda Security e configuratela con le informazioni visualizzate nella figura seguente:

Figura 49: Configurazione delle Security per la rete wireless

Completate la configurazione cliccando su OK.

Figura 50: Completamento della configurazione

Da questo momento il profilo verrà distribuito attraverso le group policy. Effettuate un gpupdate sui vostri computer client oppure utilizzate la PowerShell Invoke-GPUpdate dal domain controller e assicuratevi che i client possano accedere alla rete Wi-Fi protetta.

Conclusioni

La sicurezza è una condizione determinante per la protezione delle nostre infrastrutture e della nostra produzione. Filtrare l’accesso alle reti wireless o alle reti cablate servendosi del protocollo di autenticazione 802.1x con EAP-TLS certamente incrementa il lavoro da fare ma allo stesso tempo permette di essere sicuri che alle nostre reti possano accedere solo i computer autorizzati.

ATTENZIONE: Per motivi logistici l’evento è stato spostato al 14 marzo 2018 – seguiranno maggiori informazioni

Il prossimo 24 gennaio 2018 14 marzo 2018 si terrà un evento gratuito nell’Aula 2 del Palazzo delle Aule presso il Campus universitario “Ernesto Quagliariello” in via Orabona 4 – Bari.

Organizzato dalla Community ICT Power in collaborazione con Studenti Indipendenti, Università di Bari e Microsoft Student Partner, vedrà la partecipazione di studenti, professionisti e curiosi.

L’evento apre di fatto il primo ciclo di conferenze PowerCon, che storicamente rappresenta il marchio degli incontri formativi organizzati dalla Community ICTPower.

Vito Macina (Microsoft Most Valuable Professional e Digital Strategist) e Gianluca Nanoia (Microsoft Most Valuable Professional e Security Expert), membri della Community ICT Power, vi faranno conoscere Windows 10 oltre ogni limite, dando particolare rilievo alle ultime novità introdotte nell’ultima versione Fall Creators Update, e vi mostreranno come distribuire rapidamente il sistema operativo in azienda.

Non mancheranno anche le indicazioni per sfruttare al meglio il Cloud pubblico, argomento sicuramente di grande attualità, con una serie di Cloud Essentials.

Vi aspettiamo quindi in 24 gennaio dalle 15:00 alle 18:30 al Campus universitario.

Non mancate!

ISCRIZIONE NON RICHIESTA

I Remote Desktop Services (RDS) sono una piattaforma di presentation virtualization che permette agli utenti di poter accedere in desktop remoto alle applicazioni, senza che queste vengano installate sulle proprie macchine. La tecnologia esiste fin da NT 4.0 (NT 4.0 Terminal server è stato rilasciato nel 1998) ed è sicuramente una tecnologia matura, che offre il vantaggio di poter utilizzare le applicazioni e dati indipendentemente da dove si stia effettuando la connessione. È possibile collegarsi direttamente all’intero desktop remoto (jn questo caso si parla di VDI – Virtual Desktop Infrastructure) oppure è possibile visualizzare solo l’applicazione remota (RemoteApp – Session based virtualization).

In questa guida ci occuperemo di configurare proprio le RemoteApp, applicazioni installate ed eseguite in remoto in un server terminal, che quando vengono lanciate sembra che siano eseguite sul pc dell’utente come se fossero delle applicazioni locali, migliorando di molto l’esperienza utente visto che non c’è possibilità di confondersi come quando le connessioni terminal visualizzano due desktop (uno locale del pc da cui ci si connette ed uno remoto del server terminal).

Figura 1: Ruoli e server utilizzati dai Remote Desktop Services

Per creare un RDS Session-based deployment abbiamo bisogno di installare in Windows Server 2016 i seguenti ruoli dei Remote Desktop Services:

• Remote Desktop Session Host – è il server in cui sono installate le applicazioni che vogliamo utilizzare
• Remote Desktop Connection Broker – è il server che si occupa di gestire le connessioni verso i Session Host e verso le RemoteApp
• Remote Desktop Web Access – consente agli utenti di accedere alla RemoteApp tramite un portale web ed un browser
• Remote Desktop Licensing Server – è il server che controlla che abbiate le licenze per potervi collegare (RDS CAL)
• Remote Desktop Gateway (opzionale) – questo server utilizza il Remote Desktop Protocol (RDP) su HTTPS per stabilire una connessione sicura e crittografata tra utenti remoti in Internet e i Session Host interni alla nostra rete in cui vengono eseguiti le applicazioni

Installazione dei Remote Desktop Services

Già in Windows Server 2012 è stata migliorata molto l’installazione dei servizi necessari a creare una RDS Farm. Nella nostra guida utilizzerò un solo server (chiamato RDS01), che ho aggiunto al dominio demo.lab, che ospiterà i ruoli di Session Host, Connection Server e Web Access. È possibile installare i ruoli su server diversi, anche per poterne moltiplicare il numero ed evitare i single point of failure. Se volete maggiori informazioni su come realizzare un’infrastruttura RDS altamente disponibile vi consiglio di leggere la guida Remote Desktop Services – High availability

Sul mio server RDS01, dopo averlo aggiunto al dominio, ho lanciato il wizard per l’aggiunta dei ruoli e ho scelto Remote Desktop Services installation, come mostrato in figura:

Figura 2: Scelta dell’installazione Remote Desktop Serrvices

Nel passaggio successivo vi verrà chiesto in che modo volete configurare il vostro deployment. La scelta si può fare utilizzando la modalità Quick Start, che installa tutti i ruoli su una sola macchina, la modalità Standard, che vi permette di differenziare i ruoli su macchine diverse (utile per l’alta disponibilità) e i servizi MultiPoint, una novità di Windows Server 2016. Scegliete Standard Deployment e fate clic su Next

Figura 3: Scelta della modalità Standard per la creazione dell’infrastruttura RDS

Nel passaggio successivo dovrete scegliere se volete utilizzare delle macchine virtuali (VDI) per accedere alle vostre applicazioni o se volete utilizzare dei Terminal Server che ospiteranno le vostre RemoteApp. Scegliete Session-based desktop deployment e fate clic su Next

Figura 4: Session-based deployment

Il wizard a questo punto vi confermerà quali ruoli sono necessari per la vostra infrastruttura. Come potete notate dalla figura sotto, dovrete installare 3 ruoli: Session Host, Connection Broker e Web Access.

Figura 5: Ruoli che sono necessari alla creazione della nostra infrastruttura RDS

NOTA: Se volete distribuire i ruoli su più server è necessario aggiungerli preventivamente al Server Pool che Windows Server potrà gestire. Maggiori informazioni sono reperibili leggendo l’articolo add Servers to Server Manager

Proseguite il vostro wizard e aggiungete quindi il server RDS01 alla lista dei server su cui installare il ruolo di Connecion Broker, come mostrato in figura:

Figura 7: Scelta dei server su cui installare il ruolo di Connection Broker

Nel passaggio successivo indicate su quali server installare il ruolo di Web Access. Io ho scelto di installare il Web Access sul Connection Broker server.

Figura 8: Scelta del server su cui installare il ruolo di Web Access

Terminate il wizard scegliendo su quali server installare il ruolo di Session Host. Avendo più server collegati al Server Manager le operazioni vengono enormemente semplificate, visto che non è necessario ripeterle per ogni server che deve far parte della nostra infrastruttura RDS.

Figura 9: Aggiunta del server su cui verrà installato il ruolo di Session Host

Nella pagina di conferma vi viene segnalato che per completare l’installazione del ruolo Session Host sarà necessario il riavvio del server. Mettete un segno di spunta nella casella se volete che dopo l’installazione del ruolo il riavvio del server avvenga in automatico.

Figura 10: Schermata finale del wizard di creazione dello standard deployment RDS

Dopo qualche minuto, l’installazione dei ruoli sarà completata e il server si riavvierà. Subito dopo il riavvio, loggatevi al server RDS01 e si riaprirà in automatico il wizard, che dopo aver completato le ultime operazioni di configurazione, vi segnalerà che il deployment è terminato.

Figura 11: Completamento del deployment

Installazione delle applicazioni su server Session Host

Procedete ad installare le applicazioni sul server Session Host. Io ho deciso di distribuire Office 2016. Per installare qualsiasi applicazione su un Terminal Server è necessario andare nel pannello di controllo e scegliere la voce Install Application on Remote Desktop Server. Prima di installare qualsiasi applicazione, infatti, il server Session Host deve essere posto in una speciale modalità (Install Mode) per assicurarsi che l’applicazione possa essere eseguita in un ambiente multi-utente. Scegliete l’eseguibile dell’applicazione utilizzando il pulsante Browse e fate clic su Next.

Figura 12: Il Session Host deve esser emesso in modalità Install Mode prima di installare qualsiasi applicazione

Dopo aver terminato l’installazione dell’applicazione fate clic su Finish nella finestra del Finish Admin install, che si illuminerà da solo. Installate tutte le altre applicazioni seguendo lo stesso metodo. Nella figura è mostrato il setup di Office 2016 che sta per iniziare e la schermata del Finish Admin Install, che vi invita a cliccare il pulsante Finish
solo al termine dell’installazione.

Figura 13: Installazione dell’applicazione e Finish Admin Install

Creazione della Session Collection

Una Session Collection è un insieme di applicazioni o di desktop che volete rendere disponibili ai vostri utenti. Gran parte delle operazioni di configurazione dei servizi RDS si fanno direttamente dal Server Manager. Cliccate sul nodo relativo ai Remote Desktop Services e dalla scheda Overview cliccate su Create session collection. Si aprirà immediatamente il wizard di creazione, come mostrato in figura:

Figura 14: Creazione della Session Collection

Nella schermata successiva date un nome indicativo alla vostra Session Collection

Figura 15: Nome della Session Collection

Nel passaggio successivo dovrete indicare quali server Session Host saranno aggiunti alla Collection e a cui gli utenti si collegheranno quando vorranno utilizzare le applicazioni.

Figura 16: aggiunta dei server Session Host alla Session Collection

Specificate quali sono gli utenti o i gruppi di utenti che dovranno accedere alla Session Collection. In genere io preferisco creare dei gruppi in Active Directory che abbiano il nome dell’applicazione (in questo caso Office2016Users), in modo tale da poter concedere l’accesso alle RemoteApp semplicemente aggiungendo l’utente al gruppo autorizzato.

Figura 17: Gruppo autorizzato all’accesso della Session Collection

Nel passaggio successivo vi verrà chiesto se volete abilitare gli User Profile Disks. Gli User Profile Disks, negli scenari RDS, sono un’alternativa ai Roaming Profile e alla Folder Redirection. Il profilo dell’utente (Desktop, Documenti, Application data, ecc.) viene inserito in un disco virtuale (con estensione .VHDX) che ha il nome UVHD-SIDutente e, quando un utente si connette in sessione remota, questo disco virtuale viene agganciato al Session Host dove l’utente si collega, facendo in modo che l’utente possa accedere sempre ai propri file indipendentemente a quale Session Host si sia collegato (se ne avete più di uno nel vostro deployment).

Figura 18: Aggiunta degli User Profile Disks

Completate il wizard di creazione della Session Collection facendo clic sul pulsante Create.

Figura 19: Completamento del wizard di creazione della Session Collection

Aggiunta delle applicazioni alla Session Collection

Per poter aggiungere le applicazioni alla Session Collection e permettere ai vostri utenti di utilizzare le RemoteApp è necessario selezionare la collection dal Server Manager e cliccare, nel riquadro RemoteApp Programs su Tasks e su Publish RemoteApp Programs, come mostrato in figura:

Figura 20: Aggiunta delle RemoteApp

Il wizard di pubblicazione delle RemoteApp andrà ad interrogare uno dei Session Host che avete precedentemente aggiunto alla Collection per sapere quali applicazioni sono installate. Se avete diversi Session Host aggiunti al vostro deployment assicuratevi ovviamente che tutti abbiano le stesse applicazioni installate!

Figura 21: Scelta delle applicazioni da esporre come Remote App

Confermate la scelta delle applicazioni cliccando sul pulsate Publish.

Figura 22: Conferma della scelta delle applicazioni

Aggiunta dei certificati digitali ai Remote Desktop Services

I Remote Desktop Services utilizzano i certificati digitali per firmare il traffico e le comunicazioni che avvengono tra i computer. Quando un client si connette al server, l’identità del server viene verificata tramite certificato. Maggiori informazioni sui certificati da utilizzare con I remote Desktop Services possono essere reperite al link Using certificates in Remote Desktop Services

Io ho provveduto a comprare un certificato digitale di tipo wildcard valido per *.nicolaferrini.it e quindi utilizzabile per qualsiasi nome host. Se volete potete utilizzare una Certification Authority interna oppure utilizzare un certificato Self-Signed (anche se lo sconsiglio).

Per aggiungere un certificato al vostro deployment spostatevi nella scheda Overview e da Tasks scegliete Edit Deployment Properties, come mostrato in figura:

Figura 23: Modifica del deployment per l’aggiunta dei certificati digitali

In Configure the deployment provvedete ad installare i certificati per i diversi ruoli del vostro deployment (Connection Broker e Web Access). La procedura è mostrata in figura.

Figura 24: Aggiunta dei certificati digitali ai diversi ruoli RDS

Figura 25: Aggiunta dei certificati digitali completata

A questo punto il deployment è terminato. Siete pronti per verificarne il funzionamento.

Connessione alle RemoteApp della Session Collection

Loggatevi all’indirizzo del vostro Web Access. Nel mio caso l’host si chiama rds01.demo.lab, ma l’ho anche pubblicato esternamente con il nome apps.nicolaferrini.it. L’indirizzo completo a cui collegarvi è quindi https://apps.nicolaferrini.it/rdweb. Avendo installato un certificato valido non ottengo nessun messaggio di errore. Dalla schermata di login inserite le credenziali di un utente che avete aggiunto al gruppo autorizzato ad accedere alla vostra Session Collection, come mostrato in figura:

Figura 26: Connessione al Web Access

Dopo aver inserito le credenziali vi appariranno le icone delle applicazioni (RemoteApp) che avete deciso di aggiungere alla vostra Session Collection. Cliccate su una delle icone per aprire la connessione verso il Session Host e lanciare il programma.

Figura 27: RemoteApp disponibili per la connessione

Dopo aver lanciato la connessione verso l’applicazione, vi apparirà un messaggio in cui vi verrà chiesto se considerare attendibile il Publisher dell’applicazione. In più vi verranno date indicazioni anche sul computer remoto a cui vi state connettendo.

Figura 28: Avviso sull’attendibilità del Publisher dell’applicazione

Reinserite le credenziali di accesso alla RemoteApp e finalmente vi si aprirà una finestra con l’applicazione che avete lanciato.

Figura 29: Inserimento delle credenziali di accesso all’applicazione

Sulla barra delle applicazioni sarà visibile l’icona di Word 2016 con il simbolo dell’RDP e la finestra di Word sarà ridimensionabile e riducibile ad icona, come se l’applicazione fosse installata localmente. In realtà l’applicazione è eseguita in remoto sul Session Host.

Figura 30: La RemoteApp viene aperta ed è possibile lavorarci

Subito dopo la connessione viene anche visualizzato un popup che vi avvisa a quale computer siete connessi. Da questo momento in poi potete lanciare tutte le applicazioni che volete, anche più volte la stessa applicazione. Se volete disconnettervi da Remote Desktop Session Host è possibile cliccare col tasto destro sull’icona nella barra delle applicazioni e scegliere una delle opzioni, come mostrato in figura:

Figura 31: Disconnessione dal Remote Desktop Session Host

Se avete deciso di usare gli User Profile Disks potete anche visualizzare cosa è stato creato nella cartella condivisa dove avete deciso di posizionarli, come mostrato in figura:

Figura 32: User Profile Disks creati dopo le connessioni al Session Host

Invece di utilizzare un browser, per poter accedere alle RemoteApp è anche possibile far apparire l’elenco delle applicazioni direttamente nel menù avvio di Windows. Collegatevi al Pannello di Controllo del vostro client e cliccate sull’icona RemoteApp and Desktop Connections.

Figura 33: Aggiunta delle RemoteApp al menù avvio di Windows

Nel wizard di configurazione inserite l’indirizzo del vostro server Web Access, formattandolo come richiesto.

Figura 34: indirizzo del Web Access da contattare

Dopo la richiesta di autenticazione, che va fatta solo la prima volta, vi verrà mostrato il numero di applicazioni che siete abilitati ad eseguire.

Figura 35: Connessione al Web Access completata

Da questo momento in poi le applicazioni potranno essere lanciate direttamente dal menu avvio di Windows.

Figura 36: RemoteApp presenti nel menù avvio di Windows

Aggiunta del Remote Desktop Gateway per proteggere le connessioni

Per permettere l’accesso da Internet all’infrastruttura RemoteApp  è necessario implementare il ruolo di Remote Desktop Gateway. Vi rimando alla lettura della guida Configurare Remote Desktop Gateway in Windows Server 2016 per conoscere la modalità di implemtentazione.

Conclusioni

Le RemoteApp fanno in modo che i programmi a cui si accede in remoto tramite i Remote Desktop Services vengano visualizzati come se venissero eseguiti nel computer locale dell’utente. Questo offre un’esperienza utente notevole e facilita l’interazione con le applicazioni remote. La RemoteApp ha una finestra ridimensionabile, può essere spostata su più monitor e ha una propria icona sulla barra delle applicazioni. Davvero utile!

Abbiamo visto nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 come creare una Session Collection di RemoteApp e come configurare un’infrastruttura basata sui Remote Desktop Services di Windows Server 2016. In questa guida vedremo come rendere disponibile l’accesso alle applicazioni anche da Internet in maniera sicura tramite il ruolo Remote Desktop Gateway.

Il Remote Desktop Gateway è uno dei ruoli dell’infrastruttura di Remote Desktop per consente agli utenti remoti di connettersi a qualsiasi risorsa interna alla LAN da Internet, utilizzando una connessione crittografata, senza dover configurare connessioni VPN (Virtual Private Network) verso l’azienda. Il server trasmette il traffico RDP attraverso la porta 443, utilizzando un tunnel HTTP over TLS/SSL (Transport Layer Security/Secure Sockets Layer). Questo siginifica che , indipendentemente dai server remoti che vogliamo raggiungere, è sufficiente avere un unico server Remote Desktop Gateway (o più di uno per avere alta disponibilità) esposto ad Internet ed un’unica porta aperta (TCP 443) per poterci connettere a tutta l’infrastruttura aziendale.

Inoltre questo ruolo consente di configurare i criteri di autorizzazione (policy) per definire le condizioni che gli utenti remoti devono rispettare per connettersi alle risorse di rete interne. È possibile, ad esempio, specificare:

• Utenti o gruppi autorizzati a connettersi alle risorse di rete interne
• Risorse di rete, o gruppi di computer, a cui possono connettersi gli utenti.
• Se i computer client debbano o meno essere membri di gruppi di sicurezza di Active Directory.
• Se è consentito il reindirizzamento dei dispositivi (stampanti, porte USB, dischi locali del client).

Potete approfondire l’utilità di questo ruolo leggendo l’articolo Overview of Remote Desktop Gateway, che anche se un po’ datato vi darà un’idea ben chiara di tutte le funzionalità ed i vantaggi offerti dal Gateway.

Figura 1: Principio di funzionamento del Remote Desktop Gateway

Installazione del Remote Desktop Gateway (RDGW)

Per installare il Remote Desktop Gateway è sufficiente lanciare il wizard per l’aggiunta e la rimozione dei ruoli. Se volete creare delle policy di accesso al server che utilizzino i gruppi di Active Directory vi conviene aggiungere il server RDGW a dominio. Nel mio caso ho chiamato la macchina RDGW01 e l’ho aggiunta al dominio demo.lab

Figura 2: Aggiunta del ruolo Remote Desktop Services

Proseguite con il wizard fino ad arrivare alla scheda dei Role Services dei Remote Desktop Services e mettete il segno di spunta su Remote Desktop Gateway. Verranno automaticamente aggiunti tutti i ruoli e le feature necessarie al funzionamento del RDGW. Come potete notare verrà aggiunto anche il ruolo di Network Policy Server, il web server IIS e la funzione RPC over HTTP, che si occuperà di incapsulare il traffico RDP in un tunnel protetto HTTPS.

Figura 3: Aggiunta del role service e di tutte le funzionalità necessarie

Dopo pochi istanti verranno installati tutti i ruoli e le funzionalità per permettere il funzionamento del Remote Desktop Gateway.

Figura 4: installazione del ruolo Remote Desktop Gateway completata

Per poter configurare il RDGW è sufficiente lanciare la console RD Gateway Manager da Server Manager–>Tools–>Remote Desktop Services–> RD Gateway Manager

Figura 5: Console di gestione RD Gateway Manager

Per poter permettere che il traffico del vostro server RDGW sia sicuro è necessario importare ed installare nel server un certificato digitale. Sicuramente il server RDGW sarà quello che esporrete ad Internet ed è quindi necessario che il certificato digitale sia rilasciato da una Certification Authority pubblica, se volete permettere anche ad utenti non del vostro dominio di poter accedere alle applicazioni. Aprite le proprietà del server cliccando col tasto destro sul suo nome e dalla scheda SSL Certificate importate il certificato che vi site procurati preventivamente, come mostrato in figura:

Figura 6: Importazione del certificato nel RDGW

Nel mio caso ho utilizzato il certificato wildcard *.nicolaferrini.it, ma è sufficiente utilizzare un certificato che coincida con il nome del RDGW che darete ai vostri utenti.

Figura 7: Installazione del certificato completata

Per permettere ai vostri utenti di accedere al server RDGW è necessario creare una nuova Authorization Policy, che indicherà sia chi è autorizzato ad accedere alla rete interna sia a quali server specifici (risorse) è possibile accedere. Lanciate quindi il wizard come mostrato in figura:

Figura 8: wizard di creazione della Authorization Policy

Date un nome alla Remote Desktop Connection Authorization Policy (RD CAP) e cliccate su Next

Figura 9: Nome della Remote Desktop Connection Authorization Policy (RD CAP)

Decidete se gli utenti devono utilizzare per il login una password o anche una smart card e aggiungete un gruppo di utenti che avranno le autorizzazioni ad accedere al RDGW. I gruppi di utenti possono essere locali al RDGW oppure possono essere gruppi di sicurezza del vostro dominio (se il server RDGW è joinato ad un dominio):

Figura 10: Scelta del gruppo di utenti autorizzati ad accedere al RDGW

Proseguite nel wizard indicando se abilitare o disabilitare la possibilità da parte degli utenti di portare in sessione remota le risorse locali ed i dispositivi

Figura 11: Abilitazione della Device Redirection

È anche possibile specificare un limite alla durata della sessione (session timeout) oppure un limite di tempo (idle timeout) prima che la sessione utente venga chiusa, quando l’utente si disconnette invece che fare logoff.

Figura 12: Scelta di eventuali timeout per le sessioni utente

Ricontrollate le configurazioni della vostra policy Connection Authorization Policy (RD CAP) e proseguite con il wizard cliccando su Next

Figura 13: Configurazioni della Remote Desktop Connection Authorization Policy

Il wizard procede con la creazione di una Resource Authorization Policy (RD RAP), che indica quali risorse possono essere utilizzate dagli utenti che si connettono in remoto utilizzando il Remote Desktop Gateway. Potete dare alla RD RAP lo stesso nome che avete dato alla RD CAP.

Figura 14: Nome delle Remote Desktop Resource Authorization Policy (RD RAP)

Aggiungete i gruppi di utenti che dovranno essere associati alla Resource Authorization Policy (RD RAP). In genere sono gli stessi gruppi che avete indicato nella Connection Authorization Policy (RD CAP).

Figura 15: Gruppi che devono utilizzare la Resource Authorization Policy (RD RAP)

Nella schermata successiva del wizard potete scegliere a quali risorse interne alla rete (a quali computer) gli utenti potranno collegarsi in Desktop remoto. Se non avete particolari restrizioni potete anche permettere l’accesso a tutte le risorse.

Figura 16: Definizione delle risorse interne alla rete a cui è possibile accedere tramite RDGW

Scegliete a questo punto quali porte volete consentire per le connessioni. La porta RDP di default è la TCP 3389 ma se avete cambiato le porte interne dei vostri terminal server è possibile specificarle.

Figura 17: Scelta della porte su cui autorizzare le connessioni RDP

Terminate il wizard verificando di aver inserito in maniera corretta tutte le informazioni richieste per creare la Resource Authorization Policy (RD RAP).

Figura 18: Configurazione della RD RAP completata

Terminata la creazione delle due policy (RD CAP e RD RAP) potete fare clic su Close.

Figura 19: Creazione delle due policy completata

Adesso che avete terminato la configurazione del vostro Remote Desktop Gateway siete pronti per testare le vostre connessioni verso le risorse aziendali.

Verifica della connessione tramite client RDP

Per testare la connessione tramite client RDP di Windows basta aprire il Remote Desktop Connection client (mstsc.exe) e dalla scheda Advanced configurare la sezione Connect from anywhere, cliccando su Settings e configurando il client con le impostazioni visibili in figura:

Figura 20: configurazione del Remote Desktop gateway nel Connection client

Nel momento in cui cercherete di connettervi vi verrà chiesto di fornire le credenziali di accesso al server RDGW e successivamente le credenziali per connettervi al server di destinazione. Le credenziali da inserire possono coincidere oppure posso differire. Tutto dipende da come avete impostato le regole di connessione. Ad esempio, supponiamo che vogliate connettervi, da Internet e attraverso il vostro RDGW, al domain controller. Per connettervi al RDGW potreste usare le credenziali di un utente locale del RDGW o di un utente del dominio, mentre per accedere al domain controller potreste utilizzare le credenziali di un utente privilegiato.

Figura 21: inserimento delle credenziali di accesso a Remote Desktop Gateway

Figura 22: Inserimento delle credenziali di accesso al computer di destinazione

Se le credenziali saranno state inserite correttamente avrete il warning relativo al certificato presentato dal server di destinazione (nel mio caso DC01.demo.lab) e potrete accedere al suo desktop.

Figura 23: connessione effettuata al server di destinazione

Per verificare che effettivamente siate collegati al server remoto (nel mio caso il domainc ontroller) utilizzando il Remote desktop gateway potete utilizzare il comando netstat –na | find “443” | find “ESTABLISHED”, che vi mostrerà tutte le connessioni riuscite che utilizzando la porta indicata

Figura 24: Utilizzo del comando Netstat per la verifica della connessione attraverso al porta 443

Configurazione del Remote Desktop Gateway in una infrastruttura di Remote Desktop Services esistente

Per aggiungere il Remote Desktop Gateway appena creato ad una infrastruttura esistente, come ad esempio quella presentata nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016, in cui abbiamo realizzato un Session-based deployment, è sufficiente aggiungere al server Manager il server di Connection Broker in modo tale da poterlo amministrare da remoto. Maggiori informazioni su come amministrare un serve remoto sono reperibili leggendo l’articolo add Servers to Server Manager

Dal Server Manager selezionate il nodo dei Remote Desktop Service e dalla scheda Overview cliccate col tasto destro sull’icona RD Gateway e scegliete Add RD Gateway Servers, come mostrato in figura:

Figura 25: Aggiunta del server RDGW ad un’infrastruttura esistente

Nel wizard che si aprirà selezionate dall’elenco il server corretto e aggiungetelo, tramite il simbolo a forma di freccia, ai server selezionati.

Figura 26: Selezione del server RDGW da aggiungere al deployment

Nel passaggio successivo scegliete con quale nome il server dovrà essere individuato dagli utenti Internet. Verrà generato un certificato di tipo Self-Signed, che potrete successivamente sostituire con uno comprato da una Certification Authority pubblica.

Figura 27: Nome del certificato self-signed

Dopo qualche secondo la configurazione è completata.

Figura 28: aggiunta del server RDGW al deployment esistente completata

Vi consiglio di modificare subito il certificato esibito dal vostro server RDGW. Cliccate sul link Configure certificate che è apparso alla fine del wizard e approfittate per importare il certificato corretto. Nel mio caso ho utilizzato il wildcard *.nicolaferrini.it. Il certificato può essere modificato in qualsiasi momento dal Server Manager, Nodo Remote Desktop Services, selezionando Overview e da Tasks scegliendo Edit Deployment Properties.

Figura 29: Importazione e configurazione del certificato corretto per il RDGW

Rimanendo nella stessa finestra di Deployment Properties, cliccate su RD Gateway e aggiungete il server di Remote Desktop Gateway al vostro deployment. Selezionate l’opzione Use these RD Gateway Settings e configurate come mostrato in figura:

Figura 30: Il Deployment adesso utilizzerà il serve di Remote Desktop Gateway

A questo punto la configurazione è terminata e non vi resta atro che testare il vostro deployment.

Connessione alle RemoteApp della Session Collection attraverso il Remote Desktop Gateway

Loggatevi all’indirizzo del vostro Web Access. Nel mio caso l’host si chiama rds01.demo.lab, ma l’ho anche pubblicato esternamente con il nome apps.nicolaferrini.it. L’indirizzo completo a cui collegarvi è quindi https://apps.nicolaferrini.it/rdweb. Avendo installato un certificato valido non ottengo nessun messaggio di errore. Dalla schermata di login inserite le credenziali di un utente che avete aggiunto al gruppo autorizzato ad accedere alla vostra Session Collection, come mostrato in figura:

Figura 31: Connessione al Web Access

Dopo aver inserito le credenziali vi appariranno le icone delle applicazioni (RemoteApp) che sono disponibili nella vostra Session Collection. Cliccate su una delle icone per lanciare il programma.

Figura 32: RemoteApp disponibili nella Session Collection

Dopo aver lanciato la connessione verso l’applicazione, vi apparirà un messaggio in cui vi verrà chiesto se considerare attendibile il Publisher dell’applicazione. In più vi verranno date indicazioni anche sul computer remoto a cui vi state connettendo (rds01.demo.lab). Come potete notare dalla figura sotto, la connessione avverrà attraverso un Gateway server chiamato rdgw01.nicolaferrini.it

Figura 33: Connessione alla RemoteApp utilizzando il Remote Desktop Gateway

Inserite le credenziali richieste e finalmente sarete connessi alla vostra applicazione, ma questa volta attraverso un tunnel HTTPS:

Figura 34: Apertura della RemoteApp di Word 2016

Aumentare le sicurezza utilizzando la Multi-Factor Authentication

Per rendere ancora più sicuro l’accesso all’infrastruttura è possibile utilizzare la Multi-Factor Authentication unita all’utilizzo del Remote Desktop Gateway. Per conoscere la modalità di implementazione vi rimando alla lettura dela guida Utilizzare la Azure Multi-Factor Authentication con Remote Desktop Gateway in Windows Server 2016

Conclusioni

Il Remote Desktop Gateway è un ruolo molto importante dei Remote Desktop Services che permette l’accesso alle nostre applicazioni aziendali attraverso Internet. È possibile accedere ai desktop remoti e alle RemoteApp semplicemente utilizzando un unico server ed un’unica porta di connessione esposti ad Internet, con un vantaggio enorme in termini di configurazione e soprattutto con la sicurezza che le nostre connessioni saranno sempre cifrate. Davvero un bel vantaggio!

Come avete visto nella guida Configurare Remote Desktop Gateway in Windows Server 2016, l’accesso da Internet alle risorse aziendali, alle RemoteApp e al desktop remoto dei server è enormemente semplificato dall’installazione del Remote Desktop Gateway. RD Gateway inoltre garantisce che le comunicazioni tra Internet e le risorse della rete aziendale siano sicure, grazie all’utilizzo del protocollo HTTPS per incapsulare il traffico RDP.

Ma poiché la sicurezza non è mai troppa, poiché gli utenti possono salvare le credenziali di connessione e perdere i dispositivi da cui si connettono, poiché dobbiamo difendere le nostre risorse aziendali, in questa guida vi illustrerò come implementare la Multi-Factor Authenticazion con il Remote Desktop Gateway.

Utilizzando infatti Microsoft Azure Multi-Factor Authentication Server, l’utente per potersi autenticare dovrà inserire le proprie credenziali e una one-time password (oppure un PIN, rispondere ad un SMS, rispondere ad una telefonata, utilizzare token hardware, ecc…)

La procedura di autenticazione sarà quindi:

1. L’utente si collega al portale web delle RemoteApp e inserisce le proprie credenziali
2. L’utente fa doppio clic sull’icona dell’applicazione per lanciare la RemoteApp
3. Se è stato abilitato il Web SSO sul Remote Desktop Web Access non verrà chieste all’utente di reinserire le credenziali di accesso alla RemoteApp
4. L’utente riceve una telefonata oppure un SMS o una one-time password dal suo token (secondo fattore di autenticazione)
5. L’utente è autenticato e la RemoteApp si apre

Come funziona la Multifactor Authentication (MFA) con il Remote Desktop Gateway

Il Remote Desktop Gateway utilizza un server NPS (Network Policy Services) per poter autenticare ed autorizzare gli accessi. Il servizio NPS è installato quando installate il ruolo RD Gateway e dovete creare una Remote Desktop Connection Authorization Policy (RD CAP) ed una Remote Desktop Connection Authorization Policy (RD CAP) per permettere agli utenti di potersi loggare e accedere alla rete interna.

Il processo di autenticazione infatti funziona in questo modo:

1. Le credenziali dell’utente vengono inviate al RD Gateway
2. Il server NPS installato sull’RD Gateway controlla le credenziali e verifica se l’utente è abilitato ad entrare controllando le Remote Desktop Connection Authorization Policy (RD CAP)
3. Se le credenziali sono valide, il server RD Gateway controlla le Remote Desktop Connection Authorization Policy (RD CAP) per capire verso quali risorse della rete interna permettere l’accesso all’utente

Se invece aggiungete un Multi-Factor Authentication Server (MFA) il processo di autenticazione sarà diverso e seguirà queste fasi:

1. Le credenziali dell’utente vengono inviate al RD Gateway
2. Il server NPS controlla le credenziali e vede se l’utente è abilitato ad entrare controllando le Remote Desktop Connection Authorization Policy (RD CAP)
3. Se le credenziali sono valide, il server NPS invia la richiesta di login al server MFA
4. Il server MFA invia un sms o telefona all’utente (dipende da come avete deciso di impostare voi il controllo)
5. Il server MFA riceve dall’utente la risposta (ad esempio il PIN corretto)
6. Il server MFA comunica al server NPS che l’utente può/non può accedere
7. Il server RD Gateway controlla Remote Desktop Connection Authorization Policy (RD CAP) per capire verso quali risorse della rete interna permettere l’accesso all’utente

Figura 1: Sequenza dell’autenticazione effettuata tramite un Multi-Factor Authentication Server (MFA)

In questa guida utilizzerò il Microsoft Azure Multi-Factor Authentication Server (MFA) installato nella infrastruttura aziendale, quindi on-premises. Sul server MFA ho installato Windows Server 2016 e l’ho aggiunto al mio dominio demo.lab.

Prerequisiti

I prerequisiti per implementare la Multi-Factor Authentication con il Remote Desktop Gateway sono:

• Infrastruttura RDS (date un’occhiata all’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 per vedere come l’ho realizzata).
• Remote Desktop Gateway con NPS locale (date un’occhiata all’articolo Configurare Remote Desktop Gateway in Windows Server 2016 per sapere come l’ho installato).
• Un account Microsoft Azure (se non ne possedete uno potete attivare una versione di prova
• Un server MFA con Windows Server 2016, joinato al vostro dominio
• Un computer client da cui effettuare le prove di connessione
• Un telefono cellulare

Installazione del server Microsoft Azure Multi-Factor Authentication Server (MFA)

Per quanti di voi non avessero dimestichezza sul funzionamento della Multi-Factor Authentication e su quale tipo di autenticazione utilizzare (Server MFA on-premises, server MFA nel Cloud) consiglio di leggere l’articolo Choose the Azure Multi-Factor Authentication solution for you.

Loggatevi al portale di Microsoft Azure e selezionate Azure Active Directory e successivamente MFA Server. Dalla scheda Overview lanciate la versione di prova di Azure Active Directory Premium che vi permetterà di utilizzare la Multi-Factor Authentication, come mostrato in figura. Azure Multi-Factor Authentication è disponibile come servizio da acquistare singolarmente, che offre la possibilità di fatturare per utente e per ogni autenticazione effettuata, oppure insieme ad Azure Active Directory Premium, Enterprise Mobility Suite e Enterprise Cloud Suite.

Figura 2: Attivazione della versione di prova di Azure Multi-Factor Authentication

Cliccando sul nodo Providers, dopo aver cliccato sul pulsante Add, inserite il nome di riferimento del vostro server MFA (io ho scelto RDGW-MFA), il tipo di utilizzo e di tariffazione (per utente o per singola autenticazione) e la sottoscrizione, come mostrato in figura:

Figura 3: Creazione del Provider di autenticazione

Terminata la creazione del Provider, selezionate il server RDGW-MFA creato e dal nodo Server settings efefttuate il download del software (che installerete sulla vostra macchina on-premises) e create le credenziali di attivazione del server MFA.

Figura 4: Download del software e creazione delle credenziali di attivazione del server MFA

Dopo aver scaricato il software nella macchina che volete utilizzare come server MFA (la mia si chiama mfa01.demo.lab) lanciate il setup ed installate i prerequisiti, come mostrato in figura:

Figura 5: Installazione dei prerequisiti per il server MFA

Subito dopo l’installazione dei prerequisiti si avvierà il setup del Multi-Factor Authentication Server. Procedete all’installazione seguendo le indicazioni delle figure sotto:

Figura 6: scelta della cartella in installazione del server MFA

Figura 7: Installazione del server MFA completata

Dopo l’installazione vi verrà chiesto se volete lanciare il wizard di configurazione. Mettete il segno di spunta per poterlo saltare e fate clic su Next

Figura 8: Attivazione e configurazione manuale del server MFA

Procedete quindi all’inserimento delle credenziali di attivazione che avete generato sul portale di Azure. Prestate attenzione perché le credenziali sono valide solo per 10 minuti, quindi se non dovessero funzionare ricreatele dal portale Azure.

Figura 9: attivazione del server MFA

È possibile configurare il server MFA in modo tale che utilizzi gli utenti di Active Directory. Selezionate il pulsante Users e importate gli utenti da vostro dominio, seguendo le indicazioni mostrate nella figura sotto:

Figura 10: Importazione degli utenti di Active Directory nel vostro server MFA

Dopo aver importato gli utenti, è possibile configurarli in modo tale da scegliere per ognuno di loro un metodo di autenticazione (chiamata telefonica, SMS, PIN, App per il cellulare, ecc,.) come mostrato in figura:

Figura 11: Scelta del fattore di autenticazione per ogni utente

Adesso il vostro server Azure Multi-Factor Authentication è pronto per poter essere utilizzato.

Configurazione del Remote Desktop Gateway, del server NPS e del server MFA

Il prossimo passaggio da eseguire è configurare il Remote Desktop Gateway, il NPS ed il server MFA in modo tale che possano parlare tra di loro.

Configuriamo il server RD Gateway in modo tale che usi come server di autenticazione non più il server NPS installato sulla stessa macchina, bensì il server MFA. Sarà infatti d’ora in poi il server MFA ad essere interrogato per primo quando arriva una richiesta di connessione.

Dal Server Manager del vostro RD Gateway scegliete Tools–>Remote Desktop Services–> RD Gateway Manager. Aprite le proprietà del server RDGW e dalla scheda RD CAP Store indicate come server NPS l’indirizzo IP o il nome del vostro server MFA, come mostrato in figura:

Figura 12: Modifica del server che gestirà le policy RD CAP (Connection Authorization Policy)

Figura 13: Configurazione del nuovo server NPS completata

Configuriamo ora il server NPS che è installato sul RD Gateway in modo tale che parli con il server MFA. Entrambi utilizzeranno il protocollo RADIUS per potersi scambiare i messaggi di autenticazione. Pertanto, aggiungete come RADIUS client il vostro server MFA, configurandolo come mostrato in figura, in modo tale che possa accettare le autenticazioni RADIUS dal server MFA. Ho utilizzato come Friendly Name MFA01 (ci servirà in seguito).

Figura 14: Il server MFA diventa un RADIUS client per il server NPS

Nel momento in cui avete installato il ruolo RD Gateway si è installato anche il servizio NPS e nel nodo Remote RADIUS Server è stato creato automaticamente un gruppo di server chiamato TS GATEWAY SERVER GROUP. Dalle Proprietà selezionate il server MFA e dalla scheda Authentication/Accounting modificate le porte e lo shared secret (che dovrete poi configurare sul server MFA) come mostrato in figura:

Figura 15: Modifica delle porte e dello Shared Secret

Cliccate ora sulla scheda Load Balancing e aumentate il timeout ad almeno 60 secondi, come mostrato in figura. Questo timeout è necessario per permettere all’utente di avere il tempo di rispondere alla richiesta di seconda autenticazione (telefonata, sms, ecc…).

Figura 16: Timeout di risposta del server

Configurazione delle Policy di connessione

Sarà necessario modificare due Connection Request Policy nel server NPS: una servirà a inoltrare le richieste verso il server MFA e l’altra a ricevere le richieste che tornano dal server MFA.

Figura 17: Schema di funzionamento della verifica delle Connection Request Policy

Come prima operazione duplicate la policy di default TS GATEWAY AUTHORIZATION POLICY, come mostrato in figura:

Figura 18: Duplicazione della TS GATEWAY AUTHORIZATION POLICY

Cliccate col tasto destro sulla TS GATEWAY AUTHORIZATION POLICY originale e modificatene le condizioni. Aggiungete come Client Friendly Name il nome del RADIUS client che avete scelto prima (nel mio caso MFA01)

Figura 19: Modifica delle Conditions della TS GATEWAY AUTHORIZATION POLICY originale

Continuate a modificare la stessa policy andando nella scheda Settings e modificando l’Authentication in modo tale da scegliere Authenticate requests on this server, come mostrato in figura

Figura 20: Modifica dei Settings di Authentication della TS GATEWAY AUTHORIZATION POLICY originale

Nella scheda Settings della TS GATEWAY AUTHIRIZATION POLICY originale modificate l’Accounting, rimuovendo il segno di spunta da Forward accounting requests to this remote RADIUS server group

Figura 21: Modifica dei Settings di Accounting della TS GATEWAY AUTHORIZATION POLICY originale

Il risultato finale è quello mostrato nella figura sotto. Accertatevi che questa policy sia la prima ad essere processata!

Figura 22: Modifica delle policy originale completata

Non toccate nulla della policy che avete duplicato in precedenza (copy of TS GATEWAY AUTHIRIZATION POLICY) e assicuratevi che sia ordinata come seconda. Per chiarezza ho indicato in figura il significato delle due policy

Figura 23: Configurazione delle Network policy completata

Configurazione del server Multi-Factor Authentication

È arrivato il momento di configurare Azure Multi-Factor Authentication Server in modo tale che possa parlare con il server NPS. Spostatevi quindi sulla vostra macchina MFA e selezionate il pulsante RADIUS Authentication. Abilitate con un segno si punta la voce Enable RADIUS Authentication nella scheda Clients e aggiungete l’indirizzo IP o il nome del vostro RD Gateway (che è anche il server NPS), insieme allo Shared Secret che avete aggiunto nella Central CAP Store configuration del vostro RD Gateway Manager.

Figura 24: Configurazione del server NPS come RADIUS Client

Spostatevi nella scheda Target della stessa schermata e aggiungete lo stesso server anche come RADIUS Target, come mostrato in figura:

Figura 25: Configurazione del server NPS come RADIUS Target

La configurazione del nostro ambiente è completata. Non vi resta altro che testare il suo funzionamento.

Test di funzionamento

Per testare l’efficacia della configurazione fatta, collegatevi all’infrastruttura RDS utilizzando il portale web. Inserite le credenziali di login di un utente su cui avete abilitato la Multi-Factor Authentication e accedete al portale.

Figura 26: Login al portale web con le credenziali di un utente a cui abbiamo abilitato la Multi-Factor Authentication

Dopo aver effettuato il login, cliccate su una delle RemoteApp e lanciate la connessione.

Figura 27: Login al portale web effettuato e lancio della RemoteApp

Confermate che la connessione alla RemoteApp stia avvenendo utilizzando il Remote Desktop Gateway, come mostrato in figura:

Figura 28: Connessione alla RemoteApp attraverso il Remote Desktop Gateway

Reinserite le credenziali di login del vostro utente (se non avete abilitato il web Single Sign-on nella vostra infrastruttura RDS).

Figura 29: Reinserimento delle credenziali di login dell’ utente

A questo punto la connessione remota rimane in attesa che avvenga la verifica della vostra identità utilizzando il secondo fattore di autenticazione

Figura 30: Attesa di ricevere conferma dell’avvenuta verifica dell’identità del l’utente

Riceverete una telefonata al numero che avete inserito in Active Directory o sul server MFA. Rispondete alla telefonata e quando vi verrà chiesto confermate la vostra identità premendo il simbolo # (cancelletto – pound key) sul tastierino del telefono.

Figura 31: Telefonata per conferma dell’identità dell’utente

Finalmente la vostra identità è confermata e potrete cominciare ad utilizzare la vostra RemoteApp.

Figura 32: Apertura della RemoteApp di Word 2016

È possibile modificare il metodo di autenticazione dell’utente, scegliendolo dalla lista degli utenti presente sul Multi-Factor Authentication Server e modificandolo per esempio affinché inserisca un PIN durante la telefonata (invece che la semplice conferma alla risposta con il simbolo #) oppure risponda ad un SMS, inserendo il codice ricevuto tramite SMS più il suo PIN.

Figura 33: Inserimento di un PIN durante la telefonata di conferma

Figura 34: Inserimento di un codice + PIN tramite SMS

Figura 35: L’utente per verificare la propria identità deve rispondere all’SMS con un codice ricevuto ed il suo PIN personale

Conclusioni

La Multi-Factor Authentication ci aiuta a proteggere l’accesso ai nostri dati più importanti perché, oltre alla combinazione di username e password, richiede che venga fornita un’ulteriore prova della nostra identità. Moltissimi siti offrono la possibilità di utilizzarla (Microsoft, Facebook, Twitter, LinkedIn, Facebook, Google, Paypal per citarne solo alcuni) e adesso grazie a Azure Multi-Factor Authentication Server possiamo anche implementarla on-premises per le nostre applicazioni.

Storia

Il rilascio ufficiale di Windows Server 2003 R2, il giorno 6 dicembre 2005, segna la nascita di Windows Deployment Services (WDS) , un insieme di strumenti che facilitano la distribuzione dei sistemi operativi Windows attraverso la rete, evitando le procedure di installazione a partire dal classico CD. Il servizio di distribuzione in realtà esisteva già nelle versioni precedenti di Windows Server con il nome Remote Installation Service (RIS), ma era meno performante e più difficile da configurare; era addirittura possibile installare WDS come addon a partire da Windows Server 2003 SP1.

Nonostante i suoi anni di attività, però, WDS è spesso sottovalutato ed in molte realtà aziendali si preferisce continuare ad installare i sistemi operativi in maniera manuale. In questo articolo vedremo che è possibile configurare il servizio WDS con estrema facilità, iniziando con pochi click a distribuire qualsiasi sistema operativo Windows all’interno della nostra rete. Vedremo come in alcuni scenari l’implementazione di questo servizio possa far risparmiare davvero tantissimo tempo, spesso evitando di spostarsi per raggiungere una eventuale sede remota per un ripristino o l’installazione di un nuovo client.

Installazione e configurazione

E’ possibile installare WDS come servizio su un qualsiasi sistema operativo server a partire da Windows Server 2003 R2, ma in questo articolo ci concentreremo sull’installazione e configurazione in un ambiente basato su Windows Server 2016.

Troviamo Windows Deployment Services tra i ruoli di Windows Server 2016, quindi dal Server Manager selezionando “Aggiungi ruolo” possiamo attivare il servizio aggiungendo il corrispondente segno di spunta e confermando sulle finestre successive le opzioni di default.

Al termine dell’installazione possiamo aprire la console di gestione di WDS dal menù gestione nel Server Manager stesso oppure dall’apposito collegamento in strumenti di amministrazione.

Al primo avvio è necessario configurare le opzioni di base del servizio; per farlo selezioniamo “Configura Server” dopo aver cliccato col tasto destro sul nome del server all’interno della console. Tra le opzioni principali è necessario scegliere se erogare i servizi WDS all’interno di una infrastruttura Active Directory o in Workgroup. Questo è molto interessante perché utilizzando la prima opzione eventuali client faranno automaticamente join al dominio senza alcuna configurazione aggiuntiva; la seconda opzione, invece, permetterà tra le altre cose di avere un server di distribuzione sempre a portata di mano, installandolo ad esempio su una macchina virtuale sul nostro pc portatile, avremo il servizio sempre disponibile ad esempio durante gli interventi di assistenza tecnica presso i nostri clienti.

E’ necessario poi specificare la cartella che dovrà contenere le immagini di boot e dei sistemi operativi da distribuire. E’ necessario quindi che sia posizionata su un volume formattato NTFS con sufficiente spazio disponibile.

PXE Server

Il passo successivo è la configurazione del PXE (Preboot Execution Environment) Server. Questo è il componente che, supportato da opportune configurazioni del server DHCP, permette ai client di eseguire il boot da rete. Nello specifico dobbiamo istruire il nostro WDS server a rispondere a tutti i client che ne facciano richiesta piuttosto che solo ai client conosciuti, scegliendo se la risposta deve essere immediata o eseguita previa autorizzazione di un amministratore.

DHCP server

Nel caso il servizio DHCP risieda sullo stesso server in cui è installato WDS non sarà necessario eseguire alcuna modifica, altrimenti sarà necessario configurare le opzioni 66 e 67 del servizio DHCP per indicare, ai client che richiedono il boot da rete, il percorso da dove acquisire l’immagine di boot. In particolare è necessario indicare sull’opzione 66 l’ip del server WDS, e sull’opzione 67 il percorso dello script di avvio, che di default è: reminst\Boot\x86\wdsnbp.com

Per iniziare a distribuire i sistemi operativi in rete il passo successivo è quello di aggiungere una immagine di boot all’interno del nostro WDS server. Questa immagine non è altro che un mini sistema operativo, chiamato Windows PE (o WinPE), e sarà inviata ai client al momento del boot da rete; il client sarà così in grado di eseguire delle operazioni di base, tra cui connettersi alla rete ed acquisire l’eventuale immagine del sistema operativo da installare.

E’ possibile aggiungere immagini di boot a 32 e 64 bit. Con le immagini a 32 bit sarà possibile installare sistemi operativi a 32 e 64 bit, con quelle a 64 sarà possibile installare solo immagini a 64 bit. Se all’interno del server WDS sono presenti più immagini di boot, sul client sarà necessario selezionare manualmente l’immagine WinPE da utilizzare.

Il wizard della configurazione del WDS termina proprio con l’aggiunta delle immagini. E’ ovviamente possibile rimandare questa operazione ad un altro momento.

L’immagine di boot da utilizzare è quella contenuta nel DVD di installazione del sistema operativo da distribuire; questa si trova nella cartella sources ed è individuata dal nome boot.wim

Per aggiungere un’immagine di boot clicchiamo col tasto destro su “Immagini di Boot” e selezioniamo “Aggiungi immagine”. E’ importante notare che è possibile installare la versione di sistema operativo associata a quella immagine insieme a tutte le sue precedenti. Sarà sufficiente quindi aggiungere l’immagine di boot di Windows 10 1709 per poter installare quella versione e tutte le precedenti, a partire da Windows XP.

Ricordiamo inoltre che con WDS è possibile distribuire anche sistemi operativi Windows Server, e vedremo come attraverso dei file di risposta automatica è possibile automatizzare molte configurazioni relative al sistema operativo che stiamo distribuendo.

Aggiunta l’immagine di boot dobbiamo quindi aggiungere l’immagine del sistema operativo da distribuire. Questa immagine si trova sempre nella cartella sources del DVD ed è costituita dal file install.wim.

L’ultima operazione da fare quindi per iniziare ad utilizzare il nostro server WDS è quella di creare un gruppo di sistemi operativi sotto “Immagini di installazione” ed aggiungere l’immagine desiderata all’interno di questo gruppo. Per eseguire queste operazioni utilizziamo il menu cliccando con il tasto destro su “Immagini di installazione” e scegliendo “Aggiungi immagine”.

Se invece del DVD siamo in possesso dell’immagine scaricata tramite Media Creator Tool all’interno della cartella sources il file install sarà in formato ESD (Electronic Software Download), non supportato da WDS; in questo caso sarà necessario convertire il file ESD in WIM (Windows Image) utilizzando il comando DISM:

DISM /Get-WimInfo /WimFile:install.esd

Il comando estrae le informazioni dell’edizione di Windows contenuta all’interno del file install.esd, restituendo un elenco numerato. Selezioniamo l’edizione che ci interessa (ad esempio la 2) impostando il valore relativo nell’opzione SourceIndex del comando seguente per eseguire la conversione:

DISM /export-image /SourceImageFile:install.esd /SourceIndex:2 /DestinationImageFile:install.wim /Compress:max /CheckIntegrity

Non specificando il parametro SourceIndex verranno incluse tutte le edizioni (SKU)

L’immagine di destinazione, in formato WIM, può essere quindi aggiunta al nostro server WDS.

Cattura di una immagine esistente

Una funzionalità eccezionale è quella di poter usare, oltre all’immagine base di Windows contenuta nel CD, l’immagine catturata da un computer utilizzato come modello; è possibile quindi creare una macchina (fisica o virtuale) dove installiamo tutti gli aggiornamenti, le patch del sistema operativo e tutti i software necessari, e catturarne l’immagine per poi utilizzarla come sistema operativo di base da distribuire.

Prima di catturare l’immagine dalla macchina master è fondamentale che questa sia generalizzata. L’immagine deve essere priva quindi di tutto quello che riguarda informazioni sull’hardware, sui driver, sull’eventuale dominio, sulla licenza e su tutto quello che identifichi in qualche modo la macchina stessa. Per generalizzare l’immagine utilizziamo un tool incluso in Windows chiamato Sysprep. Avviamo sulla macchina master l’eseguibile sysprep.exe che troviamo in c:\windows\system32\sysprep, selezionamo “Generalizza” e chiediamo che al termine il sistema debba essere arrestato. Clicchiamo su OK ed attendiamo qualche minuto. La macchina si spegnerà e sarà pronta per essere catturata.

Per poter catturare l’immagine è necessario aggiungere al WDS una particolare immagine di boot, con la funzione di cattura, che viene creata automaticamente a partire dalla normale immagine di boot, selezionando dal menu contestuale “Crea immagine di Cattura. Avviando con boot da rete la macchina client e selezionando l’immagine di cattura al boot partirà un Wizard che permetterà di catturare lo stato della macchina stessa ed aggiungerla al WDS come immagine.

Distribuzione

Ora che il nostro server PXE è configurato per rispondere a tutte le richieste, abbiamo inserito le opzioni nel DHCP, abbiamo configurato un’immagine di boot ed una di installazione possiamo provare ad avviare con boot da rete un client ed effettuare la nostra prima distribuzione dell’immagine della macchina Windows 10 appena catturata.

Se stiamo utilizzando Hyper-V ricordiamo che le macchine di generazione 1 hanno bisogno di una scheda di rete Legacy per effettuare il boot da rete, quelle di Generazione 2 possono farlo con la scheda di default.

Avviamo quindi la macchina con boot da rete e vediamo che questa ottiene un IP ed alla pressione del tasto F12 inizia a ricevere l’immagine di WinPE

Completato l’avvio sarà visibile l’elenco delle immagini di installazione disponibili all’interno del server WDS, selezionando l’immagine desiderata. Partirà a questo punto l’installazione del tutto uguale a quella che siamo abituati a vedere avviando il client con il DVD di Windows 10. Alla fine dell’installazione, quindi, avremo il client con tutti i nostri software già installati ed utilizzabili. Se utilizziamo WDS integrato in Active Directory, se non lo abbiamo specificato diversamente questo client sarà già incluso nel dominio.

Drivers

Il server WDS consente di installare delle immagini in modo assolutamente indipendente dall’hardware poiché quelle che vengono installate sono delle immagini generalizzate del sistema operativo. I driver necessari vengono quindi inclusi durante l’installazione, e devono quindi essere disponibili nell’immagine stessa oppure nel repository integrato del WDS. Un’altra caratteristica molto interessante del servizio di distribuzione è quella di gestire autonomamente i driver da includere durante la distribuzione delle immagini. Per popolare il repository è sufficiente cliccare con il tasto destro sulla sezione driver e selezionare “Aggiungi pacchetto driver”

Successivamente si dovrà indicare la posizione contenente i driver da aggiungere (è sufficiente indicare il file .inf desiderato) ed il sistema li includerà durante l’installazione nel caso sia richiesto. E’ possibile aggiungere i driver a partire da una cartella radice ed il server WDS individuerà tutti i driver presenti in quella cartella ed in tutte le sottocartelle, aggiungendole al repository. E’ possibile anche organizzare i pacchetti di driver in gruppi, gestendo ad esempio un gruppo per ogni modello di client in modo da includere durante l’installazione solo i driver strettamente necessari, evitando di far aumentare la grandezza dell’immagine stessa.

Multicast

Una delle funzionalità che rende WDS un servizio fondamentale in alcuni scenari è la trasmissione delle immagini in multicast. Questa funzionalità permette di inviare un’unica immagine a più client contemporaneamente, potendo dividere questi client in tre gruppi a seconda della velocità di trasmissione. Questa funzione risulta molto utile quindi in tutte quelle occasioni in cui è necessario installare molti client nello stesso momento; uno scenario su tutti è quello di un’aula corsi, all’interno della quale può essere utile ad ogni corso reinstallare le macchine con l’immagine predefinita che potrebbe essere diversa di corso in corso. Avendo una immagine master per ogni occasione si potrebbero installare centinaia di computer con una singola operazione. E’ possibile configurare la trasmissione multicast per iniziare manualmente o quando un certo numero di client sono entrati nella coda di attesa.

Per configurare una trasmissione multicast è sufficiente selezionare “Nuova trasmissione multicast” dal menu contestuale “Trasmissioni multicast” e configurare le opzioni relative all’indirizzamento IP ed alla velocità del client.

File di risposta automatica

Come accennato in precedenza è possibile per ogni immagine definire una serie di regole per la configurazione dei client su cui verrà distribuita. Queste regole vengono definite seguendo un modello attraverso un file di risposte automatiche in formato XML. Tra le proprietà dell’immagine di installazione è possibile assegnare il file di risposte automatiche che verrà elaborato in fase di installazione. Selezionare “Permetti l’installazione dell’immagine in modalità unattended” e scegliere il file xml.

All’interno del file di risposte automatiche è possibile configurare praticamente tutte le opzioni di personalizzazione della macchina da distribuire, il numero e la dimensione delle partizioni, il codice del sistema operativo, il dominio da joinare, il nome macchina e una moltitudine di altre personalizzazioni. La creazione di questo file è una procedura abbastanza complessa, ma in alcuni scenari può servire ad automatizzare configurazioni complesse e replicarle poi infinite volte. La creazione del file da zero richiede l’utilizzo del tool Windows Assessment and Deployment Kit (Windows ADK) scaricabile dalla pagina https://developer.microsoft.com/it-it/windows/hardware/windows-assessment-deployment-kit. Dopo aver installato ed avviato il toolkit sarà possibile selezionare nuovo -> file di risposte, selezionare le opzioni desiderate e salvare il file xml da dare in pasto al server WDS.

Conclusioni

Purtroppo racchiudere tutte le potenzialità del servizio WDS in un articolo, accompagnando lo stesso da una guida sulla sua configurazione potrebbe sicuramente confondere un po’ le idee, ma invito tutti coloro che gestiscono delle infrastrutture con più di 5 client e coloro che lavorano in ambito assistenza tecnica IT a provare ad utilizzarlo. Sono pronto a scommettere che non potrete più farne a meno.

Active Directory rappresenta il cuore delle moderne infrastrutture Windows basate su sistemi operativi Windows.

Nel meetup del 15 febbraio organizzato da Torino Technologies Group in collaborazione con ICTPower.it Ermanno Goletto (MVP Cloud and Datacenter Management) e Roberto Massa (MVP Cloud and Datacenter Management) analizzeranno in modo dettagliato i componenti di Active Directory il loro impatto sul sistema in caso di malfunzionamento.

Inoltre verranno approfondite le Best Practices e gli strumenti a disposizione nelle varie versioni di Windows Server per eseguire il troubleshooting e il disaster recovery di Active Directory.

L’evento inizia alle 18 e termina alle 20 e si terrà presso il Microsoft Innovation Center (MIC) di Torino in c/o ISMB Via Pier Carlo Boggio 61 10138 Torino. Dopo le 20.00 per chi desidera continuare a chiacchierare può concludere la serata in pizzeria.

Di seguito l’agenda della sessione:

Troubleshooting del DNS
Troubleshooting di AD DS e della Replica AD
Troubleshooting della Replica SYSVOL
Scenari di Disaster Recovery
Restore del System State
Active Directory Snapshots
Active Directory Recycle Bin

Per le informazioni logistiche spotete fare riferimento al seguente link http://www.torinotechnologiesgroup.it/eventi/20180215.

Vi aspettiamo!

Come annunciato, non molto tempo fa, Microsoft ha aggiornato il modello di manutenzione del sistema operativo Windows 10, introducendo il recente canale semestrale. Esso rappresenta l’aggiornamento delle funzionalità del sistema operativo che avrà la cadenza di 2 volte all’anno, indicativamente marzo e settembre. Per gli IT Pro, e i curiosi, ricordiamo che questo canale va a sostituire le opzioni Current Branch (CB) con Canale semestrale (mirato) e Current Branch for Business (CBB) con Canale semestrale già a partire da Windows 10 versione 1703.

In prossimità dell’arrivo di Windows 10 versione 1803 (nome in codice Redstone 4 e ancora senza nome ufficiale), previsto intorno a marzo 2018, vogliamo raccogliere una serie di novità che verranno introdotte in questa nuova versione di Windows 10.

Nota: L’articolo è molto lungo e consigliamo di aggiungerlo tra i vostri Preferiti a mo’ di promemoria.

Timeline (Sequenza Temporale)

Sequenza temporale è una nuova funzionalità che andrà a migliorare le funzionalità di gestione del multitasking del PC. Essa nasce dall’esigenza di poter recuperare tutte quelle attività su cui si è lavorato in passato, dai siti web visitati fino a determinati file modificati nelle varie applicazioni utilizzate.

Timeline introduce un nuovo metodo per recuperare le attività effettuate, in un determinato periodo, sul proprio PC, su altri computer e su dispositivi iOS/Android. La nuova funzione va ad integrarsi in Visualizzazione attività (vedrete una nuova icona), con la possibilità di “muoversi” tra le applicazioni aperte e le attività passate (Figura 1)

Figura 1 – Timeline in azione una volta fatto clic su Visualizzazione attività

Come si può notare, dall’immagine precedente, la visualizzazione sarà divisa in:

• Sezioni organizzate per data con le attività salienti
• Una comoda barra di scorrimento per navigare tra esse
• Una comoda casella ricerca per individuarne di specifiche (in alto a destra).

Per default Timeline registrerà e sincronizzerà, grazie al Cloud, un massimo di 4 giorni di attività. Per avere una sincronizzazione fino a 30 giorni sarà necessario attivare un’opzione specifica tramite il pulsante Attiva presente in basso (Figura 2).

Figura 2 – Opzione per visualizzare più giorni nella sequenza temporale

Nelle Impostazioni > Privacy è presente una nuova sezione dedicata alla Cronologia attività (Figura 3) da dove sarà possibile configurare gli account che utilizzeranno la funzione Timeline, disattivare la funzione oppure cancellare la cronologia delle attività registrate fino a quel momento.

Figura 3 – La nuova sezione Cronologia attività

Il supporto a Timeline sarà aggiunto alla varie applicazioni da parte degli sviluppatori (a questo link le linee guida ufficiali) e per il momento è presente su Edge, Office, alcune Universal Windows App e Cortana (Figura 4). L’assistente vocale di Windows 10 sarà in grado di suggerire alcune attività da riprendere quando cambieremo dispositivo.

Figura 4 – Selezione di un’attività tramite Cortana

Miglioramenti nella Shell e nelle Impostazioni di Windows

Il Fluent Design è sempre più integrato nel sistema, infatti gli effetti Acrylic e Reveal vengono abilitati nel menu Start, nella Taskbar, nella schermata Condividi (Figura 5), nei menu a comparsa di Orologio e Calendario, Volume e Input.

Figura 5 – Fluent Design sempre più presente

Elenco cartelle nel menu Start personalizzabile. Per andare incontro a coloro che stanno ancora aggiornando a Windows 10, per la prima volta, Microsoft sta ulteriormente semplificando la navigazione verso le risorse presenti sul PC visualizzando i collegamenti rapidi delle cartelle Documenti e Immagini nel menu Start per impostazione predefinita. Era già presente questa possibilità, ma “probabilmente” era poco intuitiva e individuabile.

Se si vuole ulteriormente personalizzare l’elenco delle cartelle sarà sufficiente fare clic con il pulsante destro del mouse su un qualsiasi elemento presente e comparirà un collegamento diretto alle Impostazioni di Personalizzazione (Figura 6).

Figura 6 – Personalizzazione delle cartelle visibili nel menu Start

Stati di OneDrive nel Riquadro di spostamento. Nel pannello laterale di Esplora File può essere mostrato lo stato della sincronizzazione con OneDrive (Figura 7), replicando le icone di stato già viste con l’introduzione dei File su Richiesta in Windows 10 Fall Creators Update.

È possibile attivarli/disattivarli da Opzioni cartella presente nel menu Visualizza. Spostandoci nella scheda Visualizzazione > Impostazioni avanzate > Riquadro di spostamento troveremo la nuova opzione Mostra sempre lo stato di disponibilità (Figura 8).

Figura 7 – Stato di OneDrive direttamente in Esplora Risorse

Figura 8 – Opzione “Mostra sempre lo stato di disponibilità”

Nuovo look per le Impostazioni. Dopo i miglioramenti introdotti in Windows 10 versione 1709, Microsoft ha ridisegnato il nuovo Pannello di Controllo con un occhio all’acuità visiva (Figura 9). Sicuramente la schermata è molto più ordinata.

Figura 9 – Impostazioni di Windows ridisegnato

Non disturbare diventa Assistente notifiche. Con l’espansione della funzionalità Non disturbare, Microsoft cambia il nome in Assistente notifiche e non solo (Figura 10). Con essa sarà possibile:

• Scegliere gli orari in cui non si vuole essere disturbati dalle notifiche.
• Impostare la funzionalità in modo che venga attivata automaticamente in determinati orari oppure quando si sta tenendo una presentazione o eseguendo un gioco, attraverso delle Regole automatiche.
• Consentire alle notifiche con priorità di essere visualizzate, anche con la funzionalità attiva, e visualizzare un riepilogo degli elementi persi al termine dell’orario impostato.
• Nascondere tutte le notifiche ad eccezione delle sveglie.

La tre modalità (Disattivato, Solo priorità, Solo sveglie) saranno selezionabili dal Centro Notifiche, dal relativo pulsante rapido, oppure facendo clic con il tasto destro del mouse sul pulsante per richiamare sempre il Centro notifiche.

Figura 10 – Nuovo Assistente notifiche

Impostazione Accessibilità ridisegnata. Forte attenzione al tema dell’accessibilità da parte di Microsoft. Dopo i numerosi feedback sono state aggiunte nuove impostazioni di accesso facilitato (Figura 11), migliorando le singole descrizioni e raggruppando le varie impostazioni correlate nelle seguenti categorie: Visione, Udito e Interazione.

Figura 11 – Schermata Accessibilità riorganizzata in maniera più semplice per gli utenti

Nuova sezione dedicata ai Caratteri. Nell’ottica di deprecare il vecchio Pannello di Controllo, all’interno di Impostazioni > Personalizzazione viene introdotta una sezione dedicata ai Caratteri (Font) (Figura 12). Cliccando su una delle famiglie di caratteri verrà mostrata una pagina con i dettagli e un’anteprima per ciascuna variante disponibile all’interno della famiglia selezionata (Figura 13). Presenti altre informazioni su ciascun font (Metadati) e la possibilità di disinstallare il font dal sistema.

Insieme alla nuova sezione Caratteri è stata introdotta la possibilità di installare nuovi tipi di carattere attraverso il Microsoft Store (Figura 14). Al momento non ce ne sono tantissimi disponibili, ma fanno sapere che ne arriveranno altri nei mesi a seguire.

Figura 12 – La nuova sezione Caratteri presente nelle Impostazioni di Personalizzazione

Figura 13 – Dettaglio di un Font selezionato

Figura 14 – Sezione Caratteri nel Microsoft Store per l’installazione di nuovi Font

Aggiunta la sezione Audio nelle Impostazioni. I settaggi per l’audio ora sono disponibili in una nuova sezione dedicata all’interno di Impostazioni > Sistema > Audio (Figura 15), con la possibilità di regolare settaggi avanzati per app e dispositivi.

Figura 15 – Nuova sezione Audio all’interno delle Impostazioni di Sistema

Aggiunta la sezione Avvio nelle Impostazioni. L’elenco delle applicazioni configurate per essere eseguite all’avvio del PC, o al login dell’utente, viene gestito tramite la scheda Avvio presente nel Task Manager. Sempre nell’ottica di migliorare le Impostazioni di Windows 10, sarà possibile configurare le applicazioni di avvio dalla sezione presente in Impostazioni > App > Avvio (Figura 16).

Sarà possibile verificare le app disponibili per l’avvio al momento dell’accesso e abilitare / disabilitare ciascuna di esse. Come nella configurazione classica sarà visibile l’impatto che hanno sul tempo di avvio del dispositivo.

Figura 16 – Nuova sezione Avvio all’interno delle Impostazioni delle App

Miglioramenti alla gestione della grafica. Molti dispositivi recenti sono in grado di riprodurre video in modalità HDR (High Dynamic Range), ma devono essere calibrati in fabbrica per abilitare questa opzione. In Windows 10 sarà possibile riprodurre video HDR tramite nuove funzionalità presenti in Impostazioni > App > Riproduzione video (Figura 17). Se l’hardware lo consente sarà possibile abilitare l’elaborazione automatica del video per migliorarne la resa visiva.

Figura 17 – Nuova sezione Riproduzione video dedicata alle impostazioni vide per le app che utilizzano la piattaforma integrata di Windows

Nuove impostazioni per i sistemi Multi-GPU. Presente nelle impostazioni grafica una nuova pagina per i sistemi Multi-GPU (sistemi con più schede grafiche) la quale consentirà di gestire la preferenza delle prestazioni grafiche di app specifiche. Sicuramente molti hanno familiarità con impostazioni simili di AMD e Nvidia (tranquilli, continueranno a funzionare), ma se la preferenza sarà indicata da questa nuova area essa avrà la precedenza sulle altre. La pagina è presente in Impostazioni > Sistema > Schermo > (scorrendo verso il basso) > Impostazioni grafica (Figura 18).

Per utilizzare questa personalizzazione sarà sufficiente scegliere un’applicazione per impostare la relativa preferenza:

• Selezionando App classica avremo la possibilità di selezionare una classica app Win32 presente nel sistema
• Selezionando App universale avremo la possibilità di un’applicazione UWP da un elenco.

Per impostazione predefinita, l’applicazione aggiunta ha una preferenza Predefinito, ovvero il sistema decide autonomamente la migliore GPU da assegnare all’applicazione.

Cliccando sull’applicazione e sul pulsante Opzioni si potrà scegliere la GPU con risparmio energia o la GPU ad alte prestazioni (Figura 19).

Figura 18 – Nuova sezione dedicata alle Impostazioni grafica

Figura 19 – Schermata in cui si può selezionare una scheda grafica per una specifica app

Perfezionata la sezione Area geografica & Lingua. Finalmente viene migliorata la sezione Area geografica e lingua, con l’introduzione di una serie di indicazioni per ogni lingua (Figura 20). Queste sono utili ad indicare le varie opzioni disponibili come Lingua di visualizzazione, Sintesi vocale, Riconoscimento vocale e Riconoscimento grafia (Figura 21).

Figura 20 – Sezione Area geografica e lingua migliorata con più indicazioni per ogni lingua

Figura 21 – Schermata con le lingue da installare e le varie opzioni disponibili

Impostazioni per le connessioni dati con rete cellulare. Viene inserita la possibilità di preferire l’uso della rete Cellulare a quella Wi-Fi (Figura 22), favorendo (ad esempio) le connessioni 4G LTE (o superiori) e coloro che possiedono piani dati illimitati. Ricordiamo che la sezione è visibile solo utilizzando dispositivi compatibili.

Figura 22 – Sezione Cellular dedicata a quei dispositivi in cui è presente la parte telefonica per la connessione dati

Migliorata la gestione dello spazio disco.
Uno strumento molto comodo presente in Windows dai tempi di XP è Pulizia Disco. Esso permette di eliminare elementi inutili dal disco come i file temporanei o le anteprime delle immagini. Ora è stato integrato nelle nuove Impostazioni e la si può raggiungere da Impostazioni > Sistema > Archiviazione > Libera spazio ora (Figura 23).

Figura 23 – Libera spazio ora in azione come il “vecchio” Pulizia Disco

Migliorate le specifiche e le autorizzazioni. Le Opzioni avanzate di ogni singola app sono state aggiornate in modo da contenere le rispettive specifiche come il numero di versione dell’app per un facile riferimento. Dalla stessa schermata sarà possibile autorizzare quali app UWP possono accedere, ad esempio, ai contatti o alla fotocamera (Figura 24). Aggiunti anche dei link diretti per verificare il consumo della batteria e l’esecuzione in background, e configurare le notifiche nella schermata di blocco.

Come promemoria, il modo più semplice per accedere alla pagina delle impostazioni di una particolare app UWP è fare clic con il tasto destro del mouse sull’app nel menu Start e selezionare Altro > Impostazioni app.

Figura 24 – Nuova schermata dedicata alle specifiche e autorizzazioni per singola app

Pannello Emoji disponibile per più lingue. Il pannello utile ad inserire le Emoji in una qualsiasi casella di testo, o simile, è finalmente disponibile anche per le altre lingue compreso l’italiano (Figura 25). Per richiamarlo è sufficiente premere Tasto Windows + punto (.)

Figura 25 – Pannello Emoji in azione

Miglioramenti in Microsoft Edge

Il “nuovo” browser di Microsoft riceve una serie di aggiornamenti atti a migliorare l’aspetto estetico, l’esperienza d’uso “classica” (ovvero la navigazione sui siti web), l’organizzazione delle sezioni importanti e la lettura di file PDF e/o EPUB. Iniziamo dal nuovo tema scuro (c’era già, ma questo è ancora più scuro con contrasti migliori), e dall’introduzione dell’effetto Reveal e dello sfondo traslucido Acrylic provenienti dal nuovo Fluent Design (Figura 26).

Figura 26 – Miglioramenti del Fluent Design in Edge

Miglioramenti importanti nell’Hub (Preferiti, Elenco di lettura, Cronologia e Download) con una nuova schermata più ordinata, intuitiva e personalizzabile (Figura 27).

Figura 27 – Hub (Preferiti, Elenco di lettura, Cronologia e Download) migliorato

DevTools ancorabili a destra. Gli strumenti utili agli sviluppatori (F12) per analizzare una pagina web possono essere ancorati anche verticalmente, a destra, attraverso un piccolo pulsante in alto a destra. Questo miglioramento soddisfa una forte richiesta da parte di moltissimi sviluppatori web.

Figura 28 – DevTools ancorato verticalmente a destra

Stampa senza elementi superflui. Finalmente è possibile stampare pagine Web da Microsoft Edge senza pubblicità e altri elementi di confusione. Nella finestra di dialogo per la stampa sarà sufficiente impostare l’opzione Stampa senza elementi superflui, dal menu a tendina, su Attivata (Figura 29). Ovviamente questa opzione sarà visibile solo per determinati tipi di pagine web.

Figura 29 – Esempio di stampa con la funzione “Stampa senza elementi superflui” impostata su Attivata

Nuova esperienza di lettura per i file EPUB, PDF e visualizzazione di lettura. In Windows 10 versione 1803 troveremo nuove funzionalità e nuove esperienze per la lettura dei Libri in Microsoft Edge, compresi un menu a comparsa Note (Figura 30), Strumenti grammaticali per libri EPUB (Figura 31) e visualizzazione di lettura (Figura 32), un’esperienza di lettura a schermo intero, e tante altre ancora.

Figura 30 – Menu a comparsa Note con l’elenco di quelle che abbiamo creato

Figura 31 – Strumenti grammaticali in azione con la funzione evidenzia verbi attivata

Figura 32 – Visualizzazione del libro a schermo intero per una lettura immersiva

Miglioramenti in Sicurezza e Privacy

Aggiornamento di Windows Defender Application Guard (WDAG). Introdotto con Fall Creators Update e disponibile soltanto per l’edizione
Enterprise di Windows 10, WDAG è un sistema di protezione per Microsoft Edge che offre una protezione senza precedenti contro le minacce mirate utilizzando la tecnologia di virtualizzazione Hyper-V (Figura 33). Esso funziona isolando il browser dal resto del sistema, in modo da proteggere il PC da possibili attacchi sofisticati tramite il browser.

Da Windows 10 versione 1803 questa importante funzionalità di sicurezza, per fortuna, viene estesa anche agli utenti Windows 10 Pro.

Figura 33 – Windows Defender Application Guard attivo

Visualizzatore dati di diagnostica. Come ben sappiano Microsoft utilizza i dati diagnostici di Windows per focalizzare l’attenzione sulle decisioni da prendere nel miglioramento delle sue piattaforme, tant’è che è possibile indicare in fase di prima installazione/attivazione, del sistema operativo, la misura dell’invio dei dati diagnostici scegliendo fra Base o Completo. Ne abbiamo parlato in questo articolo dedicato.

L’azienda di Redmond, impegnata continuamente ad essere il più trasparente possibile sui dati diagnostici raccolti dai dispositivi Windows e fornire un maggiore controllo su tali dati, introduce due nuove funzionalità collocate in Impostazioni > Privacy > Feedback e diagnostica (Figura 34). Innanzitutto viene data la possibilità di attivare un’app (da installare tramite il Microsoft Store) (Figura 35), per la Visualizzazione dei dati di diagnostica in maniera più dettagliata e tramite ricerca (Figura 36); in aggiunta sarà possibile Eliminare i dati di diagnostica raccolti da Microsoft sul dispositivo attraverso un pulsante dedicato.

Si tratta di miglioramenti che dovrebbero andare incontro alle continue (e lecite) critiche rivolte a Microsoft per aver introdotto, in Windows 10 e altri servizi, un meccanismo di trasmissione / raccolta di dati spesso poco chiaro e trasparente per gli utenti.

Figura 34 – Feedback e diagnostica nelle impostazioni della Privacy

Figura 35 – App “Visualizzatore dati di diagnostica” presente nel Microsoft Store

Figura 36 – Esempio del dettaglio di un dato diagnostico

Riquadro delle impostazioni sulla Privacy aggiornato. Per migliorare l’impatto visivo sono state aggiunte nuove categorie nel riquadro di navigazione delle impostazioni sulla Privacy (Figura 37).

Figura 37 – Riquadro Privacy ridisegnato

Windows Defender ora è Sicurezza di Windows. È stata rinominata la pagina delle impostazioni per Windows Defender Antivirus in Impostazioni > Aggiornamento e sicurezza da Windows Defender a Sicurezza di Windows. La pagina è stata completamente ridisegnata, in modo da avere un rapido accesso alle varie Aree di protezione (Figura 38).

Figura 38 – Sezione “Sicurezza di Windows”

Configurazione di Windows Hello più semplice. Ora è possibile impostare il riconoscimento del volto, le impronte digitali o il PIN di Windows Hello direttamente dalla schermata di blocco facendo clic sul riquadro di Windows Hello in Opzioni di accesso (Figura 39).

Figura 39 – Configurazione di Windows Hello dalla schermata di blocco

Domande di sicurezza anche per gli account locali. Generalmente quando ci dimentichiamo la password di un servizio online, se configurato opportunamente, il sistema potrebbe proporci di inserire e, successivamente, rispondere a delle domande sulla sicurezza in modo da verificare la nostra identità. In Windows 10 1803 questa possibilità verrà estesa anche agli account locali in fase di prima installazione, aggiunta di un account al PC (Figura 40) e come configurazione nella sezione Opzione di accesso > Password (Figura 41).

Figura 40 – Richiesta d’inserimento domande di sicurezza durante la creazione di un nuovo account utente

Figura 41 – Aggiornamento domande di sicurezza di un utente esistente

Miglioramenti per Professionisti IT e varie

Nuova API della piattaforma Windows Hypervisor. È stata aggiunta un’API in modalità utente estesa per gli stack e le applicazioni di virtualizzazione di terze parti, che consente di creare e gestire le partizioni a livello di Hypervisor, configurare i mapping di memoria per la partizione e, creare e controllare l’esecuzione dei processori virtuali (Figura 42). Per maggiori dettagli vi consigliamo di andare a questo link.

Figura 42 – Schema della nuova API aggiunta nella piattaforma Windows Hypervisor

Aggiunte nuove Policy dedicate alla Ottimizzazione recapito per limitare la larghezza di banda massima di tutte quelle attività di download, in primo piano o in background, su determinate fasce orarie della giornata, limitare la selezione dei Peer (al momento) alla stessa sottorete, e molte altre. Le nuove policy sono editabili in Administrative Templates > Windows Components > Delivery Optimization (Figura 43).

Figura 43 – Nuove Policy dedicate alla “Ottimizzazione recapito”

Nuova combinazione per il risparmio energia in Windows 10 Pro for Workstations. Nella nuova edizione di Windows 10, introdotta con Fall Creators Update e dedicata a PC di fascia molto alta, viene aggiunta una combinazione di “risparmio energia” dedicata a tutti coloro che vogliono sfruttare al massimo tutte le potenzialità dell’hardware in possesso senza compromessi (Figura 44).

Microsoft assicura che, utilizzando questa combinazione Ultimate Performance, saranno eliminate tutte quelle micro-latenze che possono impattare direttamente sull’hardware; naturalmente questa opzione consuma molta più energia rispetto alla combinazione di default. Al momento non è disponibile su sistemi alimentati a batteria.

Figura 44 – Nuova combinazione di risparmio energia per Windows 10 Pro for Workstations

Focus sulla produttività in Windows 10 Pro for Workstations. Nell’aggiornamento di Windows 10 Fall Creators, l’esperienza out of the box per Windows 10 Pro for Workstations si basa sulla versione Pro di Windows 10. Nella prossima versione di Windows, all’interno del menu Start saranno presenti applicazioni incentrate su produttività e azienda (Figura 45), al posto delle applicazioni e dei giochi dedicate più ai consumatori.

Figura 45 – Focus sulla produttività nel menu Start di Windows 10 Pro for Workstations

Gruppo Home deprecato. A partire da questa versione il servizio Gruppo Home non sarà più operativo in Windows 10 (Figura 46). Microsoft consiglia di sfruttare funzionalità più moderne come la nuova Condivisione e OneDrive. Il profilo utente utilizzato per la condivisione e le condivisioni di file / cartelle / stampanti continueranno a funzionare.

Figura 46 – La funzionalità Gruppo Home in Windows 10 Fall Creators Update

Queste sono tutte le novità più salienti che troveremo nella prossima versione di Windows 10, la 1803. Per approfondire vi lasciamo gli articoli di riferimento direttamente dal Blog di Windows:

• Build 17017
• Build 17025
• Build 17035
• Build 17040
• Build 17046
• Build 17063
• Build 17074
• Build 17083
• Build 17093
• Build 17101

Come abbiamo già avuto modo di analizzare in articoli precedenti, Let’s Encrypt, in quanto CA, permette anche il rilascio di certificati di tipo SAN (Subjet Alternative Names), ossia certificati che sono emessi e quindi sono validi per più nomi host di uno stesso dominio oppure per nomi host differenti di domini differenti.

La possibilità di ottenere certificati come indicato, non è da confondere con l’emissione di certificati di tipo Wildcard (*) ossia di un certificato valido per tutti gli host di un singolo dominio

Sono esempi di certificati di tipo SAN rilasciati da Let’s Encrypt i seguenti

• mail.robimassa.cloud
• autodiscover.robimassa.cloud

esempi di certificati per uno stesso dominio ma per host differenti

• web.robimassa.it
• portale.robimassa.cloud

esempi di certificati per host in domini differenti.

Per quanto riguarda i certificati Wildcard, Let’s Encrypt ha annunciato che nel gennaio del 2018 avrebbe emesso questo tipo di certificati, ma recentemente stato pubblicato un annuncio che informa dello slittamento del rilascio di questa funzione.

Exchange può utilizzare certificati di questo tipo emessi da Let’s Encrypt

Nel caso di questo sevizio, per l’accesso alle risorse mail dobbiamo dichiarare in DNS un record di tipo “A” riferito al portale webmail, ed un record, sempre di tipo “A” con nome autodiscover

Per una descrizione più dettagliata sull’uso e sulla funzione di questa informazione dichiarata in DNS è possibile leggere l’articolo Autodiscover service

In modo molto semplicistico possiamo dire che l’informazione ottenuta con “autodiscover” sia essa in un record di tipo A o in un record di tipo SRV permette una identificazione automatica di risorse di servizi di collaborazione come Exchange a partire da un indirizzo mail in formato utente@dominio.com.

Fatta questa premessa, passiamo ad analizzare in quale modalità è possibile ottenere certificati di tipo SAN con Let’s Encrypt

In ambiente Windows è utilizzabile il tool Let’s Encrypt-win-simple di Lone Coder, che proprio recentemente ha cambiato il nome del proprio programma

New name

This is the first release of this program under a new name. Going forward we will call it “Windows ACME Simple”, which can be shortened to “win-acme” or “WACS”. The reason is that we want to avoid any confusion people might have about this programs relationship with the ISRG sponsored Let’s Encrypt project.

To be clear, we are not an ISRG supported client, just an independent group of people who want to help people managing Microsoft Windows machines to secure the web.

Let’s Encrypt literally wrote the book on the ACME protocol and is obviously the most popular service implementing it, but in fact everyone is free to run their own ACME server and we might see a lot more of them in the future. Therefore it also makes sense to drop “Let’s Encrypt” from the name of this program.

Per effettuare la richiesta del certificato alla CA è necessario scaricare il tool da github e copiarlo localmente per poi estrarre il contenuto.

Il client ACME (Automatic Certificate Management Environment) quale è appunto win-acme, è gestibile a riga di comando, pertanto dovremo prima creare una cartella in cui saranno salvati i certificati in formato .pfx rilasciati dalla CA e successivamente eseguire il comando letsencrypt.exe –centralsslstore C:\letsencrypt-san\

L’opzione –centralsslstore è utilizzata per
definire il percorso per il salvataggio dei certificati che dovranno poi essere importati in Exchange tramite Powershell

Figura 1 richiesta certificato

Dovremo selezionare la modalità per il rilascio di nuovi certificati con opzioni avanzate “M” e successivamente specificare i vari nomi fqdn per cui stiamo richiedendo i certificati, ognuno separato da virgola nell’esempio che è indicato la richiesta è per l’host mail.robimassa.cloud ed autodiscover.robimassa.cloud

Figura 2 Impostazioni per la validazione

Successivamente verrà chiesta la modalità di validazione, ed il modo più rapido, se si esegue la richiesta dei certificati da un server IIS, è di consentire la verifica automatica direttamente tramite il server Web.

Procedendo con la richiesta vera e propria, e conclusa la procedura, nella cartella C:\letsencrypt-san\ troviamo i due certificati in formato PFX, uno per sito.

Sarà sufficiente procedere all’importazione del certificato in IIS che verrà utilizzato per OWA

Figura 3importazione certificato in IIS

Oppure in caso di sistemi distribuiti su più Web Server Bilanciati, utilizzare la funzione di centralized ssl certificate support a questo punto il https è attivo con il certificato SAN segnato per i due host

Importazione del certificato in Exchange

Per quanto riguarda invece l’importazione dei certificati in Exchange sarà necessario eseguire il cmd-let Powershell Import-ExchangeCertificate come descritto in questo articolo.

Metodi di validazione alternativi

Esistono altri metodi di validazione da parte di Lets’Encrypt per determinare che il richiedente del certificato sia effettivamente il proprietario del dominio, uno di questi è il metodo basato su DNS.

Il client Acme in questo caso si deve “appoggiare” ad un programma esterno che ricevendo in input I parametri corretti si occupa di creare sul DNS il TXT record opportunamente configurato. Questo record, sarà poi letto dalla CA prima dell’emissione dei certificati.

Siccome il processo di rinnovo è automatizzato e quindi eseguito periodicamente alla scadenza dei certificati, il servizio DNS deve poter consentire un interoperabilità di questo tipo.

E’ consigliabile quindi la verifica della disponibiltà di automazione da parte del DNS.

Figura 4 validazione tramite DNS

Figura 5 certificato SAN

Considerazioni

Anche in questo caso Let’s Encrypt si dimostra una Certification Authority che in modo gratuito permette di attivare i protocolli di sicurezza sui propri servizi. Come già detto in precedenza, è di prossimo rilascio l’emissione di certificati WildCard, che completerà l’offerta dei servizi della CA.

Riferimenti

https://letsencrypt.org/

https://www.ictpower.it/guide/utilizzo-e-configurazione-di-lets-encrypt-in-ambiente-linuxapache.htm

Il prossimo 14 marzo 2018 si terrà un evento gratuito nell’Aula 2 del Palazzo delle Aule presso il Campus universitario “Ernesto Quagliariello” in via Orabona 4 – Bari.

Organizzato dalla Community ICT Power, con la partecipazione di DotNetSide, in collaborazione con Studenti Indipendenti, Università di Bari e Microsoft Student Partner, vedrà la partecipazione di studenti, professionisti e curiosi.

L’evento apre di fatto il primo ciclo di conferenze POWERCON, che storicamente rappresenta il marchio degli incontri formativi organizzati dalla Community ICTPower.

• Vito Macina (Microsoft Most Valuable Professional e Digital Strategist) e Gianluca Nanoia (Microsoft Most Valuable Professional e Security Expert), membri della Community ICT Power, vi faranno conoscere Windows 10 oltre ogni limite, dando particolare rilievo alle ultime novità introdotte nell’ultima versione Fall Creators Update e mostrandovi qualche anteprima della prossima
• Fabio Cozzolino, fondatore della Community DotNetSide, ci mostrerà le Connected Mobile Apps attraverso l’utilizzo di Microsoft Azure
• Giulio Mallardi (Solution Architect), anch’egli membro di ICT Power, ci parlerà di come il Cloud sia diventato un punto fondamentale per lo sviluppo di soluzioni innovative.

Vi aspettiamo quindi il 14 marzo dalle 15:00 alle 18:30 al Campus universitario.

Non mancate!

ISCRIZIONE NON RICHIESTA