Archivi categoria: Windows

Configurare un site-aware failover cluster e la node fairness in Windows Server 2016

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:

AutoBalancerLevel

Aggressiveness

Host load percentage

1 (default)

Low

80%

2

Medium

70%

3

High

60%

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:

AutoBalancerMode

Behavior

0

Disabled

1

Balance on node join only

2 (default)

Balance on node join and every 30 minutes

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.

Implementare Workgroup Cluster e Multi-Domain Cluster in Windows Server 2016

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.

How to schedule a powerCli script with task scheduler

È incredibile come si perdano le ore ogni volta che bisogna schedulare qualcosa tramite task scheduler di windows…. dato che questa cosa mi ha fatto perdere 1 ora e mezza ho pensato bene di scrivere questo articolo per fare risparmiare tempo a chi si trova nella stessa situazione.

Innanzitutto dobbiamo separare due situazioni: pre powerCli 6 e post powerCli 6 perché dalla versione 6, oltre al path di default che è cambiato, è stato tolto il file vim.psc1 dalla cartella della powerCli.

 

 

Ecco come impostare la “action” da eseguire nel task scheduler:

PRE PowerCli 6:

Program/script:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Add arguments (optional):

-PSConsoleFile  “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1”  -command “&{Z:\ScriptFolder\ScriptName.ps1}”

 

POST PowerCli 6:

Program/script:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Add arguments (optional):

-c “. \”C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1\” $true; C:\ScriptFolder\ScriptName.ps1″

L'articolo How to schedule a powerCli script with task scheduler sembra essere il primo su ITXPerience.

Implementazione di SPID da parte dei Service Provider in ambiente Windows

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:

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.i

Configurare diversi indirizzi IP per la stessa scheda di rete nelle VM in Microsoft Azure

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!

Monitoraggio avanzato del Server DNS

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

Windows 10 Creators Update

Dopo l’Anniversary Update e vari mesi di sviluppo e innumerevoli build Insider, il Creators Update (CU), nuovo major update di Windows 10, è finalmente disponibile. Nonostante Microsoft avesse inizialmente annunciato la distribuzione di un singolo pacchetto cumulativo mensile con le patch di sicurezza e non, l’arrivo del CU coincide con l’introduzione di un secondo pack […]

Come funziona Azure AD Pass-through Authentication

Una delle richieste che più spesso fanno gli utenti è quella di usare le stesse credenziali (nome utente e password) per accedere alle risorse aziendali e ai servizi basati sul Cloud. Questo tipo di autenticazione viene chiamata SAME SIGN-ON.

Utilizzando il tool Azure AD Connect molte aziende usano la sincronizzazione delle password di Azure AD allo scopo di fornire agli utenti un solo set di credenziali di accesso ai servizi locali (Active Directory) e al Cloud.

Da non confondere con l’autenticazione SAME SIGN-ON è invece l’autenticazione SINGLE SIGN-ON, che necessita di Active Directory Federation Services (ADFS). Per approfondimenti vi rimando all’articolo Che cos’è Single Sign-On (SSO).

Autenticazione Pass-through di Azure AD

Una novità, che in realtà è ancora in Preview, è rappresentata dall’autenticazione Pass-through. L’autenticazione Pass-through di Azure AD garantisce che la convalida della password per i servizi di Azure AD venga eseguita in Active Directory (quindi sul Domain controller in locale) e non è quindi necessario memorizzare le password nel Cloud nel Tenant di Azure AD.

Molte aziende infatti, per motivi di sicurezza, non vogliono che le password, anche sotto forma di hash, vengano divulgate al di fuori dell’ambiente aziendale.

L’autenticazione Pass-through è configurata tramite Azure AD Connect, che usa un agent locale per ricevere le richieste di convalida delle password che gli arrivano da Azure AD.

Questo tipo di autenticazione è supportata per tutti i Browser e i client Office che supportano l’autenticazione moderna. Non sono supportati invece i client di posta elettronica nativi su dispositivi mobili.

 

Come funziona l’autenticazione Pass-through di Azure AD

Quando un utente inserisce nome utente e password nella pagina di accesso di Azure AD, le credenziali vengono inserite nella coda del connettore presente in Azure AD per poter essere poi convalidate in Active Directory. La convalida viene eseguita secondo una modalità simile a quella delle password in Active Directory Federation Services (ADFS). A questo punto il domain controller locale valuta la richiesta e restituisce una risposta al connettore, che a sua volta la restituisce ad Azure AD. In figura viene mostrato lo schema di funzionamento:

Figura 1: Principio di funzionamento delll’autenticazione pass-through di Azure AD

Abilitazione dell’autenticazione pass-through di Azure AD

L’autenticazione Pass-through di Azure AD viene abilitata tramite Azure AD Connect. Procediamo quindi all’installazione di Azure AD Connect. Scarichiamo l’eseguibile da link http://go.microsoft.com/fwlink/?LinkId=615771 e lanciamo il setup

Figura 2: Setup di Azure AD Connect

Scegliamo di installare Azure AD Connect in modalità personalizzata, cliccando su Customize e nella schermata successiva facciamo clic su Install.

Figura 3: Installazione dei prerequisiti di Azure AD Connect

Dopo l’installazione dei componenti necessari, viene richiesta la selezione del metodo di accesso degli utenti. Scegliamo quindi la modalità Pass-Through Authentication. Gli utenti potranno accedere ai servizi cloud Microsoft, come ad esempio Office 365, usando la stessa password specificata nella rete locale. La password degli utenti verrà convalidata contattando il domain controller locale.

Figura 4: Scelta della modalità di autenticazione Pass-through

Inseriamo le credenziali per autenticarci al Tenant di Azure AD. Consiglio di usare un account nel dominio onmicrosoft.com predefinito, in modo tale che l’accesso al Tenant non vi venga precluso in caso di indisponibilità del/dei domain controller.

Figura 5: Connessione al Tenant di Azure AD

Per connettersi a Servizi di dominio di Active Directory, Azure AD Connect richiede le credenziali di un account con privilegi di Enterprise Admin. Inseriamo le credenziali corrette e facciamo clic su Add Directory.

Figura 6: Connessione alla foresta locale

Nella schermata successiva ci verranno presentati i domini UPN che sono stati verificati (nel mio caso nicolaferrini.cloud). Assicuriamoci che i domini da usare siano stati verificati in Azure AD e che siano stati aggiunti precedentemente nella console di Active Directory Domains and Trusts.

Figura 7: Aggiunta del nuovo suffisso UPN alla console di Active Directory Domains and Trusts

Figura 8: Verifica dei domini visibili nel Tenant di Azure AD

Di default vengono sincronizzati tutti i domini e le unità organizzative (OU). Per escludere alcuni domini o unità organizzative dalla sincronizzazione con Azure AD, è possibile deselezionarli. Nel mio caso ho messo tutti gli utenti nella OU chiamata Office365 e ho deciso di sincronizzare solo questa OU.

Figura 9: Impostazione del filtro relativo ai domini e alle OU da sincronizzare

Nella schermata relativa all’Identificazione univoca degli utenti lasciamo le configurazioni predefinite e facciamo clic su Next.

Figura 10: parametri per l’identificazione univoca degli utenti

Decidiamo a questo punto se vogliamo filtrare alcuni gruppi della nostra Directory locale. Nel caso lo vogliamo fare, magari perché abbiamo individuato un gruppo di utenti da utilizzare per un test, utilizziamo la notazione LDAP, indicando il distinguished name del gruppo da filtrare.

Figura 11: Scelta di un eventuale gruppo di AD da filtrare

Nella schermata delle funzionalità aggiuntive lasciamo tutto invariato. Poiché abbiamo scelto l’autenticazione Pass-through, l’opzione di sincronizzazione delle password è abilitata di default per garantire il supporto per i client legacy (come ad esempio i dispositivi mobili) e come opzione di backup. Questa opzione ovviamente non è obbligatoria, in quanto, come si è già detto, per alcune aziende è importante che le password non vengano portate nel Cloud.

Figura 12: Scelta facoltativa della password synchronization

Figura 13: Schermata finale di conferma

Dopo aver cliccato su Install partirà il processo di configurazione di Azure AD Connect, come mostrato in figura:

Figura 14: Configurazione del connettore di Azure AD Connect

Terminata la configurazione ci apparirà la schermata finale che ci avviserà dell’avvenuta installazione. Nel mio caso ho ricevuto un avviso che indicava che alcune funzionalità dell’autenticazione Pass-through potrebbero non funzionare in quanto alcune porte sono bloccate.

Per il corretto funzionamento è necessario infatti che siano abilitate le seguenti porte verso il server che esegue il tool di Azure AD Connect:

Numero della porta

Descrizione

80 Abilita il traffico HTTP in uscita per la convalida di sicurezza quale gli elenchi di revoche dei certificati SSL.
443 Abilita l’autenticazione utente con Azure AD.
8080/443 Abilita la sequenza di bootstrap del connettore e l’aggiornamento automatico del connettore.
9090

Abilita la registrazione del connettore (necessaria solo per il processo di registrazione del connettore).

9091

Abilita il rinnovo automatico dei certificati di attendibilità del connettore.

9352, 5671

Abilita la comunicazione tra il connettore e il servizio di Azure AD per le richieste in ingresso.

9350

Facoltativo, consente prestazioni migliori per le richieste in ingresso.

10100–10120

Abilita le risposte dal connettore ad Azure AD.

Figura 15: Configurazione completata

A questo punto ho testato la funzionalità collegandomi al portare https://login.microsoftonline.com ed inserendo le credenziali di un utente locale presente nella OU chiamata Office365 che ho deciso di sincronizzare. Mi è apparsa la schermata “Tentativo di accesso per conto dell’utente” e sono riuscito a loggarmi senza difficoltà.

Figura 16: Accesso dal portale login.microsoftonline.com

Figura 17: Tentativo di accesso per conto dell’utente

Figura 18: Accesso effettuato

Alta disponibilità dell’autenticazione Pass-through di Azure AD

Sicuramente avere un solo server per l’autenticazione di Azure AD rappresenta un single point of failure. Di Di default il primo connettore dell’autenticazione Pass-through viene installato nel server dove avete installato Azure AD Connect. Per distribuire un secondo connettore in un altro server per garantire disponibilità elevata e bilanciamento del carico delle richieste di autenticazione basta scaricare l’Azure AD Application Proxy Connector sul server desiderato, come mostrato in figura:

Figura 19: Download dell’Azure AD Application Proxy Connector

Una volta scaricato Azure AD Application Proxy Connector eseguite un prompt di PowerShell con privilegi amministrativi ed eseguite il comando:

AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q

Successivamente è necessario registrare il connettore con Azure AD per l’autenticazione Pass-through con la seguente procedura:

  1. Aprire una finestra di PowerShell come amministratore
  2. Passare a C:\Programmi\Microsoft AAD App Proxy Connector ed eseguire lo script
    .\RegisterConnector.ps1 -modulePath “C:\Program Files\Microsoft AAD App Proxy Connector\Modules\” -moduleName “AppProxyPSModule” -Feature PassthroughAuthentication
  3. Inserire le credenziali del proprio account amministratore del Tenant Azure AD.

Figura 20: Configurazione di Azure AD Application Proxy Connector sul secondo server

Conclusioni

L’Autenticazione Pass-through di Azure AD semplifica enormemente gli scenari di autenticazione degli utenti, dando la possibilità di evitare che le password vengano sincronizzate con il Cloud e l’autenticazione degli utenti continui ad essere gestita tramite i Domain Controller locali.

RetroComputing: Windows 3.11

Ben 25 anni fa, nel lontano 6 aprile 1992, venne rilascaito Windows 3.11 was released on April 6, 1992. Volendo vedere come era, è possibile simularlo all’interno di un web browser: Il termine retrocomputing indica una attività di “archeologia informatica” che consiste nel reperire computer di vecchie generazioni, ed utilizzarli nuovamente.

Switch delle shell Linux con Windows 10 WSL

Sono passati 9 mesi dal rilascio di Windows 10 Anniversary Update, l’aggiornamento del sistema operativo che ha introdotto la funzionalità Windows Subsystem for Linux (WSL), grazie alla quale è possibile eseguire su Windows i binari di tipo ELF64, compilati cioè per funzionare su un sistema operativo Linux.

All’interno della community ICTPower ci siamo spesso occupati di questa nuova funzionalità, poiché ribadisce con forza la volontà di Microsoft di avvicinare il mondo dell’Open Source, e costituisce quindi una delle novità più importanti della politica aziendale degli ultimi tempi.

Rimandiamo quindi agli articoli precedenti in cui abbiamo illustrato gli step per l’installazione di questa funzionalità:

https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm

e mostrato come sostituire l’immagine di Ubuntu di default con una contenente Suse:

https://www.ictpower.it/guide/opensuse-in-windows-subsystem-for-linux-in-windows-10.htm

In questo articolo, invece, presentiamo un progetto molto interessante che è possibile trovare su github, chiamato WSL Distribution Switcher. Come è possibile intuire dal nome si tratta di un tool in grado di tenere installate sul nostro client Windows 10 molteplici distribuzioni di Linux, ed impostare quella in uso con WSL con un semplice comando.

Finalmente, quindi, ognuno è libero di utilizzare la propria distribuzione preferita, e l’occasione è imperdibile per chi si sta avvicinando al mondo Linux per la prima volta per provare le differenze tra le varie distribuzioni senza creare un numero enorme di macchine virtuali, e scegliere quella più adatta alle proprie esigenze. L’occasione è imperdibile anche per me, poiché utilizzando in maniera molto più agevole CentOS rispetto alle altre, finalmente ho la possibilità di farlo anche con WSL.

Come premessa riporto la pagina del progetto è la seguente, in modo da poterla seguire per tutti gli aggiornamenti futuri:

https://github.com/RoliSoft/WSL-Distribution-Switcher

Il tool è costituito da una serie di immagini, una per ogni distribuzione di Linux, ed uno script per effettuare lo switch da una distribuzione all’altra. Lo script è scritto in Python, un linguaggio di programmazione molto semplice e dinamico, e quindi abbiamo bisogno di installare le relative librerie per utilizzarlo.

Scarichiamo l’ultima versione di Python3 dal sito python.org, ad oggi troviamo la versione 3.6.1 disponibile a questo link:

https://www.python.org/ftp/python/3.6.1/python-3.6.1-amd64.exe

ed installiamo il pacchetto lasciando le impostazioni di default:

Scarichiamo quindi il pacchetto contenente il tool dall’indirizzo:

https://github.com/RoliSoft/WSL-Distribution-Switcher/archive/master.zip

Ed estraiamo l’archivio, ad esempio nella cartella Download

Nel mio caso particolare tutti i file sono nella cartella:

C:\Users\ICTPower\Downloads\WSL-Distribution-Switcher-master

Apriamo una PowerShell e posizionamoci in questa cartella. Per eseguire semplicemente questa operazione è possibile scrivere “powershell” nella barra degli indirizzi della cartella stessa, ed avviamo il download della distribuzione desiderata utilizzando lo script get-source. Iniziamo, ad esempio, scaricando un’immagine di CentOS con il comando:

py.exe .\get-source.py centos

Allo stesso modo è possibile effettuare il download di debian, fedora, suse ed alpine; in futuro saranno sicuramente disponibili immagini di altre distribuzioni. Per eseguire lo step successivo è necessario che WSL sia installato ma non attivo, quindi non dovranno essere aperte istanze di Windows bash al momento dell’esecuzione del comando altrimenti lo script restituirà un errore.

Scaricata l’immagine la installiamo con:

py.exe .\install.py centos

Al termine delle operazioni l’immagine appena installata diventa quella di default all’apertura di Windows bash, verifichiamolo subito aprendo una shell eseguendo dal prompt dei comandi:

bash

e leggiamo il contenuto del file /etc/os-release, che nelle distribuzioni CentOS ci da un po’ di informazioni sulla versione in uso

cat /etc/os-release

Come possiamo vedere ci troviamo su una CentOS7, loggati nel sistema con l’utente creato in fase di installazione di WSL. Nel mio caso il nome dell’utente è gnanoia. Ho trovato un problema nell’eseguire il comando “su” e guadagnare i privilegi di root. Al momento della richiesta della password, infatti, questa non veniva riconosciuta. Non avendo modo di indagare se il problema fosse dovuto alla versione dell’immagine, alla mia build di Windows10 o ad altri fattori, ho trovato un rapido workaround settando l’utente root come predefinito all’apertura di Windows bash; in questo modo la shell viene avviata senza la richiesta di alcuna password ed è possibile eseguire il comando “passwd” per settarne una nuova. E’ poi possibile reimpostare l’utente non privilegiato come predefinito per tornare alla condizione iniziale.

E’ possibile modificare l’utente predefinito di WSL utilizzando il comando lxrun /setdefaultuser <user>, quindi nel nostro caso eseguiamo da un prompt di DOS:

lxrun /setdefaultuser root

quindi apriamo bash e modifichiamo la password con il comando

passwd

chiudiamo la shell di root con

exit

chiudimo la shell iniziale per tornare al DOS con

exit

e risettiamo l’utente iniziale come predefinito. Nel mio caso:

lxrun /setdefaultuser gnanoia

Tutta la sequenza è visibile nello screenshot seguente:

Proviamo ora ad avviare bash ed utilizzare su per utilizzare la shell con privilegi amministrativi:

Ora la nostra immagine Centos7 è completa e funzionante, e possiamo utilizzare il gestore dei pacchetti yum per installare i nostri software preferiti.

Da un’analisi più approfondita però sono emerse delle limitazioni dovute alla tenera età di WSL, per cui non risulta possibile installare alcuni pacchetti, probabilmente per la mancanza del supporto ad alcune syscall; non ci rimane che essere pazienti e sperare che questa funzionalità cresca il più velocemente possibile chissà che nella prossima build di Windows10 non sia già tutto perfettamente funzionante.

In particolare i test di installazione sono falliti per iptools ed httpd, nello screenshot seguente vediamo il dettaglio dell’errore:

yum install httpd

Alla fine dell’elaborazione del comando il risultato sarà quello mostrato in figura:

Senza allarmarci troppo, quindi, fiduciosi di una rapida risoluzione, non perdiamo troppo di vista lo scopo dell’articolo, e torniamo all’installazione di distribuzioni alternative di Linux per WSL, provando ad effettuare in maniera rapida lo switch da una all’altra.

Torniamo quindi sulla nostra PowerShell per scaricare ed installare un’immagine di debian.

Come per l’installazione precedente, lo script imposta l’ultima immagine installata come predefinita, quindi avviando Windows bash ci aspettiamo di trovare una shell Debian. Infatti…

Per switchare da una distribuzione all’altra non è ovviamente necessario reinstallarla, quindi volendo tornare ad utilizzare CentOS, od una qualsiasi altra distribuzione già installata possiamo ricorrere allo script per lo switch:

py.exe .\switch.py centos

Verifichiamo che l’operazione ha avuto successo riaprendo bash e leggendo il file /etc/os-release

Ringraziamo sentitamente gli autori dello script, e rimaniamo in attesa della disponibilità delle nostre immagini preferite; anche in questo caso non possiamo fare a meno di notare che l’avvicinamento di Microsoft al mondo dell’Open Source sta scatenando una miriade di contributi di chi, ognuno a modo proprio, cerca di favorire la completa integrazione dei sistemi.