L’anno scorso abbiamo organizzato al Politecnico di Bari il primo Cloud Day, nel quale abbiamo illustrato le principali novità e visioni del mondo Microsoft con l’aiuto di Paola Presutto (Technical Evangelist di Microsoft Italia), Microsoft Student Partner e Professionisti del settore DEV e IT. Proprio queste ultime due parole, unite dalla congiunzione “e”, nascondono due branche dell’informatica talmente vaste che spesso vengono un po’ troppo sottovalutate: Sviluppatore e Sistemista.

Oggi la tecnologia incontra nuove frontiere mai esplorate rivoluzionando il modo di concepire l’utilizzo dei dati e, per questo motivo, le Community ICT Power e DotNetSide, in collaborazione con Microsoft Italia, Politecnico di Bari e Azione Universitaria Politecnico, vi propongono una giornata intera dedicata alla conoscenza delle potenzialità offerte da entrambe queste figure professionali con un extra trasversale ed inedito.

La conferenza gratuita, dedicata a studenti, professionisti e curiosi, vedrà la presenza di diversi ospiti e professionisti tra cui alcuni Evangelist di Microsoft Italia. Dopo la Sessione Plenaria (Keynote), ci saranno diverse sessioni distribuite su 2 track parallele per sviluppatori (aula magna) e sistemisti (aula multimediale). Come sempre non mancheranno delle sorprese e vi consigliamo caldamente di rimanere fino alla fine.

Vi aspettiamo a Bari il 25 maggio 2017 alle ore 9.00 presso l’Aula Magna Attilio Alto del Politecnico di Bari (c/o Campus Universitario) in Via Edoardo Orabona 4 e per iscrivervi è necessario registrarsi a questa pagina Eventbrite.

Questa giornata prosegue un percorso iniziato nel 2016, portando ancora una volta a Bari: innovazione, conoscenza e opportunità di fare rete!

Il servizio DNS è diventato uno dei cardini delle varie infrastrutture Aziendali, Active Directory si “appoggia” sul Name Server per tutta la componente Kerberos e non solo.

Le varie applicazioni aziendali hanno riferimenti FQDN anche all’interno dell’infrastruttura e del perimetro di rete Aziendale, e la navigazione Internet, da sempre richiede tale servizio.

Il DNS, appunto perché è utilizzato per la navigazione, può in qualche modo, chiaramente non da solo, fornire indicazioni su quelli che possono essere tentativi di risoluzione di siti malevoli.

Infatti alcune soluzioni commerciali di protezione si basano proprio su una gerarchia di questo servizio, mettendo a disposizione motori che forniscono esclusivamente risoluzioni per host in qualche modo “fidati”.

È interessante la lettura di questo articolo che introduce all’analisi forense dei log relativi al servizio DNS.

Dal punto di vista dell’operatività del servizio, conoscere le query che il DNS deve risolvere, permette anche di effettuare una pulizia di record dichiarati in modo statico e che nel tempo sono diventati assolutamente inutilizzati ed in generale creano soltanto confusione.

Cercheremo in questo articolo di analizzare quelle che sono le modalità di analisi del funzionamento del DNS aziendale andando a rilevare quali e quante sono le richieste che un DNS deve soddisfare nel corso del tempo.

Un’indicazione molto generica di funzionamento, tramite il PowerShell è possibile ottenerla con il Commandlet Get-DnsServerStatistics

Figura 1

Tuttavia, come si può vedere nella figura 1 vengono fornite solo informazioni molto scarne, principalmente sul numero di query effettuate per tipologia di Record ed il loro stato.

In Windows 2016 è disponibile nativamente la funzione “Enhanced DNS logging and diagnostics “un tool integrato che permette una diagnostica profonda sul funzionamento, non solo dal punto di vista della disponibilità del servizio, ma di come questo è utilizzato, le query a cui deve rispondere etc.

Dalla versione 2016, questa funzione è integrata nativamente, ma era già stata introdotta con Windows 2012 R2 per mezzo dell’installazione della KB: 2956577

Attivazione del log analitico del DNS

Di default il sistema non ha attiva questa funzione di tracing, ma deve essere abilitata mediante il registro eventi

Figura 2 attivazione della modalità di Debug

Posizionandosi nel “ramo” del log eventi “Application and Services Logs\Microsoft\Windows\DNS-Server nelle opzioni a disposizione tramite il tasto DX, esiste la possibilità di attivare il “Service and Debug Log” tramite il quale il DNS inizierà a registrare tutta la sua attività.

È importante considerare il fatto che, in installazioni molto grandi le dimensioni del file di log possono rapidamente raggiungere la soglia limite di 4Gb per registro, è bene quindi effettuare un periodo di osservazione al fine di verificare che non si raggiungano situazioni di funzionamento critiche.

Dal momento che ora tutte le attività del DNS sono tracciate nel Registro Eventi è possibile effettuarne un monitoraggio andando ad identificare il tipo di query che viene effettuata, ed anche quali hostname vengono richiesti al DNS.

Come detto in precedenza in questo modo possiamo verificare se e quali record in quanto non utilizzati possono essere con una certa sicurezza rimossi.

Figura 3 dettaglio voce del log di debug

Nella figura 3 è riportato il dettaglio di un elemento del registro eventi relativo ad una ricerca diretta per la risoluzione di www.google.com, siccome il messaggio di log vero e proprio viene archiviato sotto forma di testo è necessario estrapolarne le informazioni, dal punto di vista della diagnostica sono utili i “campi”:

• Source
• Qname
• Qtype

Il primo individua il richiedente la risoluzione, ossia il client del servizio DNS,

il secondo è l’oggetto vero e proprio della richiesta di risoluzione DNS

mentre il “campo” Qtype individua il tipo di query, secondo l’RFC che norma il servizio DNS come riportato in questa tabella

Ricerca degli eventi all’interno del registro

Come detto sopra le informazioni utili alla diagnostica sono salvate sotto forma di stringhe testuali ed in questo caso è molto utile l’utilizzo delle “Espressioni Regolari” per individuare le varie parti del messaggio.

PowerShell dal canto suo dispone di cmd-let per l’accesso al registro e permette l’uso delle Regular Expression nei suoi parametri di ricerca.

Il cmd-let usato in questo esempio per accedere al registro eventi è Get-WinEvent per mezzo del quale vengono rilevati gli eventi del registro di debug

Get-WinEvent -LogName “Microsoft-Windows-DNSServer/Analytical” -oldest

Tramite le opzioni di filtro applicate all’output, possiamo ottenere le informazioni sul tipo di query che vengono sottoposte al server

Get-WinEvent -LogName “Microsoft-Windows-DNSServer/Analytical” -Oldest | Where-Object { $_.Message -match “QTYPE=[0-9]+”} | ForEach-Object {$DnsRecords += $Matches.Values}

Figura 4 rilevazione del tipo di ricerca fatta sul DNS

Lo script riportato sopra rileva il numero di query eseguite sul DNS raggruppate per tipologia

Get-WinEvent -LogName “Microsoft-Windows-DNSServer/Analytical” -Oldest | Where-Object { $_.Message -match “QNAME=.*?; QTYPE=1”} | ForEach-Object {$DnsRecords += $Matches.Values}

Figura 5 rilevazione e raggruppamento dei nomi host richiesti al DNS

Mentre in questo caso sono rilevate le risoluzioni richieste al DNS

Le Espressioni regolari utilizzate al fine della ricerca puntuale delle occorrenze all’interno dei vari messaggi sono riportate qui sotto, e come si vede fanno parte della stringa di ricerca

• QTYPE=[0-9]+
  
• QNAME=.*?; QTYPE=1
  

Al fine di essere ragionevolmente sicuro che I parametri di ricerca siano corretti, personalmente utilizzo il sito https://regex101.com/ per verificare che l’espressione applicata sulla stringa dia i risultati voluti, il sito Regex01 riporta anche le varie indicazioni sulle strutture delle stringhe di ricerca e consente in modo interattivo di verificare la costruzione delle query valutandone la correttezza sintattica.

Nel caso in cui sia necessario monitorare diversi DNS il cmd-let permette di accedere a server remoti tramite l’opzione -computername

Logging di versioni precedenti la 2012R2

Le versioni di WindowsServer precedenti la 2012R2 non permettono la modalità di attivazione del log DNS come visto finora, per questa tipologia di sistemi è possibile attivare un log su file, funzione che è comunque rimasta anche nelle recenti versioni.

L’attivazione del log avviene tramite lo Snap-in di gestione DNS, alla voce “Debug Logging” spuntando il checkbox, di attivazione del Log.

Figura 6 attivazione log per versioni “legacy”

Sono disponibili ulteriori opzioni, come ad esempio il log delle connessioni in uscita piuttosto che quelle in ingresso, la tipologia di pacchetti, il protocollo di trasporto etc. di default non è necessario attivare il dettaglio in quanto le informazioni di base forniscono già sufficienti indicazioni per determinare eventuali problemi di funzionamento.

Figura 7 DNS log file

Il file di log riporta la descrizione delle varie componenti il log stesso, tuttavia per l’analisi del contenuto del logfile è possibile utilizzare appositi tool free come ad esempio Zedlan

Figura 8 Output Zedlan

Considerazioni

Il servizio DNS è sempre di più uno snodo nevralgico del sistema, il suo monitoraggio, così come la sua manutenzione diventano quindi imprescindibili, le indicazioni riportate sopra non sono sicuramente esaustive ma sono frutto dell’esperienza quotidiana di chi le ha scritte, ed hanno lo scopo di fornire al lettore un punto di vista differente sull’approccio alla gestione di questo servizio.

Riferimenti

https://technet.microsoft.com/en-us/library/dn800669(v=ws.11).aspx

https://blogs.technet.microsoft.com/tip_of_the_day/2016/05/16/tip-of-the-day-using-dns-analytical-logging/

https://support.microsoft.com/it-it/help/2956577/update-adds-query-logging-and-change-auditing-to-windows-dns-servers

Una delle novità più interessanti in ambito Networking riguardo Microsoft Azure è stata presentata pochi giorni fa nell’annuncio General availability: Multiple IP addresses per network interface

Trovo questa funzionalità particolarmente interessante perché risolve diversi problemi che mi avevano posto alcuni clienti. Ad esempio una web agency che ha creato diversi web server in Microsoft Azure ha bisogno di far girare diversi siti web e servizi con differenti indirizzi IP e certificati digitali sulla stessa scheda di rete della VM.

Questo tipo di funzionalità è utilizzabile per poter creare dei bilanciatori di carico o dei firewall utilizzando macchine virtuali gestite da noi.

È anche disponibile da pochissimi giorni la possibilità di avere almeno due schede di rete in tutte le macchine virtuali (Windows e Linux) create in Azure, come annunciato in General availability: Dual network interfaces for all Azure VMs

Per poter assegnare alla stessa scheda di rete due indirizzi IP diversi è sufficiente collegarsi al portale di Azure, selezionare la VM da modificare e cliccare sulla scheda di rete utilizzata dalla VM, come mostrato in figura:

Figura 1: Selezione dell’interfaccia di rete da modificare per la VM

Dopo aver cliccato sull’interfaccia di rete interessata, nel nuovo blade che vi si aprirà selezionate IP Configurations e cliccate sul pulsante Add per aggiungere un nuovo indirizzo, come mostrato in figura:

Figura 2: Blade IP Configurations per la scheda da modificare

Nel Blade Add IP configuration scegliete un nome simbolico per l’indirizzo IP da aggiungere, scegliete se volete mantenere statico o dinamico l’indirizzo IP privato (vi consiglio di mantenerlo statico) e successivamente scegliete se volete abilitare l’indirizzo IP Pubblico, come mostrato in figura:

Figura 3: Aggiunta del secondo indirizzo IP pubblico

Una volta completata la procedura ed assegnato il nome al secondo indirizzo IP pubblico vi verrà mostrata la schermata con gli indirizzamenti per la vostra scheda di rete, come mostrato in figura:

Figura 4: Indirizzamenti IP privati e pubblici per la scheda di rete della VM

Avete un numero limitato di indirizzi IP privati e pubblici da assegnare, come documentato dall’articolo https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits?toc=%2fazure%2fvirtual-network%2ftoc.json#azure-resource-manager-virtual-networking-limits

Per completare l’operazione è necessario collegarsi in desktop remoto alla macchina virtuale ed assegnare gli indirizzi privati manualmente. Se infatti eseguite il comando ipconfig /all all’interno della VM vedrete che verrà visualizzato solo l’indirizzo primario, come mostrato in figura:

Figura 5: Presenza solo dell’indirizzo Primario assegnato alla scheda di rete della VM

Modificate le proprietà della scheda di rete aggiungendo manualmente gli indirizzi IP interni che avete assegnato staticamente nel portale di Azure, come mostrato in figura:

Figura 6: Assegnazione statica degli indirizzi privati scelti

Dopo aver assegnato gli indirizzi (attenti a non sbagliare perché altrimenti non vi riconnetterete più alla VM) la connessione in desktop remoto potrebbe disconnettersi per un secondo, ma poi sarete nuovamente collegati.

Rilanciando il comando ipconfig /all potrete verificare che adesso la scheda di rete ha i due IP interni che avete assegnato, come mostrato in figura:

Figura 7: Scheda di rete con doppio indirizzo IP interno

La macchina virtuale sarà raggiungibile in Desktop remoto su tutti gli indirizzi pubblici che avete assegnato, in quanto le regole di firewall sono definite dallo stesso Network Security Group.

Volendo è possibile dare un’occhiata alle proprie configurazioni di rete utilizzando lo strumento Network Watcher, che è possibile abilitare per ogni regione. Cliccate su Monitor nella Dashboard e abilitate il Network Watcher per le regioni disponibili per la vostra sottoscrizione.

Figura 8: Abilitazione del Network Watcher

Tra le funzionalità messe a disposizione del Network Watcher c’è la visualizzazione della Topologia del proprio scenario di rete, che mostra le varie interconnessioni e le associazioni tra le risorse di rete in un gruppo di risorse. Dal menù a tendina in alto scegliete la vostra sottoscrizione, il resource group e la scheda di rete da monitorare e vi verrà creata automaticamente la topologia di rete, con le diverse connessioni, come mostrato in figura:

Figura 9: Topologia di rete creata col Network Watcher

Conclusioni

La possibilità di avere due schede di rete su tutte le macchine virtuali in Azure e assegnare alla stessa scheda di rete diversi indirizzi IP, sia pubblici che privati, ci permette di implementare degli scenari di networking anche complesso che finora non era possibile realizzare. Creare bilanciatori di carico e firewall con le macchine virtuali su Azure non è mai stato così facile!

Introduzione

Con il decreto della Presidenza del Consiglio dei Ministri del 24 ottobre 2014, pubblicato sulla Gazzetta Ufficiale n. 285 del 9 dicembre 2014 è stata aperta la strada all’attuazione sistema SPID che, come è possibile leggere sulle FAQ pubblicate sul sito governativo dedicato a SPID, rappresenta “il sistema di autenticazione che permette a cittadini ed imprese di accedere ai servizi online della pubblica amministrazione e dei privati aderenti con un’identità digitale unica“.

SPID è stato è stato progettato in conformità a eIDAS (electronic IDentification Authentication and Signature) descritto nel Regolamento UE n° 910/2014 che ha l’obiettivo di rafforzare la fiducia nelle transazioni nell’Unione Europea, fornendo una base normativa comune per interazioni elettroniche sicure fra cittadini, imprese e pubbliche amministrazioni. Le tecniche e protocolli su cui si basa SPID sono già stati sperimentati a livello europeo e adottate dai progetti sperimentali Stork e Stork II (Secure idenTity acrOss boRders linKed), a riguardo si veda SPID verso eIDAS.

Sempre come riportato nelle FAQ “l’identità SPID è costituita da credenziali (nome utente e password) che vengono rilasciate all’utente e che permettono l’accesso a tutti i servizi online”.

Per quanto riguarda le differenze tra SPID e la Carta nazionale sempre nelle FAQ viene riportato quanto segue:

“I due strumenti hanno usi e scopi in parte diversi e in questa prima fase di implementazione del sistema SPID coesisteranno.

A differenza della Carta Nazionale dei Servizi – che non è completamente dematerializzata – per l’uso dell’identità SPID non è necessario alcun lettore di carte e può essere utilizzata in diverse modalità (da computer fisso o da mobile).”

“Nella prima fase di avvio del sistema pubblico di identità digitale la necessità è quella di far coesistere il sistema di autenticazione tramite SPID con quelli già esistenti.

La progressiva implementazione del sistema da parte della pubblica amministrazione (che durerà 24 mesi) farà si che tutti i servizi online siano accessibili tramite SPID.”

SPID è diventato operativo Il 28 luglio 2015, con la Determinazione n. 44/2015 in cui sono stati emanati da AgID i quattro regolamenti (Accreditamento gestori, utilizzo identità pregresse, modalità attuative, regole tecniche) previsti dall’articolo 4, commi 2, 3 e 4, del DPCM 24 ottobre.

Il 7 ottobre 2016 è stata pubblicata la Determinazione 239/2016 che consente anche ai privati di accedere al sistema SPID in qualità di fornitori di servizi.

Le Pubbliche Amministrazioni dovranno aderire al circuito SPID per consentire l’identificazione elettronica dei cittadini per l’erogazione dei propri servizi on line entro il 31 dicembre 2017.

Per ulteriori informazioni si vedano Sistema Pubblico per la gestione dell’Identità Digitale – SPID, le FAQ su spid.gov.it, le FAQ su agid.gov.it e la pagina su Wikipedia dedicata a SPID.

Argomenti

• Architettura di SPID
• Requisiti per l’implementazione di SPID da parte di una Pubblica Amministrazione
• Procedura per l’implementazione di SPID da parte di una Pubblica Amministrazione
  • Procedura Tecnica
  • Procedura Amministrativa
• Conclusioni

Architettura di SPID

Scendendo nel dettaglio dell’architettura di SPID sono previsti tre ruoli:

• Identity provider o gestore di identità digitale (IP) che fornisce le credenziali di accesso al sistema (identità digitali) e gestisce i processi di autenticazione degli utenti. Al momento gli IP accreditati sono Aruba, Infocert, Poste, Sielte e Tim, ma qualunque soggetto in possesso dei requisiti previsti dalle norme può fare richiesta di accreditamento all’Agenzia per l’Italia Digitale (per l’elenco aggiornato degli IP si veda Identity Provider Accreditati).
• Service provider o fornitore di servizi (SP) che mette a disposizione servizi digitali accessibili tramite il login con credenziali SPID. Gli SP sono rappresentati dalle pubblica amministrazioni e dai privati aderenti.
• Attribute provider o gestore di attributi qualificati (AP) che fornisce attributi che qualificano gli utenti (stati, ruoli, titoli, cariche), finalizzati alla fruizione dei servizi, per determinati servizi o processi, infatti, potrà essere necessario dimostrare il possesso di una specifica condizione o di un particolare requisito personale o professionale. Al m omento gli AP accreditati sono il Ministero dello Sviluppo Economico (in relazione ai dati contenuti nell’indice nazionale degli indirizzi Pec delle imprese e dei professionisti), i Consigli, gli Ordini e i Collegi delle professioni regolamentate (per attestare l’iscrizione agli albi professionali), le Camere di Commercio, Industria, Artigianato e Agricoltura (per l’attestazione di cariche e incarichi societari) e l’AgID (in relazione ai dati contenuti nell’indice degli indirizzi della pubblica amministrazione e dei gestori di pubblici servizi).

L’AgID è invece chiamato a svolgere il ruolo di vigilanza sui soggetti accreditati e il ruolo di garante della federazione, gestendo il registro che rappresenta l’insieme dei soggetti che hanno sottoscritto il rapporto di fiducia.

Di seguito lo schema di funzionamento di SPID e il flusso delle interazioni tra i vari ruoli al fine di concedere all’utente l’accesso ai propri dati.

Requisiti per l’implementazione di SPID da parte di una Pubblica Amministrazione

Le Pubbliche Amministrazioni, in qualità di Service Provider, per rendere i propri servizi online accessibili tramite SPID in modo da favorire e semplificare l’utilizzo dei servizi digitali da parte di tutti i cittadini devono attenersi a quanto indicato nella Come diventare fornitore di servizi SPID del sito governativo dedicato a SPID.

Le modalità di funzionamento di SPID sono quelle previste da SAML v2 per il profilo “Web Browser SSO” – SAML V2.0 Technical Overview – Oasis par4.3.

Come riportato nella documentazione presente sul sito developers.italia.it (la comunità italiana degli sviluppatori di servizi pubblici) al link SPID – Regole Tecniche – Introduzione l’implementazione SPID deve rispettare le seguenti:

Devono essere previste le due versioni “SP-Initiated”:

• Redirect/POST binding
  
• POST/POST binding
  

Il meccanismo di autenticazione è innescato dalla richiesta inoltrata dall’utente tramite browser ad un Fornitore di Servizi (Service Provider o SP) che si rivolge al Gestore delle Identità (Identity provider o IdP) selezionato dall’utente in modalità “pull”.

La richiesta di autenticazione SAML, basata sul costrutto <AuthnRequest>, può essere inoltrata da un Service Provider all’Identity Provider usando il binding:

• HTTP Redirect
  
• HTTP POST
  

La relativa risposta SAML, basata sul costrutto <Response>, può essere, invece, inviata dall’Identity Provider al Service Provider solo tramite il binding HTTP POST.

Di seguito lo l funzionamento di un’autenticazione SPID bastata su SAML v2.0:

Come riportato sul sito developers.italia.it al link SPID – Regole Tecniche – Regole tecniche Service Provider il Service Provider deve implementare l’autenticazione in base alle seguenti indicazioni:

Il fornitore di servizi (Service Provider o SP) eroga i servizi agli utenti, richiede l’autenticazione agli Identity Provider e gestisce la procedura di autorizzazione al servizio per la realizzazione dei profili SSO previsti, SP-Initiated Redirect/POST binding e POST/POST binding, deve mettere a disposizione le seguenti interfacce:

• IAuthnResponse: ricezione delle risposte di autenticazione SAML
  
• IMetadataRetrieve: permette il reperimento dei SAML metadata del Service Provider da parte dell’Identity Provider.
  

Per quanto riguarda processamento della <Response> ovvero l’implementazione dell’interfaccia IAuthnResponse devono essere osservate le seguenti indicazioni:

Alla ricezione <Response> qualunque sia il binding utilizzato il Service Provider prima di utilizzare l’asserzione deve operare almeno le seguenti verifiche:

• controllo delle firme presenti nella <Assertion> e nella <response>;
  
• nell’elemento <SubjectConfirmationData> verificare che:
  
  • l’attributo Recipient coincida con la assertion consuming service URL a cui la <Response> è pervenuta
    
  • l’attributo NotOnOrAfter non sia scaduto;
    
  • l’attributo InResponseTo riferisca correttamente all’ID della <AuthnRequest> di richiesta
    

Il fornitore di servizi deve garantire che le asserzioni non vengano ripresentate, mantenendo il set di identificatori di richiesta (ID) usati come per le <AuthnRequest> per tutta la durata di tempo per cui l’asserzione risulta essere valida in base dell’attributo NotOnOrAfter dell’elemento <SubjectConfirmationData> presente nell’asserzione stessa.

Per quanto riguarda invece l’implementazione dell’interfaccia IMetadataRetrieve devono essere osservate le seguenti indicazioni:

Le caratteristiche del Service Provider devono essere definite attraverso metadata conformi allo standard SAML v2.0 (SAML-Metadata) e rispettare le condizioni di seguito indicate:

Nell’elemento <EntityDescriptor> devono essere presenti i seguenti attributi:

• entityID: indicante l’identificativo univoco (un URI) dell’entità
  
• ID univoco, per esempio basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità)
  

L’elemento <KeyDescriptor>
contenenete il certificato della corrispondente chiave pubblica dell’entità, utile per la verifica della firma dei messaggi prodotti da tale entità nelle sue interazioni con le altre (SAML-Metadata, par. 2.4.1.1);

• deve essere l’elemento <Signature> riportante la firma sui metadata. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Metadata, cap. 3) utilizzando chiavi RSA almeno a 1024 bit e algoritmo di digest SHA-256 o superiore;
  

Per la massima tutela della privacy dell’utente il Service Provider deve rendere minima la visibilità dei servizi effettivamente invocati. In questa logica occorre rendere ove possibile indifferenziate le richieste relative a servizi che condividono lo stesso set minimo di attributi necessari per l’autorizzazione.

Infine quanto riguarda invece la disponibilità dei Metadata devono essere osservate le seguenti indicazioni:

I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso l’interfaccia IMetadataRetrive alla URL https://<dominioGestoreIdentita>/metadata, ove non diversamente specificato nel Registro SPID, e saranno firmate in modalita detached dall’Agenzia per l’Italia Digitale. L’accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile.

Per quanto riguarda la sicurezza sul canale di trasmissione nei documenti REGOLAMENTO RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014) e Avviso nr. 1 del 25 febbraio 2016 GESTIONE DELLA SICUREZZA DEL CANALE DI TRASMISSIONE viene riportato quanto segue:

Il profilo SAML SSO raccomanda l’uso di SSLv.3.0 o TLS 1.0 nei colloqui tra Asserting party (Identity Provider e Attribute Authority ), le Relying Party (Service Provider) e lo user agent. In ambito SPID si rende obbligatorio l’impiego di TLS nella versione più recente disponibile.

In relazione all’impiego di TLS (paragrafo 1.2.2.3 delle regole tecniche), al fine di fornire un riferimento più puntuale si precisa che, allo stato delle conoscenze, la versione raccomandata è la 1.2 e che, in casi particolari e temporanei, può essere adottata la versione 1.1, fermo restando che la versione 1.2 deve essere adottata lato server.

Conseguentemente, le versioni più obsolete dei browser, che non supportano le versioni del protocollo indicate, non devono essere utilizzate e, i livelli minimi accettati per l’accesso ai servizi SPID, devono essere documentati nei confronti degli utenti.

Oltre a implementare le interfacce per necessarie allo scambio d’informazioni tra SP e IP al fine di eseguire l’autenticazione sarà necessario, sia per una questione di user experience che di immagine del sistema, la standardizzazione delle interfacce, della comunicazione e dell’utilizzo del logo spid in base alle regole prodotte da AgID (a riguardo si veda il seguente LINEE GUIDA SULLE INTERFACCE E SULLE INFORMAZIONI IDP/SP).

Per quanto riguarda l’implementazione delle interfacce di comunicazione e l’adeguamento delle interfacce grafiche è possibile fare riferimento ai repository pubblicati su GitHub da developers.italia.it (la comunità italiana degli sviluppatori di servizi pubblici) disponibili all’interno del Repository GitHub Italia.

Per maggiori informazioni si vedano:

• REGOLAMENTO RECANTE LE REGOLE TECNICHE (articolo 4, comma 2, DPCM 24 ottobre 2014)
• Avvisi SPID

Procedura per l’implementazione di SPID da parte di una Pubblica Amministrazione

In sintesi una Pubblica Amministrazione (PA) per adeguare i sistemi informativi alle regole tecniche e alle regole di design dedicate a SPID deve completare due procedure, una tecnica e una amministrativa.

Procedura Tecnica

Il completamento della procedura tecnica richiede i seguenti passi.

Passo 1: implementare le interfacce di comunicazione basate su SAML v2 e adeguare le interfacce grafiche alla user experience richiesta da SPID.

A meno che la PA non abbia sviluppato in modo autonomo l’applicativo web su cui è necessario implementare SPID per renderlo accessibile in modo da favorire e semplificare l’utilizzo da parte di tutti i cittadini, tali operazioni vengono normalmente eseguite dal produttore dell’applicativo.

Passo 2: Elaborare un metadata come descritto nell’Avviso n. 6 del 29/07/2016 NOTE SUL DISPIEGAMENTO DI SPID PRESSO I GESTORI DEI SERVIZI tenendo presente che gli attributi richiesti per l’erogazione di ogni servizio online dovranno essere attinenti e non eccedenti.

A meno che PA non abbia sviluppato in modo autonomo l’applicativo web, anche in questo caso la PA dovrà coordinarsi col produttore dell’applicativo per l’elaborazione del metadata che di fatto è un documento XML contenente le informazioni necessarie per l’interfacciamento dei sistemi di un service provider con quelli delle entità con cui deve interagire (Identity provider e Attribute Provider).

Ogni service provider, secondo le regole tecniche SPID, deve mettere a disposizione un solo metadata (indipendentemente dal numero di servizi erogati dal Service Provider).

Passo 3: Dopo aver elaborato il primo metadata la PA dovrà renderlo disponibile su una url https della PA stessa e darne comunicazione segnalandolo al sistema di supporto per le pubbliche amministrazioni, selezionando la categoria “Comunicazione metadata”. Il metadata verrà verificato e, se necessario, sarà richiesto di apportare modifiche utili a garantire il rispetto delle regole tecniche, in questo caso sarà necessario ripetere la procedura di invio del metadata.

Il metadata dovrà essere firmato tramite chiavi RSA di almeno 1024 bit e algoritmo di digest SHA-256 o superiore (a riguardo si veda [SAML-Metadata] cap3).

Per la firma del metadata è possibile utilizzare un certificato a disposizione della PA con i requisiti richiesti oppure generarne uno autofirmato.

Nel Repository GitHub Italia – SPID Metadata Signer sono disponibili Tools e Scripts per la firma del metadata SAML SPID in ambienti Linux e MacOS.

Per firmare metadata SAML SPID in ambiente Windows è possibile utilizzare il porting del repository SPID Metadata Signer che ho reso disponibile GitHub al seguente SPID Metadata Signer in ambiente Windows.

Come detto precedentemente il metadata dovrà essere reso disponibile su una url https della PA come ad esempio https://<dominioGestoreIdentita>/metadata. Per assolvere a tale requisito la PA se non ha già a disposizione un sito istituzionale in https con certificato conforme ai requisiti all’interno del quale pubblicare il metadata, può acquistare un certificato o utilizzare Let’s Encrypt per ottenere un certificato tramite cui implementare la pubblicazione in https.

Per una guida su come configurare IIS, il web server nativo in Windows, per l’utilizzo ei certificati Let’s Encrypt si veda Implementazione di Let’s Encrypt in ambiente Windows Server 2016.

Se possibile per maggiore semplicità la scelta ottimale sarebbe quella di avere un host dedicato al web server che ospiterà il metadato rispondendo ad un sottodominio dedicato (per esempio spid.dominioserviceprovider) per consentire una maggior scalabilità e indipendenza della parte infrastrutturale dedicata all’autenticazione rispetto a quella dedicata alla parte applicativa.

Un server dedicato consente infatti una più semplice gestione della sicurezza permettendo di applicare configurazioni al livello del web server più restrittive e una modularità maggiore dell’infrastruttura che permette anche scenari ibridi in cui il web server che pubblica i metadati sia in cloud e il server applicativo on premisis.

Il web server che ospita il metadata dovrà infatti essere adeguatamente protetto per evitare compromissioni o mancate disponibilità del metadata stesso.

Nel caso il metadata venga esposto tramite IIS è possibile applicare una serie di best practices finalizzate all’hardenig del web server a riguardo si veda al esempio il mio post Hardening di IIS tramite le HTTP Response Headers.

Passo 4: Dopo che il metadata sarà accettato dagli Identity Provider, i servizi online potranno essere “interfacciati” a SPID per successivi test e messa in produzione.

Procedura Amministrativa

Una volta che i primi servizi interfacciati a SPID saranno pronti per essere pubblicati, il legale rappresentate della PA dovrà compilare e firmare la convenzione e dovrà essere compilato anche il file con l’indicazione dei servizi accessibili tramite SPID. Entrambi i documenti dovranno poi essere inviati all’indirizzo: protocollo@pec.agid.gov.it.

Per concludere il processo di adesione a SPID sono necessarie due figure di riferimento:

• Referente tecnico per tutte le attività di implementazione del sistema di autenticazione SPID
• Rappresentante legale per la firma della convenzione

Sicurezza

L’identità SPID è costituita da credenziali con caratteristiche differenti in base al livello di sicurezza richiesto per l’accesso. Scendendo nel dettaglio esistono tre livelli di sicurezza ognuno dei quali corrisponde a un diverso livello di identità SPID, i livelli di sicurezza di SPID corrispondono anche ad altrettanti livelli specificati nella norma internazionale ISO-IEC 29115:

• Livello 1: permette di accedere ai servizi online attraverso un nome utente e una password scelti dall’utente. A tale livello è associato un rischio moderato e compatibile con l’impiego di un sistema autenticazione a singolo fattore (password associata alla digitazione di una UserID). Il Livello 1 corrisponde al Level of Assurance LoA2 dello standard ISO/IEC DIS 29115.
• Livello 2: necessario per servizi che richiedono un grado di sicurezza maggiore permette l’accesso attraverso un nome utente e una password scelti dall’utente, più la generazione di un codice temporaneo di accesso (one time password). A tale livello è associato un rischio ragguardevole e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori, non necessariamente basato su certificati digitali (password e OTP associati alla digitazione di una UserID). Il Livello 2 corrisponde al Level of Assurance LoA3 dello standard ISO/IEC DIS 29115.
• Livello 3: oltre al nome utente e la password, richiede un supporto fisico (es. smart card) per l’identificazione. A tale livello è associato un rischio altissimo e compatibile con l’impiego di un sistema di autenticazione informatica a due fattori basato su certificati digitali e criteri di custodia delle chiavi private su dispositivi che soddisfano i requisiti dell’Allegato 3 della Direttiva 1999/93/CE. Il Livello 3 corrisponde al Level of Assurance LoA4 dello standard ISO/IEC DIS 29115.

Pubbliche amministrazioni e privati definiscono autonomamente il livello di sicurezza necessario per poter accedere ai propri servizi digitali, ma ad oggi sono disponibili solo identità SPID di primo e secondo livello (come riportato nella FAQ).

Per maggiori dettagli si veda l’Avviso nr 4 del 09/06/2016 Livelli di servizio minimo per funzionalità omogenee.

Conclusioni

Come riportato nella pagina Diffusione del sistema pubblico di identità digitale (SPID) del sito governativo ItaliaSemplice.gov.it i risultati attesi sulla diffusione di SPID erano di 3 milioni di utenti con un’identità digitale a settembre 2015 e di 10 milioni di utenti a dicembre 2017.

I dati aggiornati dello Stato di attuazione dell’agenda digitale di cui SPID fa parte sono disponibili alla pagina Avanzamento Crescita Digitale e al 05/05/2017 i dati erano i seguenti:

• amministrazioni attive: 3.720
• identity provider accreditati: 5
• servizi disponibili tramite SPID: 4.273
• identità SPID erogate: 1.384.375

Sebbene i dati reali di diffusione siano per il momento al di sotto dei valori attesi non si può negare che tale sistema di autenticazione non stia prendendo piede anche grazie ad azioni di Governo, come per esempio il bonus 18App e Carta del Docente, inoltre l’obbligo per le Pubbliche Amministrazioni di aderire al circuito SPID entro il 31 dicembre 2017 darà sicuramente un’ulteriore spinta.

Un altro elemento che aumenterà la diffusione di SPIP sarà l’attivazione del Livello 3 di sicurezza la cui assenza per il momento scoraggia le grandi realtà private come gli istituti di credito ad aderire al sistema.

Per avere informazioni sulle Pubbliche Amministrazioni che erogano i servizi abilitati SPID si veda la pagina Dove puoi usare SPID.

Mancano ormai pochissimi giorni all’evento GRATUITO DEV s IT che si terrà il 25 Maggio 2017 presso il Politecnico di Bari.

Organizzato dalle Community ICT Power e DotNetSide, in collaborazione con Microsoft Italia, Politecnico di Bari e Azione Universitaria Politecnico, è attualmente il più grande evento che si terrà nel Sud Italia nel 2017 e vedrà la partecipazione di studenti e di professionisti, sia del mondo IT (sistemisti) che del mondo DEV (sviluppatori).

Con 2 track parallele e la presenza di prestigiosi speaker, l’evento è in grado di assicurare una visione attuale e completa del panorama informatico e del mondo lavorativo, nell’ottica della Digital Transformation.

Durante la keynote Fabio Santini, Developer Experience and Evangelism Lead &
Andrea Benedetti, Director of Technical Evangelism di Microsoft Italia ci parleranno di Digital Transformation, Big Data, Cloud e Sicurezza.

Per la prima volta a Bari potremo vedere dal vivo anche le Hololens, la soluzione di Mixed Reality realizzata da Microsoft!

Paola Presutto, Senior Technical Evangelist di Microsoft, ci parlerà invece della soluzione di Hybrid Cloud realizzata con Microsoft Azure come naturale evoluzione ed espansione dell’azienda moderna, che non può rimanere indietro e che ha bisogno di soluzioni efficaci per essere competitiva sul mercato.

Non mancherà anche di assistere ad una sessione sul Public Speaking tenuta da Lorenzo Barbieri, Cloud Wizard di Microsoft Italia, che ha già destato forte interesse nelle edizioni precedenti e che sicuramente ci riserverà delle sorprese ed un suo intervento sul Cloud pubblico di Microsoft Azure visto a 360°.

La community ICTPower schiererà il proprio leader Nicola Ferrini, Microsoft Regional Director e doppio Most Valuable Professional, che in una sessione doppia ci mostrerà come amministrare al meglio un’azienda, con tutta una serie di funzionalità di cui ormai la sistemistica moderna non può più fare a meno. Grazie all’esperienza acquisita sul campo avremo esempi reali ed attuali di quelli che sono gli errori comuni commessi e verrà mostrato come ottimizzare le infrastrutture esistenti con un laboratorio guidato. Insomma.Windows Server in azienda al massimo del suo potenziale!

Vito Macina (Microsoft Most Valuable Professional e Digital Strategist) e Gianluca Nanoia (IT & Security Expert), anche loro membri della Community ICTPower, vi faranno vedere Windows 10 oltre ogni limite, con particolare riferimento alle ultime novità della Creators Update e alla collaborazione con il mondo Linux ed Open Source in genere.

Gianluca Nanoia terrà anche una sessione sulla Cybersecurity, argomento di grandissima attualità, in cui ci parlerà di come implementare una strategia ottimale di difesa dagli attacchi informatici, analizzando anche le dinamiche degli ultimi avvenimenti, come ad esempio la diffusione del virus Wannacry.

Avete mai sentito parlare di ChatBot? No??? Allora la sessione di Giulio Mallardi, Solution Architect e membro della Community ICTPower, fa al caso vostro. I chatbot, programmi che simulano una conversazione tra robot e essere umano, non avranno più segreti per voi!

Fabio Cozzolino, anche lui doppio Most Valuable Professional e leader della Community DotNetSide, farà vedere come creare applicazioni utilizzando Visual Studio per Mac, creato con Mono, una piattaforma di sviluppo open source basata su .NET Framework sponsorizzata da Microsoft. Sessione imperdibile!

Salvatore Aprile, anche lui membro della Community DotNetSide, ci mostrerà invece come sviluppare le Real-Time Web Application, applicazioni che gestiscono le informazioni trasmessendole praticamente in tempo reale tra l’utente e i server (o tra utente ed utente), in contrasto con le tradizionali web app in cui il client deve richiedere le informazioni al server.

Prestigioso e decisamente interessante sarà anche la sessione di Andrea Benedetti, Director of Technical Evangelism di Microsoft Italia, che ci parlerà di Intelligenza Artificiale e della vision di Microsoft su questo argomento. Solo pochi giorni fa a Build 2017, la conferenza annuale di Microsoft dedicata agli sviluppatori che orbitano attorno al mondo Windows, sono state mostrate delle novità incredibili su questo argomento e certamente Andrea avrà delle fantastiche demo da mostrare!

Non mancherà anche un angolo esperti grazie alla presenza dei Microsoft Student Partner di Bari, che saranno disponibili a rispondere alle vostre domande tecniche e a mostrarvi le novità dei prodotti Microsoft Consumer.

Sicuramente non avete più scuse per partecipare. Per potervi registrare gratuitamente all’evento usare il QR Code nell’immagine qui sopra, visitate il link https://devsit-poliba.eventbrite.it oppure utilizzare il form qui sotto. Vi aspettiamo!

Si è conclusa la prima edizione del DEV s IT, evento gratuito che si è tenuto presso il Politecnico di Bari il 25 Maggio 2017 e che ha avuto come filo conduttore la volontà di far vedere ai laureandi e ai liberi professionisti quelle che sono le novità del panorama delle tecnologie Microsoft sia per gli sviluppatori che per i sistemisti.

La conferenza, unica nel suo genere, grazie al notevole contenuto delle sessioni proposte ha avuto un enorme afflusso di pubblico (oltre 200 partecipanti) , ha generato notevole interesse e partecipazione da parte dei presenti e si è profilata come il più grande evento tecnico del Sud Italia del 2017.

Al Politecnico di Bari abbiamo sperimentato che la tecnologia può e deve essere il motore di una vera e grande rivoluzione, soprattutto quando la si comprende. Il primo evento DEV s IT ha messo insieme ICT Power (community di sistemisti) e DotNetSide – .NET South Italy Developers User Group (community di sviluppatori) per creare un qualcosa di unico e ricco di passione sia per gli sviluppatori che per i sistemisti. La presenza ed il supporto di 3 importanti esponenti del team di evangelismo di Microsoft Italia, che ci hanno accompagnato in questa grande prima avventura, ha determinato l’entusiasmo di tutti i partecipanti, che a gran voce ne hanno chiesto una seconda edizione.

Notevole il supporto offerto dai ragazzi di Azione Universitaria Politecnico, a cui vanno i nostri più sentiti ringraziamenti. Si sono prodigati in maniera considerevole per organizzare la logistica dell’evento e sono stati davvero eccezionali.

I Microsoft Students Partner di Bari hanno messo a disposizione il proprio tempo per creare un corner tecnico dove hanno risposto alle domande degli studenti, entusiasmati dalle presentazioni degli speaker e dalla Keynote tenuta da Fabio Santini, Head of Innovation di Microsoft Italia.

Gli speaker poi, quasi tutti Microsoft MVP (Most Valuable Professional), si sono fermati a lungo a parlare con professionisti e studenti e ad approfondire i temi trattati durante le sessioni, fornendo indicazioni su dove reperire poi altro materiale di studio. Sicuramente il terreno era fertile per invitare gli studenti ad approfondire e a studiare.

Quello che da una parte mi ha fatto molto piacere, mentre dall’altra mi continua a turbare, è stata la dichiarazione di almeno 5 persone, di aziende diverse, che hanno dovuto chiedere un giorno di ferie per partecipare alla conferenza, in quanto il proprio responsabile si era opposto alla loro partecipazione in orario lavorativo. Stiamo assistendo a scenari tecnologici in cui c’è una velocità di aggiornamento senza pari rispetto al passato. Non aggiornarsi significa rimanere indietro e non essere più competitivi. Ritengo, come tecnico e come formatore, che sia ridicolo non far aggiornare i proprio dipendenti e non farli addirittura partecipare a seminari gratuiti. Nel nostro caso, oltre alla prestigiosa location del Politecnico di Bari, la conferenza è stata tenuta dai TOP tecnici italiani, pluricertificati e pluripremiati a livello mondiale. E, si sa, la conferenza la fanno gli speaker!

Abbiamo offerto un’occasione immancabile per aggiornarsi e avere un’idea chiara dei trend tecnologici dei mesi a venire e delle opportunità di investimento nelle nuove tecnologie. Spero che questi responsabili un giorno leggano queste righe e si attivino personalmente nel cambiare questo stato di cose e questa inattività. La formazione è e deve essere un presupposto essenziale per la crescita delle persone, delle aziende e del business.

Grazie ancora a tutti gli speaker e i ragazzi, che hanno messo a disposizione a titolo gratuito il proprio tempo libero per poter dare un’opportunità di crescita ai nostri giovani e ai professionisti, che hanno fatto della propria passione un lavoro e del proprio lavoro una passione.

A questo link trovate tutti i tweet con l’hashtag #devsit17, mentre nei prossimi giorni pubblicheremo un articolo dedicato con tutte le slide e i video delle sessioni registrate.

Al prossimo anno con…guardate il Teaser qui sotto!

Mentre nelle precedenti versioni di Windows Server era necessario che tutti i nodi di un cluster fossero joinati ad un dominio di Active Directory, in Windows Server 2016 è stata introdotta la possibilità di creare cluster usando dei nodi in workgroup, permettendo quindi di non dover utilizzare un dominio ed implementare dei domain controller.

Nota: Con Windows Server 2016 è inoltre possibile creare cluster i cui nodi appartengono a domini diversi.

Per implementare un workgroup cluster o un multi-domain cluster è necessario però che vengano rispettati determinati prerequisiti:

• Creare un account utente con lo stesso nome e la stessa password su tutti i nodi
• Aggiungere l’account creato al gruppo Administrators locale
• Se non si utilizza l’account predefinito Administrator è necessario creare la chiave di registro LocalAccountTokenFilterPolicy in HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System e metterla con valore 1
• Il cluster deve essere creato nella modalità Active Directory-Detached Cluster, senza creare nessun oggetto in AD
• È necessari creare il Cluster Network Name (chiamato anche Administrative Access Point) di tipo DNS
• Ogni nodo deve avere un suffisso DNS
• Nel caso di un multi-domain cluster, i suffissi DNS per tutti i domini del cluster devono essere presenti su tutti i nodi
• Il Witness consigliato è un Cloud Witness oppure un Disk Witness. Non è supportato in entrambi i casi l’utilizzo del File Share Witness.

In questo articolo creeremo un workgroup cluster a due nodi (chiamati NODO1 e NODO2) utilizzando Windows Server 2016. Dopo aver preparato i nodi del cluster ed aver installato il sistema operativo ho provveduto a configurare il suffisso DNS su entrambi i nodi, come mostrato in figura:

Figura 1: Modifica del suffisso DNS

Dopo aver riavviato entrambi i nodi, ho provveduto a modificare il file HOSTS sulle macchine in modo tale che potessero risolvere i nomi dei nodi e il nome del cluster (che ho deciso di chiamare WRKGCLUSTER). Questa operazione è necessaria solo se non volete configurare un DNS. Nel caso abbiate un DNS in rete potete popolare la zona scelta (il suffisso DNS) per il vostro cluster (nel mio caso demo.lab).

Figura 2: Modifica del file HOSTS per la risoluzione del nomi

Ho provveduto quindi a creare su entrambi i nodi l’account di servizio ClusterSVC, ho impostato la stessa password e l’ho aggiunto al gruppo Administrators locale, come mostrato in figura:

Figura 3: Creazione dell’account per l’autenticazione NTLM

L’account è necessario affinché i nodi utilizzino l’autenticazione NTLM. Poiché non sto usando l’account Administrator è necessario inserire sui nodi la chiave di registro indicata nei prerequisiti. In maniera rapida ho eseguito sui due nodi, da un prompt PowerShell con privilegi elevati, il comando:

New-ItemProperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

Figura 4: Inserimento della chiave di registro necessaria all’utilizzo degli account

Successivamente ho provveduto ad installare la feature del Failover Cluster sui due nodi. È possibile usare il Server Manager oppure il comando PowerShell
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools

Figura 5: Installazione della funzionalità di Failover Cluster tramite PowerShell

Terminata l’installazione ho avviato il Failover Cluster Manager e ho lanciato il wizard per la creazione del Cluster. Ho aggiunto i due nodi e ho cliccato su Next, come mostrato in figura:

Figura 6: Aggiunta dei due nodi

Nella schermata successiva ho deciso di lanciare il Validate Configuration Wizard che ovviamente mi ha riportato dei Warning, come mostrato in figura:

Figura 7: Validate Configuration Wizard

Figura 8: Warning relativo alla non appartenenza dei nodi del cluster al dominio

Nella schermata successiva del wizard ho indicato il nome del cluster e l’indirizzo IP scelto, come mostrato in figura:

Figura 9: Scelta del nome del cluster e dell’indirizzo

Terminata la verifica che non ci sia un server con lo stesso nome NETBOIS e non ci siano indirizzi IP duplicati nella stessa rete, appare la schermata riepilogativa mostrata in figura, che indica che il cluster utilizzerà per la registrazione solo il DNS:

Figura 10: Schermata riepilogativa relativa alla creazione del cluster

La stessa operazione poteva essere effettuata utilizzando il comando PowerShell

New-Cluster –Name WRKGCLUSTER.demo.lab -Node NODO1.demo.lab,NODO2.demo.lab -AdministrativeAccessPoint DNS -StaticAddress 10.10.0.5

Al termine della procedura ho ottenuto la schermata finale dell’avvenuta creazione del cluster

Figura 11: Creazione del cluster completata

Figura 12: Nodi del cluster attivi

Conclusioni

I Workgroup Cluster e i Multi-Domain Cluster sono decisamente un’importante novità introdotta in Windows Server 2016. I workload supportati sono SQL Server, File Server e Hyper-V. Per quanto riguarda Hyper-V la mancanza dell’autenticazione Kerberos in realtà complica le cose in quanto la Live Migration non è supportata, mentre è supportata la Quick Migration.

Il Site-Aware failover è una novità relativa alla funzionalità di Failover Clustering che è stata introdotta in Windows Server 2016. Anche se in realtà già in Windows Server 2012 R2 era possibile realizzare un cluster i cui nodi erano funzionanti in due regioni geografiche diverse, non c’era modo per indicare in quale di queste regioni si trovassero i diversi nodi, in modo tale da poterli gestire in maniera diversa e poter indicare ai diversi servizi di poter fare “failover” nella stessa area geografica.

Con Windows Server 2016 è stata invece introdotta la possibilità di raggruppare i nodi in base alla loro posizione fisica in modo tale da poter, ad esempio, permettere alle risorse del cluster di poter essere trasferite su un nodo nello stesso sito in caso di manutenzione o draining di un altro nodo.

Per poter implementare la site awareness è possibile procedere in due modi, uno automatico ed uno manuale.

Se si utilizza il modo automatico è possibile utilizzare i Site di Active Directory. Quindi se avete già definito dei Site dentro i quali avete messo i vostri Domain Controller e a cui avete associato delle subnet, vi basterà digitare il comando PowerShell (lanciato con privilegi elevati):

(Get-Cluster).AutoAssignNodeSite = 1

Se volete utilizzare la modalità manuale sarà invece prima necessario definire quali sono i Site e successivamente aggiungervi i nodi, utilizzando i comandi PowerShell (lanciati con privilegi elevati):

#Creazione dei Site

New-ClusterFaultDomain –Name Roma –Type Site –Description “Datacenter Primario” –Location “Datacenter Roma”

New-ClusterFaultDomain –Name Milano –Type Site –Description “Datacenter Secondario” –Location “Datacenter Milano”

#Assegnazione dei nodi ai Site

Set-ClusterFaultDomain –Name Nodo1 –Parent Roma

Set-ClusterFaultDomain –Name Nodo2 –Parent Roma

Set-ClusterFaultDomain –Name Nodo3 –Parent Milano

Set-ClusterFaultDomain –Name Nodo4 –Parent Milano

Questo tipo di configurazione permette di migliorare notevolmente il failover, il placement delle macchine virtuali, gli heartbeat tra i nodi e il quorum.

Ad esempio la Failover Affinity permette che le risorse vengano spostate su un nodo dello stesso sito, prima di tentare di spostarle in un sito differente. Inoltre durante la Node Drain le macchine virtuali vengano spostate localmente, su un nodo vicino.

Il Cross-Site Heartbeat da’ la possibilità di configurare in maniera accurata alcuni parametri come ad esempio il CrossSiteDelay (il tempo tra due heartbeat inviati tra nodi in siti diversi) e il CrossSiteThreshold (il numero di heartbeat persi tra due nodi in site diversi). Entrambi i valori sono configurabili con i comandi PowerShell (lanciati con privilegi elevati)

(Get-Cluster).CrossSiteDelay = 1000    #valore di default

(Get-Cluster).CrossSiteThreshold = 20  #valore di default

Un’altra interessante novità di Windows Server 2016 riguarda la Virtual Machine Node Fairness, che è già abilitata di default ma che viene disabilitata se utilizzate la funzionalità Dynamic Optimization di System Center Virtual Machine Manager. La VM Node Fairness permette di bilanciare le macchine virtuali tra i diversi nodi del cluster: dopo aver valutato l’utilizzo del processore e della memoria, le macchine vengono automaticamente migrate (utilizzando la Live Migration) da un nodo più carico ad un nodo scarico. Il bilanciamento può essere configurato per ottenere le migliori performance nel cluster, utilizzando il comando PowerShell (eseguito con privilegi elevati) per configurare la percentuale di utilizzo del nodo:

(Get-Cluster).AutoBalancerLevel = 2

riprendendo i valori dalla seguente tabella:

Oppure è possibile configurare ogni quanto tempo deve essere utilizzata la node fairness, utilizzando il comando PowerShell (eseguito con privilegi elevati):

(Get-Cluster).AutoBalancerMode = 2

riprendendo i valori dalla seguente tabella:

Conclusioni

Queste due importanti novità relativa al cluster di Windows Server 2016 sono pensate sia per la gestione del Disaster Recovery geografico tra diversi siti della nostra infrastruttura, sia per l’ottimizzazione delle performance dei nodi, senza dover ricorrere a prodotti a pagamento come SCVMM. Sicuramente un grosso passo in avanti per rendere i nostri datacenter più performanti ed avere lo stesso livello di funzionalità offerte dal Cloud pubblico.

Se ne è parlato qualche mese fa e finalmente arriva l’annuncio ufficiale. Microsoft ha presentato una nuova SKU del sistema operativo Windows 10 dedicata ai cosiddetti Power User, ovvero utenti che utilizzano Workstation con hardware di fascia alta (anche di livello Server) e in scenari che richiedono un’elevata potenza di calcolo.

Questa ulteriore edizione di Windows 10 è frutto dei feedback provenienti dalla grande Community dei Windows Insider e sarà rilasciata in concomitanza con il prossimo aggiornamento di funzionalità a settembre, Fall Creators Update.

Il valore di Windows 10 Pro for Workstations è strutturato per aumentare le prestazioni e l’affidabilità dei PC di fascia alta con le seguenti “nuove” caratteristiche:

• Resilient File System (ReFS). Il nuovo file system progettato per ottimizzare la disponibilità dei dati, ridimensionare in modo efficiente a set di dati grandi in vari carichi di lavoro e per garantire l’integrità dei dati per mezzo della resilienza ai danneggiamenti, introdotto in Windows Server, verrà abilitato di default.
• Memoria Persistente. Supporto ai nuovi moduli di memoria non volatile NVDIMM-N, ovvero nuovi dispositivi con un comportamento simile ad altre memorie di massa come i classici dischi rigidi e i nuovi dischi a stato solido (SSD). Questa nuova tecnologia migliora notevolmente la velocità di lettura e scrittura dei file. Essendo NVDIMM-N una memoria non volatile, allo spegnimento della Workstation, i file saranno sempre disponibili.
• File Sharing rapido. Nella nuova edizione di Windows 10 è presente una nuova funzione chiamata SMB Direct, la quale supporta l’utilizzo delle schede di rete che dispongono di Remote Direct Memory Access (RDMA). Queste possono operare alla massima velocità con bassissima latenza e utilizzare meno CPU.
• Supporto Hardware esteso. Gli utenti che dispongono di configurazioni ad alte prestazioni avranno il supporto a queste nuove tipologie di hardware. Saranno supportati processori di livello server, come Intel Xeon o AMD Opteron, fino 4 CPU (oggi il limite è 2 CPU) e memoria RAM fino a 6 TB (oggi il limite è 2 TB).

Sicuramente una grande attenzione alle prestazioni da parte di Microsoft in un periodo dove l’innovazione viaggia molto rapidamente. Con l’arrivo di Windows 10 Pro for Workstations avremo modo di utilizzare il sistema operativo ad un livello superiore, consentendo di massimizzare ogni aspetto della nostra Workstation all’ultimo grido.

Nel sondaggio condotto da Gartner del 17 marzo 2017 sull’adozione di Windows 10 in vendita al seguente User Survey Analysis: Windows 10 Migration Looks Healthy si stima che l’85% delle aziende hanno iniziato la migrazione a Windows 10 e la porteranno a termine entro la fine del 2017, il sondaggio è stato condotto alla fine del 2016 su 1000 aziende di sei paesi.

In un secondo sondaggio eseguito da Dimensional Research sull’adozione di Windows 10 commissionato da Ivanti pubblicato il 27 aprile 2017 al seguente Windows 10 Adoption is Quickly Accelerating but Plagued with Concerns, Reports New Ivanti State of Windows 10 Adoption Survey si stima che il 91% delle organizzazioni IT hanno iniziato l’adozione di Windows 10, il sondaggio è stato condotto su 1.800 professionisti IT di tutto il mondo.

Ed Bott, Microsoft MVP e giornalista autore di libri su tecnologie Microsoft da più di 25 anni, ha analizzato il sondaggio di Gartner e lo ha confrontato con il sondaggio di Dimensional Research e ha condiviso alcune interessanti informazioni che ermergono dai sondaggi nell’articolo Windows 10 Upgrades Accelerate, Yet Many IT Pros Have Concerns pubblicato da Redmond Magazine:

• Secondo Gartner il tempo di deploy di Windows 10 in una azienda che è di circa 21 mesi e secondo Dimensional Research il 77% delle organizzazioni intende completare la migrazione in due anni
• Secondo Dimensional Research gli ostacoli all’adozione di Windows 10 sono dovuti per il 50% al software legacy e per il 26% a fornitori di applicazioni di terze parti
• Secondo Gartner un quarto delle aziende non intraprende l’adozione di Windows 10 a causa del budget limitato in quanto non considera tale attività business-critical
• Secondo Dimensional Research il 60% riferisce che i tempi di logon in Windows 10 sono più veloci e il 16% che sono molto più veloci

Da entrambi i sondaggi, come riferisce Ed Bott, emerge una sorprendente popolarità di Windows 10 Long-Term Servicing Branch (LTSB). Secondo Dimensional Research una azienda su cinque e il il 27% delle aziende con più di 5.000 prevede di distribuire LTSB. Di seguito le considerazioni di Ed Bott a riguardo di questo aspetto sulle statistiche di adozione di Windows 10:

“Those numbers must be causing sleepless nights and even a few ulcers among product planners in Redmond. Microsoft is positioning the LTSB as a special-purpose distribution, one that should be reserved for hardware running mission-critical applications where stability is paramount.

But these findings suggest that enterprise admins are planning to use the LTSB to justify holding off because of what they perceive as the chaos of the new twice-yearly schedule for Windows 10 feature updates.

As Windows 10 nears its second anniversary, Microsoft has made some concessions to those skittish admins. With careful planning, an organization can stay on a single release in the Current Branch for Business for up to 18 months.

For IT admins who are used to planning upgrades every five years, that still feels much too fast.”

La scelta tra services models CCB (Current Branch for Business) o LTSB (Long Term Servicing Branch) che da luglio sono diventati rispettivamente Semi-Annual Channel e Long-Term Servicing Channel (a riguardo si veda il post Novità nei Microsoft servicing models è da valutare attentamente.

Innanzitutto va precisato che LTSB/LTSC è adottabile solo da quelle aziende che hanno la possibilità di utilizzare l’edizione Windows 10 Enterprise in quanto LTSB è una versione dell’edizione Enterprise, quindi occorre avere una Software Assurance attiva sul sistema operativo. Di conseguenza i ragionamenti che seguiranno possono essere applicati ad aziende che sono titolari di contratti multilicenza o aderiscono al programma Cloud Solution Provider (a riguardo si veda il seguente link https://www.microsoft.com/it-it/windowsforbusiness/buy).

Scendendo nel dettaglio Windows 10 LTSB è una versione di Windows 10 priva di alcune caratteristiche, ma per il resto è di fatto una versione Enterprise comprensiva di tutte le caratteristiche di sicurezza avanzate quali Device Guard, Windows Information Protection, Windows Defender ATP con un supporto supporto è di 10 anni dalla data di rilascio di una build contro i 18 mesi del service model Semi-Annual Channel. Quindi LTSB garantisce per 10 anni il rilascio di aggiornamenti di sicurezza e aggiornamenti qualitativi

Le caratteristiche non disponibili e le limitazioni nella versione LTSB sono:

• Tutte le app cosiddette “first party” come ad esempio posta, calendario, news, meteo, camera
• Lo Store anche se è possibile aggiungere app in quanto il framework per eseguirle è presente
• Non può essere aggiornata alla build successiva tramite Windows Update, ma solo da strumenti quali WSUS, SCCM o di terze parti
• Non è presente Cortana
• Non è presente il browser Edge (è presente Internet Explorer 11)
• E’ sconsigliato l’utilizzo di Office 365 click 2 run e suggerito l’utilizzo di Office 2016
• E’ sconsigliato l’utilizzo su hardware Surface
• La cadenza di rilascio delle nuove build non è così regolare in quanto è stato dichiarato che verrà pubblicata una nuova build Long Term ogni circa 3-4 anni, ma va precisato che la prima build era stata pubblicata nel 2015 e la seconda nel 2016

A riguardo si veda Windows 10 Long Term Servicing Branch (LTSB) di Marco Moioli (Technology Solutions Professional Windows 10 at Microsoft).

Microsoft ha dato delle linee guida su quelli che sono gli scenari in cui è suggerita l’adozione dell’LTSB/LTSC, come riportato in Overview of Windows as a service, indicando che l’LTSP dovrebbe essere utilizzata solo per special-purpose devices o specialized systems, va precisato che questa è un linea guida, non viene dichiarato che scenari differenti non siano supportati, ma solo che sarebbero più indicati per il Semi-Annual servicing channel:

“Specialized systems—such as PCs that control medical equipment, point-of-sale systems, and ATMs—often require a longer servicing option because of their purpose. These devices typically perform a single important task and don’t need feature updates as frequently as other devices in the organization. It’s more important that these devices be kept as stable and secure as possible than up to date with user interface changes. The LTSC servicing model prevents Windows 10 Enterprise LTSB devices from receiving the usual feature updates and provides only quality updates to ensure that device security stays up to date. With this in mind, quality updates are still immediately available to Windows 10 Enterprise LTSB clients, but customers can choose to defer them by using one of the servicing tools mentioned in the section Servicing tools.”

“Long-term Servicing channel is not intended for deployment on most or all the PCs in an organization; it should be used only for special-purpose devices. As a general guideline, a PC with Microsoft Office installed is a general-purpose device, typically used by an information worker, and therefore it is better suited for the Semi-Annual servicing channel.”

Inoltre viene specificato che è possibile passare dalla versione LTSB di Windows 10 Enterprise alla versione Semi-Annual Channel di Windows 10 Enterprise senza perdita di dati in quanto è supportato l’upgrade tra le due versioni:

“If an organization has devices currently running Windows 10 Enterprise LTSB that it would like to change to the Semi-Annual Channel, it can make the change without losing user data. Because LTSB is its own SKU, however, an upgrade is required from Windows 10 Enterprise LTSB to Windows 10 Enterprise, which supports the Semi-Annual Channel.”

Dato per scontato che sia possibile utilizzare l’edizione Enterprise di Windows 10, che le funzionalità non presenti in LTSB non siano di interesse e non siano necessarie funzionalità diverse da quelle presenti nella build installata per due o tre anni è possibile valutare se eseguire il deploy della versione LTSB/LTSC o della versione Semi-Annual Channel.

Il post Throwback Thursday: To CBB or to LTSB? pubblicato su ivanti contiene una serie di considerazioni e valutazioni sull’azione di LTSB/LTSC o di CBB/SAC che possono essere utilizzare per orientarsi e la prima considerazione che viene fatta è che la scelta tra CCB/SAC e LTSB/LTSC è qual è il tempo entro occorre necessariamente eseguire un upgrade di build:

“Microsoft is very zealous in its insistence that LTSB should only be used for machines that are “not general purpose”. According to them, a machine that has Microsoft Office on it counts as “general purpose” (an interesting way of classification!), and should therefore always be allocated to the CBB branch. Examples of LTSB use cases only cover critical endpoints such as air-traffic control systems and life-support machines. So to make the choice between CB/CBB or LTSB, what you really need to know is exactly how long you have before the next upgrade must be applied.”

La seconda considerazione che viene fatta è che l’upgrade ad una build successiva va pianificato e gestito nel modo corretto e soprattutto occorre conosce il tempo necessario per eseguire tale attività. L’upgrade ad un build successiva è infatto l’adozione di una versione successiva del sistema operativo e quindi occorre eseguire nell’arco dei 18 mesi i test, la gestione degli eventuali issue e incompatibilità, la gestione dell’impatto di eventuali cambi all’interfaccia utente , la gestione di eventuali feature rimosse, la verifica della poolicies applicate per la gestione centralizzata e quindi il deploy:

“So if we consider 8-14 months as the servicing window for a CBB machine, and err on the side of caution down to 8 months, then in that eight month period you must:

• Test all applications
• Identify any application issues
• Work with vendors to resolve application issues and verify success
• Assess the user interface for any potential changes that require training or communications
• Identify any features which have been removed that users may rely on
• Verify that all previously-applied policies and configurations still work as intended

And that’s probably not an exhaustive list…I’m sure every enterprise out there has some specific testing that needs doing in addition to this list. The presence of the Windows Insider branch means that some of these actions can be done prior to the actual CB release, but still, it’s a lot of work.

So really, when you are deciding on CB/CBB or LTSB, the main question is – do you think you can fit all of the required testing and remediation into the maintenance window? If the answer is yes, use CB/CBB. If not, then go with LTSB.”

Una terza considerazione riguarda l’adozione di LTSB che secondo un sondaggio condotto da ivanti tra gli enterprise EUC (End-user computing) admins indicherebbe che 1 su quattro hanno pianificato di adottare LTSB contro il 54% che ha deciso di adottare CB/CBB, mentre i rimanenti hanno optato per un’adozione mista di LTSB e CB/CBB, di seguito le percentuali:

• 54% di adozione CB/CBB
• 24% di adozione mista CB/CBB e LTSB
• 22% di adozione LTSB

“Interestingly, nearly 1 in 4 respondents reported plans to adopt LTSB, compared to 54% for CB/CBB. The remainder were opting for a mixed environment encompassing both major branches.

The lion’s share of respondents appear committed to embracing the CB/CBB model, but it is also clear that many more people than Microsoft expected are looking at adopting LTSB – either wholly, or in part.”

Una quarta considerazione è che delle limitazioni di LTSB quella che per esperienza dell’autore quella che è più sentita è la mancanza di Edge, mentre la manca dell Store, Cortana e delle Universal Apps non viene al momento percepita come una ragione per scegliere CB/CBB.

“In my experience, the main feature that is lost when adopting LTSB is Microsoft Edge. It’s about the only application or feature that businesses seem to be concerned about losing access to. The Windows Store, Cortana, and all the other Universal Apps don’t seem yet to have enough uptake or interest to justify any meaningful interest in adopting CBB on a feature basis alone.

However, because there isn’t a real killer app available on the UWP platform yet…doesn’t mean there won’t be one. Microsoft – and other vendors too – are slowly porting applications to the new platform, and every iterative update of Windows 10 brings more. The Desktop Bridge offers a way for vendors to convert applications directly from legacy desktop formats without a huge development effort, and this may drive future movement towards the UWP model.”

Per quanto riguarda le Pubbliche Amministrazioni italiane l’adozione di LTSB/LTSC in determinati ambienti e scenari potrebbe aiutare nell’adempimento delle Misure minime di sicurezza ICT per le pubbliche amministrazioni pubblicate nella CIRCOLARE 17 marzo 2017, n. 1/2017 sulla Gazzetta Ufficiale che recepisce la Direttiva del Presidente del Consiglio dei ministri 1° agosto 2015 – 17A02399. L’adeguamento delle Pubbliche amministrazioni alle Misure minime dovrà avvenire entro il 31 dicembre 2017, a cura del responsabile della struttura per l’organizzazione, l’innovazione e le tecnologie di cui all’art.17 del C.A.D., ovvero, in sua assenza, del dirigente allo scopo designato.

Per semplificare l’adeguamento alla misura minima ABSC 2.1.1 se non necessario è conveniente non consentire l’utilizzo di app:

• ABSC 2.1.1: Stilare un elenco di software autorizzati e relative versioni necessari per ciascun tipo di sistema, compresi server, workstation e laptop di vari tipi e per diversi usi. Non consentire l’installazione di software non compreso nell’elenco.

L’adeguamento alle misure minime ABSC 3.2.1 e ABSC 4.1.1 può essere più semplice in quanto LTSB/LTSC garantisce una stabilità della configurazione delle workstation per maggior tempo:

• ABSC 3.2.1: Definire ed impiegare una configurazione standard per workstation, server e altri tipi di sistemi usati dall’organizzazione.
• ABSC 4.1.1: Ad ogni modifica significativa della configurazione eseguire la ricerca delle vulnerabilità su tutti i sistemi in rete con strumenti automatici che forniscano a ciascun amministratore di sistema report con indicazioni delle vulnerabilità più critiche.

L’adeguamento alla misura minima ABSC 4.5.1 implica che i sistemi siano sempre aggiornati e quindi nel caso di adozione del CBB/SAC il rispetto del deploy della buid successiva entro i 18 mesi deve essere tassativamente rispettato:

• ABSC 4.5.1: Installare automaticamente le patch e gli aggiornamenti del software sia per il sistema operativo sia per le applicazioni.

Conclusioni

Come emerge dalle statistiche il tempo medio di una migrazione a Windows 10 è di circa due anni questo significa che adottando il service model Current Branch for Business / Semi-Annual Channel sarà necessario eseguire su alcune macchine un upgrade di Build in quanto il supporto del sistema operativo termina dopo 18 mesi dal rilascio della build.

Lo scoglio più comune l’adozione di una nuova Build di Windows 10 ogni 18 mesi sono le ridotte risorse IT che non riescono a completare test e deploy in tale periodo oppure l’impossibilità di avere software certificato per la nuova build entro tale periodo.

Nel caso di dubbio tra l’adozione di CBB/SAC o LTSB/LTSC l’adozione di Windows 10 Enterprise LTSB permette di gestire l’infrastruttura con maggior tranquillità per un determinato periodo tenendo conto che in caso di necessità è possibile eseguire semplicemente l’upgrade alla versione Windows 10 Enterprise CBB/SAC senza alcuna perdita di dati.

Lo scorso 14 settembre 2017 è stato annunciato al pubblico un nuovo progetto, attualmente in Technical Preview, che è stato concepito per poter gestire Windows Server utilizzando un browser e concentrando in un’unica console l’intera gestione del sistema operativo. Il Project ‘Honolulu’ (questo il nome in codice del software in attesa del nome definitivo) è un nuovo tool che sarà rilasciato in maniera autonoma, per permetterne un più rapido sviluppo, e sarà in grado di gestire Windows Server 2012, Windows Server 2012 R2 e Windows Server 2016.

Se volete provarlo anche voi, dal 22 settembre 2017 potete scaricarlo da link https://aka.ms/HonoluluDownload e partecipare alla Technical Preview.

Giusto per darvi un’idea di quello che farà Project Honolulu vi allego subito un’immagine delle FAQ:

Figura 1: FAQ relative a Project Honolulu

Dopo aver scaricato il software, che pesa solo 30 MB, procedete all’installazione, scegliendo con pochi clic quale porta usare per il webserver e quale certificato (per il momento andrà bene un certificato self-signed). Volendo è anche possibile consultare la Deployment Guide al link https://docs.microsoft.com/en-us/windows-server/manage/honolulu/deployment-guide

Figura 2: Installazione del software Project Honolulu

Terminata l’installazione se provate ad accedere utilizzando Internet Explorer riceverete un messaggio di errore che vi avviserà che il sito è navigabile solo con browser moderni, come Microsoft Edge oppure Google Chrome.

Figura 3: Browser supportati da Project Honolulu

Utilizzando uno dei browser suggeriti (io userò Google Chrome), collegatevi all’indirizzo del server dove avete installato il tool e loggatevi con credenziali amministrative, come mostrato in figura:

Figura 4: Autenticazione alla pagina web di amministrazione

Dopo la fase di autenticazione vi verrà presentata una schermata di benvenuto, come pochi semplici passi per familiarizzare con la console.

Figura 5: Schermata di benvenuto del tool

Noterete subito che il server sul quale è stato installato Project Honolulu è stato aggiunto di default alla console. Se volete aggiungere altri server (server singoli, failover clusters, ecc.) vi basterà cliccare sul pulsante Add e a destra della console vi apparirà Add Connections, come mostrato in figura:

Figura 6: Aggiunta di ulteriori server da gestire

Cliccando sui link dei diversi server vi apparirà una schermata dalla quale sarà possibile avere un’Overview dello stato di utilizzo del server, gestire certificati, dispositivi, utenti e gruppi, firewall, ruoli e funzionalità e molto altro ancora.

Figura 7: Overview del server e visualizzazione dei parametri più importanti

Figura 8: Registro eventi del server, con possibilità di effettuare filtri

Figura 9: Gestione dei ruoli e delle funzionalità del server, con la possibilità di aggiungerli e rimuoverli

Figura 10: Informazioni relative alle macchine virtuali ospitate sul server da gestire (nel caso sia installato Hyper-V)

È possibile anche visualizzare dei video di presentazione del tool collegandosi al link https://blogs.technet.microsoft.com/windowsserver/2017/09/22/project-honolulu-technical-preview-is-now-available-for-download/

Conclusioni

Come avete potuto constatare il software è molto leggero e permette di evitare di dover aprire tante console per poter gestire le funzionalità di un server, aggiungendo il vantaggio di poter utilizzare un browser per le connessioni alle diverse macchine. Davvero una rivoluzione nella gestione di Windows Server.

P.S: non dimenticatevi di seguire anche il blog ufficiale per essere sempre aggiornati sul tool. L’indirizzo è https://blogs.technet.microsoft.com/servermanagement/

AGGIORNAMENTO del 3 Ottobre: Sono state rese disponibili le registrazioni di due sessioni dedicate a Server Management che si sono tenute alla conferenza Ignite 2017:

• Discover what’s new with Windows Server management experiences
  Manage and monitor your Windows Server 2016 hyper-converged infrastructure

Tra qualche giorno, il 17 Ottobre 2017,  verrà rilasciato al pubblico Windows Server, versione  1709, la nuova versione del sistema operativo server di Microsoft.
Durante la conferenza Ignite 2017 sono state mostrate alcune novità interessanti e soprattutto è stata resa nota la modalità con cui verranno rilasciate d’ora in poi le nuove versioni di Windows Server.

Windows Server, versione  1709 avrà diverse novità in ambito Container e Windows Subsystem for Linux, oltre alla possibilità di migliorare Hyper-V grazie al supporto per le nuove Storage Class Memory. Una curiosità: Windows Server, versione  1709 sarà disponibile solo in modalità Core (Standard e Datacenter) ed in versione Nano Server.

Windows Server Cadence

Poiché alcune realtà lavorative si evolvono rapidamente, una versione più veloce di Windows Server, con rilascio di nuove funzionalità, potrebbe essere un approccio decisamente adeguato per mantenere il passo coi tempi. Per questo motivo ci saranno due Channel in Windows Server:

1. Semi-Annual Channel. La versione verrà rilasciata in primavera e in autunno e sarà disponibile per i clienti che sottoscrivono la Software Assurance oppure per i clienti di Microsoft Azure. Ogni release sarà supportata per 18 mesi e avrà nel nome l’indicazione anno/mese (ad es. 1709)
2. Long-Term Servicing Channel. Versione disponibile per tutti coloro che non vogliono aggiornare ogni 6-12 mesi. Il programma di supporto sarà di 5 anni + altri 5 anni di Extended Support. La release avrà il nome Windows Server + anno di rilascio

Ovviamente, per chi potrà, sarà possibile utilizzare entrambe le versioni, decidendo in base alle applicazioni e ai servizi da far girare.

Figura 1: Channel di rilascio delle versioni di Windows Server 2016

Figura 2: Funzionamento del Semi-Annual Channel e del Long Term Servicing Channel in Windows Server 2016

Nano Server

Nella versione 1709 Nano Server sarà ottimizzato per l’utilizzo con i Containers. La dimensione di questa versione di Windows Server è ormai di fatto di pochissimi mega e la rende ideale per creare applicazioni web all’interno di container sia Windows che Linux, grazie alla collaborazione con Docker.

Nano Server aveva anche evidenziato problemi come server di virtualizzazione, in quanto risultava difficile l’installazione, la gestione, il patching e l’installazione dei driver per l’hardware ottimizzato. Si è deciso per questo motivo di specializzarlo per workload più adeguati.

Figura 3: Scelta della corretta modalità di installazione di Windows in base al workload

Figura 4: Le dimensioni di Windows Server 1709 Nano Server sono state notevolmente ridotte

Hybrid Application Platform

Ai container verrà aggiunta la possibilità di utilizzare il protocollo SMB 3.0, rendendo di fatto possibile salvare i dati in una semplice cartella condivisa. In più ai container sarà aggiunto il support a .NET Core 2.0

I Linux Container, grazie alla Hyper-V Isolation, permetteranno di realizzare piattaforme in cui far girare qualsiasi tipo di container (Windows e Linux) in maniera sicura. Infatti ogni container farà girare dei Kernel Linux reali all’interno della Hyper-V Child Partition. Questo permetterà anche di utilizzare Windows Subsystem for Linux (WSL) in Windows Server 2016.

Figura 5: Novità della Hybrid Application Platform in Windows Server 2016 1709

Project Honolulu

Ho già parlato nell’articolo Project ‘Honolulu’: la rivoluzione della gestione di Windows Server della nuova interfaccia di management di Windows Server completamente realizzata in HTML5. Il progetto mi è davvero piaciuto e soprattutto sarà gratuito. Il software è molto leggero e permette di evitare di dover aprire tante console per poter gestire le funzionalità di un server, aggiungendo il vantaggio di poter utilizzare un browser per le connessioni alle diverse macchine. Davvero una rivoluzione nella gestione di Windows Server. In più è stato anche annunciato che verrà inserita la possibilità di effettuare il Backup su Azure!

Figura 6: Project Honolulu, la nuova frontiera nella gestione di Windows

Software Defined Datacenter

Windows Server 2016 utilizza le stesse funzionalità disponibili in Microsoft Azure. Il Cloud OS, come è stato chiamato, supporta i più grandi server fisici (24 TB di RAM e 512 logical processors) e le più grandi macchine virtuali (12 TB di RAM e 240 virtual processors) attualmente disponibili e ci mette a disposizione la stessa scalabilità del Cloud pubblico. Il termine Software Defined Datacenter indica l’insieme delle tecnologie che permettono alle infrastrutture di essere virtualizzate. Grazie anche alla gestione offerta dalla suite System Center 2016, Windows Server 2016 utilizza tecnologie per virtualizzare l’hardware, lo storage, la rete, i sistemi operativi e le applicazioni, facendo in modo che vengano separate dall’hardware fisico e dall’associazione 1:1 con i server come succedeva in passato. Per maggiori informazioni su SDDC potete visitare la pagina https://docs.microsoft.com/en-us/windows-server/sddc

Figura 7: Tecnologie usate da Windows Server per gestire un Software Defined Datacenter (SDDC)

Conclusioni

Lo scopo di questo articolo è quello di darvi un’idea delle funzionalità che verranno rilasciate nel prossimo Windows Server, versione  1709 e dopo il rilascio seguiranno altri articoli in cui approfondiremo ogni singola novità. Nel frattempo, potete dare anche un’occhiata ai video delle sessioni di Ignite 2017:

1. Windows Server: What’s New and What’s Next
   
2. Windows Server Fall Release: Technical Foundation
   
3. Windows Server Feature Release: How to Maximize Developer Efficiency Today and Tomorrow
   
4. Discover What’s New with Windows Server Management Experiences
   
5. Everything you need to know about the new Windows Server release cadence
   

Dopo circa 1 anno, grazie al grande interesse manifestato durante l’evento del 21 settembre 2016, Accademia del Levante, in collaborazione con la Community ICT Power, ospiterà il prossimo 31 ottobre 2017, a partire dalle ore 15:00, un seminario completamente gratuito che illustrerà le principali novità e funzionalità di Windows 10 Fall Creators Update e Windows Server 2016, affrontando anche un tema importante come la gestione dei certificati. Inoltre, andremo ad esplorare la continua evoluzione del servizio cloud Microsoft Azure per fare sempre più attività ottimizzando al meglio le risorse da utilizzare.

Con questi eventi si conferma l’importanza dei nuovi sistemi operativi di Microsoft visti come delle piattaforme integrate e molto più “aperte” rispetto al passato. Una giornata particolare e interessante aperta a tutti coloro che hanno sete di conoscenza.

Per tutti i presenti all’evento ci sarà, come sempre, la possibilità di ricevere un attestato di partecipazione e dei simpatici gadget a sorpresa.

Agenda

Per le iscrizioni potete visitare la pagina http://www.accademiadellevante.org/news/683-seminario-gratuito-microsoft-prowercon2017.html 

In questo articolo vedremo come creare delle macchine virtuali in Microsoft Azure da utilizzare come Hosts per i container Docker.

Esistono diversi modi per poterlo fare, ma certamente avere un automatismo che mi crei la macchina virtuale e mi installi Docker semplifica di molto il lavoro.

Il comando che permette di creare automaticamente la macchina virtuale da usare come host è docker-machine. Potrete trovare un esauriente articolo alla pagina https://docs.docker.com/machine/, che vi darà un’idea dei comandi da utilizzare.

Il comando docker-machine create creerà per voi l’host per i container, in base ai driver che gli indicherete. I driver https://docs.docker.com/machine/drivers/ rappresentano le piattaforme che possono ospitare il nostro host. Attualmente sono disponibili i seguenti driver:

• Amazon Web Services
  
• Microsoft Azure
  
• Digital Ocean
  
• Exoscale
  
• Google Compute Engine
  
• Generic
  
• Microsoft Hyper-V
  
• OpenStack
  
• Rackspace
  
• IBM Softlayer
  
• Oracle VirtualBox
  
• VMware vCloud Air
  
• VMware Fusion
  
• VMware vSphere
  
• VMware Workstation (unofficial plugin, not supported by Docker)
  
• Grid 5000 (unofficial plugin, not supported by Docker)
  

Creazione tramite Azure Cloud Shell

Il modo più veloce per creare un host container su Azure è l’utilizzo della Azure Cloud Shell. Azure Cloud Shell è una shell interattiva accessibile dal browser che permette di gestire le risorse di Azure. Gli utenti Linux possono scegliere di utilizzare Bash, mentre gli utenti Windows possono scegliere di utilizzare PowerShell. È possibile lanciare la Azure Cloud Shell direttamente dal portale di Azure, come mostrato in figura:

Figura 1: Lancio della Azure Cloud Shell dal portale

Quando lanciate la Azure Cloud Shell dal portale di Microsoft Azure per la prima volta, vi verrà chiesto di creare un gruppo di risorse, un account di archiviazione e una condivisione file (Azure file share). Scegliete di utilizzare Bash (Linux).

Figura 2: Primo lancio della Azure Cloud Shell con la richiesta di creazione dello storage

Dopo aver creato un account di archiviazione con ridondanza locale (LRS), a cui vengono applicati i normali costi di uno storage account, e aver creato una Azure file share, questa verrà utilizzata sia per gli ambienti Bash che PowerShell.

Figura 3: Creazione di Azure Cloud Shell completata

Nella Azure Cloud Shell sono preinstallati i più diffusi strumenti da riga di comando. Quindi non abbiamo bisogno di installare nulla e per lanciare la creazione di una nuova macchina virtuale host ci basterà utilizzare il comando:

docker-machine create -d azure –azure-subscription-id “id_della_vostra_sottoscrizione” –azure-ssh-user ictpower –azure-open-port 80 –azure-size “Standard_D2_v2” dockervm00

Dopo aver lanciato il comando verrà creata una VM chiamata dockervm00 che utilizzerà come sistema operativo Ubuntu 16.04 LTS, in cui verrà installato Docker. Tramite il comando abbiamo anche indicato di rendere disponibile la porta 80 (che verrà aperta nel Network Security Group) e abbiamo scelto di usare per l’autenticazione tramite SSH un utente chiamato ictpower.

Al momento del lancio del comando vi verrà chiesto di autenticarvi, collegandovi al link https://aka.ms/devicelogin ed inserendo il codice monouso visualizzato nella console.

Figura 4: Inserimento del codice monouso nella pagina di autenticazione https://aka.ms/devicelogin

Figura 5: Autenticazione con il proprio account al tenant Azure

Figura 6: Dopo aver completato l’accesso viene richiesta l’autorizzazione al login da parte di Docker Machine for Azure

Figura 7: Autenticazione e Autorizzazione completata

Dopo aver completato la procedura di login ed aver autorizzato Docker Machine for Azure, la creazione della macchina virtuale (resource group, storage account, vnet, public ip, ecc.) procede in autonomia, come mostrato in figura:

Figura 8: Creazione della VM host per i container

Dopo pochi minuti la macchina sarà pronta e sarà possibile cominciare ad utilizzare i container con Docker.

Creazione tramite l’applicazione Docker for Windows

Una maniera alternativa che è possibile utilizzare per la creazione dell’host che ospiterà i nostri container è l’utilizzo dell’applicazione Docker for Windows, che possiamo installare in una macchina locale (io ho usato una macchina con Windows 10), da cui poi lanceremo i comandi per la creazione della VM host su Azure. L’applicazione Docker for Windows, scaricabile dal link https://docs.docker.com/docker-for-windows/install/, è un pacchetto che contiene tutto il necessario per eseguire Docker su un sistema operativo Windows, compresi i tool di gestione a riga di comando.

Figura 9: Installazione dell’applicazione Docker for Windows

Figura 10: Installazione di Docker for Windows completata

Io ho installato l’applicazione su una macchina Windows 10, su cui non ho installato Hyper-V. Lanciando l’applicazione ho ricevuto un messaggio di errore che mi invita ad abilitare il ruolo di Hyper-V, come mostrato in figura. Per l’obiettivo che vogliamo raggiungere non è un’operazione necessaria, in quanto al momento mi interessano solo i tool di gestione a riga di comando.

Figura 11: Messaggio di avviso dell’applicazione Docker for Windows che segnala l’assenza di Hyper-V

Da un Command Prompt con privilegi elevati lanciate lo stesso comando che vi ho mostrato prima e che provvederà a creare la VM chiamata dockervm00

docker-machine create -d azure –azure-subscription-id “id_della_vostra_sottoscrizione” –azure-ssh-user ictpower –azure-open-port 80 –azure-size “Standard_D2_v2” –azure-location westeurope dockervm00

Figura 12: Lancio del comando Docker-machine create

Al momento del lancio del comando vi verrà chiesto di autenticarvi, collegandovi al link https://aka.ms/devicelogin ed inserendo il codice monouso visualizzato nella console.

Figura 13: Login dell’applicazione Docker Machine for Windows con un codice monouso

Figura 14: Autenticazione al tenant di Azure

Figura 15: Autenticazione dell’applicazione Docker for Windows completata

Dopo l’autenticazione viene creata la macchina virtuale con Ubuntu 16.04 LTS e viene installato automaticamente il Docker Engine, che utilizzeremo per far girare i nostri container, come mostrato in figura:

Figura 16: Creazione della VM host completata

Lanciando il comando docker-machine ls ci verrà mostrata la VM che è stata creata, l’indirizzo IP che è stato assegnato alla VM e lo stato della VM, come mostrato in figura:

Figura 17: Informazioni sullo stato della VM host creata su Azure

Durante il processo di provisioning della macchina virtuale, Docker Machine crea un certificato self-signed che verrà utilizzatoper creare una sessione SSH sicura verso il Docker host. La chiave privata del certificato verrà conservata nel profilo dell’utente. Questo permette di creare e gestire i Docker container dallo stesso computer da cui avete effettuato il Docker Host deployment. Per semplificare la gestione dell’Host e per creare i container è sufficiente configurare le variabili d’ambiente aprendo una console di PowerShell con privilegi elevati e lanciando il comando

docker-machine env dockervm00 | Invoke-Expression

Adesso che abbiamo configurato l’host, possiamo provare ad eseguire un webserver (nel nostro caso nginx) per testare il suo corretto funzionamento. Eseguiamo quindi un container che usa un’immagine con il webserver nginx, che sia in ascolto sulla porta 80 e che se l’host si riavvia riparta in automatico (–restart=always), lanciando il comando:

docker run -d -p 80:80 –restart=always nginx

Figura 18: Esecuzione del container di test con il webserver nginx

Per collegarci al container appena creato possiamo procurarci il suo indirizzo IP anche con il comando
docker-machine ip dockervm00
e da un browser verificare se il webserver è funzionante e raggiungibile.

Figura 19: Verifica dell’esecuzione del container

Conclusioni

Indipendentemente dal metodo utilizzato, sia con la Azure Cloud Shell che con i tool dell’applicazione Docker for Windows, la creazione di un host su Azure per ospitare i nostri container è un’operazione molto semplice che ci dà un’idea dell’enorme flessibilità offerta sia dal Cloud che dalla tecnologia alla base dei container stessi.

Come abbiamo avuto modo di vedere nel Video Tech Heroes di Nicola Ferrini e Paola Presutto, Microsoft ha abbandonato il supporto delle versioni “legacy” di IE mantenendolo esclusivamente per la versione 11.

Nella estrema varietà di siti che ci si trova ad utilizzare, soprattutto in ambito aziendale, non è raro incontrare applicazioni web che richiedono la compatibilità con versioni precedenti di Internet Explorer.

Già dalla versione 10 del browser era attivabile la gestione della “Visualizzazione Compatibilità“

Figura 1

Questa impostazione tuttavia non consentiva (e non consente nemmeno in IE 11) un’impostazione puntuale su un singolo host, infatti definendo www.ictpower.it come host da visualizzare in modalità compatibile, l’elenco viene popolato con l’intero dominio ictpower.it.

Se ci si trova ad operare in ambienti intranet esiste una sola impostazione disponibile ed anche qui non è possibile gestire il singolo host in visualizzazione compatibilità

Alcune soluzioni che abbiamo avuto modo di analizzare hanno visto implementare un dominio differente nel quale riferire i singoli host per cui è richiesta la modalità compatibile. Questa soluzione è difficilmente gestibile e richiede comunque un certo impatto sulla struttura DNS interna.

La configurazione di Internet Explorer 11 prevede una modalità operativa denominata Enterprise Mode, per mezzo della quale è possibile ovviare alla limitazione vista in precedenza, potendo così definire un preciso host in visualizzazione compatibile.

In modo ancor più granulare è possibile definire se un determinato sito deve essere utilizzato in modalità IE7 oppure IE8.

L’attivazione della Modalità Enterprise può avvenire tramite Group Policy o chiavi di registro, e la definizione dei siti e della relativa modalità di navigazione è impostata all’interno di un file XML.

La compilazione di questo file è possibile tramite un apposito tool di gestione, di cui vedremo le peculiarità più avanti.

Attivazione di Enterprise Mode tramite Group Policy

Per mezzo di una GPO è possibile centralmente gestire la modalità operativa del Browser, la Policy oltre che attivare questa impostazione istruisce il “client” su dove reperire il file XML di impostazione. Il percorso in questo caso deve essere un URL navigabile ed accessibile dal client e deve essere dichiarato nella forma

http://<FQDN>/<Nome_File>.xml

In generale, IE11, quando lavora in “Enterprise Mode”, dopo 65 secondi circa dall’avvio, ricerca il file secondo le impostazioni previste nella GPO, una volta individuato e scaricato in locale, questo non viene più controllato fino al prossimo riavvio del browser.

Il file XML, riporta all’interno un numero di versione, all’avvio, IE verifica che il file salvato localmente sia allineato con la versione presente nel repository centrale, nel caso in cui il file locale sia meno recente procede allo scaricamento della versione aggiornata.

La Group Policy può essere definita nelle impostazioni Utente o Computer in:

Modelli Amministrativi\Componenti di Windows\Internet Explorer\Usa Elenco Siti Web di Internet Explorer modalità Enterprise

Chiaramente la definizione della policy nel ramo Computer farà ereditare l’impostazione a tutti gli utenti

Figura 2

Nella configurazione riportata sopra è indicato L’URL completo del file XML definito per le impostazioni del Browser

Attivazione di Enterprise Mode tramite Registro di Sistema

Come accennato in precedenza Internet Explorer può essere attivato per la modalità Enterprise anche tramite chiavi di registro, questa impostazione consente una maggior flessibilità di gestione permettendo di definire tre modalità di reperimento del file XML, che sono:

• Percorso HTTP(S): “SiteList”=”http://intranet.ictpower.it/SiteList.xml”
  
• Rete locale: “SiteList”=”\\UNC_PATH\share\ SiteList.xml”
  
• File locale: “SiteList”=file:///c:\\Users\\<user>\\documenti\\ SiteList.xml
  

Analogamente alla configurazione tramite Group Policy è possibile impostare il browser “per Machine” o “per User”, sarà sufficiente modificare la chiave nel ramo HKLM (HKEY_LOCAL_MACHINE) piuttosto che HKCU (HKEY_CURRENT_USER) per il resto il percorso sarà invariato.

A questo punto navigando un sito per cui è previsto l’uso in modalità Enterprise il browser presenterà anche una visualizzazione particolare, che sta ad indicare l’attivazione di questa modalità.

Figura 3

Le configurazioni viste ora definiscono in modo centralizzato quali siti devono essere navigati in modalità Enterprise, e gli utenti non hanno modo di agire ulteriormente. È possibile attivare una chiave di registro che di fatto “sblocca” l’accesso a questa modalità e quindi gli utilizzatori possono attivarla in autonomia sui vari siti utilizzati.

Modelli Amministrativi\Componenti di Windows\Internet Explorer\Consenti agli utenti di attivare e utilizzare a modalità Enterprise dal menu strumenti

Figura 4

Quando si attiva questa impostazione, è possibile specificare un URL che punta ad un server WEB che ha la funzione di archiviare i messaggi che vengono inviati quando un utente attiva o disattiva la modalità Enterprise dal menu strumenti.

Figura 5

Per dettagli ulteriori sulla configurazione del Server Web e per la consultazione del file di log è possibile consultare questo link.

Creazione del file XML per la gestione della Modalità Enterprise di Internet Explorer 11

Le configurazioni che abbiamo analizzato, si avvalgono, come già detto di un file formato XML che riporta le impostazioni relative ai vari siti, la creazione e gestione di questo file è facilitata da un apposito tool “Enterprise Mode Site List Manager“.

Ad oggi sono disponibili due versioni dello strumento a seconda della versione del sistema operativo e dello schema di XML a questo associato.

Al fine di scegliere correttamente la versione adatta si consiglia di seguire questo link, per brevità si riporta qui sotto la tabella riassuntiva delle versioni e relative compatibilità.

Figura 6

Dalla pagina di download dello strumento e relativamente alla versione V.2 viene riportato il seguente avviso

This tool lets IT Professionals create and update the Enterprise Mode Site List in the version 2.0 (v.2) XML schema. The Enterprise Mode schema has been updated to v.2 to be easier to read and to provide a better foundation for future capabilities. The v.2 schema is supported on Windows 7, Windows 8.1, and Windows 10. The v.1 XML schema will also continue to be supported on Windows 7, Windows 8.1, and Windows 10.

Il tool permette, tramite il tasto ADD, di inserire, uno per ogni riga, I vari URL che dovranno essere navigati in modalità compatibile, in alto è riportata la versione della configurazione utilizzato dal sistema per la comparazione tra il file locale e quello disponibile centralmente.

Caratteristica particolarmente utile è la possibilità di definire soltanto determinati Path di un sito, inserendo il percorso all’interno del campo URL, in questo modo è possibile gestire in modo estremamente preciso le singole aree che richiedono emulazioni differenti rispetto all’intero sito web.

Figura 7 ( definizione di siti visualizzati in modalità compatibile IE7)

Figura 8 (visualizzazione della sola area /articoli/ in modalità compatibile IE7)

Riferimenti:

https://docs.microsoft.com/it-it/internet-explorer/ie11-deploy-guide/turn-on-enterprise-mode-and-use-a-site-list

https://docs.microsoft.com/en-us/internet-explorer/ie11-deploy-guide/check-for-new-enterprise-mode-site-list-xml-file

https://technet.microsoft.com/library/dn640701.aspx

https://technet.microsoft.com/it-it/library/dn781326.aspx

Con il rilascio dell’ultima versione del sistema operativo server, chiamata Windows Server 1709 e delle cui novità ne ho parlato nella’articolo https://www.ictpower.it/sistemi-operativi/windows-server-2016-1709-quali-saranno-le-novita.htm, Microsoft e Docker ci offrono la possibilità di far girare i container Linux in un Windows Container Host.

Tra i prerequisiti richiesti per far girare i container Linux ci sono l’installazione di Docker Enterprise Edition e di LinuxKit.

In questa guida vi mostrerò come far girare i Linux Containers all’interno di una macchina virtuale. Per poterlo fare sarà necessario abilitare la Nested virtualization nella VM, in quanto i container Linux possono essere solo Hyper-V Containers. Per avere maggiori informazioni sulla Nested Virtualization vi rimando all’articolo https://www.ictpower.it/guide/abilitare-la-nested-virtualization-con-le-nuove-azure-vm-dv3-ed-ev3.htm

Dopo aver creato la macchina virtuale, che ho chiamato 1709 – Linux Containers, sarà necessario configurarla con la memoria RAM statica ed abilitare la nested virtualization con il comando PowerShell (eseguito con privilegi elevati)

Set-VMProcessor -VMName “1709 – Linux Containers” -ExposeVirtualizationExtensions $true

Configurate la scheda di rete della VM in modo tale che sia abilitato il Mac Address spoofing con il comando PowerShell

Get-VMNetworkAdapter -VMName “1709 – Linux Containers” | Set-VMNetworkAdapter -MacAddressSpoofing On

Procedete quindi all’installazione di Windows Server 1709 e terminata l’installazione, utilizzando il tool sconfig, affettuate tutti gli aggiornamenti, come mostrato in figura:

Figura 1: Installazione di Windows Server versione 1709 completata

Figura 2: Installazione degli aggiornamenti

Al termine degli aggiornamenti la versione di Windows sarà la 10.0.16299.19

Installazione di Docker Enterprise Edition

Per installare Docker Enterprise Edition è necessario lanciare un prompt PowerShell con privilegi elevati ed eseguire i comandi:

Install-Module DockerProvider -Force

Install-Package Docker -ProviderName DockerProvider -Force

Figura 3: Installazione di Docker Enterprise for Windows completata

Terminata l’installazione procedete ad un riavvio della macchina virtuale.

Dopo il riavvio potete verificare che il servizio Docker stia girando usando il comando PowerShell Get-Service docker e potete verificare la versione utilizzando il comando Docker version, come mostrato in figura:

Figura 4: Verifica della versione di Docker e dello stato del servizio

Adesso che i prerequisiti sono stati installati possiamo procedere all’installazione di Docker for Linux e del LinuxKit.

Installazione di Docker for Linux e del LinuxKit

Utilizzando un prompt PowerShell eseguito con privilegi elevati installiamo LinuxKit con i seguenti comandi:

$progressPreference = ‘silentlyContinue’

mkdir “$Env:ProgramFiles\Linux Containers”

Invoke-WebRequest -UseBasicParsing -OutFile linuxkit.zip https://github.com/friism/linuxkit/releases/download/preview-1/linuxkit.zip

Expand-Archive linuxkit.zip -DestinationPath “$Env:ProgramFiles\Linux Containers\.”

rm linuxkit.zip

Figura 5: Installazione del LinuxKit

A questo punto scaricate la build di Docker deamon che contiene una versione di Preview che supporta i Linux Container in Windows utilizzando la cmdlet di PowerShell

Invoke-WebRequest -UseBasicParsing -OutFile dockerd.exe https://master.dockerproject.org/windows/x86_64/dockerd.exe

Successivamente avviate un demone Docker che sia in ascolto su una pipe separata utilizzando il comando PowerShell

$Env:LCOW_SUPPORTED=1

$env:LCOW_API_PLATFORM_IF_OMITTED=“linux”

.\dockerd.exe -D –experimental -H “npipe:////./pipe//docker_lcow” –data-root c:\lcow

Figura 6: Avvio del demone Docker per l’esecuzione dei container Linux

Lasciate la finestra che ha avviato il demone in esecuzione (NON CHIUDETELA) e provate ad eseguire un Linux Container aprendo un’altra finestra con il Command Prompt e eseguendo il comando:

docker -H “npipe:////./pipe//docker_lcow” run -ti busybox sh

Figura 7: esecuzione del comando per il lancio del Linux Container

Se l’immagine non è presente nel vostro host Windows verrà scaricata, estratta ed eseguita. È possibile scaricare l’immagine anche utilizzando il comando docker -H “npipe:////./pipe//docker_lcow” pull busybox

Conclusioni

Attualmente l’esecuzione di Linux Container in un Windows Server host richiede un po’ di lavoro per la configurazione e non è supportata in produzione. Sicuramente è un ulteriore passo in avanti per poter permettere agli sviluppatori di poter creare e testare applicazioni Windows/Linux facendo girare container per entrambe le piattaforme side-by-side sullo stesso sistema operativo.

Non è la prima volta che ci troviamo a parlare di Linux su Windows, e questa volta iniziamo a fare davvero sul serio perché parliamo di Linux su Windows Server.

Proprio così! A partire dalla build 16215 di Windows Server è possibile installare come app alcune distribuzioni di Linux, che possono girare sulla nostra macchina fisica o virtuale grazie al componente Windows Subsystem for Linux che i lettori abituali del sito della nostra community conoscono già bene. Per tutti gli altri riporto l’articolo in cui annunciavamo il rilascio del componente e la guida per l’installazione https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm

Sul nostro nuovo Windows Server, conosciuto fino a poco fa come Windows Server RS3 (RedStone 3), ma il cui nome ufficiale è Windows Server, versione 1709, l’interfaccia grafica è stata completamente rimossa e quindi l’installazione di WSL è ben diversa da quella che conosciamo per Windows 10. Aggiungere ed utilizzare questa funzionalità ad ogni modo è estremamente semplice; vediamo in pochi passi come fare:

Il primo step è sicuramente quello di installare una macchina, fisica o virtuale, con una release di Windows Server >16215. Potete scaricare Windows Server, versione 1709 dal portale Volume Licensing Service Center (VLSC) oppure potete utilizzare una macchina virtuale creata su Microsoft Azure, disponibile da pochissimi giorni nel Marketplace. Nel nostro caso, essendo iscritti al programma Microsoft Insider, abbiamo scaricato ed installato l’ultima build disponibile. Windows Server, versione 1709 è disponibile nelle versioni Standard e Datacenter, ma sono nella modalità di installazione Core, come visibile in figura:

Avviamo PowerShell con privilegi amministrativi ed eseguiamo il comando

systeminfo | Select-String “^OS Version”

per verificare la build installata

La build installata è la 16299, quindi è possibile attivare la funzionalità di Windows Subsystem for Linux.

Per verificare che la funzionalità sia disponibile possiamo eseguire da PowerShell il comando

Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Abilitiamo quindi la feature con il comando PowerShell

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Dopo il riavvio abbiamo la funzionalità WSL attiva.

Possiamo a questo punto scaricare la nostra distribuzione preferita scegliendo tra i link seguenti:

• Ubuntu – https://aka.ms/wsl-ubuntu-1604
• OpenSUSE – https://aka.ms/wsl-opensuse-42
• SLES – https://aka.ms/wsl-sles-12

Per questo esempio scaricheremo il pacchetto relativo alla distribuzione Ubuntu, salvandolo con il nome Ubuntu.zip nella nostra home directory con il commando

Invoke-WebRequest -Uri https://aka.ms/wsl-ubuntu-1604 -OutFile ~/Ubuntu.zip -UseBasicParsing

Il pacchetto occupa circa 200MB. Estraiamo l’archivio con

Expand-Archive ~/Ubuntu.zip ~/Ubuntu

Ritroveremo così nella nostra home la cartella Ubuntu contenente l’app da installare

L’installazione è estremamente semplice e viene avviata lanciando l’eseguibile relativo alla distribuzione. Nel nostro caso

Ubuntu.exe

Un wizard ci chiederà di impostare un nome utente ed una password per l’ambiente Linux. Le credenziali saranno completamente indipendenti da quelle di Windows e l’utente sarà membro del gruppo sudoers quindi potrà utilizzare il comando sudo per eseguire l’installazione di eventuali pacchetti aggiuntivi.

Al termine dell’installazione ci troveremo già all’interno della shell linux. Per tornare a PowerShell digitiamo

exit

in qualsiasi momento possiamo utilizzare la nostra distribuzione Ubuntu aprendo la shell Linux con:

bash

Siamo quindi in grado di eseguire comandi e software Linux direttamente sulla nostra macchina Windows Server, versione 1709 e per concludere questa guida eseguiamo

cat /etc/lsb-release

Che ci mostrerà le informazioni sulla distribuzione in uso, confermando che siamo su una Ubuntu 16.04 Long Term Support

Conclusioni

La presenza di Windows Subsystem for Linux anche su Windows Server apre degli scenari di utilizzo molto interessanti, che finora avevamo visto solo nella versione client Windows 10.

Moltissime sono le novità introdotte in Windows 10 Fall Creators Update che abbiamo avuto già modo di elencare nell’articolo Windows 10 Fall Creators Update, ci siamo!. Oggi mi voglio soffermare sulle novità relative ad Hyper-V. Nonostante Hyper-V sia stato introdotto nelle versioni Pro ed Enterprise fin dalla versione Windows 8 a 64 bit (il nome ufficiale è Client Hyper-V), sembra che sia ancora sconosciuto a diversi utenti e voglio approfittare di questo articolo per un piccolo refresh.

Per tutti coloro che si cimentano per la prima volta con Client Hyper-V consiglio di leggere l’articolo Introduzione a Hyper-V in Windows 10; in questo articolo mostrerò solo quelle che sono le novità introdotte nella versione Fall Creators Update di Windows 10 (versione 1709).

Installazione di Client Hyper-V

L’installazione di Client Hyper-V viene effettuata semplicemente cercando in Start la parola Hyper-V ed aprendo la console relativa all’installazione delle funzionalità aggiuntive di Windows. Dopo aver scelto la voce Hyper-V procedete cliccando su OK e riavviate il PC. Dopo un paio di riavvii l’hypervisor sarà stato installato e potrete procedere alla gestione utilizzando l’Hyper-V Manager.

Figura 1: Installazione della funzionalità aggiuntiva di Hyper-V in Windows 10

Figura 2:Installazione completata e riavvio del client Windows 10

La console di Management di Client Hyper-V è una classica MMC 3.0 in tutto e per tutto uguale a quella presente su Windows Server. Infatti la console può essere utilizzata per gestire Server Hyper-V remoti.

Figura 3: Hyper-V Manager – Console di gestione di Hyper-V

Default Switch

Come potrete vedere visitando le configurazioni relative al Virtual Switch Manager, in questa versione di Windows 10 è stato creato automaticamente uno switch chiamato Default Switch che permette alle macchine virtuali di condividere la connessione dell’host attraverso una NAT (Network Address Translation). Non importa quindi se siete collegati con un cavo o se siete in Wi-Fi: avrete subito la possibilità di far ricevere alle vostre macchine le configurazioni di rete (DHCP e DNS) e di farle navigare. Fantastico!

Il default switch una volta creato non può essere rinominato o rimosso. Infatti tutte le impostazioni sono in grigio (non modificabili), come mostrato in figura:

Figura 4: proprietà del Default Switch

Ovviamente nessuno vi vieta di creare nuovi switch (Interni, Privati oppure Esterni) e di configurarli come meglio credete, collegandoli alla rete cablata oppure alla rete Wi-Fi.

Figura 5: External Switch collegato alla rete cablata

Quick Create virtual machine gallery

Già nella Build Insider 15002 rilasciata a Gennaio 2016 e poi in via definitiva nella versione Windows 10 Creators Update era stata introdotta In Client Hyper-V la possibilità di creare velocemente macchine virtuali utilizzando il pulsante Quick Create. Se volete approfondire vi rimando all’articolo Creare una macchina virtuale con Hyper-V e all’articolo Hyper-V virtual machine gallery and networking improvements.

Figura 6: Quick Create VM presente nella versione Windows 10 Creators Update (1703)

Nella versione Windows 10 Fall Creators Update (1709) il wizard è stato migliorato e vi permette di creare macchina virtuali partendo da una galleria di immagini già pronte (un’immagine chiamata Windows 10 dev environment è già disponibile di default). Cliccando sul pulsante Quick Create si aprirà una finestra da cui potrete scegliere quale immagine installare. Io ho scelto quella di default ed è iniziato un download da 12,73 GB, come mostrato in figura:

Figura 7: Creazione di una nuova macchina virtuale partendo da un’immagine presente nella Gallery

Figura 8: Download dell’immagine dalla gallery Microsoft

Al termine del download avviate la macchina virtuale e procedete alle successive configurazioni.

Figura 9:Installazione della VM completata

Ovviamente potete creare anche macchine virtuali utilizzando una vostra ISO oppure utilizzando un file vhd o vhdx esistente scegliendo Local Installation Source, come mostrato in figura:

Figura 10: Installazione partendo da una ISO o da un virtual disk esistente

Figura 11: Creazione della VM completata, con la possibilità di modificarne i parametri prima dell’avvio

Se volete aggiungere la vostra immagine personalizzata alla galleria di Windows 10, per poterla poi successivamente riutilizzare, potete seguire i passaggi descritti nell’articolo Create your custom Quick Create VM gallery

Virtual Machine sharing

Un’altra novità interessante introdotta in Client Hyper-V è la possibilità di esportare la macchina virtuale (anche da accesa) in modo tale da poterla condividere con altri PC. La funzione di Share permette di creare un file .vmcz all’interno del quale ci sono i file di configurazione e i dischi della macchina virtuale, che vengono anche compressi. Dopo aver spostato il file su un altro host con almeno Windows 10 Fall Creators Update e Client Hyper-V installato, semplicemente cliccando due volte sul file, la macchina viene direttamente importata e sarà utilizzabile. Più semplice di così???

Nota: questa funzione non permette di esportare nessun Checkpoint. Se volete esportare eventuali checkpoint che avete creato, dovrete utilizzare la funzione Export dall’Hyper-V Manager, cliccando col tasto destro sulla VM da esportare.

Figura 12: Esportazione e compressione della VM in formato .VMCZ tramite la funzionalità di Sharing

Figura 13: importazione della VM direttamente dal file .VMCZ

Nota: Se doveste ricevere un messaggio di errore che dice che non siete autorizzati ad importare la macchina, assicuratevi che l’utente con cui siete loggati sia parte del gruppo Hyper-V Administrators

Automatic Checkpoint

Dalla versione di Windows 10 Fall Creators Update, Client Hyper-V crea automaticamente un Checkpoint quando la macchina virtuale viene avviata (solo se non ci sono altri Checkpoint esistenti). Questa funzionalità è abilitata di default ma può essere facilmente modificata dalle proprietà della VM oppure eseguendo il comando PowerShell Set-VM –Name NomeDellaVM –AutomaticCheckpointsEnabled . Quando la VM viene spenta il Checkpoint viene rimosso e viene effettuato il Merge dei dischi.

Figura 14: Automatic Checkpoint creato all’avvio della VM

Figura 15: funzionalità di Automatic Checkpoint abilitata di default

Pass-Through della batteria

In Windows 10 Fall Creators Update la macchina virtuale è capace di vedere lo stato di carica della batteria. Questo vi permette di poter fare dei test all’interno del sistema operativo utilizzando le funzioni di risparmio energetico o le ottimizzazioni che Windows usa quando lo stato di carica della batteria è troppo basso. Oppure banalmente se state utilizzando la macchina virtuale in modalità Schermo intero potreste accorgervi che non avete più batteria J

Figura 16: Lo stato di carica della batteria è visualizzato anche all’interno della VM

Conclusioni

Davvero interessanti le novità introdotte in Client Hyper-V. Trovo davvero utili alcune delle funzionalità che vi ho elencato e la mia preferita è quella degli Automatic Checkpoint. E la vostra qual è?

L’Active Directory (AD) se non gestita e monitorata correttamente può diventare un vettore di attacco per l’infrastruttura aziendale. Di seguito elencheremo una serie di tipologie di attacco che possono sfruttare AD come vettore cercano di capire come possono essere prevenute e mitigate.

Attacchi su Active Directory volti a creare una BotNet

Questo tipo di scenari attacco sono stati analizzati da Ty Miller (Managing Director at Threat Intelligence Pty Ltd) e Paul Kalinin (Senior Security Consultant at Threat Intelligence Pty Ltd) nella sessione The Active Directory Botnet tenuta al blackhat USA 2017.

Tali attacchi si basano sul fatto che gli oggetti utente in Active Directory hanno come risaputo un gran numero di attributi che possono essere letti da tutti gli account utenti e computer del dominio, per contare il numero di attributi esposti da un account utente è possibile utilizzare il seguente comando PowerShell:

(Get-ADUser -Identity Username -Properties *).PropertyCount

Gli attributi di un oggetto utente in Active Directory possono essere di vario tipo come Stringa, Numerico, Boolean, Binario, etc. e ogni attributo può contenere dati di diversa dimensione da pochi bytes fino MBytes, di seguito una query PowerShell per vedere nome, tipo e dimensione massima degli attributi degli oggetti utente in Active Directory (a riguardo si veda il post Exploring Active Directory Data Types with PowerShell):

$schema =[DirectoryServices.ActiveDirectory.ActiveDirectorySchema]::GetCurrentSchema()

$schema.FindClass(‘user’).OptionalProperties | Select Name, RangeUpper | Sort RangeUpper -Descending

Gli attributi possono quindi essere utilizzati per l’injection dei dati da parte di una botnet al fine di utilizzarli successivamente da altri computer. Una Active Directory Botnet presenta infatti il seguente schema di funzionamento:

1. Gli host compromessi fanno injection di dati negli attributi del loro account AD ed eseguono query nel dominio per identificare i sistemi compromessi
2. Questo approccio permette al bot master e agli slave di identificare le macchine infette su cui lanciare i comandi le cui risposte saranno memorizzate negli attributi dell’account AD corrispondente all’endpoint e lette poi dall’host che aveva lanciato il comando
3. Le Botnet possono anche implementare una funzione di copertura che consente comunicazioni confidenziali tra gli host e la possibilità di utilizzare proprietà personalizzate di Active Directory per eludere tentativi di rilevamento
4. Questo tipo di attacco fornisce un potente canale di comunicazione che elude i Network Access Controls (NAC) e consente di implementare un Command & Control basato su Active Directory
5. Grazie all’utilizzo degli attributi degli oggetti AD né la Domain separation né la network segmentation possono interrompere la comunicazione
6. Dopo aver stabilità la comunicazione con la Botnet gli attributi binari vengono utilizzati per scaricare file posizioni remote tramite binary-to-text Base64 encoding
7. A questo punto le bots possono comunicare esternamente tramite shell remote che vengono utilizzate anche per eseguire l’exfiltration dei dati all’esterno dell’infrastruttura

La prevenzione di questo tipo di attacchi non può che basarsi sul monitoraggio regolare delle modifiche sugli attributi degli oggetti utenti di AD che non dovrebbero subire Variazioni in modo regolare, ovvero occorre rispettare la quinta legge delle 10 Immutable Laws of Security Administration:

Law #5: Eternal vigilance is the price of security

Nativamente come indicato in Monitoring Active Directory for Signs of Compromise è possibile eseguire l’audit delle Directory Service Changes, ma si noti che vi sono alcune limitazioni (per maggior dettagli si veda Audit Directory Service Changes):

“This subcategory reports changes to objects in AD DS. The types of changes that are reported are create, modify, move, and undelete operations that are performed on an object. Directory service change auditing, where appropriate, indicates the old and new values of the changed properties of the objects that were changed. Only objects with SACLs cause audit events to be generated, and only when they are accessed in a manner that matches their SACL entries. Some objects and properties do not cause audit events to be generated due to settings on the object class in the schema. This subcategory applies only to domain controllers.”

Per maggiori dettagli suul’Auditing di AD si veda anche AD DS Auditing Step-by-Step Guide.

In alternativa è possibile utilizzare prodotti di terze parti, come ad esempio ADAudit Plus di ManageEngine, mentre al momento Advanced Threat Analytics (ATA) non rileva attività malevole basate sulla modifica degli attributi degli oggetti AD, per i dettagli sulle attività sospette rilevate da ATA si veda: Advanced Threat Analytics suspicious activity guide.

AD Discretionary Access Control Lists (DACL) Backdoors

Questo tipo di scenari attacco sono stati analizzati da Andy Robbins (Adversary Resilience Lead at SpecterOps) e Will Schroeder (Offensive Engineer at SpecterOps) nella sessione An ACE Up the Sleeve: Designing Active Directory DACL Backdoors tenuta al blackhat USA 2017 e nel post Active Directory Access Control List – Attacks and Defense del Microsoft Advanced Threat Analytics Team.

Tali attacchi si basano sull’utilizzo del Discretionary Access Control List (DACL) per eseguire privilege escalation in un ambiente di dominio utilizzando come vettore di attacco la creazione di un path di escalation basato sulle permissions degli oggetti AD (DACLs), ma prima di affrontare alcuni potenziali scenari di attacco occorre prima analizzare i concetti su cui questi attacchi si basano.

L’Access Control è implementato assegnando Security Descriptors agli oggetti AD, un Security Descriptor è un set di informazioni collegate ad ogni oggetto e che contiene quattro componenti di sicurezza:

• Il Security identifiers (SIDs) dell’Object Creator (l’utente che ha creato l’oggetto) e del primary group dell’oggetto
• La Discretionary Access Control List (DACL) costituita da access control entries (ACE) che rappresentano i SID di utenti e gruppi a cui sono consentiti o negati i diritti di accesso all’oggetto
• La System Access Control List (SACL) costituita dagli utenti e gruppi a cui è consentito l’auding sull’oggetto
• Un set di control bits che qualificano il significato di un descrittore di protezione o dei singoli membri.

Va precisato che gli accounts built-in privilegiati (Domain Admins, Enterprise Admins, etc) sono protetti dal Security Descriptor propagation (o SDProp) che forza le ACL per impedire modifiche non autorizzate ogni 60 minuti (per default) resettando le permissions a quelle del container AdminSDHolder contenuto nel System container della Domain Partition. Il processo esegue i task in modo recursivo su tutti i membri dei gruppi e disabilita l’eredità su tutti i protected accounts.

Uno scenario di attacco basato sulla Discretionary Access Control List (DACL) è quello che
si basa sulle deleghe di permissions su oggetti AD concessi ad account non-built-in privilegiati. AD consente ad un amministratore di delegare permission a normali account di dominio (utenti, gruppi, computer) senza la necessità di aggiungere tali account a gruppi amministrativi e tra le deleghe comunemente concesse vi sono “Reset Password” (spesso concessa agli utenti helpdesk) e la “Add New Member to a group” (spesso concessa ai proprietari dei business group).

Quindi nel caso in cui venga compromesso un account a bassi privilegi, ma con la delega “Add New Member to a group” che gli permette di aggiungere un utente ad un gruppo che ha a sua volta il privilegio di “Reset Password” su un gruppo che contiene utenti ad elevati privilegi è possibile creare un path di attacco volto alla compromissione di account privilegiati.

Di seguito un schema di esempio di questo path di attacco:

Come illustrato precedentemente un ipotetico attaccante non sarà in grado di eseguire una privileges escalation sui privileged built-in accounts le cui ACL sono protette da SDProp, quindi la modifica alle ACL di default del container AdminSDHolder è sconsigliata perché estende la superficie di attacco del dominio, va comunque precisato che non esistono motivi per cui sia necessario modificare le ACL di default del container AdminSDHolder come riportato nel post Active Directory Access Control List – Attacks and Defense:

“Why would you change AdminSDHolder manually? No idea.

You should be careful with changing the AdminSDHolder, the Exchange team faced several issues with that (in a release candidate) which were all fixed for RTM as the granted permissions on the AdminSDHolder enabled an elevation of privilege scenario that is unacceptable in any environment. If you have a good reason (as we couldn’t find one) please leave us comments at ATAResearch@Microsoft.com.”

Anche in questo caso la prevenzione di questo tipo di attacchi deve innanzitutto basarsi sul monitoraggio dell’infrastruttura inteso come ricerca di potenziali path di attacco e per eseguire tali ricerche è possibile utilizzare un tool open source come BloodHound che utilizzando la teoria dei grafi ricerca relazioni nascoste o non desiderate in un ambiente Active Directory. Un altro tool open source per eseguire l’analisi dei path e delle relazioni in AD, a cui gli stessi autori di BloodHound si sono ispirati, è Active Directory Control Paths. Un terzo tool GUI basato su PowerShell per la creazione di report delle access control lists (DACLs) e delle system access control lists (SACLs) in un ambiente Active Directory è https://github.com/canix1/ADACLScanner, il cui utilizzo è descritto nel post Forensics: Active Directory ACL investigation.

Per l’identificazione di questo tipo di attacchi può anche essere impiegato ATA come indicato nel post Active Directory Access Control List – Attacks and Defense:

“ATA can detect multiple reconnaissance methods, including the ones used by BloodHound, to detect advanced attacks happening in your network.”

Conclusioni

Gli attacchi che hanno come obbiettivo Active Directory sono ovviamente molto pericolosi perché se messi in atto mettono nelle mani dell’attaccante il controllo completo dell’infrastruttura. Per prevenire tali attacchi è necessario gestire attentamente la propria infrastruttura, analizzarla attentamente al fine di scovare preventivamente possibili path di attacco o di escalation e monitorare attentamente comportamenti anomali al fine di bloccare rapidamente eventuali tentativi di compromissione di Active Directory. In altre parole occorre rispettare le 10 Immutable Laws of Security Administration e in particolare oltre alla già citata quinta legge anche la settima:

Law #7: The most secure network is a well-administered one

Dal momento che Active Directory rappresenta il fulcro su cui si basa la sicurezza dell’intera infrastruttura oltre al monitoraggio e analisi è bene adottare anche delle serie politiche per la gestione di account privilegiati a riguardo di veda Securing Privileged Access in cui viene descritto come implementare la protezione degli accessi privilegiati tramite l’utilizzo di account amministrativi separati per attività amministrative, l’adozione di Privileged Access Workstations (PAWs) (a riguarda si veda http://aka.ms/CyberPAW), l’adozione di Local Administrator Password Solution (LAPS) (a riguarda si veda http://aka.ms/LAPS) sia per le workstations che per i server al fine di evitare attacchi Pass-the-Hash and Pass-the-Ticket (per ulteriori informazioni inerenti all’implementazione di queste politiche di sicurezza di veda http://aka.ms/securitystandards).

Sempre nell’ottica di adottare anche delle serie politiche per la gestione di account privilegiati anche le indicazioni fornite nel post Protecting Domain Administrative Credentials circa la best practice di differenziare le credenziali di un amministratore di sistema in base al Tier per cui vengono utilizzate limitando i privilegi di tali credenziali alle sole attività che è necessario svolgere nel Tier:

• Tier 0: attività amministrative su Active Directory
• Tier 1: attività amministrative su server applicativi
• Tier 2: attività non privilegiate di utilizzo dei servizi dell’infrastruttura informatica

Come già discusso anche l’adozione di strumenti di analisi dell’infrastruttura evoluti e basati su machine learning come Advanced Threat Analytics (ATA) possono essere utili nel monitoraggio di tentativi di compromissione, ma come indica la decima delle 10 Immutable Laws of Security Administration non bisogna basare le proprie difese affidandosi ciecamente ad un prodotto di sicurezza:

Law #10: Technology is not a panacea

ATA è sicuramente un ottimo strumento per la rilevazione di vari tipi di attacchi tra cui quelli relativi ad Active Directory (a riguardo si veda Advanced Threat Analytics suspicious activity guide) inoltre la tipicità di questo tipo di prodotto fa sì che sia lecito aspettarsi una sempre maggiore efficacia nel rilevamento dei tentativi di compromissione, ma come detto precedentemente occorre prevedere una difesa della propria infrastruttura basata su più livelli di protezione e monitoraggio. Infatti ATA, al momento, oltre a non avere specifiche funzionalità per il rilevamento di Active Directory BotNet basate sulla modifica degli attributi degli oggetti AD può essere eluso con particolari tecniche descritte nella sessione Evading Microsoft ATA for Active Directory Domination tenuta al blackhat USA 2017 da Nikhil Mittal.

Lavorare su Hyper-V è diventato d’uso comune soprattutto da quando è possibile installarlo gratuitamente come funzionalità aggiuntiva del nostro Windows Desktop.

Una problematica particolare è relativa all’impossibilità di creare un virtual switch (commutatore di rete virtuale) su rete esterna.

In questa piccola guida vedremo come fare evitando di disinstallare il ruolo Hyper-V.

Prerequisiti:

Ruolo Hyper-V installato.

Durante la creazione di un nuovo virtual switch si ottiene un errore generico. Guardando tra i log, si rilevano errori più dettagliati:

Figura 1: Event Viewer – Errore 1

Figura 2: Event Viewer – Errore 2

Figura 3: Event Viewer – Errore 3

Figura 4: Event Viewer – Errore 4

Per risolvere il problema, rimuoviamo eventuali virtual switch creati in precedenza.

Figura 5: Hyper-V – Gestione commutatori virtuali

Nel mio caso ho rimosso tutti i commutatori per la rete esterna.

Lanciamo una powershell elevata ed eseguiamo il comando

netcfg -u vms_pp

Figura 6: PowerShell – Rimozione vms_pp

In questo modo disinstalleremo il vms_pp (Hyper-V Extensible Virtual Switch) che consente ad Hyper-V di gestire le schede di rete.

Aprire la directory:

c:\windows\winsxs\

Tra le tante directory vi è la amd64_wvms_pp.inf_ con relativa versione:

Figura 7: Lista Directory

Nel mio caso:

amd64_wvms_pp.inf_31bf3856ad364e35_10.0.16299.15_none_85d1bf506286d48f

Verifichiamo che in questa directory sia presente il file wvms_pp.inf

Se tutto torna, eseguire il comando inserendo il path correto:

netcfg -l c:\windows\winsxs\amd64_wvms_pp.inf_31bf3856ad364e35_10.0.16299.15_none_85d1bf506286d48f\wvms_pp.inf -c p -i vms_pp

Figura 8: PowerShell – Nuova installazione vms_pp

A questo punto riproviamo la creazione di un virtual switch:

Figura 9: Hyper-V – Configurazione nuovo virtual switch

Cliccando su Applica il processo terminerà con successo.

Figura 10: Hyper-V – Configurazione nuovo virtual switch completata

Conclusione

Questa soluzione è utile soprattutto nel caso in cui il nodo Hyper-V non può essere formattato. Una soluzione pratica anche per gli ambienti di produzione.