Archivi categoria: howto

Configurare Azure Active Directory Conditional Access per le applicazioni SaaS

Facebooktwittergoogle_plusredditlinkedin

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 a tutte le applicazioni necessarie senza dover ripetere una seconda volta l’autenticazione (ad esempio, digitando una password). La configurazione di Single Sign-On basato su password consente agli utenti dell’organizzazione di accedere automaticamente a un’applicazione SaaS di terze parti tramite Azure AD utilizzando le informazioni dell’account utente dall’applicazione SaaS di terze parti. 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

Utilizzo di Azure DNS per la validazione automatica di Let’s Encrypt

Facebooktwittergoogle_plusredditlinkedin

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

Configurare e gestire Azure DNS

Facebooktwittergoogle_plusredditlinkedin

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

Novità di Windows Subsystem for Linux in Windows 10 Build 17063 (e successive)

Facebooktwittergoogle_plusredditlinkedin

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.

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.

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.