Archivi categoria: Sistemi Operativi

Classifica delle soluzioni di sicurezza endpoint secondo Gartner nel triennio 2016-2018

Facebooktwittergoogle_plusredditlinkedin

Introduzione

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

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

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

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

Struttura dell’analisi

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

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

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

Gartner definisce la categoria Endpoint Protection Platforms come segue:

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

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

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

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

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

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

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

Risultato

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

Vendor

QM 2016

QM 2017

QM 2018

Score

Trend

Sophos

4

4

4

444

«

Symantec

4

4

4

444

«

Trend Micro

4

4

4

444

«

ESET

2

1

3

312

­

Kaspersky Lab

4

4

2

244

¯

Microsoft

3

3

2

233

¯

Cylance

2

2

2

222

«

SentinelOne

2

2

2

222

«

Carbon Black

0

2

2

220

«

CrowdStrike

0

2

2

220

«

F-Secure

2

1

2

212

­

Panda Security

2

1

2

212

­

Malwarebytes

0

1

2

210

­

Cisco

0

0

2

200

Endgame

0

0

2

200

McAfee

0

0

2

200

Palo Alto Networks

0

2

1

120

¯

Bitdefender

2

1

1

112

«

Comodo

0

1

1

110

«

FireEye

0

0

1

100

Fortinet

0

0

1

100

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

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

Pro di Sophos

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

Pro di Symantec

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

Pro di Trend Micro

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

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

Contro di Kaspersky Lab secondo Gartner

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

Conro di Microsoft secondo Gartner

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

Contro di Palo Alto Networks secondo Gartner

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

Conclusioni

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

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

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

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.

Windows 10 Insider Preview (RS4) Recap, cosa troveremo nella versione 1803

Facebooktwittergoogle_plusredditlinkedin

Come annunciato, non molto tempo fa, Microsoft ha aggiornato il modello di manutenzione del sistema operativo Windows 10, introducendo il recente canale semestrale. Esso rappresenta l’aggiornamento delle funzionalità del sistema operativo che avrà la cadenza di 2 volte all’anno, indicativamente marzo e settembre. Per gli IT Pro, e i curiosi, ricordiamo che questo canale va a sostituire le opzioni Current Branch (CB) con Canale semestrale (mirato) e Current Branch for Business (CBB) con Canale semestrale già a partire da Windows 10 versione 1703.

In prossimità dell’arrivo di Windows 10 versione 1803 (nome in codice Redstone 4 e ancora senza nome ufficiale), previsto intorno a marzo 2018, vogliamo raccogliere una serie di novità che verranno introdotte in questa nuova versione di Windows 10.

Nota: L’articolo è molto lungo e consigliamo di aggiungerlo tra i vostri Preferiti a mo’ di promemoria.

Timeline (Sequenza Temporale)

Sequenza temporale è una nuova funzionalità che andrà a migliorare le funzionalità di gestione del multitasking del PC. Essa nasce dall’esigenza di poter recuperare tutte quelle attività su cui si è lavorato in passato, dai siti web visitati fino a determinati file modificati nelle varie applicazioni utilizzate.

Timeline introduce un nuovo metodo per recuperare le attività effettuate, in un determinato periodo, sul proprio PC, su altri computer e su dispositivi iOS/Android. La nuova funzione va ad integrarsi in Visualizzazione attività (vedrete una nuova icona), con la possibilità di “muoversi” tra le applicazioni aperte e le attività passate (Figura 1)

Figura 1 – Timeline in azione una volta fatto clic su Visualizzazione attività

Come si può notare, dall’immagine precedente, la visualizzazione sarà divisa in:

  • Sezioni organizzate per data con le attività salienti
  • Una comoda barra di scorrimento per navigare tra esse
  • Una comoda casella ricerca per individuarne di specifiche (in alto a destra).

Per default Timeline registrerà e sincronizzerà, grazie al Cloud, un massimo di 4 giorni di attività. Per avere una sincronizzazione fino a 30 giorni sarà necessario attivare un’opzione specifica tramite il pulsante Attiva presente in basso (Figura 2).

Figura 2 – Opzione per visualizzare più giorni nella sequenza temporale

Nelle Impostazioni > Privacy è presente una nuova sezione dedicata alla Cronologia attività (Figura 3) da dove sarà possibile configurare gli account che utilizzeranno la funzione Timeline, disattivare la funzione oppure cancellare la cronologia delle attività registrate fino a quel momento.

Figura 3 – La nuova sezione Cronologia attività

Il supporto a Timeline sarà aggiunto alla varie applicazioni da parte degli sviluppatori (a questo link le linee guida ufficiali) e per il momento è presente su Edge, Office, alcune Universal Windows App e Cortana (Figura 4). L’assistente vocale di Windows 10 sarà in grado di suggerire alcune attività da riprendere quando cambieremo dispositivo.

Figura 4 – Selezione di un’attività tramite Cortana

Miglioramenti nella Shell e nelle Impostazioni di Windows

Il Fluent Design è sempre più integrato nel sistema, infatti gli effetti Acrylic e Reveal vengono abilitati nel menu Start, nella Taskbar, nella schermata Condividi (Figura 5), nei menu a comparsa di Orologio e Calendario, Volume e Input.

Figura 5 – Fluent Design sempre più presente

Elenco cartelle nel menu Start personalizzabile. Per andare incontro a coloro che stanno ancora aggiornando a Windows 10, per la prima volta, Microsoft sta ulteriormente semplificando la navigazione verso le risorse presenti sul PC visualizzando i collegamenti rapidi delle cartelle Documenti e Immagini nel menu Start per impostazione predefinita. Era già presente questa possibilità, ma “probabilmente” era poco intuitiva e individuabile.

Se si vuole ulteriormente personalizzare l’elenco delle cartelle sarà sufficiente fare clic con il pulsante destro del mouse su un qualsiasi elemento presente e comparirà un collegamento diretto alle Impostazioni di Personalizzazione (Figura 6).

Figura 6 – Personalizzazione delle cartelle visibili nel menu Start

Stati di OneDrive nel Riquadro di spostamento. Nel pannello laterale di Esplora File può essere mostrato lo stato della sincronizzazione con OneDrive (Figura 7), replicando le icone di stato già viste con l’introduzione dei File su Richiesta in Windows 10 Fall Creators Update.

È possibile attivarli/disattivarli da Opzioni cartella presente nel menu Visualizza. Spostandoci nella scheda Visualizzazione > Impostazioni avanzate > Riquadro di spostamento troveremo la nuova opzione Mostra sempre lo stato di disponibilità (Figura 8).

Figura 7 – Stato di OneDrive direttamente in Esplora Risorse

Figura 8 – Opzione “Mostra sempre lo stato di disponibilità”

Nuovo look per le Impostazioni. Dopo i miglioramenti introdotti in Windows 10 versione 1709, Microsoft ha ridisegnato il nuovo Pannello di Controllo con un occhio all’acuità visiva (Figura 9). Sicuramente la schermata è molto più ordinata.

Figura 9 – Impostazioni di Windows ridisegnato

Non disturbare diventa Assistente notifiche. Con l’espansione della funzionalità Non disturbare, Microsoft cambia il nome in Assistente notifiche e non solo (Figura 10). Con essa sarà possibile:

  • Scegliere gli orari in cui non si vuole essere disturbati dalle notifiche.
  • Impostare la funzionalità in modo che venga attivata automaticamente in determinati orari oppure quando si sta tenendo una presentazione o eseguendo un gioco, attraverso delle Regole automatiche.
  • Consentire alle notifiche con priorità di essere visualizzate, anche con la funzionalità attiva, e visualizzare un riepilogo degli elementi persi al termine dell’orario impostato.
  • Nascondere tutte le notifiche ad eccezione delle sveglie.

La tre modalità (Disattivato, Solo priorità, Solo sveglie) saranno selezionabili dal Centro Notifiche, dal relativo pulsante rapido, oppure facendo clic con il tasto destro del mouse sul pulsante per richiamare sempre il Centro notifiche.

Figura 10 – Nuovo Assistente notifiche

Impostazione Accessibilità ridisegnata. Forte attenzione al tema dell’accessibilità da parte di Microsoft. Dopo i numerosi feedback sono state aggiunte nuove impostazioni di accesso facilitato (Figura 11), migliorando le singole descrizioni e raggruppando le varie impostazioni correlate nelle seguenti categorie: Visione, Udito e Interazione.

Figura 11 – Schermata Accessibilità riorganizzata in maniera più semplice per gli utenti

Nuova sezione dedicata ai Caratteri. Nell’ottica di deprecare il vecchio Pannello di Controllo, all’interno di Impostazioni > Personalizzazione viene introdotta una sezione dedicata ai Caratteri (Font) (Figura 12). Cliccando su una delle famiglie di caratteri verrà mostrata una pagina con i dettagli e un’anteprima per ciascuna variante disponibile all’interno della famiglia selezionata (Figura 13). Presenti altre informazioni su ciascun font (Metadati) e la possibilità di disinstallare il font dal sistema.

Insieme alla nuova sezione Caratteri è stata introdotta la possibilità di installare nuovi tipi di carattere attraverso il Microsoft Store (Figura 14). Al momento non ce ne sono tantissimi disponibili, ma fanno sapere che ne arriveranno altri nei mesi a seguire.

Figura 12 – La nuova sezione Caratteri presente nelle Impostazioni di Personalizzazione

Figura 13 – Dettaglio di un Font selezionato

Figura 14 – Sezione Caratteri nel Microsoft Store per l’installazione di nuovi Font

Aggiunta la sezione Audio nelle Impostazioni. I settaggi per l’audio ora sono disponibili in una nuova sezione dedicata all’interno di Impostazioni > Sistema > Audio (Figura 15), con la possibilità di regolare settaggi avanzati per app e dispositivi.

Figura 15 – Nuova sezione Audio all’interno delle Impostazioni di Sistema

Aggiunta la sezione Avvio nelle Impostazioni. L’elenco delle applicazioni configurate per essere eseguite all’avvio del PC, o al login dell’utente, viene gestito tramite la scheda Avvio presente nel Task Manager. Sempre nell’ottica di migliorare le Impostazioni di Windows 10, sarà possibile configurare le applicazioni di avvio dalla sezione presente in Impostazioni > App > Avvio (Figura 16).

Sarà possibile verificare le app disponibili per l’avvio al momento dell’accesso e abilitare / disabilitare ciascuna di esse. Come nella configurazione classica sarà visibile l’impatto che hanno sul tempo di avvio del dispositivo.

Figura 16 – Nuova sezione Avvio all’interno delle Impostazioni delle App

Miglioramenti alla gestione della grafica. Molti dispositivi recenti sono in grado di riprodurre video in modalità HDR (High Dynamic Range), ma devono essere calibrati in fabbrica per abilitare questa opzione. In Windows 10 sarà possibile riprodurre video HDR tramite nuove funzionalità presenti in Impostazioni > App > Riproduzione video (Figura 17). Se l’hardware lo consente sarà possibile abilitare l’elaborazione automatica del video per migliorarne la resa visiva.

Figura 17 – Nuova sezione Riproduzione video dedicata alle impostazioni vide per le app che utilizzano la piattaforma integrata di Windows

Nuove impostazioni per i sistemi Multi-GPU. Presente nelle impostazioni grafica una nuova pagina per i sistemi Multi-GPU (sistemi con più schede grafiche) la quale consentirà di gestire la preferenza delle prestazioni grafiche di app specifiche. Sicuramente molti hanno familiarità con impostazioni simili di AMD e Nvidia (tranquilli, continueranno a funzionare), ma se la preferenza sarà indicata da questa nuova area essa avrà la precedenza sulle altre. La pagina è presente in Impostazioni > Sistema > Schermo > (scorrendo verso il basso) > Impostazioni grafica (Figura 18).

Per utilizzare questa personalizzazione sarà sufficiente scegliere un’applicazione per impostare la relativa preferenza:

  • Selezionando App classica avremo la possibilità di selezionare una classica app Win32 presente nel sistema
  • Selezionando App universale avremo la possibilità di un’applicazione UWP da un elenco.

Per impostazione predefinita, l’applicazione aggiunta ha una preferenza Predefinito, ovvero il sistema decide autonomamente la migliore GPU l’applicazione.

Cliccando sull’applicazione e sul pulsante Opzioni si potrà scegliere la GPU con risparmio energia o la GPU ad alte prestazioni (Figura 19).

Figura 18 – Nuova sezione dedicata alle Impostazioni grafica

Figura 19 – Schermata in cui si può selezionare una scheda grafica per una specifica app

Perfezionata la sezione Area geografica & Lingua. Finalmente viene migliorata la sezione Area geografica e lingua, con l’introduzione di una serie di indicazioni per ogni lingua (Figura 20). Queste sono utili ad indicare le varie opzioni disponibili come Lingua di visualizzazione, Sintesi vocale, Riconoscimento vocale e Riconoscimento grafia (Figura 21).

Figura 20 – Sezione Area geografica e lingua migliorata con più indicazioni per ogni lingua

Figura 21 – Schermata con le lingue da installare e le varie opzioni disponibili

Impostazioni per le connessioni dati con rete cellulare. Viene inserita la possibilità di preferire l’uso della rete Cellulare a quella Wi-Fi (Figura 22), favorendo (ad esempio) le connessioni 4G LTE (o superiori) e coloro che possiedono piani dati illimitati. Ricordiamo che la sezione è visibile solo utilizzando dispositivi compatibili.

Figura 22 – Sezione Cellular dedicata a quei dispositivi in cui è presente la parte telefonica per la connessione dati

Migliorata la gestione dello spazio disco.
Uno strumento molto comodo presente in Windows dai tempi di XP è Pulizia Disco. Esso permette di eliminare elementi inutili dal disco come i file temporanei o le anteprime delle immagini. Ora è stato integrato nelle nuove Impostazioni e la si può raggiungere da Impostazioni > Sistema > Archiviazione > Libera spazio ora (Figura 23).

Figura 23 – Libera spazio ora in azione come il “vecchio” Pulizia Disco

Migliorate le specifiche e le autorizzazioni. Le Opzioni avanzate di ogni singola app sono state aggiornate in modo da contenere le rispettive specifiche come il numero di versione dell’app per un facile riferimento. Dalla stessa schermata sarà possibile autorizzare quali app UWP possono accedere, ad esempio, ai contatti o alla fotocamera (Figura 24). Aggiunti anche dei link diretti per verificare il consumo della batteria e l’esecuzione in background, e configurare le notifiche nella schermata di blocco.

Come promemoria, il modo più semplice per accedere alla pagina delle impostazioni di una particolare app UWP è fare clic con il tasto destro del mouse sull’app nel menu Start e selezionare Altro > Impostazioni app.

Figura 24 – Nuova schermata dedicata alle specifiche e autorizzazioni per singola app

Pannello Emoji disponibile per più lingue. Il pannello utile ad inserire le Emoji in una qualsiasi casella di testo, o simile, è finalmente disponibile anche per le altre lingue compreso l’italiano (Figura 25). Per richiamarlo è sufficiente premere Tasto Windows + punto (.)

Figura 25 – Pannello Emoji in azione

Miglioramenti in Microsoft Edge

Il “nuovo” browser di Microsoft riceve una serie di aggiornamenti atti a migliorare l’aspetto estetico, l’esperienza d’uso “classica” (ovvero la navigazione sui siti web), l’organizzazione delle sezioni importanti e la lettura di file PDF e/o EPUB. Iniziamo dal nuovo tema scuro (c’era già, ma questo è ancora più scuro con contrasti migliori), e dall’introduzione dell’effetto Reveal e dello sfondo traslucido Acrylic provenienti dal nuovo Fluent Design (Figura 26).

Figura 26 – Miglioramenti del Fluent Design in Edge

Miglioramenti importanti nell’Hub (Preferiti, Elenco di lettura, Cronologia e Download) con una nuova schermata più ordinata, intuitiva e personalizzabile (Figura 27).

Figura 27 – Hub (Preferiti, Elenco di lettura, Cronologia e Download) migliorato

DevTools ancorabili a destra. Gli strumenti utili agli sviluppatori (F12) per analizzare una pagina web possono essere ancorati anche verticalmente, a destra, attraverso un piccolo pulsante in alto a destra. Questo miglioramento soddisfa una forte richiesta da parte di moltissimi sviluppatori web.

Figura 28 – DevTools ancorato verticalmente a destra

Stampa senza elementi superflui. Finalmente è possibile stampare pagine Web da Microsoft Edge senza pubblicità e altri elementi di confusione. Nella finestra di dialogo per la stampa sarà sufficiente impostare l’opzione Stampa senza elementi superflui, dal menu a tendina, su Attivata (Figura 29). Ovviamente questa opzione sarà visibile solo per determinati tipi di pagine web.

Figura 29 – Esempio di stampa con la funzione “Stampa senza elementi superflui” impostata su Attivata

Nuova esperienza di lettura per i file EPUB, PDF e visualizzazione di lettura. In Windows 10 versione 1803 troveremo nuove funzionalità e nuove esperienze per la lettura dei Libri in Microsoft Edge, compresi un menu a comparsa Note (Figura 30), Strumenti grammaticali per libri EPUB (Figura 31) e visualizzazione di lettura (Figura 32), un’esperienza di lettura a schermo intero, e tante altre ancora.

Figura 30 – Menu a comparsa Note con l’elenco di quelle che abbiamo creato

Figura 31 – Strumenti grammaticali in azione con la funzione evidenzia verbi attivata

Figura 32 – Visualizzazione del libro a schermo intero per una lettura immersiva

Miglioramenti in Sicurezza e Privacy

Aggiornamento di Windows Defender Application Guard (WDAG). Introdotto con Fall Creators Update e disponibile soltanto per l’edizione
Enterprise di Windows 10, WDAG è un sistema di protezione per Microsoft Edge che offre una protezione senza precedenti contro le minacce mirate utilizzando la tecnologia di virtualizzazione Hyper-V (Figura 33). Esso funziona isolando il browser dal resto del sistema, in modo da proteggere il PC da possibili attacchi sofisticati tramite il browser.

Da Windows 10 versione 1803 questa importante funzionalità di sicurezza, per fortuna, viene estesa anche agli utenti Windows 10 Pro.

Figura 33 – Windows Defender Application Guard attivo

Visualizzatore dati di diagnostica. Come ben sappiano Microsoft utilizza i dati diagnostici di Windows per focalizzare l’attenzione sulle decisioni da prendere nel miglioramento delle sue piattaforme, tant’è che è possibile indicare in fase di prima installazione/attivazione, del sistema operativo, la misura dell’invio dei dati diagnostici scegliendo fra Base o Completo. Ne abbiamo parlato in questo articolo dedicato.

L’azienda di Redmond, impegnata continuamente ad essere il più trasparente possibile sui dati diagnostici raccolti dai dispositivi Windows e fornire un maggiore controllo su tali dati, introduce due nuove funzionalità collocate in Impostazioni > Privacy > Feedback e diagnostica (Figura 34). Innanzitutto viene data la possibilità di attivare un’app (da installare tramite il Microsoft Store) (Figura 35), per la Visualizzazione dei dati di diagnostica in maniera più dettagliata e tramite ricerca (Figura 36); in aggiunta sarà possibile Eliminare i dati di diagnostica raccolti da Microsoft sul dispositivo attraverso un pulsante dedicato.

Si tratta di miglioramenti che dovrebbero andare incontro alle continue (e lecite) critiche rivolte a Microsoft per aver introdotto, in Windows 10 e altri servizi, un meccanismo di trasmissione / raccolta di dati spesso poco chiaro e trasparente per gli utenti.

Figura 34 – Feedback e diagnostica nelle impostazioni della Privacy

Figura 35 – App “Visualizzatore dati di diagnostica” presente nel Microsoft Store

Figura 36 – Esempio del dettaglio di un dato diagnostico

Riquadro delle impostazioni sulla Privacy aggiornato. Per migliorare l’impatto visivo sono state aggiunte nuove categorie nel riquadro di navigazione delle impostazioni sulla Privacy (Figura 37).

Figura 37 – Riquadro Privacy ridisegnato

Windows Defender ora è Sicurezza di Windows. È stata rinominata la pagina delle impostazioni per Windows Defender Antivirus in Impostazioni > Aggiornamento e sicurezza da Windows Defender a Sicurezza di Windows. La pagina è stata completamente ridisegnata, in modo da avere un rapido accesso alle varie Aree di protezione (Figura 38).

Figura 38 – Sezione “Sicurezza di Windows”

Configurazione di Windows Hello più semplice. Ora è possibile impostare il riconoscimento del volto, le impronte digitali o il PIN di Windows Hello direttamente dalla schermata di blocco facendo clic sul riquadro di Windows Hello in Opzioni di accesso (Figura 39).

Figura 39 – Configurazione di Windows Hello dalla schermata di blocco

Domande di sicurezza anche per gli account locali. Generalmente quando ci dimentichiamo la password di un servizio online, se configurato opportunamente, il sistema potrebbe proporci di inserire e, successivamente, rispondere a delle domande sulla sicurezza in modo da verificare la nostra identità. In Windows 10 1803 questa possibilità verrà estesa anche agli account locali in fase di prima installazione, aggiunta di un account al PC (Figura 40) e come configurazione nella sezione Opzione di accesso > Password (Figura 41).

Figura 40 – Richiesta d’inserimento domande di sicurezza durante la creazione di un nuovo account utente

Figura 41 – Aggiornamento domande di sicurezza di un utente esistente

Miglioramenti per Professionisti IT e varie

Nuova API della piattaforma Windows Hypervisor. È stata aggiunta un’API in modalità utente estesa per gli stack e le applicazioni di virtualizzazione di terze parti, che consente di creare e gestire le partizioni a livello di Hypervisor, configurare i mapping di memoria per la partizione e, creare e controllare l’esecuzione dei processori virtuali (Figura 42). Per maggiori dettagli vi consigliamo di andare a questo link.

Figura 42 – Schema della nuova API aggiunta nella piattaforma Windows Hypervisor

Aggiunte nuove Policy dedicate alla Ottimizzazione recapito per limitare la larghezza di banda massima di tutte quelle attività di download, in primo piano o in background, su determinate fasce orarie della giornata, limitare la selezione dei Peer (al momento) alla stessa sottorete, e molte altre. Le nuove policy sono editabili in Administrative Templates > Windows Components > Delivery Optimization (Figura 43).

Figura 43 – Nuove Policy dedicate alla “Ottimizzazione recapito”

Nuova combinazione per il risparmio energia in Windows 10 Pro for Workstations. Nella nuova edizione di Windows 10, introdotta con Fall Creators Update e dedicata a PC di fascia molto alta, viene aggiunta una combinazione di “risparmio energia” dedicata a tutti coloro che vogliono sfruttare al massimo tutte le potenzialità dell’hardware in possesso senza compromessi (Figura 44).

Microsoft assicura che, utilizzando questa combinazione Ultimate Performance, saranno eliminate tutte quelle micro-latenze che possono impattare direttamente sull’hardware; naturalmente questa opzione consuma molta più energia rispetto alla combinazione di default. Al momento non è disponibile su sistemi alimentati a batteria.

Figura 44 – Nuova combinazione di risparmio energia per Windows 10 Pro for Workstations

Focus sulla produttività in Windows 10 Pro for Workstations. Nell’aggiornamento di Windows 10 Fall Creators, l’esperienza out of the box per Windows 10 Pro for Workstations si basa sulla versione Pro di Windows 10. Nella prossima versione di Windows, all’interno del menu Start saranno presenti applicazioni incentrate su produttività e azienda (Figura 45), al posto delle applicazioni e dei giochi dedicate più ai consumatori.

Figura 45 – Focus sulla produttività nel menu Start di Windows 10 Pro for Workstations

Gruppo Home deprecato. A partire da questa versione il servizio Gruppo Home non sarà più operativo in Windows 10 (Figura 46). Microsoft consiglia di sfruttare funzionalità più moderne come la nuova Condivisione e OneDrive. Il profilo utente utilizzato per la condivisione e le condivisioni di file / cartelle / stampanti continueranno a funzionare.

Figura 46 – La funzionalità Gruppo Home in Windows 10 Fall Creators Update

Queste sono tutte le novità più salienti che troveremo nella prossima versione di Windows 10, la 1803. Per approfondire vi lasciamo gli articoli di riferimento direttamente dal Blog di Windows:

Surface Pro 2017, profili colore sRGB/Enhanced spariti dopo formattazione

Facebooktwittergoogle_plusredditlinkedin

Surface è diventato ormai un dispositivo di riferimento per quanto riguarda la categoria dei Tablet PC, ovvero un oggetto versatile con il giusto mix di mobilità e produttività. Poco tempo fa abbiamo recensito il modello Surface Pro 4 e da poche settimane abbiamo acquistato il nuovo Surface Pro (2017) Modello 1796. Presto lo recensiremo per coloro che sono interessati all’uso quotidiano, sia in ambiente domestico che lavorativo.

Una delle novità importanti riguarda lo schermo e nello specifico i profili colore. Il nuovo Surface Pro ha ben 2 profili colore di serie utili soprattutto a chi fa il fotografo, videomaker e grafico: sRGB e Enhanced. Il primo copre il gamut fino al 96% (l’insieme dei colori che il dispositivo o la periferica è in grado di produrre, riprodurre o catturare ed è un sottoinsieme dei colori visibili), e arriva al 71% di AdobeRGB. Il secondo cerca di avvicinarsi al P3-D65 (un spazio colore RGB comune utilizzato per la proiezione di film nell’industria cinematografica Americana); è oggettivamente più contrastato ed ha colori più accesi, rendendo questo profilo più adatto all’uso di tutti i giorni. Se volete approfondire vi rimandiamo all’articolo recensione di HDBlog.it

Ma come è possibile switchare da un profilo colore all’altro? Semplicissimo, direttamente dalle azioni rapide presenti in basso nel centro notifiche. Fermi tutti, da qui parte ufficialmente il nostro articolo guida.

Da buoni IT Pro quali siamo, non appena abbiamo tirato fuori dalla scatola il nuovo e fiammante Surface, ci siamo subito accorti che la versione del sistema operativo era aggiornata alla versione numero 1703. Questo è un buon motivo per eseguire una bella pulizia e reinstallare da zero il sistema operativo con la ISO ufficiale di Windows 10 Fall Creators Update (1709) rilasciata nell’ottobre scorso.

Installiamo Windows 10 1709, installiamo i Driver ufficiali, riavviamo il sistema e…il pulsante per switchare tra i profili colore non c’è più (Figura 1).

Figure 1 – Centro notifiche senza il pulsante per la selezione del profilo colore

“Qualcosa è andato storto durante la formattazione” e, quindi, riformattiamo nuovamente. Nulla da fare. Iniziamo così a cercare su internet e arriviamo ad una discussione su Reddit dalla quale emerge, come unica soluzione, l’installazione dell’immagine di recovery ufficiale. Peccato che questa non sia aggiornata!

Non ci arrendiamo e nella Microsoft Community USA pubblichiamo un post di domanda nel quale chiediamo spiegazioni sulla problematica. Una nostra collega MVP, Barb Bowman, ci risponde e dopo qualche giorno, con un contatto interno a Microsoft, riusciamo ad avere la seguente procedura:

  • Effettuare l’installazione pulita di Windows 10 sul nuovo Surface Pro
  • Al termine installare gli ultimi driver ufficiali utilizzando il pacchetto MSI scaricabile dal sito di Microsoft
  • Riavviare il sistema
  • Verificare da Impostazioni > Sistema > Notifiche e azioni l’assenza dell’azione rapida Profilo colore
  • Installare le più recenti versioni di Visual C++ 2017 supportate, sia x86 che x64, scaricabili sempre dal sito di Microsoft
  • Riavviare il sistema
  • Verificare che l’azione rapida per la selezione del profilo colore sia finalmente comparsa (Figura 2)

Figure 2 – Centro notifiche con il pulsante per la selezione del profilo colore

Una soluzione semplice, ma efficace nel caso vi siate trovati con questa problematica.

Presto pubblicheremo una guida su come formattare in maniera drastica un Surface e installare, ad esempio, Windows 10 Enterprise.

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!