Archivi categoria: Azure

Implementare una VPN site-to-site in Azure con Veeam PN

Facebooktwittergoogle_plusredditlinkedin

Quando un’organizzazione decide di adottare servizi offerti da cloud pubblici si trova spesso a dover affrontare la sfida di interconnettere in modo sicuro e gestito utenti e servizi della propria rete con le risorse ospitate nel cloud.

Tipicamente, questo scenario implica mettere in conto i costi del servizio VPN offerto dal vendor del cloud pubblico e il dover configurare un appliance locale seguendo indicazioni e prescrizioni in termini di compatibilità legate a tale servizio.

Ad esempio, nel caso di Microsoft Azure, realizzare una VPN site-to-site prevede la disponibilità nella propria rete locale di un dispositivo VPN “convalidato” (vedi https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices).

Talvolta potrebbe essere necessario dover collegare una o più sedi della nostra organizzazione a virtual machine o applicazioni che abbiamo collocato su Azure non disponendo però del numero o del tipo di apparati necessari, oppure non essendo possibile alterare la configurazione di quelli esistenti…

In questo articolo vedremo come creare una VPN fra la rete locale aziendale e una subnet in Azure utilizzando il componente gratuito Veeam PN realizzato da Veeam Software (https://www.veeam.com).

Veeam Powered Network (PN)

Veeam PN è un tool di Software Defined Networking (basato su una distro Linux Ubuntu 16.04.1 LTS) che consente di creare in maniera molto semplice e lineare tunnel VPN fra reti aziendali (“site-to site”) o fra un client e la rete aziendale (“point-to-site”).

Si basa sulla tecnologia OpenVPN (https://openvpn.net/index.php/open-source/333-what-is-openvpn.html) la cui implementazione è semplificata da un’interfaccia web che permette di applicare intuitivamente configurazioni e politiche amministrative.

Si può scaricare, previa registrazione gratuita, da qui: https://www.veeam.com/cloud-disaster-recovery-azure-download.html

Il download consiste in un file .ova di circa 1 Gb.

Nota: I file .ova sono “pacchetti” che contengono descrizioni e informazioni di certificazione relative ad una macchina virtuale (nel nostro caso l’appliance Veeam PN) che possono agilmente essere importate in ambiente VMware.

Come anticipato, Veeam PN può aiutarci (e possiamo dire che il tool sia nato proprio per questo scopo) nel creare connessioni protette verso nostre risorse collocate in Azure risolvendo il problema di dover modificare la configurazione di apparati VPN esistenti in conformità con le specifiche indicate da Microsoft:

  • VPN site-to-site, fra una o più sedi della nostra organizzazione ed una nostra subnet in Azure;
  • VPN point-to-site, fra uno o più client ed una nostra subnet in Azure.

Figura 1 – Scenari di implementazione di Veeam PN

Il ruolo svolto da Veeam PN, e quindi la relativa configurazione, dipende dalla collocazione nell’architettura:

  • Network Hub: gestisce il traffico fra la rete che offre i servizi e le reti o i client che devono accedervi in modo protetto; nel nostro schema il ruolo Network Hub di Veeam PN è collocato in Azure.
  • Site Gateway: stabilisce il tunnel VPN fra la rete che offre i servizi ed una rete remota; nel nostro schema, il ruolo Site Gateway è collocato on-premise.

Per consentire ad un singolo computer di accedere ad una rete gestita dal ruolo Network Hub, occorre installare sul PC Windows o Linux il client OpenVPN (https://openvpn.net/index.php/open-source/downloads.html). Per OS X e MacOS seguire le indicazioni riportate qui: https://openvpn.net/index.php/access-server/docs/admin-guides/183-how-to-connect-to-access-server-from-a-mac.html.

Requisiti di Veeam PN

Per installare l’appliance on-premise si raccomanda di utilizzare VMware vSphere versione 5.x o successive. La virtual machine dovrà disporre di almeno 1 CPU, 1GB di RAM e di un disco thin-provisioned di 4 GB. Per fare qualche sperimentazione è anche possibile utilizzare VMware Workstation o Virtual Box, ma non se ne raccomanda l’impiego in produzione.

Per installare l’appliance in Azure, dovremo prevedere una virtual machine almeno di dimensioni A1 (1 core, 1,75GB di RAM, 70 GB di spazio disco.

L’amministrazione di Veeam PN si effettua via browser: le versioni più recenti di Internet Explorer, Edge, Firefox, Chrome sono tutte supportate.

Informazioni sui requisiti e le indicazioni relative all’installazione del client OpenVPN sono disponibili qui: https://openvpn.net/index.php/open-source/documentation/install.html.

Porte utilizzate da Veeam PN:

Da Verso Protocollo Porta
Site Gateway Network Hub TCP/UDP 1194
Computer client Network Hub TCP/UDP 6179
Browser Network Hub o Site Gateway HTTPS 443

Installazione del ruolo Network Hub

Il primo ruolo di Veeam PN da installare è quello di Network Hub su Azure.

Una volta fatto accesso alla sottoscrizione Azure sulla quale abbiamo privilegi amministrativi, selezionare l’opzione Create a Resource e, nella casella di testo, digitare veeam pn, poi premere Invio.

Figura 2 – Create a Resource

Nei risultati della ricerca, fare clic su Veeam PN for Microsoft Azure.

Figura 3 – Veeam PN for Microsoft Azure, trovato!

Nella pagina successiva, fare clic su Create.

Figura 4 – Avvio creazione risorsa

Viene presentata la prima delle schede di configurazione della virtual machine che ospiterà il network appliance.

Fornire un nome per la virtual machine, un nome ed una password per l’account amministrativo, selezionare la sottoscrizione Azure in cui collocare la risorsa, decidere se utilizzare un Resource Group esistente (ma privo di risorse) o se crearne uno ad hoc e la regione Azure in cui desideriamo operare.

Infine, clic su OK.

Figura 5 – Informazioni di base

Nella scheda Veeam PN Settings:

  • Selezionare la dimensione della virtual machine: una Standard A1 può essere sufficiente per sperimentazioni o piccoli carichi di lavoro; in produzione si raccomanda di selezionare almeno una Dv2;
  • Specificare o creare uno Storage Account in cui verrà creato il disco della virtual machine;
  • Dare un nome univoco alla virtual machine;
  • Selezionare la Virtual Network a cui l’appliance sarà connesso (tipicamente la stessa Virtual Network in cui si trovano le risorse che dovranno essere raggiunte tramite VPN) e la relativa Subnet;
  • Fare clic su OK.

Figura 6 – Veeam PN Settings

Nella scheda successiva, Security Settings, selezionare la lunghezza della chiave di cifratura adottata per la generazione del canale sicuro e fare clic su OK.

Figura 7 – Security Settings

Nella scheda VPN Information è possibile selezionare le funzionalità con cui sarà configurato l’appliance Veeam PN e quindi stabilire se sarà possibile consentire connessioni site-to-site o point-to-site o entrambe. È anche possibile specificare protocolli e porte non di default. I valori predefiniti sono UDP 1194 per le connessioni site-to-site e UDP 6179 per le connessioni point-to-site.

Effettuate le scelte, fare clic su OK.

Figura 8 – VPN Information

Nella scheda Summary, dopo una verifica finale dei parametri impostati, è possibile fare clic su OK.

Figura 9 – Summary

Nella scheda successiva fare clic su Create.

Il processo di creazione delle risorse e della macchina virtuale dura pochi minuti.

Figura 10 – Fasi della creazione appliance Veeam PN

Configurazione del ruolo Network Hub

Al termine della creazione della macchina virtuale Veeam PN, è necessario effettuare alcune configurazioni preliminari.

Dal portale amministrativo di Azure, fare clic su Virtual Machines, poi sul nome della macchina virtuale Veeam PN appena creata per visualizzarne le proprietà.

Figura 11 – Indirizzo pubblico appliance

Annotare il Public IP Address (nel nostro caso 40.127.163.70), avviare un browser e connettersi via https.

Effettuare il login con le credenziali amministrative specificate al momento della creazione della virtual machine.

Figura 12 – Login

Nella scheda Azure Setup, fare clic su Next.

Figura 13 – Avvio wizard

Veeam PN richiede che ci si autentichi su Microsoft Azure Active Directory. Copiare il codice di autenticazione fornito e accedere al link indicato nella scheda.

Figura 14 – Codice di autenticazione (CTRL+C)

Incollare il codice nella casella di testo della pagina Web e, se il codice fornito risulta corretto, fare clic su Continua.

Figura 15 – Codice di autenticazione (CTRL+V)

Qualora richiesto, selezionare l’account corrente o specificarne uno diverso che abbia accesso alla sottoscrizione Azure.

Figura 16 – Conferma account

Tornare alla pagina di configurazione di Veeam PN e fare clic su Next.

Figura 17 – Il wizard prosegue

Al termine della configurazione automatica, fare clic su Finish.

Figura 18 – Azure setup completato

Configurazione dell’accesso dalla rete remota

È ora necessario consentire l’accesso al Veeam PN con il ruolo Network Hub da parte del Veeam PN con il ruolo Site Gateway che sarà installato e configurato successivamente.

Nella pagina principale del portale amministrativo di Veeam PN, fare clic su Clients.

Figura 19 – Portale amministrativo Veeam PN

Fare clic su Add.

Figura 20 – Aggiunta client

Nella scheda Add Client selezionare l’opzione Entire
Site e fare clic su Next.

Figura 21 – Opzione Entire Site

Specificare un nome identificativo e la subnet (nel formato CIDR) a cui appartengono gli host on-premise che dovranno connettersi ad Azure tramite VPN. Poi fare clic su Next.

Figura 22 – Informazioni sulla subnet on-premise

Nella scheda di riepilogo, fare clic su Finish.

Figura 23 – Completamento aggiunta client

Viene proposta la finestra di dialogo per il salvataggio del file (.xml) di configurazione che sarà poi necessario importare durante la configurazione del Veeam PN con il ruolo di Site Gateway.

Salvare il file in una posizione successivamente accessibile.

Nel portale amministrativo di Veeam PN è ora presente la rete che abbiamo appena definito come client.

Figura 24 – Conferma dell’aggiunta client

Installazione del ruolo Site Gateway

Passiamo ora a configurare Veeam PN on-premise per poter connettere con un tunnel VPN la rete aziendale ad Azure.

Collocare il pacchetto .ova scaricato dal sito Veeam (https://www.veeam.com/cloud-disaster-recovery-azure-download.html) in una posizione accessibile dall’ambiente VMware.

Per istruzioni dettagliate su come effettuare il deployment di un template OVA in ambiente vSphere: https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-AFEDC48B-C96F-4088-9C1F-4F0A30E965DE.html

Figura 25 – Package OVA caricato in vSphere

Qui https://spaces.uncc.edu/display/CKB/Importing+OVA+File+into+VMware+Workstation+14 una guida su come procedere utilizzando invece VMware Workstation (scenario consigliato unicamente nel caso di laboratori o sperimentazioni).

Completato il deployment del pacchetto .ova, dal client vSphere o dalla console di VMware Workstation, ricavare l’indirizzo IP dell’appliance Veeam PN (nel nostro caso 192.168.1.94) e accedervi via browser con le credenziali di default:

  • Utente: root
  • Password: VeeamPN

Figura 26 – Login al Veeam PN on-premise

Viene immediatamente richiesto di cambiare la password di default.

Figura 27 – Cambio password

Nella scheda successiva, Initial Configuration, è possibile scegliere il ruolo che dovrà svolgere questo appliance o se ripristinare la configurazione da un precedente backup.

Nel nostro caso, selezionare l’opzione Site gateway, poiché il ruolo Network Hub è stato precedentemente collocato su Azure, e fare clic su Next.

Figura 28 – Configurazione ruolo

Occorre ora effettuare l’upload del file .xml di configurazione generato durante la configurazione del ruolo Network Hub.

Fare clic su Browse e selezionare il file. Poi fare clic su Finish.

Figura 29 – Completamento configurazione

Dopo qualche secondo, nel portale amministrativo del Veeam PN on-premise viene segnalata l’effettuata connessione con il Veeam PN collocato su Azure.

Figura 30 – Conferma connessione lato on-premise…

Connettersi con il browser al Veeam PN su Azure e verificare che anche da quel lato gli indicatori siano “verdi”,

Figura 31 – …e conferma connessione lato Azure

Test della connessione VPN

Nello schema qui dis eguito, lo scenario oggetto della verifica: il client aziendale appartenente alla sede di Roma (indirizzo IP 192.168.1.246) deve potersi connettere tramite VPN al server AZRSRV01 collocato su Azure (indirizzo IP privato 10.1.0.4).

Figura 32 – Schema scenario da verificare

Nel portale amministrativo di Azure, fare clic su Virtual Machines, poi sulla macchina virtuale Veeam PN. Infine fare clic su Networking. Prendere nota dell’indirizzo IP privato (nel nostro caso 10.1.0.5).

Figura 33 – Rilevamento IP privato appliance Veeam PN su Azure

Accedere al client aziendale collocato nella rete on-premise, aprire una sessione Command Prompt con privilegi amministrativi elevati.

Eseguire il comando:

route -p add x.x.x.x mask y.y.y.y z.z.z.z

Dove:

  • x.x.x.x è l’indirizzo della subnet Azure a cui si desidera accedere
  • y.y.y.y è la relativa Subnet Mask
  • z.z.z.z è l’indirizzo IP del Veeam PN on-premise

Nel nostro caso:

route -p add 10.1.0.0 mask 255.225.255.0 192.168.1.94

Effettuare un tracert verso l’IP privato del Veeam PN su Azure.

Figura 34 – Tracert OK!

Vogliamo ora verificare di poter accedere anche al server collocato nella subnet Azure.

Il server ha come indirizzo privato 10.1.0.4 e non è raggiungibile (per regole di firewall) tramite il suo indirizzo IP pubblico.

Figura 35 – Rilevamento IP privato VM server su Azure

Proviamo ad accedere in RDP al server AZRSRV01 attraverso il suo IP privato 10.1.0.4.

Figura 36 – RDP OK!

WOW!

Instradamento automatico

Si noti che non è stato necessario modificare la routing table del server su Azure, grazie ad uan configurazione effettuata automaticamente dal Veeam PN con il ruolo Network Hub.

Accedere al portale amministrativo di Azure, fare clic su Resource Groups e poi sul nome del Resource Group in cui è stato collocato l’appliance Veeam PN.

Tra i vari elementi presenti, ne è elencato anche uno di tipo Route table.

Figura 37 – Route table creata da Veeam PN

Facendo clic su questo elemento si evidenza come sia stata automaticamente creata una route che inoltra attraverso l’host 10.1.0.5 (il Veeam PN) il traffico indirizzato verso la rete 192.168.1.0/24 (la subnet on-premise).

Tale route è applicata alla subnet su cui sono attestati sia l’appliance Veeam PN che il server AZRSRV01.

Figura 38 – Caratteristiche route table

Magia!

Conclusioni

In questo articolo abbiamo visto, passo per passo, come sia possibile, grazie ad un appliance gratuito realizzato da Veeam, realizzare una VPN site-to-site fra una sede aziendale e una subnet su Azure senza implicare modifiche agli apparati di networking esistenti o dover configurare un VPN Gateway su Azure.

Implementare Azure AD Domain Services

Facebooktwittergoogle_plusredditlinkedin

Gli Azure AD Domain Services permettono di poter aggiungere (joinare) macchine virtuali ad un dominio gestito senza la necessità di distribuire e manutenere i domain controller. Abilitando gli Azure AD Domain Services, verranno create in Azure due macchine virtuali che diventeranno i domain controller del dominio che vorrete creare. Queste due macchine saranno collegate ad una Azure Virtual Network (VNET) e sarà possibile aggiungere computer sia ospitati in macchine virtuali Azure sia ospitati on-premises, se la vostra rete virtuale è collegata in modalità Site-to-Site alla vostra infrastruttura aziendale. Per poter accedere alle applicazioni potrete utilizzare le vostre credenziali di Azure AD.

Sfruttando le funzionalità offerte, sarà possibile utilizzare LDAP, NTLM (NT LAN Manager) e l’autenticazione Kerberos, ampiamente usate nelle aziende, per eseguire la migrazione in Azure di applicazioni legacy compatibili con le directory.

Per abilitare le funzionalità di Azure AD Domain Services è necessario prima avere una directory di Azure AD (sincronizzata con una directory locale oppure solo cloud).

Una volta abilitata la funzionalità di Azure AD Domain Services sarà possibile eseguire i seguenti compiti amministrativi:

  • Aggiungere computer al dominio gestito.
  • Configurare le Group Policy per le unità organizzative (OU) “AADDC Computers” e “AADDC Users” nel dominio gestito.
  • Amministrare il DNS nel dominio gestito.
  • Creare e amministrare unità organizzative (OU) personalizzate nel dominio gestito.
  • Ottenere l’accesso amministrativo ai computer aggiunti al dominio gestito.

Privilegi amministrativi non disponibili in un dominio gestito

Il dominio viene gestito da Microsoft, incluse le attività quali applicazione di patch, monitoraggio ed esecuzione di backup. Il dominio è bloccato e non si hanno privilegi per eseguire alcune attività amministrative. Ecco alcuni esempi di attività che non è possibile eseguire:

  • Non vengono concessi privilegi di amministratore di dominio (Domain Admin) o amministratore dell’organizzazione (Enterprise Admin) per il dominio gestito.
  • Non è possibile estendere lo Schema del dominio gestito.
  • Non è possibile connettersi ai controller di dominio per il dominio gestito usando Desktop remoto.
  • Non è possibile aggiungere controller di dominio al dominio gestito.

Configurazione della directory di Azure

In questo articolo utilizzerò una directory di Azure che utilizza un dominio personalizzato chiamato “demolab.it”. Per aggiungere un dominio personalizzato alla vostra Azure Active Directory potete seguire le indicazioni contenute nell’articolo Aggiungere un nome di dominio personalizzato ad Azure Active Directory

Figura 1: Dominio personalizzato da utilizzare per gli Azure AD Domain Services

Poiché sto utilizzando un Directory esistente, ho anche alcuni gruppi ed alcuni utenti attivi. Agli utenti ho cambiato il logon name (username) in modo tale che utilizzino il dominio personalizzato “demolab.it”.

Figura 2: Utenti già esistenti in Azure AD

Abilitazione della funzionalità di Azure AD Domain Services

Dal portale di Azure scegliete di creare una nuova risorsa di tipo Azure AD Domain Services e scegliete quale sarà il DNS Domain Name che verrà utilizzato per creare il dominio gestito. Come già anticipato, io utilizzerò il dominio “demolab.it”. Indicate la sottoscrizione, il Resource Group e la Location dove creare le risorse.

Figura 3: Scelta del nome di dominio ce dovrà utilizzare Azure AD Domain Services

Nella schermata successiva scegliete a quale Virtual Network vorrete collegare i vostri Azure AD Domain Services ed il dominio gestito. Potete utilizzare una rete esistente oppure crearne una nuova. Nel mio caso ho deciso di creare una nuova rete virtuale.

Figura 4: Creazione di una nuova VNET da utilizzare con gli Azure AD Domain Services

Alla VNET verrà associato anche un Network Security Group, ottimizzato per proteggere gli Azure AD Domain Services.

Figura 5: Scelta della VNET e creazione di un Network Security Group associato

Nel passaggio successivo dovrete aggiungere gli utenti al gruppo AAD DC Administrators, uno speciale gruppo che avrà i privilegi nel dominio gestito che verrà creato. Questo gruppo verrà aggiunto al gruppo Administrators locale di tutte le macchine che verranno aggiunte al dominio gestito, come succede ai Domain Admins in Active Directory on-premises, e potranno connettersi in Desktop remoto alle macchine che verranno successivamente aggiunte (joinate) al dominio gestito.

NOTA: In un dominio gestito con Azure AD Domain Services non ci sono né Domain Admins né Enterprise Admins.

Figura 6: Aggiunta degli utenti al gruppo degli AAD DC Administrators

Controllate le configurazioni e cliccate su OK per completare la creazione degli Azure AD Domain Services. Ci vorranno circa 30 minuti per completare la creazione dei due domain controller.

Figura 7: Configurazione completata

Dopo circa 30 minuti sarà possibile verificare l’avvenuta creazione degli Azure AD Domain Services e sarà possibile aggiornare i DNS della vostra Virtual Network in modo tale che puntino agli indirizzi IP dei due domain controller creati per il dominio gestito. Cliccate su Configure e nel giro di pochi secondi la VNET verrà configurata automaticamente con i due IP da utilizzare per la risoluzione DNS.

Figura 8: Creazione completata e configurazione dei DNS

Infatti, se controllate le configurazioni della VNET vedrete che saranno stati modificati i server DNS.

Figura 9: Modifica dei server DNS della VNET compleltata

Nota: Durante il processo di provisioning, Azure AD Domain Services crea le applicazioni “Domain Controller Services” e “AzureActiveDirectoryDomainControllerServices” all’interno della directory dell’organizzazione. Queste applicazioni sono necessarie per far funzionare il dominio gestito ed è fondamentale che non vengono mai eliminate.

Figura 10: Applicazioni create per la gestione di Azure AD Domain Services

Connessione al dominio gestito

Per utilizzare il dominio gestito e per configurarlo è possibile creare una nuova VM e collegarla alla VNET utilizzata.

Figura 11: Creazione di una nuova VM per gestire Azure AD Domain Services

Terminata la creazione della VM potete collegarvi col le credenziali di amministratore locale che avete indicato al momento della creazione. Se controllate le configurazioni di rete della VM noterete che ha ottenuto i DNS corretti e quindi sarà capace di connettersi al dominio gestito “demolab.it”

Figura 12: La macchina virtuale ha ottenuto le configurazioni di rete corrette e può risolvere il nome del dominio gestito “demolab.it”

Per poter aggiungere la macchina al dominio gestito potete utilizzare le credenziali di un utente del gruppo AAD DC Administrators, come mostrato in figura:

Figura 13: aggiunta della VM al dominio gestito utilizzando le credenziali di un utente membro del gruppo AAD DC Administrators

Per autenticare gli utenti nel dominio gestito, Azure Active Directory Domain Services necessita dell’hash delle password in un formato idoneo per l’autenticazione NTLM e Kerberos. Azure AD non genera o archivia l’hash delle password nel formato necessario per l’autenticazione NTLM o Kerberos finché non si abilita Azure Active Directory Domain Services per il tenant. Per ovvi motivi di sicurezza, Azure AD non archivia nemmeno le credenziali di tipo password in un formato non crittografato. Azure AD quindi non può generare automaticamente questi hash delle password NTLM o Kerberos in base alle credenziali esistenti degli utenti.

Se avete configurato Azure AD per avere account utente solo cloud, tutti gli utenti che devono usare Azure Active Directory Domain Services devono cambiare le proprie password.

Se Azure Ad è sincronizzata con una directory on-premises (per mezzo di Azure AD Connect), è necessario abilitare la sincronizzazione degli hash NTLM e Kerberos per usare il dominio gestito. Fate riferimento all’articolo Abilitare la sincronizzazione password nel dominio gestito per gli account utente sincronizzati con l’istanza locale di AD per abilitare la sincronizzazione degli hash delle password.

Poiché l’utente che sto utilizzando per aggiungere la macchina virtuale al dominio gestito “demolab.it” era già presente in Azure AD (nel mio caso è solo Cloud) prima della creazione degli Azure AD Domain Services, non riesco a joinare la macchina al dominio gestito e ricevo un messaggio di errore (in realtà non chiarissimo).

Figura 14:Messaggio di errore dovuto alla mancanza di un hash delle password in formato corretto

Procedo quindi al cambiamento della password per l’utente admin@demolab.it, che avevo aggiunto al gruppo AAD DC Administrators. Il processo di modifica delle password determina la generazione in Azure AD degli hash delle password richiesti da Azure Active Directory Domain Services per l’autenticazione Kerberos e NTLM. È possibile impostare come scadute le password per tutti gli utenti del tenant che devono usare Azure Active Directory Domain Services oppure richiedere a tali utenti di cambiare le proprie password.

In questo caso mi sono collegato alla pagina https://mypass.microsoft.com e ho cambiato la password dell’utente admin@demolab.it, che stavo utilizzando per joinare la VM al dominio gestito.

Figura 15: Modifica della password dell’utente del gruppo AAD DC Administrators che stavo utilizzando per joinare la VM al dominio gestito

Dopo circa 20 minuti dalla modifica, la nuova password è utilizzabile in Azure Active Directory Domain Services. Ho riprovato ad aggiungere la VM al dominio gestito e questa volta non ho ricevuto nessun errore.

Figura 16: Dopo la modifica della password e l’attesa di qualche minuto, il join al dominio gestito avviene senza problemi

Gestione di Azure AD Domain Services

Adesso che avete aggiunto la VM al dominio gestito potete installare le console per la gestione. Io ho aggiunto la Group Policy Console, tutti gli AD DS Tools ed anche la console per la gestione del DNS.

Figura 17: Aggiunta degli strumento di amministrazione

Come si può vedere nelle schermate successive, è ora possibile amministrare il dominio gestito. Potete utilizzare la console Active Directory Users and Computers, L’Active Directory Administrative Center oppure AD PowerShell.

Figura 18: Console Active Directory Users and Computers e visualizzazione dei Domain Controllers del dominio gestito

Nella OU AADDC Users potrete vedere tutti gli utenti che avere creato in Azure AD (sia che siano solo cloud, sia che siano sincronizzati con Active Directory on-premises). Si può notare che i pulsanti di creazione dei nuovi utenti e dei nuovi gruppi non sono abilitati. La gestione degli utenti dovrà continuare ad essere effettuata da Azure AD.

Figura 19: Utenti del dominio gestito, gli stessi presenti in Azure AD

Per creare un nuovo utente o un nuovo gruppo dovete collegarvi al Portale di Azure e effettuare l’operazione dal nodo Azure Active Directory. Come già detto prima, siate pazienti perché ci vorranno circa 20 minuti per sincronizzare Azure AD con Azure AD Domain Services e per vedere il nuovo utente apparire nella console di Active Directory Users and Computers.

Figura 20: Utenti di Azure AD

Per amministrare il DNS potete invece collegarvi ad uno dei domain controller che sono stati creati nel dominio gestito (recuperate i nomi nella OU dei DC)), come mostrato in figura:

Figura 21: Console di gestione del DNS

È possibile utilizzare la console Group Policy Management nella macchina virtuale aggiunta al dominio per amministrare le Group Policy (GPO) nel dominio gestito, a patto che siate membri del gruppo AAD DC Administrators.

Sono presenti diverse GPO nel dominio gestito, tra cui la Default Domain Policy, AADDC Computers GPO e AADDC users GPO. È possibile personalizzare queste GPO o crearne delle altre. Io ho creato una nuova Organizational Unit (OU) e una nuova Group policy (GPO), come mostrato in figura:

Figura 22: Console di gestione delle GPO del dominio gestito

Conclusioni

Molto spesso in azienda si usano applicazioni che usano LDAP per l’accesso in lettura o scrittura alla directory aziendale oppure usano l’autenticazione integrata di Windows (autenticazione NTLM o Kerberos) per autenticare gli utenti finali. Per spostare le applicazioni locali nel cloud, è necessario risolvere le dipendenze da Active Directory. Spesso gli amministratori adottano una delle soluzioni seguenti:

  • Creano una connessione VPN da sito a sito tra Azure e l’infrastruttura on-premises.
  • Creano un domain controller aggiuntivo dell’Active Directory aziendale in una VM di Azure
  • Creano in Azure un dominio separato, utilizzando una o più VM promosse a domain controller

Tutti questi approcci tuttavia prevedono costi elevati e un carico di lavoro amministrativo significativo. Gli amministratori devono distribuire i controller di dominio tramite macchine virtuali in Azure. In più, devono gestire, proteggere, applicare patch, monitorare, eseguire il backup e risolvere i problemi relativi a tali macchine virtuali. L’utilizzo di connessioni VPN alla directory locale rende i carichi di lavoro distribuiti in Azure suscettibili a errori o interruzioni di rete temporanee.

Azure Active Directory Domain Services è pensata per offrire un’alternativa più semplice.

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

Facebooktwittergoogle_plusredditlinkedin

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

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

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

Creazione del Service Principal (Registered App)

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

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

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

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

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

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

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

Figure 4: Generazione della chiave completata

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

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

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

Installazione dell’estensione Let’s Encrypt

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

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

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

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

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

Figure 8: Accettazione dei termini legali di utilizzo

L’estensione sarà subito visibile tra quelle installate

Figure 9: Installazione dell’estensione completata

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

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

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

Figure 11: Creazione del WebJob nella Web App

Configurazione dell’estensione di Azure Let’s Encrypt

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

Figure 12: Configurazione dell’estensione

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

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

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

Figure 14: Prima richiesta del certificato

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

Aggiunta di un host name per il Custom Domain

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

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

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

Figure 17: Il wizard ha riconosciuto gli hostname personalizzati

Figure 18: Scelta del nome host per cui richiedereil certificato

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

Figure 19: Creazione del certificato completata

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

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

Conclusioni

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

Creare VM in Azure utilizzando VHD personalizzati

Facebooktwittergoogle_plusredditlinkedin

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

Preparazione del disco della macchina virtuale

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

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

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

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

Figura 2: Generalizzazione dell’immagine con il comando SYSPREP

Upload del disco VHD in uno Storage Account di Azure

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

Figura 3: Creazione di un nuovo Storage Account

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

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

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

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

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

Figura 5: Connessione ad Azure Storage

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

Figura 6: Caricamento del VHD nel BLOB Container

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

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

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

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

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

Figura 8: VHD personalizzato caricato nell’account di archiviazione

Creazione di una Managed Image utilizzando un VHD personalizzato

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

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

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

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

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

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

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

Figura 11: Creazione dell’immagine completata

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

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

#Connessione all’Azure Account

Connect-AzureRmAccount

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

$imageConfig New-AzureRmImageConfig -Location “West Europe”

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

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

Figura 12: Creazione dell’immagine personalizzata da PowerShell

Creazione della VM utilizzando un’immagine personalizzata

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

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

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

#Creazione della VM

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

Figura 14: Creazione della Azure VM da PowerShell comletata

Conclusioni

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

Implementare Azure AD password protection per Windows Server Active Directory

Facebooktwittergoogle_plusredditlinkedin

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

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

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

Azure AD password protection

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

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

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

Figura 1: Personalizzazione delle configurazioni di Azure AD Password Protection

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

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

Utilizzare Azure AD password protection in Windows Server Active Directory

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

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

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

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

Installazione del software

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

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

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

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

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

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

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

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

Figura 8: Azure AD password protection proxy – License Agreement

Figura 9: Azure AD password protection proxy – Avvio servizi

Figura 10: Azure AD password protection proxy – Installazione completata

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

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

Verifica della funzionalità di Azure AD Password protection

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

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

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

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

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

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

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

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

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

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

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

Figura 18: Reportistica tramite PowerShell

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

Conclusioni

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

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

Facebooktwittergoogle_plusredditlinkedin

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

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

Figura 1: Principio di funzionamento delle Region di Azure

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

Azure Managed Disks

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

Dischi basati su Storage Account

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

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

Availability Zones

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

Figura 2: Availabily Zones nelle Region di Azure

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

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

E solo per questi servizi:

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

Creazione di una macchina virtuale in una Availability Zone

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

Figura 3: Creazione di una nuova VM in Azure

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

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

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

Figura 5: Spiegazione sulle funzionalità offerte dalla Availability Zone

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

Figura 6: Scelta della Availabilty Zone

Figura 7: Creazione della VM completata

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

Creazione di una macchina virtuale in una Availability Zone utilizzando PowerShell

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

Figura 9: verifica delle Availability Zone nella Region scelta

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

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

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

Figura 11: Creazione della VM completata

Conclusioni

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

Migrazione dei dischi delle macchine virtuali in Azure a Managed Disks

Facebooktwittergoogle_plusredditlinkedin

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

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

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

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

Migrazione dei dischi delle VM esistenti

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

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

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

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

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

Figura 4: Migrazione dei dischi della VM a Managed Disks

Figura 5: Operazione di migrazione dei dischi in corso

Figura 6: Migrazione dei dischi completata

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

Conversione tramite Azure Powershell

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

Figura 7: Aggiornamento del modulo PowerShell di AzureRM

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

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

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

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

Figura 8: Conversione dei dischi tramite PowerShell

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

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

$avSetName ‘mioAvailabilitySet’

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

Update-AzureRmAvailabilitySet -AvailabilitySet $avSet -Sku Aligned

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

{

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

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

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

}

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

Problematiche nella migrazione

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

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

Figura 11: Rimozione dell’estensione effettuata a macchina accesa

Conclusioni

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

Buon lavoro!

Nic

GitLab si sposta da Azure a GoogleCloud

Facebooktwittergoogle_plusredditlinkedin

Appena dato l’annuncio dell’acquisizione da parte di Microsoft di GitHub, la paura, o anche solo l’antipatia, verso il nuovo padrone hanno creato una migrazione di massa: abbiamo assistito ad una vero e proprio esodo dei progetti ospitati. E molti hanno scelto il principale concorrente: GitLab.

Pochi, però forse, sanno che GitLab a sua volta si appoggia all’infrastruttura cloud di Microsoft, Azure: se l’obbiettivo era scappare dal nuovo padrone, in realtà ci si stava consegnando volontariamente, sebbene indirettamente.

Ecco perché l’annuncio del 25 Giugno fatto da GitLab potrebbe avere un risalto particolare: dal 28 Luglio (o giù di lì) lo stesso sarà migrato su piattaforma Google Cloud abbandonando Azure.
Il tempismo potrebbe essere sospetto, quasi ad arte, ma per poter migrare un portale ampio come GitLab serve tempo e preparazione: più di 200 TB di dati dei repository e 2 TB di database, il tutto a caldo, ovvero lasciando il sito principale attivo ed aperto all’uso durante tutto il processo.
Per permettere clonazione e sincronizzazione di sito primario (Azure) e secondario (Google) viene usato Geo, una tecnologia sviluppata da GitLab proprio per questi scopi e per cui questa migrazione rappresenta un test sul campo particolarmente gravoso ma interessante.

La motivazione principale può essere riassiunta in Kubernetes: in GitLab pensano che questa tecnologia sia l’unico modo per garantire il servizio ed aumentare la scalabilità dello stesso. E chi meglio di chi ha inventato Kubernetes per usarlo?
In parallelo GitLab cambierà anche la tecnologia di storage utilizzato, passando dal “solito” filesystem (NFS, considerato un single-point-of-failure) ad un sistema ad oggetti (il più famoso è S3 di Amazon, ma non è l’unico). Anche questo passaggio non è banale, e la sicurezza di non tralasciare nulla richiederà una certa cura.

Per chi volesse seguire da vicino i lavori è disponibile una pagina con tutti i dettagli del processo (ovviamente un repository Git su GitLab), da cui abbiamo conferma che il lavoro è stato avviato ben prima dell’acquisizione di GitHub (almeno 4 mesi fa). A voler essere cattivi, potremmo far notare che questo non implica non sia stato accelerato, però.