Tutti gli articoli di Nicola Ferrini

Creare una connessione Site-to-Site in Microsoft Azure

Microsoft Azure è la soluzione di cloud pubblico che permette di poter eseguire facilmente gran parte dei workload aziendali utilizzando le risorse hardware messe a disposizione online. Io sono dell’idea che un cloud ibrido, in cui alcuni workload sono online ed altri sono on-premises possa essere la soluzione più interessante per le aziende italiane.

In questo articolo voglio mostrarvi come connettere la rete aziendale on-premises con la rete virtuale di Azure (VNET), in modo tale che il cloud sia una naturale estensione della nostra infrastruttura. Per poterlo fare verrà creato un tunnel VPN IPsec/IKE (IKEv1 o IKEv2) tra due dispositivi: il primo dispositivo si troverà nella nostra infrastruttura (Local Network Gateway) e sarà raggiungibile dal cloud tramite un secondo dispositivo creato su Azure (Virtual Network Gateway).

Prerequisiti

Per poter realizzare una connessione Site-to-Site tra la vostra sede aziendale e Microsoft Azure è necessario che vengano rispettati alcuni prerequisiti:

  • Avere a disposizione in azienda un dispositivo VPN compatibile
  • Un indirizzo IP IPv4 pubblico esterno per il dispositivo VPN. L’indirizzo IP non può trovarsi dietro NAT

Figura 1: Schema di funzionamento di una connessione Site-to-Site

Configurazione della connessione

Per prima cosa è necessario avere una Virtual Network (VNET) all’interno della propria sottoscrizione Azure. Alla VNET verranno collegate tutte le macchine virtuali e i servizi che volete ospitare nel cloud. Scegliete di creare una nuova Virtual Network e indicate i parametri relativi al nome della rete, allo spazio di indirizzi da utilizzare e alle sottoreti ed ovviamente alla Regione di Azure dove volete crearla, come mostrato in figura:

Figura 2: Creazione della VNET

Figura 3: VNET creata – Visualizzazione Subnet

Una volta che è stata creata la VNET sarà necessario creare una subnet per il Gateway. In genere è sufficiente utilizzare una sottorete /27 o /28. Per poterlo fare vi basterà selezionare la VNET creata e scegliere il comando per aggiungere la Gateway Subnet. Il Nome per la subnet verrà compilato automaticamente con il valore ‘GatewaySubnet’. Questo valore è obbligatorio per consentire ad Azure di riconoscere la subnet come GatewaySubnet, quindi non modificatelo.

Figura 4: Aggiunta della Gateway Subnet

A questo punto siete pronti per la creazione del Gateway, che farà da Endpoint per la connessione VPN. Si tratta di due macchine virtuali messe in alta disponibilità e create da Microsoft che assicureranno la connessione con il dispositivo VPN che avere in casa.

Cliccate su Nuovo (+) à Networking à Virtual Network Gateway ed inserite i dati richiesti: nome, tipo di Gateway, SKU, Virtual Network a cui associarlo e indirizzo IP pubblico, come mostrato in figura:

Figura 5: Creazione del Virtual Network Gateway

Quando si crea il Virtual Network Gateway è necessario specificare un tipo di VPN. Il tipo di VPN scelto dipende dal tipo di connessione che si desidera creare. Ad esempio, una connessione Point-to-Site (P2S) richiede obbligatoriamente un tipo di VPN RouteBased. Dopo avere creato un gateway non è possibile modificare il tipo di VPN. È necessario eliminare il gateway e ricrearne uno nuovo. Lo SKU del Gateway VPN stabilisce il numero massimo di connessioni e la velocità effettiva aggregata. Attualmente sono disponibili le seguenti configurazioni:

SKU

Tunnel S2S/
rete virtuale-rete virtuale

Connessioni
P2S

Velocità effettiva
aggregata

VpnGw1

Max. 30

Max. 128

500 Mbps

VpnGw2

Max. 30

Max. 128

1 Gbps

VpnGw3

Max. 30

Max. 128

1,25 Gbps

Basic

Max. 10

Max. 128

100 Mbps

Per maggiori informazioni potete visitare la pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-gateway-settings#gwsku

La creazione del gateway può richiedere fino a 45 minuti. Nell’attesa potete procedere alla creazione del Local Network Gateway, che rappresenta il dispositivo VPN che avete in azienda e che volete usare per la connessione Site-to-Site. Per crearlo è sufficiente cliccare su Nuovo (+) à Networking à Local network gateway e compilare i campi indicando la rete (o le reti) presente in azienda e l’indirizzo IP pubblico del dispositivo VPN aziendale, come mostrato in figura:

Figura 6: Creazione del Local Network Gateway

Dopo aver atteso il completamento della creazione del Virtual Network Gateway, siamo pronti per creare la connessione Site-to-Site. Selezionate il Gateway e nel tab Settings cliccate su Connections, come mostrato in figura:

Figura 7: Scheda Connections del gateway VPN appena creato

Cliccando su Add avrete la possibilità di scegliere il Tipo di connessione, il Local Network Gateway e la Pre-Shared Key (PSK) necessaria a configurare la connessione IPSEC/IKE, come mostrato in figura:

Figura 8: Configurazione della connessione Site-To-Site

A questo punto il Gateway avrà lo Status Connecting fino a quando non avrete configurato il dispositivo in azienda.

Figura 9: Creazione VPN Site-to-Site completata

Configurazione del dispositivo VPN aziendale

Maggiori informazioni su come configurare i dispositivi VPN e sui parametri IPsec/IKE per le connessioni del Gateway VPN possono essere visualizzate alla pagina https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices . Microsoft ha predisposto un elenco dei dispositivi VPN dei maggiori vendor con relativa configurazione.

Personalmente nei miei laboratori utilizzo come endpoint Microsoft RRAS installato su Windows Server 2012 R2. È possibile configurarlo manualmente per la connessione IKEv2 oppure potete trovare uno script di configurazione al link https://github.com/Azure/Azure-vpn-config-samples/tree/master/Microsoft

Conclusioni

La connessione VPN Site-to-Site ci permette di poterci collegare alle VNET create in Microsoft Azure ed utilizzare il cloud come estensione delle nostre reti aziendali, dandoci di fatto l’opportunità di accedere alle notevoli risorse di calcolo offerte, come se fossero disponibili in azienda.

Configurare un site-aware failover cluster e la node fairness in Windows Server 2016

Il Site-Aware failover è una novità relativa alla funzionalità di Failover Clustering che è stata introdotta in Windows Server 2016. Anche se in realtà già in Windows Server 2012 R2 era possibile realizzare un cluster i cui nodi erano funzionanti in due regioni geografiche diverse, non c’era modo per indicare in quale di queste regioni si trovassero i diversi nodi, in modo tale da poterli gestire in maniera diversa e poter indicare ai diversi servizi di poter fare “failover” nella stessa area geografica.

Con Windows Server 2016 è stata invece introdotta la possibilità di raggruppare i nodi in base alla loro posizione fisica in modo tale da poter, ad esempio, permettere alle risorse del cluster di poter essere trasferite su un nodo nello stesso sito in caso di manutenzione o draining di un altro nodo.

Per poter implementare la site awareness è possibile procedere in due modi, uno automatico ed uno manuale.

Se si utilizza il modo automatico è possibile utilizzare i Site di Active Directory. Quindi se avete già definito dei Site dentro i quali avete messo i vostri Domain Controller e a cui avete associato delle subnet, vi basterà digitare il comando PowerShell (lanciato con privilegi elevati):

(Get-Cluster).AutoAssignNodeSite 1

Se volete utilizzare la modalità manuale sarà invece prima necessario definire quali sono i Site e successivamente aggiungervi i nodi, utilizzando i comandi PowerShell (lanciati con privilegi elevati):

#Creazione dei Site

New-ClusterFaultDomain –Name Roma –Type Site –Description “Datacenter Primario” –Location “Datacenter Roma”

New-ClusterFaultDomain –Name Milano –Type Site –Description “Datacenter Secondario” –Location “Datacenter Milano”

#Assegnazione dei nodi ai Site

Set-ClusterFaultDomain –Name Nodo1 –Parent Roma

Set-ClusterFaultDomain –Name Nodo2 –Parent Roma

Set-ClusterFaultDomain –Name Nodo3 –Parent Milano

Set-ClusterFaultDomain –Name Nodo4 –Parent Milano

Questo tipo di configurazione permette di migliorare notevolmente il failover, il placement delle macchine virtuali, gli heartbeat tra i nodi e il quorum.

Ad esempio la Failover Affinity permette che le risorse vengano spostate su un nodo dello stesso sito, prima di tentare di spostarle in un sito differente. Inoltre durante la Node Drain le macchine virtuali vengano spostate localmente, su un nodo vicino.

Il Cross-Site Heartbeat da’ la possibilità di configurare in maniera accurata alcuni parametri come ad esempio il CrossSiteDelay (il tempo tra due heartbeat inviati tra nodi in siti diversi) e il CrossSiteThreshold (il numero di heartbeat persi tra due nodi in site diversi). Entrambi i valori sono configurabili con i comandi PowerShell (lanciati con privilegi elevati)

(Get-Cluster).CrossSiteDelay 1000    #valore di default

(Get-Cluster).CrossSiteThreshold 20  #valore di default

Un’altra interessante novità di Windows Server 2016 riguarda la Virtual Machine Node Fairness, che è già abilitata di default ma che viene disabilitata se utilizzate la funzionalità Dynamic Optimization di System Center Virtual Machine Manager. La VM Node Fairness permette di bilanciare le macchine virtuali tra i diversi nodi del cluster: dopo aver valutato l’utilizzo del processore e della memoria, le macchine vengono automaticamente migrate (utilizzando la Live Migration) da un nodo più carico ad un nodo scarico. Il bilanciamento può essere configurato per ottenere le migliori performance nel cluster, utilizzando il comando PowerShell (eseguito con privilegi elevati) per configurare la percentuale di utilizzo del nodo:

(Get-Cluster).AutoBalancerLevel 2

riprendendo i valori dalla seguente tabella:

AutoBalancerLevel

Aggressiveness

Host load percentage

1 (default)

Low

80%

2

Medium

70%

3

High

60%

Oppure è possibile configurare ogni quanto tempo deve essere utilizzata la node fairness, utilizzando il comando PowerShell (eseguito con privilegi elevati):

(Get-Cluster).AutoBalancerMode 2

riprendendo i valori dalla seguente tabella:

AutoBalancerMode

Behavior

0

Disabled

1

Balance on node join only

2 (default)

Balance on node join and every 30 minutes

Conclusioni

Queste due importanti novità relativa al cluster di Windows Server 2016 sono pensate sia per la gestione del Disaster Recovery geografico tra diversi siti della nostra infrastruttura, sia per l’ottimizzazione delle performance dei nodi, senza dover ricorrere a prodotti a pagamento come SCVMM. Sicuramente un grosso passo in avanti per rendere i nostri datacenter più performanti ed avere lo stesso livello di funzionalità offerte dal Cloud pubblico.

Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3

Sono disponibili solo da un paio di giorni (e non in tutte le Regioni di Azure) le nuove macchine virtuali della Serie Dv3 ed Ev3. Queste macchine virtuali sono le prime ad essere ospitate su host Hyper-V basati su Windows Server 2016 e sono le prime che usano la tecnologia Hyper-Threading.

L’utilizzo dell’Hyper-Threading permetterà di creare macchine virtuali con più core e quindi migliorerà le performance e l’efficienza delle VM. I processori utilizzati sono Intel® Broadwell E5-2673 v4 2.3GHz e Intel® Haswell 2.4 GHz E5-2673 v3.

Grazie all’host Windows Server 2016 è adesso possibile abilitare la Nested Virtualization, che permette di poter eseguire il ruolo di Hyper-V anche in una macchina virtuale e di farci girare macchine virtuali annidate oppure Hyper-V Containers. Per maggiori informazioni su cosa sia la virtualizzazione annidata e come abilitarla in Windows Server 2016 vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Alla pagina https://azure.microsoft.com/it-it/blog/introducing-the-new-dv3-and-ev3-vm-sizes/ potrete trovare un elenco dettagliato delle nuove VM disponibili, dei tagli previsti e delle Regioni dove attualmente sono abilitate.

Creazione di una nuova VM di tipo Ev3 su Azure

Per poter sfruttare la Nested Virtualization è necessario creare una macchina virtuale di tipo Dv3 oppure Ev3 in una delle regioni abilitate. Io ho deciso di utilizzare una macchina E4s_v3 e l’ho creata in West Europe, scegliendo come sistema operativo Windows Server 2016.

Figura 1: Creazione della VM in West Europe

Figura 2: Scelta della dimensione della VM

Figura 3: Configurazione dello storage, della rete e dell’IP pubblico della VM

Figura 4: Schermata riassuntiva con le scelte selezionate

Al termine della creazione della VM potete collegarvi in desktop remoto per configurarla. Dal Server Manager aggiungete il ruolo di Hyper-V e vedrete che non riceverete nessun messaggio di errore, come mostrato in figura:

Figura 5: Abilitazione del ruolo Hyper-V nella nested VM in Azure

Abilitazione della Nested Virtualization

Per semplificare l’abilitazione e la creazione di macchine virtuali annidate, potete scaricare uno script in PowerShell realizzato da Charles Ding, ingegnere del gruppo di sviluppo Microsoft Azure, all’indirizzo https://aka.ms/azurenestedvirtualization. Lo script vi permetterà di configurare il ruolo di Hyper-V e tutte le altre caratteristiche necessarie alla creazione della Nested VM.

Eseguite lo script in PowerShell ISE (lanciato con privilegi elevati) e la prima volta lo script provvederà ad installare il ruolo di Hyper-V, come mostrato in figura:

Figura 6: Esecuzione dello script che installa Hyper-V e che crea la VM annidata

L’installazione di Hyper-V richiede un paio di riavvii, quindi verrete disconnessi dal desktop remoto. Dopo qualche minuto, potrete ricollegarvi e rilanciare lo script per creare la VM. Modificate il valore $VMName “NestedVM-Level2” scegliendo il nome che volete assegnare alla vostra Nested VM e rilanciate lo script. Lo script verificherà che i prerequisiti sia tutti rispettati e creerà la macchina virtuale, abilitando tutte le estensioni necessarie alla virtualizzazione annidata, come mostrato in figura:

Figura 7: Lo script ha creato la VM annidata

Dopo aver avviato la VM annidata, nel mio caso chiamata NestedVM-Level2, potete installare il sistema operativo, come mostrato in figura:

Figura 8: Accensione della nested VM e installazione del sistema operativo

Se volete permette alla macchina annidata di navigare, poiché il MAC Address spoofing non è abilitato su Azure per motivi di sicurezza, sarà necessario creare una rete NAT nell’hypervisor (la VM su Azure) e poi assegnare alla Nested VM un indirizzo statico oppure potete usare il DHCP.

Per prima cosa create nella macchina “host” (la VM su Azure) un nuovo internal switch chiamato NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione di uno switch di tipo Internal

New-VMSwitch -SwitchName “NAT” -SwitchType Internal

Con il comando Get-NetAdapter individuate l’indice assegnato alla nuova interfaccia di rete creata

Figura 9: Interfaccia di rete creata dallo switch di tipo Internal

A questo punto potete assegnare alla nuova scheda di rete un indirizzo IP statico (nel mio caso ho scelto 192.168.0.1), che poi verrà utilizzato dalla nested VM come gateway:

#Assegnazione dell’IP alla nuova interfaccia (sarà il gateway della rete)

New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13

Figura 10: Assegnazione dell’IP statico alla nuova interfaccia di rete

Create la rete di NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione della rete di NAT

New-NetNat -Name NATnetwork -InternalIPInterfaceAddressPrefix 192.168.0.0/24

Adesso che avete completato la configurazione della rete potete collegare la Nested VM al virtual switch NAT che avete creato in precedenza, come mostrato in figura:

Figura 11: La nested VM viene collegata al virtual switch chiamato NAT

Potete installare sulla macchina Azure il servizio DHCP e quindi fare in modo che gli indirizzi vengano assegnati automaticamente. In alternativa potete configurare la scheda di rete della Nested VM con un IP statico, come mostrato in figura:

Figura 12: Configurazione dell’IP statico nella Nested VM

Come è possibile vedere dalla figura sotto, adesso la Nested VM è in grado di navigare in Internet.

Figura 13: La nested VM è connessa ad Internet

Conclusioni

La Nested Virtualization su Azure permette di utilizzare la nuova funzionalità di Windows Server 2016 e di eseguire macchine virtuali annidate oppure gli Hyper-V Containers di Docker. Un possibile caso d’uso della virtualizzazione annidata potrebbe essere la configurazione di un laboratorio di Hyper-V in un ambiente virtualizzato e il test di scenari a più computer (come ad esempio un cluster) senza la necessità di avere dei server fisici.

Implementare Workgroup Cluster e Multi-Domain Cluster in Windows Server 2016

Mentre nelle precedenti versioni di Windows Server era necessario che tutti i nodi di un cluster fossero joinati ad un dominio di Active Directory, in Windows Server 2016 è stata introdotta la possibilità di creare cluster usando dei nodi in workgroup, permettendo quindi di non dover utilizzare un dominio ed implementare dei domain controller.

Nota: Con Windows Server 2016 è inoltre possibile creare cluster i cui nodi appartengono a domini diversi.

Per implementare un workgroup cluster o un multi-domain cluster è necessario però che vengano rispettati determinati prerequisiti:

  • Creare un account utente con lo stesso nome e la stessa password su tutti i nodi
  • Aggiungere l’account creato al gruppo Administrators locale
  • Se non si utilizza l’account predefinito Administrator è necessario creare la chiave di registro LocalAccountTokenFilterPolicy in HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System e metterla con valore 1
  • Il cluster deve essere creato nella modalità Active Directory-Detached Cluster, senza creare nessun oggetto in AD
  • È necessari creare il Cluster Network Name (chiamato anche Administrative Access Point) di tipo DNS
  • Ogni nodo deve avere un suffisso DNS
  • Nel caso di un multi-domain cluster, i suffissi DNS per tutti i domini del cluster devono essere presenti su tutti i nodi
  • Il Witness consigliato è un Cloud Witness oppure un Disk Witness. Non è supportato in entrambi i casi l’utilizzo del File Share Witness.

In questo articolo creeremo un workgroup cluster a due nodi (chiamati NODO1 e NODO2) utilizzando Windows Server 2016. Dopo aver preparato i nodi del cluster ed aver installato il sistema operativo ho provveduto a configurare il suffisso DNS su entrambi i nodi, come mostrato in figura:

Figura 1: Modifica del suffisso DNS

Dopo aver riavviato entrambi i nodi, ho provveduto a modificare il file HOSTS sulle macchine in modo tale che potessero risolvere i nomi dei nodi e il nome del cluster (che ho deciso di chiamare WRKGCLUSTER). Questa operazione è necessaria solo se non volete configurare un DNS. Nel caso abbiate un DNS in rete potete popolare la zona scelta (il suffisso DNS) per il vostro cluster (nel mio caso demo.lab).

Figura 2: Modifica del file HOSTS per la risoluzione del nomi

Ho provveduto quindi a creare su entrambi i nodi l’account di servizio ClusterSVC, ho impostato la stessa password e l’ho aggiunto al gruppo Administrators locale, come mostrato in figura:

Figura 3: Creazione dell’account per l’autenticazione NTLM

L’account è necessario affinché i nodi utilizzino l’autenticazione NTLM. Poiché non sto usando l’account Administrator è necessario inserire sui nodi la chiave di registro indicata nei prerequisiti. In maniera rapida ho eseguito sui due nodi, da un prompt PowerShell con privilegi elevati, il comando:

New-ItemProperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

Figura 4: Inserimento della chiave di registro necessaria all’utilizzo degli account

Successivamente ho provveduto ad installare la feature del Failover Cluster sui due nodi. È possibile usare il Server Manager oppure il comando PowerShell
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Figura 5: Installazione della funzionalità di Failover Cluster tramite PowerShell

Terminata l’installazione ho avviato il Failover Cluster Manager e ho lanciato il wizard per la creazione del Cluster. Ho aggiunto i due nodi e ho cliccato su Next, come mostrato in figura:

Figura 6: Aggiunta dei due nodi

Nella schermata successiva ho deciso di lanciare il Validate Configuration Wizard che ovviamente mi ha riportato dei Warning, come mostrato in figura:

Figura 7: Validate Configuration Wizard

Figura 8: Warning relativo alla non appartenenza dei nodi del cluster al dominio

Nella schermata successiva del wizard ho indicato il nome del cluster e l’indirizzo IP scelto, come mostrato in figura:

Figura 9: Scelta del nome del cluster e dell’indirizzo

Terminata la verifica che non ci sia un server con lo stesso nome NETBOIS e non ci siano indirizzi IP duplicati nella stessa rete, appare la schermata riepilogativa mostrata in figura, che indica che il cluster utilizzerà per la registrazione solo il DNS:

Figura 10: Schermata riepilogativa relativa alla creazione del cluster

La stessa operazione poteva essere effettuata utilizzando il comando PowerShell

New-Cluster –Name WRKGCLUSTER.demo.lab -Node NODO1.demo.lab,NODO2.demo.lab -AdministrativeAccessPoint DNS -StaticAddress 10.10.0.5


Al termine della procedura ho ottenuto la schermata finale dell’avvenuta creazione del cluster

Figura 11: Creazione del cluster completata

Figura 12: Nodi del cluster attivi

Conclusioni

I Workgroup Cluster e i Multi-Domain Cluster sono decisamente un’importante novità introdotta in Windows Server 2016. I workload supportati sono SQL Server, File Server e Hyper-V. Per quanto riguarda Hyper-V la mancanza dell’autenticazione Kerberos in realtà complica le cose in quanto la Live Migration non è supportata, mentre è supportata la Quick Migration.

Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD

Privileged Access Management (PAM) è una funzionalità introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) e che permette di gestire quella che viene chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server.

JEA è un toolkit di Windows PowerShell che definisce un set di comandi per l’esecuzione di attività con privilegi. Limitando nel tempo i privilegi amministrativi è possibile anche aumentare il livello di sicurezza perché molto spesso si assegnano privilegi elevati e successivamente questi privilegi non vengono rimossi, o per dimenticanza o banalmente perché si sottovaluta il pericolo derivante dalla non adozione della modalità amministrativa del Least Administrative Privilege.

Se dobbiamo concedere ad esempio al gruppo di Help Desk o al consulente esterno di effettuare operazioni privilegiate adesso possiamo fare in modo che ci sia un limite di tempo all’appartenenza ad un gruppo amministrativo. Stesso discorso vale se dobbiamo eseguire degli script con un utente particolare.

Privileged Access Management (PAM) contribuisce quindi a risolvere il problema dell’accesso alle risorse di Active Directory ed evitare che gli autori di un attacco informatico possano ottenere le credenziali degli account amministrativi.

Prerequisiti

Per poter utilizzare PAM è necessario prima di tutto che il livello funzionale dalla Foresta di Active Directory sia Windows Server 2016. Inoltre PAM è una funzione che va abilitata, perché non è attiva di default.

Per verificare il livello funzionale della foresta e del dominio potete utilizzare la console Active Directory Administrative Center, come mostrato in figura:

Figura 1: Innalzamento del livello funzionale del Dominio e della Foresta

In alternativa potete anche usare i seguenti comandi PowerShell:

#Get the Active Directory Forest functional level

(Get-ADForest).ForestMode

#Get the Active Directory Domain functional level

(Get-ADDomain).DomainMode

Figura 2: Uso di PowerShell per la verifica dei livelli funzionali di dominio e di foresta

Per innalzare il livello funzionale del dominio e della foresta potete anche usare i comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2016

Set-ADDomainMode -Identity demo.lab -DomainMode Windows2016

#Raise livello funzionale della foresta a Windows 2016

Set-ADForestMode -Identity demo.lab -ForestMode Windows2016

Abilitazione della funzionalità Privileged Access Management (PAM)

Una volta che vi siete accertati che la Foresta abbia il livello funzionale Windows Server 2016, potete installare la funzionalità PAM solo utilizzando PowerShell:

#Abilitazione della funzionalità Privileged Access Management (PAM)

Enable-ADOptionalFeature “Privileged Access Management Feature” -Scope ForestorconfigurationSet -Target demo.lab

Figura 3: Abilitazione della funzionalità Privileged Access Management (PAM)

Nota: Una volta abilitata la funzionalità non è possibile disabilitarla.

Per verificare se la funzionalità sia stata già installata è possibile usare la cmdlet

#Verifica dell’installazione della funzionalità Privileged Access Management (PAM)

Get-ADOptionalFeature “Privileged Access Management Feature”

Figura 4: Verifica dell’installazione della funzionalità Privileged Access Management (PAM) tramite PowerShell

Assegnazione temporanea dell’appartenenza di un utente ad un gruppo di Active Directory

Per poter assegnare temporaneamente uno o più utenti ad un gruppo di AD è necessario effettuare i seguenti comandi PowerShell:

#Definisco la durata di appartenenza al gruppo

$durata New-TimeSpan -Minutes 20

#Aggiungo al gruppo Domain Admind due utenti (attualmente Domain Users)

Add-ADGroupMember -Identity “Domain Admins” -Members nicferr,hector -MemberTimeToLive $durata

Figura 5: Aggiunta di due utenti al gruppo Domain Admins

Per verificare che i due utenti appartengano al gruppo Domain Admin vi basta poi lanciare la cmdlet

Get-ADGroup “Domain Admins” -Property Member -ShowMemberTimeToLive


Figura 6: Verifica dell’appartenenza al gruppo Domain Admins

Come si può notare dalla figura sopra, il risultato riporta:

Member : {<TTL=1068>,CN=Ettore Ferrini,CN=Users,DC=demo,DC=lab, <TTL=1068>,CN=Nicola Ferrini,CN=Users,DC=demo,DC=lab, CN=Administrator,CN=Users,DC=demo,DC=lab}

Accanto ai nomi dei due utenti aggiunti al gruppo Domain Admins c’è un campo TTL (espresso in secondi), che indica la durata rimanente dell’appartenenza al gruppo stesso.

Conclusioni

Privileged Access Management (PAM) è una funzionalità concepita appositamente per gli account amministrativi. Gli amministratori (o gli script) che necessitano solo occasionalmente dell’accesso per gruppi con privilegi, possono richiedere questo accesso e mantenerlo per un periodo limitato di tempo, garantendo la modalità amministrativa del Least Administrative Privilege ed aumentando di fatto la sicurezza della nostra infrastruttura di Active Directory.

Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/it-it/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services

Connected Ability – Hackaton disabilità visive – 27-28 giugno 2017 in Microsoft House

Oggi vogliamo condividere con voi un’iniziativa che si terrà alla fine di questo mese (27 e 28 Giugno) in Microsoft House in Viale Pasubio 21 a Milano.

Si tratta di un Hackathon di due giorni che mette al centro le disabilità visive e che prende il nome di Connected Ability. Non si tratterà solo di un evento informativo con sessioni e workshop, ma prevederà anche 24 ore durante le quali si svilupperanno progetti, idee e soluzioni. Questo hackathon rientrerà in un progetto ambizioso e molto più ampio, grazie al quale vorremmo sensibilizzare le nostre audience a proposito delle disabilità fisiche e non.

Dopo la mattinata del 27 giugno, in cui vedremo protagonisti diversi esponenti dell’Unione Nazionale Ciechi, nonché testimonianze e qualche sessione tecnica, verranno creati dei team e si darà il via a un vero e proprio hackathon con la possibilità di rimanere a dormire in Microsoft House. Lo scopo è sensibilizzare tutti, e non solo i partecipanti, al tema della disabilità e sforzarsi di mettersi nei panni altrui per creare delle soluzioni accessibili. Nei team gireranno a rotazione delle persone ipovedenti o non vedenti che possono essere di aiuto nella sensibilizzazione all’argomento.

Per maggiori informazioni potete visitare la pagina http://www.techiteasy.it/ dove in prima riga c’è il rimando all’hackathon, o collegarvi direttamente al link di iscrizione https://aka.ms/mscomm

Per partecipare all’Hackaton viene richiesto come conoscenza di base un linguaggio di programmazione supportato da Visual Studio e/o Xamarin ma anche se non si hanno competenze tecniche la propria esperienza potrà essere utile all’interno di un team di lavoro.

Ci sarà parallelamente un Hackathon Online, che prevede delle dirette Facebook dalla Microsoft House in quei giorni e la possibilità di interagire con esperti Microsoft.

Contiamo sul vostro interesse e sulla vostra sensibilità.

Restate in contatto con l’iniziativa utilizzando l’hashtag #ConnectedAbility

Adozione di Office 365 indolore con gli strumenti di Office365Italia.com

Oggi vi segnalo un’iniziativa molto interessante che riguarda il mondo che gira intorno all’offerta cloud di collaboration di Microsoft: il sito https://www.office365italia.com, un’offerta per aiutare l’adozione in azienda degli strumenti di Office 365 e SharePoint in modalità eLearning.
Office 365, presente da anni sul mercato, è ormai una piattaforma solida e in grado di offrire strumenti utili al nostro lavoro di tutti i giorni, sia in privato che in collaborazione con colleghi o persone esterne all’azienda. Strumenti, molto integrati gli uni con gli altri, che vengono tenuti aggiornati con cadenza mensile e rinnovati nelle loro funzionalità.
Passare ad Office 365 è una passeggiata dal punto di vista tecnico, ma necessita di un piano di adozione ad hoc per gli utenti finali, utile a facilitare l’adozione dei nuovi strumenti in azienda. Bisogna tenere sempre ben a mente che la formazione per gli utenti finali è la base per l’introduzione di qualsiasi nuovo software in azienda e anche in questo caso non possiamo certo sentirci esclusi da questo dato di fatto.
Ecco quindi dove si posiziona Office365Italia.com: con centinaia di video corsi, fatti ognuno da brevi lezioni, è possibile formare gli utenti finali della propria intranet all’utilizzo dei principali strumenti di Office 365 contenendo i costi di formazione con la possibilità, allo stesso tempo, di coprire una popolazione aziendale molto ampia.
Assieme all’offerta di supporto all’adozione in modalità eLearning, è possibile integrare attraverso attività formative on-site, corsi 1 to 1 in video-conferenza e webinar.
Per chi di voi è interessato ad approfondire, Office365Italia.com ci offre gratis 5 licenze del corso di OneDrive for Business.
Scrivete pure a contatta@office365italia.com dando come riferimento il sito ictpower.it 😉

Nic

Configurare diversi indirizzi IP per la stessa scheda di rete nelle VM in Microsoft Azure

Una delle novità più interessanti in ambito Networking riguardo Microsoft Azure è stata presentata pochi giorni fa nell’annuncio General availability: Multiple IP addresses per network interface

Trovo questa funzionalità particolarmente interessante perché risolve diversi problemi che mi avevano posto alcuni clienti. Ad esempio una web agency che ha creato diversi web server in Microsoft Azure ha bisogno di far girare diversi siti web e servizi con differenti indirizzi IP e certificati digitali sulla stessa scheda di rete della VM.

Questo tipo di funzionalità è utilizzabile per poter creare dei bilanciatori di carico o dei firewall utilizzando macchine virtuali gestite da noi.

È anche disponibile da pochissimi giorni la possibilità di avere almeno due schede di rete in tutte le macchine virtuali (Windows e Linux) create in Azure, come annunciato in General availability: Dual network interfaces for all Azure VMs

Per poter assegnare alla stessa scheda di rete due indirizzi IP diversi è sufficiente collegarsi al portale di Azure, selezionare la VM da modificare e cliccare sulla scheda di rete utilizzata dalla VM, come mostrato in figura:

Figura 1: Selezione dell’interfaccia di rete da modificare per la VM

Dopo aver cliccato sull’interfaccia di rete interessata, nel nuovo blade che vi si aprirà selezionate IP Configurations e cliccate sul pulsante Add per aggiungere un nuovo indirizzo, come mostrato in figura:

Figura 2: Blade IP Configurations per la scheda da modificare

Nel Blade Add IP configuration scegliete un nome simbolico per l’indirizzo IP da aggiungere, scegliete se volete mantenere statico o dinamico l’indirizzo IP privato (vi consiglio di mantenerlo statico) e successivamente scegliete se volete abilitare l’indirizzo IP Pubblico, come mostrato in figura:

Figura 3: Aggiunta del secondo indirizzo IP pubblico

Una volta completata la procedura ed assegnato il nome al secondo indirizzo IP pubblico vi verrà mostrata la schermata con gli indirizzamenti per la vostra scheda di rete, come mostrato in figura:

Figura 4: Indirizzamenti IP privati e pubblici per la scheda di rete della VM

Avete un numero limitato di indirizzi IP privati e pubblici da assegnare, come documentato dall’articolo https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits

Per completare l’operazione è necessario collegarsi in desktop remoto alla macchina virtuale ed assegnare gli indirizzi privati manualmente. Se infatti eseguite il comando ipconfig /all all’interno della VM vedrete che verrà visualizzato solo l’indirizzo primario, come mostrato in figura:

Figura 5: Presenza solo dell’indirizzo Primario assegnato alla scheda di rete della VM

Modificate le proprietà della scheda di rete aggiungendo manualmente gli indirizzi IP interni che avete assegnato staticamente nel portale di Azure, come mostrato in figura:

Figura 6: Assegnazione statica degli indirizzi privati scelti

Dopo aver assegnato gli indirizzi (attenti a non sbagliare perché altrimenti non vi riconnetterete più alla VM) la connessione in desktop remoto potrebbe disconnettersi per un secondo, ma poi sarete nuovamente collegati.

Rilanciando il comando ipconfig /all potrete verificare che adesso la scheda di rete ha i due IP interni che avete assegnato, come mostrato in figura:

Figura 7: Scheda di rete con doppio indirizzo IP interno

La macchina virtuale sarà raggiungibile in Desktop remoto su tutti gli indirizzi pubblici che avete assegnato, in quanto le regole di firewall sono definite dallo stesso Network Security Group.

Volendo è possibile dare un’occhiata alle proprie configurazioni di rete utilizzando lo strumento Network Watcher, che è possibile abilitare per ogni regione. Cliccate su Monitor nella Dashboard e abilitate il Network Watcher per le regioni disponibili per la vostra sottoscrizione.

Figura 8: Abilitazione del Network Watcher

Tra le funzionalità messe a disposizione del Network Watcher c’è la visualizzazione della Topologia del proprio scenario di rete, che mostra le varie interconnessioni e le associazioni tra le risorse di rete in un gruppo di risorse. Dal menù a tendina in alto scegliete la vostra sottoscrizione, il resource group e la scheda di rete da monitorare e vi verrà creata automaticamente la topologia di rete, con le diverse connessioni, come mostrato in figura:

Figura 9: Topologia di rete creata col Network Watcher

Conclusioni

La possibilità di avere due schede di rete su tutte le macchine virtuali in Azure e assegnare alla stessa scheda di rete diversi indirizzi IP, sia pubblici che privati, ci permette di implementare degli scenari di networking anche complesso che finora non era possibile realizzare. Creare bilanciatori di carico e firewall con le macchine virtuali su Azure non è mai stato così facile!

Proteggere i dati aziendali con Azure Information Protection

Il termine Informatica deriva dalla fusione delle due parole Informazione e Automatica. Le informazioni che gestiamo ogni giorno rappresentano, per gli utenti e per le aziende, delle importanti risorse per il business. Uno degli obiettivi più importanti che ci dobbiamo prefissare è quello relativo alla protezione dei dati. Tantissime informazioni vengono condivise ogni giorno dagli utenti, a volte anche in maniera sbagliata.

Per evitare che informazioni importanti vengano inviate dai nostri utenti a persone non autorizzate, anche per sbaglio, abbiamo a disposizione uno strumento davvero potente: Azure Information Protection.

Azure Information Protection (AIP) è il nuovo nome scelto da Microsoft per un servizio che è disponibile da diversi anni: Azure RMS (Rights Management Services). Tramite questo servizio basato sul Cloud è possibile proteggere e classificare documenti ed inviare messaggi di posta elettronica con contenuti che saranno disponibili solo per il destinatario. La protezione delle informazioni è basata sulla gestione dei diritti sul file, che includono copia, stampa, modifica e controllo completo.

Le informazioni (I dati) vengono protette grazie alla crittografia e le autorizzazioni che concediamo permettono di accedere al file ed interagire con lo stesso anche a chi non fa parte del nostro Tenant Azure AD, come ad esempio aziende partner con cui vogliamo collaborare. La protezione che applichiamo tramite i Rights Management Services rimane associata ai documenti e ai messaggi di posta elettronica indipendentemente che si trovino all’interno o all’esterno della nostra infrastruttura. La condivisione diventa quindi allo stesso tempo semplice e sicura.

Un altro grande vantaggio di Azure Information Protection è rappresentato anche dalla possibilità di poter essere usato su più dispositivi, inclusi telefoni, tablet e PC. Questo rende di fatto possibile mantenere il file protetto indipendentemente dalla piattaforma dalla quale viene usufruito.

Figura 1: Protezione del documento con Azure Information Protection

Prequisiti per l’implementazione e l’utilizzo di Azure Information Protection

Prima di distribuire Azure Information Protection per la nostra organizzazione è necessario verificare di possedere alcuni prerequisiti. È necessario quindi che la nostra azienda abbia:

  • Una sottoscrizione di Azure Information Protection (verificare le informazioni sulla sottoscrizione e l’elenco delle funzionalità nel sito Azure Information Protection)
  • Tenant di Azure Active Directory (necessaria per accedere al portale di Azure e configurare i criteri di Azure Information Protection)
  • Dispositivi client supportati (Windows 7, Windows 8, Windows 8.1, Windows 10)

Come attivare il servizio Rights Management?

È possibile attivare il servizio Right Management in vari modi, inclusi l’uso di Windows PowerShell e il portale di amministrazione di Office365.

Se preferite utilizzare PowerShell potete semplicemente installare il modulo Windows PowerShell per Microsoft Azure Rights Management scaricando l’Azure Rights Management Administration Tool.

Dopo aver installato il tool vi basterà eseguire la cmdlet Connect-AadrmService e, quando richiesto, specificare i dati dell’account dell’amministratore globale per il Tenant di Azure Information Protection. Eseguendo la cmdlet  Enable-Aadrm verrà attivato il servizio Azure Rights Management.

Figura 3: Attivazione del servizio Rights Management tramite PowerShell

Se preferite utilizzare l’interfaccia grafica vi basterà collegarvi al portale https://portal.office.com e dall’Office Admin Center dovrete cercare RMS nel campo di ricerca presente nella pagina principale. Verrete quindi reindirizzati alla pagina Manage Microsoft Azure Information Protection settings.

Figura 4: Pagina Manage Microsoft Azure Information Protection settings del portale di Office365

Nella pagina Rights Management fate clic su attiva. Se questo pulsante visualizza il testo deactivate, vuol dire che il servizio è già attivato.

Figura 5: Attivazione del servizio Rights management dal portale di Azure

Configurare e pubblicare le policy di Azure Information Protection

Azure Information Protection ha la possibilità di utilizzare alcune policy per poter applicare le protezioni ed i diritti di utilizzo per i nostri documenti.

Il passaggio successivo all’attivazione consiste infatti nella configurazione di queste policy.

Per poter modificare le policy, o per crearne di nuove, dovete accedere al portale di Azure come amministratore globale del Tenant e dal Marketplace scegliete Security + Identity e successivamente Azure Information Protection. Fate clic su Create per abilitare la funzionalità.

Figura 6: Abilitazione della funzionalità di Azure Information Protection dal portale di Azure

La creazione dura pochissimi istanti. Vi basta poi riaprire il blade di Azure Information Protection per poter visualizzare la Global policy. Come potete notare dalla figura sotto ci sono 5 etichette predefinite per la classificazione dei documenti: PersonalPublicGeneralConfidential, and Highly Confidential.

Figura 7: Global Policy di Azure Information Protection

All’interno della Global Policy troverete una serie di Label che vi serviranno ad individuare il grado di riservatezza da dare ai vostri file ed a definire i livelli di accesso ai file.

Se volete creare un’etichetta personalizzata (Label) è sufficiente cliccare sul pulsante Add a New Label e nel blade che vi si aprirà configurate i parametri che vi interessano (Label Name, Description Color, Permission, ecc.). Nella figura sotto è mostrata la creazione della nuova Label chiamata ICTPower Sensitive Informations, che prevede che venga applicato un Template di Azure RMS chiamato Nicola Ferrini 365 – Confidential. La creazione e la personalizzazione dei Template esula da questa guida. Maggiori informazioni sono disponibili alla pagina Configurazione di modelli personalizzati per il servizio Azure Rights Management.

Figura 8: Creazione di un’etichetta personalizzata

Cliccate su Save e verificate che la nuova Label sia disponibile tra quelle già presenti nella Global Policy.

Figura 9: Aggiunta della nuova label alla Global Policy

Terminata la modifica della Global Policy basta chiudete il blade e confermate di voler pubblicare cliccando su Publish.

Figura 10: Pubblicazione della Global Policy aggiornata

Installazione del client di Azure Information Protection

Per poter utilizzare Azure Information Protection è necessario utilizzare un client. Il client permetterà di far apparire un nuovo pulsante sulla barra di Office e ci permetterà di visualizzare le etichette create ed applicare le policy configurate. Il client si integra anche con il sistema operativo e vi permetterà di poter rendere sicuri anche file diversi da quelli classici di Office, come ad esempio i file .PDF. Scaricate il client di Azure Information Protection e installatelo.

Figura 11: Installazione del client di Azure Information Protection

Al termine dell’installazione, se apriamo un’applicazione Office, riceveremo il messaggio che è possibile etichettare e proteggere le informazioni contenute nel documento, come mostrato in figura:

Figura 12: Messaggio che ci avvisa che è possibile etichettare e proteggere le informazioni

Nella barra degli strumenti di Word (o di Excel e Powerpoint) sarà anche disponibile il pulsante Proteggi e le Label che abbiamo impostato nella Global Policy saranno visibili in una barra subito sopra l’area di lavoro, come mostrato in figura:

Figura 13: Barra degli strumenti creata dal client di Azure Information Protection

Fate clic su Proteggi –> Guida e commenti e suggerimenti e nella finestra di dialogo Microsoft Azure Information Protection verificate lo stato del client, che vi darà informazioni relative all’ account con cui siete connessi, data e ora dell’ultima connessione, data di installazione del client.

Figura 14: Informazioni fornite dal client di Azure Information Protection

Classificazione, aggiunta di etichette (Label) e protezione dei file

Per poter cambiare la Label è sufficiente cliccare sulla barra di Azure Information Protection e modificare la Sensitivity. Nel mio caso ho scelto di utilizzare la Label che ho aggiunto alla Global Policy. Se per errore sbagliate ad impostare la Label (e quindi il livello di Riservatezza) potete cliccare sul simbolo a forma di matita e utilizzare il simbolo a forma di cestino per eliminarla.

Figura 15: Applicazione della Label scelta per proteggere il documento

Nel mio esempio la Label permetteva anche di applicare il Template RMS. Il documento è quindi protetto dal modello di Azure Rights Management che ho specificato quando ho creato la nuova Label. Cliccando sulla scheda File si possono infatti visualizzare le informazioni in Proteggi documento e verificare il Template che è stato automaticamente utilizzato.

Figura 16: Modello di Azure Right Management applicato

Condivisione di file protetti e tracciamento del documento

Per proteggere un documento con Azure Information Protection non è necessario utilizzare Office. È possibile fare clic in Esplora Risorse col tasto destro sull’icona del file e scegliere Classifica e proteggi. Verrà visualizzata la finestra di dialogo Classifica e proteggi – Azure Information Protection, come mostrato in figura:

Figura 17: Protezione del documento da Esplora Risorse

Aggiungete al documento la Sensitivity desiderata e definite le Permission. Selezionate Proteggi con autorizzazioni personalizzate per visualizzare opzioni aggiuntive e per definire delle Permission personalizzate non previste dalla Label scelta. Gli utenti o i gruppi a cui vorrete aggiungere le permission devono essere indicati come indirizzi di posta elettronica, come mostrato in figura:

Figura 18: Scelta delle opzioni di protezione per il documento

Dopo aver applicato la protezione noterete anche che l’icona del file è stata modificata. Nel mio caso ho protetto un file .PDF e come si può vedere è stata modificata anche l’estensione del file in .PPDF

Se fate doppio clic sul file vi si aprirà Azure Information Protection Viewer invece che il vostro lettore PDF preferito.

Figura 19: Azure Information Protection Viewer

Spesso abbiamo bisogno di condividere i nostri documenti anche all’esterno dell’azienda. Se spedite il documento inviandolo come allegato di posta elettronica o semplicemente utilizzate un disco esterno, un pendrive USB o un servizio per la condivisione dei file, il documento non perderà la protezione che gli avete assegnato.

Figura 20: Invio del documento protetto

La prima volta che il destinatario vorrà accedere ad un documento protetto con Azure Information Protection dovrà seguire le istruzioni riportate alla pagina https://aka.ms/rms-signup. Per poter aprire il documento protetto con RMS bisogna immettere l’indirizzo di posta elettronica aziendale che è stato indicato da chi ha applicato la protezione prima dell’invio del file, che identifica di fatto chi è legittimato all’utilizzo del file.

Figura 21: richiesta di inserimento dell’indirizzo di posta elettronica aziendale autorizzato all’apertura del documento

Una volta effettuato l’accesso con l’account aziendale basta cliccare su Inizio, come mostrato in figura:

Figura 22: Accesso effettuato con l’account aziendale

Esistono diversi tipi di client di Azure Information Protection, disponibili per computer e per dispositivi mobili (Microsoft, Apple, Android). Dal sito sarà possibile scegliere quello più adatto dalla pagina che si aprirà automaticamente, come mostrato in figura:

Figura 23: Client di Azure Information Protection disponibili

Scegliete il client che volete installare, a seconda del sistema operativo da cui state visualizzando l’allegato di posta o il file in generale. Verrete quindi reindirizzati alla pagina per il download di Microsoft Azure Information Protection Viewer.

Figura 24: download di Microsoft Azure Information Protection Viewer

Dopo il download e l’installazione potrete finalmente visualizzare il file.

Figura 25: Visualizzazione del file tramite Azure Information Protection Viewer

È anche possibile tenere traccia del file, cioè sapere chi e quando lo ha aperto e modificato. Vi basta cliccare sull’icona Proteggi dell’applicazione Office e scegliere Rileva e Revoca. Se state visualizzando il file dall’Azure Information Protection Viewer potete anche fare clic sul pulsante Track and Revoke. Sarà necessario però avere una licenza di Azure Rights Management Premium per accedere al sito di tracciamento dei documenti.

Figura 26: Richiesta delle credenziali per poter accedere al Tracking del file

Conclusioni

Azure Information Protection ci permette di poter proteggere e soprattutto condividere i nostri file in sicurezza, utilizzando una serie di template già pronti e facili da usare. I documenti e i dati sensibili che vogliamo condividere all’esterno dell’azienda saranno dotati di una protezione contro l’accesso non autorizzato indipendentemente da dove sono archiviati o con chi vengono condivisi.

Implementare il Single Sign-On (SSO) con Azure AD

La maggior parte degli utenti vuole utilizzare un’unica password per poter accedere sia all’Active Directory locale che ai servizi che usano Azure AD, come ad esempio Office 365. Abbiamo visto in un precedente articolo, Come funziona Azure AD Pass-through Authentication, come poter fare in modo che l’autenticazione avvenga utilizzando il domain controller locale, nel caso non vogliamo replicare le nostre password in Azure AD. Utilizzare la stessa username e password sia all’interno che all’esterno della propria infrastruttura aziendale prende il nome di SAME SIGN-ON.

In questo articolo vedremo invece come implementare il SINGLE SIGN-ON (SSO), un’opzione che consente agli utenti di non dover digitare la password, ma solo il nome utente, per accedere ad Azure Active Directory.

SSO è una funzionalità che viene abilitata tramite il tool Azure AD Connect e funziona sia con la sincronizzazione delle password sia con l’autenticazione pass-through. Questo tipo di funzionalità però è disponibile solo se il computer da cui effettuiamo la connessione è joinato al dominio.

Vantaggi del Single Sign-on con autenticazione Pass-through di Azure AD

Sicuramente tra i vantaggi più evidenti di questo tipo di autenticazione spicca quello di evitare l’uso dei Federation Services, che prevedono una farm di almeno 2 Server ADFS nel Backend e 2 Server Web Application Proxy nella DMZ, per un totale di 4 server! Per avere un’idea di quanto sia complicata l’infrastruttura che usa ADFS potete dare un’occhiata all’articolo Checklist: Use AD FS to implement and manage single sign-on.

Come funziona

Il principio di funzionamento del Single Sign-On con Azure AD è molto semplice. Quando l’utente tenta di accedere ad una risorsa che usa Azure AD per l’autenticazione, come ad esempio il portale di Office 365, gli vengono chieste le credenziali. L’utente viene reindirizzato al portale di autenticazione https://login.microsoftonline.com e dopo aver inserito la propria username, viene reindirizzato verso il proprio domain controller. Active Directory restituisce un ticket Kerberos al client. Il client invia il ticket Kerberos acquisito da Active Directory ad Azure AD. Azure AD decrittografa il ticket Kerberos e restituisce un token all’utente, che lo riutilizza per poter accedere alla risorsa, come ad esempio il portale di Office365.

Il tutto avviene in maniera completamente trasparente per l’utente, che dopo aver inserito la username si ritrova autenticato senza aver dovuto inserire la password.

Figura 1: Principio di funzionamento del Single Sign-On (SSO)

Abilitazione di SSO con autenticazione pass-through

Single Sign-On è un’opzione che può essere abilitata utilizzando il tool Azure AD Connect tramite sincronizzazione delle password o autenticazione pass-through.

In questo articolo ci occuperemo di implementare il SSO con l’autenticazione pass-through.

Procediamo all’installazione di Azure AD Connect scaricando l’eseguibile dal link http://go.microsoft.com/fwlink/?LinkId=615771 e lanciamo il setup

Figura 2: Setup di Azure AD Connect

Scegliamo di installare Azure AD Connect in modalità personalizzata, cliccando su Customize, e nella schermata successiva facciamo clic su Install.

Figura 3: Installazione dei prerequisiti di Azure AD Connect

Dopo l’installazione dei componenti necessari, viene richiesta la selezione del metodo di accesso degli utenti. Scegliamo quindi la modalità Pass-Through Authentication e mettiamo il segno di spunta su Enable single sign-on, come mostrato in figura:

Figura 4: Single Sign-On con autenticazione pass-through

Inseriamo a questo punto le credenziali da Global Admin del nostro Tenant di Azure AD. Usate un utente creato nel Cloud, possibilmente un account del dominio onmicrosoft.com.

Figura 5: Connessione ad Azure AD

Nella schermata successiva inseriamo le credenziali di Enterprise Admin del nostro dominio di Active Directory locale.

Per poter utilizzare le stesse credenziali sia per il login in Active Directory che per il login in Azure AD è necessario che gli username e i suffissi UPN (User Principal Name) coincidano. Per questo motivo nella schermata successiva vi verranno mostrati i domini che sono stati verificati nel vostro Tenant di Azure AD. Verificate che i domini siano corretti, altrimenti procedete alla regsitrazione dei suffisso UPN utilizzando la console di Active Directory Domains and Trusts.

Figura 6: Verifica dei suffissi UPN e del domini verificati in Azure AD

Di default vengono sincronizzati tutti i domini della foresta e tutte le unità organizzative (OU). Per escludere alcuni domini o unità organizzative dalla sincronizzazione con Azure AD, è possibile deselezionarli. Io ho deciso di sincronizzare solo la OU chiamata Office365.

Figura 7: Scelta dei domini e delle OU da sincronizzare

Nella schermata relativa all’Identificazione univoca degli utenti lasciamo le configurazioni predefinite e facciamo clic su Next. Lasciamo tutte le impostazioni di default anche per la schermata Filter Users and Devices.

Figura 8: Parametri per l’identificazione univoca degli utenti

Figura 9: Scelta degli utenti o del gruppo da sincronizzare

Nella schermata delle Optional Features, poiché abbiamo scelto l’autenticazione Pass-through, l’opzione di sincronizzazione delle password è abilitata di default. Questa opzione non è obbligatoria e per alcune aziende è importante che le password non vengano portate nel Cloud. Decidiamo quindi di non selezionarla, come mostrato in figura:

Figura 10: Optional features

Quando si abilita Single Sign-On in Azure AD Connect, viene creato un account computer denominato AZUREADSSOACCT nell’Active Directory locale e la chiave di decrittografia di Kerberos è condivisa con Azure AD. Inoltre vengono creati due Service Principal Name (SPN) Kerberos per indicare gli URL del cloud usati durante l’autenticazione tra il client e Azure AD. Inseriamo a questo punto le credenziali di Domain admin appropriate per il nostro dominio, in modo tale che venga creato l’account computer AZUREADSSOACCT , come mostrato in figura:

Figura 11: Inserimento delle credenziali per la configurazione del computer account nell’ Active Directory locale

Cliccando su Next avremo completato la configurazione e subito dopo inizierà il processo di sincronizzazione con il nostro Tenant di Azure AD.

Figura 12: Completamento del processo di configurazione

Figura 13: Installazione completata

Figura 14: Account computer AZUREADSSOACCT creato nell’Active Directory locale

Per poter testare il funzionamento del Single SIGN-On ci basterà loggarci su uno dei client del dominio e accedere al portale di autenticazione di Azure AD https://login.microsoftonline.com

Per poter garantire l’accesso automatico del client è prima necessario impostare nella Local Intranet del browser i due url:

Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per Azure AD.

Apriamo Internet Explorer, clicchiamo sul simbolo della rotellina per aprire le Internet Options, spostiamoci nella scheda Security e selezioniamo Local Intranet. Dopo aver cliccato su Sites, clicchiamo su Advanced e si aprirà la schermata dove potremo inserire i due URL, come mostrato in figura:

Figura 15: Aggiunti esplicita all’area Intranet del computer dei due siti di autenticazione

Figura 16: Particolare dei due URL aggiunti alla Local Intranet

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

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

Facendo clic sul pulsante Show potremo inserire i due URL richiesti, come mostrato in figura:

Figura 17: URL e valori da inserire

Conclusioni

Il SINGLE SIGN-ON, in associazione all’autenticazione Pass-through, ci permette di avere le stesse funzionalità che fino ad ora erano possibili sono utilizzando gli Active Directory Federation Services, che richiedono diverse macchine per poter funzionare. Davvero una grossa novità ed un grosso vantaggio per autenticarsi in Azure AD senza dover sincronizzare le password in Azure AD.