Da qualche mese è disponibile il Remote Desktop Web Client, un client html5 per poter accedere in remoto ad un’infrastruttura di Remote Desktop Services e di RemoteApp.

Abbiamo già visto nell’articolo Creare una farm di Remote Desktop Services in Microsoft Azure quanto sia facile costruire un ambiente di test basato su RDS in Windows Server 2012 R2 o in Windows Server 2016 utilizzando delle macchine virtuali ospitate in Microsoft Azure. Se volete invece creare la farm RDS on-premises potete seguire le indicazioni contenute nella guida Distribuire l’ambiente Desktop remoto

Per accedere direttamente alle applicazioni installate ed eseguite in remoto in un server terminal (RemoteApp), che quando vengono lanciate sembra che siano eseguite sul pc dell’utente come se fossero delle applicazioni locali, allora potete leggere la guida Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016

In questo articolo utilizzeremo la farm RDS realizzata in Azure per installare il Remote Desktop Web Client, che offre un’esperienza più fluida quando ci si connette da un browser supportato e che permette agli utenti di accedere ai desktop VDI o RDS oppure alle RemoteApp semplicemente conoscendo l’URL dell’RDS Web Access, da macchine con sistema operativo Windows, Mac OS, ChromeOS o Linux.

Prerequisiti per l’installazione del Remote Desktop Web Client

Prima di procedere all’installazione del Remote Desktop Web Client sono necessari i seguenti prerequisiti:

• La Farm RDS deve utilizzare come sistema operativo Windows Server 2016 oppure Windows Server 2019
• La Farm RDS deve avere un RD Gateway, un RD Connection Broker e un RD Web Access
• Assicuratevi di utilizzare licenze CAL  per-user client access licenses (CALs) invece che per-device, altrimenti verranno attivate tutte le licenze
• Installate la KB4025334
  sulla macchina con il ruolo di RD Gateway
  
• Installate un certificato pubblico sulle macchine con il ruolo di RD Gateway e RD Web Access
  

Installazione del Remote Desktop Web Client

Prima di procedere all’installazione del Remote Desktop Web Client sulla macchina con il ruolo di RD Web Access sarà necessario procurarsi il certificato digitale installato sulla macchina RD Connection Broker ed esportarlo in formato .cer

Il certificato, dopo essere stato copiato sulla macchina RD Web Access, verrà utilizzato al momento dell’installazione del client

Da Esegui lanciate il comando certlm.msc per aprire la console dei Certificati Computer e dal ramo Remote Desktop esportate il certificato del RD Connection Broker (nel mio caso broker.ictpower.lab) in formato .cer

Figura 1: Esportazione del certificato dalla macchina RD Connection Broker

Copiate il certificato esportato sulla macchina con il ruolo di RD Web Access.

L’installazione del Remote Desktop Web Client è possibile solo tramite PowerShell, scaricando il package direttamente dalla PowerShell Gallery. Prima di procedere all’installazione del client, se utilizzate Windows Server 2016 è necessario aggiornare il modulo PowerShellGet con il comando

#Aggiornamento del modulo PowerShell PowerShellGet per supportare l'installazione del modulo di Remote Desktop web client management
Install-Module -Name PowerShellGet -Force

Figura 2: Aggiornamento del modulo PowerShellGet

IMPORTANTE: Procedete a riavviare la sessione di PowerShell prima di procedere.

Dopo aver riavviato la sessione potete installare il modulo PowerShell per il Remote Desktop web client management scaricandolo dalla PowerShell Gallery con il comando

#Installazione del modulo PowerShell per Remote Desktop web client management dalla PowerShell gallery
Install-Module -Name RDWebClientManagement

Figura 3: Installazione del modulo PowerShell per il Remote Desktop web client management

Accettate la licenza e scaricate l’ultima versione del Remote Desktop web client con il comando

#Download dell'ultima versione del Remote Desktop web client
Install-RDWebClientPackage

Figura 4: Download dell’ultima versione del Remote Desktop web client

Procedete quindi a configurare il Remote Desktop web client con il certificato che avete precedentemente esportato dal Remote Desktop Connection Broker. Io lo avevo salvato in C: nella macchina RD Web Access.

#Importazione del certificato del Remote Desktop Connection Broker
Import-RDWebClientBrokerCert "C:\broker.cer"

Figura 5: Importazione del certificato del Remote Desktop Connection Broker

Infine, non vi resta altro che pubblicare il Remote Desktop web client con il comando

#Pubblicazione del Remote Desktop Web Client
Publish-RDWebClientPackage -Type Production -Latest

Riceverete il WARNING: Using the Remote Desktop web client with per-device licensing is not supported anche se avete già configurato il vostro ambiente RDS per l’utilizzo delle CAL per-user

Figura 6: Pubblicazione del Remote Desktop Web Client

Per visualizzare tutti i comandi disponibili nel modulo PowerShell di Remote Desktop web client management potete eseguire il comando Get-Command -Module RDWebClientManagement

Figura 7: Comandi disponibili nel modulo PowerShell di Remote Desktop web client management

Connessione alla Farm RDS utilizzando il Remote Desktop web client

Per connettervi alla Farm RDS utilizzando il Remote Desktop web client vi basterà utilizzare il collegamento https://server_fqdn/RDWeb/webclient, facendo attenzione ad utilizzare il nome pubblico che appare nel certificato che avete installato nel RD Web Access. Nel mio caso è https://rds2019.ictpower.it/rdweb/webclient

Sotto sono mostrate le diverse schermate che appaiono quando effettuate l’accesso ad una RemoteApp

Figura 8: Autenticazione alla pagina del Remote Desktop Web Client

Figura 9: RemoteApp disponibili nella Farm RDS

Figura 10: Accesso alla RemoteApp e richiesta di redirect di stampanti e appunti dal client con cui vi connettete

Figura 11: Lancio della RemoteApp Word 2019

Figura 12: Connessione a Word 2019 effettuata tramite RemoteApp

L’accesso tramite Remote Desktop Web Client è possibile da sistemi operativi Windows, Mac OS, ChromeOS o Linux utilizzando i browser Edge, Internet Explorer 11, Google Chrome, Safari o Mozilla Firefox (v55.0 e versioni successive). Al momento non sono supportati di dispositivi mobili. Nelle schermate sotto potete visualizzare l’accesso alla farm RDS e alle RemoteApp utilizzando Ubuntu 18.10 e il browser Mozilla Firefox:

Figura 13: Connessione a Word 2019 tramite RemoteApp da Firefox installato in Ubuntu 18.10

Figura 14: Connessione effettuata a Word 2019 tramite RemoteApp da Firefox installato in Ubuntu 18.10

Conclusioni

Il Remote Desktop Web Client utilizza HTML5 per fornire un’esperienza utente migliorata, grazie all’integrazione con i nuovi browser. Non sarà quindi necessario installare sulle macchine Windows, Mac OS, ChromeOS o Linux nessun tipo di client ma basterà utilizzare i browser Edge, Internet Explorer 11, Google Chrome, Safari o Mozilla Firefox (v55.0 e versioni successive). Al momento non sono supportati di dispositivi mobili.

Per maggior informazioni su Remote Desktop Web Client vi rimando alla pagina https://docs.microsoft.com/it-it/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin

Per rimanere sempre aggiornati sulle versioni disponibili e sulle funzionalità potete visitare la pagina What’s new for the Remote Desktop web client?

Il 26 Marzo è stata annunciato Windows Admin Center Preview 1903.

Questo aggiornamento comprende una nuova serie funzionalità basate sui feedback degli utenti.

Nel dettaglio:

• Notifiche Email – Al primo posto della classifica delle richieste degli utenti;
• Nuova funzionalità per la gestione della sezione “Active Directory Users and Groups” – Seconda classificata;
• Nuova funzionalità di gestione del DHCP – Quinta classificata;
• Nuova funzionalità di gestione del DNS – Settima classificata;

Al sesto posto, la richiesta più gettonata è risultata essere la possibilità di aggiungere connessioni a Windows Admin Center da Active Directory. In questa versione è stata rilasciata la possibilità di effettuare una ricerca su AD quando si aggiunge una connessione alla lista delle connessioni. Probabilmente nei prossimi rilasci anche questa feature diverrà più completa.

Ultima chicca, il tema scuro (Dark UI), rilasciato nella versione 1812, perde lo status di feature sperimentale ed entra a far parte delle possibili configurazioni presenti nella sezione “settings”.

A differenza delle release precedenti, sono stati superati i problemi che potevano accadere in fase di aggiornamento di un’installazione funzionante. Possiamo, quindi, evitare di disinstallare procedendo direttamente con l’installazione. Al primo accesso verremo informati che l’aggiornamento è stato effettuato con successo.

Figura 1: WAC – Primo accesso

Nuove estensioni

Le estensioni stanno diventano sempre più importanti per quello che WAC vuole essere. In questa release ci sono grosse novità fra cui la notifica di un’estensione disponibile!

Dopo aver aggiunto un nuovo server alla lista delle connessioni, all’apertura del server in oggetto viene mostrata una notifica se è disponibile una estensione non installata relativa a quel server o alle sue funzionalità. Stessa cosa all’apertura di un tool o estensione già installata se è presente un aggiornamento.

Al momento non è possibile disabilitare queste notifiche ma in roadmap, nella prossima release, è stata già pianificata questa funzione per gli utenti che non vorranno riceverle.

Sempre all’apertura della connessione con un server dalla lista delle connessioni, i tool DNS e DHCP saranno visibili solo se i relativi servizi sono effettivamente installati e configurati sul server.

Active Directory

Installando questa estensione apparirà nel menù laterale il nuovo tool

Figura 2: WAC – Active Directory

Le nuove funzionalità sono:

• Creare un nuovo utente
• Gestire le proprietà di base di un utente
• Gestire l’appartenenza ai gruppi
• Ricercare utenti e computer
• Finestra di dettaglio per utenti, gruppi e computer
• Effettuare il reset password di un utente
• Rimuovere utenti e computer
• Configurare Single Sign-on

Quest’ultima feature è possibile utilizzarla, ad esempio, per configurazioni di tipo Constrained Delegation o Resource-based constrained delegation (l’unico requisito è un domain controller Windows Server 2012 o superiore).

Figura 3: WAC – Active Directory

DNS

Anche in questo caso, dopo aver installato l’estensione DNS, nel menù possibile utilizzare il nuovo tool

Figura 4: WAC – DNS

Con questo nuovo tool è possibile:

• Verificare i dettagli delle zone e dei record DNS
• Creare nuove zone: primarie, secondarie, stub o configurarne le proprietà, ad esempio l’aggiornamento dinamico
• Creare Host record, CNAME record, MX record o configurarne le proprietà, ad esempio TTL, FQDN, ecc…
• Creare zone di reverse lookup e relativi record PTR

DHCP

L’ultimo tool da installare è quello relativo al DHCP

Figura 5: WAC – DHCP

In questo caso, le possibilità sono le seguenti:

• Verificare scope IPv4 e IPv6
• Creare scope IPv4 e IPv6
• Configurare proprietà, ad esempio la durata del lease, il range di indirizzi IP, attivare o disattivare scope, ecc…
• Creare indirizzi riservati ed esclusioni

Azure Monitor

Questa nuova feature è stata richiesta a gran voce dagli utenti ed è stata rilasciata integrata ad Azure Monitor. Da questa release è possibile creare delle notifiche personalizzate sullo stato dei server che verranno inviate tramite email. Considerando che con Azure Monitor abbiamo 5GB di dati per mese gratis possiamo effettuare in tranquillità tutti i nostri test su un paio di server.

Per abilitare le queste notifiche lato WAC, è sufficiente accedere su un server e cliccare su “Gestisci Avvisi” (Manage Alerts)

Figura 6: WAC – Panoramica

Tra le funzionalità più interessanti: Se WAC è installato su una VM insights senza Azure Monitor, possiamo utilizzare la Service Map di Azure. Questo approccio permette il discovery automatico delle componenti su Windows e Linux e mappa le comunicazioni tra loro. Per maggiori informazioni è possibile consultare la documentazione ufficiale Microsoft.

Conclusioni

Lo sforzo fatto in termini di sviluppo e, soprattutto, il legame con gli utenti sono gli aspetti che maggiormente stiamo apprezzando. Restiamo in attesa dei prossimi rilasci per continuare ad apprezzare sempre di più questo fantastico prodotto.

Windows Virtual Desktop è un servizio completo (attualmente ancora in Preview) di virtualizzazione di desktop e applicazioni che viene eseguito nel cloud. È possibile connettersi da qualsiasi dispositivo tramite un’applicazione nativa oppure tramite il client Web HTML5 di Windows Virtual Desktop.

Le caratteristiche principali di questo servizio sono:

• I servizi di infrastruttura come gateway, broker e licensing vengono forniti come servizio in Azure. Non è necessario distribuire e gestire alcuna infrastruttura locale.
• Windows Virtual Desktop può utilizzare Azure Active Directory (Azure AD) come provider di identità, consentendo di utilizzare anche l’autenticazione multifattore (MFA) o l’accesso condizionale.
• Una volta che un utente è connesso al servizio Windows Virtual Desktop, l’accesso alle macchine virtuali joinate ad Active Directory verrà fornito utilizzando le identità di Azure AD. Negli ambienti in cui è implementato Active Directory Federation Services (ADFS) per Single Sign-On (SSO), all’utente non verranno richieste le credenziali per la connessione alla VM.
• Nella VM di destinazione non è necessario aprire alcuna porta in ingresso. Anche la porta RDP predefinita, TCP 3389, non deve essere aperta. Un agent installato nella VM crea una connessione in uscita utilizzando la porta TCP 443. Tutto il traffico RDP verrà gestito da un Reverse Proxy in Azure in quanto le macchine virtuali non sono direttamente esposte a Internet. Le VM possono anche essere raggiunte utilizzando un indirizzo IP privato.
• Windows Virtual Desktop usa Windows 10 multi-session di Windows 10 Enterprise, in cui più utenti possono accedere contemporaneamente alla stessa VM client Windows tramite RDP (la multisessione era storicamente possibile solo sui sistemi operativi Windows Server).

Durante l’anteprima pubblica, i desktop e le app possono essere distribuiti in macchine virtuali in qualsiasi area di Azure, mentre la soluzione di gestione e i dati per queste macchine virtuali risiederanno negli Stati Uniti (area West US 2). Per questo motivo potreste avre qualche problema di latenza.

Prerequisiti di Windows Virtual Desktop

Per configurare Windows Virtual Desktop, è necessario avere:

• Una sottoscrizione di Azure con un credito sufficiente (necessario per ospitare le risorse).
• Scaricare e installare le cmdlet di Windows Virtual Desktop per Windows PowerShell su una macchina da cui effettuerete la gestione.
• Assicurarsi che la rete virtuale in Azure (VNET) sia configurata in modo tale che le nuove macchine virtuali possano contattare il controller di dominio o i servizi di dominio di Azure AD (Azure AD Domain Services).
• Assicurarsi che tutte le risorse di Azure si trovino nella stessa regione di Azure.
• Se si richiede SSO (client HTML5 escluso), sarà necessario AD FS o gli utenti dovranno autenticarsi quando si accede alla VM.

Nella figura sotto sono mostrati gli accountnecessari per opoter configurare l’infrastruttura di Windows Virtual Desktop

Figura 1: Account necessari alla configurazione di Windows Virtual Desktop

Assicuratevi anche di avere le licenze appropriate per gli utenti in base al desktop e alle applicazioni che prevedete di distribuire:

I passaggi da effettuare sono i seguenti:

1. Consentire al servizio Windows Virtual Desktop di accedere ad Azure AD.
2. Assegnare il ruolo “TenantCreator” a un account utente.
3. Creare un tenant per Windows Virtual Desktop.
4. Distribuire il primo pool di host per Windows Virtual Desktop.
5. Verificare se un utente può accedere a una sessione desktop.

Consentire al servizio Windows Virtual Desktop di accedere ad Azure AD

Per consentire a Windows Virtual Desktop di accedere ad Azure AD è necessario procurarsi l’ID del tenant da utilizzare. Per farlo collegatevi al portale di Azure e andate in Azure Active Directory > Properties > Directory ID, come mostrato in figura:

Figura 2: Directory ID del nostro tenant di Azure AD

Collegatevi alla pagina https://rdweb.wvd.microsoft.com ed inserite il tenant ID di Azure AD per consentire alla Server App di potervi accedere. In questo modo permetterete al servizio di Windows Virtual Desktop di poter interrogare il vostro tenant di Azure Ad per poter effettuare compiti amministrativi. Effettuate il login e consentite l’accesso.

Figura 3: Consenso alla Server App per l’accesso a Windows Virtual Desktop

Figura 4: Conferma dei permessi per l’accesso alla Server App

Figura 5: Registrazione dell’applicazione Server App completata

Attendete un minuto ed effettuate la stessa operazione per concedere l’accesso alla Client App. Inserite lo stesso Directory ID che avete utilizzato per registrare la Server App

Figura 6: Consenso alla Client App per l’accesso a Windows Virtual Desktop

Figura 7: Conferma dei permessi per l’accesso alla Client App

Figura 8: Registrazione dell’applicazione Client App completata

Assegnare il ruolo TenantCreator a un account utente in Azure AD

Per poter creare un tenant di Windows Virtual Desktop è necessario assegnare i privilegi di TenantCreator ad un utente di Azure AD. Loggatevi al portale di Azure e da Azure Active Directory > Enterprise applications cercate l’applicazione Windows Virtual Desktop. Nella voce Users and groups aggiungete l’utente di Azure AD a cui volete dare i permessi di TenantCreator, come mostrato in figura:

Figura 9: Applicazioni Windows Virtual Desktop in Azure AD

Figura 10: Assegnazione del ruolo di TenantCreator ad un utente di Azure AD

Creare un tenant per Windows Virtual Desktop

Per creare un tenant di Windows Virtual Desktop è necessario dapprima procurarsi il proprio SubScriptionID della sottoscrizione Azure nella quale volete create le VM da utilizzare. Dal portale di Azure vi basterà cliccare sul nodo Subscriptions per verificare al volo l’ID.

Figura 11: Subscription ID della sottoscrizione Azure da utilizzare per la creazione delle VM di Windows Virtual Desktop

Fate riferimento alla pagina https://docs.microsoft.com/it-it/azure/virtual-desktop/tenant-setup-azure-active-directory per ottenere maggiori informazioni sulla creazione del tenant di Windows Virtual Desktop Preview

Per procedure alla creazione del tenant è necessario installare il modulo PowerShell di Windows Virtual Desktop. Nello script sotto viene mostrato come creare il tenant. Sostituite i valori di <ID del TENANT DI AZURE AD> e <ID DELLA SOTTOSCRIZIONE> con quelli che vi siete procurati prima

#Install PowerShell modules
Install-Module -Name Microsoft.RDInfra.RDPowerShell
Import-Module -Name Microsoft.RDInfra.RDPowerShell

# Setting Deployment context
$brokerurl = "https://rdbroker.wvd.microsoft.com"
$aadTenantId = "<ID del TENANT DI AZURE AD>"
$azureSubscriptionId = "<ID DELLA SOTTOSCRIZIONE>"Add-RdsAccount -DeploymentUrl $brokerurl

#create the Windows Virtual Desktop tenant
New-RdsTenant -Name "<Nome del tenant>" -AadTenantId $aadTenantId -AzureSubscriptionId $azureSubscriptionId

Figura 12: Collegamento al Broker di Windows Virtual Desktop

Figura 13: Creazione del nuovo tenant di Windows Virtual Desktop

Distribuire il primo pool di host di Windows Virtual Desktop

Per distribuire il primo pool di host di Windows Virtual Desktop, una collezione di VM che verrà creata in Azure e che verranno joinate al vostro dominio di Active Directory, collegatevi al portale di Azure e cercate nel Marketplace Windows Virtual Desktop – Provision a host pool. Seguite il wizard di creazione ed inserite tutte le informazioni richieste. Nelle schermate sotto sono mostrati tutti i passaggi necessari. Fate riferimento alla pagina https://docs.microsoft.com/it-it/azure/virtual-desktop/create-host-pools-azure-marketplace per ulteriori informazioni sulla configurazione.

Nel pannello di informazioni di base procedete come segue:

1. Immettete un nome per il pool di host che sia univoco all’interno del tenant di Windows Virtual Desktop.
2. Selezionate l’opzione appropriata per il tipo di desktop (Pooled o Personal).
3. Immettete un elenco di voci delimitate da virgole corrispondenti agli utenti che possono accedere ai client di Windows Virtual Desktop. Se ad esempio si vuole assegnare l’accesso a user1@contoso.com e user2@contoso.com, immettere “user1@contoso.com,user2@contoso.com”.
4. In Location selezionate la stessa località della macchina virtuale che ha connettività con il server Active Directory.

Figura 14: Creazione dell’host pool

Configurare le macchine virtuali

Per il pannello di configurazione delle macchine virtuali:

1. Accettate i valori predefiniti oppure personalizzate il numero e le dimensioni delle VM.
2. Immettete un prefisso per i nomi delle macchine virtuali. Ad esempio, se si immette il nome “WVD”, le macchine virtuali saranno denominate “WVD-0”, “WVD-1” e così via.

Figura 15: Scelta della dimensione e del numero delle VM da creare

Impostazioni della macchina virtuale

1. Selezionate Image source e immettete le informazioni appropriate. Se scegliete di non usare dischi gestiti, selezionate l’account di archiviazione contenente il file con estensione vhd.
2. Immettete il nome utente e la password per l’account di dominio che aggiungerà le VM al dominio di Active Directory locale. Gli stessi valori di nome utente e password verranno creati come account locali nelle macchine virtuali. È possibile reimpostare questi account locali in seguito.
3. Selezionate la rete virtuale (VNET) che ha connettività con il server Active Directory, quindi scegliere una subnet in cui ospitare le macchine virtuali.

Figura 16: Configurazione delle VM, credenziali per il join a dominio delle VM e rete virtuale (VNET) a cui connetterle

Per il pannello di informazioni sul tenant di Desktop virtuale Windows:

1. Immettete il nome del gruppo di tenant di Windows Virtual Desktop. Se non è stato pianificato uno specifico nome di gruppo di tenant, lasciare il valore predefinito “Default Tenant Group“.
2. Immettete il nome del tenant di Windows Virtual Desktop in cui verrà creato il pool di host.
3. Specificate il tipo di credenziali da usare per l’autenticazione come proprietario di Servizi Desktop remoto del tenant di Windows Virtual Desktop. Potete immettere le credenziali di un global administrator del tenant di Azure AD.

Figura 17: Indicazione del Windows Virtual Desktop tenant e dell’ Azure AD tenant da utilizzare

Per gli ultimi due pannelli:

1. Nel pannello Riepilogo rivedete le informazioni sulla configurazione.
2. Nel pannello Acquista rivedete le informazioni aggiuntive sull’acquisto effettuato da Azure Marketplace. Selezionate Crea per distribuire il pool di host.

Figura 18: Schermata riepilogativa e validazione del setup

Figura 19: Creazione dell’Host Pool di Windows Virtual Desktop

A seconda del numero di VM create, questo processo può richiedere circa 30 minuti.

Figura 20: Deployment dell’host pool di Windows Virtual Desktop

Le macchine che verranno create non avranno un indirizzo IP pubblico e non saranno raggiungibili direttamente da Internet, ma solo attraverso un reverse proxy di Microsoft, che garantisce un elevato livello di sicurezza. Come si può vedere nell’immagine sotto, la VM possiede solo l’IP provato della VNET a cui è collegata.

Figura 21: Le VM create non sono accessibili direttamente da Internet e non hanno un IP pubblico

Sarà possibile collegarsi alle VM create utilizzando RDP e usando come credenziali il nome utente e la password per l’account di dominio che avete utilizzato per aggiungere le VM al dominio di Active Directory locale. Gli stessi valori di nome utente e password sono stati creati come account locali nelle macchine virtuali. Se controllate la versione del sistema operativo noterete che è stato installato Windows 10 for Virtual Desktops. Potete a questo punto installare tutte le applicazioni che volete far utilizzare ai vostri utenti.

Figura 22: Nella VM verrà installato Windows 10 for Virtual Desktops

Verifica di accesso dell’utente al Windows Virtual Desktop Pool

Per poter verificare l’accesso al pool creato è necessario procurarsi il Remote Desktop Client per Windows, Android o iOS oppure utilizzare il client HTML5. Per scaricare il client Windows collegatevi al link Remote Desktop client e installatelo sulla vostra macchina. Nelle figure sotto sono mostrati tutti i passaggi relativi all’installazione

Figura 23: Accettazione delle licenza di Remote Desktop Client

Figura 24: Completamento dell’installazione del Remote Desktop Client

Lanciate il client ed effettuate la sottoscrizione al feed di Windows Virtual Desktop cliccando sul tasto Subscribe. Dopo esservi autenticati vi apparirà l’elenco dei Windows Virtual Desktop a cui l’utente può fare l’accesso. Nel mio caso il dominio locale di Active Directory usa i Federation Services per l’autenticazione (con Multi-Factor Authentication). Poiché mi sto collegando da una macchina fuori dominio mi viene richiesta l’autenticazione. Se il client da cui effettuate la connessione è in dominio allora potrete utilizzare il Single Sign-On (SSO).

Figura 25: Inserimento delle credenziali per l’autenticazione

Figura 26: Utilizzo di Active Directory Federation Services ed Azure Multi-factor Authentication

Figura 27: Connessione dell’account a Windows 10

Figura 28: Connessione al pool di Windows Virtual Desktop effettuata

Figura 29: Inserimento delle credenziali per la connessione al Remote Desktop

Figura 30: Connessione a Windows Virtual Desktop effettuata

Una volta che avete sottoscritto il feed, i Desktop Remoti e le RemoteApp saranno disponibili nel menù avvio di Windows

Figura 31: I Remote Desktop e le RemoteApp sono disponibili nel menù avvio di Windows

Connessione tramite client HTML5

Abbiamo già avuto modo di parlare del nuovo client HTML5 per Remote Desktop Services nell’articolo Remote Desktop Web Client in Windows Server 2016 e Windows Server 2019. Grazie a questa nuova funzionalità potete utilizzare un browser per potervi collegare ai vostri Windows Virtual Desktop. Collegatevi alla pagina http://aka.ms/wvdweb e utilizzate le credenziali di un utente che avete abilitato all’accesso dei Virtual Desktop per effettuare la connessione.

Figura 32: Connessione al pool di Windows Virtual Desktop creato

Figura 33: Login da parte dell’utente abilitato

Figura 34: Connessione al Windows Virtual Desktop tramite client HTML5 effettuata

Connessione tramite smartphone

Per connettersi tramite smartphone (nel mio caso Android) ho scaricato dal Play Store l’applicazione Microsoft Remote Desktop e ho aggiunto un nuovo Remote Resource Feed che punta all’indirizzo https://rdweb.wvd.microsoft.com. La connessione è molto veloce ed è davvero semplice. Nelle schermate sotto ci sono tutti i passaggi:

Aggiunta di altri utenti all’accesso di Windows Virtual Desktop

In qualsiasi momento è possibile permettere l’accesso ad altri utenti del vostro dominio di Azure AD

#Sign in to the Windows Virtual Desktop environment
Add-RdsAccount -DeploymentUrl "https://rdbroker.wvd.microsoft.com"

#Set the context to the Windows Virtual Desktop tenant group
Set-RdsContext -TenantGroupName "<tenantgroupname>"

#Add users to the desktop application group
Add-RdsAppGroupUser "<tenantname>" "<hostpoolname>" "Desktop Application Group" -UserPrincipalName <userupn>

Se volete aggiungere diversi utenti sarà necessario lanciare l’ultima cmdlet Add-RdsAppGroupUser diverse volte, una per ogni utente.

Figura 35: Aggiunta di un secondo utente al pool di Windows Virtual Desktop

Creazione delle RemoteApp

È anche possibile connettersi ai Windows Virtual Desktop utilizzando le RemoteApp.

Eseguite la cmdlet di PowerShell seguente per creare un nuovo gruppo vuoto di RemoteApp

New-RdsAppGroup <tenantname> <hostpoolname> <appgroupname> -ResourceType "RemoteApp"

Eseguite la cmdlet seguente per ottenere un elenco di applicazioni installate all’interno delle VM del Windows Virtual Desktop pool. Prendere nota dei valori di FilePath, IconPath, IconIndex dell’applicazione da pubblicare.

Get-RdsStartMenuApp <tenantname> <hostpoolname> <appgroupname>

Eseguite la cmdlet seguente per pubblicare una nuova RemoteApp nel gruppo di applicazioni creato prima

New-RdsRemoteApp <tenantname> <hostpoolname> <appgroupname> <remoteappname> -Filepath <filepath> -IconPath <iconpath> -IconIndex <iconindex>

Eseguite la cmdlet seguente per concedere agli utenti l’accesso alle RemoteApp del gruppo.

Add-RdsAppGroupUser <tenantname> <hostpoolname> <appgroupname> -UserPrincipalName <userupn>

Figura 36: Enumerazione delle applicazioni installate nelle VM

Figura 37: Pubblicazione di una RemoteApp (Wordpad) e assegnazione ad un utente

A questo punto sarà possibile collegarsi per verificare che il nuovo gruppo di RemoteApp sia disponibile per gli utenti abilitati. Per procedere alla verifica ho utilizzato il browser e dopo essermi collegato a http://aka.ms/wvdweb ho inserito le credenziali dell’utente che ho autorizzato.

Figura 38: Utente collegato tramite client HTML5 alla RemoteApp eseguita tramite Windows Virtual Desktop

Figura 39: Lancio della RemoteApp

Figura 40: Connessione alla RemoteApp effettuata con successo

Conclusioni

Windows Virtual Desktop permette di poter ospitare in Azure la nostra infrastruttura VDI o di RemoteApp, di poter assegnare agli utenti i desktop in modalità persistente o non-persistente, dedicata o multisessione, in maniera estremamente semplice e senza la necessità di dover esporre le nostre macchine virtuali direttamente ad Internet. Il Cloud ci permette di poter scalare facilmente in caso di necessità e ci assicura un livello di sicurezza difficilmente raggiungibile all’interno delle nostre aziende.

Potete dare un’occhiata anche a video interessanti di sessioni tenute ad Ignite:

• Scott Manchester’s Mechanics Live (20 minuti)
• Windows Virtual Desktop Overview (43 minuti)
• Windows Virtual Desktop Deep Dive  (56 minuti)
• A tour of Microsoft Windows Virtual Desktop  (20 minuti)
• Office in Virtual Desktop environments (53 minuti)
• New multi-session virtualization capabilities in Windows (32 minuti)

Il 27 Marzo è stata rilasciata la versione 1902 di SCCM (System Center Configuration Manager) che comprende una serie di nuove funzionalità.

Prima di procedere con l’aggiornamento, vi consiglio di eseguire le seguenti operazioni:

• Verificate che la versione di SCCM (Current branch) non sia precedente alla 1710;
  
• Controllate lo stato generale dell’infrastruttura;
  
• Procedete con l’aggiornamento alla 1809 dell’ADK (Assessment and Deployment Kit) per Windows 10 e del SQL Server Native Client almeno alla versione 2012;
  
• Sui server con ruoli di Configuration Manager, applicate gli ultimi aggiornamenti di sicurezza e se richiesto procedente con un riavvio;
  
• Effettuate un backup del site database;
  
• In console, avviate il check dei prerequisiti prima di lanciare l’aggiornamento di versione.
  

Per ulteriori dettagli Checklist for installing update 1902 for Configuration Manager.

Di seguito le novità di maggior rilevanza.

Client Health Dashboard

Tramite la dashboard è possibile controllare lo stato generale dei client di Configuration Manager applicando i filtri desiderati.

Si trova in Monitoring -> Overview -> Client Status -> Client Health Dashboard.

Figura 1 – Client Health Dashboard

Ricerca del device tramite MAC Address

Nelle version precedenti per ricercare un client in base al MAC Address era necessaria una query ad-hoc. Dalla 1902 è possibile applicare il criterio MAC Address in fase di ricerca del device.

Figura 2 – Ricerca del device applicando il criterio MAC Address

Verifica degli utenti collegati alla console SCCM

In Administration -> Overview -> Security -> Console Connections è disponibile il nuovo tab Console Connections per vedere le connessioni recenti alla console SCCM.

Figura 3 – Verifica delle connessioni utenti alla console SCCM

PowerShell Script all’interno di una task sequence

È possibile inserire e modificare uno script powershell all’interno di una task sequence senza creare un apposito package.

Figure 4 – Inserimento di uno script powershell all’interno di una task sequence

Gestione di OneDrive for Business tramite SCCM

In Assets and Compliance -> Overview -> Compliance Settings -> OneDrive for Business Profiles è si può impostare la migrazione delle known folder (Desktop, Documenti ed Immagini) su OneDrive for Business.

Trovate approfondimenti sull’implementazione di OneDrive for Business in un ambiente enterprise all’articolo https://www.ictpower.it/guide/configurare-onedrive-for-business-in-un-ambiente-enterprise.htm .

Figura 5 – Gestione OneDrive for Business profile in SCCM

Impostazione di una finestra di dialogo per distribuzione sotware e richiesta riavvio

SCCM di default utilizza la toast notification per notificare una modifica software o un riavvio. Dalla nuova versione , viene offerta una seconda opzione impostando una finestra di dialogo al fine di attirare l’attenzione dell’utente.

Tale soluzione alternativa si può applicare spuntando la voce “When software changes are required, show a dialog window to the user instead of a toast notification“, che si trova tra le preferenze di deployment.

Figura 6 – Impostare una finestra di dialogo nelle opzioni di deployment

Se si vuole utilizzare questa opzione anche nel caso di richiesta di riavvio, bisogna modificare i client settings interessati.

Nel tab Computer Restart troverete la voce “When a deployment requires a restart, show a dialog window to the user instead of a toast notification”.

Figura 7 – Impostare una finestra di dialogo per la richiesta di riavvio

Figure 8 – Finestra di dialogo SCCM Client

Supporto delle lingue aggiuntive di Office 365

A differenza delle release precedent di SCCM, adesso è presente il pieno supporto di tutte le 103 lingue di Office 365, non legandosi più ai Windows Update.

Visualizzazione dello schermo principale in controllo remoto

Durante la fase di controllo remoto di un client di SCCM è possibile scegliere tra la visualizzazione di tutti gli schermi o solo quello principale.

Stop dei servizi Cloud

Nel caso in cui si raggiunga il limite massimo di banda impostato, Configuration Manager può stoppare automaticamente i servizi cloud.

Conclusioni

Con il rilascio di questa versione, Microsoft ha implementato una serie di funzionalità molto interessanti che semplificano ed ottimizzano la user experience oltre a garantire una miglior gestione della suite Office.

Per ulteriori aggiornamenti e dettagli, è disponibile l’articolo ufficiale What’s new in version 1902 of Configuration Manager.

Abbiamo già avuto modo di parlare nell’articolo Modern Desktop Deployment and Management Lab Kit: laboratori pratici per la distribuzione e la gestione di Microsoft 365 di Modern Desktop. Il termine Modern Desktop si riferisce ad un’installazione di Windows 10 e Office 365, mantenuta costantemente aggiornata.

Avere un Modern Desktop significa sfruttare al massimo le funzionalità offerte sia dal sistema operativo che dalla suite di collaborazione Office 365, avendo la possibilità di migliorare la produttività, il lavoro di gruppo e la collaborazione all’interno dell’azienda. In più, avendo sempre un sistema aggiornato, possiamo assicurare un livello di efficienza e di sicurezza notevole, che ci permette di difenderci dai continui attacchi che ci arrivano dall’esterno (e molto spesso anche dall’interno) dell’azienda.

A partire dalla versione 1710 di SCCM ( System Center Configuration Manager), Microsoft ha rilasciato la funzionalità di Co-Management. Il Co-Management è uno dei modi principali per collegare la distribuzione di Configuration Manager esistente al cloud di Microsoft 365 e permette di poter gestire i dispositivi Windows 10 contemporaneamente tramite Configuration Manager e Microsoft Intune.

Figura 1: Funzionamento di Co-Management con SCCM e Intune

I vantaggi sono davvero notevoli. Quando si registrano client di Configuration Manager per il Co-Management con Intune è possibile avere:

• Accesso condizionale per la conformità (compliance) del dispositivo
• Azioni remote basate su Intune, ad esempio: riavvio, controllo remoto o ripristino delle impostazioni predefinite
• Visibilità centralizzata dello stato di aggiornamento e configurazione di tutti i dispositivi
• Collegare utenti, dispositivi e app con Azure Active Directory (Azure AD)
• Provisioning moderno con Windows Autopilot
• Gestione remota di Windows 8.1, Windows 10, Android e iOS

Figura 2: Gestione dispositivi con la funzionalità di Co-Management con SCCM e Intune

Abilitazione della funzionalità di Co-Management

Per scrivere questo articolo ho utilizzato il Modern Desktop Deployment and Management Lab Kit, che mi ha permesso dicreare velocemente il laboratorio di test e Microsoft 365 Enterprise Demo Content
(disponibile solo per partner Microsoft) per il tenant di Azure.

Per configurare il co-management oltre a dover avere già un’infrastruttura SCCM, sono necessarie le seguenti licenze:

• Azure AD Premium;
• Licenza di Intune o EMS (Enterprise Mobility + Security).

Come prerequisito per la gestione Intune, il device deve essere registrato in Azure AD con una delle seguenti modalità:

• Azure AD Join;
• Hybrid Azure AD Join.

Configurazione dell’Hybrid Azure AD Join

Attraverso il comando dsregcmd /status è possibile verificare se il client sia joinato o meno in Azure AD.

Figura 3 – Verifica del client se è joinato in Azure AD

Per procedere con la configurazione dell’Hybrid Azure AD Join, sono necessarie delle attività sull’AD Connect.

Nel wizard, selezionate Configure device options, inserite le credenziali di global admin e successivamente spuntate Configure Hybrid Azure AD Join.

Figura 4 – Configure device options in AD Connect

Figura 5 –Inserimento credenziali di global admin in AD Connect

Figura 6 – Configure Hybrid Azure AD Join in AD Connect

Per la configurazione del SCP (service connection point) selezionate il vostro authentication service ed inserite le credenziali di enterprise admin della foresta AD.

NOTA: Nel caso abbiate come authentication service l’ADFS, vengono richieste le credenziali di administrator dell’ADFS per aggiornare automaticamente le regole di autenticazione del relying party trust interessato.

Figura 7 – Configurazione del SCP per Azure AD

Avendo nel mio laboratorio solo dispositivi Windows 10, nella finestra successiva ho selezionato la prima voce Windows 10 or later domain-joined devices. Per supportare device downlevel domain-joined ( dispositivi con OS inferiore a Windows 10) sono necessarie operazioni aggiuntive come da guida https://docs.microsoft.com/en-us/azure/active-directory/devices/hybrid-azuread-join-federated-domains#enable-windows-down-level-devices

Figura 8 – Selezione dell’OS dei dispositivi da joinare in Azure AD

Figura 9 – Sommario AD Connect per configurazione Hybrid Azure AD Join

Figura 10 – Configurazione completata su Azure AD per hybrid Azure AD Join

Dopo aver completato il wizard sull’AD Connect, verificate lato client (consiglio un riavvio) la registrazione in Azure AD lanciando il comando dsregcmd /status tramite prompt dei comandi.

Figura 11 – verifica client correttamente registrato in Azure AD tramite dsregcmd /status

Anche in Azure AD troverete il client joinato nella modalità di Hybrid Azure AD Joined.

Figura 12 – Portale Azure AD con dispositivo registrato in modalità Hybrid Azure AD Joined

Configurazione della funzionalità Co-Management in SCCM

NOTA: Prima di procedere con la configurazione, vi consiglio di individuare o creare una device collection che farà da pilot per il co-management.

Su SCCM in Administrator à Overview à Cloud Services à Co-Management configurate la funzionalità inserendo le credenziali di un account con licenza Intune e diritti amministrativi.

Figura 13 – Inserimento credenziali con diritti amministrativi e licenza Intune

Nella finestra successiva, tra le opzioni disponibili in Automatic enrollment in Intune, selezionate Pilot.

Figura 14 – Automatic enrollment in Intune solo per pilot

Figura 15 – Assegnazione workload ad Intune solo per il gruppo Pilot

Indicate la collection interessata per il gruppo pilot.

Figura 16 – Selezione della device collection per il gruppo pilot

Figura 17 – Sommario configurazione completata Co-Management

Una volta completati tutti i passaggi, verificate sul portale Intune che il client abbia il seguente stato:

Figura 18 – Stato client in Co-Management su portale Intune

Sul client di Configuration Manager, troverete la proprietà di Co-Management in Enabled.

Figura 19 – Stato client in Co-Management su Configuration Manager

Conclusioni

L’approccio del Co-Management offre numerosi vantaggi e garantisce una maggiore flessibilità in quanto permette di usufruire delle due soluzioni di management (Configuration Manager e Microsoft Intune) contemporaneamente.

Per approfondire, è disponibile l’articolo ufficiale https://docs.microsoft.com/it-it/sccm/comanage/overview

Tantissime sono le funzionalità di Hyper-V (nuove e aggiornate) in Windows Server 2016 e Microsoft Hyper-V Server 2016. Per utilizzare queste nuove funzionalità è necessario però utilizzare la corretta versione di configurazione (virtual machine configuration version) della macchina virtuale.

Al momento della creazione della macchina virtuale verrà sempre utilizzata la versione più recente ma se spostate o se importate la VM creata con una versione precedente di Hyper-V sarà necessario aggiornare manualmente la versione di configurazione della VM.

In Hyper-V in Windows Server 2016 e Microsoft Hyper-V Server 2016 sono state introdotte o aggiornate le seguenti funzionalità:

• Compatible with Connected Standby (novità)
• Discrete device assignment (novità)
• Encryption support for the operating system disk in generation 1 virtual machines (novità)
• Host resource protection (novità)
• Hot add and remove for network adapters and memory (novità)
• Hyper-V Manager improvements (aggiornamento)
• Integration services delivered through Windows Update (aggiornamento)
• Linux Secure Boot (novità)
• More memory and processors for generation 2 virtual machines and Hyper-V hosts (aggiornamento)
• Nested virtualization (novità)
• Networking features (novità)
• Production checkpoints (novità)
• Rolling Hyper-V Cluster upgrade (novità)
• Shared virtual hard disks (aggiornamento)
• Virtual machine backup (novità)
• Shielded virtual machines (novità)
• Start order priority for clustered virtual machines (novità)
• Storage quality of service (QoS) (aggiornamento)
• Virtual machine configuration file format (aggiornamento)
• Virtual machine configuration version (aggiornamento)
• Virtualization-based security for generation 2 virtual machines (novità)
• Windows Containers (novità)
• Windows PowerShell Direct (novità)

Trovate tutti i dettagli alla pagina https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/what-s-new-in-hyper-v-on-windows

In Hyper-V in Windows Server 2019 e Microsoft Hyper-V Server 2019 sono state introdotte o aggiornate le seguenti funzionalità:

• Storage Spaces Direct (aggiornamento)
• Shielded VM (aggiornamento)
• Encrypted Subnets (novità)
• Simplified Two-Node Clusters (novità)
• Persistent Memory (novità)
• ReFS Deduplication (novità)

Maggiori informazioni sono disponibili alla pagina https://docs.microsoft.com/en-us/windows-server/get-started-19/whats-new-19

Modifica della versione di configurazione della macchina virtuale

Ho già evidenziato prima che quando si sposta o si importa una macchina virtuale in un computer che esegue Hyper-V in Windows Server 2019, Windows Server 2016 o Windows 10, la versione di configurazione della macchina virtuale non viene aggiornata automaticamente. Ciò significa che è possibile riportare la macchina virtuale in un host Hyper-V che esegue una versione precedente di Windows o Windows Server ma senza l’aggiornamento di versione non è possibile utilizzare alcune delle nuove funzionalità di macchina virtuale finché non si aggiorna manualmente la versione di configurazione.

Quando si aggiorna la versione di configurazione si modifica la struttura dei file che viene utilizzata per archiviare la configurazione di macchine virtuali e i file del checkpoint. Le macchine virtuali aggiornate usano un nuovo formato di file di configurazione (.VMCX) progettato per aumentare l’efficienza di lettura e scrittura dei dati di configurazione della VM.

Cosa accade se non viene aggiornata la versione di configurazione della macchina virtuale?

Se si hanno macchine virtuali che sono state create con una versione precedente di Hyper-V, alcune funzionalità che sono disponibili negli host di virtualizzazione più recenti potrebbero non funzionare finché non si aggiorna la versione di configurazione delle macchine virtuali.

Come indicazione generale, è consigliabile aggiornare la versione di configurazione dopo aver aggiornato correttamente gli host di virtualizzazione a una versione più recente di Windows e avere la ragionevole certezza che non è necessario eseguire il rollback del sistema operativo.

La tabella seguente illustra la versione di configurazione minima che la macchina virtuale deve avere per poter usare alcune funzionalità di Hyper-V.

L’aggiornamento della versione può essere effettuato sia tramite Hyper-V Manager che tramite comandi PowerShell. La macchina virtuale però deve essere spenta. La macchina verrà aggiornata direttamente alla massima versione supportata dall’host di virtualizzazione e non sarà possibile scegliere versioni intermedie.

Figura 1: Aggiornamento della versione di configurazione della macchina virtuale tramite Hyper- V Manager

Figura 2: Richiesta di conferma dell’aggiornamento della versione di configurazione della VM

Figura 3: Aggiornamento della versione di configurazione della VM completata

Le operazioni di aggiornamento della versione di configurazione della macchina virtuale possono essere effettuate anche tramite PowerShell. Per conoscere la versione supportata dall’host Hyper-V potete utilizzare il comando Get-VMHostSupportedVersion -Default, mentre per elencare tutte le VM e la rispettiva versione potete utilizzare il comando Get-VM * | Format-Table Name, Version . L’aggiornamento può essere effettuato lanciando il comando Update-VMVersion <NomedellaVM> . Nella figura sotto è mostrato il risultato

Figura 4: Aggiornamento della versione di configurazione delle macchine virtuali effettuato tramite comando PowerShell

Una volta modificata la versione la macchina virtuale non potrà essere più accesa su un host che non supporta la versione aggiornata e non sarà possibile effettuare il downgrade della versione di configurazione. Sarà perciò necessario ricreare la VM.

NOTA: Anche se in questo articolo abbiamo parlato di Windows Server 2016 e Windows Server 2019, le stesse operazioni sono valide per Client Hyper-V disponibile in Windows 10 e Windows 8.1
Se volete approfondire le novità introdotte in Client Hyper-V vi rimando alla lettura dell’articolo Novità introdotte in Client Hyper-V in Windows 10 Fall Creators Update

Conclusioni

Aggiornando la versione di configurazione delle macchine virtuali in Hyper-V abbiamo la possibilità di sfruttare al meglio le funzionalità più recenti introdotte in Windows 10, Windows Server 2016 e Windows Server 2019. In questo modo le VM saranno più performanti, potranno utilizzare virtual hardware aggiuntivo e avranno un livello di sicurezza superiore grazie alle feature native di protezione del boot, di utilizzo del TPM e per finire anche di crittografia, di cui abbiamo parlato nell’articolo Creare un Guarded Fabric con l’Admin-trusted attestation e le Shielded VMs in Windows Server 2016

Quando un dispositivo è joinato ad un dominio di Active Directory gli utenti possono accedere alle risorse aziendali senza dover reinserire le proprie credenziali di autenticazione ogni volta che si tenta di effettuare l’accesso a queste risorse. Se il dispositivo non è joinato, gli utenti possono accedere alle risorse aziendali, in particolare i siti web, ma devono reinserire ogni volta le credenziali.

In Windows 8.1 è stata introdotta la funzionalità di WorkPlace Join, che in Windows 10 è stata rinominata in Device Registration. Gli utenti possono accedere alle applicazioni web con l’esperienza di Single Sign-On (SSO) effettuando l’accesso da un dispositivo abilitato per la Device
Registration, senza che il dispositivo sia un computer del dominio.

La Device Registration è particolarmente utile quando gli utenti utilizzano i propri dispositivi privati per accedere alle risorse aziendali. Lo Smart working, fenomeno che si sta diffondendo nelle aziende intaliane e nella pubblica amministrazione, ci permette di lavorare da casa e di essere flessibii negli orari e negli spazi dove lavorare.

Ma per lavorare abbiamo bisogno di un device, che sia un portatile, un tablet o un PC e abbiamo bisogno di poter controllare gli accessi da questi dispositivi.

In questa guida voglio affrontare la gestione dei dispositivi mobili e dei computer che non sono collegati al dominio aziendale e che pertanto risultano più difficili da gestire. Il BYOD (Bring Your Own Device) da quasi 10 anni permette di portare i propri dispositivi personali nel posto di lavoro e usarli per avere accesso alle informazioni aziendali e alle loro applicazioni.

ATTENZIONE: Se state cercando una guida per configurare l’Azure AD Device Registration vi rimando alla lettura dell’articolo Configurare l’accesso condizionale alle applicazioni on-premises utilizzando Azure AD Device Registration . In questa guida mi occuperò di Device Registration con AD FS on-premises.

Abilitando la Device Registration gli utenti potranno registrare i propri dispositivi nella rete aziendale e dopo aver effettuato l’enrollment del dispositivo, un oggetto verrà creato nell’Active Directory locale e verrà associato all’utente. Un certificato utente verrà installato sul dispositivo e verrà utilizzato per le autenticazioni, a patto che abbiate configurato la vostra applicazione web per supportare la claim-based authentication

Figura 1: Schema di funzionamento della Device Registration

Il dispositivo abilitato per la Device Registration verrà utilizzato come secondo fattore di autenticazione quando l’utente tenterà di accedere alle applicazioni aziendali che utilizzano la claim-based authentication e gli amministratori di dominio potranno creare delle policy di accesso all’app in modo tale da consentire l’accesso solo ai dispositivi conosciuti.

NOTA: Se il dispositivo viene utilizzato da diversi utenti ogni utente potrà registrare il dispositivo in maniera indipendente.

Come funziona la Device Registration

La funzionalità di Device Registration ha due scopi principali:

• Registrare in Active Directory i dispositivi non joinati al dominio
• Permettere il Single Sign-On (SSO) alle applicazioni e alle risorse interne all’azienda.

La funzionalità di Device Registration utilizza il Device Registration Service e gli Active Directory Federation Services (AD FS) con la Device Authentication abilitata. Quando un utente registra un dispositivo attraverso il processo di enrollment il Device Registration Service rilascerà un certificato digitale per il dispositivo. Il certificato verrà utilizzato per autenticare il dispositivo quando verrà effettuato l’accesso alle risorse interne.

In più il dispositivo verrà associato all’utente in Active Directory in modo tale che gli amministratori potranno configurare delle policy di accesso da applicare agli utenti e ai loro dispositivi registrati.

Figura 2: Registrazione dei dispositivi per l’utilizzo tramite Device Registration

Se viene implementato anche un Web Application Proxy i dispositivi potranno accedere alle risorse aziendali anche dall’esterno della rete aziendale e da Internet.

Prerequisiti per la Device Registration

Per poter implementare la Device Registration è necessario avere:

• Active Directory con lo schema esteso a Windows Server 2012 R2.
• Una PKI (Public Key Infrastructure) che emetta i certificati digitali per i dispositivi. La CA (Certification Authority) deve essere considerata attendibile e i certificati devono contenere le informazioni relative all’ Authority Information Access (AIA), al CRL distribution point (CDP) e alla Certificate Revocation List (CRL).
• Active Directory Federation Services
• Device Registration Service
• Un record DNS per il nome host enterpriseregistration
• Un Web Application Proxy per accedere da Internet (facoltativo)
• Un sistema operativo supportato (Windows 10 Pro, Windows 10 Enterprise, Windows 10 Education, Windows RT 8.1, Windows 8.1 e iOS). Non sono supportate le versioni HOME

Abbiamo visto nell’articolo Active Directory Federation Services in Windows Server 2016 come configurare i Federation Services e come configurare un Web Application Proxy, mentre partendo dall’articolo Deploy PKI in Windows Server 2016 abbiamo mostrato come mettere in piedi una Certification Authority in Windows Server.

Quando create un certificato da utilizzare per Active Directory Federation Services e per la Device Registration è obbligatorio aggiungere, oltre al nome del server AD FS, anche il nome enterpriseregistration

Nel mio caso ho creato, usando una CA interna, il certificato con i nomi:

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

Figura 3: richiesta del certificato con i nomi obbligatori

Figura 4: Certificato emesso con i nomi scelti

Se avete già installato i Federation Services e volete sostituire il certificato esistente perché magari non conteneva il nome obbligatorio enterpriseregistration potete utilizzare la mia guida Aggiornamento dei certificati SSL per Active Directory Federation Services in Windows Server 2012 R2, Windows Server 2016 e Windows Server 2019

Figura 5: Utilizzo del certificato corretto da parte di Active Directory Federation Services

Configurazione della Device Registration

Per configurare la Device Registration con Active Directory Federation Services loggatevi nel Federation Server come Domain Admin ed eseguire il seguente comando

Initialize-ADDeviceRegistration

Quando vi verrà chiesto il ServiceAccountName inserite quello che avete utilizzato per installare il Federation Server. Se avete utilizzato un Group Managed Service Account (gMSA) inseritelo nel formato domain\accountname$

Su tutti i Federation Server sarà invece necessario lanciare il comando

Enable-AdfsDeviceRegistration

che permetterà di abilitare la funzionalità di Device Registration.

Figura 6: Inizializzazione della funzionalità di Device Registration in Active Directory Federation Services

Il comando Initialize-ADDeviceRegistration creerà uno nuovo container nella domain partition in Active Directory chiamato RegisteredDevices e due nuovi container nella configuration partition (in Configuration –> Services –> Device Registration Configuration) chiamati Device Registration Services e Device Registration Service DKM

Figura 7: Containr creato nella container nella domain partition in Active Directory

Figura 8: Container creati nella container nella configuration partition in Active Directory

È possibile verificare le configurazioni anche utilizzando il comando PowerShell

Get-AdfsDeviceRegistration

Il risultato è mostrato nella figura sotto:

Figura 9: Verifica delle configurazioni tramite PowerShell

Verificate anche che l’EnrollmentServer Endpoint sia abilitato utilizzando il comando

Get-AdfsEndpoint /EnrollmentServer/

Figura 10: Verifica dell’abilitazione dell’EnrollmentServer Endpoint

Nel caso fosse disabilitato potete abilitarlo con il comando

Enable-AdfsEndpoint /EnrollmentServer/

Set-AdfsEndpoint /EnrollmentServer/ -Proxy $True

Ricordatevi di riavviare il servizio di Active Directory Federation Service su TUTTI i server AD FS

Dalla console di AD FS sarà possibile verificare che la Device Registration è abilitata

Figura 11: La Device Registration è stata abilitata in AD FS

Abilitare la seamless second factor authentication

La seamless second factor authentication permette di aumentare il livello di protezione degli accessi alle risorse e alle applicazioni aziendali da parte dei dispositivi che non sono in dominio. Quando il dispositivo è “registrato” diventa un dispositivo “noto” per gli amministratori, che possono utilizzare questa informazione per creare delle regole di accesso condizionale (Conditional Access Policy).

Per abilitare questa funzionalità è sufficiente lanciare il comando PowerShell

Set-AdfsGlobalAuthenticationPolicy -DeviceAuthenticationEnabled $true -DeviceAuthenticationMethod All

Figura 12: Abilitazione della seamless second factor authentication

Aggiornamento della configurazione sui Web Application Proxy

Se avete implementato i Web Application Proxy, per permettere l’accesso alle applicazioni anche dall’esterno della rete aziendale e da Internet, dovete considerare che non sarà necessario pubblicare il servizio di Device Registration in quanto verrà automaticamente gestito dai Federation Server. Sarà tuttavia necessario completare la procedura lanciando su tutti i Web Application Proxy il comando PowerShell

Update-WebApplicationProxyDeviceRegistration

Figura 13: Completamento della procedura di attivazione di Device Registration sui Web Application Proxy

Configurazione dei client

Per poter utilizzare la Device Registration per un client in workgroup è necessario che il certificato utilizzato sia considerato attendibile dai dispositivi. Se utilizzate una Certification Authority privata per poter gestire i certificatevi assicuratevi che il certificato di Root CA sia disponibile sui client. Procuratevi quindi il certificato di Root CA e installatelo sui dispositivi da aggiungere. Nel mio caso mi sono collegato dalla macchina in workgroup e ho utilizzato il servizio di Certification Authority Web Enrollment per procurarmi il certificato della CA interna.

Figura 14: Installazione del certificato di Root CA

A questo punto non vi resterà altro da fare che effettuare la Device Registration. Nel mio caso ho utilizzato Windows 10, versione 1809 e dall’app Settings mi sono spostato in Access Work or school e ho inserito il mio account di lavoro (nic-byod@nicolaferrini.cloud).

Basta seguire la procedura guidata e dopo aver inserito le credenziali nel prompt del Federation Server il vostro dispositivo sarà aggiunto e visibile nei Registered Devices.

Figura 15: Aggiunta della macchina in wordkgroup ai Registered Devices del dominio

Creazione delle Access Control Policies

Per permettere l’accesso solo ai dispositivi considerati attendibili è possibile creare una Access Control Policy in Active Directory Federation Services. Nella Policy sarà possibile permettere l’accesso alle applicazioni solo dai dispositivi con un Trust Level di tipo Authenticated, Managed o Compliant. Nelle foto sotto sono mostrare le configurazioni disponibili

Figura 16: Aggiunta di una nuova Access Control Policy ad Active Directory Federation Services

Figura 17: Filtro della policy che permette l’accesso solo a dispositivi con un particolare Trust Level

Conclusioni

La Device Registration permette agli utenti aziendali di poter utilizzare i propri dispositivi privati per accedere alle risorse interne all’azienda. Gli amministratori di sistema avranno la possibilità di poter filtrare gli accessi e di poter consentire solo ai dispositivi riconosciuti di poter visualizzare le applicazioni aziendali, aumentando il livello di sicurezza di accesso alle informazioni. Filtrare gli accessi alle applicazioni la cui autenticazione è gestita dal Federation Server e consentirli solo se provenienti da dispositivi conosciuti e attendibili permette di proteggere gli assett aziendali e permette di non rinunciare alla sicurezza, fattore determinante quando si utilizza il Bring Your Own Device (BYOD).

Qualche giorno fa Microsoft ha annunciato l’anteprima pubblica di Hybrid Agent. L’agente ibrido fa parte di Exchange Modern Hybrid, una nuova topologia ibrida disponibile per connettere i server Exchange on-premises a Exchange Online basata sulla stessa tecnologia dell’Azure Application Proxy. L’agente può essere installato su una macchina stand-alone dedicata oppure sullo stesso server Exchange.

Hybrid Configuration Wizard è l’applicazione responsabile dell’installazione dell’agente ibrido. È necessario eseguire l’HCW dalla macchina che vogliamo utilizzare e non è necessario installare l’agente su una macchina che ospita Exchange come anticipato in precedenza. È però necessario che la macchina che ospita l’agente sia in grado di connettersi all’Exchange con il ruolo CAS dell’organizzazione.

L’agente ibrido rimuove la necessità di pubblicare i servizi dell’Exchange Onpremises e l’acquisto di certificati di terze parti (prerequisiti necessari in uno scenario di ibridazione classico) ed è importante tenere presente che questo comporta delle limitazioni in ambito di condivisione delle informazioni tra utenti di Exchange Online e utenti di Exchange on-premises.

Feature supportate:

• Visibilità delle informazioni Free/Busy da Exchange online a Exchange on-premises e viceversa
• Migrazione delle mailbox da Exchange on-premises a Exchange Online e viceversa

Requisiti di Porte e Protocolli:

• Porte HTTPS (TCP) 443, e 80 devono essere aperte tra la macchina con l’agente ibrido e internet.
  
• Porte HTTPS (TCP) 443, 80, (WinRM porte http)5985 e 5986 devono essere aperte tra la macchina che ospita l’agente ed Exchange con il ruolo CAS
  

Feature non supportate:

• Suggerimenti di Messaggio
• Tracking delle e-mail
• Ricerca Multi-Mailbox

Questa nuova tecnologia porta con sé le seguenti limitazioni:

• L’agente ibrido non gestirà alcun flusso di posta SMTP, quindi è ancora necessario pubblicare la porta 25 e un certificato di terze parti per mettere in sicurezza il flusso di posta tra Exchange Online e l’ambiente di Exchange Onpremises.
• Non è possibile utilizzare l’agente ibrido in caso si voglia abilitare la Hybrid Modern Authentication in quanto si renderebbe necessaria la pubblicazione dei Autodiscover, EWS, MAPI e OAB.
• In aggiunta è essenziale sapere che l’anteprima pubblica supporta un singolo agente per ogni organizzazione di Exchange, dunque non è possibile avere alta affidabilità nel momento in caso di problemi del server con a bordo l’agente. Essendo un’anteprima pubblica ha un supporto limitato da parte di Microsoft, condizione che andiamo ad accettare nel momento in cui accettiamo i “Termini e Condizioni” in fase di configurazione dell’Hybrid Configuration Wizard.

Lo schema seguente illustra una tipica configurazione ibrida tramite il nuovo agente:

Figura 1 – Schema Implementazione Agente

Prerequisiti per l’installazione:

Per consentire l’installazione dell’agente ed eseguire le migrazioni di mailbox da e verso il tenant di Office 365 è necessario abilitare l’MRS Proxy sulla virtual directory degli Exchange Web Services del CAS della nostra Organizzazione OnPremises con il seguente comando:

Set-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -MRSProxyEnabled $true

Andiamo a vedere lo stato dell’Exchange Web Services con il seguente comando:

Get-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” | select name,MRSProxyEnabled

In caso di presenza di una versione obsoleta dell’Hybrid Configuration Wizard procediamo con la disinstallazione e in seguito con l’installazione della versione più aggiornata di quest’ultimo.

Sarà necessaria la presenza .NET Framework versione 4.6.2 sulla macchina destinata ad ospitare l’agente, in caso ci sia una versione obsoleta verrà proposto del wizard l’aggiornamento del componente.

Andiamo ora ad effettuare la configurazione step by step nel nostro laboratorio:

Dall’interfaccia di gestione dell’Exchange Onpremises vado a selezionare Hybrid->Configura

Figura 2 – Download Setup Hybrid Configuration Wizard da sezione “Hybrid” di Exchange Onpremises

Figura 3 – Inizio Setup Hybrid Configuration Wizard

Dopo l’immissione delle credenziali di global admin del Tenant di O365 e le credenziali con privilegi amministrativi dell’organizzazione OnPremises, attendiamo che l’HCW riunisca informazioni e configurazione sugli ambienti. Al termine fare click su Next.

Figura 4 – Controllo raggiungibilità Exchange Client Access Server e Exchange Online (Neccessari Domain Admin Onpremises e Global Admin del tenant)

Andiamo a selezionare la “Full Hybrid Configuration”, al termine fare click su Next.

Figura 5 – Scelta configurazione Full Hybrid

Selezioniamo “Use Exchange Modern Hybrid Topology”, al termine fare click su Next.

Figura 6 – Scelta Exchange Modern Hybrid Topology (Hybrid Agent)

Nota: Se non vediamo l’opzione “Use Exchange Modern Hybrid Topology (Preview)” nell’HCW è perché probabilmente abbiamo già effettuato un’ibridazione classica delle Organizzazioni Onpremises e Office 365 e dunque questa opzione non sarà disponibile.

Andiamo ad accettare i termini e le condizioni, qui viene specificato che il supporto per questo prodotto è limitato essendo un’anteprima pubblica, al termine fare click su Next.

Figura 7 – Accettiamo Termini e Condizioni

Immettiamo le credenziali necessarie ad Exchange Online per la creazione dell’endpoint di migrazione, al termine fare click su Next.

Figura 8 – Immissione credenziali necessarie per installazione agente su Exchange Onpremises

Figura 9 – Download e Installazione Agente

Figura 10 – Registrazione e Validazione Agente

Eseguiamo il download, l’installazione, la registrazione e la validazione dell’Exchange con il ruolo CAS nell’Organizzazione OnPremises.

Figura 11 – Configurazione e Validazione Agente Completata

Configuriamo il CAS On-Premises per il trasporto sicuro delle e-mail tra le Organizzazioni, in caso di presenza di una macchina con il ruolo EDGE nella nostra DMZ possiamo cambiare configurazione e utilizzare quest’ultima.

Figura 12 – Scelta Ruolo Exchange per il flusso e-mail tra Exchange Onpremises ed Exchange Online

Figura 13 – Scelta Exchange con ruolo CAS che ospiterà i connettori in ricezione per il flusso di posta

Figura 14 – Scelta Exchange con ruolo CAS che ospiterà i connettori di invio per il flusso

Selezioniamo il certificato che vogliamo utilizzare per mettere al sicuro il traffico SMTP tra le due Organizzazioni.

Figura 15 – Scelta del certificato per l’hybrid mail transport

Immettiamo l’FQDN della nostra organizzazione, questo permetterà di configurare il connettore d’invio dell’Exchange Online in direzione della nostra organizzazione Onpremises.

Figura 16 – Configurazione FQDN dell’Organizzazione Onpremises

Figura 17 – Update della configurazione ibrida

Test di Migrazione di una Mailbox:

Procediamo con la migrazione di una mailbox dalla nostra Organizzazione On-Premises in direzione di Exchange Online.

Figura 18 – Migrazione mailbox da Exchange Onpremises verso Exchange Online

Figura 19 – Batch di Migrazione Pronto

Figura 20 – Inizio del batch di migrazione

Figura 21 – Elementi mailbox sincronizzati con mailbox Exchange Online

Completiamo il batch di Migrazione.

Figura 22 – Batch di migrazione completato

Effettuiamo un test di condivisione FREE/BUSY dalla mailbox appena migrata su Exchange Online verso una mailbox ancora presente nella nostra Organizzazione OnPremises.

Figura 23 – Esempio Free Busy da utente su Exchange Online verso utente su Exchange OnPremises

Informazioni Aggiuntive:

I dettagli dell’installazione dell’agente sulla macchina possono essere consultati andando sulla seguente chiave di registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Hybrid Service

Figura 24 – Chiave di registro dell’Agente

L’immagine seguente illustra la lista di servizi della macchina con a bordo l’agente ibrido:

Figura 25 – Servizio dell’agente ibrido

CONCLUSIONI

L’agente ibrido porta importanti benefici in termini di semplicità di configurazione dell’Organizzazione OnPremises in vista della migrazione delle mailbox su Exchange Online. È necessario però tenere in mente il fatto che siamo ancora ad un’anteprima pubblica con supporto limitato e la possibilità di avere un’unica macchina con a bordo questa tecnologia. Assicuratevi di testare a lungo questa soluzione prima di renderla disponibile al vostro ambiente di produzione.

Per maggiori informazioni sull’agente ibrido vi rimando alla seguente pagina https://docs.microsoft.com/it-it/exchange/hybrid-deployment/hybrid-agent

Il primo aggiornamento di funzionalità dell’anno è finalmente disponibile, per tutti. Microsoft ha annunciato qualche settimana fa grossi cambiamenti nella gestione degli aggiornamenti di Windows 10, il tutto a fronte dell’aggiornamento precedente (1809) il quale si è rivelato poco felice. Approfondiremo questo aspetto con un successivo articolo dedicato, in questo daremo solo qualche accenno.

I più attenti avranno notato un cambio sul naming rispetto a quanto siamo abituati, ed effettivamente c’è e deriva sempre dalla precedente “esperienza”. La 1903 è andata in “RTM” a marzo, è stata distribuita ad aprile ai sottoscrittori di un abbonamento alla piattaforma per gli sviluppatori (MSDN) ed è disponibile a tutti a partire da questo mese. Ecco da dove deriva il nome ufficiale Windows 10 May 2019 Update.

La data di rilascio è 21 maggio 2019, quindi a partire da questo giorno Microsoft inizia a distribuire la nuova versione del sistema operativo Windows 10. La versione è identificata dal numero 1903 build 18362.

Ci sono diverse novità e migliorie presenti in questo nuovo aggiornamento di funzionalità e la più importante, annunciata a inizio aprile 2019, riguarda il processo di aggiornamento. L’obiettivo principale è quello di migliorare l’esperienza dell’utente offrendo maggiore controllo, trasparenza e qualità. Infatti, coloro che sono in possesso di una versione aggiornata di Windows 10 1803 o 1809 riceveranno una notifica in cui il sistema stesso mostra la disponibilità al download di un nuovo aggiornamento di funzionalità (quando sarà disponibile per il PC), come mostrato nella figura sottostante.

In questo modo, da un lato, l’utente potrà continuare a ricevere e verificare la presenza degli aggiornamenti qualitativi mensili e, dall’altro, decidere autonomamente quando installare l’aggiornamento di funzionalità cliccando su Download and install now. L’aggiornamento forzato entrerà in funzione quando la versione di Windows 10 installata ha terminato il suo ciclo di vita, ovvero 18 mesi dal rilascio ufficiale.

Gli amministratori IT, invece, possono iniziare a distribuire, all’interno delle proprie organizzazioni, la nuova versione di Windows 10 per verificare che app, dispositivi e infrastruttura funzionino come previsto. Ovviamente May 2019 Update è disponibile tramite Windows Server Update Services (WSUS), Windows Update for Business e Volume Licensing Service Center (VLSC) per la distribuzione in “anelli”, utilizzando System Center Configuration Manager o altri software simili.

Come sempre, le principali novità le elenchiamo di seguito:

• Windows Sandbox (una delle novità più interessanti)
• Windows Defender Application Guard migliorato
• Windows Defender Application Control (WDAC) migliorato
  
• Reserved Storage (OEM e installazioni pulite)
  
• Miglioramenti nella protezione dell’Identità
  
• Miglioramenti nella Console e WSL (approfondimento)
  
• Miglioramenti per la Sicurezza del sistema
  
• Miglioramenti nel pannello Impostazioni di Windows
  
• Miglioramenti nell’interfaccia del sistema
  
• Possibilità di rimuovere alcune applicazioni pre-installate
  
• Windows Update ridisegnato e semplificato
  
• Impostazioni privacy per il microfono
  
• Cortana separato dalla Ricerca
• Tema Chiaro

Ulteriori informazioni sulle novità di Windows 10 1903

Per chi volesse scaricare le ISO ufficiali vi forniamo i relativi dati identificativi:

• it_windows_10_business_editions_version_1903_x64_dvd_80006e02.iso
  SHA1: EE75A54678665606A5F5DE5F627101FF5BF87EAB
• it_windows_10_business_editions_version_1903_x86_dvd_fbbd1f98.iso
  SHA1: C16CA5546493332904CE8330A90CC0E5EDFE8CDA
• en_windows_10_business_editions_version_1903_x64_dvd_37200948.iso
  SHA1: E90FF03188AE55367BD0603C4D8B98B72C890DBB
• en_windows_10_business_editions_version_1903_x86_dvd_ca4f0f49.iso
  SHA1: DFE44D88849BEDF9DF686DFAA9964A9B1009986B

Per chi volesse provare una versione di valutazione di 90 giorni (edizione Enterprise) può scaricarla dall’ Evaluation Center:

Lingue disponibili

English (United States), English (Great Britain), Chinese (Simplified), Chinese (Traditional), French, German, Italian, Japanese, Korean, Spanish, Portuguese (Brazil)

Edizioni

• Windows 10 Enterprise, version 1903 | 64-bit ISO
• Windows 10 Enterprise, version 1903 | 32-bit ISO
• Windows 10 Enterprise LTSC 2019 | 64-bit ISO
• Windows 10 Enterprise LTSC 2019 | 32-bit ISO

Nelle prossime settimane, come di consueto, ci soffermeremo su alcune delle novità annunciate tramite la pubblicazione di articoli dedicati e sessioni all’interno di eventi sul territorio nazionale.

Continuate a seguirci sui nostri canali per tutte le novità.

Quando dobbiamo gestire un’infrastruttura RDS, soprattutto se le connessioni avvengono tramite reti poco performanti, è probabile che gli utenti lamentino malfunzionamenti generalizzati.

A volte la causa può essere imputata alla connessione, ma anche il comportamento degli utilizzatori può determinare situazioni che necessitano di approfondimento. Ad esempio, gli utenti che “chiudono” la finestra relativa alla sessione RDP senza effettuare una disconnessione corretta generano un numero elevato di sessioni disconnesse.

Per verificare il funzionamento dell’infrastruttura è utile interrogare il registro eventi in modo da individuare gli eventi significativi, soprattutto in caso di problemi di connessione.

Una RDS Farm può essere strutturata in diversi modi. L’esempio che prenderemo in considerazione in questo articolo si basa su una configurazione con accesso per mezzo di un portale Web e di un Connection Broker che ridirige le sessioni di connessione su più Session Host.

Prima di passare all’analisi vera e propria degli eventi è utile rivedere quali sono i flussi e le interazioni tra i vari componenti l’intera Farm RDS

I 5 ruoli che compongono una Farm RDS sono:

• Remote Desktop Web Access
  
• Remote Desktop Connection Broker
  
• Remote Desktop Session Host
  
• Remote Desktop Gateway
  
• Remote Desktop Licensing
  

Nel contesto analizzato in questa guida il ruolo RD Gateway non è installato e quindi non verrà considerato

Figura 1 schema dei ruoli RDS

Lo schema di figura 1 riporta in modo semplificato le relazioni tra i vari ruoli, l’uso del Web Access è utile in quanto permette da un unico portale l’accesso alle risorse che vengono rese disponibili

Configurazione della Farm tramite Server Manager

L’immagine qui sotto riporta la configurazione dell’ambiente utilizzato per l’analisi degli eventi

Figura 2 configurazione della farm RDS

Ruoli RDS

Il ruolo di Connection Broker che ha il compito di orchestrare gli accessi coordinando la distribuzione delle risorse in base al carico ed alla disponibilità degli host di sessione.

Il ruolo di Session Host, definisce i server dove fisicamente sono disponibili ed installate le applicazioni che vengono accedute tramite RDS.

Questo caso di studio non prevede la gestione di risorse di tipo Virtual Desktop (VDI)

Dal pannello di configurazione di RDS sono definiti 2 Session Host con uguale peso che verranno orchestrati tramite il Broker

Figura 3 infrastruttura Session Host

Analisi del flusso delle connessioni

Web Access

Il collegamento verso una farm RDS inizia dal ruolo di Web Access, quando l’utente ha effettuato il login viene generato e firmato digitalmente un file .RDP che permette la connessione sul Session Host

Il server Web essendo basato su IIS, ha i file di log che di default sono in “C:\inetpub\logs\LogFiles\W3SVC1”

In questa cartella, all’interno è presente un log testuale di tutte le attività. Analizzandolo è possibile identificare l’IP di provenienza della connessione ed anche l’utente che si è identificato

2019-05-19 21:32:29 10.0.1.81 GET /RDWeb/Pages/rdp/mstsc256_32x32.png – 443 dominio\utente
10.0.1.81 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko https://ts.ictpower.it/RDWeb/Pages/it-IT/Default.aspx 200 0 0 31

Ruolo Connection Broker

Il ruolo di Broker ha la responsabilità di assicurare la connessione, ossia di fare sì che sulla base delle regole configurate, ogni utente riceva le risorse corrette siano esse Sessioni Terminal, Remote App o VM in un ambiente VDI.

Il Broker si occupa anche di gestire le sessioni interrotte riconnettendole al Session Host corretto

All’interno del Registro Eventi il ruolo di Broker archivia le informazioni in:

“Microsoft-Windows-TerminalServices-SessionBroker/Operational“

“Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”

Registro Eventi

“Microsoft-Windows-TerminalServices-SessionBroker/Operational”

Le informazioni disponibili in questo ramo del registro permettono di rilevare le attività del broker durante la connessione verso le risorse che questo espone.

Una connessione che avviene in modo normale, senza errori, riporta i seguenti eventi in ordine cronologico

Figura 4 Sessione di login

Event ID 800

Event ID 801

Event ID 787

Event ID 818

Dettaglio di singoli eventi

Event ID 800

Figura 5 event ID 800

Questo evento riporta le richieste di connessione ed è utile per identificare le richieste di da parte degli utenti

Event ID 801

Figura 6 event ID 801

In questo evento sono riportate informazioni di dettaglio relativamente alla sessione ed in particolare il Session Host di destinazione e l’informazione su eventuali sessioni disconnesse su cui il Broker ha riconnesso la sessione in ingresso

Disconnected Session Found 0x0 indica che non erano presenti sessioni disconnesse su cui l’utente è stato indirizzato

Figura 7 event ID 801 con riconnessiona ad una sessione disconnessa

Il dettaglio dell’evento sopra informa che il collegamento in ingresso è stata assegnato ad una sessione disconnessa che non ha ancora raggiunto i limiti impostati per il reset.

Disconnected Session Found 0x1 è il dettaglio dell’evento che evidenzia questo comportamento

La condizione sopra si verifica per ogni singolo utente, non verranno mai riassegnate sessioni disconnesse ad utenti differenti

Event ID 787

Figura 8 event ID 787

Con l’interrogazione dell’evento ID 787 è possibile conoscere il nome della farm per cui l’utente ha richiesto l’accesso, viene identificata come “farm” il nome della Collection (figura 2).

Il Session ID è invece utile per identificare puntualmente la sessione utente anche sul session Host in quanto identificata in entrambe i ruoli con lo stesso ID

Event ID 818

Figura 9 event ID 818

È l’informazione ultima delle attività relative al Broker, da questo momento gli eventi dovranno essere seguiti direttamente sul Session Host su cui l’utente ha fatto accesso.

l’evento ID 818 riporta testualmente

“This connection request has resulted in a successful session logon (User successfully logged on to the end point). Remote Desktop Connection Broker will stop monitoring this connection request.”

Registro Eventi

“Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational”

In questo registro si trovano le informazioni relative alla gestione e reindirizzamento delle connessioni che il broker riceve in ingresso e ridirige verso i Session Host

Gli eventi che sono presenti per una sessione che avviene in modo normale, senza disconnessioni, sono

Event ID 1301

Event ID 1307

Figura 10 event ID 1301 versione del client RDP

Questo evento riporta il nome utente che accede alla farm RDS e l’indicazione della versione del client

Event ID 1307

Figura 11 event ID 1307

In questo evento è riportata l’informazione del Session Host di destinazione

La sequenza di eventi descritta sopra è presente anche se si accede ad una Remote App anziché ad una sessione desktop come in questo caso

Ruolo Session Host

Su questo server viene indirizzata la connessione ed è il ruolo che ospita le applicazioni, i registri eventi utili per la diagnostica delle connessioni RDP sono

“Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”

“Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational”

Registro Eventi

“Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”

Analogamente a quanto visto con il ruolo di Broker questo registro riporta gli eventi relativi alle connessioni che il Session Host riceve.

L’esempio sotto riporta la sequenza di eventi che è rilevabile per una connessione che inizia e viene terminata in modo normale, senza disconnessioni forzate

Figura 12 sequenza completa degli eventi su un Session Host Server

La sequenza degli eventi è la seguente e sono elencati nell’ordine quelli relativi alla connessione e successivamente quelli relativi alla disconnessione

Eventi Relativi alla connessione

Event ID 41

Event ID 42

Event ID 21

Eventi relativi alla disconnessione

Event ID 22

Event ID 23

Event ID 40

Event ID 24

Dettaglio di singoli eventi

Event ID 40/41

Figura 13 eventi 40 e 41 arbitraggio delle sessioni

Questi due eventi in successione temporale, indicano che il Session Host ha gestito l’arbitraggio della connessione ed è riportato l’ID della sessione che come abbiamo visto in precedenza, ha la sua corrispondenza sul Broker nell’evento ID 787

Event ID 21

Figura 14 event ID 13 logon utente

Questo evento riporta il dettaglio della connessione verso il Session Host con il nome utente e l’ip del client da cui è stata richiesta la connessione

Event ID 22

Figura 15 event ID 22 assegnazione della Shell

È l’ultimo degli eventi relativi al login ed all’accesso dell’utente, i tre eventi che seguono sono relativi alla disconnessione

Event ID 23

Figura 16 logoff utente

Quando viene richiesta la disconnessione “pulita” della sessione il primo evento che viene registrato è relativo all’ID 23

Event ID 40

Figura 17 event ID 40 e Reason Code 12

Questo è l’evento più significativo in caso di diagnostica, rilevarne la presenza, ma soprattutto il “Reason Code” può aiutare a diagnosticare problemi di connessione, evidenziare problemi di autenticazione o di risorse del Session Host

Figura 18 event ID 40 e reason code 5

Reason code 5 indica una disconnessione non richiesta dall’utente e tipicamente è indice di due possibili cause

Chiusura della sessione in modo anomalo della sessione RDS con la funzione “Chiudi Finestra”

Cadute della connessione di rete, questo evento è comune nel caso di connessioni particolarmente degradate

Reason code 3 indica che una sessione ha raggiunto il limite di inattività ed è stata terminata

La tabella seguente riporta i codici possibili relativi agli eventi di disconnessione

Figura 19 reason codes di disconnessione

Event ID 24

Figura 20 conclusione della sessione e completamento della disconnessione

Questo, in ordine temporale è l’ultimo evento e informa della conclusione della sessione.

Considerazioni

L’ambiente RDS è molto complesso e le variabili con cui può essere implementato sono molteplici, il caso analizzato in questo articolo prende spunto da una installazione reale dove si sono presentati problemi di gestione delle connessioni, problemi in parte dovuti alle reti di connessione ed in parte alla scelta di utilizzare alcuni utenti comuni per l’accesso al desktop e di demandare l’autenticazione dell’utente all’applicativo.

Questa modalità operativa, ha amplificato il “problema” delle sessioni disconnesse in quanto il tempo minimo impostabile per il reset di queste sessioni è di 1 minuto, l’individuazione di determinati eventi ha permesso di correggere alcune configurazioni e di implementare le modalità di accesso in modo differente

Individuazione degli eventi tramite PowerShell

Al fine di agevolare la ricerca degli eventi descritti nell’articolo, è proposto qui un semplice script PowerShell che con poche modifiche può aiutare nella ricerca dei vari eventi all’interno del registro

Per operare lo script deve aver popolata la varibile $RdsShServers con il nome di tutti i Session Host, quando eseguito verranno riportati gli eventi di disconnessione con Reason Code 5

#Rilevazione degli eventi di disconnessione non corretti

$RdsShServers = 'rdsh01srv','rdsh02srv','rdsh04srv','rdsh03srv'
foreach ($RdsShServer in $RdsShServers )

{
$NotCorrectDisconnection = Get-WinEvent -ComputerName $RdsShServer -FilterHashtable @{logname='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational';ID=40 ;StartTime=(Get-Date).Date } | where-object  { $_.Message -like '*reason code 5' }
Write-Host $RdsShServer " " $NotCorrectDisconnection.Count
} 



{


$NotCorrectDisconnection
=
Get-WinEvent
-ComputerName
$RdsShServer
-FilterHashtable @{logname='Microsoft-Windows-TerminalServices-LocalSessionManager/Operational';ID=40 ;StartTime=(Get-Date).Date } |
where-object { $_.Message -like
'*reason code 5' }


Write-Host
$RdsShServer
" "
$NotCorrectDisconnection.Count


}

Il reset delle sessioni in stato disconnesso può essere gestito in modo alternativo come descritto in questo articolo

https://massarobi.wordpress.com/2019/05/10/gestione-delle-sessioni-rds-disconnesse/

La versione rilasciata ad aprile è stata la più attesa: non è più una preview bensì una release in General Availability (GA), quindi ufficiale.

I contributi della comunità che vengono rilasciati sul portale uservoice restano un punto cardine per il miglioramento di Windows Admin Center, sia in termini di priorità che di investimenti da parte di Microsoft. Provare ad elencarli tutti è piuttosto complicato poiché sono davvero tanti. Raggruppando per tematiche quelli più significativi otteniamo quella che può definirsi la lista delle funzionalità di Windows Admin Center.

User Experience

Sezione in cui ricadono tutte quelle funzionalità relative all’utilizzo della dashboard:

• Shared connections: Gli amministratori possono condividere/fornire la lista delle connessioni agli utenti di un WAC gateway
• Add connections from Active Directory: Utilizzando una comoda search bar, è possibile aggiungere una nuova connessione ricercando direttamente da Active Directory
• Dark mode theme: Una personalizzazione del tema della dashboard, da chiaro a scuro

Platform

Notifiche, accessibilità e vari tool funzionali ricadono in questo ambito. I più importanti:

• PowerShell module for connections: Utilizzando PowerShell è possibile programmare/automatizzare l’import e l’export della lista delle connessioni, comprese le personalizzazioni come tags e connessioni condivise
• PowerShell module for extensions: Utilizzando PowerShell è possibile visualizzare il dettaglio delle estensioni utilizzate, configurarne i feeds, installare/aggiornare/rimuovere estensioni sia automaticamente che programmaticamente.

Core Tools

Sezione dedicata alla gestione dei server

• Power options: utilizzando la relativa sezione è possibile operare sui power profiles, configurando impostazioni come “High performance power plan” degli host Hyper-V
• Platform hardware access: Nella pagina Server Overview Page viene mostrato il serial number del controller BMC con un link all’IP del server se si utilizza questo standard (IPMI-compatible BMC)
• SMB Shares for storage: Con questa funzionalità è possibile creare e configurare una VM ed utilizzare una share di rete per contenere il VHD.
• Containers: Questo tool è un’estensione rilasciata da poco ed ancora in preview. Permette la visualizzazione dei container su un Windows Server container host. Se il sistema utilizzato è Windows Server Core è possibile visualizzare i logs degli eventi ed accedere alla CLI del container.

Ancora in versione preview tra le estensioni disponibili:

• DNS tool: Dopo averlo abilitato nella pagina delle estensioni, questo tool permette la gestione del DNS server.
• DHCP tool: Anche in questo caso è da abilitare nella pagina delle estensioni, permette la gestione del DHCP server.
• Active Directory: permette di gestire utenti e gruppi AD, abilitare/disabilitare utenti e computer, resettare password e tanto altro.
• Windows Admin Center Developer Tools: per permettere lo sviluppo di un’estensione custom, è possibile abilitare questa estensione che da accesso al Windows Admin Center SDK. Per maggiori informazioni è possibile consultare la documentazione ufficiale oppure visitare la pagina GitHub.
• Windows Defender: permette la gestione di Windows Defender e la visualizzazione degli eventi analizzati dall’antivirus.

Figura 1: WAC – Windows Defender

Hybrid

Sezione è dedicata all’integrazione con Azure

• Storage Migration integration with Azure File Sync: Utilizzando Azure File Sync (AFS) permette, ad esempio, di migrareda una vecchia versione di Windows Server a Windows Server 2019.
• Storage Migration Services: una ulteriore modalità di migrazione, da un Windows Server 2003/2008/2012 direttamente ad una VM in IaaS su Azure.
• Azure Backup: permette di monitorare/gestire i vari jobs di backup, gestire gli errori, utilizzare Recovery Services Vault e tanto altro.
• Automate deployment in Azure: Microsoft ha rilasciato uno script per la creazione di un gateway Windows Admin Center su Azure. Questo fantastico script permette la creazione dell’intero ambiente e relative configurazioni all’interno del resource group. Eseguibile su Azure Cloud Shell.
• Azure Hybrid services tool: In questa sezione sono state centralizzate tutte una serie di funzionalità relative ai servizi su Azure.

Figura 2: WAC – Servizi ibridi di Azure

Ancora in preview:

• Azure Monitor: con questo tool è possibile configurare delle email di notifica dello stato dei server.
• Azure File Sync: permette la centralizzazione delle share su Azure. Azure File Sync gestisce Windows Server utilizzandolo come sistema di cache della share su Azure.

HCI – Hyperconverged infrastructure

Sezione dedicate alle infrastrutture iperconvergenti

• Clustering: permette la possibilità di gestire un failover cluster iperconvergente (HCI) con relativa gestione delle risorse nel cluster.
• Hyper-V: permette la creazione e gestione delle VM, l’aggiunta/rimozione di VHD a VM accese e tanto altro.
• Storage Spaces Direct: permette la gestione dei dischi configurati con Storage Spaces Direct (S2D), quindi dischi altamente disponibili, per funzionalità di storage anche per un cluster HCI.
• Software Defined Networking: una suite di tre tool per la gestione delle ACL, dei protocolli (IPSEC, GRE, L3), il monitoraggio delle reti SDN e tanto altro.

Extension experience

Infine abbiamo tutta una serie di tool e sezioni dedicate alle notifiche di Windows Admin Center stesso, alla gestione degli aggiornamenti interni e delle estensioni messe a disposizione sia da Microsoft che dai partner.

Sono attualmente disponibili diversi tool da installare per migliorare l’utilizzo della dashboard di WAC così come è possibile, utilizzando SDK e guide ufficiali, creare dei feed per distribuire le estensioni sviluppate ad hoc, sia sui canali ufficiali sia su canali privati.

Figura 3: WAC – Estensioni

Conclusioni

In un solo anno sono successe tante cose, molti rilasci, tantissime funzionalità. La community che collabora con Microsoft cresce sempre di più e Windows Admin Center migliora di rilascio in rilascio. Quello che possiamo provare con mano oggi è una versione stabile che rappresenta in maniera impeccabile lo sforzo fatto per il raggiungimento degli obbiettivi prefissati: una sistema di gestione alternativo, moderno, accattivante e gratis!

Microsoft Intune è uno strumento di management cloud-based che permette la gestione e la protezione dei dispositivi aziendali.

Nell’articolo Configurare il Co-Management per gestire i dispositivi Windows 10 con Configuration Manager e Intune abbiamo già avuto modo di parlare dei numerosi vantaggi che lo strumento offre nel Modern Desktop.

Intune supporta diverse tipologie di applicazioni e le opzioni disponibili variano a seconda dell’app.

Figura 1 – Tipologie di applicazioni disponibili su Intune

Quando si parla di gestione delle app, si intendono le seguenti attività:

• Assegnazione delle app per dispositivi mobili;
• Configurazione delle app con le relative impostazioni;
• Aggiornamento delle app;
• Creazione di report sull’inventario delle app per dispositivi mobili;
• Monitoraggio dell’uso delle app per dispositivi mobili.

Per configurare una nuova applicazione, fate l’accesso al portale Intune e selezionate Client apps -> Apps -> Add.

Figura 2 – Aggiungere un’applicazione su Intune

Applicazioni disponibili su Intune

Office 365 Suite

Questo tipo di app permette di semplificare la distribuzione della suite Office 365 ai dispositivi Windows 10 e macOS.

Per le personalizzazioni di Office 365, è possibile importare il file .xml (Office Customization Tool) o utilizzare il Configuration designer, come dal seguente esempio.

Create una nuova applicazione selezionando come App type
Windows 10 e compilate i campi richiesti nel tab App Suite Information.

Figura 3 – Compilazione del tab App Suite Information

Nel tab Configure App Suite, specificate le applicazioni della suite da installare sui dispositivi.

Figura 4 – Selezione delle app di Office 365 da installare

Nel tab App Suite Settings verranno richieste una serie di impostazioni:

• Architettura;
• Update channel;
• Versione della suite O365;
• Eventuale rimozione delle versioni precedenti;
• Accettazione automatica dell’EULA;
• Shared computer activation;
• Lingue.

Figura 5 – Opzioni disponibili per la suite O365 nel tab App Suite Settings

Line-of-business app

La
Line-of-business permette l’installazione di un’app utilizzando l’apposito file di setup.

Le estensioni file per le Line-of-business app di Windows sono msi, appx, appxbundle, msix e msixbundle. Per macOS sono supportati solo file con estensione pkg.

Di seguito un esempio di distribuzione di 7-zip utilizzando il file con estensione .msi .

Selezionate come app type Line-of-business app e successivamente caricate il file di setup.

Figura 6 – Caricamento del file di setup .msi

Popolate I campi richiesti nel tab App Information, facendo attenzione al campo App install context che varia a seconda dell’applicazione da installare.

Figura 7 – App information per Line-of-business app

Windows app (Win32)

Tramite questo tipo di app, è possibile distribuire applicazioni sia a 32 bit che a 64 bit per sistemi operativi Windows.

Per usare la gestione delle app Win32, sono necessari i seguenti prerequisiti:

• Windows 10 versione 1607 o successive (edizioni Enterprise, Pro ed Education);
• Client joinato nelle modalità Azure Active Directory (AAD) o Hybrid Azure Active Directory;
• Dimensioni massime di 8 GB.

Per la preparazione dell’applicazione da distribuire, è necessario utilizzare il tool IntuneWinAppUtil.exe.

Di seguito un esempio di distribuzione dell’applicativo Citrix Workspace utilizzando come tipo app Windows app (Win32).

Effettuate il download del setup di Citrix Workspace, del tool IntuneWinAppUtil.exe e avviate prompt dei comandi.

Lanciate il comando intunewinapputil -c (Cartella contenente il file di setup) -s (file di setup) citrixreceiver.exe -o (Cartella di destinazione dove verrà generato il file con estensione.intunewin)

Per tutte le opzioni disponibili e la documentazione vi invito a consultare la pagina officiale su GitHub Microsoft Win32 Content Prep Tool.

Figura 8 – Utilizzo del tool IntuneWinAppUtil.exe

Completata la procedura di conversione, creiamo una nuova Windows app (Win32) e carichiamo il file generato nel tab App package file.

Figura 9 – Caricamento del file .intunewin

Popolate tutti i campi richiesti in App information.

Figura 10 – App information Citrix Workspace

Nel tab Program vengono richiesti i comandi per installare e disinstallare l’applicazione interessata. Nel caso di Citrix Workspace sono i seguenti:

• Install command: CitrixWorkspaceApp.exe /silent
• Uninstall command: CitrixWorkspaceApp.exe /uninstall

Figura 11 – Tab Program specifica dei comandi da lanciare per l’installazione e la disinstallazione

Figura 12 – Requirements dell’applicazione da installare

La detection rule varia a seconda dell’applicazione.

Nel caso di Citrix Receiver, ho preferito utilizzare la verifica su una chiave di registro:

• Rule type: Registry;
• Key Path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\PluginPackages\XenAppSuite\ICA_Client
  
• Value name: Version
• Detection method: Version comparison;
• Operator: Greater than or equal to;
• Value: 18.10.0.20023

Figura 13 – Detection method per applicazione Citrix Workspace

Store App

È possibile aggiungere un’app degli store Android, iOS e Microsoft.

Per distribuire l’applicazione sui dispositivi, è necessario che gli utenti abbiano un account sullo store di riferimento.

Su Intune è necessario indicare l’url dell’app da installare (Es. https://play.google.com/store/apps/details?id=com.citrix.Receiver&hl=it) .

Figura 14 – Configurazione di una Store App

Sul dispositivo apparirà un pop-up con la richiesta di installazione dell’applicazione.

Figura 15 – Popup con richiesta di installazione dell’applicazione

Figura 16 – Installazione dell’applicazione dallo store di riferimento

Built-in App

La Built-in App semplifica l’assegnazione di app gestite dedicate, ad esempio l’app di Microsoft Teams, ai dispositivi iOS e Android.

Il metodo di installazione è analogo a quello della Store App.

Figura 17 – Lista built-in app disponibili su Intune

Figura 18 Popup con richiesta di installazione dell’applicazione

Figura 19 – Installazione dell’applicazione dallo store di riferimento

Web link

Questo tipo di App permette di pubblicare un collegamento web sia all’interno dell’App Portale Aziendale sia nel widget di riferimento.

Figura 20 – Configurazione di un web link

Figura 21 – Visualizzazione del Web Link sul Widget

Assegnazione di un’app

Una volta terminata la configurazione di un’applicazione, è necessario assegnarla ad un gruppo di utenti.

In Client apps -> Apps -> Selezionare l’applicazione -> Assignments.

Figura 22 – Tab Assignments nell’applicazione desiderata

I tipi di assegnazione a disposizione sono:

• Available for enrolled devices: assegnare l’app ai gruppi di utenti che possono installare l’app dall’app Portale aziendale o dal sito Web.
• Required: l’app viene installata nei dispositivi nei gruppi selezionati;
• Uninstall: l’app viene disinstallata dai dispositivi nei gruppi selezionati.

Figura 23 – Tipi di assegnazione disponibili per applicazione

Conclusioni

Come abbiamo potuto vedere, Intune offre un’ampia gamma di funzionalità per la gestione delle applicazioni sui dispositivi aziendali e permette una facile amministrazione da parte del reparto IT.

Per approfondire, è disponibile l’articolo ufficiale https://docs.microsoft.com/it-it/intune/apps-add

Circa un anno fa in ICTPower è comparso il primo articolo sulla nuova console di gestione centralizzata di Windows Server chiamata Windows Admin Center (WAC). Gli articoli ripropongono approfondimenti sulle versioni, sugli scenari di utilizzo e sui metodi di implementazione.

In questo approfondimento vogliamo analizzare la gestione del certificato di accesso al Portale, che utilizza di default un certificato di tipo Self-Signed. Lo scenario che riproponiamo di seguito si basa, in un ambiente Enterprise, sulla diponibilità di una CA integrata in AD e configurata secondo le guide proposte anch’esse su ICTPower

Di norma l’installazione di WAC consente la scelta di un certificato già presente nello store macchina.

Se questo certificato non fosse già disponibile, è possibile indicare all’installer di generarne uno di tipo Self-Signed che avrà una scadenza di 60 giorni. Per la peculiarità di una connessione di questo tipo ai vari utenti verrà proposto un warning relativo alla connessione non sicura

Il certificato generato dall’installer è visualizzabile con il comando certlm.msc eseguito sul server dove avete installato la console di gestione di Windows Admin Center.

Figura 1 certificato Self- Signed creato durante l’installazione di Windows Admin Center

Questa guida propone i passi necessari alla modifica di una installazione già funzionante in cui è necessario sostituire il certificato auto firmato con uno “ufficiale” rilasciato dalla CA interna

I passi da eseguire sono:

• Creazione di un template ad hoc, se non già presente; il template che si utilizza è quello disponibile nella CA come “Web Server”
• Richiesta del certificato secondo il template creato, la richiesta deve essere effettuata come Account Macchina
• Riconfigurazione del WAC affinché usi il certificato ottenuto dalla CA interna

Creazione del Template sulla CA

Accedendo alla console di gestione della Issuing CA è necessario individuare il ramo Certificate Template e successivamente Manage

Figura 2 gestione template del certificato

Dall’elenco è necessario individuare il template Web Server

Figura 3 selezione del template certificato da duplicare

Con il tasto DX selezionare Duplicate Template e proseguire con le impostazioni
modificando alcuni Tab

Figura 4 definizione del nome e della validità del nuovo template certificato

Nel tab General bisogna impostare il nome del nuovo Template ed eventualmente la validità

Figura 5 impostazione della sicurezza per l’utilizzo del nuovo template certificato

Nel tab Security è necessario definire i permessi di Enroll al fine di permettere al server di Windows Admin Center di poter richiedere ed ottenere il certificato. Nell’esempio sopra la security è più “ampia” del necessario, permettendo a tutti gli utenti autenticati di usare questo template; in caso fosse necessario, potrebbero essere definiti permessi più stretti, ad esempio soltanto per l’account macchina relativo al server WAC

Terminata la configurazione del template, dalla gestione della CA, è necessario abilitarne il rilascio.

È sufficiente selezionare Certificate Template/New/ Certificate Template to Issue e dall’elenco abilitare il template duplicato in precedenza.

Figura 6 distribuzione del template duplicato

Figura 7 abilitazione del template duplicato

A questo punto la configurazione della CA è terminata ed è necessario operare sullo store di certificati macchina del WAC Server in modo da ottenere un certificato secondo il Template creato

Generazione della richiesta ed Enroll del certificato

Con il comando certlm.msc è possibile accedere direttamente allo store Certificati Macchina del Windows Admin Center e dal ramo Personal/Certificate operare come segue

Figura 8 Richiesta del certificato da utilizzare in Windows Admin Center

Con il tasto DX selezionare All Tasks e Request
New Certificate e proseguire per i passi successivi con le impostazioni predefinite

Figura 9 Wizard per la richiesta di un nuovo certificato

Figura 10 utilizzo delle Policy dichiarate in AD

Selezionando Active Directory Enrollment Policy viene visualizzato l’elenco completo dei template abilitati, e tra questi è presente anche quello creato in precedenza per WAC

Figura 11 selezione del template certificato da utilizzare per WAC

Selezionato quest’ultimo e cliccando sulla richiesta di ulteriori informazioni necessarie per l’Enroll, si deve fornire l’informazione relativa all’FQDN del server WAC

Figura 12 impostazione del nome da inserire nel certificato

Per completare questo passo è necessario modificare Subject Name ed Alternative Name in modo coerente con l’ambiente di installazione del WAC e successivamente premere Add per entrambe i campi, proseguendo con OK la richiesta può essere successivamente completata con Enroll

Figura 13 completamento dell’enrollment del certificato

Figura 14 rilascio del certificato

A questo punto nello Store Macchina del server è presente il certificato richiesto

Figura 15 visualizzazione del certificato rilasciato

Anche la parte di configurazione/richiesta del certificato dal lato del server WAC è completata, a questo punto della procedura è necessario fare si che l’applicazione utilizzi il nuovo certificato disponibile

Per Prima cosa è necessario individuare il Thumbprint del Certificato, e questo valore può essere rilevato con il comando certutil -store my oppure direttamente in modalità grafica con l’utility certlm.msc

Figura 16 Thumbprint del certificato creato per WAC

Figura 17 Thumbprint tramite certutil -store my

Tra le due possibilità, se si vuole copiare tramite “copia incolla” il valore del Thumbrint è preferibile la seconda in quanto se si utilizza la GUI vengono copiati alcuni caratteri nascosti che all’atto della validazione dell’Hash, da parte dell’installer, fanno sì che la procedura non si concluda correttamente generando il seguente errore

Figura 18 errore in fase di “lettura” del thumbrint copiato dalla GUI

Riconfigurazione dell’Installazione di Windows Admin Center per l’utilizzo del nuovo certificato

Ottenuta l’informazione sul certificato da utilizzare è sufficiente accedere al pannello di controllo nella sezione programmi e funzionalità e modificare WAC

Figura 19 modifica dell’installazione di WAC

Verrà avviato l’installer che presenterà le opzioni possibili

Figura 20 scelta delle opzioni di modifica

Selezionando Cambia e fornendo il valore del thumbprint rilevato in precedenza l’accesso al portale WAC avverrà tramite una connessione SSL cifrata con il certificato scelto

Figura 21 dichiarazione del certificato da utilizzare in sostituzione di quello self-signed

A questo punto il browser non presenta più il classico Warning relativo all’utilizzo di un certificato non valido, ed è possibile verificare che la connessione SSL avviene per mezzo del certificato impostato prima

Figura 22 accesso al portale e verifica dell’utilizzo del certificato rilasciato dalla Ca interna

La procedura vista qui è da utilizzare per una installazione di Windows Admin Center già operativa e funzionante, ma con un certificato self-signed generato in fase di installazione, tuttavia disponendo già da subito di un certificato da utilizzare per WAC sarebbe sufficiente impostarne il valore, da rilevare nelle modalità descritte sopra o con metodi alternativi, e variare le opzioni di default come evidenziato in figura 21 durante la fase di prima installazione.

La procedura riportata in questa guida è stata seguita ed implementata per una installazione in produzione con CA versione 2012R2, Windows Admin Center versione 1904 installato su Windows Server 2016. Come è rilevabile dalla documentazione relativa a WAC sono possibili altri scenari di installazione, ma la parte che è oggetto di questa guida rimane pressoché invariata.

Riferimenti

Windows Admin Center Documentazione Ufficiale

IctPower Documentazione su Windows Admin Center

IctPower Documentazione sulla implementazione di CA di tipo Enterprise

Torniamo prepotentemente a parlare di Linux su Windows in seguito alle grandi novità introdotte da Microsoft a partire da Windows 10 Build 18917. Questa versione al momento è disponibile solo per gli iscritti al programma Insider. Se non vedete l’ora di provarla per scoprire questa e molte altre funzionalità in anteprima potete iscrivervi gratuitamente direttamente sul portale Insider all’indirizzo https://insider.windows.com/en-us/

La grande novità di cui vogliamo parlare oggi è il cambiamento sostanziale nella struttura della funzionalità WSL (Windows Subsystem for Linux), che già da qualche anno rappresenta uno degli aspetti più particolari dei nuovi sistemi operativi Microsoft. Un cambiamento che un po’ stravolge quello che conoscevamo di WSL, a tal punto che la funzionalità ora viene chiamata WSL2. Abbiamo ampiamente scritto di WSL nei precedenti articoli su questo portale, quindi non ci dilungheremo troppo nel descrivere le potenzialità dello strumento, ma spendiamo due righe solo per ricordare che grazie a questa funzionalità è possibile utilizzare i binari compilati per Linux direttamente sul nostro client Windows 10 o su Windows Server 2019. La prima versione di WSL, che è ancora presente sulle versioni in uso di Windows 10, utilizza uno strato software che si comporta come un emulatore, e permette così di gestire l’esecuzione dei comandi Linux effettuando le opportune “traduzioni” per rendere le chiamate di sistema gestibili dal kernel Windows.

Ricordiamo come attivare WSL, anche perché rappresenta un prerequisito per l’uso di WSL2, e teniamo presente che la funzionalità è presente su tutti i Windows 10 a 64bit, ma è disattivata di default. L’attivazione è tuttavia semplicissima, è sufficiente infatti aprire “Attiva o disattiva funzionalità di Windows”

Mettere un segno di spunta su “Sottosistema Windows per Linux” e riavviare

In alternativa è possibile installare la funzionalità aprendo una PowerShell con privilegi elevati attraverso il comando:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Al riavvio del sistema possiamo scegliere l’app relativa alla distribuzione da installare ed installarla come una normale Windows App. Ad oggi sono disponibili le seguenti distribuzioni, di cui vi fornisco un collegamento ipertestuale, ma l’elenco è in continuo aggiornamento; per ottenere l’elenco completo è sempre possibile cercare “Linux” direttamente sul Microsoft Store.

• Ubuntu 16.04 LTS
  
• Ubuntu 18.04 LTS
  
• OpenSUSE Leap 15
  
• OpenSUSE Leap 42
  
• SUSE Linux Enterprise Server 12
  
• SUSE Linux Enterprise Server 15
  
• Kali Linux
  
• Debian GNU/Linux
  
• Fedora Remix for WSL
  
• Pengwin
  
• Pengwin Enterprise
  
• Alpine WSL
  

Per questo esempio abbiamo scelto Ubuntu 18.04 LTS, apriamo quindi il relativo link:

Cliccando su Ottieni verrà avviato il download della distribuzione tramite l’App Microsoft Store

Al termine del download clicchiamo su Launch per avviare il mini-wizard per l’installazione

Durante il Wizard sarà richiesto di scegliere l’username e la password dell’utente da utilizzare all’interno della distribuzione Linux. L’utente è completamente indipendente da quello utilizzato su Windows. Al temine è possibile utilizzare la nostra distribuzione Ubuntu con WSL

Possiamo ora digitare exit per chiudere la shell e terminare l’esecuzione del processo WSL.

Veniamo quindi alla novità introdotta con la build 18917, dove l’emulatore lascia spazio ad un vero Kernel Linux, con un notevole aumento di prestazioni e soprattutto di compatibilità. Questo è reso possibile dalla tecnologia di virtualizzazione inclusa in Windows 10, attraverso la quale WSL2 è in grado di eseguire i comandi Linux facendo uso di una apposita macchina virtuale. Questa macchina virtuale avrà quindi un indirizzo IP diverso da quello della macchina Windows, ed è in fase di prossimo sviluppo il sistema di comunicazione tra Windows e WSL2 anche utilizzando “localhost”.

Vediamo subito come attivare WSL2, operazione che consiste semplicemente nel selezionare tra le funzionalità di Windows quella denominata “Virtual Machine Platform”

In alternativa è possibile installare la funzionalità aprendo una PowerShell con privilegi elevati attraverso il comando:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

Come vediamo nello screenshot seguente, non è richiesto il riavvio

Possiamo a questo punto indicare alla nostra macchina di utilizzare la nostra app Ubuntu con WSL2 (macchina virtuale) e non più con WSL (emulatore).

Utilizziamo quindi il comando PowerShell seguente per visualizzare la corretta denominazione delle distribuzioni installate sulla macchina

wsl --list --verbose (o più velocemente wsl -l -v)

Assicuriamoci che la distribuzione sia in stato “Stopped”, quindi se necessario chiudiamo tutte le istanze di WSL aperte, altrimenti la conversione alla versione 2 restituirà l’errore “Accesso negato”.

Sostituendo a <Distro> il nome della distribuzione attiviamo così Windows Subsystem For Linux versione 2

wsl --set-version <Distro> 2

Nel nostro caso:

wsl --set-version Ubuntu-18.04 2

Da questo momento stiamo utilizzando Ubuntu in una macchina virtuale, perfettamente integrata nel sistema Windows 10; notiamo che la vm non utilizza in alcun modo il servizio Hyper-V. Sulla nostra macchina, infatti, è stato possibile convertire la macchina a WSL2 abilitando l’opzione Virtual Machine Platform senza utilizzare il ruolo Hyper-V. In ogni caso teniamo presente che per l’attivazione di questa funzionalità è richiesto il supporto alla virtualizzazione sul processore e la relativa abilitazione nel BIOS.

Verifichiamo che Ubuntu stia girando in una VM semplicemente guardando il risultato dei comandi ipconfig (da Windows) e ip addr (da Linux); noteremo che gli ip in uso sono diversi

È però ancora assolutamente possibile lanciare comandi Linux dal prompt di comandi di Windows, volendo anche in maniera concatenata:

A questo punto non posso non terminare l’articolo con una prova di forza: vediamo come si comparta WSL2 con nmap il tool di scansione della rete per eccellenza, una sfida davvero ostica perché una delle limitazioni più grosse della prima versione di WSL è quella di non poter utilizzare i RAW socket; nmap infatti non è utilizzabile in una sessione WSL.

Installiamo nmap con

sudo apt-get install nmap

E lanciamo un portscan su www.ictpower.it

FUNZIONA! Il risultato ci mostra che sono aperte le porte 80 e 443 come potremmo aspettarci su un qualsiasi webserver, e possiamo sicuramente affermare che il tool nmap viene eseguito con successo.

Direi a questo punto senza ombra di dubbio che WSL2 è promosso a pieni voti, ed ora sta solo a noi capire come sfruttarlo al meglio.

Alla prossima!

Introduzione

In questo articolo faremo alcune considerazioni sul licensing dei Remote Desktop Services tratte dall’analisi dell’EULA (End-User License Agreement) ovvero l’accordo di licenza con l’utente finale di Windows Server e Windows. Occorre infatti prestare attenzione quando è necessario acquistare le RDS CAL per non incorrere in fraintendimenti soprattutto quando si utilizzano prodotti di terze parti per la gestione della multiutenza.

Windows Server EULA e RDS

Gli accordi di licenza finale dei prodotti Microsoft tradotti nelle varie lingue sono disponibili al seguente link Microsoft License Terms da cui è possibile ricercare l’EULA per Windows Server 2019 Datacenter e Standard in lingua italiana disponibile anche al seguente link diretto https://www.microsoft.com/en-us/Useterms/Retail/WindowsServer2019/DatacenterAndStandard/Useterms_Retail_WindowsServer2019_DatacenterAndStandard_Italian.htm.

Sebbene di seguito di citerà l’EULA per Windows Server 2019 Datacenter e Standard le considerazioni valgono in linea di principio anche per le versioni precedenti di Windows Server.

Una prima considerazione risaputa è che i servizi Windows Server Remote Desktop richiedono licenze CAL Aggiuntive (punto 4 lettera a) ovvero richiedono la versione corrispondente della licenza CAL per Servizi Windows Server Remote Desktop (RDS CAL).

Il punto 4 lettera b dell’EULA specifica in modo più dettagliato quando occorre possedere l’RDS CAL:

“Servizi Windows Server Remote Desktop. In aggiunta a una licenza CAL per Windows Server, il licenziatario dovrà acquistare la corrispondente versione della licenza CAL per Servizi Windows Server Remote Desktop per ciascun utente o dispositivo che (i) accede, in modo diretto o indiretto, alla funzionalità Remote Desktop Services, (ii) accede, in modo diretto o indiretto, al software server per ospitare un’interfaccia utente grafica (utilizzando la funzionalità Servizi Windows Server Remote Desktop o altra tecnologia) o (iii) accede alla funzionalità Servizi Multipoint. Per ulteriori informazioni sulle licenze CAL per Servizi Desktop Remoto Windows Server, visitare la pagina (aka.ms/windowsrds).”

In particolare si noti che viene specificato che l’RDS CAL è necessaria se si accede in modo diretto o indiretto al software server per ospitare un’interfaccia utente grafica (utilizzando la funzionalità Servizi Windows Server Remote Desktop o altra tecnologia). In altre parole la necessità dell’RDS CAL è legata al fatto non solo di utilizzare la funzionalità Remote Desktop Services, ma anche al fatto di accedere a software server che ospita un’interfaccia utente grafica. Questo significa che se si implementano soluzioni di terze parti che offrono la possibilità di accedere all’interfaccia grafica del server in modalità simile a quanto offerto dalla funzionalità Remote Desktop Services è comunque necessaria l’RDS CAL.

Questo aspetto è anche chiarito più esplicitamente nel documento di maggio 2017 Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS relativo a Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 e Windows Server 2016 in cui viene indicato:

“Server RDS CAL for each user or device that (i) directly or indirectly accesses any of the RDS functionality and/or (ii) directly or indirectly accesses the server software to interact with a graphical user interface (GUI) using RDS functionality or any other third-party technology.

Remote Desktop Services functionality is defined as those features or services that are running when enabling the Remote Desktop Services role and/or role service(s) in Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2016. This includes, but is not limited to, Remote Desktop Gateway, Remote Desktop Web Access, Remote Desktop Connection Broker, Remote Desktop Session Host, and Remote Desktop Virtualization Host.”

Sempre nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS è possibile trovare la seguenti FAQ da cui risulta che l’RDS CAL è necessaria se si fa uso di una qualunque tecnologia che permette l’interazione con la GUI.

“Do I need an RDS CAL if I am using a third-party technology like Citrix XenApp, Citrix XenDesktop, Ericom PowerTerm WebConnect, Quest Virtual Access Suite, GraphOn Go-Global, and so on to directly or indirectly access the server software to interact with the GUI?

Yes. An RDS CAL is required for any technology used to directly or indirectly interact with the GUI. This includes (but is not limited to) using Microsoft Remote Desktop Services or other third-party software that enables multiuser scenarios on Windows Server.”

Un’altra interessante FAQ presente nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS è quella che riporta che la versione della RDS CAL deve corrispondere alla versione del sistema operativo server (indicazione che era anche fornita nel punto 4 lettera b dell’EULA):

“What version of the RDS CALs do I need?

The CAL version must correspond to the server software version it accesses. Older version of CALs cannot be used with the newer version of the server software, but newer version RDS CALs can be used with an older version of the server software as defined in the interoperability matrix at http://social.technet.microsoft.com/wiki/contents/articles/14988.rds-and-ts-cal-interoperability-matrix.aspx.

The only exception to this rule are the R2 server releases where the older CALs can sometimes work with the newer R2 release of server software. For example, Windows Server 2012 RDS CALs can be used with Windows Server 2012 R2, and there are no new Windows Server 2012 R2 RDS CALs required.”

Una terza FAQ presente nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS riporta inoltre che l’RDS CAL è necessaria anche quando si usa una qualunque funzionalità dei Remote Desktop Services indipendentemente dal fatto che si implementi o meno un ambiente multiutente:

“Do I need an RDS CAL if I am not running a multiuser environment but use functionality in Remote Desktop Services—for example, Remote Desktop Gateway?

Yes. An RDS CAL is required to use any functionality included in the Remote Desktop Services role in Windows Server. For example, if you are using RDS Gateway and/or Remote Desktop Web Access to provide access to a Windows client operating system on an individual PC, both an RDS CAL and Windows Server CAL are required.”

Il punto 4 lettera a dell’EULA specifica le eccezioni per le quali il licenziatario non necessita di CAL e una di queste eccezioni riguarda un massimo di due dispositivi o utenti che accedono alle istanze del software server esclusivamente per tali istanze. Ciò implica che non sono necessarie CAL e RDS CAL per un massimo di due dispositivi o utenti che accedono a istanze sul server per scopi amministrativi.

Tale aspetto è chiarito più esplicitamente sempre nel documento Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS con indicazione specifica e una FAQ dedicata:

“No RDS CALs are required for up to two users to access instances of the server software for administration purposes.”

“Do I have to acquire RDS CALs if I am only remotely administering Windows Server operating systems by using Remote Desktop for Administration?

No. Up to two users may connect to the Windows Server operating system simultaneously to perform administrative functions without needing any RDS CALs. Additional administrative users need the appropriate RDS CALs.”

Windows 10 EULA e RDS

Sempre dal link Microsoft License Terms è possibile ricercare l’EULA per Windows 10 in lingua italiana disponibile anche al seguente link diretto https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/Useterms_Retail_Windows_10_Italian.htm.

Dalla lettura dell’EULA di Windows 10 è possibile concludere che nel caso si voglia accedere remotamente al sistema in modalità multiutenza per scopi diversi dall’assistenza remota, anche con strumenti di terze parti, occorre possedere una licenza per ogni utente che esegue l’accesso.

L’accesso multiutente viene disciplinato in maniera più precisa nelle seguenti opzioni multiutente contenute nel punto 2 lettera d dell’EULA:

“(ii) Connessioni multiple o in pool. L’hardware o il software utilizzato dal licenziatario per eseguire il multiplexing o il pooling delle connessioni oppure per diminuire il numero di dispositivi o utenti che accede al software o lo usa non riduce il numero di licenze necessarie. Il licenziatario potrà utilizzare tale hardware o software solo nel caso in cui disponga di una licenza per ciascuna istanza del software in uso.

(iii) Connessioni dei dispositivi. Il licenziatario potrà consentire a un massimo di 20 ulteriori dispositivi di accedere al software installato sul dispositivo con licenza per utilizzare le seguenti funzionalità software: servizi file, servizi stampa, servizi di informazioni Internet, Condivisione connessione Internet e servizi di telefonia sul dispositivo con licenza. Il licenziatario potrà consentire a un numero qualsiasi di dispositivi di accedere al software sul dispositivo con licenza per sincronizzare i dati tra i dispositivi. Il presente Articolo non indica, tuttavia, che il licenziatario abbia il diritto di installare il software o di utilizzare la funzione principale del software (diversa dalle funzionalità ivi elencate) su uno qualsiasi di questi altri dispositivi.

(v) Accesso remoto. Non più di una volta ogni 90 giorni, il licenziatario potrà designare un singolo utente che utilizzerà fisicamente il dispositivo con licenza quale utente autorizzato. L’utente autorizzato potrà accedere al dispositivo con licenza da un altro dispositivo tramite le tecnologie di accesso remoto. Altri utenti, in momenti diversi, potranno accedere al dispositivo con licenza da un altro dispositivo tramite le tecnologie di accesso remoto, ma solo su dispositivi dotati di una licenza specifica per eseguire un’edizione identica o superiore di questo software.

(vi) Assistenza remota. Il licenziatario potrà utilizzare le tecnologie di assistenza remota per condividere una sessione attiva senza dover ottenere ulteriori licenze per il software. Assistenza remota consente a un utente di connettersi direttamente al computer di un altro utente, in genere per correggere eventuali problemi.”

Inoltre occorre tenere in considerazione anche le seguenti restrizioni riportate nel punto 2 lettera c dell’EULA:

“(i) utilizzare o virtualizzare alcune funzionalità del software separatamente;

(iv) aggirare le restrizioni o le limitazioni tecniche presenti nel software;

(v) utilizzare il software come software server, per l’hosting di servizi commerciali, renderlo disponibile per l’uso simultaneo da parte di più utenti su una rete, installarlo su un server e consentire agli utenti di accedervi da remoto o installarlo su un dispositivo per l’utilizzo solo da parte di utenti remoti;”

Conclusioni

Concludendo possiamo riassumere che in ambiente Windows Server è necessaria una RDS CAL ogni volta che si utilizza una qualunque funzionalità dei Remote Desktop Services (indipendentemente dal fatto che si implementi o meno un ambiente multiutente) o si se si fa uso di una qualunque tecnologia che permette l’interazione con la GUI.

Mentre per quanto riguarda Windows 10 solo l’utente a cui è stata assegnata la licenza può accedere al dispositivo da un altro dispositivo tramite le tecnologie di accesso remoto, mentre altri utenti, in momenti diversi, potranno accedere al dispositivo da altri dispositivi tramite le tecnologie di accesso remoto solo se tali dispositivi sono dotati di una licenza specifica per eseguire un’edizione identica o superiore a quella del dispositivo a cui si connettono.

Riferimenti

• Microsoft License Terms
• Windows Server2019 Datacenter and Standard EULA Italian.htm
• Windows 10 EULA Italian
• Licensing Windows Server Remote Desktop Services and Microsoft desktop applications for use with RDS

Qualche settimana fa è stata rilasciata nel Windows Store una preview di Windows Terminal, una nuova App frutto di un altro progetto Open Source di Microsoft, tramite cui è possibile utilizzare e gestire tutte le interfacce a riga di comando esistenti con ottime performance ed in maniera molto intuitiva.

Una delle caratteristiche principali è la possibilità di utilizzare più Tab, ed in ognuno di essi avviare delle sessioni PowerShell, WSL o cmd.

Windows Terminal non è quindi una nuova shell, ma una interfaccia da cui è possibile utilizzare delle sessioni di shell diverse. Non sostituirà, quindi, la console tradizionale, ma la affiancherà migliorandone l’usabilità. Windows Terminal può infatti utilizzare il rendering di testo offerto dalla propria GPU attraverso i driver DirectWrite/DirectX se supportati, in modo da integrare qualsiasi carattere grafico, emoji, ideogramma o simbolo particolare. È inoltre possibile utilizzare una enorme quantità di font (non sono però ancora disponibili per il download) e colori, aspetto sicuramente apprezzato da chi scrive codice o script ed ha necessità di personalizzarne la visualizzazione.

Il progetto è ovviamente appena partito e si prevedono già molte integrazioni future, e sicuramente la scelta di aver reso il codice disponibile a tutti sarà un’ottima strategia per ottenere velocemente il contributo tutte le community di settore.

Per tutti gli interessati questa https://github.com/microsoft/terminal è la pagina del progetto, e tutti sono chiamati a collaborare.

A noi non rimane altro che provarla, ricordando che è possibile farlo solo a partire da Windows 10 build 18362 (cioè Windows 10 versione 1903). Dal Windows Store cerchiamo Windows Terminal

Figura 1: Download dell’app Windows Terminal dal Windows Store

Clicchiamo su Get (Ottieni) ad attendiamo il download di circa 5MB.

Avviamo quindi l’App cliccando su Launch (Avvia)

Figura 2: Lancio dell’applivazione Windows Terminal

Il nostro nuovo Windows Terminal è pronto, vediamo subito che è possibile avviare le nostre shell di diverso tipo utilizzando tab diversi.

Figura 3: Avvio di shell diverse utilizzando i tab dell’applicazione

La modifica delle impostazioni non è proprio immediata, notiamo infatti che cliccando su settings viene aperto con notepad un file JSON, non proprio user friendly

Figura 4: Modifica delle impostazioni dell’applicazione Windows Terminal

Notiamo inoltre una non perfetta gestione dell’High DPI Scaling, infatti utilizzando un monitor 4K i titoli delle tab, e soprattutto l’icona per chiuderle, vengono nascosti dal tasto + e la gestione di più tab è un po’ scomoda.

Tuttavia nel video presentato da Kevin Gallo durante la keynote di Rajesh Jha durante la Microsoft Build Conference 2019 a Seattle è visibile quello che probabilmente è la direzione verso cui il team di sviluppo sta lavorando: un terminale molto accattivante con effetti 3D, trasparenza, colori ed hyperlink integrati.

Figura 5: Utilizzo di PowerShell in Windows Terminal

Figura 6: Utilizzo di Bash in Windows Terminal

Figura 7: Utilizzo del Command Prompt (cmd) in Windows Terminal

Siamo sicuramente contenti dell’integrazione di un terminale “universale” all’interno del nostro Windows 10, ovviamente trattandosi di una Preview non ci aspettiamo la perfezione, ma siamo convinti che questo strumento potrebbe far parte del set di ogni sistemista o sviluppatore.

Rimaniamo quindi in attesa di novità su questo fronte; il primo rilascio della versione stabile è previsto per la fine del 2019.

Il Failover Cluster è un gruppo di computer che interagiscono tra di loro per migliorare la disponibilità e la scalabilità dei ruoli cluster. Se in uno o più nodi del cluster si verifica un errore, il servizio verrà garantito dagli altri nodi (processo di failover). I ruoli cluster, inoltre, vengono monitorati in modo proattivo per verificare che funzionino correttamente. Se non funzionano, vengono riavviati o spostati in un altro nodo.

Novità del clustering di failover in Windows Server 2019

• Set di cluster – Consentono di aumentare il numero di server oltre i limiti correnti di un cluster. Questa operazione viene eseguita mediante il raggruppamento di più cluster in un set di cluster. Maggiori papprofondimenti sono disponibili leggendo il mio articolo Introduzione ai Cluster Sets in Windows Server 2019
• Azure-aware cluster – I cluster di failover rileva ora automaticamente quando è in esecuzione nelle macchine virtuali IaaS di Azure e ottimizza la configurazione per garantire il failover proattivo e la registrazione degli eventi di manutenzione pianificata di Azure per ottenere i massimi livelli di disponibilità.
• Migrazione del cluster tra domini (cross-domain)– I cluster di failover si possono ora spostare in modo dinamico da un dominio di Active Directory ad un altro, semplificando il consolidamento dei domini.
• USB witness – È ora possibile usare un semplice dispositivo USB collegato a uno switch di rete come witness nella determinazione del quorum per un cluster.
• Miglioramenti all’infrastruttura di cluster – La cache CSV è ora abilitata per impostazione predefinita per migliorare le prestazioni delle macchine virtuali.
• Cluster Aware Updating supporta Storage Spaces Direct – Cluster Aware Updating (CAU) è ora integrato e compatibile con Storage Spaces Direct e convalida e garantisce il completamento della risincronizzazione dei dati su ciascun nodo. In più controlla gli aggiornamenti solo se necessario e riavvia i nodi in modo intelligente. In questo modo orchestra i riavvii di tutti i server del cluster per la manutenzione pianificata.
• Cluster hardening – Le comunicazioni interne a un cluster tramite Server Message Block (SMB) per Cluster Shared Volumes e Storage Spaces Direct ora sfruttano i certificati per rendere la piattaforma più sicura. In questo modo i cluster di failover possono funzionare senza dipendenze su NTLM e abilitare le baseline di sicurezza.
• Eliminazione dell’autenticazione NTLM – Il cluster di failover non utilizza più l’autenticazione NTLM, ma usa in maniera esclusiva l’autenticazione Kerberos e l’autenticazione basata su certificati. Non sono necessarie modifiche da parte per sfruttare i vantaggi di questo miglioramento della sicurezza.
  

Schema di funzionamento di un cluster

Per realizzare questa guida ho creato un domain controller (DC1.demo.lab) e due server che verranno poi clusterizzati (FS1.demo.lab e FS2.demo.lab). Ho anche creato una macchina che farà da ISCSI target (ISCSI1.demo.lab) ed ospiterà lo storage condiviso dei due nodi del cluster.

Anche se utilizzerò Windows Server 2019, la stessa procedura è valida se utilizzate Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012.

Nella figura sotto è mostrato lo schema del laboratorio realizzato:

Figura 1: Schema del laboratorio realizzato

Prerequisiti per la creazione di un Failover Cluster

Prima di iniziare a configurare il cluster, verificate i prerequisiti seguenti:

• Assicuratevi che tutti i server da aggiungere come nodi del cluster eseguano la stessa versione di Windows Server.
• Esaminate i requisiti hardware per assicurarvi che la configurazione in uso sia supportata. Per altre informazioni seguite la guida Requisiti hardware per il clustering di failover e opzioni di archiviazione.
• Assicuratevi che tutti inodi del cluster possano accedere ad uno storage condiviso.
• Assicuratevi che tutti i server da aggiungere come nodi del cluster siano aggiunti allo stesso dominio Active Directory.
• Assicuratevi che l’account da usare per la creazione del cluster sia un utente di dominio che dispone di diritti di amministratore su tutti i server da aggiungere come nodi del cluster.

NOTA: Per essere supportato da Microsoft, tutto l’hardware deve essere certificato per la versione di Windows Server in esecuzione e la soluzione completa del cluster di failover deve superare tutti i test della Convalida guidata configurazione. Per altre informazioni sulla convalida del cluster di failover, vedere Convalidare l’hardware per un cluster di failover.

Check-list delle attività da eseguire

La creazione di un Failover Cluster richiede l’esecuzione delle seguenti attività:

• Verificare i prerequisiti
• Installare la funzionalità Clustering di failover in tutti i server da aggiungere come nodi del cluster
• Eseguire la convalida guidata del cluster per la verifica della configurazione
• Eseguire la Creazione guidata cluster per creare il cluster di failover
• Creare ruoli del cluster per ospitare i carichi di lavoro del cluster

Configurazione dello storage condiviso

Ad ogni nodo del cluster deve essere collegato storage condiviso, cioè visibile da tutti i nodi. È possibile presentare lo storage ai diversi nodi tramite ISCSI, SAN Fiber Channel, Shared SAS oppure tramite gli Storage Spaces. Ho già avuto modo di parlarvi degli Storage Spaces nell’articolo Implementare Storage Spaces Direct in Windows Server 2016 con Microsoft Azure e nell’articolo Storage Spaces Tiering in Windows Server 2016

In questa guida mi servirò di un ISCSI Target installato sulla macchina ISCSI1.demo.lab che pubblica due dischi: un disco di quorum da 10 GB e un disco dati da 500GB. La configurazione dell’ISCSI Target esula dai contenuti di questa guida. Per approfondimenti vi rimando alla lettura dell’articolo Configure Windows 2012 R2 as iSCSI target

Sui due nodi del cluster, FS1.demo.lab ed FS2.demo.lab, ho collegato i dischi ISCSI utilizzando l’ISCSI Initiator, come mostrato in figura:

Figura 2: Configurazione dell’ISCSI Initiator sui due nodi del cluster

Dopo aver collegato i dischi tramite l’ISCSI Initiator, ho provveduto sulla macchina FS1.demo.lab ad inizializzare i dischi e a formattarli, come mostrato nelle figure sotto:

Figura 3: Inizializzazione dei dischi ISCSI sulla macchina FS2.demo.lab

Figura 4: Formattazione dei due dischi ISCSI sulla macchina FS1.demo.lab

Poiché si tratta di dischi ISCSI, sulla macchina FS2.demo.lab i due dischi risulteranno formattati ma saranno visti offline. Windows infatti non supporta la clusterizzazione dei dischi NTFS. Provvederemo più tardi ad utilizzare la funzionalità di Cluster Shared Volume per permettere ad entrambi i nodi di poter scrivere contemporaneamente sullo stesso disco.

Configurazione della rete

I due nodi sono collegati tramite due schede di rete: una di management ed una dedicata all’heartbeat. Vi consiglio la lettura dell’articolo Configuring Windows Failover Cluster Networks per approfondire tutti i requisiti di rete necessari per il corretto funzionamento del Cluster.

Installazione e configurazione del Cluster

Per configurare uno Scale-out File Server è necessario che su entrambi i nodi venga installata la funzionalità di File Server e di Failover Clustering. Potete servirvi del Server Manager per installare le funzionalità su entrambi i nodi, oppure potete utilizzare il comando PowerShell

$servers = "fs1.demo.lab", "fs2.demo.lab"
foreach ($server in $servers)
{
    Install-WindowsFeature -computername $server –Name Failover-Clustering –IncludeManagementTools
}

Figura 5: Aggiunta del secondo nodo al Server Manager di FS1.demo.lab per poterlo gestire

Figura 6: Aggiunta della funzionalità di Failover Clustering

Effettuate l’installazione del ruolo di File Server e della funzionalità di Failover Clustering anche sul secondo nodo.

Figura 7: Installazione del ruolo di File Server e della funzionalità di Failover Clustering anche sul secondo nodo

Terminata l’installazione della funzionalità, utilizzate la console del Failover Cluster Manager per testare la configurazione dei due nodi e per creare il nuovo cluster. Vi consiglio di verificare i prerequisiti elencati alla pagina Creare un cluster di failover

Lanciate quindi il wizard per la validazione del cluster, in modo tale da essere sicuri che tutti i prerequisiti siano stati rispettati.

Figura 8: Validazione dei nodi del cluster

Figura 9: Validazione effettuata

In alternativa potete utilizzare il comando PowerShell

Test-Cluster –Node fs1.demo.lab,fs2.demo.lab

Terminata la validazione potete creare il nuovo cluster. Cliccate su Create the cluster now using the validates nodes e seguite il wizard di creazione. Indicate il nome del cluster (nel mio caso CLUSTER1) e l’indirizzo IP da assegnargli, come mostrato nelle figure sotto. Io ho anche scelto di aggiungere al cluster tutti i dischi condivisi che sono stati agganciati ai nodi, utilizzando Add all eligible storage to the cluster.

Figura 10: indicazione del nome e dell’indirizzo IP del cluster

Figura 11: Aggiunta dello storage condiviso da tutti i nodi del cluster

Figura 12: Creazione del cluster completata

La creazione del cluster può essere eseguita anche utilizzando il comando PowerShell

New-Cluster –Name CLUSTER1 –Node fs1.demo.lab,fs2.demo.lab –StaticAddress 10.10.10.69

Verificate la creazione del cluster dalla console del Failover Cluster Manager e verificate che i dischi condivisi siano stati aggiunti. Come si vede dalla figura sotto, il disco da 10GB viene utilizzato per il quorum, mentre quello da 500GB è disponibile per i dati e può essere trasformato in un Cluster Shared Volume (CSV). I CSV permettono a tutti i nodi di un cluster di failover di poter accedere contemporaneamente sia in lettura che in scrittura ad un disco formattato NTFS o ReFS. NTFS ed ReFS non sono infatti file system clusterizzabili. Per approfondimenti vi rimando alla lettura dell’articolo Utilizzare volumi condivisi del Cluster in un cluster di failover

Cliccate col tasto destro sul disco da utilizzare e scegliete la voce Add to Cluster Shared Volume.

Figura 13: Aggiunta del disco condiviso al Cluster Shared Volume

Il processo è praticamente istantaneo e permette di trasformare il disco in un mount point. Adesso tutti i nodi del cluster potranno accedere al disco utilizzando il percorso predefinito C:\ClusterStorage\Volume1 e potranno leggere e scrivere contemporaneamente nello storage condiviso.

Figura 14: il disco è stato trasformato in un Cluster Shared Volume

Verificate anche la configurazione delle schede di rete per controllare che ognuna delle schede sia utilizzata nel modo corretto per il management, lo scambio dati e per l’heartbeat.

Figura 15: Configurazione delle reti del cluster

Il cluster è ora configurato.

A questo punto non vi resta che aggiungere al cluster i ruoli di Windows Server oppure le applicazioni che volete rendere disponibili. I ruoli supportati sono:

• Namespace Server
• DFS Namespace Server
• Distributed Transaction Coordinator (DTC)
• File Server
• Generic Application
• Generic Script
• Generic Service
• Hyper-V Replica Broker
• iSCSI Target Server
• iSNS Server
• Message Queuing
• Other Server
• Virtual Machine
• WINS Server

Conclusioni

La funzionalità di Failover Clustering permette di rendere altamente disponibili le nostre applicazioni o le macchine virtuali e diminuisce drasticamente le interruzioni di servizio (downtime). Già da Windows Server 2012 R2 Microsoft supporta failover cluster fino a 64 nodi fisici ed una scalabilità fino a 8.000 macchine virtuali in esecuzione contemporaneamente. Ogni nodo fisico con Hyper-V è in grado di eseguire fino a 1024 macchine virtuali.

La funzionalità di Shadowing delle sessioni remote è presente da diverso tempo in RDS, sebbene abbia vissuto fasi alterne nel tempo, come è possibile leggere in questo Post di Ermanno Goletto. Per chi non la conoscesse, si tratta della possibilità di accedere, in modalità visualizzazione o controllo, ad una sessione RDP attiva su un session Host.

In una infrastruttura RDS è possibile sfruttare questa funzione per fornire assistenza e supporto agli utenti, interagendo con le loro attività.

Di default è attiva ed è utilizzabile direttamente da Server Manager nel contesto di gestione della Farm RDS, è sufficiente individuare la Collection, ed identificare la sessione a cui connettersi

Server Manager\Remote Desktop Services\Collections\Desktop1

Identificata la sessione, con il dato DX selezionare Shadow

Figura 1 selzione della sessione connessa

Si apre a questo punto una maschera in cui viene richiesto di specificare la modalità di connessione, ossia se in sola visualizzazione o in controllo e quindi in piena interazione con l’utente, è anche possibile specificare se richiedere all’utente il consenso alla connessione.

Figura 2 modalità di connessione

A questo punto proseguendo con OK all’utente connesso viene proposto un messaggio che lo informa della richiesta di accesso

Figura 3 prompt di conferma della richiesta di accesso

Non appena ottenuta la conferma la sessione può essere controllata o visualizzata da remoto

Questo comportamento, come detto prima, è di default e l’accesso è possibile in quanto il permesso di Shadowing sulle connessioni RDP è concesso agli utenti Amministratori.

Gestione dei permessi di Shadowing

Nel caso sia necessario garantire questa funzionalità ad utenti non amministratori è necessario che il permesso venga esplicitato per i vari utenti, direttamente sulla connessione RDP dei singoli Session Host

Per una gestione più semplice è preferibile creare un gruppo all’interno di AD ed assegnare il permesso di Shadowing a questo gruppo, successivamente verranno definiti come membri i vari utenti che dovranno operare in modalità Shadow sulle sessioni RDS

La modifica dei permessi di default avviene con un comando che opera direttamente tramite WMI sulle proprietà della connessione RDP dei Session Host. Tramite GPO invece è possibile modificare la modalità di accesso alle sessioni RDS.

Impostazioni tramite Wmic (WMI)

Supponendo di aver creato sul dominio ICTPOWER il gruppo UtentiRdsShadowing il comando per assegnarne i permessi è il seguente

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName=”RDP-Tcp”) CALL AddAccount “ictpower\UtentiRdsShadowing”,2

più in dettaglio vediamo che viene identificato il nome della connessione RDP con TerminalName RDP-Tcp e con AddAccount viene definito il gruppo ictpower\UtentiRdsShadowing il parametro al termine del comando prevede 3 valori:

• 0 = WINSTATION_GUEST_ACCESS
• 1 = WINSTATION_USER_ACCESS
• 2 = WINSTATION_ALL_ACCESS

Per verificare le impostazioni correnti è possibile utilizzare il comando

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting

il cui output sarà simile a questo

Caption DenyAdminPermissionForCustomization Description InstallDate Name PolicySourceDenyAdminPermissionForCustomization Status StringSecurityDescriptor TerminalName

O:SYG:SYD:(A;;CC;;;IU)(A;;0xf03bf;;;SY)(A;;CCSWLOSDRCWDWO;;;LS)(A;;CCLO;;;NS)(A;;0xf03bf;;;BA)(A;;CCWPCR;;;RD)S:NO_ACCESS_CONTROL Console

O:SYG:SYD:(A;;0xf03bf;;;S-1-5-21-263436683-1377918197-1349984968-1110)(A;;CC;;;IU)(A;;0xf03bf;;;SY)(A;;CCSWLOSDRCWDWO;;;LS)(A;;CCLO;;;NS)(A;;0xf03bf;;;BA)(A;;CCWPCR;;;RD)S:(AU;FA;CCWPCR;;;WD) RDP-Tcp

In grassetto nell’ultima riga è riportato il SID del gruppo ictpower\UtentiRdsShadowing, per poter risalire al nome del gruppo dato il SID il comando è sufficiente utilizzare il Cmd-Let

Get-ADGroup -Identity S-1-5-21-263436683-1377918197-1349984968-1110

Se fosse necessario ricondurre le impostazioni ad un valore di default è possibile utilizzare il comando seguente

wmic /namespace:\\root\CIMV2\TerminalServices PATH WIN32_TSPermissionsSetting WHERE (TerminalName="RDP-Tcp") CALL RestoreDefaults

dopo la variazione dei permessi di accesso tramite il comando VMIC è necessario riavviare il servizio RDS con il comando

net stop "Remote Desktop Services" && net start "Remote Desktop Services"

Impostazioni tramite Group Policy (GPO)

Le impostazioni per mezzo delle GPO definiscono la modalità con cui gli utenti che richiedono di effettuare lo shadow potranno accedere alla Sessione

La Group Policy è configurabile in Computer/Policies/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connection

Figura 4 impostazione delle modalità di shadowing

Si può definire l’accesso in controllo completo con o senza autorizzazione utente, l’accesso in sola modalità visualizzazione con o senza autorizzazione esplicita dell’utente ed una ulteriore impostazione che nega qualunque tipo di accesso allo shadow delle sessioni, chiaramente questa configurazione è indipendente dai permessi di accesso impostati con WMIC che devono comunque essere dichiarati.

La Group Policy vista in figura 4 è configurabile a livello Macchina e quindi per qualunque utente che ha una connessione sul Session Host, nel caso fosse necessario definire regole diverse di controllo delle sessioni RDS in base agli utenti collegati, è possibile attivare una Group Policy nel contesto utente e come tale applicata solamente a determinati account.

La Group Policy è configurabile in User/Policies/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connection

Figura 5 impostazioni modalità di shadowing nel contesto utente

La GPO deve essere assegnata alla OU dove risiede l’utente che deve essere controllato e non all’utente che effettua il controllo sulla sessione RDS, per il resto le impostazioni sono identiche a quelle viste per il contesto macchina.

Utilizzo di Script in Powershell e del client RDS per la gestione delle attività di Shadowing

Fino a questo punto abbiamo visto le impostazioni dell’ambiente RDS e la modalità di accesso allo Shadowing avviene a partire dal Server Manager e dalle funzioni disponibili nella sua interfaccia.

Essendo a conoscenza dell’Id della sessione RDS su un determinato Session Host, è possibile eseguire il client RDP in modo che effettui il mirroring della sessione voluta.

Supponendo di eseguire l’accesso alla sessione 10 sul server RDSH01 in modalità di controllo, dovremo eseguire il comando MSTSC con le impostazioni seguenti:

Mstsc.exe /v: /shadow:10 /control

Nel caso in cui non sia necessario eseguire il controllo ma solo la visualizzazione della sessione è sufficiente omettere l’opzione /control

L’individuazione dell’id della sessione non è propriamente immediato, soprattutto nel caso in cui l’accesso alla Farm RDS avviene con un unico utente comune a più connessioni, l’elenco all’interno del Server Manager presenta in questo caso molteplici connessioni tutte originate dal medesimo utente.

E’ necessario quindi individuare l’ID della sessione direttamente dall’interno della stessa eseguendo il command-let Get-Process

(Get-Process -PID $pid).SessionID

Ottenuto il valore numerico relativo alla sessione, è possibile effettuarne il mirroring come visto sopra.

Scenario di utilizzo delle funzioni di Shadow

in ambienti distribuiti, con operatori che svolgono la funzione di assistenza nei confronti degli utenti della farm RDS è importante permettere che da un lato l’operatore che richiede supporto possa indicare in modo preciso le informazioni sulla propria connessione, e dall’altro il personale addetto al supporto possa accedere in visualizzazione o controllo della sessione senza possibilità di errori.

Qui di seguito sono riportati due script in PowerShell che permettono in modo semplice l’individuazione delle informazioni sulla sessione connessa alla Farm RDS, e la creazione guidata di una sessione di accesso in mirror o controllo della sessione stessa, chiaramente il primo script dovrà essere eseguito all’interno della sessione, ed il secondo script dovrà essere eseguito da una qualunque postazione di rete con le credenziali di un utente che dispone dei permessi di accesso in Shadow come visto in precedenza.

Per fare si che ogni utente che accede alla farm RDS abbia disponibile sul desktop il collegamento allo script di identificazione della sessione è possibile usare le Group Policy.

Identificazione della sessione RDS

#### Script per identificare (dato un desktop in RDS) il client da cui viene avviata la  sessione, il server Session Host su cui si è collegati,e l'identificativo di Sessione
# dichiarazione Variabili e recupero info di sessione
$TsSessionID = (Get-Process -PID $pid).SessionID
$TsServerName = $env:COMPUTERNAME
$TsClientName = $env:CLIENTNAME

## Creazione della stringa messaggio inserita nel Pop-Up Utente

$InfoSessioneTS = "Nome Client:  " + $TsClientName   + "`r`n"  +  "Nome Server:  " + $TsServerName   +   "`r`n" +  "Identificativo Sessione RDS ID:   " +$TsSessionID
Write-Host $InfoSessioneTS

###
Add-Type -AssemblyName System.Windows.Forms

# Costruzione della Msg-Box 
function Read-MessageBoxDialog([string]$Message, [string]$WindowTitle, [System.Windows.Forms.MessageBoxButtons]$Buttons = [System.Windows.Forms.MessageBoxButtons]::OK, [System.Windows.Forms.MessageBoxIcon]$Icon = [System.Windows.Forms.MessageBoxIcon]::None)
{
       return [System.Windows.Forms.MessageBox]::Show($Message, $WindowTitle, $Buttons, $Icon)
}

$buttonClicked = Read-MessageBoxDialog -Message $InfoSessioneTS   -WindowTitle "IctPower " -Buttons OK -Icon Information

Una volta eseguito questo script costruisce una MsgBox con riassunte le informazioni utili ad identificare la sessione

Figura 6 informazioni di sessione

Lo script sarà avviato direttamente da un file .cmd opportunamente strutturato e nel caso si voglia utilizzare una GPO per la pubblicazione del link sul desktop, questa dovrà riferirsi al file di avvio

start /min C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\supporto\IdentificaSessione.ps1

Gestione guidata del di Mirror della sessione RDS

Individuata la sessione all’interno della Farm RDS è possibile utilizzare questo script per creare l’accesso in Shadow alla sessione stessa, lo script è più complesso nella sua costruzione ma non fa altro che creare una check-box per ogni Session-Host presente, consentire l’immissione del valore dell’ID sessione ed un ulteriore check-box relativo alla funzione di controllo o semplice visualizzazione della sessione, ottenute queste impostazioni viene strutturato ed eseguito il comando MSTSC come visto sopra.

######   Script per l'avvio di una sessione Shadow su RDSSession Host 
######   Per ogni Controllo  System.Drawing.Point(x,y) per posizionamento nel Form (1,1) in alto a sx
######   Per ogni Session Host è necessario definire il comando VMIC di concessione della sessione Shadow al Gruppo/utenti 

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

# Creazione del Form generale
$form = New-Object System.Windows.Forms.Form
$form.Text = 'ICTPower'
$form.Size = New-Object System.Drawing.Size(500,300)
$form.StartPosition = 'CenterScreen'

# Creazione del Tasto Ok
$OKButton = New-Object System.Windows.Forms.Button
$OKButton.Location = New-Object System.Drawing.Point(150,220)
$OKButton.Size = New-Object System.Drawing.Size(75,23)
$OKButton.Text = 'OK'
$OKButton.DialogResult = [System.Windows.Forms.DialogResult]::OK
$form.AcceptButton = $OKButton
$form.Controls.Add($OKButton)

# Creazione del Tasto Cancel
$CancelButton = New-Object System.Windows.Forms.Button
$CancelButton.Location = New-Object System.Drawing.Point(300,220)
$CancelButton.Size = New-Object System.Drawing.Size(75,23)
$CancelButton.Text = 'Cancel'
$CancelButton.DialogResult = [System.Windows.Forms.DialogResult]::Cancel
$form.CancelButton = $CancelButton
$form.Controls.Add($CancelButton)

# Definizione di una Etichetta di Commento Generale
$TestoForm = New-Object System.Windows.Forms.Label
$TestoForm.Location = New-Object System.Drawing.Point(10,20)
$TestoForm.Size = New-Object System.Drawing.Size(280,20)
$TestoForm.Text = 'Inserire le Informazioni sulla Sessione Remota:'
$form.Controls.Add($TestoForm)



##### Costruzione Area Inserimento ID Sessione
##### Etichetta e Textbox    
$TestoRDSId = New-Object System.Windows.Forms.Label
$TestoRDSId.Location = New-Object System.Drawing.Point(10,40)
$TestoRDSId.Size = New-Object System.Drawing.Size(130,20)
$TestoRDSId.Text = 'Id Sessione RDS:'
$Form.Controls.Add($TestoRDSId)

$TsSessionID = New-Object System.Windows.Forms.TextBox
$TsSessionID.Location = New-Object System.Drawing.Point(150,40)
$TsSessionID.Size = New-Object System.Drawing.Size(40,20)
$form.Controls.Add($TsSessionID)


##### Costruzione Area Inserimento checkbox Monitoraggio/Controllo
#Checkbox Controllo
$CheckboxTsSessionControl = New-Object System.Windows.Forms.CheckBox
$CheckboxTsSessionControl.Location = New-Object System.Drawing.Point(250,40)
$CheckboxTsSessionControl.Size = New-Object System.Drawing.Size(210,30)
$CheckboxTsSessionControl.Text = "Selezionare per Controllo Sessione - Default solo Visualizzazione"
$form.Controls.Add($CheckboxTsSessionControl)


#### Costruzione Area Inserimento CheckBox di definizione dei SessionHost

#Checkbox RdSh01
 $Checkboxrdsh01 = New-Object System.Windows.Forms.Checkbox 
 $Checkboxrdsh01.Location = New-Object System.Drawing.Point(150,80) 
 $Checkboxrdsh01.Size = New-Object System.Drawing.Size(300,20)
 $Checkboxrdsh01.Text = "RDSH01"
 $Form.Controls.Add($Checkboxrdsh01)

 
 #Checkbox RdSh02
 $CheckboxRdsh02 = New-Object System.Windows.Forms.Checkbox 
 $CheckboxRdsh02.Location = New-Object System.Drawing.Point(150,110) 
 $CheckboxRdsh02.Size = New-Object System.Drawing.Size(300,20)
 $CheckboxRdsh02.Text = "RDSH02"
 $Form.Controls.Add($CheckboxRdsh02)

 #Checkbox RdSh03
 $CheckboxRdsh03 = New-Object System.Windows.Forms.Checkbox 
 $CheckboxRdsh03.Location = New-Object System.Drawing.Point(150,140) 
 $CheckboxRdsh03.Size = New-Object System.Drawing.Size(300,20)
 $CheckboxRdsh03.Text = "RDSH03"
 $Form.Controls.Add($CheckboxRdsh03)

 
 #Checkbox RdSh04
 $CheckboxRdsh04 = New-Object System.Windows.Forms.Checkbox 
 $CheckboxRdsh04.Location = New-Object System.Drawing.Point(150,170) 
 $CheckboxRdsh04.Size = New-Object System.Drawing.Size(300,20)
 $CheckboxRdsh04.Text = "RDSH04"
 $Form.Controls.Add($CheckboxRdsh04)


## Carico il Form
$form.Add_Shown({$TestoForm.Select()})
$result = $form.ShowDialog()
$form.Topmost = $true


### Attribuzione Switch di controllo alla stringa di Connessione
if ( $CheckboxTsSessionControl.Checked){

    $TsSessionControl = "/Control"
       }


# Avvio di MSTSC sulla base degli input definiti
$RDSId = $TsSessionID.Text
if (($result -eq [System.Windows.Forms.DialogResult]::OK) -and 
   (($Checkboxrdsh01.Checked) -or 
   ($CheckboxRdsh02.Checked)-or 
   ($CheckboxRdsh03.Checked) -or 
   ($CheckboxRdsh04.Checked))) {
   
   if ($Checkboxrdsh01.Checked)   {
        $RdsHost = "rdsh01.ictpower.local"
        Write-Host $RdsHost
   }
    elseif ($CheckboxRdsh02.Checked)   {
        $RdsHost = "rdsh02.ictpower.local"
        Write-Host $RdsHost
   }
    elseif ($CheckboxRdsh03.Checked)   {
        $RdsHost = "rdsh03.ictpower.local"
        Write-Host $RdsHost
   }
    elseif ($CheckboxRdsh04.Checked)   {
        $RdsHost = "rdsh04.ictpower.local"
        Write-Host $RdsHost
   }
  
    Mstsc.exe /v:$RdsHost  /shadow:$RDSId  $TsSessionControl
    
}

Figura 7

La figura qui sopra riporta il form che viene creato per mezzo di questo script, premendo ok in questo caso si effettua il mirror della sessione numero 5 sul Session Host RDSH01

Considerazioni

Le soluzioni proposte in questo articolo prendono spunto da un caso reale dove si è reso necessario permettere ad un gruppo di utenti di accedere in modalità di consultazione o controllo al fine di fornire assistenza agli utilizzatori su un certo numero di applicativi distribuiti da una Farm RDS, la scelta di implementazione della soluzione ha previsto l’impiego di pochi utenti di accesso comuni a numerosi utenti singoli, e demandando la successiva autenticazione a livello applicativo. Questa modalità ha evidenziato le problematiche esposte sopra relative all’identificazione delle singole Sessioni.

Dal 21 maggio 2019 tutti possono scaricare Windows 10, versione 1903 che finalmente è stata rilasciata al pubblico dopo che era stata rilasciata il 18 Aprile ai sottoscrittori MSDN.

Da tutti i partecipanti al programma Windows Insider questa versione era conosciuta come 19H1. Il nome ufficiale che è stato scelto è invece May 2019 Update e la build rilasciata è la 18362, che porta diverse novità interessanti.

Figura 1: build rilasciata di Windows 10, versione 1903

Le novità introdotte in questa versione di Windows 10 sono:

• Windows Sandbox (una delle novità più interessanti)
• Windows Defender Application Guard migliorato
• Windows Defender Application Control (WDAC) migliorato
• Reserved Storage (OEM e installazioni pulite)
• Miglioramenti nella protezione dell’Identità
• Miglioramenti nella Console e WSL
• Miglioramenti per la Sicurezza del sistema
• Miglioramenti nel pannello Impostazioni di Windows
• Miglioramenti nell’interfaccia del sistema
• Possibilità di rimuovere alcune applicazioni pre-installate
• Windows Update ridisegnato e semplificato
• Impostazioni privacy per il microfono
• Cortana separato dalla Ricerca

Tema Chiaro e nuovo sfondo

Tra le novità più evidenti vi segnalo un Tema chiaro (Light Theme), richiesto a gran voce dai feedback raccolti e uno nuovo sfondo ufficiale del sistema operativo, che ha ora un taglio essenziale e decisamente più moderno. Il menu Start è stato alleggerito e ci sono meno icone che ne semplificano l’utilizzo.

Figura 2: Tema light e nuovo sfondo per Windows 10, versione 1903

Clipboard History

È stata aggiunta una nuova esperienza per gli appunti (clipboard) che deve essere precedentemente abilitata dall’app Settings e che permette di mantenere una cronologia di ciò che avete copiato precedentemente negli appunti. Abilitando la Clipboard History potrete utilizzare la combinazione di tasti Win+V per far apparire uno snippet che vi mostrerà la cronologia degli appunti che potrete incollare.

Figura 3: Clipboard History in Windows 10, versione 1903

Mirroring degli smartphone Android

Dalla build 18356 di Windows 10 19H1 (Fast Ring) era apparsa agli Insider la possibilità di eseguire le applicazioni Android sul PC grazie ad una nuova funzionalità dell’applicazione Il tuo telefono e che permette di effettuare il mirroring del proprio smartphone Android. La funzionalità ha subito destato il mio interesse perché spesso durante le mie lezioni duplico lo schermo del mio smartphone per mostrare le app di gestione di Microsoft 365 oppure per mostrare le app di Multi-Factor Authentication. L’applicazione di fatto permette di controllare in maniera completa il proprio smartphone Android dal PC con Windows 10, solo che al momento della stesura di questo articolo è limitata solo a pochi modelli di smartphone con Android 7.0 o superiore:

• Samsung Galaxy S8
• Samsung Galaxy S8+
• Samsung Galaxy S9
• Samsung Galaxy S9+
• Samsung Galaxy S10
• Samsung Galaxy S10+
• Samsung Galaxy S10e
• Samsung Galaxy Note 8
• Samsung Galaxy Note 9
• OnePlus 6
• OnePlus 6T

Trovate la lista aggiornata alla pagina https://answers.microsoft.com/en-us/insider/forum/insider_apps-insider_other-insiderplat_pc/phone-screen-supported-devices/18794409-3e4a-40eb-a6b1-7d06a16b956e

Per poter collegare il telefono al proprio PC è necessario andare in Settings e scegliere Phone (in italiano Il tuo telefono).

Collegate il vostro smartphone cliccando su Add a phone e installate l’app Microsoft Launcher dal Play Store. Per collegare tra di loro i diversi dispositivi vi verrà chiesto di utilizzare un Microsoft Account. Se non avete mai collegato il vostro account Microsoft al vostro PC Windows 10 vi verrà chiesto di loggarvi. Cliccate sul pulsante Sign in with Microsoft.

Seguite la procedura per collegare il vostro Microsoft Account

Figura 4: Collegamento del Microsoft Account al proprio PC

Il Microsoft Account vi permette di poter ricevere la posta sul vostro PC Windows 10 oppure di sincronizzare la vostra rubrica e le vostre impostazioni. Ritornate alla pagina Home della vostra App Settings e cliccate nuovamente sul pulsante Phone. Cliccate sul pulsante “Add a phone” ed inserite il vostro numero di cellulare. Riceverete un SMS con un link che vi permetterà di scaricare l’App per lo smartphone che vi permetterà di collegarlo al vostro PC Windows 10.

Figura 5: Collegamento dello smartphone al proprio PC

Controllate quindi il vostro smartphone e verificate di aver ricevuto l’SMS con il link per scaricare l’App. Cliccate sul link e scaricate ed installate l’App Microsoft Launcher

Figura 6: Installazione dell’app Microsoft Launcher sul proprio smartphone

Installate e lanciate l’App Microsoft Launcher. Vi verrà chiesto di inserire le credenziali del vostro Microsoft Account. Seguite la procedura e al termine vedrete che il vostro smartphone sarà stato aggiunto al PC.

Per poter utilizzare lo Screen Mirroring è necessario che sia lo smartphone che il PC siano collegati tramite bluetooth e che il dispositivo bluetooth installato nel PC supporti la funzionalità “Bluetooth radio supports Low Energy Peripheral Role”

Per verificarlo potete utilizzare Gestione periferiche, selezionare il dispositivo Bluetooth e aprirne le Proprietà. Dalla Scheda Dettagli verificate che Bluetooth radio supports Low Energy Peripheral Role sia true.

Figura 7: Il dispositivo bluetooth deve supportare la funzionalità “Bluetooth radio supports Low Energy Peripheral Role”

Purtroppo, non ho potuto ancora testare personalmente la funzionalità, ma vi lascio qui sotto un video che ve la mostra:

Windows Sandbox

Si tratta di una funzionalità che permette di eseguire Windows 10 in un ambiente protetto all’interno del quale poter testare ed eseguire software che riteniamo non sicuro, senza il rischio che possa creare danni al nostro sistema.

Windows Sandbox è basato sulla tecnologia degli Hyper-V Containers, in cui ogni contenitore viene eseguito all’interno di una speciale macchina virtuale. In questo modo viene offerto un isolamento a livello di kernel tra ogni contenitore di Hyper-V e l’host Windows 10.

In questo ambiente desktop isolato siamo quindi sicuri che l’applicazione girerà in maniera completamente isolata rispetto al sistema operativo host e soprattutto non avremo la necessità di dover creare una macchina virtuale dedicata per questo scopo. Ogni software che verrà installato in Windows Sandbox rimarrà nella sandbox. Una volta che Windows Sandbox verrà chiuso, tutto il software installato e tutti i file creati verranno automaticamente cancellati.

Le caratteristiche principali di Windows Sandbox sono:

• È parte del sistema operativo: Tutto ciò che è necessario per far funzionare Windows Sandbox è incluso in Windows 10 Pro e Enterprise. Non c’è bisogno di scaricare o di creare un virtual disk (VHD)
• Installazione sempre pulita: Tutte le volte che Windows Sandbox viene eseguito è pulito come se fosse una nuova installazione di Windows.
• Usa e getta: Nulla resta sul dispositivo, tutto verrà cancellato una volta chiusa l’applicazione Windows Sandobx.
• Sicuro: Usa la virtualizzazione hardware-based per isolare il kernel, che si affida a Microsoft Hyper-V per eseguire un kernel separato che isola Windows Sandbox dal sistema operativo.

Windows Sandbox occupa solo 25MB e al momento dell’installazione occuperà circa 100MB. Si tratta infatti di un’immagine generata dinamicamente e che verrà utilizzata per creare un Hyper-V Container molto leggero. Utilizzerà infatti i file presenti all’interno del sistema operativo host Windows 10 per potersi generare, come mostrato nella figura sotto:

Figura 8: Principio di funzionamento dell’immagine di WIndows Sandbox

Prerequisiti per l’utilizzo della funzionalità Windows Sandbox

Per poter utilizzare questa nuova funzionalità è necessario che vengano rispettati i seguenti prerequisiti:

• Windows 10 Pro oppure Enterprise
• Architettura a 64bit
• Virtualization capabilities abilitate nel BIOS
• Almeno 4GB of RAM (8GB raccomandati)
• Almeno 1 GB di spazio disco libero (disco SSD raccomandato)
• Almeno 2 core (4 cores con hyperthreading raccomandati)

Se volete utilizzare questa funzionalità all’interno di una macchina virtuale, poiché verrà utilizzato Hyper-V, sarà necessario abilitare la virtualizzazione annidata (nested virtualization) nella VM. A macchina spenta, eseguite il seguente comando nell’host Hyper-V fisico:

Set-VMProcessor -VMName <Nome della VM> -ExposeVirtualizationExtensions $true

In questo modo viene abilitata la virtualizzazione nidificata per la macchina virtuale.

Per abilitare la funzionalità è sufficiente andare in Settings > Apps > Programs and Features > Turn Windows Features on or off, quindi selezionare Windows Sandbox come mostrato in figura:

Figura 9: Abilitazione della funzionalità Windows Sandbox

Il sistema di riavvierà un paio di volte, per permettere l’installazione della funzionalità.

Terminata l’installazione basterà cercare Windows Sandbox nel menu Start per poter avviare la sandbox.

Figura 10: Windows Sandbox in esecuzione

Per testare applicazioni o eseguire file sospetti vi basterà effettuare un copia-incolla per copiare l’eseguibile dall’host all’interno della Sandbox e poi testarlo, oppure potrete scaricarlo direttamente da Internet. La Windows Sandbox infatti naviga in Internet tramite una rete NAT grazie al Default Virtual Switch che viene installato in Windows 10.

Chiudendo la Windows Sandbox annullerete tutte le modifiche fatte. Un messaggio vi avvertirà che perderete tutti i dati.

Figura 11:Messaggio di avviso di perdita dati alla chiusura di Windows Sandbox

Miglioramenti nella protezione dell’identità

In Windows 10, versione 1903 è stato migliorato il supporto per la passwordless FIDO authentication tramite Windows Hello oppure tramite FIDO security Key che supportano gli standard FIDO2 (Fast IDentity Online) e CTAP2 (Client-to-Authenticator Protocol) in Microsoft Edge e nelle versioni più recenti di Mozilla Firefox. Trovate l’annuncio ufficiale alla pagina https://fidoalliance.org/microsoft-achieves-fido2-certification-for-windows-hello/

Accedere senza password è una delle funzionalità che ultimamente Microsoft sta promuovendo maggiormente e i dispositivi biometrici, ormai diffusi in tutti i computer portatili, possono essere utilizzati per accedere a Windows e alle applicazioni web. Per approfondimenti sull’uso del protocollo WebAuthn per l’autenticazione delle applicazioni web vi rimando alla lettura del documento https://www.w3.org/2018/Talks/06-WebAuthn.pdf

Per configurare Windows Hello con un lettore di impronte digitali e fare in modo che l’accesso al Microsoft Account avvenga senza inserire la password vi rimando alla lettura dell’articolo Utilizzare Windows Hello in Windows 10 per accedere al Microsoft Account con WebAuthn, mentre se volete farlo tramite una Security Key (nel mio caso una Yubikey 5 Nano) vi rimando alla lettura dell’articolo Passwordless login al Microsoft Account con Yubikey

Figura 12: Accesso al Microsoft Account utilizzando la webauth in Mozilla Firefox

Figura 13: Richiesta di autenticazione tramite impronta digitale oppure tramite Security Key

Reserved Storage

In questa release di Windows 10 sono state introdotte delle migliorie sulla gestione dello spazio del disco. Attraverso Reserved Storage parte dello spazio del disco verrà messo da parte in modo tale da poter essere utilizzato per gli aggiornamenti, per le applicazioni, per i file temporanei e per la cache di sistema. L’obiettivo è migliorare la funzionalità quotidiana del PC assicurando che le funzioni critiche del sistema operativo abbiano sempre accesso allo spazio su disco.

Se effettuate un’installazione pulita di Windows 10, versione 1903 Reserved Storage verrà abilitato di default e non sarà necessario effettuare alcuna operazione aggiuntiva. Se invece effettuate un aggiornamento al momento l’opzione non è disponibile.

Inizialmente lo spazio riservato è di 7GB, ma verrà dinamicamente aumentato man mano che installerete applicazioni. Reserved Storage non può essere rimosso dal sistema operativo, ma è possibile ridurre la quantità di spazio riservata rimuovendo funzioni (da Settings > Apps > Apps & features > Manage optional feature) e lingue opzionali inutilizzate.

Per verificare lo spazio utilizzato da Reserved Storage potete utilizzare l’app Settings > cercate Storage Settings > cliccate sul link Show more categories > cliccate su System & reserved

Figura 14: Reserved Storage in Windows 10, versione 1903

NOTA: Quando un nuovo aggiornamento sarà disponibile, Windows 10 cancellerà automaticamente i file che si troveranno in Reserved Storage in modo tale da liberare spazio per l’installazione del nuovo aggiornamento.

Windows Update

Nelle precedenti versioni di aggiornamento delle funzionalità di Windows 10 l’installazione degli aggiornamenti veniva avviata automaticamente. A partire dall’aggiornamento di Windows 10 versione 1903 gli utenti avranno più controllo sull’avvio dell’aggiornamento del sistema operativo. Agli utenti verrà mostrata la notifica che un aggiornamento è disponibile e consigliato, ma sarà compito dell’utente iniziare ed effettuare l’aggiornamento.

Mantenere le macchine supportate e ricevere aggiornamenti mensili è fondamentale per la sicurezza dei dispositivi. La nuova gestione di Windows Update permetterà agli utenti maggiore controllo e trasparenza in merito all’installazione degli aggiornamenti e tutti i client avranno la possibilità di scegliere esplicitamente se desiderano aggiornare il proprio dispositivo quando “controllano gli aggiornamenti” oppure potranno mettere in pausa gli aggiornamenti per un massimo di 35 giorni.

Trovate ulteriori notizie alla pagina Improving the Windows 10 update experience with control, quality and transparency

Figura 15: Nuova modalità di gestione di Windows Update

Figura 16: É possibile mettere in pausa gli aggiornamenti fino a 35 giorni

In questo modo, da un lato l’utente potrà continuare a ricevere e verificare la presenza degli aggiornamenti qualitativi mensili e, dall’altro decidere autonomamente quando installare l’aggiornamento di funzionalità. L’aggiornamento forzato entrerà in funzione quando la versione di Windows 10 installata ha terminato il suo ciclo di vita, ovvero dopo 18 mesi dal rilascio ufficiale per le versioni di marzo e 30 mesi per le versioni di settembre per le versioni Enterprise e 18 mesi per tutte le versioni Pro.

Per informazioni sul supporto di Windows 10 vi invito a leggere il documento https://support.microsoft.com/it-it/help/4462896/updates-to-servicing-and-support-for-windows-10

*Gli aggiornamenti delle funzionalità verranno rilasciati due volte all’anno, a marzo e a settembre.

NOTA: A partire da Windows 10, versione 1903 se il dispositivio non si riavverà automaticamente dopo l’installazione, gli aggiornamenti installati verranno rimossi automaticamente e riceverete al riavvio la notifica “We removed some recently installed updates to recover your device from a startup failure”. Il sistema provvederà a disabilitare l’aggiornamento che ha creato problemi per i successivi 30 giorni, sufficienti affinché venga rilasciata una nuova patch.

Windows Security

Diverse novità sono state introdotte anche nell’app Windows Security. Windows Defender Antivirus mantiene il PC al sicuro con la protezione antivirus integrata in Windows 10 e fornisce protezione in tempo reale contro le minacce software, come virus e malware provenienti da e-mail, app e Web.

Windows Defender Security Center è una potente suite di funzionalità di sicurezza ideata per proteggere Windows 10 per tutta la durata del supporto e assicura protezione completa da virus, malware, spyware e altre minacce per il sistema, i file e le attività online. Aprendo il Windows Defender Security Center potrete attivare gratuitamente la protezione e se collegate il vostro dispositivo a OneDrive oppure a OneDrive For Business avrete la possibilità di proteggervi dai Ransomware perché i vostri dati verranno caricati nel Cloud e saranno protetti dal versioning offerto da OneDrive.

Figura 17: Abilitazione di Virus & threat protection in Windows 10

Figura 18: configurazione di OneDrive per la protezione contro i ransomware

Figura 19: Ransomware protection

Ne volete sapere di più? Alla pagina What’s new in Windows 10, version 1903 IT Pro content trovate ulteriori e più dettagliate informazioni sulle novità rilasciate in Windows 10, versione 1903.

Conclusioni

Sono tante le novità inserite in Windows 10, versione 1903 e in questo articolo vi ho citato solo le più importanti. Il lavoro che Microsoft sta facendo per migliorare l’interazione con gli smartphone ed aumentare le funzionalità relative alla sicurezza è davvero notevole.

Da una decina di giorni circa, è possibile abilitare il passwordless sign in anche per gli account di Azure Active Directory, utiizzando una security key che supporta gli standard FIDO2 (Fast IDentity Online) e CTAP2 (Client-to-Authenticator Protocol). Attualmente la funzionalità è in preview, ma già da tempo viene utilizzata per accedere al Microsoft Account, come ho già avuto modo di scrivervi nell’articolo Passwordless login al Microsoft Account con Windows Hello e con Yubikey

La gestione delle password è sempre stata critica sia per gli utenti e che per gli amministratori di sistema e spesso è causa di accessi da parte di malintenzionati per via della scarsa cura che gli utenti ne hanno oppure della semplicità delle password utilizzate.

Accedere senza password (passwordless sign in) è una delle funzionalità che ultimamente Microsoft sta promuovendo maggiormente e i dispositivi biometrici, ormai diffusi in tutti i computer portatili, possono essere utilizzati per accedere a Windows e alle applicazioni web. A partire da Windows 10, versione 1809 (October 2018 Update), sono state diverse le novità introdotte da Microsoft per favorire gli utenti ed evitare sempre di più l’utilizzo delle password per effettuare l’autenticazione, a fronte dell’utilizzo di security key oppure di App installate in uno smartphone.

I concentti di base sull’autenticazione passworless sono ben descritti nell’articolo What is passwordless?

Prerequisiti

Per poter utilizzare il passwordless sign in con Azure AD è necessario avere:

• Una security key compatibile con FIDO2
• Aver abilitato Azure Multi-Factor Authentication (MFA)
• Windows 10 versione 1809 e successive
• Un browser che supporti il protocollo WebAuthn per l’autenticazione delle applicazioni web (al momento è possibile usare solo Microsoft Edge)

Per approfondimenti sul protocollo WebAuthN vi rimando alla lettura del documento https://www.w3.org/2018/Talks/06-WebAuthn.pdf

Per la realizzazione di questo articolo ho utilizzato una security Yubikey prodotta dalla Yubico che riesce a gestire la multi-factor authentication e la passwordless authentication.

Per poter utilizzare la passwordless authentication come metodo di autenticazione è necessario prima di tutto collegarsi al portale Azure e da Azure Active Directory > User Settings cliccare sul collegamento Manage user feature preview settings

Figura 1: Abilitazione della funzionalità di Preview in Azure Active Directory

Dal blade User feature previews selezionate in Users can use preview features for registering and managing security info – enhanced quale gruppo di utenti volete abilitare per poter testare le funzionalità in anteprima. Potete scegliere anche di abilitare la funzionalità per tutti gli utenti. Io ho scelto di abilitarla solo per un gruppo chiamato ICTPower Crew. Cliccate su Save per confermare la vostra scelta.

Figura 2: Abilitazione della funzionalità di anteprima solo per un gruppo di Azure AD

Navigate quindi in Azure Active Directory > Authentication methods > Authentication method policy (Preview) per abilitare il metodo da utilizzare. Cliccate su FIDO2 Security Key e abilitate la funzionalità. Non modificate altri parametri, perché al momento della stesura di questo articolo la funzionalità è ancora in preview e la key restriction policy non
funziona. Sarà disponibile al momento della general availability.

Figura 3: Abilitazione dell’uso della FISO2 Security Key come metodo di autenticazione passwordless

Registrazione della Security Key

Per poter registrare ed associare la propria security key all’account di Azure AD, ogni utente dovrà andare nel proprio profilo utilizzando il link https://myprofile.microsoft.com e modificare le Security Info. Dallo stesso link sarà possibile gestire anche le funzionalità di Multi-Factor Authentication.

Se l’utente ha già abilitato la Azure MFA potrà aggiungere direttamente la Security Key, altrimenti deve aggiungere almeno un metodo di autenticazione Azure MFA. L’account con cui mi sono loggato ha già abilitato Azure MFA e cliccando sul bottone +Add method ho potuto scegliere dal menù a tendina di aggiungere la Security Key.

Figura 4: Aggiunta del nuovo metodo di autenticazione basato su una Security Key

Poiché le Security Key possono essere sia USB che NFC (comode da utilizzare con uno smartphone), vi verrà presentato un menù da cui scegliere il tipo di chiave

Figura 5: Scelta del tipo di Security Key tra USB e NFC

Verrete a questo punto reindirizzati ad una pagina di login e vi verrà chiesto di inserire la vostra Security Key. Dopo l’inserimento della chiave dovrete proteggere l’accesso alla chiave con un PIN. Il PIN dovrà essere inserito ogni volta che vorrete utilizzare la Security Key per autenticarvi.

Figura 6: Configurazione di un PIN per utilizzare la Security Key

Dopo la configurazione del PIN sarà necessario toccare la chiave per attivarla.

Figura 7: Per utilizzare la chiave è necessario “toccarla”

Poiché è possibile utilizzare diverse chiavi per uno stesso account di Azure AD, vi verrà chiesto di inserire un nome descrittivo per distinguere facilmente le diverse Security Key.

Figura 8: Scelta del nome della Security Key per poterle distinguere facilmente

Figura 9: Associazione della Security Key all’account id Azure AD completata

Utilizzo della security Key per il login passwordless ad Azure AD

Per poter testare il login passwordless ad Azure AD (e quindi ad Office 365 o a Microsoft 365) dovrete servirvi di un browser che supporti il  protocollo WebAuthn e le Web Authentication API, che sono utilizzate dai browser più recenti, compresi Google Chrome (dalla versione 67 in poi https://developers.google.com/web/updates/2018/05/webauthn ) e Mozilla Firefox (dalla versione 60 in poi https://www.mozilla.org/en-US/firefox/60.0/releasenotes/ ).

Al momento della stesura di questa guida però l’unico browser funzionante è Microsoft
Edge. Mi sono collegato alla pagina di login di Office 365 e sono stato reindirzzato al sito https://login.microsoftonline.com. Nella finestra che si è aperta ho cliccato sul link Sign-in options

Figura 10: Test del login passwordless

A questo punto nel browser mi è stata presentata la possibilità di utilizzare Windows Hello oppure una Security Key

Figura 11: Tra le opzioni disponibili per il Sign-in c’è anche la Security Key

Vi verrà chiesto di inserire il PIN della Security Key e successivamente di confermare il login “toccando” la chiave, come mostrato nelle figure sotto:

Figura 12: Inserimento del PIN della Security Key

Figura 13: Richiesta di “toccare” la chiave per confermare l’autenticazione

È interessante notare che se utilizzate la stessa chiave per diversi account, vi verrà chiesto quale account utilizzare per il login e tutto questo senza digitare nulla dalla tastiera!

Figura 14: Richiesta di scelta dell’account di Azure AD con cui effettuare il login nel caso usiate la stessa security key con account differenti

Conclusioni

Il passwordless sign-in utilizzando una Security Key è decisamente una funzionalità interessante. L’accesso passwordless garantisce che ci si possa autenticare in modo molto semplice ma allo stesso tempo molto più sicuro. Il protocollo WebAuthn e lo standard FIDO2 sono pensati per gestire al meglio le nostre credenziali di accesso. Per ulteriori informazioni potete fare riferimento alla pagina Enable passwordless sign in for Azure AD (preview)