Archivi categoria: Windows Server 2016

Generazione di certificati SAN con Let’s Encrypt ed utilizzo in Microsoft Exchange

Facebooktwittergoogle_plusredditlinkedin

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

Configurazione dell’interfaccia utente di GLPI e FusionInventory

Facebooktwittergoogle_plusredditlinkedin

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/


Integrazione FusionInventory con GLPI v9.2.1 in ambiente Windows

Facebooktwittergoogle_plusredditlinkedin

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:

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:

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.

Active Directory disaster recovery Meetup TTG – ICTPower, giovedì 15 febbraio 2018

Facebooktwittergoogle_plusredditlinkedin

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

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

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

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

Di seguito l’agenda della sessione:

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

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

Vi aspettiamo!

Implementare Windows Deployment Services in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Storia

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

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

Installazione e configurazione

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

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

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

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

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

PXE Server

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

DHCP server

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

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

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

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

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

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

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

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

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

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

DISM /Get-WimInfo /WimFile:install.esd

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

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

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

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

Cattura di una immagine esistente

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

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

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

Distribuzione

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

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

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

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

Drivers

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

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

Multicast

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

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

File di risposta automatica

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

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

Conclusioni

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

Utilizzare la Azure Multi-Factor Authentication con Remote Desktop Gateway in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

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

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

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

La procedura di autenticazione sarà quindi:

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

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

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

Il processo di autenticazione infatti funziona in questo modo:

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

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

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

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

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

Prerequisiti

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

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

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

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

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

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

Figura 3: Creazione del Provider di autenticazione

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

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

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

Figura 5: Installazione dei prerequisiti per il server MFA

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

Figura 6: scelta della cartella in installazione del server MFA

Figura 7: Installazione del server MFA completata

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

Figura 8: Attivazione e configurazione manuale del server MFA

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

Figura 9: attivazione del server MFA

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

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

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

Figura 11: Scelta del fattore di autenticazione per ogni utente

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

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

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

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

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

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

Figura 13: Configurazione del nuovo server NPS completata

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

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

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

Figura 15: Modifica delle porte e dello Shared Secret

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

Figura 16: Timeout di risposta del server

Configurazione delle Policy di connessione

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

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

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

Figura 18: Duplicazione della TS GATEWAY AUTHORIZATION POLICY

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

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

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

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

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

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

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

Figura 22: Modifica delle policy originale completata

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

Figura 23: Configurazione delle Network policy completata

Configurazione del server Multi-Factor Authentication

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

Figura 24: Configurazione del server NPS come RADIUS Client

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

Figura 25: Configurazione del server NPS come RADIUS Target

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

Test di funzionamento

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

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

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

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

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

Figura 28: Connessione alla RemoteApp attraverso il Remote Desktop Gateway

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

Figura 29: Reinserimento delle credenziali di login dell’ utente

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

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

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

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

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

Figura 32: Apertura della RemoteApp di Word 2016

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

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

Figura 34: Inserimento di un codice + PIN tramite SMS

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

Conclusioni

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

Configurare Remote Desktop Gateway in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

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

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

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

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

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

Figura 1: Principio di funzionamento del Remote Desktop Gateway

Installazione del Remote Desktop Gateway (RDGW)

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

Figura 2: Aggiunta del ruolo Remote Desktop Services

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

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

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

Figura 4: installazione del ruolo Remote Desktop Gateway completata

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

Figura 5: Console di gestione RD Gateway Manager

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

Figura 6: Importazione del certificato nel RDGW

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

Figura 7: Installazione del certificato completata

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

Figura 8: wizard di creazione della Authorization Policy

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

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

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

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

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

Figura 11: Abilitazione della Device Redirection

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

Figura 12: Scelta di eventuali timeout per le sessioni utente

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

Figura 13: Configurazioni della Remote Desktop Connection Authorization Policy

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

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

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

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

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

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

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

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

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

Figura 18: Configurazione della RD RAP completata

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

Figura 19: Creazione delle due policy completata

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

Verifica della connessione tramite client RDP

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

Figura 20: configurazione del Remote Desktop gateway nel Connection client

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

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

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

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

Figura 23: connessione effettuata al server di destinazione

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

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

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

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

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

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

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

Figura 26: Selezione del server RDGW da aggiungere al deployment

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

Figura 27: Nome del certificato self-signed

Dopo qualche secondo la configurazione è completata.

Figura 28: aggiunta del server RDGW al deployment esistente completata

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

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

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

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

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

Connessione alle RemoteApp della Session Collection attraverso il Remote Desktop Gateway

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

Figura 31: Connessione al Web Access

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

Figura 32: RemoteApp disponibili nella Session Collection

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

Figura 33: Connessione alla RemoteApp utilizzando il Remote Desktop Gateway

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

Figura 34: Apertura della RemoteApp di Word 2016

Conclusioni

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