Archivi categoria: Datacenter

Active Directory Password Policies: facciamo un po’ di chiarezza

Facebooktwittergoogle_plusredditlinkedin

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

Quante password policies posso applicare ad un singolo dominio?

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

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

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

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

Quando viene applicata la password policy?

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

Quando gli utenti vengono impattati?

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

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

Quando vengono distribuite le modifiche apportate ad una password policy?

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

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

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

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

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

Cos’è la Fine-Grained Password Policy?

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

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

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

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

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

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

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

Conclusioni

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

Buon lavoro!

Nic

Configurare l’accesso sicuro ad Azure AD utilizzando Privileged Identity Management

Facebooktwittergoogle_plusredditlinkedin

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

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

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

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

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

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

Abilitare Privileged Identity Management per la directory di Azure

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

Figura 1: Aggiunta della risorsa Azure AD Privileged Identity Management

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

Figura 2: Attivazione della trial di Azure AD Premium P2

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

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

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

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

Figura 5: Consenso all’attivazione di PIM

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

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

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


Figura 7: Ruoli assegnati nella directory di Azure AD

Gestione dei ruoli e degli accessi privilegiati

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

Figura 8: Utente con un ruolo permanente di Exchange Administrator

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

Figura 9: Verifica del ruolo dal portale di Azure AD

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

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

Figura 11: Verifica della conversione del ruolo

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

Figura 12: Murphy è diventato un utente senza privilegi amministrativi

Richiesta di appartenenza temporanea ad un ruolo amministrativo

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

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

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

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

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

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

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

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

Gestione del processo di attivazione del ruolo

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

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

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

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

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

Conclusioni

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

Buon lavoro!

Nic

Impossibile connettersi via RDP a macchine on-premises o alle Azure Virtual Machine: Errore CredSSP Encryption Oracle Remediation

Facebooktwittergoogle_plusredditlinkedin

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

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

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

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

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

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

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

Figura 2: Aggiornamenti installati sul sistema operativo client

Problema

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

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

Anche controllando il Registro Eventi l’errore appare chiaro:

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

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

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

Soluzione

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

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

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

Figura 5: Aggiornamenti di Maggio 2018 su Windows Server 2016

Figura 6: Aggiornamenti di Maggio 2018 su Windows 10

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

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

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

Figura 7: Abilitazione della soluzione Azure Update Management

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

Figura 8: Principio di funzionamento di Azure Update Management

Tipi di client supportati:

La tabella seguente elenca i sistemi operativi supportati:

Sistema operativo Note
Windows Server 2008, Windows Server 2008 R2 RTM Supporta solo le valutazioni degli aggiornamenti
Windows Server 2008 R2 SP1 e versioni successive Sono richiesti .NET Framework 4.5 e WMF 5.0 o versioni successive per Windows Server 2008 R2 SP1
CentOS 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Red Hat Enterprise 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
SUSE Linux Enterprise Server 11 (x86/x64) e 12 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Ubuntu 12.04 LTS e versioni x86/x64 più recenti Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.

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

Figura 9: Aggiornamenti mancanti sulla VM

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

Figura 10: Programmazione dell’aggiornamento della VM

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

Figura 11: Aggiornamenti programmati

Conclusioni

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

Buon lavoro!

Nic

Windows Server 2019 e Windows Admin Center: le novità previste per il prossimo autunno

Facebooktwittergoogle_plusredditlinkedin

Da circa un mese è disponibile nel programma Insider la nuova versione LTSC (Long Term Servicing Channel) di Windows Server, che sarà chiamata Windows Server 2019 e che verrà rilasciata probabilmente ad Ottobre 2018. Le versioni LTSC sono rilasciate ogni 2-3 anni e hanno un supporto mainstream di 5 anni + altri 5 anni di supporto esteso (chi ha la Premium Assurance può aggiungerci altri 6 anni oltre a quelli previsti dal supporto ufficiale!). Questo tipo di versioni sono adatte a chi non ha bisogno di rinnovare troppo spesso il sistema operativo Server e vuole una versione più stabile.

La versione SAC (Semi-Annual Channel) di Windows Server invece viene rilasciata ogni 6 mesi e viene supportata per i 18 mesi successivi. Ogni primavera ed ogni autunno verrà rilasciata una versione SAC, disponibile solo per i clienti che hanno la Software Assurance o che la utilizzano in Azure. Attualmente sono disponibili Windows Server 1709 e Windows Server 1803, entrambe solo in modalità Core e Nano, cioè senza interfaccia grafica, progettate soprattutto per ospitare Containers e applicazioni Cloud.

La scelta tra le due versioni è quindi determinata dall’uso che se ne vuole fare e dal workload che volete farci girare.

Novità in Windows Server 2019

Windows Server 2019 è l’evoluzione di Windows Server 2016, il primo sistema operativo pensato come Cloud OS. Una delle novità che mi ha maggiormente colpito in Windows Server 2019 è il Windows Admin Center, una console di amministrazione basata sul browser che finora era conosciuta come Project Honolulu e di cui ho parlato nell’articolo Project ‘Honolulu’: la rivoluzione della gestione di Windows Server e che sarà anche disponibile gratuitamente per le precedenti versioni di Windows Server (a partire da Windows Server 2012).

Il Windows Admin Center rappresenta il futuro della gestione di Windows Server, è molto leggero (meno di 40 MB), si può installare anche in Windows 10 e si integra con Azure Active Directory. Potete scaricarlo da link https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/understand/windows-admin-center e potete cominciare a testarlo fin da ora. Presto sarà anche possibile integrarlo con App di terze parti. Per maggiori informazioni vi invito a leggere l’articolo Announcing Windows Admin Center: Our reimagined management experience

La sicurezza è sempre un fattore determinante. Oltre a delle buone pratiche operative, bisogna servirsi delle migliori tecniche di protezione possibile. Già in passato, in un precedente articolo intitolato Creare un Guarded Fabric con l’Admin-trusted attestation e le Shielded VMs in Windows Server 2016, ho parlato delle Shielded Virtual Machines, novità introdotta in Windows Server 2016 con lo scopo di proteggere le macchine virtuali. In Windows Server 2019 si potranno proteggere anche le Linux VM e verranno introdotte le Encrypted Networks, che permetteranno agli amministratori di sistema di crittografare il traffico tra i server.

In più in Windows Server 2019 sarà disponibile Windows Defender Advanced Threat Protection (ATP), che sarà capace di intercettare attacchi ed exploits zero day e sarà disponibile fin subito dopo l’installazione del SO. Già in Windows Server 2016 era stato introdotto per la prima volta in un sistema operativo Server un antivirus, precedentemente conosciuto come Endpoint Protection e disponibile con System Center Configuration Manager, che si è distinto in passato per la sua leggerezza e per la sua efficacia. Se volete avere maggiori informazioni potete fare riferimento all’articolo Windows Defender Antivirus on Windows Server 2016

Figura 1: Windows Defender ATP in Windows Server 2019 Preview

Dal punto di vista applicativo in questi mesi si è parlato a lungo di Container e di Windows Subsystem for Linux (WSL), sia in Windows Server 2016 che in Windows 10. L’introduzione di Windows Subsystem for Linux on Windows Server aggiungerà la possibilità di eseguire Container Linux e Container Windows side-by-syde in Windows Server 2019 e con l’aggiunta di un orchestratore come Kubernetes sarà veramente facile creare dei cluster di container. Se non sapete come funziona Kubernetes vi invito a leggere l’articolo Creare un Azure Container Service (ACS) con un Kubernetes cluster.

Figura 2: Gestione di un cluster Kubernetes in Windows Server 2019 Preview

Uno dei trend nella virtualizzazione negli ultimi anni è l’Hyper-Converged Infrastructure (HCI). Già nell’articolo Windows Server 2016 Highlights: Hyper-converged Cluster ho evidenziato che tra le novità di Windows Server 2016 spiccano quelle relative all’iperconvergenza dello storage e dell’hypervisor. Per iperconvergenza o per infrastruttura iperconvergente si intende una infrastruttura IT basata su risorse hardware offerte da un unico vendor, che integra calcolo, memorizzazione, virtualizzazione e networking. Tutte le risorse vengono gestite tramite software e in Windows Server 2019 la gestione sarà affidata al Windows Admin Center

Figura 3: Gestione di un’infrastruttura HCI con il nuovo Windows Admin Center in Windows Server 2019

Tante perciò sono le novità annunciate della prossima versione del sistema operativo Server di casa Microsoft, ma di sicuro nei prossimi mesi ne usciranno altre. Vi terrò informati sulle novità, ma se volete seguire i diversi rilasci delle versioni Insider seguite la pagina https://insider.windows.com/en-us/for-business-getting-started-server/, dove vengono indicate tutte le versioni con i relativi post di annuncio delle funzionalità introdotte.

Che aspettate? Scaricate subito la Windows Server 2019 Insider Preview Build 17639

Nic

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.

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

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

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.