Fusion Inventory è un progetto Open Source francese nato nel 2010 durante il FOSDEM meeting con l’obbiettivo di fornire una migliore integrazione tra differenti progetti di asset management come OCS Inventory, GLPI e GOSA. Come riportato nell’Overview al momento Fusion Inventory è in grado gestire l’inventario dei seguenti device:

• Computers
• Network devices
• Printers
• Virtual machines (VMware vCenter/ESX/ESXi, Virtualbox, Libvirt, Xen, OpenVZ/Virtuozzo, Parallels, LXC, FreeBSD Jails, HPVM, Vserver, Hyper-V)
• Android phone

Inoltre può inviare comandi Wake on Lan e gestire l’installazione, update e la rimozione di software su OS Windows, OS X, Linux e*BSD.

Di seguito lo schema di funzionamento di Fusion Inventory che sfrutta SNMP, WMI il registro di Windows per gestire l’inventario hardware e software dei dispositivi:

Mentre nel seguente schema viene illustrata l’integrazione di Fusion Inventory con GLPI basata sull’Agent distribuito sui computer e sul Plugin installato su GLPI:

In questo articolo verranno analizzati gli aspetti relativi all’installazione del plugin e relativa configurazione per l’import dei dispositivi e l’installazione e la configurazione dell’Agent in ambiente Windows.

Installazione del plugin per FusionInventory in GLPI

La prima operazione da eseguire per utilizzare l’agent di FusionInventory in GLPI è quella di installare il plugin che può essere scaricato da GitHub al seguente link https://github.com/fusioninventory/fusioninventory-for-glpi/releases. Al momento l’ultima release compatibile con GLPI 9.2 è la 9.2+1.0.

Se occorre aggiornare il plugin occorre prima disattivarlo in GLPI tramite il menù Configurazione/Plugin quindi rimuovere la cartella plugins/fusioninventory in GLPI per rimuovere i file deprecati e infine si procede come per una normale installazione. Il plugin non va disinstallato in quanto questo causerebbe la perdita dei dati FusionInventory.

Per installare il plugin occorre scompattare il package, ad esempio con 7zip, quindi copiare la cartella fusioninventory nella cartella plugins di GLPI, per maggior sicurezza eseguire una copia di backup del database di GLPI.

Terminata la copia dei file del plugin occorre installarlo e attivarlo tramite menù Configurazione/Plugin.

Configurazione inziale del plugin per FusionInventory in GLPI

Affinchè l’agent di FusionInventory possa funzionare occorre configurare il plugin specificando il Link d’accesso al servizio tramite il menu Amministrazione/Entità/Root entity/Fusioninventory, l’impostazione di default è https://localhost/glpi.

Dopo l’installazione del plugin, se non è già stato fatto, occorre configurare la gestione delle operazioni pianificate in caso contrario l’interfaccia di GLPI visualizzerà l’errore “GLPI cron not running“, per rimuover il warnig occorre creare una operazione pianificata eseguita ad intervalli compresi tra 1 e 5 minuti che avvii il seguente comando (a riguardo si veda Cron for GLPI and for FusionInventory):

“PathPHP\php.exe” -f PathGLPI\glpi\front\cron.php

Le opzioni di configurazione del plugin sono disponibili tramite il menu Amministrazione/FusionInventory/Generale/Impostazioni generali e sono suddivise nei seguenti gruppi:

• Configurazione generale in cui è possibile impostare la porta TCP dell’Agent e l’utilizzo di SSL per la comunicazione con l’Agent che permette di mettere in sicurezza le informazioni scambiate, a riguardo si veda la sezione Security della documentazione di FusionInventory.
• Inventario dei computer in cui è possibile definire quali informazioni del computeri verranno raccolte dall’Agent
• Inventorio di rete in cui è possibile definire quali informazioni dei dispositivi di rete verranno raccolte dall’Agent tramite SNMP
• Gestione pacchetto in cui è possibile configurare come gestire come vengono inviati i dati al server da parte del’Agent
• Moduli degli agenti in cui è possibile configurare le azioni che possono essere eseguite dall’Agent
• Blocchi in cui è possibile bloccare l’aggiornamento di alcuni campi di Computer, Stampanti e Periferica di rete da parte dell’Agent per evitare che vengano sovrascritte informazioni che si preferisce gestire manualmente

Tramite il menù Amministrazione/FusionInventory/Regole/
Equipment import and link rules è possibile gestire come importare dispositivi Computer, Printer e Network Equipment, Peripheral, Monitor, Phone, in modo da indentificare apparati in modo univoco secondo regole basate su seriale, UUID, nome, MAC o a combinazioni di questi identificativi.

Lo UUID(Universally unique identifier) è un identificatore di 128-bit che rispetta l’RFC4122 esposto dalla classe wmi Win32_ComputerSystemProduct che a sua volta ricava il valore dalla struttura System Information relativa alle informazioni SMBIOS, a riguardo si veda System Management BIOS su Wikipedia. E’ possibile ricavare lo UUID di un computer trami il seguente comando PowerShell:

Get-WmiObject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID

E’ possibile modificare, aggiungere, abilitare/disabilitare e variale l’ordine di applicazione delle rule, a riguardo si veda How to work ‘Equipment import and link rules’.

Di seguito un esempio di configurazione delle rule per un asset di tipo computer:

• la rule Computer constraint (name) nega l’importazione nel caso non esista un nome
• le rule Computer update (by uuid), Computer update (by name), Computer import (by uuid), Computer import (by name) aggiornano e se necessario creano l’asset computer identificandolo prima tramite l’UUID e poi tramite il nome
• La rule Computer import denied blocca l’importazione se le rule precedenti non sono soddisfatte

L’elenco delle rule termina con le rule Global che definiscono come gestire importazione e aggiornamento degli asset non classicabili come Computer, Printer e Network Equipment, Peripheral, Monitor, Phone. Inoltre tramite il pulsante Verifica gestire delle regole è possibile eseguire un test di funzionamento delle regole.

Inoltre l’importazione e la creazione dei dispositivi è ulteriormente configurabile tramite i seguenti gruppi di rule disponibili tramite il menù Amministrazione/FusionInventory/Regole:

• Ignored import devices
• Computer entity rules
• Computer location rules
• Computer information rules
• Blacklist

Installazione dell’Agent come servizio in ambiente Windows

La prima opzione d’installazione è quella di installare sui computer utilizzando gli installer a 32 bit o 64 bit a seconda del versione del sistema operativo, al momento è disponibile la versione 2.4 dell’agente scaricabile da GitHub al seguente link https://github.com/fusioninventory/fusioninventory-agent/releases.

Di seguito i passi di installazione, le opzioni e le configurazioni richieste dal setup d’installazione, per informazioni sull’installare, l’installazione massiva l’installazione silente e le opzioni a riga di comando dell’installer si vedano:

• Microsoft Windows Installation
• Windows installer 2.3.x visual mode
• Windows large installation
• Windows installer 2.3.x command-line

Per i dettagli sui passi d’installazione si veda Windows installer 2.3.x visual mode, l’installer prevede le seguenti possibilità ed opzioni di configurazione.

Scelta della lingua d’installazione, al momento sono disponibili le lingue Inglese, Francese e Spagnolo:

Scelta dei componenti da installare, al moneto sono disponibili i seguenti componenti:

• Collect (registry query, WMI query e search file)
• Deploy (software deploy)
• ESX (ESX remote inventory)
• Inventory
• NetDiscovery (network discovery)
• NetInventory (network inventory tramite SNMP)
• WakeOnLan (wake on lan)

Impostazione del path locale dei risultati e dell’URL dei server GLPI o OCS a cui inviare i risultati

Impostazione della modalità di esecuzione, al momento è possibile configurare l’agente per essere eseguito come servizio, operazione pianificata o manuale:

Se viene selezionato la modalità di esecuzione Servizio è possibile configurare il server web locale che verrà installato per consentire il monitoraggio remoto del servizio:

Se viene selezionato la modalità di esecuzione operazione pianificata è possibile configurare la frequenza e l’intervallo orario di esecuzione:

Configurazione delle opzioni di esecuzione e delle opzioni avanzate di configurazione e di log

Al momento non è disponibile il file msi per la distribuzione tramite Group Policy, ma è possibile eseguire l’installazione tramite uno script di avvio computer di questo tipo sfruttando le opzioni a riga di comando dell’installer:

%SystemDrive%
cd %ProgramFiles%
if exist FusionInventory-Agent goto end
\\share\fusioninventory-agent_windows-x64_2.4.exe /acceptlicense /S /server=’http://serverGLPI/glpi/plugins/fusioninventory/’ /runnow
:end

Installazione in modalità portable dell’Agent in ambiente Windows

Se non si intende installare l’agent è anche possibile utilizzare la modalità di installazione portable utilizzando il package a 32 bit o 64 bit a seconda del versione del sistema operativo, al momento è disponibile la versione 2.4 dell’agente scaricabile da GitHub al seguente link https://github.com/fusioninventory/fusioninventory-agent/releases. Tramite la modalità portable è possibile scompattare l’agent senza necessità di avere privilegi amministrativi.

Per eseguire l’Agent sono già disponibili i seguenti script:

• fusioninventory-agent.bat per eseguire l’agent che a sua volta può eseguire vari task tra cui l’inventario, deployment di software o il network discovery si in modo autonomo o in combinazione con un server di gestione compatibile come GLPI, OCS o OTRS (per dettagli si veda fusioninventory-agent)
• fusioninventory-esx.bat per eseguire l’inventario di ESX/ESXi e vCenter VMware remoti tramite l’interfaccia SOAP (per dettagli si veda fusioninventory-esx)
• fusioninventory-injector.bat per eseguire test, benchmark o eseguire il push dell’inventario da macchine off-line (per dettagli si veda fusioninventory-injector)
• fusioninventory-inventory.bat per eseguire un task di inventario in modo autonomo senza necessità di un server GLPI (per dettagli si veda fusioninventory-inventory)
• fusioninventory-netdiscovery.bat per eseguire un discovery su di un network range tramite SNMP versione 1 (per dettagli si veda fusioninventory-netdiscovery)
• fusioninventory-netinventory.bat per eseguire l’inventario su un device di rete tramite SNMP versione 2c (per dettagli si veda fusioninventory-netinventory)
• fusioninventory-wakeonlan.bat per eseguire un task wakeonlan in modo autonomo senza necessità di un server GLPI (per dettagli si veda fusioninventory-wakeonlan)
• fusioninventory-wmi.bat per creare l’inventario di una macchina remota Win32 tramite l’interfaccia WMI

L’agent in modalità portable può comunque essere distribuito tramite le Group Policy Preferences per copiare sul client i file dell’Agent ed avviarlo in modo automatico ad esempio tramite un’operazione schedulata.

Configurazione dell’Agent

L’agent si può configurare tramite file di configurazione in /etc/agent.cfg o tramite registry tramite la chiave HKEY_LOCAL_MACHINE\SOFTWARE\FusionInventory-Agent o nel caso di agent a 32 bit su un sistema a 64 bit tramite la chiave KEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\FusionInventory-Agent, a riguardo si vedano:

• Agent configuration
• Agent man pages
• agent.cfg

Per quanto riguarda la configurazione tramite registro è possibile utilizzare le stesse voci di configurazione del file agent.cfg creando nelle chiave di registro i relativi valori di tipo string (REG_SZ), di seguito un esempio di configurazione che imposta il server GLPI (chiave server), esclude dal rilevamento le i dispositivi categorizzati come stampanti, monitor, video, storage, usb:

Conclusioni

L’utilizzo di Fusion Inventory in combinazione con GLPI consente di gestire l’inventario o parte di esso in modo automatizzato, ovviamente negli scenari in cui parte dell’inventario viene gestito manualmente occorre configurare opportunamente quali dati devono essere raccolti. Si pensi ad esempio al caso in cui i computer vengono acquistati e inventariati e solo dopo connessi in rete, inoltre in molti casi le informazioni che Fusion Inventory raccoglie potrebbero essere non così consistenti, si pensi ad esempio alla marca e modello che Fusion Inventory determina in base a quanto rileva sul sistema tramite wmi e chiavi di registro e quindi non sempre il produttore mantiene sempre le stesse diciture con l’avvicendarsi delle versioni software.

Un altro aspetto da tenere presente è che ne caso si elimina un asset computer occorre eliminarlo anche dal cestino di GLPI in caso contrario se Fusion Inventory rileva in rete un computer che risponde ai requisiti di indentificazione tramite nome, numero di serie, etc. connette le informazioni al primo asset che rispetta la query di identificazione indipendentemente che sia o meno nel cestino di GLPI causando quindi una conseguente impossibilità nel reperire le informazioni raccolte i n quanto gli asset nel cestino non vengono visualizzati.

Glpi è, come abbiamo visto un prodotto completo ed estendibile tramite vari plug-in, ad esempio FusionInventory consente di realizzare partendo da GLPI un valido sistema di Sw ed Hw inventory aziendale. Abbiamo anche scritto una guida su come Integrare FusionInventory con GLPI v9.2.1 in ambiente Windows.

Recentemente la normativa AgID “Misure Minime di Sicurezza ICT” per la Pubblica Amministrazione ha imposto tra le varie implementazioni, anche l’adozione di un inventory automatico del Software intallato. GLPI e l’estensione FusionInventory permettono in modo assolutamente economico e perfettamente automatico di implementare questa funzione, e non avendo in questo caso, la necessità di utilizzare altre funzionalità proprie di GLPI, vediamo come è possibile gestirne l’interfaccia utente in modo da permettere la sola consultazione richiesta.

GLPI presenta la possibilità di “modellare” l’interfaccia dei vari utenti che accedono in modo da presentare ad ognuno esclusivamente le funzioni necessarie. E’ quindi possibile impostare esclusivamente in consultazione le funzioni di inventario messe a disposizione con FusionInventory.

Il punto di partenza è chiaramente l’utente di GLPI che può essere locale oppure riferito ad una sorgente di autenticazione esterna ad esempio Active Directory, in GLPI ad ogni utente deve essere assegnato un profilo in modo da poter completare il processo di login, ed è all’interno delle impostazioni del profilo che possiamo definire con precisione le funzioni, o per meglio dire in questo caso, le visualizzazioni consentite.

Nell’esempio che proponiamo viene creato un profilo “Consultazione HW/SW” con il solo accesso all’inventario di Hardware, Software ed alla visualizzazione delle impostazioni del plugin di FusionInventory

Creazione del profilo

Dal menù di amministrazione nella sezione profili troviamo l’elenco di tutti i quelli esistenti, alcuni di questi sono presenti di default già dall’installazione. Nelle caratteristiche di base del profilo possiamo specificare se gli utenti avranno un’interfaccia semplificata oppure standard, per la quale è possibile ulteriormente definire i campi visualizzati.

Figura 1 pagina profili

Dalla Pagina Principale/Amministrazione/Profili tramite il tasto “+” si può creare il nuovo profilo.

Figura 2creazione profilo

E’ possibile fare sì che il profilo sia dichiarato come “Predefinito”, in questo caso verrà applicato di default ad ogni nuovo utente aggiunto a GLPI, e se è abilitata la possibilità di Self-Provisioning, ogni utente ( se presente in Active Directory ) potrà accedere a GLPI senza ulteriori profilazioni. Verrà quindi autenticato, creato e profilato all’atto del primo accesso.

Di Default GLPI durante l’installazione crea il profilo Self-Service come predefinito e sempre per impostazione predefinita tutti gli utenti oggetto di autenticazione esterna, possono collegarsi. Normalmente, anche per ragioni di sicurezza, è utile non definire alcun profilo come predefinito e disattivare l’impostazione di auto configurazione degli utenti esterni.

Proseguendo nella creazione del profilo si definisce il nome, se deve essere applicato di default ai nuovi utenti, e quale interfaccia di base applicare.

Nell’esempio sono riportate le informazioni corrette al fine di consentire le impostazioni di consultazione per FusionInventory, proseguendo con “Aggiungi” si apre una pagina ulteriore che riporta tutte le varie componenti consultabili ed eventualmente modificabili dagli utenti, l’ultima colonna a destra è utile per l’impostazione rapida di tutti i permessi su ogni asset.

Figura 3 selezione dei permessi

A questo punto è sufficiente selezionare il componente da visualizzare e le azioni permesse per il profilo, per il Plugin FusionInventory potremmo anche non attivare nessuna visualizzazione in quanto è GLPI dalla pagina Asset che riporta gli inventari fatti dagli agent installati, tuttavia è possibile permettere agli utenti la sola visualizzazione delle impostazioni del Plugin attivando i permessi di lettura come riportato sotto.

Terminata l’impostazione del profilo è sufficiente associarlo agli utenti interessati, accedendo al menu Amministrazione dopo aver selezionato il/gli utenti voluti, tramite il menu Azioni è possibile applicare il nuovo profilo.

Figura 4attribuzione dei permessi ad un utente

Nell’esempio descritto in questa guida la possibilità di consultazione per l’utente sarà quindi ridotta alle sole visualizzazioni di Computer (inteso come Hardware) e Software.

Figura 5 accesso ad una pagina ridotta

Considerazioni: la nuova normativa AgID citata in precedenza “impone” a tutta la P.A. una serie di obblighi al fine dell’adeguamento ad uno standard minimo di sicurezza. Alcune di queste implementazioni non hanno ( o quasi ) alternative di tipo Open-Source, la soluzione di inventory ha, come abbiamo visto la possibilità di essere implementata a costo zero, permettendo quindi di impiegare in modo più incisivo le sovente esigue risorse economiche disponibili.

Riferimenti:

Installazione GLPI v9.1.4 in ambiente Windows

Installazione di GLPI 9.2.0 in ambiente Linux

Gestione backup GLPI v9.1.4 in ambiente Windows

Configurazione autenticazione Windows in GLPI v9.1.4

Integrazione FusionInventory con GLPI v9.2.1 in ambiente Windows

http://fusioninventory.org/

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

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

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

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

esempi di certificati per uno stesso dominio ma per host differenti

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

esempi di certificati per host in domini differenti.

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

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

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

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

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

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

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

New name

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

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

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

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

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

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

Figura 1 richiesta certificato

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

Figura 2 Impostazioni per la validazione

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

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

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

Figura 3importazione certificato in IIS

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

Importazione del certificato in Exchange

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

Metodi di validazione alternativi

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

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

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

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

Figura 4 validazione tramite DNS

Figura 5 certificato SAN

Considerazioni

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

Riferimenti

https://letsencrypt.org/

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

Come facilmente immaginabile, anche nelle ultime build di Windows 10 del programma Insider ci sono novità importanti che riguardano il componente Windows Subsystem for Linux. Ricordiamo che il programma Insider permette di testare in anteprima le ultime novità del sistema operativo Windows 10 anche con grande anticipo rispetto al rilascio ufficiale, quindi tutto ciò che leggerete in questo articolo sarà sicuramente parte integrante della prossima versione di Windows 10, conosciuta per ora con il nome RS4 o 1803. Riguardo alla funzionalità Windows Subsystem for Linux la componente che ha subito il cambiamento più importante è sicuramente il sistema di gestione dei permessi, che già dalla build 17063 ha visto un upgrade fondamentale; è stata poi aggiunta la possibilità di configurare attraverso un file di testo una serie di parametri da passare alla shell linux al momento dell’apertura.

La gestione dei permessi è sicuramente una delle caratteristiche più difficili da gestire nell’interazione tra Windows e WSL, poiché l’idea di avere un unico sistema su cui utilizzare indifferentemente comandi ed applicazioni Windows e Linux si scontra con le profonde differenze che ci sono tra i due sistemi da questo punto di vista. A segnare i confini tra un sistema e l’altro è sicuramente il filesystem, poiché l’NTFS di Windows non contempla l’esistenza dei “permission bits”, che sono invece alla base della gestione dei permessi sotto linux. Non mi dilungherò troppo nel dettaglio sulla gestione dell’accesso a file e cartelle da parte di linux; se qualcuno volesse approfondire questo argomento riporto un articolo molto esaustivo dal sito linux.com (https://www.linux.com/learn/understanding-linux-file-permissions).

Per risolvere questo limite WSL supporta il filesystem DrvFs che, attraverso una sorta di “plugin”, permette di salvare per ogni file una serie di metadati, all’interno dei quali sono memorizzate le informazioni circa proprietà e permessi così come li troveremmo su un sistema Linux.

Gestione dei permessi

Prima della build 17063 i files presenti sul filesystem Windows, risultavano tutti appartenere all’utente root e con permessi di lettura/scrittura abilitati, ed eventuali comandi chown e chmod per cambiarne la proprietà o i permessi non sortivano effetti, pur non restituendo errori. A partire da questa build, invece, è stato introdotto il supporto ai permission bits e al cambio di proprietario di files e cartelle, sia all’interno del filesystem nella distribuzione linux emulata, sia all’interno del filesystem Windows montato.

Notiamo immediatamente che eseguendo il comando

ls -al

nella home del nostro utente predefinito vediamo che il proprietario dei files è proprio il nostro utente (in questo caso chiamato gnanoia)

E’ possibile, inoltre, utilizzare il comando chown per modificare il proprietario di file e cartelle, e chmod per modificare i permission bits. Vediamo nello screenshot seguente come abbiamo creato un file di testo con l’utente root e ne abbiamo cambiato proprietà e permessi.

Per consentire il cambio dei permessi nel filesystem DrvFS, cioè nel filesystem Windows montato sulla distribuzione linux, è necessario aggiungere nell’opzione mount il paramentro -o metadata. Questo farà si che ogni file e cartella porti con sé un file (nascosto all’utente) all’interno del quale sono indicati i permessi così come li vedrebbe un sistema operativo linux.

All’apertura della shell bash, poiché il filesystem è montato di default senza il parametro metadata, sarà necessario prima smontarlo per poterlo rimontare con le opzioni corrette. Smontiamo quindi la partizione c: con:

sudo umount /mnt/c

e la montiamo con:

sudo mount -t drvfs C: /mnt/c -o metadata

Da questo momento in poi i comandi chown e chmod avranno effetto anche sui file della nostra partizione C: di Windows. Cambiare i permessi dall’interno della shell linux, tuttavia, non avrà effetto sull’accesso a questi file relativamente al sistema operativo Windows.

Configurazione automatica di wsl

Come accennato all’inizio di questo articolo a partire dalla build 17093 è possibile passare a WSL alcuni parametri per la configurazione della bash al momento dell’apertura. Proprio come indicato in precedenza, quindi, possiamo indicare a WSL di montare l’unità C di Windows utilizzando il supporto ai metadati già in fase di apertura, in modo da non dover smontare l’unità e rimontarla con le apposite opzioni ad ogni utilizzo.

Tutte le configurazioni vanno passate a WSL attraverso un file di testo chiamato wsl.conf che va posizionato all’interno della cartella /etc della distribuzione linux da utilizzare. Il file di esempio seguente consente appunto di montare l’unità C con il supporto ai metadati, in modo da utilizzare anche in questa partizione la gestione dei permessi di linux.

[automount]

enabled = true

root = /windir/

options = "metadata,umask=22,fmask=11"

mountFsTab = false

Vediamo infatti come all’apertura dell’app Ubuntu lanciando il comando mount è possibile notare il supporto ai metadati attivo sull’unità C:

Per-directory case sentitivity

La build 17110 introduce un’altra novità molto interessante per l’interoperabilità tra Windows e WSL: la gestione dei nomi di file e cartelle in modo case sensitive. Chi usa linux abitualmente sa benissimo che i nomi di files e cartelle sono case sensitive e quindi due nomi scritti con maiuscole e minuscole differenti identificano di fatto due file diversi, a differenza degli utenti Windows che non danno nessuna importanza al tipo di lettere utilizzate. Dovendo gestire, quindi, su un unico sistema sia Windows che Linux questo aspetto è uno di quelli che pensavamo avrebbe fatto la differenza tra un linux “vero” ed uno gestito da WSL. Windows 10 in realtà è sempre stato in grado di distinguere i file utilizzando il metodo case sensitive; passando alla syscall Createfile il parametro FILE_FLAG_POSIX_SEMANTICS, il sistema operativo è in grado di gestire lettere maiuscole e minuscole in maniera differente. Questa possibilità è gestita da una chiave di registro, che in maniera globale permette al sistema di riconoscere e dare un diverso significato alle lettere maiuscole e minuscole all’interno dei nomi dei file; modificando questa chiave, però, si ottiene spesso un effetto distruttivo poiché le applicazioni non sono fatte per supportare questa funzionalità.

WSL da sempre è in grado di bypassare il controllo di questa chiave e gestire i nomi dei file indipendentemente da Windows, così file e cartelle presenti nel filesystem linux sono sempre case sensitive.

A partire dalla build 17110, però, possiamo estendere questa possibilità anche alle cartelle presenti sul filesystem Windows, utilizzando il comando fsutil.exe

In particolare possiamo abilitare e disabilitare il supporto ai nomi Case Sensitive da Windows rispettivamente con i seguenti comandi da eseguire su un prompt con privilegi elevati:

fsutil.exe file setCaseSensitiveInfo <path> enable

fsutil.exe file setCaseSensitiveInfo <path> disable

Per integrare questo supporto su WSL sarà necessario inserire il parametro case=dir tra le opzioni del comando mount.

E’ possibile quindi creare una cartella dal prompt di DOS con:

mkdir cartella

Abilitare il supporto ai nomi case sensitive con:

fsutil.exe file setCaseSensitiveInfo cartella enable

e successivamente creare all’interno della cartella due file di testo chiamati FILE.txt e File.txt esattamente come avremmo fatto con una shell linux.

Conclusioni

Come abbiamo visto lo sviluppo su WSL procede a ritmi elevatissimi, quindi non ci resta che stare a guardare le sorprese che sono in serbo per noi nelle prossime build, non dimenticandoci che il componente WSL e tutte le sue incredibili potenzialità sono da poco disponibili anche sulle ultime build di Windows Server 2016.

Nella varietà di scelta tra i servizi disponibili all’interno di Azure troviamo il servizio DNS, in realtà non è un vero e proprio servizio offerto come registrar, in quanto non permette la registrazione di un dominio, ma permette di operare come server delegato.

Per poter registrare un qualunque dominio, dovremo, come fatto finora, riferirci ad un operatore di mercato, presso il Nic è disponibile un elenco di Aziende che operano come Registrar a livello italiano.

Le varie Aziende che operano in questo settore mettono a disposizione i vari servizi di registrazione.

Normalmente viene anche messo a disposizione un pannello tramite il quale è possibile gestire i vari record riferiti al dominio.

Abbiamo già detto che Azure in questo contesto opera come “delegato” ossia vengono reindirizzate le varie query sui DNS server a fronte di una esplicita delega sul Name Server principale per mezzo della definizione di un NS record secondo la RFC 1035.

Apparentemente questa configurazione può apparire inutile ed effettivamente non sempre è necessario o utile attivare i Name server di Azure in delega. Tuttavia alcune necessità, come ad esempio l’automazione richiesta da Let’s Encrypt per la validazione sulla base DNS, possono richiedere che l’aggiunta, la cancellazione o la modifica di record possano avvenire in modo automatico.

Quindi se il registrar presso il quale abbiamo registrato il nostro dominio non avesse queste funzionalità, possiamo utilizzare Azure-DNS in quanto servizio completamente automatizzabile.

Nell’esempio utilizzato per questo articolo deleghiamo i Name Server di Azure per la risoluzione del dominio robimassa.cloud ospitato presso Aruba

Creazione della zona delegata su Azure

Dalla creazione risorse è necessario scegliere DNS zone

Figura 1 creazione zona delegata su Azure DNS

Nel campo nome è necessario specificare il nome completo del dominio, specificare la sottoscrizione di riferimento ed eventualmente il nome del resource group da creare per la risorsa DNS. Nel caso di una zona su cui sarà necessario definire script di automazione è possibile creare un resource group dedicato in modo da “confinare” la risorsa.

Figura 2 creazione zona delegata su Azure DNS

Terminata la configurazione della zona DNS è possibile procedere alla creazione dei vari record già presenti nel servizio “principale” in modo da non creare interruzioni nella risoluzione dei nomi quando verrà attivata la delega.

Figura 3 creazione dei record relativi al dominio

Sono anche disponibili le informazioni relative ai name server da impostare per la delega sul DNS principale che dovranno poi essere usate successivamente.

A questo punto la nuova zona delegata è pronta ed è sufficiente procedere con la configurazione dei record NS su name server del Registrar.

Configurazione del Record NS sul portale del Registrar

Il dominio robimassa.cloud è stato registrato tramite Aruba che ne è quindi il registrar e tramite il quale è possibile gestire i vari record. La prima impostazione è relativa a quale è il name server principale per la zona e quindi per attivare la delega è necessario impostare l’uso di name server esterni.

Figura 4 pannello di gestione del DNS per robimassa.cloud

E successivamente dovranno essere creati i vari record NS secondo le informazioni ricavabili dal servizio Azure-DNS per la zona robimassa.cloud

Figura 5 impostazione record NS

A questo punto, atteso il tempo di replica tra i vari DNS globali le nuove informazioni ed impostazioni diventano operative

Figura 6 verifica delega con Nslookup

Nel caso in cui sia necessario delegare la gestione del dominio DNS sarà sufficiente creare un utente e successivamente attribuire i permessi minimi sul servizio

Figura 7 definizione accesso al servizio

Controllo delle attività sulla zona DNS

Accedendo ad “Activity Log” è possibile consultare tutte le attività eseguite sulla zona

Figura 8 consultazione Log

Riferimenti

Azure Dns Prezzi

Informazioni generali su Azure DNS

In ICTPower ci siamo occupati a più riprese della Certification Authority Let’s Encrypt, ed abbiamo visto come è possibile utilizzarla in diversi scenari.

In Ambienti OpenSource, con la validazione basata su Apache, In un altro articolo abbiamo proposto lo scenario che si può utilizzare con IIS come base per la validazione.

In questo articolo vediamo quali sono le modalità di validazione per il rilascio ed il rinnovo dei certificati sulla base di ambienti DNS, in questo modo è possibile utilizzare un servizio DNS, anche in hosting, per la gestione del ciclo di vita dei certificati gestiti da Let’s Encrypt. Le procedure proposte si basano sul client Win-Acme (WACS) e quindi in ambiente Windows.

Let’s Encrypt utilizza, analogamente a quanto visto per la validazione tramite servizi WEB, un’automazione che provvede a gestire determinati record all’interno del DNS.

Figura 1 Validazione tramite servizio DNS generico

Nella figura 1 è riportato un esempio di come Win-Acme, tramite le opzioni avanzate, permette di utilizzare il DNS per la validazione.

Nell’esempio sopra Win-Acme ricerca uno script a cui passare “hostname, record name e token“, e se opportunamente eseguito interagisce con il servizio DNS in modo da “scrivere” all’interno queste informazioni che lette dalla CA prima del rilascio del certificato, attestano che il richiedente è il reale proprietario del dominio.

E’ quindi chiaro che la disponibilità da parte del fornitore del servizio DNS ad una gestione automatizzata è fondamentale.

Nel panorama Italiano, Aruba non permette questo tipo di automazione (almeno da richiesta fatta al supporto tecnico nel mese di febbraio 2018), ma come vedremo in seguito questo non è necessariamente un limite.

Esistono diversi gestori di servizi DNS che rilasciano nelle gallery relative alle automazioni, script nati per far interagire i client CertBot con il loro DNS in modo da automatizzare le richieste verso Let’s Encrypt.

La maggioranza delle automazioni finora sono relative ad ambienti Linux.

Nel nostro caso utilizziamo invece Azure-DNS per la validazione da parte della CA, non ci occuperemo di come effettuare la delega al servizio Azure della risoluzione per il dominio, questa attività è trattata in dettaglio in questo articolo e si presuppone sia già stata effettuata.

Prima di procedere con la richiesta del certificato vero e proprio è necessario configurare il servizio Azure-DNS in modo che permetta l’accesso ad un “utente” con le credenziali minime per poter creare e cancellare record all’interno del Database DNS.

Questa tipologia di accesso è possibile con la creazione di un Service Principal Account
che possiamo definire come una identità di livello applicativo.

     Assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.

Per poter creare una identità di questo tipo possiamo utilizzare Azure Powershell e con l’utilizzo di alcune command let procedere alla sua creazione, l’accesso all’ambiente PS avviene direttamente dal portale Azure

Figura 2 accesso alla Cloud Shell

La preparazione dell’ambiente non è immediata e può richiedere anche più di un minuto, terminato l’accesso, disponiamo di un ambiente comandi direttamente sulla sottoscrizione.

Per procedere alla creazione del Principal account che verrà utilizzato per l’automazione è sufficiente utilizzare questi comandi

$Password = ConvertTo-SecureString -String “InserireQuiLaPassword” -AsPlainText -Force

New-AzureRmADServicePrincipal -DisplayName LetsEncrypt -Password $Password

Figura 3 creazione del service principal

In questo modo è stato creato l’account “Letsencrypt” con la relativa password ed è necessario assegnare i permessi di accesso alla zona DNS relativa al dominio per il quale stiamo richiedendo il certificato

Figura 4 attribuzione dei permessi

Accedendo alla gestione della zona robimassa.cloud tramite Access Control (IAM) si attribuisce il ruolo di DNS Zone Contributor al Service Principal Letsencrypt creato in precedenza.

La preparazione dell’ambiente relativo al servizio DNS è completata e prima di procedere alla generazione del certificato è utile recuperare alcune informazioni che saranno poi richieste dal client Win-Acme.

• Tenant ID (directory ID) ossia l’identificativo della Directory a cui ci stiamo riferendo
• Client ID l’identificativo del Service Principal creato prima
• Secret la password definita per il Principal
• DNS Subscription ID l’identificativo del Servizio DNS in questo caso (robimassa.cloud)
• DNS Resource Group Name il resource group definito per la risorsa DNS pubblica

In questa guida si fa riferimento al dominio robimassa.cloud, forse è superfluo specificarlo, ma il dominio DEVE essere un dominio pubblico regolarmente raggiungibile e quindi acquistato tramite i normali canali commerciali, nello specifico questo dominio è stato acquistato da Aruba.

Generazione del certificato

Il client Win-Acme dovrà essere eseguito con l’opzione –centralsslstore in modo da permettere l’archiviazione dei certificati (SAN o singolo Host) all’interno di una cartella, questo è necessario nel nostro caso in quanto i certificati rilasciati non vengono associati in automatico ad un Host Web, ma sono archiviati per un utilizzo successivo.

letsencrypt.exe –centralsslstore C:\letsencrypt-san\

vengono richieste a questo punto le impostazioni di base che sono quelle viste in figura 1 ad eccezione della validazione, per la quale dovremo selezionare l’opzione 1 ossia [dns-01] Azure DNS

Figura 5 richiesta validazione su Azure DNS

Proseguendo dovremo fornire le indicazioni relative all’accesso automatico del client come riportato sopra, ed al termine completata l’esecuzione, verranno salvati i certificati nella directory.

Figura 6 richiesta certificato

A questo punto il certificato è correttamente salvato in formato pfx e disponibile ad essere utilizzato, può ancora essere definito un utente con cui verrà eseguita periodicamente la task di rinnovo.

Se fosse necessario verificare i certificati emessi è possibile, sempre client Win-Acme la procedure di verifica.

Figura 7 verifica dei certificati emessi

Riferimenti

• https://letsencrypt.org
• Client Win-Acme su Git Hub
• https://certbot.eff.org/
• IctPower Let’s Encrypt in Apache HTTP
• IctPower Let’s Encrypt in IIS WindowsServer

Introduzione

La corretta gestione di una moderna infrastruttura IT dipende principalmente dalle scelte dei prodotti software e una delle scelte più importanti è sicuramente la scelta della soluzione di sicurezza degli endpoint (workstations, smartphones e tablets) ovvero software antivirus, antimalware di ultima generazione.

In questo articolo vi proponiamo un approccio basato sulla comparazione dei report di Gartner dell’ultimo triennio per analizzare l’evoluzione del posizionamento dei Vendor di soluzioni Endpoint Protection Platforms (EPP) nel quadrante magico (QM) di Garner.

Lo scopo è quello di fornire una rapida panoramica di come, secondo Gartner, i Vendor si sono posizionati e di quale sia il loro l’attuale Trend senza fermarsi alla sola analisi dell’ultimo report annuale.

Le soluzioni di EPP hanno subito negli ultimi anni un’evoluzione tale da richiedere una rivisitazione da parte di Gartner della definizione di EPP e dei parametri di valutazione (a riguardo si veda il report Redefining Endpoint Protection for 2017 and 2018 – Published: 29 September 2017 – ID: G00337106) e quindi la valutazione di come un Vendor si è posizionato nel corso degli ultimi anni e del suo Trend può essere un’informazione in sede di scelta di una soluzione di Endpoint Security.

Struttura dell’analisi

Gartner è una importante azienda nel mondo IT che si occupa di Analisi e ricerche di mercato/prodotto e advisoring e il cui obiettivo è quello di supportare le decisioni strategiche con consulenze e report che hanno lo scopo di fornire un punto di vista “super partes” sullo stato generale di un mercato, di una azienda o dei suoi prodotti.

Uno dei report prodotti da Gartner più famosi è il quadrante magico (QM) che è di semplice comprensione perché permette rapidamente di avere una panoramica, secondo Gartner, sul posizionamento che hanno gli attori del mercato. L’analisi del QM va però sempre approfondita con la lettura del documento a cui è affiancato in cui viene motivato in dettaglio le ragioni del posizionamento e che quindi vanno poi contestualizzate negli specifici scenari in cui si sta eseguendo la valutazione perché alcune motivazioni potrebbero essere poco influenti per le scelte necessarie. L’elenco dei Magic Quadrant è disponibile al seguente Gartner Magic Quadrant.

L’analisi dei Vendor di prodotti classificati da Gartner come Endpoint Protection Platforms basata sui seguenti report:

• Magic Quadrant for Endpoint Protection Platforms – Published: 24 January 2018 – ID: G00325704
• Magic Quadrant for Endpoint Protection Platforms – Published: 30 January 2017 – ID: G00301183
• Magic Quadrant for Endpoint Protection Platforms – Published: 01 February 2016 – ID: G00273851

Gartner definisce la categoria Endpoint Protection Platforms come segue:

“The endpoint protection platform provides security capabilities to protect workstations, smartphones and tablets. Security and risk management leaders of endpoint protection should investigate malware detection effectiveness, performance impact on the host machines and administrative overhead.”

Nell’analisi saranno presi in considerazione i Vendor che sono stati inseriti nel report nell’anno in corso (2018) e per semplicità di verranno ordinati in base ad uno Score calcolato sulla base del QM a cui verrà attribuito il seguente valore:

• 4 = Leaders
  
• 3 = Challengers
  
• 2 = Visionaries
  
• 1 = Niche Players
  
• 0 = Non Classificato
  

Lo Score attributo a ciascun Vendor, sulla base del quale sono stati ordinati dal valore maggiore a minore, è stato ottenuto con la seguente formula per pesare maggiormente il valore del QM degli ultimi anni:

• Se QM 2018 > 0 allora lo Score vale (100* QM 2018) + (10 * QM 2017) + QM 2016
  
• Se QM 2018 = 0 allora lo Score vale 0
  

L’obbiettivo è quello di ottenere una classifica del Vendor di soluzioni EPP ordinata in base al miglior posizionamento nei quadrante Gartner nel triennio e in base al miglior Trend di posizionamento nel corso degli anni.

Di seguito i tre MQ di gartner sulla base dei quali è stata eseguita l’analisi:

Risultato

Di seguito i Vendor ordinati in base allo Score calcolato, in base alla considerazioni precedenti dal valore maggiore al minore:

In base alla classifica ottenuta i leader della categoria Endpoint Protection Platforms del triennio 2016-2018 sono Sophos, Symantec e Trend Micro mentre ESET sta aumentato la sua competitività.

Di seguito gli aspetti positivi dei primi 3 Vendor della classifica ottenuta evidenziati nel report Gartner del 2018:

Pro di Sophos

• Intercept X clients report strong confidence in not only protecting against most ransomware, but also the ability to roll back the changes made by a ransomware process that escapes protection.
  
• Intercept X is available as a stand-alone agent for organizations that are unable to fully migrate from their incumbent EPP vendor.
  
• The exploit prevention capabilities focus on the tools, techniques and procedures that are common in many modern attacks, such as credential theft through Mimikatz.
  
• The Sophos Central cloud-based administration console can also manage other aspects of the vendor’s security platform, from a single console, including disk encryption, server protection, firewall, email and web gateways.
  
• Root Cause Analysis provides a simple workflow for case management and investigation for suspicious or malicious events.
  
• Root Cause Analysis capabilities are available to macOS, along with protection against cryptographic malware.
  

Pro di Symantec

• Symantec seems to have finally found a stable footing with its management team bringing stability across the company.
  
• SEP 14 and, most recently, SEP 14.1 have proven to be very stable and efficient on resources. Clients report that the addition of ML and other advanced anti-malware capabilities have improved threat and malicious software detection, and containment.
  
• Symantec ATP, its EDR-focused solution, provides good capabilities for detection and response, and existing SEP customers will benefit from its use of the existing SEP agent.
  
• Symantec has started to embrace a cloud-first strategy with the introduction of its latest product updates, including SEP Cloud and EDR Cloud, which provide a cloud-based console with feature parity to the on-premises management console.
  
• Symantec’s broad deployment across a very large deployment population of both consumer and business endpoints provides it with a very wide view into the threat landscape across many verticals.
  

Pro di Trend Micro

• Trend Micro participates in a wide range of third-party tests, with good results overall, and the OfficeScan client delivers functionality that other traditional vendors provide in their separate EDR add-on, such as IOA-driven behavioral detection.
  
• The virtual patching capabilities can reduce pressure on IT operational teams, allowing them to adhere to a strategic patch management strategy without compromising on security.
  
• For customers looking for a single strategic vendor, Trend Micro has strong integration across the endpoint, gateway and network solutions to enable real-time policy updates and posture adjustments.
  
• Trend Micro offers managed detection and response services, in its Advanced Threat Assessment Service, to augment the technology with expert analysis and best practices.
  

Di seguito invece gli aspetti negativi dei Vendor che hanno avuto un trend in discesa rispetto al 2017, inteso come cambio di quadrante, evidenziati nel report Gartner del 2018.

Contro di Kaspersky Lab secondo Gartner

• Gartner clients report that the management console, Kaspersky Security Center, can appear complex and overwhelming, especially when compared to the fluid, user-centric design of newer EPP and EDR vendor management consoles.
  
• The mainstream EDR capabilities were introduced into the Kaspersky Anti Targeted Attack Platform in late 2017, one of the last vendors to begin adding these features.
  
• The EDR investigation lacks step-by-step, guided investigations for less experienced organizations, but Kaspersky Lab can provide training on using its products for advanced topics like digital forensics, malware analysis and incident response.
  
• The Kaspersky Endpoint Security Cloud — a cloud-based management solution — is currently available only for SMB customers. Larger organizations looking for cloud-based management must deploy and maintain the management server in AWS or Azure.
  

Conro di Microsoft secondo Gartner

• The biggest challenge continues to be the scattered security controls, management servers, reporting engines and dashboards. Microsoft is beginning to center its future management and reporting around the Windows Defender Security Center platform, which is the management interface for the whole Windows Defender suite, including ATP. Microsoft Intune is replacing System Center as the primary management tool.
  
• To access advanced security capabilities, organizations need to sign up for the E5 tier subscription, which clients report as being more expensive than competitive EPP and EDR offerings, reducing the solution set’s overall appeal.
  
• Microsoft relies on third-party vendors to provide malware prevention, EDR and other functionality on non-Windows platforms, which may lead to disparate visibility and remediation capabilities and additional operational complexities.
  
• The advanced security capabilities are only available when organizations migrate to Windows 10. It does much less to address all other Windows platforms currently in operation.

Contro di Palo Alto Networks secondo Gartner

• There is currently no cloud-based management option; customers must use an on-premises management server.
  
• While Traps collects endpoint forensics data, it does not provide any response capabilities or postevent remediation tools. Organizations that do not use a Palo Alto Networks NGFW will need to take a multivendor approach to gain these capabilities.
  
• Traps lacks EDR capabilities beyond simple IOC searching, making investigation hard without an additional product.
  
• Palo Alto Networks acquired LightCyber in early 2017, but has not yet used the technology to improve the limited detection and response capabilities in Traps.
  
• Traps displayed a high rate of false positives in AV-TEST testing between August and October 2017.
  

Conclusioni

Ovviamente come già scritto precedente prima di trarre conclusioni è necessaria la lettura del documento a cui è affiancato il QM Gartner, inoltre le considerazioni relative ai vendor ovviamente prendono in esame la situazione che vi era alla data di pubblicazione del report, quindi, ad esempio, nel caso del QM Gartner del 2018 ovviamente alcune affermazioni relative a funzionalità del prodotto o alle scelte tecno – commerciali del Vendor che hanno portato al posizionamento potrebbero non essere corrette se valutate dopo il 24 gennaio 2018.

L’analisi dell’evoluzione del posizionamento nel quadrante sulla base della formula che abbiamo proposto può ovviamente non essere condivisibile, ma sicuramente la valutazione del Vendor sulla base di più report può aiutare a determinare la scelta di un prodotto della categoria Endpoint Protection Platforms che dovrà essere utilizzato per alcuni anni sebbene debba essere impiegato per gestire una delle problematiche IT più dinamiche come la protezione di workstations, smartphones e tablets da rischi di sicurezza. In ogni caso la classifica può essere rivista inserendo nel calcolo dello Score dei parametri che vadano a pesare la presenza e l’implementazione di determinate funzionalità indispensabili nell’infrastruttura IT oggetto della valutazione.

L’analisi che abbiamo proposto può quindi essere utilizzata come metro di valutazione per la scelta di una soluzione EPP, ma anche come parametro di confronto per valutare una soluzione presentata durante un incontro commerciale o ancora come strumento per giustificare le propria scelta nei confronti della Direzione aziendale.

A partire dall’ 8 Maggio 2018, a seguito del rilascio da parte di Microsoft degli aggiornamenti mensili ed in particolar modo della KB4103727, diversi utenti stanno ricevendo una serie di errori nei collegamenti RDP dovuti alla CredSSP Encryption Oracle Remediation.

Le connessioni Desktop remoto (RDP) sono infatti soggette ad una vulnerabilità di “Remote Code Execution” che è stata descritta nella CVE-2018-0886. Già dal 18 Marzo 2018 Microsoft aveva rilasciato una patch per poter gestire questa vulnerabilità e aveva introdotto una Group Policy per mitigarne i rischi. Se volete conoscere l’evoluzione degli aggiornamenti per questa vulnerabilità potete leggere l’articolo CredSSP updates for CVE-2018-0886

Con le patch contenute nel Cumulative Update di Maggio 2018, la Group Policy è stata modificata ed il valore è passato da Vulnerable a Mitigated. Il parametro lo trovate in Computer Configuration -> Administrative Templates -> System -> Credentials Delegation

Questa modifica al parametro della Group Policy obbliga la connessione RDP ad essere instaurata solo se dall’altra parte risponde una macchina che abbia ricevuto l’aggiornamento della KB4103727

Per maggiori informazioni sui diversi valori che il parametro può avere potete fare riferimento all’articolo https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

Figura 1: Policy utilizzata per la gestione della vulnerabilità di CredSSP Encryption

Per verificare che abbiate installato la KB “incriminata” (KB4103727) potete lanciare un prompt di PowerShell con privilegi elevati ed eseguire il comando Get-Hotfix

Figura 2: Aggiornamenti installati sul sistema operativo client

Problema

Sul mio client Windows 10 ho installato la KB4103727 e quando ho tentato di connettermi ad una macchina dove la patch non era installata ho ricevuto il seguente messaggio di errore:

Figura 3: Impossibile collegarvi via RDP su una macchina non aggiornata

Anche controllando il Registro Eventi l’errore appare chiaro:

Figura 4: Errore nel Registro Eventi relativo al fallimento della negoziazione sicura della connessione

Il comportamento delle macchine può essere riassunto in questo modo:

• se sia il client che la VM o il PC hanno la patch, la connessione avverrà in maniera sicura
• se il client ha la patch ma la VM o il PC non ce l’hanno, apparirà un messaggio di errore e non sarà possibile connettersi
• se il client non ha la patch ma la VM o il PC ce l’hanno, sarà possibile collegarsi via RDP ma la connessione non sarà sicura

Soluzione

Per ovviare al problema è possibile modificare la Policy che vi ho indicato prima (mettendo il valore su Vulnerable) o disinstallare la KB4103727 oppure modificare il registro utilizzando il comando

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

Io sconsiglio queste soluzioni. La cosa migliore da fare è aggiornare tutte le VM ed i PC installando gli aggiornamenti di sicurezza consigliati. Per aggiornare un PC o una VM potete utilizzare Windows Update oppure un server WSUS.

Figura 5: Aggiornamenti di Maggio 2018 su Windows Server 2016

Figura 6: Aggiornamenti di Maggio 2018 su Windows 10

Connessione ad una VM in Microsoft Azure e installazione della patch mancante

Se tentate di connettervi ad una VM in Azure in cui non avete installato la patch KB4103727, allora ricevete l’errore descritto prima e sarà necessario aggiornarla o mitigare la vulnerabilità.

Nel mio caso però la VM non è in dominio e non ho la possibilità di accedervi in console. Per installare la patch mi sono servito della funzionalità di Azure Update Management, una soluzione che vi permette di eseguire gli aggiornamenti per le macchine Windows e per le macchine Linux direttamente dal portale di Azure e tramite un Automation Account.

Figura 7: Abilitazione della soluzione Azure Update Management

Il principio di funzionamento di Azure Update Management è molto semplice e può essere riassunto dal seguente diagramma:

Figura 8: Principio di funzionamento di Azure Update Management

La tabella seguente elenca i sistemi operativi supportati da Azure Update Management:

Dopo pochissimi minuti dall’abilitazione della soluzione, la macchina verrà testata e verranno mostrati gli aggiornamenti mancanti. Come è possibile vedere dalla figura, manca il Security Update KB4103723

Figura 9: Aggiornamenti mancanti sulla VM

Fate clic sul pulsante Schedule update deployment che vi appare nel blade del portale di Azure e programmate quando volete effettuare l’aggiornamento. L’aggiornamento non è programmabile prima di 30 minuti e potete scegliere di eliminare alcune patch dall’installazione.

Figura 10: Programmazione dell’aggiornamento della VM

Una volta che avete schedulato l’aggiornamento non vi resta che attendere. La programmazione sarà visibile cliccando su Scheduled update deployment, come mostrato in figura:

Figura 11: Aggiornamenti programmati

Figura 12: Esecuzione del job di Update Deployment all’orario stabilito

Cliccando sul nome del job, nel mio caso Aggiornamenti Maggio 2018, potrete ricevere maggiori dettagli sullo stato di aggiornamento, come mostrato in figura:

Figura 13: Stato di avanzamento degli aggiornamenti

Dopo alcuni minuti, il processo di aggiornamento terminerà e finalmente potrete connettervi in RDP alla Azure VM.

Figura 14: Aggiornamenti completati

Conclusioni

Avere le macchine sempre aggiornate e lavorare con sistemi operativi sicuri è un prerequisito importante per non essere soggetti alle vulnerabilità dei software e dei sistemi operativi e non perdere i propri dati. Prima di aggiornare però assicuratevi di fare dei test sulla vostra infrastruttura e verificate che tutto continui a funzionare prima di distribuire in maniera massiva gli aggiornamenti.

Buon lavoro!

Nic

Azure Active Directory (Azure AD) è il servizio di gestione delle identità di Microsoft che combina in un’unica soluzione i servizi di directory, la gestione dell’accesso delle applicazioni e la protezione delle identità. Inoltre permette l’accesso Single Sign-On (SSO) a migliaia di app SaaS basate sul cloud e app locali. Il Single Sign-On permette di accedere alle applicazioni effettuando l’accesso solo una volta con un singolo account utente. Dopo aver effettuato l’accesso, è possibile accedere alle applicazioni senza dover ripetere una seconda volta l’autenticazione (ad esempio inserendo le credenziali di accesso per l’App). La configurazione di Single Sign-On basato su password consente infatti agli utenti di accedere automaticamente a un’applicazione SaaS tramite Azure AD utilizzando le informazioni di acesso che possono essere pre-memorizzate e non distribuite agli utenti. Per maggiori informazioni vi rimando all’articolo Informazioni sull’accesso alle applicazioni e Single Sign-On con Azure Active Directory ed al video Single Sign On to Applications

Figura 1: Il Single Sign-On permette di accedere alle applicazioni effettuando l’accesso solo una volta con un singolo account utente

In un mondo dominato dai dispositivi mobili e basato sul cloud, la sicurezza è una priorità assoluta per le aziende e, poiché gli utenti possono accedere alle risorse aziendali da una serie di dispositivi e ovunque si trovino, è necessario che oltre a stabilire chi possa accedere a determinate risorse diventa fondamentale anche decidere il modo in cui accedere. L’accesso condizionale è una funzionalità di Azure Active Directory che consente di applicare controlli sull’accesso in base a specifiche condizioni.

Figura 2: Schema di funzionamento di Azure Conditional Access

Con i criteri di accesso condizionale è possibile controllare il modo in cui gli utenti autorizzati (che hanno ottenuto l’accesso a un’App cloud) possono accedere alle App cloud in condizioni specifiche. Per poter abilitare questa funzionalità loggatevi al portale Azure e selezionate il nodo Azure Active Directory. Cliccando su Conditional Access avrete la possibilità di definire la policy di accesso alle applicazioni. Per poter utilizzare questa funzionalità è necessario però abilitare il piano Premium P2 di Azure AD. Se non lo avete già fatto potete abilitare una trial gratuita, come mostrato in figura:

Figura 3: Abilitazione della trial di Azure AD Premium

Figura 4: Scelta della versione trial da attivare

Per maggiori informazioni su Azure AD Premium P2, sulle funzionalità che vengono abilitate e sui prezzi potete leggere l’articolo https://azure.microsoft.com/it-it/pricing/details/active-directory/

Una volta terminata l’attivazione avrete la possibilità di creare una nuova policy di accesso condizionale. Cliccate su New Policy per creare un nuovo set di regole.

Figura 5: Policy di accesso condizionale

Voglio creare una policy che obblighi gli utenti ad usare la Azure Multi-Factor Authentication quando si connettono dall’esterno dell’azienda (al di fuori della rete aziendale) e voglio permettere solo alcuni tipi di dispositivi (smartphone Android). La prima impostazione che è possibile fare consiste nel dichiarare a quali utenti o a quali gruppi deve essere associata la policy, come mostrato in figura:

Figura 6: Scelte dei gruppi o degli utenti a cui applicare la policy

La scelta successiva consiste nel selezionare quali App, tra quelle disponibili, saranno soggette alla policy. Potete scegliere tutte le applicazioni oppure selezionarne solo alcune, come mostrato in figura:

Figura 7: Scelta delle applicazioni da filtrare

È possibile dare alla policy un indicazione sul rischio quando si usano le App. Il rischio di accesso è un’indicazione della probabilità (elevata, media o bassa) che un tentativo di accesso non sia stato eseguito dal legittimo proprietario di un account utente. Azure AD calcola il livello di rischio di accesso durante l’accesso di un utente. Nel mio caso ho deciso di assegnare il valore High perché le applicazioni che ho selezionato sono critiche per la mia azienda.

Figura 8: Scelta del valore di rischio

È possibile anche fare in modo che l’applicazione sia lanciata solo da alcune piattaforme, sia Pc che smartphone.

Figura 9: Scelta della piattaforma da cui viene avviata l’applicazione

Poiché la policy serve a filtrare l’accesso e a consentire l’utilizzo dell’App solo tramite Azure Multi-factor Authentication, decido di impostarla per qualsiasi Location ed escludo quelle che sono invece le Trusted Location. Successivamente definirò la Trusted Location (la mia rete aziendale) e quando i dispositivi si trovano in azienda non saranno sottoposti alla policy.

Figura 10: Configurazione della Location dove si devono trovare i dispositivi quando lanciano l’applicazione

Figura 11: Esclusione dalla policy delle Trusted Locations

È possibile anche stabilire quali client verranno utilizzati per connettersi all’App e poterne eventualmente impedire l’accesso

Figura 12: Scelta dei client che potranno essere utilizzati per connettersi all’App

Figura 13: Scelta del Device State

A questo punto stabilisco il controllo dell’accesso e permetto l’accesso solo a chi usa la multi-factor authentication, come mostrato in figura:

Figura 14: Configurazione del controllo dell’accesso e relative impostazioni

Il passaggio finale è l’abilitazione della policy.

Figura 15: Abilitazione della policy

Poiché ho creato l’eccezione nella policy che consente l’utilizzo dell’applicazione senza multi-factor authentication, devo definire quali sono le Trusted Location. Per farlo basta cliccare su Named Locations e poi selezionale New Location, come mostrato in figura. A questo punto potrete definire l’indirizzo IP della vostra rete aziendale o il range degli indirizzi. È anche possibile definire quali sono gli indirizzi IP che vengono considerati sicuri e non soggetti alla multi-factor authentication utilizzando il collegamento Configure MFA trusted IPs

Figura 16: Creazione della Trusted Location

Dopo aver creato la policy è possibile testarla da un dispositivo che non sia nella rete aziendale o che non sia collegato tramite un Trusted IPs. Navigate all’indirizzo https://myapps.microsoft.com e autenticatevi. Dopo l’autenticazione vi apparirà la lista delle applicazioni a cui siete abilitati.

Figura 17: Lista delle applicazioni disponibili per l’utente

Figura 18: Logon all’applicazione automatico (notate la freccia in figura)

Figura 19: Logon all’applicazione da un device Android

Conclusioni

In Azure AD gli utenti possono accedere alle App cloud da una vasta gamma di dispositivi, inclusi i dispositivi mobili (smartphone, tablet) e i dispositivi personali (notebook, Pc). Con l’accesso condizionale possiamo aumentare il livello di sicurezza per l’accesso alle App, facendo in modo che la connessione all’App sia consentita solo da alcune applicazioni (ad esempio il browser), solo da alcuni dispositivi (ad esempio smartphone Android, iPhone, PC o Mac) e solo da alcune reti (solo la rete aziendale). Se volete acquisire familiarità con la configurazione dei criteri di accesso condizionale vi consiglio di leggere anche l’articolo Introduzione all’accesso condizionale in Azure Active Directory.

Buon lavoro!

Nic

Dalla versione di Windows 10 Anniversary Update (Professional oppure Enterprise) è possibile aggiungere il sistema operativo client di casa Microsoft ad Azure Active Directory (Azure AD), la directory basata sul cloud multi-tenant usata come servizio di gestione delle identità, che combina i servizi di directory, la gestione dell’accesso delle applicazioni e la protezione delle identità in un’unica soluzione.

Per avere un’idea dei possibili vantaggi e degli scenari di utilizzo di un computer Windows 10 joinato ad Azure AD vi consiglio di leggere prima l’articolo Usage scenarios and deployment considerations for Azure AD Join

In ogni caso potete joinare ad Azure AD solo un computer in Workgroup. Se avete un computer già joinato al dominio locale e volete approfittare delle funzionalità di Single Sign-On, potete invece Connettere un computer in dominio ad Azure AD (Workplace Join). Si tratta quindi di due funzionalità completamente diverse. Per completezza vi inserisco una tabella che riassume le differenze:

Figura 1: tabella riassuntiva delle differenze di funzionalità tra Azure AD Join e Workplace Join

In questo articolo mi occuperò solo di Azure AD Join

Gli utenti possono joinare i propri dispositivi Windows 10 sia durante la first-run experience, il momento in cui si accende il dispositivo per la prima volta ed è necessario inserire le prime informazioni per completare l’installazione, sia dall’app Settings, dove si può decidere se connettere il sistema operativo ad Azure AD oppure joinarlo. Se joinate Windows 10 ad Azure AD potete utilizzare le credenziali di Azure AD per potervi loggare al PC ed utilizzare la funzionalità di Single Sign-On (SSO) quando accedete alle applicazioni SaaS basate sul cloud ed ad Office 365.

È anche possibile impedire agli utenti ed ai gruppi creati in Azure AD la possibilità di joinare i propri dispositivi o limitarne il numero, oltre a forzare l’uso della multi-factor authentication. Dopo che un utente ha joinato il proprio dispositivo in Azure AD è possibile controllarne il comportamento, è possibile cancellarlo, bloccarlo oppure gestirlo con un software di Mobile Device Management (come Microsoft Intune).

Se decidete di joinare Windows 10 durante la first-run experience, i passaggi da seguire cambiano in base alla release di Windows 10 che state utilizzando e sono descritti nell’articolo Aggiungere un nuovo dispositivo Windows 10 con Azure AD in fase di completamento dell’installazione. In sintesi, i passaggi da effettuare sono i seguenti:

1. Quando si accende il nuovo dispositivo e viene avviato il processo di installazione, viene visualizzato il messaggio Preparazione . Seguite le istruzioni per configurare il dispositivo.
2. Iniziate personalizzando il paese e la lingua. Quindi accettate le Condizioni di licenza software Microsoft.
3. Selezionate la rete che desiderate usare per la connessione a Internet.
4. Fate clic su Questo dispositivo appartiene all’organizzazione.
5. Immettete le credenziali di Azure AD e quindi fate clic su Accedi.
6. Il dispositivo individua un tenant in Azure AD. Se si è in un dominio federato, si verrà reindirizzati al server del servizio token di sicurezza locale, ad esempio Active Directory Federation Services (AD FS). Se si è in un dominio non federato, immettete le credenziali direttamente nella pagina ospitata da Azure AD.
7. Vi viene richiesto di effettuare l’autenticazione a più fattori (non obbligatoria).
8. Windows registra il dispositivo nella directory dell’organizzazione in Azure AD

Nel mio caso invece, ho deciso di joinare ad Azure AD una macchina virtuale con Windows 10 Professional che ho creato nel Cloud Azure. Non potendo accedere alla schermata della first-run experience, mi sono prima loggato a Windows 10 con le credenziali amministrative in mio possesso e successivamente ho lanciato l’applicazione Settings, che mi permette di gestire gli Accounts. Dalla funzionalità Access Work or School ho cliccato su Connect e poi sul link Join this device to Azure Active Directory, come mostrato in figura:

Figura 2: Schermata iniziale per l’aggiunta di un computer Windows 10 ad Azure AD

Nella schermata successiva ho inserito le credenziali di un utente di Azure AD (non serve che sia un utente privilegiato nel vostro tenant di Azure, può essere un utente qualsiasi).

Figura 3: Inserimento delle credenziali dell’utente a cui associare il dispositivo Windows 10

Figura 4: Inserimento password

Figura 5: L’account che ho usato utilizza la multi-factor authentication (non obbligatoria)

Dopo aver inserito le credenziali, un avviso vi dirà che l’account di Azure AD verrà aggiunto al gruppo Administrators locali della macchina Windows 10 e che alcune policy potrebbero essere applicate alla macchina.

Figura 6: Avviso riguardo l’applicazione di policy sulla macchina Windows 10 dopo il join ad Azure AD

Figura 7: Conferma dell’avvenuto join ad Azure AD

Nella scheda Access work or School adesso appare l’utente che avete utilizzato, a fianco del simbolo di una borsa di lavoro.

Figura 8: Informazioni sull’utente connesso

Se accedete al Pannello di controllo e verificate i membri del gruppo Administrators, vedrete che è stato aggiunto un account con il nome AzureAD\NicolaFerrini, come mostrato in figura.

Figura 9: L’utente di Azure AD è stato aggiunto al gruppo Administrators

Dal portale di Azure è anche possibile verificare in Azure Active Directory che un nuovo dispositivo è stato aggiunto alla directory dove si trova l’utente che avete utilizzato per joinare Windows 10.

Figura 10: Il nuovo dispositivo Windows 10 aggiunto ad Azure AD

Cliccando sul dispositivo sarà possibile ricevere maggiori informazioni, sarà possibile disabilitarlo o anche rimuoverlo.

Figura 11: Proprietà del dispositivo aggiunto ad Azure AD

Connessione in RDP ad un computer joinato ad Azure AD

Per testare la funzionalità di Single Sign-On (SSO) è necessario loggarsi al computer con le credenziali di Azure AD (usando come username AzureAD\NomeCognome). Nel mio caso però, poiché la macchina è ospitata su Azure, non ho la possibilità di connettermi in console e devo necessariamente farlo in Desktop Remoto (RDP). Ho quindi fatto logoff con l’utente che stavo utilizzando e ho provato a loggarmi con le credenziali di Azure AD. Infatti l’utente di Azure AD fa parte del gruppo Administrators locali della macchina, che possono accedere di default in RDP. Dopo aver inserito username e password invece ho ottenuto il seguente errore:

Figura 12: Connessione in RDP alla macchina Windows 10 utilizzando le credenziali di Azure AD

Figura 13: Errore di login in RDP usando le credenziali dell’utente di Azure AD

Come ben documentato nell’articolo Connettersi a un PC remoto aggiunto ad Azure Active Directory, l’accesso in RDP alle macchine Windows 10 è possibile a partire da Windows 10 versione 1607. Entrambi i PC (locale e remoto) devono eseguire Windows 10 versione 1607 o versioni successive. È necessario però che il  Remote Credential Guard, una nuova funzionalità di Windows 10 versione 1607, sia disattivata nel PC client che utilizzate per connettervi al PC remoto.

Ovviamente è un’opzione che NON consiglio, visto che poi esporrebbe il vostro client alla perdita di credenziali per tutte le connessioni RDP e ad attacchi di tipo Pass The Hash.

In alternativa è possibile effettuare queste operazioni:

• Disabilitare nel computer remoto Windows 10 joinato ad Azure AD la Network Level Authentication
• Modificare il file .RDP utilizzato per la connessione aggiungendo i valori:
  • enablecredsspsupport:i:0
  • authentication level:i:2

Per disabilitare la Network Level Authentication vi basta andare nel Pannello di controllo e dalle proprietà del Sistema, utilizzate il tab Remote per rimuovere il segno di spunta dalla abilitazione della Network Level Authentication come mostrato in figura:

Figura 14: Disabilitazione della Network Level Authentication

Per modificare il file .RDP vi basta aprirlo con Notepad++ (o con un altro editor di testo a vostra scelta) e aggiungere le due righe sopra indicate, come mostrato in figura:

Figura 15: Modifica del file .RDP

A questo punto, se lanciate la connessione remota utilizzando il file .RDP modificato, il processo di autenticazione sarà diverso. Prima vi apparirà il messaggio di errore del certificato presentato dal client Windows 10 e successivamente vi verrà chiesto di inserire le credenziali di Azure AD

Figura 16: Connessione al computer remoto effettuata

Figura 17: Inserimento delle credenziali di Azure AD

Nonostante l’utente utilizzando abbia la Multi-factor authentication abilitata, per le connessioni RDP non verrà richiesta.

Figura 18: Verifica dell’utente connesso in RDP

Adesso che l’utente è connesso con il suo account di Azure AD potrà approfittare della funzionalità di Single Sign-On (SSO) per loggarsi al portale di Azure o al portale di Office 365, senza che gli vengano chieste le credenziali di autenticazione, utilizzando il browser Edge. Altri browser alternativi, come Google Chrome o Mozilla Firefox non sono compatibili con l’SSO.

Figura 19: L’accesso al portale di Office 365 con l’account di Azure AD e con il browser Edge non richiede l’inserimento delle credenziali di accesso

Conclusioni

Numerosi sono i motivi per cui potrebbe essere utile joinare un computer ad Azure AD. Tra i tanti, è possibile configurare utenti e dipendenti in modo che usino i dispositivi Windows personali (BYOD, Bring Your Own Device) per accedere alle App e alle risorse aziendali (applicazioni SaaS). Gli utenti possono aggiungere i propri account Azure AD (account aziendali o account scolastici) a un dispositivo personale Windows per accedere alle risorse ed alle applicazioni in totale sicurezza e conformità. I dispositivi possono anche essere assoggettati ad alcune policy di sicurezza e possono essere gestiti da remoto con software di Mobile Device Management. Rimane a mio avviso ancora difficile e poco sicuro connettersi in RDP a questi dispositivi e spero che ben presto venga innalzato il livello di sicurezza e non sia necessario effettuare dei workaround.

Buon lavoro!

Nic

In qualsiasi realtà aziendale è necessario effettuare delle attività di amministrazione informatica che richiedono dei permessi amministrativi elevati ed è una buona pratica che gli utenti abbiano sempre i minori permessi amministrativi possibili, per assicurare un buon livello di sicurezza ed impedire che vengano effettuate delle operazioni senza consenso (volutamente o per sbaglio). È interessante anche limitare nel tempo eventuali permessi amministrativi, giusto il tempo necessario per effettuare l’operazione. Mi è capitato spesso di vedere account privilegiati assegnati ad un consulente esterno che poi non sono stati più rimossi e questo mette a forte rischio la sicurezza aziendale.

Ho avuto modo qualche tempo fa di mostrarvi una nuova funzionalità  introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) nell’articolo Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD e ho già affrontato il tema della Gestione dell’accesso alle macchine virtuali in Microsoft Azure con la funzionalità JIT (Just-in-Time)

In questo articolo voglio invece parlarvi di come rendere sicuro l’accesso ad Azure AD (e quindi a tutte le risorse che gestisce) utilizzando Privileged Identity Management, che permette di assegnare permessi amministrativi limitati nel tempo e che permette di monitorare e approvare questo tipo di accessi privilegiati.

Privileged Identity Management (PIM) richiede però che abbiate una sottoscrizione Azure AD Premium P2 oppure che abbiate Enterprise Mobility + Security E5. Per chi non conoscesse le differenze tra le diverse edizioni di Azure AD consiglio vivamente la lettura del documento Informazioni su Azure Active Directory, mentre per il pricing vi rimando al link Prezzi di Azure Active Directory

I vantaggi nell’uso di Azure AD Privileged Identity Management sono davvero notevoli e vi permettono di:

• Vedere a quali utenti vengono assegnati i ruoli con privilegi per gestire le risorse di Azure
• Abilitare l’accesso come amministratore JIT su richiesta ad Office 365 e alle risorse di Azure (sottoscrizioni, gruppi di risorse e alle singole risorse)
• Visualizzare una cronologia dell’attivazione dell’amministratore, comprese le modifiche che gli amministratori hanno apportato alle risorse di Azure
• Essere avvisati delle modifiche apportate nelle assegnazioni del ruolo di amministratore
• Richiedere l’approvazione per attivare i ruoli di amministratore con privilegi di Azure AD
• Esaminare l’appartenenza dei ruoli di amministratore e richiedere agli utenti di fornire una giustificazione per l’appartenenza continua ad un determinato ruolo

Abilitare Privileged Identity Management per la directory di Azure

Per cominciare è necessario che accediate al portale di gestione di Azure AD utilizzando i privilegi di un Global Administrator. Decidete di aggiungere una nuova risorsa e scegliete Azure AD Privileged Identity Management. Seguite le indicazioni presenti in console e fate clic su Create.

Figura 1: Aggiunta della risorsa Azure AD Privileged Identity Management

Come accennato prima, per poter aggiungere questa funzionalità è necessario abilitare un piano di Azure AD Premium 2. Potete attivare anche una trial della durata di 30 giorni per testare tutte le funzionalità offerte dal piano.

Figura 2: Attivazione della trial di Azure AD Premium P2

Per poter attivare Privileged Identity Management è necessario che venga verificata l’identità del Global Administrator che la sta attivando. Seguite il wizard ed utilizzate la multi-factor authentication per poter assicurare l’attivazione, come mostrato in figura:

Figura 3: Richiesta della verifica dell’identità prima dell’attivazione di Privileged Identity Management

Figura 4: Completamento della verifica dell’identità con l’utilizzo della multi-factor authentication

Dopo aver effettuato la verifica, confermate l’attivazione facendo clic sul punsante Consent, come mostrato in figura:

Figura 5: Consenso all’attivazione di PIM

La procedura non è ancora terminata e l’ultimo passaggio richiede che effettuiate il Sign Up di Privileged Identity Management ai ruoli di Azure AD directory.

Figura 6: Sign Up di PIM ai ruoli di Azure AD directory

Adesso che avete completato tutti gli step per l’attivazione della funzionalità di Privileged Identity Mangement, potrete visualizzare tutti i ruoli che sono stati assegnati nella vostra directory di Azure AD.

Figura 7: Ruoli assegnati nella directory di Azure AD

Gestione dei ruoli e degli accessi privilegiati

In questa guida utilizzerò il mio tenant di Office 365 e la relativa Azure Directory. Nel tenant è presente un utente, che si chiama Murphy Law, che attualmente è un Exchange Administrator.

Figura 8: Utente con un ruolo permanente di Exchange Administrator

La verifica del ruolo può essere fatta anche dal portale di Azure AD.

Figura 9: Verifica del ruolo dal portale di Azure AD

Sicuramente molti di voi conosceranno la Legge di Murphy e penseranno che probabilmente non sia il caso di affidare la gestione di Exchange Online ad un utente con un nome simile, soprattutto di non farlo in maniera permanente. Io tra l’altro sono molto d’accordo con la Chiosa di O’Toole alla legge di Murphy: Murphy era un ottimista. Per questo motivo ho deciso di convertire il ruolo di Exchange Administrator all’utente Murphy Law da Permanente ad Eleggibile. Murphy potrà richiedere di diventare Exchange Administrator quando ne avrà bisogno, ma per il resto del tempo rimarrà un utente limitato.

Figura 10: Modifica del ruolo di Exchange Administrator da Permament ad Eligible

Figura 11: Verifica della conversione del ruolo

Dal portale amministrativo di Office 365 adesso risulterà che Murphy Law è un semplice utente, senza alcun ruolo amministrativo.

Figura 12: Murphy è diventato un utente senza privilegi amministrativi

Richiesta di appartenenza temporanea ad un ruolo amministrativo

Quando l’utente dovrà effettuare delle operazioni su Exchange Online e avrà bisogno dei privilegi corretti, potrà connettersi al portare di Azure AAD con le proprie credenziali e dal nodo di Privileged Identity Management potrà fare richiesta di attivazione di uno dei ruoli che sono per lui eleggibili, come mostrato in figura:

Figura 13: Richiesta di attivazione di uno dei ruoli per cui l’utente è eleggibile

Figura 14: Richiesta di conferma dell’identità tramite multi-factor authentication

Il ruolo potrà essere attivato per un certo numero di ore, che sono determinate dal “template” del ruolo e che posso essere modificate, e può essere attivato a partire da una certa data e ora invece che immediatamente.

Figura 15: Attivazione temporanea del ruolo con attivazione personalizzata del tempo di inizio

Nel portale amministrativo è possibile verificare l’attivazione del ruolo, la durata e la scadenza dello stesso.

Figura 16: Verifica dell’attivazione del ruolo dal portale di Azure AAD

Da questo momento in poi e per la durata di un’ora l’utente farà parte degli Exchange Administrator.

Gestione del processo di attivazione del ruolo

Come abbiamo visto, l’utente si è auto-attivato il ruolo. È però possibile fare in modo che, prima dell’attivazione, sia necessaria l’approvazione da parte di un utente ancora più privilegiato. Per poter usare l’approvazione è necessario modificare il comportamento del ruolo. Loggatevi in Azure AAD e selezionate Azure AD Privileged Identity Management. Dal nodo Azure Active Directory Roles scegliete Roles e poi selezionate il ruolo che volete modificare. Potete modificarne la durata, potete richiedere che venga mandata una mail agli amministratori ogni volta che il ruolo viene attivato ma soprattutto potete attivare l’approvazione, come mostrato in figura:

Figura 17: Modifica del ruolo di Exchange Administrator ed attivazione dell’approvazione

Terminata la procedura, ogni volta che verrà effettuata una richiesta per avere il ruolo di Exchange Administrator, l’Approver riceverà una mail con la richiesta e potrà decidere se concedere o rifiutare la richiesta.

Figura 18: Mail di richiesta per l’approvazione del ruolo

Figura 19: Approvazione o rifiuto della richiesta dal portare di Azure AD

Conclusioni

Azure AD Privileged Identity Management (PIM) è disponibile con il piano AAD Premium P2 e permette alle aziende di poter controllare meglio quando gli utenti utilizzano gli account privilegiati. Poter limitare nel tempo i privilegi ed utilizzare la Just in Time Administration è sicuramente vantaggioso in termini di sicurezza e permette di poter gestire nel cloud lo stesso principio del Least Administrative Privilege che “dovremmo” avere in azienda. Per approfondimenti sul tema vi rimando alla lettura dell’articolo Iniziare ad usare Azure AD Privileged Identity Management

Buon lavoro!

Nic

Sempre più spesso mi capita, quando sono in azienda o durante i corsi, di riscontrare perplessità o inesattezze sulla corretta applicazione delle password policies da parte degli amministratori di dominio. Per questo motivo oggi voglio scrivere un articolo che faccia chiarezza sulla corretta applicazione delle policy e sull’esatto ordine con cui questa avviene.

Quante password policies posso applicare ad un singolo dominio?

Rispondere a questa domanda è semplice: una ed una sola!

• Solo le policy applicate a livello di DOMINIO vengono considerate valide e verranno distribuite agli utenti. Le policy applicate a livello di OU (Organizational Unit), inclusa la OU dei Domain Controllers, vengono ignorate.
• Se a livello di dominio ci sono più policy (ad esempio la Default Domain Policy ed una policy creata da voi) verranno considerati tutti i settaggi delle due policy (viene cioè fatto un merge), ma in caso di conflitto avrà la precedenza il settaggio della policy con la precedenza più alta (cioè la policy che ha un numero inferiore al quello della Default Domain Policy – Link Order più basso).
• La password policy viene gestita dal domain controller che ha il ruolo FSMO di PDC Emulator.

Quindi, ci può essere solo una password policy per ogni account database e un dominio di Active Directory è considerato un singolo account database, come succede con i computer standalone.

Figura 1: in caso di più policy, vince quella con il LInk Order più basso

Quando viene applicata la password policy?

La password policy è sempre applicata alla macchina e non all’utente. Quindi quando avviene un aggiornamento della policy, questa viene applicata in background ogni 90 minuti di default (Background Refresh of Group Policy), all’avvio del computer oppure utilizzando il comando GPupdate.

Quando gli utenti vengono impattati?

Se cambio la password policy e stabilisco che la lunghezza minima della password sia 8 invece che 6 caratteri, gli utenti non si accorgono della modifica fino a quando la password non scade o gli viene chiesto di cambiarla (perché un amministratore l’ha resettata).

Quindi la modifica non è così “impattante” come si penserebbe e non costringerebbe tutti gli utenti del dominio a cambiare la password lo stesso giorno, per essere compliant con la nuova lunghezza minima imposta.

Quando vengono distribuite le modifiche apportate ad una password policy?

Nel momento in cui modificate la password policy, i seguenti settaggi vengono distribuiti immediatamente:

• Minimum password length
• Password must meet complexity requirements
• Reversible encryption

Mentre gli altri settaggi vengono distribuiti solo dopo un logon, logoff, reboot oppure un GPO refresh

• Minimum password age
• Maximum password age
• Lockout duration
• Lockout threshold
• Observation window

Attenzione sempre a distinguere tra distribuzione della policy e applicazione dei nuovi settaggi, che avvengono in momenti distinti a seconda del settaggio stesso, come ho già sottolineato.

Cos’è la Fine-Grained Password Policy?

A partire da Windows Server 2008 (e solo se il livello funzionale del dominio è innalzato a Windows Server 2008) è possibile applicare una password policy direttamente agli utenti o ai gruppi di sicurezza globale (global security groups) di Active Directory. Questa funzionalità, chiamata Fine-Grained Password Policy, permette di definire configurazioni differenti per le password e le account lockout policy per differenti tipi di utenti all’interno del dominio.

Supponiate infatti che la password policy per gli amministratori di dominio o per gli utenti privilegiati richieda un numero minino di caratteri superiore a quelli di un utente limitato. Con la Fine-Grained Password Policy (FGPP) potete applicare la policy direttamente al gruppo di utenti interessato.

Non potete comunque applicare la policy alla singola Organizational Unit (OU). Potreste però creare uno Shadow Group, cioè un gruppo a cui vengono aggiunti tutti gli utenti di una determinata OU con uno script PowerShell automatico ed applicare la FGPP allo Shadow Group. Online trovate decine di esempi di script su come creare uno Shadow Group ed aggiungerci in maniera automatica gli utenti presenti nella OU.

Per creare una FGPP vi rimando alla lettura dell’articolo Step-by-Step: Enabling and Using Fine-Grained Password Policies in AD

Figura 2: Configurazione di una Fine-Grained Password Policy per il gruppo Domain Admins

All’atto pratico, la Fine-Grained Password Policy non modifica nessuna Group Policy, ma modifica un attributo dell’utente chiamato msDS-ResultantPSO. È importante applicare alla FGPP una precedenza, perché nel caso l’utente appartenga a gruppi diversi e a questi gruppi siano state applicate diverse FGPP, la precedenza diventa determinante perché vincerà la FGPP con il valore di precedenza più basso.

Figura 3: Verifica della corretta applicazione della FGPP ad un utente del gruppo a cui è stata applicata la policy

Conclusioni

Spero con questo articolo di aver dipanato alcuni dubbi in merito all’applicazione delle password policy, soprattutto per quanto riguarda le tempistiche di applicazione dopo che avete modificato alcuni parametri, e di avervi indicato il giusto modo per procedere ad una corretta configurazione delle stesse.

Buon lavoro!

Nic

Azure DevTest Labs è un servizio che permette agli sviluppatori o ai tester di creare un ambiente nel Cloud che gli permetta di tenere sotto controllo i costi e allo stesso tempo gli permetta di effettuare tutti i test applicativi utilizzando sia macchine Windows che macchine Linux. Grazie all’uso di alcune policy è possibile tenere sotto controllo i costi ed il numero di macchine virtuali da utilizzare in ambiente di test. Molto spesso infatti mi è capitato di vedere alcuni laboratori ed alcuni POC che, dopo essere stati creati, vengono lasciati accesi e non vengono più gestiti. Se realizzati nel Cloud, questi lab possono diventare un vero incubo a fine mese, quando arriva la fattura da Microsoft.

Limitando invece il numero di macchine virtuali che un utente può creare, impostando l’avvio e lo spegnimento automatico e decidendo il numero massimo di VM che è possibile creare in ogni lab, si riescono sicuramente a gestire meglio le risorse che vengono messe a disposizione per il test.

Creazione del Dev Test Lab

La creazione del DevTest Lab è molto semplice. Loggatevi al portale Azure e decidete di creare un nuovo DevTest Lab. Inserite il nome del lab, la location ed il Resource Group da utilizzare ed eventualmente abilitate l’Auto-shutdown.

Figura 1: Creazione di un DevTest Lab

La creazione dura pochi secondi e tra le prime operazioni da fare c’è l’aggiunta delle macchine virtuali che volete rendere disponibili nel lab. Vi potete servire delle immagini presenti nel Marketplace oppure potete utilizzare le vostre immagini personalizzate.

Figura 2: Aggiunta delle macchine virtuali al DevTest Lab

Dopo aver cliccato sul pulsante Add potete scegliere le immagini disponibili nel Marketplace. In questo articolo ho deciso di utilizzare l’immagine di Windows Server 2016. Procedete alla configurazione del nome della VM, della username e della password per accedere alle VM. Configurate la dimensione delle VM e gli eventuali Artifacts da installare, cioè software aggiuntivi da mettere nella VM, come mostrato in figura. Gli Artifacts sono la parte più importante del lab, perché contengono gli script per configurare automaticamente le nostre VM e prepararle per il laboratorio. Ad esempio, potremmo creare uno script che installa un webserver o uno script che promuove la macchina a domain controller e riutilizzarlo tutte le volte che vogliamo ricreare le VM del laboratorio.

Figura 3: Installazione degli Artifacts nella VM

Configurate la VNET e la subnet a cui connettere la VM, l’eventuale indirizzo IP pubblico e scegliete il numero delle VM da creare, oltre a decidere se la VM deve essere Claimable. Le macchine virtuali verranno create e messe in un pool condiviso, a disposizione di chi ne abbia bisogno, e rimarranno spente fino a quando qualcuno non deciderà di effetuarne il Claim, cioè di accenderle ed utilizzarle.

Figura 4: Configurazione del numero delle VM a disposizione nel DevTest Lab

Subito dopo vedrete che le vostre macchine cominceranno ad essere create e configurate secondo le configurazioni che avete indicato.

Figura 5: Creazione delle macchine virtuali

Dopo aver atteso la creazione delle VM, è possibile andare nel nodo Claimable virtual machines e selezionare Claim machine, come mostrato in figura. L’operazione consiste nell’accensione (e quindi nel pagamento) della VM e la rende disponibile all’utilizzo.

Figura 6: Claim di una macchina virtuale (la macchina verrà accesa e resa disponibile agli utenti del DevTest Lab)

Figura 7: Solo le VM che sono state richieste vengono accese, le altre rimangono spente

Per poter permettere l’accesso al DevTest Lab e alle VM, potete cliccare sul nodo Configuration and Policies e successivamente selezionare Access Contro (IAM). Cliccando su Add è possibile aggiungere utenti e gruppi e dare loro il giusto ruolo. Nella figura sotto viene concesso ad un utente il permesso di DevTest Labs User

Figura 8: Aggiunta dei permessi di utilizzo del DevTest Lab

La seguente tabella mostra le operazioni che possono essere concesse agli utenti in base al loro ruolo:

Tra le tante configurazioni disponibili, è sicuramente interessante la possibilità di accendere e spegnere automaticamente le VM del laboratorio, come mostrato in figura:

Figura 9: Accensione automatica delle VM nel DevTest Lab

Per maggiori informazioni sulle policy vi rimando alla lettura dell’articolo Gestire tutti i criteri per un lab in Azure DevTest Labs

Acceso alle VM del DevTest Lab

Una volta che il DevTest Lab è stato creato e configurato e dopo aver effettuato il Claim delle VM, vi potrete connettere alla VM cliccando sul nome e selezionando il pulsante Connect

Figura 10: Connessione alla VM disponibile nel DevTest Lab

Sicuramente interessante è la parte di gestione dei costi. La funzionalità di gestione dei costi consente di tenere traccia dei costi del lab e di visualizzare i costi stimati del mese in corso fino alla data odierna e la proiezione dell’ammontare dei costi a fine mese. È anche possibile impostare dei Target e dei limiti.

Figura 11: Proiezione dei costi mensili per le risorse utilizzate nel DevTestLab

Figura 12: impostazione del Target mensile per il nostro DevTEst Lab

Per maggiori informazioni sulla funzionalità di gestione dei costi vi rimando alla lettura dell’articolo Visualizzare la tendenza dei costi mensili stimati per il lab in Azure DevTest Labs

Conclusioni

L’utilizzo dei DevTest Lab permette alle aziende di tenere sotto controllo i costi per la gestione degli ambienti di test e di sviluppo e ne automatizza l’accensione e lo spegnimento, con un notevole risparmio economico ed una migliore gestione tramite la specifica di limiti e quote. Utilizzando i template personalizzati e gli Artifacts siamo in grado di velocizzare notevolmente la realizzazione del lab e di permettere dei test rapidi ed efficienti.

Buon lavoro!

Nic

Azure Site Recovery è un servizio che permettere di poter replicare in Microsoft Azure le nostre macchine fisiche on-premises e le nostre macchine virtuali Hyper-V oppure VMware, per poterle avviare nel momento in cui si verifica un disastro. Ho già avuto modo di affrontare in diversi articoli come proteggere macchine virtuali VMware e come proteggere e migrare server fisici con Azure Site Recovery. Per chi volesse sapere cosa offre e come funziona Azure Site Recovery consiglio la lettura del documento Informazioni su Site Recovery.

In questo articolo vi voglio parlare di come effettuare il Disaster Recovery (DR) di una macchina virtuale ospitata in Microsoft Azure.

Il servizio, disponibile solo da pochi giorni, permette di replicare una macchina virtuale da una Region di Azure verso un’altra Region, in modo tale che se il sito primario non sia disponibile (per un disastro, per problemi di connettività, ecc..) la macchina virtuale possa essere accesa nel sito secondario e sia già pronta per poter eseguire le applicazioni.

Creazione del Recovery Service Vault

Prima di procedere all’abilitazione della replica della nostra Azure VM è necessario creare un Backup and Site Recovery Vault. Collegatevi al portale di Azure e dopo esservi autenticati create un nuovo Recovery Services Vault, come mostrato in figura. Quando create il Recovery Services Vault considerate sempre due fattori:

• Il Recovery Services Vault non si deve trovare nella Region di Azure dove si trovano le Azure VM da proteggere
• Il Resource Group in cui inserite il Recovery Services Vault non deve essere nella Region delle VM da proteggere

Le due condizioni sono necessarie perché, in caso di disastro nella Region dove sono ospitate le VM, non sarebbero disponibili né Resource Group né Recovery Services Vault!

Figura 1: Creazione del Recovery Services Vault in una Region diversa da quella dove sono ospitate le Azure VM da proteggere

Protezione delle Azure VM

Terminata la creazione del Recovery Services Vault siamo pronti per proteggere le nostre Azure VM. Dal portale di Azure vi basterà selezionare la VM da proteggere e cliccare sul collegamento Disaster Recovery. Nel blade che si aprirà configurate la Region di destinazione della replica della vostra VM ed il Resource Group, la VNET, lo Storage Account e tutti gli altri parametri richiesti, come mostrato in figura:

Figura 2: Configurazione della Replica della VM e Replication settings

Attenzione: Per poter abilitare la replica della VM è necessario che nella macchina virtuale sia installato l’Azure VM agent. Nel caso non lo fosse o nel caso non rispondesse alle richieste del portale riceverete un messaggio come quello mostrato in figura:

Figura 3: Messaggio di errore nel caso l’Azure VM agent non sia installato o non funzioni

L’abilitazione della replica dura diversi minuti. Potete controllare lo stato della replica dalle notifiche, come mostrato in figura:

Figura 4: Notifiche sulla creazione degli oggetti necessari alla replica della VM

Selezionando la VM e cliccando su Disaster Recovery sarà possibile visualizzare il Site Recovery Job iniziale di abilitazione della replica, come mostrato in figura:

Figura 5: Informazioni sullo stato di replica della Azure VM

Figura 6: Job di abilitazione della replica

Dal blade del Disaster Recovery sarà sempre possibile tenere sotto controllo lo stato di replica della VM e sarà possibile modificare i parametri. Cliccate sul tasto Settings e modificate i parametri della VM replicata. Potete ad esempio decidere in quale Resource Group accenderla e a quale VNET collegarla, oltre ovviamente alla dimensione che deve avere.

Figura 7: Configurazioni della VM replicata

Test del Failover

È sempre buona norma testare periodicamente il failover e verificare che tutto funzioni nella VM che avete replicato. Per effettuare il test vi basta cliccare su Test Failover e seguire le istruzioni. Vi verrà chiesto il Recovery Point che volete testare e la Azure VNET a cui collegare la VM.

Figura 8: Failover Test della VM

Dopo qualche minuto, nel Resource Group dove avete deciso di avviare la macchina per testare il Failover, apparirà la VM e vi ci potrete collegare per poter verificare che tutto funzioni perfettamente.

Figura 9: Macchina virtuale di test per il Failover

Dopo le opportune verifiche potete cliccare su Cleanup test failover e cancellare la macchina virtuale di test, come mostrato in figura:

Figura 10: Cleanup test failover

Failover della Azure VM

Per poter eseguire il Failover della Azure VM è sufficiente cliccare sul pulsante Failover e dal blade scegliere quale Recovery Point applicare e se spegnere la macchina prima di iniziare il failover. Lo spegnimento della macchina ha senso ovviamente in un Failover programmato e non in caso di vero disastro

Figura 11: Failover della Azure VM nella seconda Region di Azure

Terminato il Fialover potete decidere anche di cambiare recovery point utilizzando il pulsante Change recovery point oppure confermare la scelta fatta utilizzando il pulsante Commit. Dopo aver effettuato il Commit però non sarà più possibile modificare il Recovery Point.

Figura 12: Commit della macchina virtuale e completamento del Failover

Terminato il disastro è possibile riproteggere la Azure VM utilizzando il pulsante Re-protect. La macchina verrà replicata nuovamente verso la Region di partenza, ma se volete potete cliccare sul pulsante Customize e modificare i parametri, scegliendo il Resource Group, la VNET, lo Storage Account e l’Availability Set della macchina di destinazione.

Figura 13: Re-protect della Azure VM

Conclusioni

Il Disaster Recovery è decisamente importante vista la nostra dipendenza dai sistemi IT. Nonostante tutti gli sforzi profusi, può capitare sempre che accada qualcosa di imprevisto che interrompa la possibilità di usufruire dei servizi. Nonostante il Cloud sia stato concepito per essere affidabile, è buona norma essere sempre preparati al peggio. La replica delle VM di Azure è sicuramente una funzionalità interessante per essere certi di poter gestire un disastro importante e per assicurare alle aziende che hanno anche degli obblighi contrattuali o delle esigenze molto stringenti in ambito di Disaster Recovery di poter usufruire delle VM ospitate in Azure ed essere compliant con le loro specifiche.

Per approfondimenti potete visitare la pagina Set up disaster recovery for Azure VMs to a secondary Azure region

Vi invito anche a leggere l’articolo Azure resiliency technical guidance: recovery from a region-wide service disruption, che vi spiega quali sono le strategie da adottare nel caso un’intera regione di Azure non sia disponibile.

La necessità di rendere utilizzabili al di fuori del perimetro aziendale le applicazioni interne è un’esigenza ormai quotidiana, ma la disponibilità esterna di queste risorse costringe necessariamente chi amministra l’infrastruttura ad “aprire le porte” verso Internet, con tutte le implicazioni dal punto di vista della sicurezza che questo comporta.

Sono state e sono tutt’ora utilizzate una serie di tecniche di mitigazione, ad esempio l’impiego di proxy a reverse con l’utilizzo di sistemi di re-writing degli URL, che consentono una separazione netta delle connessioni in ingresso e forniscono una certa sicurezza sulle risorse esposte.

Questa architettura permette la collocazione in DMZ di sole macchine con il compito di gestire le richieste in ingresso e ridirigerle poi, con alcune regole di controllo all’interno. In questo modo le infrastrutture sensibili non hanno contatto diretto con l’esterno.

Contestualmente a questi accorgimenti l’adozione di sistemi IDS/IPS “garantiscono” un accettabile livello di sicurezza.

In ogni caso questo approccio ha richiesto e richiede che il firewall perimetrale consenta la connessione ed “apra” almeno una porta verso l’interno, richiede anche che i vari apparati posti a controllo del perimetro siano costantemente aggiornati e verificati

Azure Active Directory Application Proxy

In Microsoft Azure è disponibile un servizio che si lega in modo stretto con Azure Active Directory e che in maniera concettualmente del tutto nuova permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda.

Questo servizio è Azure Active Directory Application Proxy, disponibile con la versione BASIC o PEMIUM di Azure Active Directory.

Per poter utilizzare la funzione di Application Proxy, dal portale di Azure è sufficiente, selezionata la Directory di riferimento, attivare la funzionalità in prova valida per 30 giorni e successivamente terminata la fase di test, effettuarne l’acquisto.

Figura 1: Abilitazione servizi AAD Premium

Figura 2: Attivazione di Azure AD Premium P2 Trial

Attivata la funzionalità di Azure AD Premium è necessario installare il componente Application Proxy Connector. La scelta più corretta è quella di dedicare un sistema server a questa funzione, scelta che permette una migliore scalabilità delle risorse e di gestione.

Figura 3 Download componente Connector

Per configurare correttamente regole di uscita dell’Application Proxy è utile la lettura del documento Attività iniziali del proxy di applicazione e installazione del connettore

Mentre per un controllo diretto ed una verifica puntuale della configurazione è disponibile il tool Azure Active Directory Application Proxy Connector Ports Test Tool

È anche possibile permettere che il Connector interno utilizzi per collegarsi ad Azure un Web Proxy , questo qualora non fosse possibile agire direttamente sul Firewall per definire regole puntuali di uscita.

In questo caso è bene considerare che un possibile malfunzionamento del Web Proxy stesso si ripercuoterebbe necessariamente sulla raggiungibilità delle applicazioni.

L’aspetto interessante, relativo alla sicurezza del sistema, è che NON è richiesto che in ingresso venga definita alcuna regola sul Firewall.

L’applicazione che è utilizzata esternamente sarà disponibile tramite il portale Azure e sarà la componente Application Proxy che si occuperà di renderla accessibile e di “dialogare” con il Connector interno, che è la sola componente ad avere contatti con l’applicazione in rete locale.

Per analogia con il sistema tradizionale a Reverse Proxy il Connector è un Reverse Proxy, con la sola ma importante differenza che questo, come detto sopra, non ha contatti con l’esterno ma riceve e reindirizza le richieste dalla componente cloud.

Figura 4: Principio di funzionamento di Azure Active Directory Application Proxy

A questo punto è evidente che l’infrastruttura di sicurezza Aziendale può essere “alleggerita” in quanto come già detto non è richiesto che siano attivate porte in ascolto, questo compito è demandato ad Azure.

Pubblicazione di una applicazione interna tramite Azure AD Application Proxy

Dal portale di Azure selezionare la directory in cui si è abilitata la funzione e successivamente selezionare Configura un’app

Figura 5: Aggiunta dell’applicazione on-premises da esporre

Nella maschera successiva scegliere “Add your own on-premises application”

Verrà così proposta una ulteriore videata con le specifiche proprie dell’applicazione che si intende pubblicare

• Nome serve ad identificare l’applicazione all’interno del portale di accesso e di configurazione
• URL interno è l’effettivo URL che il connettore installato on premise contatterà (di norma l’Url dell’applicazione interna)
• URL Esterno è il riferimento
  pubblico per la raggiungibilità dell’applicazione interna, nel caso si usi un dominio Custom, questo è selezionabile dalla casella
• Metodo di Autenticazione Preliminare è effettivamente la modalità con cui gli utenti accederanno all’autenticazione dell’applicazione.

Con la modalità Azure AD l’utente verrà effettivamente autenticato con i servizi di Azure e quindi beneficiando anche di quelle che sono le prerogative di questi utenti: gestione Self-Service della password, possibilità di definire criteri di sblocco personalizzati, accesso da dispositivi con determinate caratteristiche etc.

Con la modalità Passtrough invece, all’utente viene proposto direttamente (se previsto) il login dell’applicazione interna.

Nel caso in cui sia impostata la modalità Azure AD e l’applicazione (tipicamente legacy) non sia in grado di utilizzare di questa modalità, verrà richiesta una seconda autenticazione.

A questo punto è possibile accedere all’applicazione, è da notare che di default tutto il traffico è in HTTPS e viene utilizzato un certificato generato per il nome host definito.

Tuttavia, siccome si possono anche gestire URL esposti in Azure con FQDN del proprio dominio pubblico è possibile effettuare l’upload di un certificato aziendale.

Controllo delle funzionalità del Connector Gateway

Questo oggetto non ha particolari opzioni di configurazione, all’atto dell’installazione, viene richiesto un account amministratore globale della directory e con questo il gateway si registra ed autentica sulla directory stessa.

È possibile all’interno del registro eventi rilevare eventuali errori o anomalie archiviate in AadApplicationProxy (fig.6)

Sono anche disponibili, al fine di valutare le performance di questo servizio alcuni Performance Counters (fig.7)

Figura 6: Contatori disponibili per la verifica delle performance del servizio

Figura 7: Aggiunta dei contatori

Considerazioni relative agli aspetti di sicurezza

Controllo tramite NMAP delle informazioni deducibili tramite un port SCAN

Al di là delle considerazioni espresse in precedenza, un piccolo e sicuramente approssimativo test relativo agli aspetti legati alla sicurezza è stato condotto utilizzando NMAP.

Tramite questo tool si è cercato di identificare il sistema operativo sul quale l’applicazione è installata.

Sono stati effettuati due TEST distinti, il primo verso una applicazione esposta in modo tradizionale FWàRev-ProxyàApplicazione

Figura 8: Scansione verso l’esposizione con Reverse Proxy tradizionale

Nmap seppure con una certa approssimazione ha rilevato un host Linux fig. sopra

Ed il secondo sempre verso la stessa applicazione ma esposta tramite AZURE con la struttura descritta sopra

Figura 9 Scansione verso l’esposizione con Azure Application Proxy

Nmap non è riuscito ad identificare il sistema verso il quale ha fatto la scansione.

Conclusioni

Partendo dall’assunto che non esiste LA soluzione perfetta, sicura e garantita e vista anche la velocità di implementazione e il discreto grado di sicurezza by-default dell’infrastruttura, la soluzione di Azure Application Proxy può essere un valido aiuto alle realtà che necessitano di rendere fruibili le proprie applicazioni all’esterno del perimetro aziendale.

Riferimenti:

Azure Application Proxy Connector

Azure Application Proxy Connector – connessione tramite proxy interno

Risoluzione dei problemi relativi alla pubblicazione di applicazioni tramite Azure

Sicurezza

Abbiamo visto nel precedente articolo Creare DevTest Labs in Microsoft Azure come il servizio DebTest Labs consenta agli sviluppatori o ai tester di creare un ambiente in Azure che permetta di tenere sotto controllo i costi e allo stesso tempo permetta di effettuare tutti i test applicativi utilizzando sia macchine Windows che macchine Linux. L’evoluzione di questo servizio, che attualmente è in Preview, si chiama Azure Lab Services ed è un servizio che permette di creare un ambiente per lo sviluppo oppure un laboratorio da utilizzare per uso scolastico.

Il proprietario di un Lab crea un laboratorio, esegue il provisioning delle macchine virtuali Windows o Linux, installa il software e gli strumenti necessari e li rende disponibili per gli utenti del lab. Gli utenti del lab si connettono alle macchine virtuali del lab e le possono utilizzare per poter effettuare attività giornaliere oppure per svolgere i compiti scolastici. In ogni caso sarà possibile tenere sempre sotto controllo i costi del laboratorio e questo permette di ottimzizare l’utilizzo delle risorse a disposizione.

Diversi sono i vantaggi offerti dagli Azure Lab Services ed in particolare vi evidenzio:

• Configurazione veloce e flessibile di un lab. Tramite Azure Lab Services, i proprietari di lab possono configurare velocemente un lab per le loro esigenze ed il servizio offre scalabilità e resilienza dell’infrastruttura.
• Esperienza semplificata per gli utenti dei lab. Gli utenti del lab possono eseguire la registrazione a un lab con un codice di registrazione e accedervi in qualsiasi momento per usare le risorse del lab.
• Analisi e ottimizzazione dei costi. Il proprietario del lab può impostare pianificazioni del lab per arrestare e avviare automaticamente le macchine virtuali. Può anche specificare le fasce orarie in cui le macchine virtuali del lab saranno accessibili agli utenti, impostare i criteri di utilizzo per ciascun utente o lab per ottimizzare i costi, nonché analizzare le tendenze di utilizzo e attività in un lab.
• Sicurezza incorporata. Gli utenti del lab possono accedere in modo sicuro alle risorse tramite la rete virtuale configurata con ExpressRoute o con VPN da sito a sito. (attualmente non disponibile nella Preview)

In questo articolo creerò un laboratorio da utilizzare in una classe, per permettere agli studenti di lavorare con le macchine virtuali ed eseguire i compiti scolastici.

Creazione del laboratorio

Per poter creare il laboratiorio vi basta loggarvi al portale di Azure e creare una nuova risorsa di tipo Lab Services, come mostrato in figura:

Figura 1: Creazione di un nuovo Lab Service

Dopo aver atteso la creazione di un nuovo Lab Account, dalla scheda Overview, cliccate sul collegamento per poter aggiungere un nuovo Lab Creator. Il Lab Creator è un ruolo che permetterà al docente di poter creare una classe per i propri studenti oppure permetterà di creare un ambiente di test o di demo.

Figura 2: Aggiunta del Lab Creator

Figura 3: Configurazioni del ruolo di Lab Creator e dei permessi per la creazione del lab

Una volta che avrete deciso a chi concedere i privilegi di Lab Creator potrete far collegare il lab creator al sito web di Azure Lab Services. Dopo essersi autenticato gli verrà chiesto di confermare le autorizzazioni di accesso richiesta dall’ap Azure Lab Services, come mostrato in figura:

Figura 4: Conferma dell’accesso e autorizzazioni per Azure Lab Services

Il Lab Creator a questo punto è pronto per creare un nuovo laboratorio, cliccando sul pulsante New Lab. Oltre a fornire il nome del laboratorio, gli verrà chiesto la dimensione delle VM da utilizzare, la versione del sistema operativo (Windows o Linux) e le credenziali di accesso alla VM, come mostrato in figura. È possibile modificare la dimensione delle VM da utilizzare nel lab seguendo le istruzioni dell’articolo Use PowerShell to set allowed VM sizes in Azure Lab Services ed aggiungere altre immagini delle VM oltre a quelle proposte di default, seguendo le istruzioni dell’articolo Use PowerShell to add a marketplace image to a lab in Azure DevTest Labs

Figura 5: Creazione di un nuovo laboratorio

Figura 6: Immagini delle macchine virtuali disponibili di default

Dopo qualche istante sarà possibile, dalla Dashboard del Lab, accedere alle configurazioni. Attendete che venga completata la creazione della VM e, dopo averla avviata, configurate il template della macchina virtuale con tutte le caratteristiche che volete fornire agli utenti del lab. Collegatevi alla macchina in desktop remoto ed effettuate le personalizzazioni che desiderate (installazione di software, configurazioni).

Figura 7: Creazione del laboratorio completata

Terminate le configurazioni del template potete modificarne i dettagli, per fornire ai vostri studenti/utenti maggiori informazioni sulla VM.

Figura 8: Modifica dei dettagli del template

A questo punto potete pubblicare il template facendo clic sul pulsante Publish. Una volta che il template è stato pubblicato non sarà più possibile modificarlo.

Figura 9: Pubblicazione del template della VM

Configurazione dei criteri di utilizzo del laboratorio

È possibile definire dei criteri di utilizzo del laboratorio, come ad esempio il numero massimo di utenti che potranno utilizzarlo. Per poter definire la policy vi basterà cliccare su Usage Policy e definire il numero massimo di utenti consentito, come mostrato in figura:

Figura 10: Definizione della Usage Policy del Lab

Dopo aver stabilito il numero massimo di macchine virtuali da creare nel vostro Lab (nella Preview potete creare un massimo di 5 VM), potrete registrare i vostri utenti e dargli la possibilità di accedere al laboratorio.

Figura 11: Creazione delle VM nel Lab

Prossimamente sarà possibile anche limitare l’utilizzo del laboratorio a determinati periodi della giornata. Al momento la funzionalità non è ancora disponibile.

Figura 12: Abilitazione della programmazione della disponibilità del Lab

Utilizzo del Lab

Per permettere l’utilizzo del lab ai propri studenti ed ai propri collaboratori sarà necessario prima aggiungere gli utenti utilizzando il pulsante User registration e successivamente inviare il link che verrà generato a chi dovrà utilizzare il lab.

Figura 13: Generazione del link per poter permettere agli studenti di poter accedere al laboratorio

Dal portale amministrativo sarà possibile verificare le assegnazioni e lo stato della macchina virtuale, come mostrato in figura:

Figura 14: verifica delle assegnazioni delle VM disponibili nel Lab

Collegamento al Lab

A questo punto chi riceverà il link dovrà collegarsi al sito web di Azure Lab Services e dopo aver inserito le credenziali dell’organizzazione (quindi di Azure AD) ed aver accettato le autorizzazioni da dare agli Azure Lab Services, potrà cominciare ad utilizzare la macchina virtuale del laboratorio che gli è stata assegnata. Nella schermata principale vedrà le VM a cui gli è stato consentito l’accesso e, dopo averle avviate, potrà collegarsi in desktop remoto utilizzando le credenziali fornite dal Lab Creator.

Figura 15: Dopo l’accesso al portale degli Azure Lab Services l’utente vedrà le VM che gli sono state assegnate

Figura 16: Accesso alla VM del Lab dopo l’accensione

Dal portale di amministrazione il Lab Creator può tenere sotto controllo la situazione, può avviare/stoppare la macchina virtuale, può connettersi in desktop remoto per dare assistenza all’utilizzatore della VM

Figura 17: Gestione delle VM del Lab dal portale amministrativo

Conclusioni

Azure Lab Services può essere usato per implementare molti scenari. Uno dei più importanti prevede la possibilità di ospitare computer di sviluppo per gli sviluppatori oppure è un’interessante soluzione per implementare laboratori scolastici nel Cloud. Un docente può creare un laboratorio, installare macchina virtuali Windows o Linux, installare il software necessario per le esercitazioni e rendere disponibili le VM ai propri studenti. Vedremo nella versione finale cosa sarà disponibile, intanto proviamo la preview

Buon lavoro!

Nic

Gli Storage Spaces sono una tecnologia introdotta in Windows Server 2012 ed in Windows 8 che permette di poter proteggere i nostri dati nel caso ci sia un’avaria di uno o più dischi fisici. Si tratta dell’implementazione software del concetto di RAID, il cui scopo è aumentare le performance, rendere il sistema resiliente alla perdita di uno o più dischi e poterli rimpiazzare senza interrompere il servizio.

Con gli Storage Spaces Microsoft introduce un tecnologia che permette di implementare quello che si chiama Software Defined Storage (SDS), che permette di poter collegare alla macchina una serie di dischi (JBOD) e di poter ottenere le stesse funzionalità di una SAN (Storage Area Network).

Si parte dalla creazione di uno Storage Pool (cioè un insieme di dischi fisici) e si crea lo Storage Space, sotto forma di disco virtuale. Il disco virtuale creato viene poi formattato e visualizzato come volume nel sistema operativo.

Figura 1: Principio di funzionamento degli Storage Spaces

In Windows Server 2012 R2 è stata introdotta una nuova tecnologia chiamata Storage Spaces Tiering, che permette di utilizzare dischi diversi (SSD e HDD) all’interno dello stesso Storage Pool. Il vantaggio principale offerto dagli Storage Spaces Tiers è quello di poter conservare i dati che vengono acceduti più frequentemente sui dischi SSD e di spostare i dati più “freddi” sui dischi meccanici HDD, più capienti e decisamente meno costosi.
In questo modo si aumentano di molto le performance offerte dallo storage e l’ottimizzazione avviene in maniera automatica e schedulata.

Creazione dello Storage Pool

Nel mio laboratorio ho utilizzato 4 dischi SSD da 512 GiB ed 8 dischi HDD da 2 TiB. Utilizzando il Server Manager mi sono spostato nel nodo File and Storage Services e ho selezionato Storage Pools. Come si vede dall’immagine sotto, i dischi sono virtuali (sto usando una VM) e vengono visti come dischi SAS. Per creare un nuovo Storage Pool basta cliccare sul pool Primordial e col tasto destro scegliere New Storage Pool

Figura 2: Wizard per la creazione di un nuovo Storage Pool

Date un nome al pool di dischi (nel mio caso si chiamerà Pool1) e cliccate su Next

Figura 3: Nome del Pool di dischi

Nel passaggio successivo verranno mostrati i dischi fisici collegati alla vostra macchina. Potete decidere di utilizzarli tutti o in parte (potete creare diversi Pool) e se saranno inseriti automaticamente nel Pool e quindi contribuiranno fin da subito. È anche possibile utilizzare alcuni dischi come Hot Spare, cioè verranno utilizzati per rimpiazzare dei dischi che eventualmente dovessero subire un guasto.

Figura 4: Allocazione dei dischi (Automatica, Manuale o Hot Spare)

Selezionate quindi i dischi da aggiungere al Pool. Io li ho aggiunti tutti e ho allocato un disco SSD ed un disco HDD di Hot Spare, come mostrato in figura:

Figura 5: Scelta dei dischi da aggiungere al Pool

Figura 6: Conferma delle configurazioni scelte per la creazione dello Storage Pool

Cliccando su Create verrà creato lo Storage Pool. Il processo di creazione dura una manciata di secondi.

Figura 7: Creazione dello Storage Pool

Creazione del Virtual Disk

Terminata la creazione dello Storage Pool, il passaggio successivo consiste nella creazione del Virtual Disk, che poi verrà trasformato in Volume. Dal Server Manager avviate il wizard per la creazione del virtual disk come mostrato in figura:

Figura 8: Wizard per la creazione del Virtual Disk

Poiché nel mio laboratorio sto utilizzando dei vhdx, questi non riescono a far capire a Windows Server il loro Media Type (viene visualizzato come Unknown) e nel momento in cui decido di creare il nuovo Virtual Disk mi accorgo che non è possibile abilitare gli Storage Tiers. È infatti necessario che nello Storage Pool sia disponibile almeno un disco SSD ed almeno un disco HDD.

Figura 9: Creazione degli Storage Tiers non disponibile

Per ovviare a questo problema sarà sufficiente utilizzare un paio di comandi Powershell per sistemare il Media Type dei dischi. Aprite un prompt di PowerShell con privilegi elevati per verificare il Media Type

Get-StoragePool Pool1 | Get-PhysicalDisk | FT FriendlyName, MediaType, Size

Lanciate il seguente comando per modificare il Media Type di tutti i dischi più piccoli di 1 TiB e configurarli come SSD (io ho 4 dischi da 512 GiB che simuleranno gli SSD)

Get-StoragePool Pool1 | Get-PhysicalDisk | ? Size -lt 1TB | Set-PhysicalDisk –MediaType SSD

Lanciate il seguente comando per modificare il Media Type di tutti i dischi più grandi di 1 TiB e configurarli come HDD (io ho 8 dischi da 2 TiB che simuleranno gli HDD)

Get-StoragePool Pool1 | Get-PhysicalDisk | ? Size -gt 1TB | Set-PhysicalDisk –MediaType HDD

Nella figura sotto sono mostrati i risultati dell’operazione:

Figura 10: Modifica degli Media Type dei dischi

A questo punto vi basterà effettuare il refresh nella console del Server Manager per verificare che il Media Type sia stato configurato correttamente

Figura 11: Media Type dei dischi configurato correttamente

Se rilanciate il wizard vedrete che adesso sarà possibile abilitare gli Storage Tiers.

Figura 12: Abilitazione degli Storage Tiers

Una novità introdotta in Windows Server 2016 è l’Enclosure Resiliency. Il sistema operativo si rende conto che i dischi fisici si trovano su Enclosures diversi e quindi quando verrà creato il virtual disk verranno utilizzati dischi fisici in modo che i dati sia presenti su enclosures diversi e che siano disponibili anche se dovesse subire un guasto l’intero enclosure.

Figura 13: Enclosure Awareness ed Enclosure Resiliency

Il volume che voglio creare è un volume di tipo Mirror (simile ai RAID1), che mi permette di avere molta affidabilità anche se a scapito di maggior spazio utilizzato.

Figura 14: Creazione di un virtual disk con funzionalità Mirror

Scelgo anche di creare il virtual disk in modalità There-way Mirror, in modo tale da avere 3 copie del dato ed potervi accedere anche nel caso in cui ci fosse il guato contemporaneo di due dischi fisici.

Figura 15: Configurazione Three-Way Mirror contro la perdita contemporanea di due dischi fisici

Figura 16: Quando di usano gli Storage Tiers è possibile usare solo il fixed provisioning

Scegliete, in base allo spazio a disposizione, la dimensione che avrà il virtual disk. Nel mio esempio voglio creare un disco da 1 TiB utilizzando 265 GiB per il Faster Tier (SSD) e 768 GiB per lo Standard Tier (HDD).

Figura 17: Dimensioni del Virtual Disk e relative specifiche per i Tiers

Confermate le configurazioni scelte e fate clic su Create.

Figura 18: Conifera delle configurazioni del Virtual Disk

La creazione del Virtual Disk dura pochissimi secondi.

Figura 19: Creazione del disco completata

Dalla console Disk Management potrete notare che adesso c’è un nuovo disco, da formattare, della dimensione di 1 TiB.

Figura 20: il Virtual Disk creato è visibile dalla console di Disk Management

Il volume potrà essere creato dalla stessa console di Disk Management oppure dal Server Manager. Se avete lasciato attivato il segno di spunta su Create a volume when this wizard closes nel wizard di creazione del Virtual Disk, vi si aprirà un nuovo wizard per la creazione del Volume.

Figura 21: Selezione del virtual disk su cui creare il Volume

Figura 22: Il Volume deve avere la stessa dimensione del Virtual Disk perché stiamo utilizzando gli Storage Tiers

Assegnate una lettera al Volume.

Figura 23: Assegnazione della lettera al nuovo Volume

Decidete l’etichetta per il nuovo Volume. Potrete formattare il nuovo Volume solo con il File System NTFS perché gli Storage Tiers non permettono di formattare utilizzando il File System REFS.

Figura 24: Etichetta del Volume e File System

Figura 25: Conferma delle configurazioni per la creazione del nuovo Volume

La creazione del nuovo Volume dura pochi secondi

Figura 26: Creazione del Volume completata

Figura 27: Il nuovo Volume è visibile in Esplora Risorse

Processo di ottimizzazione degli Storage Tiers

Windows Server si occupa di ottimizzare in maniera trasparente ed automatica le performance dello storage, spostando i dati che vengono acceduti più frequentemente nel Faster Tier, più veloce ma più costoso e spostando quelli meno utilizzati nello Standard Tier, più lento ma più economico. Durante la giornata gli Storage Spaces creano una heat map dei dati in base a quanto spesso ogni pezzo di dato viene acceduto. Il dato è mappato e spostato tra i diversi livelli, rendendo la fruizione dello stesso molto più perfomante.

Figura 28: Processo di ottimizzazione degli Storage Tiers

Dopo che il wizard è completato verrà automaticamente abilitata anche un’operazione pianificata che si occuperà di gestire ed ottimizzare gli Storage Tiers. L’operazione verrà ripetuta ogni 4 ore ed eseguirà il comando %windir%\system32\defrag.exe -c -h -g -# -m 8 -i 13500

Figura 29: Operazione pianificata per l’ottimizzazione degli Storage Tiers

Conclusioni

Gli Storage Spaces in generale e gli Storage Spaces Tiers in particolare aggiungono a Windows Server le stesse funzionalità che sono tipiche di una SAN (Storage Area Network), riducendone però costi e vincoli all’utilizzo di particolari dischi. Uno degli investimenti maggiori che Microsoft ha fatto negli ultimi anni nello sviluppo di Windows Server è proprio sul Software Defined Datacenter, una serie di tecnologie che permette all’hardware ad al software di espandersi oltre il tradizionale rapporto uno a uno.

Gli Active Directory Federation Services (ADFS) permettono di identificare, autenticare ed autorizzare gli utenti e di offrire il web single sign-on per applicazioni che non sono ospitate nei server del vostro dominio.

Supponete infatti di voler utilizzare un applicativo web creato da un’azienda esterna alla vostra organizzazione (Resource Partner) e di non voler comunicare a questa azienda username e password dei vostri utenti di dominio (Account Partner). ADFS vi permette di reindirizzare le autenticazioni per l’applicazione web verso il vostro Federation Server e di usare il vostro domain controller come database per le autenticazioni. Basta quindi installare due Federation Server ed aprire un’unica porta (il traffico tra i server è HTTPS) per poter avere la possibilità di loggarsi senza reinserire le credenziali e allo stesso tempo non doverle comunicare a nessuno.

Figura 1: Principio di funzionamento di ADFS

In questo articolo mi occuperò della configurazione di una nuova Farm ADFS in Windows Server 2016. Per conoscere tutte le novità della nuova versione di ADFS vi rimando alla lettura dell’articolo What’s new in Active Directory Federation Services per Windows Server 2016

Prima però di avventurarci nella configurazione vera e propria della nostra Farm ADFS vi consiglio di leggere l’articolo Checklist: Deploying a Federation Server Farm e l’articolo Best practices for securing Active Directory Federation Services

L’infrastruttura tipica di una Farm ADFS è quella presentata nella figura 2. All’interno della LAN abbiamo il domain controller e le macchine in dominio, tra cui i server ADFS, mentre nella DMZ abbiamo il Web Application Proxy, che rimarrà in workgroup e che si occuperà di proteggere le connessioni da Internet verso il server ADFS.

Figura 2: Infrastruttura di ADFS che verrà realizzata

Gestione dei certificati per il Namespace ADFS

Come prima operazione procuratevi un certificato digitale per il nome del vostro ADFS Namespace. Utilizzate le informazioni contenute alla pagina Requisiti del certificato per ADFS per conoscere le caratteristiche che deve avere il certificato da installare su tutti i server della vostra infrastruttura ADFS, compresi i Web Application Proxy.

NOTA: Tutti i server ADFS e i server Web Application Proxy necessitano di un certificato SSL per soddisfare le richieste HTTPS per il servizio federativo. Il certificato da installare deve essere esattamente
lo stesso su tutti i server dell’infrastruttura ADFS.

Nel mio caso utilizzerò il certificato con il nome sts.nicolaferrini.cloud. Dopo che avrete installato lo stesso certificato sia sulla macchina ADFS (in dominio) che sulla macchina Web Application Proxy (in workgroup) potete procedere con la configurazione del server ADFS

Requisiti per il dominio

ADFS 2016 richiede che il controller del dominio sia almeno Windows Server 2008 (il livello funzionale del dominio può invece essere ancora Windows Server 2003) e che tutte le macchine ADFS della Farm siano joinate allo stesso dominio. Per la creazione della Farm ADFS potete utilizzare uno standard service account oppure un Group Managed Service Account (gMSA). Per utilizzare un gMSA è necessario che i domain controller sia almeno Windows Server 2012 e uno dei vantaggi più evidenti del loro utilizzo è che la password dell’account viene aggiornata automaticamente.

Io preferisco utilizzare i Group Managed Service Account (gMSA),
e poiché sto usando un ambiente nuovo ed è la prima volta che ne creo uno devo prima creare la Key Distribution Services KDS Root Key, necessaria al domain controller per generare le password dei gMSA. Per poter creare la chiave è sufficiente eseguire, con privilegi elevati, in un domain controller il seguente comando PowerShell

Add-KdsRootKey –EffectiveImmediately

I domain controller aspetteranno fino a 10 ore dal momento della creazione della chiave prima di poter permettere la creazione di un Group Managed Service Account (gMSA), in modo tale da consentire a tutti i domain controller presenti nel dominio di poter replicare la chiave appena creata. In un ambiente di laboratorio potete accelerare questa operazione eseguendo con privilegi elevati in un domain controller il seguente comando PowerShell:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)

Figura 3: Creazione della Key Distribution Services KDS Root Key per la generazione delle password dei Group Managed Service Account (gMSA).

Requisiti per il database di ADFS

Per l’installazione di ADFS è possibile utilizzare sia il Windows Internal Database (WID) che Microsoft SQL Server (sono supportate le versioni SQL Server 2008 e successive). Per maggiori informazioni vi rimando alla lettura dell’articolo Requisiti del database di configurazione di una Farm ADFS. In questo articolo utilizzerò il Windows Internal Database.

Installazione del primo server della Farm ADFS

Aprite il Server Manager in Windows Server 2016 e lanciate il wizard per l’aggiunta di un nuovo ruolo. Io sto utilizzando la macchina ADFS1.cloud. lab, che ho joinato al dominio, e procedo all’installazione del ruolo di Active Directory Federation Services, come mostrato in figura:

Figura 4: Installazione del ruolo Active Directory Federation Services

Figura 5: Riepilogo delle funzionalità offerte dal ruolo ADFS

Figura 6: Installazione del ruolo ADFS completata

Cliccando sul collegamento Configure the federation service in this server potrete lanciare il wizard che vi permetterà di creare il primo server della vostra Farm ADFS. Verificate anche dal link AD FS prerequisites di aver completato tutti i prerequisiti d’installazione e procedete cliccando su Next.

Figura 7: Creazione del primo Federation Server nella Farm

Figura 8: Account di dominio da utilizzare per la configurazione del server ADFS

Nella schermata successiva scegliete dal menù a tendina il certificato da utilizzare (che dovrete aver precedentemente installato) ed il Federation Service Name, che vi servirà successivamente per configurare il Web Application Proxy. Indicate anche il nome da visualizzare nella pagina di autenticazione di ADFS.

Figura 9: Certificato, Federation Service Name e nome della Farm ADFS da creare

Nella schermata successiva specificate il Service Account che farà girare i servizi ADFS. Utilizzerò, come già detto, un Group Managed Service Account chiamato ADFSservice

Figura 10: Creazione del Group Managed Service Account

Figura 11: Utilizzo del Windows Internal Database (WID)

Figura 12: Schermata riassuntiva delle configurazioni scelte

Figura 13: Controllo dei prerequisiti

Figura 14: Configurazione della Farm ADFS completata

La creazione della Farm ADFS è completata, ma è necessario riavviare la macchina. Notate alcuni warning che mi sono apparsi nella schermata finale. I warning si riferiscono ad alcuni nomi che mancano nel certificato (certauth.sts.nicolaferrini.cloud e enterpriseregistration.nicolaferrini.cloud). La mancanza di questi nomi non permetterà di registrare i dispositivi tramite ADFS e non permetterà l’autenticazione tramite certificato (novità della versione 4.0 di ADFS). Ricordatevi quindi di utilizzare certificati di tipo SAN con tutti i nomi. Il certificato corretto da utilizzare nel mio dominio avrebbe dovuto includere questi nomi:

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

Dopo il riavvio potete connettervi alla AD FS Management console e verificare le configurazioni del vostro server. Aprendo le proprietà potrete accertarvi di aver utilizzato i nomi corretti, come mostrato in figura:

Figura 15: ADFS Management console e Federation Service Properties

Creazione della zona DNS e record per il server ADFS

Per permettere la corretta risoluzione dei nomi del server ADFS ho creato nel domain controller una zona con il nome pubblico nicolaferrini.cloud e ho creato un record host per sts.nicolaferrini.cloud, in modo tale che le macchine interne sappiano come contattare il server ADFS. Il dominio interno ed il dominio esterno infatti differiscono ed è necessario configurare correttamente la risoluzione dei nomi.

Figura 16: Creazione della zona e del record DNS per il server ADFS

Verifica della funzionalità ed accesso alla pagina di Sign-In

ADFS in Windows Server 2016 disabilita di default la pagina idpinitiatedsignon, utile per testare se l’installazione è avvenuta correttamente. È possibile riabilitarla lanciando sul server ADFS il comando Powershell, eseguito con privilegi elevati

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Figura 17: Abilitazione della pagina idpinitiatedsignon

Collegatevi quindi all’indirizzo https://<FQDN DEL SERVER ADFS>/adfs/ls/idpinitiatedsignon.htm per verificare che tutto funzioni. Nel mio caso ho digitato l’indirizzo https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm e ho potuto verificare di avere accesso alla pagina di Sign-In

Figura 18: Verifica dell’accesso alla pagina di Sign-In

È anche possibile verificare che sia attivo l’url relativo ai Federation Service Metadata collegandosi a https://<FQDN DEL SERVER ADFS>/federationmetadata/2007-06/federationmetadata.xml. Nel mio caso ho utilizzato l’indirizzo https://sts.nicolaferrini.cloud/federationmetadata/2007-06/federationmetadata.xml

Figura 19: Verifica dell’accesso ai Federation Service Metadata

Aggiunta dei altri server ADFS alla Farm esistente

In caso il server ADFS non funzionasse i vostri utenti non potrebbero loggarsi. È quindi opportuno aggiungere un ulteriore server alla Farm ADFS che avete appena realizzato. La procedura è ben descritta nell’articolo Add a Federation Server to a Federation Server Farm. Dopo aver aggiunto il secondo server alla Farm sarà necessario anche utilizzare un bilanciatore di carico a monte dei due server per assicurarne l’alta disponibilità. Ulteriori informazioni sono disponibili alla pagina Load Balancer Requirements for ADFS 2016

Installazione del Web Application Proxy

Il Web Application Proxy (WAP), da installare in DMZ e da lasciare in Workgroup, è necessario per proteggere i server ADFS ed evitare di esporli direttamente ad Internet. Il WAP si comporta da Reverse Proxy e permette l’accesso sicuro alle applicazioni on-premises dall’esterno dell’infrastruttura aziendale. Maggiori dettagli sono disponibili nell’articolo Web Application Proxy in Windows Server 2016

Prerequisiti per la configurazione del proxy

• Installare esattamente lo stesso certificato che avete installato sui server ADFS
• Assicurarsi che il WAP possa risolvere il nome interno del vostro server ADFS o del VIP del vostro Load Balancer
• Creare un record DNS pubblico per il WAP, in modo tale che possa essere contattato dall’esterno
• Aprire le porte del firewall (la porta 443 per l’HTTPS deve essere aperta dall’esterno verso il WAP e dal WAP verso ADFS)

Installazione del Web Application Proxy

L’installazione del Web Application Proxy è molto semplice. Dal Server Manager lanciate il wizard per aggiungere un nuovo ruolo e scegliete il ruolo Remote Access, come mostrato in figura:

Figura 20: Aggiunta del ruolo Remote Access, necessario per l’installazione del Web Application Proxy

Figura 21: Descrizione delle funzionalità offerta dal ruolo Remote Access

Scegliete di installare il role service Web Application Proxy e aggiungete tutte le funzionalità richieste dal ruolo

Figura 22: Installazione del role service Web Application Proxy

Figura 23: Installazione del ruolo completata

Fate clic sul link Open the Web Application Proxy Wizard per lanciare la configurazione del WAP

Figura 24Web Application Proxy Configuration Wizard

Indicate quale sarà il server ADFS a cui dovrà puntare il WAP quando riceverà le richieste di autenticazione ed autorizzazione. Nel mio caso il server è sts.nicolaferrini.cloud

Figura 25: Configurazione del Federation Server da contattare

Figura 26: Scelta del certificato digitale

Figura 27: Comandi PowerShell che verranno eseguiti per la configurazione del WAP

Terminata la configurazione potrete aprire la Remote Access Management console e verificare che tutti i servizi siano perfettamente funzionanti, come mostrato in figura:

Figura 28: Remote Access Management console

Accesso dall’esterno dell’organizzazione

Per verificare che tutto funzioni perfettamente potete collegarvi da una macchina ESTERNA alla vostra infrastruttura e collegarvi al WAP. Modificate il DNS pubblico in modo tale che punti all’IP pubblico del WAP, controllate le configurazioni dei firewall e connettetevi al vostro server (nel mio caso sts.nicolaferrini.cloud) tentando di raggiungere la pagina idpinitiatedsignon, esattamente come avete fatto prima. Se avete configurato tutto correttamente vi collegherete al WAP che inoltrerà la richiesta al server ADFS (o al bilanciatore).

Figura 29: Connessione al server ADFS avvenuta dall’esterno dell’organizzazione, tramite WAP

Accesso dall’interno dell’organizzazione

Se provate a collegarvi da una macchina in dominio, usando qualsiasi browser, alla pagina di autenticazione https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm vi apparirà un messaggio che vi richiederà di inserire le credenziali. Per poter garantire l’accesso automatico dell’utente è prima necessario impostare nella Local Intranet l’url del Federation Server. Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per AD FS.

Figura 30: Richiesta di credenziali anche dalla macchina in dominio

Figura 31: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

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\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Figura 32: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

#Verifica dei client attualmente supportati
Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

#Aggiunta dei browser Firefox, Chrome e Edge
Set-AdfsProperties –WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,“MSIE 6.0”,“MSIE 7.0”,“MSIE 8.0”,“MSIE 9.0”,“MSIE 10.0”,“Trident/7.0”, “MSIPC”,“Windows Rights Management Client”,“Mozilla/5.0”,“Edge/12”)

#Riavvio dei servizio Active Directory Federation Services
Restart-Service ADFSSRV

Figura 33: Modifica dei client che supportano la WIA in ADFS

Conclusioni

I vantaggi offerti dai Federation Services sono notevoli, perché permettono il Single Sign-On ed evitano che le password dei nostri utenti vengano memorizzate al di fuori della nostra organizzazione. Sia per motivi burocratici, che di privacy, sarebbe impossibile rivolgersi a fornitori di servizi esterni, che dovrebbero archiviare e gestire (e quindi mantenere aggiornate) le nostre credenziali. Con ADFS l’autenticazione avviene in azienda e i nostri dati sono al sicuro!

Azure AD Connect è un tool gratuito che integra le directory locali (dominio) con Azure Active Directory. Questo permette di sincronizzare utenti e password on-premises con il tenant di Office 365 e con tutte le applicazioni SaaS che usano Azure AD per l’autenticazione.

In alcuni casi però le aziende preferiscono non sincronizzare le password dei propri utenti con Azure AD. Per poter consentire l’accesso ai servizi cloud si può ricorrere all’autenticazione basata sugli Active Directory Federation Services. Grazie all’accesso federato, gli utenti possono accedere ai servizi basati su Azure AD con le proprie password locali e, se si collegano da un computer all’interno della rete aziendale (joinato al dominio), non devono immettere di nuovo le password per autenticarsi (Single Sign-On).

Per configurare un’infrastruttura basata su ADFS potete leggere il mio articolo Configurare Active Directory Federation Services in Windows Server 2016

Figura 1: Autenticazione ai servizi SaaS effettuata con Active Directory Federation Services

In questo articolo vi voglio mostrare come il tool Azure AD Connect vi permetta facilmente di configurare la federazione con Active Directory Federation Services (ADFS) locale e Azure AD. Usando l’opzione di federazione con ADFS, è possibile distribuire una nuova installazione di ADFS oppure specificare un’installazione esistente in una farm ADFS di Windows Server 2012 R2 o di Windows Server 2016.

Assicuratevi di aver verificato tutti i Prerequisiti di Azure AD Connect e procedete al download del tool Azure AD Connect. In questo momento è disponibile la versione 1.1.819.0 del 14/05/2018.

Lanciate il wizard di installazione e accettate la licenza, come mostrato in figura:

Figura 2: Lancio del wizard di installazione di Azure Ad Connect

La configurazione che vogliamo applicare richiede che venga effettuata una Installazione personalizzata di Azure AD Connect, pertanto cliccate sul tasto Customize

Figura 3: Scelta dell’installazione personalizzata di Azure Ad Connect

Figura 4: Installazione dei componenti richiesti

Terminata l’installazione dei componenti, scegliamo in quale modo gli utenti faranno il Sign-in. Ho già avuto modo di affrontare in un altro articolo i vantaggi della Azure AD Pass-through Authentication, mentre in questo articolo vi mostro come configurare la Federation con AD FS.

Figura 5: scelta della modalità di Sign-in per gli utenti

Figura 6: Connessione al tenant di Azure AD con le credenziali di Global Admin

Figura 7: Connessione all’Active Directory locale

Cliccate sul pulsante Add Directory ed inserite le credenziali di un utente che abbia permessi sufficienti per leggere le informazioni dal dominio locale. È anche possibile creare un nuovo utente.

Figura 8: Selezione di un utente di AD locale

Figura 9: Connessione all’AD locale effettuata

Assicuratevi di aver configurato correttamente i suffissi UPN per gli utenti del vostro AD locale. Trovate maggiori informazioni leggendo l’articolo How to prepare a non-routable domain for directory synchronization

Figura 10: LIsta dei dominio presenti on-premises e verifica dei domini personalizzati aggiunti online

Nella schermata successiva sarà possibile scegliere quali domini della vostra foresta volete sincronizzare e quali OU. Sarà possibile modificare i filtri anche in un secondo momento, come ho già avuto modo di spiegare nel mio articolo Configurare i filtri in Azure AD Connect

Figura 11: Filtro dei domini e delle OU da sincronizzare

Figura 12: Scelta dell’identificativo univoco con cui vengono rappresentati utenti, gruppi e dispositivi

Figura 13: Eventuale filtro in base al Distinguished Name di un gruppo di AD

Nella schermata relativa alle Optional features potete scegliere se abilitare la Password hash Synchronization o l’attribute filtering. Obiettivo di questo articolo è quello di usare i Federation Services per l’autenticazione ed evitare di sincronizzare le password con il Cloud e per questo motivo lasciate invariate tutte le scelte di default.

Figura 14: Scelta delle Optional features

A questo punto siete pronti per configurare Azure AD Connect con la vostra Farm ADFS. Inserite le credenziali di un amministratore del dominio in cui si torva la vostra Farm ADFS e cliccate su Next.

Figura 15: Inserimento credenziali dell’amministratore del dominio

È possibile creare una nuova AD FS Farm oppure utilizzare una Farm esistente. Nel mio caso ho già una Farm (che ho creato con gli steps descritti nel mio articolo Configurare Active Directory Federation Services in Windows Server 2016). Specifico quindi il server che ospita la Farm ADFS e proseguo con il wizard.

Figura 16: Scelta del server che ospita la Farm ADFS

Figura 17: Selezione del dominio online da federare con la directory on-premises

Figura 18: Conferma dell’installazione di Azure AD Connect

Figura 19: Configurazione completata

Terminata l’installazione di Azure AD Connect potete procedere alla verifica della funzionalità di connettività. Il vostro dominio personalizzato di Azure AD è stato convertito da Standard a Federato ed il Federation Server Gateway di Microsoft adesso punta per l’autenticazione al vostro Web Application Proxy (nel mio caso è sts.nicolaferrini.cloud). Assicuratevi di aver configurato correttamente la risoluzione dei nomi (sia internamente che esternamente alla vostra infrastruttura) e di aver aperto le porte del firewall.

Figura 20: Verifica della funzionalità di federation

Figura 21: Funzionalità verificata

Test di autenticazione – Accesso dall’ESTERNO dell’organizzazione

Adesso che avete configurato tutto correttamente vi basterà collegarvi ad una applicazione Saas che usa Azure AD per l’autenticazione. Ad esempio potete collegarvi ad Office365 tramite il portale https://portal.office.com. Verrete subito reindirizzati al Federation Gateway di Microsoft (https://login.microsoftonline.com) e potrete inserire le credenziali del vostro utente di dominio.

Figura 22: Connessione al portale Office365

Il Microsoft Federation Gateway si accorgerà che il dominio è federato e vi farà collegare direttamente al vostro Web Application Proxy. A quel punto potrete inserire la password del vostro account di dominio, che tramite il vostro Active Directory Federation Server verrà verificata col domain controller.

Figura 23: Reindirizzamento da parte del Microsoft Federation Gateway verso il Web Application Proxy aziendale

Figura 24: Pagina di autenticazione del Federation Server aziendale

Se le credenziali inserite sono corrette verrete reindirizzati alla pagina del Federation Gateway di Microsoft (https://login.microsoftonline.com)

Figura 25: Funzionalità “Mantieni l’accesso (KMSI)”. Questa funzionalità concede l’accesso agli utenti che tornano alle applicazioni senza richiedere di immettere nuovamente il nome utente e password

Figura 26: Accesso al portale di Office365 completato

Test di autenticazione – Accesso dall’INTERNO dell’organizzazione

Se vi collegate da una macchina in dominio e siete loggati con lo stesso utente con cui volete fare il Sign-In ad Azure AD, Active Directory Federation Services provvederà ad usare il token Kerberos che già possedete e ad utilizzare la Windows Integrated Authentication (WIA) per farvi accedere ad Azure AD (Single Sign-On). Però appena utilizzerete il browser vi accorgerete che vi apparirà lo stesso una finestra di autenticazione. Per evitare di reinserire le credenziali ed utilizzare il Single Sign-On sarà necessario considerare attendibile l’url del Federation Server ed inserirlo nella Local Intranet.

Figura 27: Richiesta delle credenziali di accesso anche da una macchina in dominio

Figura 28: Aggiunta nelle Internet Options dell’url del Federation Server nei Local Intranet Trusted Sites

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\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Figura 29: Aggiunta ai Trusted Sites dell’url del Federation Server tramite GPO centralizzata

Connessione tramite i browser Google Chrome, Mozilla Firefox e Microsoft Edge

Se volete effettuare la connessione da browser alternativi ad Internet Explorer sarà necessario, dopo aver inserito nella Local Intranet l’url del Federation Server, apportare alcune modifiche alla configurazione del server ADFS, come spiegato nell’articolo

Configurazione autenticazione intranet basata su form per i dispositivi che non supportano WIA

Infatti sarà necessario modificare la lista dei client che possono supportare la Windows Integrated Authentication (WIA). Per farlo vi basterà eseguire sul server ADFS, da un prompt di PowerShell eseguito con privilegi elevati, i seguenti comandi:

#Verifica dei client attualmente supportati
Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

#Aggiunta dei browser Firefox, Chrome e Edge
Set-AdfsProperties –WIASupportedUserAgents @(“MSAuthHost/1.0/In-Domain”,“MSIE 6.0”,“MSIE 7.0”,“MSIE 8.0”,“MSIE 9.0”,“MSIE 10.0”,“Trident/7.0”, “MSIPC”,“Windows Rights Management Client”,“Mozilla/5.0”,“Edge/12”)

#Riavvio dei servizio Active Directory Federation Services
Restart-Service ADFSSRV

Figura 30: Modifica dei client che supportano la WIA in ADFS

Conclusioni

Azure AD Connect vi permette di configurare facilmente la federazione con Active Directory Federation Services (ADFS) locale e Azure AD. In questo modo gli utenti potranno beneficiare del Single Sign-On (SSO) e le aziende non saranno costrette a dover sincronizzare le password degli utenti con Azure AD. Con pochi semplici passaggi l’autenticazione avviene in azienda e i nostri dati sono al sicuro, permettendo di rispettare i requisiti di privacy e di compliance.

Tra le novità introdotte in Active Directory Federation Services (AD FS) in Windows Server 2016 c’è la possibilità di integrare l’autenticazione con Microsoft Azure Multi-Factor Authentication (MFA), in modo tale da inserire una One-Time Password (OTP) invece che la password di dominio.

Tra le problematiche più note, infatti, si riscontra quella dovuta al blocco dell’account in Active Directory dopo che qualcuno ha tentato di indovinare la password e l’ha sbagliata diverse volte.

Figura 1: Numero massimo di tentativi di accesso falliti prima che l’account venga bloccato

Figura 2: Account bloccato dopo 10 tentativi di accesso falliti

Come avrete modo di leggere nell’articolo Azure AD and ADFS best practices: Defending against password spray attacks, utilizzare ADFS 2016 ed Azure MFA con sistema principale di autenticazione permette di ottenere un sistema passwordless, basato esclusivamente su un OTP.

Ho già avuto modo di farvi vedere come Configurare Active Directory Federation Services in Windows Server 2016 e come Configurare AD FS 2016 ed Office 365 con Azure AD Connect nei miei precedenti articoli. Oggi vi voglio mostrare quanto sia facile integrare ADFS 2016 con Azure MFA.

Registrazione degli utenti in Azure MFA

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup), ma gli utenti devono essersi già registrati e aver attivato l’MFA. Per farlo possono collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione, in cui possono inserire il numero di telefono a cui ricevere messaggi SMS, le chiamate oppure posso collegare l’App per il cellulare (Azure Authenticator)

Figura 3: Configurazione della Multi-factor authentication

Azure MFA come autenticazione principale

Se si utilizza Azure MFA come Primary Authentication in AD FS si può evitare di inserire la password durante il login ad Azure AD, ad Office365 oppure ad altre applicazioni SaaS ed utilizzare un codice temporaneo OTP. Se stiamo utilizzando un pc sconosciuto per autenticarci allora è il caso di prendere il massimo delle precauzioni (potrebbe esserci un keylogger sulla macchina oppure qualcuno potrebbe vedere la password che digitiamo).

Prerequisiti

Per poter connettere ADFS a Azure MFA dovete accertarvi di avere i seguenti prerequisiti:

• Installazione on-premises di un’infrastruttura AD FS basa su Windows Server 2016
• Federazione dell’infrastruttura con Azure AD
• Aver installato il modulo PowerShell per Azure AD (Msoline)
• Permessi di Global Administrator nella sottoscrizione di Azure AD
• Credenziali di Enterprise Administrator per configurare la Farm ADFS per Azure MFA

Configurazioni dei server ADFS

Come prima operazione creeremo un certificato digitale da utilizzare per MFA. Il certificato dovrà essere creato su TUTTI i server AD FS della vostra Farm. Per creare un certificato relativo alla nostra Azure AD useremo la cmdlet di PowerShell

$certbase64=New-AdfsAzureMfaTenantCertificate -TenantIdnicolaferrini.onmicrosoft.com

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD

Figura 4: Creazione del certificato da utilizzare per Azure MFA

Il certificato verrà salvato nello store Local Computer

Figura 5: Certificato da utilizzare per Azure MFA creato

Connettetevi al vostro tenant di Azure AD con il comando Connect-MsolService e successivamente aggiungete le credenziali al Service Principal Name (SPN) del client di Azure Multi-Factor Auth utilizzando il comando PowerShell

New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64

981f26a1-7f43-403b-a875-f8b09b8cd720 è il guid dell’ Azure Multi-Factor Auth Client

Figura 6: Aggiunta delle credenziali al Service Principal Name (SPN) del client di Azure Multi-factor Auth

Configurazione della Farm AD FS

Dopo aver completato i passaggi precedenti in ogni server della Farm ADFS, è necessario impostare il servizio Azure MFA come fattore di autenticazione. Lanciate, una sola volta e su un server ADFS qualsiasi, il comando PowerShell

Set-AdfsAzureMfaTenant -TenantId nicolaferrini.onmicrosoft.com -ClientId981f26a1-7f43-403b-a875-f8b09b8cd720

Ovviamente sostituite il TenantID con quello della vostra directory di Azure AD.

Riavviate il Servizio di Active Directory Federation Service su tutte le macchina ADFS della vostra Farm.

Figura 7: Impostazione del servizio Azure MFA come fattore di autenticazione

Verificate che il nuovo metodo di autenticazione Azure MFA sia presente ed abilitato nella console AD FS Management, come mostrato in figura:

Figura 8: Azure MFA è adesso un Primary Authentcation method per la nostra Farm ADFS

Nel mio caso ho abilitato Azure MFA solo per l’accesso dall’esterno e non dall’interno dell’infrastruttura.

Verifica della presenza di Azure MFA come Primary Authentication method

Per verificare che tutto funzioni perfettamente è possibile collegarsi alla pagina di login del vostro server ADFS (nel mio caso è https://sts.nicolaferrini.cloud/adfs/ls/idpinitiatedsignon.htm)

Poiché ho federato la mia ADFS con Office 365, vado sul portale di autenticazione https://portal.office.com ed inserisco le credenziali di un utente del dominio e testo l’autenticazione dall’ESTERNO della mia infrastruttura.

Figura 9: Connessione al portale di Office 365

Figura 10: Il dominio di Azure AD è federato e vengo reindirizzato al mio Federation Server

Nella pagina di login è apparso un nuovo link che mi permette di utilizzare la Azure Multi-Factor Authentication.

Figura 11: Nella pagina di login del Federation Server è presente il link per utilizzare la Azure Multi-Factor Authentication

Cliccando però sul link ricevo un messaggio di errore. L’utente che sta tentando di connettersi non ha infatti effettuato il ProofUp, cioè la registrazione di Azure MFA. Per poter accedere deve prima collegarsi a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup ed eseguire la procedura di registrazione. Successivamente potrà riprovare a loggarsi con ADFS e Azure MFA.

Figura 12: Pagina di errore se l’accesso viene effettuato da un utente che non si è registrato in Azure MFA

Se invece tento di accedere con un utente che si è precedentemente registrato in Azure MFA, mi viene presentata una pagina dove posso inserire il codice di verifica che ho sulla mia App Azure Auhtenticator oppure posso utilizzare altre opzioni (SMS, telefonata, notifica sull’App)

Figura 13: Inserimento della One-Time Password (OTP) per l’autenticazione

Personalizzazione del portale di accesso di AD FS

AD FS non permette che avvenga la registrazione degli utenti in Azure MFA (proofup) e abbiamo visto che se un utente non si è precedentemente registrato non riuscirà ad utilizzare Azure MFA. È possibile però apportare delle modifiche alle pagine del portale di autenticazione ADFS e fare in modo di venire rediretti automaticamente alla pagina a https://account.activedirectory.windowsazure.com/Proofup.aspx oppure in alternativa a https://aka.ms/mfasetup per eseguire la procedura di registrazione.

Per poter personalizzare l’aspetto della pagina di Sign-In di ADFS è possibile seguire la procedura descritta nell’articolo Advanced Customization of AD FS Sign-in Pages

In questo esempio farò apparire un errore personalizzato, che avvisa gli utenti che devono prima registrarsi ad Azure MFA e successivamente provare a loggarsi al portale.

Come prima operazione clonerò il tema di default delle pagine di Sign-In (che chiamerò AzureMFA) e lo esporterò in modo tale da poterne modificare il file onload.js. La procedura deve essere effettuata da PowerShell su tutti i server ADFS della vostra Farm utilizzando i comandi:

#Creazione di un nuovo tema per il portale ADFS
New-AdfsWebTheme –Name AzureMFA –SourceName default

#Esportazione del tema per poter effettuare le modifiche
Export-AdfsWebTheme –Name AzureMFA –DirectoryPath c:\AzureMFAtheme

Figura 14: Creazione di un nuovo tema per la pagina di Sign-In di ADFS

Nella cartella C:\AzureMFATheme\script troverete il file onload.js, che dovrete modificare inserendo alla fine del file le seguenti righe:

// Se Azure MFA non è disponibile per l'utente si riceve un messaggio che fornisce la procedura corretta per la registrazione
if (document.getElementById('errorMessage').innerHTML.search("The selected authentication method is not available") ) { 
// Show message with redirect link
	errorMessage.innerHTML = 'E\' necessario prima registrarsi per la Multi-Factor Authentication. Collegarsi al portale <a href="https://aka.ms/mfasetup">https://aka.ms/mfasetup</a>, inserire per l\'autenticazione la propria password, registrarsi ad Azure MFA e riprovare successivamente a loggarsi a questa pagina utilizzando la Multi-Factor Authentication.';
}

Figura 15: Modifica del file onload.js con il messaggio di errore personalizzato

Terminata la modifica del file è necessario inserirlo nel tema che avete clonato (nel mio caso si chiama AzureMFA) eseguendo il comando PowerShell

#Aggiornamento del tema con il file onload.js personalizzato
Set-AdfsWebTheme -TargetName AzureMFA -AdditionalFileResource @{Uri=‘/adfs/portal/script/onload.js’;path=“c:\AzureMFAtheme\script\onload.js”}

Successivamente rendete il tema attivo, sostituendo quello di default, con il comando:

#Applicazione del tema personalizzato
Set-AdfsWebConfig -ActiveThemeName AzureMFA

Figura 16: Modifiche apportate al tema di ADFS

Adesso se un utente non ha effettuato il ProofUp, cioè non si è registrato ad Azure AD, invece che ricevere un messaggio di errore che gli indica la procedura corretta di registrazione ad Azure MFA.

Figura 17: Accesso al portale con le credenziali di un utente che non ha effettuato il ProofUp

Figura 18: Messaggio di errore che avvisa l’utente che non può usare la Azure MFA perché deve prima registrarsi (proofup)

Figura 19: L’utente si deve autenticare con la password per poter attivare Azure MFA

Figura 20: L’utente viene reindirizzato al portale di registrazione di Azure MFA

Conclusioni

Per rendere più sicura l’infrastruttura, per evitare che gli utenti vengano bloccati in Active Directory per troppi tentativi di indovinare la password e per stare più tranquilli quando si autenticano utilizzando AD FS da un computer che non è il loro, la soluzione di integrare AD FS 2016 con Azure MFA ed utilizzare un OTP per l’autenticazione è decisamente la migliore e vi permette di sfruttare al massimo le tecnologie disponibili per impedire attacchi di password spray o di password guessing.