Archivi categoria: Windows Server 2016

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.

Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3

Sono disponibili solo da un paio di giorni (e non in tutte le Regioni di Azure) le nuove macchine virtuali della Serie Dv3 ed Ev3. Queste macchine virtuali sono le prime ad essere ospitate su host Hyper-V basati su Windows Server 2016 e sono le prime che usano la tecnologia Hyper-Threading.

L’utilizzo dell’Hyper-Threading permetterà di creare macchine virtuali con più core e quindi migliorerà le performance e l’efficienza delle VM. I processori utilizzati sono Intel® Broadwell E5-2673 v4 2.3GHz e Intel® Haswell 2.4 GHz E5-2673 v3.

Grazie all’host Windows Server 2016 è adesso possibile abilitare la Nested Virtualization, che permette di poter eseguire il ruolo di Hyper-V anche in una macchina virtuale e di farci girare macchine virtuali annidate oppure Hyper-V Containers. Per maggiori informazioni su cosa sia la virtualizzazione annidata e come abilitarla in Windows Server 2016 vi rimando alla lettura dell’articolo https://docs.microsoft.com/it-it/virtualization/hyper-v-on-windows/user-guide/nested-virtualization

Alla pagina https://azure.microsoft.com/it-it/blog/introducing-the-new-dv3-and-ev3-vm-sizes/ potrete trovare un elenco dettagliato delle nuove VM disponibili, dei tagli previsti e delle Regioni dove attualmente sono abilitate.

Creazione di una nuova VM di tipo Ev3 su Azure

Per poter sfruttare la Nested Virtualization è necessario creare una macchina virtuale di tipo Dv3 oppure Ev3 in una delle regioni abilitate. Io ho deciso di utilizzare una macchina E4s_v3 e l’ho creata in West Europe, scegliendo come sistema operativo Windows Server 2016.

Figura 1: Creazione della VM in West Europe

Figura 2: Scelta della dimensione della VM

Figura 3: Configurazione dello storage, della rete e dell’IP pubblico della VM

Figura 4: Schermata riassuntiva con le scelte selezionate

Al termine della creazione della VM potete collegarvi in desktop remoto per configurarla. Dal Server Manager aggiungete il ruolo di Hyper-V e vedrete che non riceverete nessun messaggio di errore, come mostrato in figura:

Figura 5: Abilitazione del ruolo Hyper-V nella nested VM in Azure

Abilitazione della Nested Virtualization

Per semplificare l’abilitazione e la creazione di macchine virtuali annidate, potete scaricare uno script in PowerShell realizzato da Charles Ding, ingegnere del gruppo di sviluppo Microsoft Azure, all’indirizzo https://aka.ms/azurenestedvirtualization. Lo script vi permetterà di configurare il ruolo di Hyper-V e tutte le altre caratteristiche necessarie alla creazione della Nested VM.

Eseguite lo script in PowerShell ISE (lanciato con privilegi elevati) e la prima volta lo script provvederà ad installare il ruolo di Hyper-V, come mostrato in figura:

Figura 6: Esecuzione dello script che installa Hyper-V e che crea la VM annidata

L’installazione di Hyper-V richiede un paio di riavvii, quindi verrete disconnessi dal desktop remoto. Dopo qualche minuto, potrete ricollegarvi e rilanciare lo script per creare la VM. Modificate il valore $VMName “NestedVM-Level2” scegliendo il nome che volete assegnare alla vostra Nested VM e rilanciate lo script. Lo script verificherà che i prerequisiti sia tutti rispettati e creerà la macchina virtuale, abilitando tutte le estensioni necessarie alla virtualizzazione annidata, come mostrato in figura:

Figura 7: Lo script ha creato la VM annidata

Dopo aver avviato la VM annidata, nel mio caso chiamata NestedVM-Level2, potete installare il sistema operativo, come mostrato in figura:

Figura 8: Accensione della nested VM e installazione del sistema operativo

Se volete permette alla macchina annidata di navigare, poiché il MAC Address spoofing non è abilitato su Azure per motivi di sicurezza, sarà necessario creare una rete NAT nell’hypervisor (la VM su Azure) e poi assegnare alla Nested VM un indirizzo statico oppure potete usare il DHCP.

Per prima cosa create nella macchina “host” (la VM su Azure) un nuovo internal switch chiamato NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione di uno switch di tipo Internal

New-VMSwitch -SwitchName “NAT” -SwitchType Internal

Con il comando Get-NetAdapter individuate l’indice assegnato alla nuova interfaccia di rete creata

Figura 9: Interfaccia di rete creata dallo switch di tipo Internal

A questo punto potete assegnare alla nuova scheda di rete un indirizzo IP statico (nel mio caso ho scelto 192.168.0.1), che poi verrà utilizzato dalla nested VM come gateway:

#Assegnazione dell’IP alla nuova interfaccia (sarà il gateway della rete)

New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13

Figura 10: Assegnazione dell’IP statico alla nuova interfaccia di rete

Create la rete di NAT utilizzando il comando PowerShell (lanciato con privilegi elevati):

#Creazione della rete di NAT

New-NetNat -Name NATnetwork -InternalIPInterfaceAddressPrefix 192.168.0.0/24

Adesso che avete completato la configurazione della rete potete collegare la Nested VM al virtual switch NAT che avete creato in precedenza, come mostrato in figura:

Figura 11: La nested VM viene collegata al virtual switch chiamato NAT

Potete installare sulla macchina Azure il servizio DHCP e quindi fare in modo che gli indirizzi vengano assegnati automaticamente. In alternativa potete configurare la scheda di rete della Nested VM con un IP statico, come mostrato in figura:

Figura 12: Configurazione dell’IP statico nella Nested VM

Come è possibile vedere dalla figura sotto, adesso la Nested VM è in grado di navigare in Internet.

Figura 13: La nested VM è connessa ad Internet

Conclusioni

La Nested Virtualization su Azure permette di utilizzare la nuova funzionalità di Windows Server 2016 e di eseguire macchine virtuali annidate oppure gli Hyper-V Containers di Docker. Un possibile caso d’uso della virtualizzazione annidata potrebbe essere la configurazione di un laboratorio di Hyper-V in un ambiente virtualizzato e il test di scenari a più computer (come ad esempio un cluster) senza la necessità di avere dei server fisici.

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.

Privileged Access Management e Temporary Group Membership in Windows Server 2016 AD

Privileged Access Management (PAM) è una funzionalità introdotta in Windows Server 2016 che si basa sul principio dell’amministrazione Just In Time (JIT) e che permette di gestire quella che viene chiamata Just Enough Administration (JEA), che ha come scopo quello di aumentare la sicurezza nella gestione e nella delega dei privilegi in Windows Server.

JEA è un toolkit di Windows PowerShell che definisce un set di comandi per l’esecuzione di attività con privilegi. Limitando nel tempo i privilegi amministrativi è possibile anche aumentare il livello di sicurezza perché molto spesso si assegnano privilegi elevati e successivamente questi privilegi non vengono rimossi, o per dimenticanza o banalmente perché si sottovaluta il pericolo derivante dalla non adozione della modalità amministrativa del Least Administrative Privilege.

Se dobbiamo concedere ad esempio al gruppo di Help Desk o al consulente esterno di effettuare operazioni privilegiate adesso possiamo fare in modo che ci sia un limite di tempo all’appartenenza ad un gruppo amministrativo. Stesso discorso vale se dobbiamo eseguire degli script con un utente particolare.

Privileged Access Management (PAM) contribuisce quindi a risolvere il problema dell’accesso alle risorse di Active Directory ed evitare che gli autori di un attacco informatico possano ottenere le credenziali degli account amministrativi.

Prerequisiti

Per poter utilizzare PAM è necessario prima di tutto che il livello funzionale dalla Foresta di Active Directory sia Windows Server 2016. Inoltre PAM è una funzione che va abilitata, perché non è attiva di default.

Per verificare il livello funzionale della foresta e del dominio potete utilizzare la console Active Directory Administrative Center, come mostrato in figura:

Figura 1: Innalzamento del livello funzionale del Dominio e della Foresta

In alternativa potete anche usare i seguenti comandi PowerShell:

#Get the Active Directory Forest functional level

(Get-ADForest).ForestMode

#Get the Active Directory Domain functional level

(Get-ADDomain).DomainMode

Figura 2: Uso di PowerShell per la verifica dei livelli funzionali di dominio e di foresta

Per innalzare il livello funzionale del dominio e della foresta potete anche usare i comandi PowerShell:

#Raise livello funzionale del dominio a Windows 2016

Set-ADDomainMode -Identity demo.lab -DomainMode Windows2016

#Raise livello funzionale della foresta a Windows 2016

Set-ADForestMode -Identity demo.lab -ForestMode Windows2016

Abilitazione della funzionalità Privileged Access Management (PAM)

Una volta che vi siete accertati che la Foresta abbia il livello funzionale Windows Server 2016, potete installare la funzionalità PAM solo utilizzando PowerShell:

#Abilitazione della funzionalità Privileged Access Management (PAM)

Enable-ADOptionalFeature “Privileged Access Management Feature” -Scope ForestorconfigurationSet -Target demo.lab

Figura 3: Abilitazione della funzionalità Privileged Access Management (PAM)

Nota: Una volta abilitata la funzionalità non è possibile disabilitarla.

Per verificare se la funzionalità sia stata già installata è possibile usare la cmdlet

#Verifica dell’installazione della funzionalità Privileged Access Management (PAM)

Get-ADOptionalFeature “Privileged Access Management Feature”

Figura 4: Verifica dell’installazione della funzionalità Privileged Access Management (PAM) tramite PowerShell

Assegnazione temporanea dell’appartenenza di un utente ad un gruppo di Active Directory

Per poter assegnare temporaneamente uno o più utenti ad un gruppo di AD è necessario effettuare i seguenti comandi PowerShell:

#Definisco la durata di appartenenza al gruppo

$durata New-TimeSpan -Minutes 20

#Aggiungo al gruppo Domain Admind due utenti (attualmente Domain Users)

Add-ADGroupMember -Identity “Domain Admins” -Members nicferr,hector -MemberTimeToLive $durata

Figura 5: Aggiunta di due utenti al gruppo Domain Admins

Per verificare che i due utenti appartengano al gruppo Domain Admin vi basta poi lanciare la cmdlet

Get-ADGroup “Domain Admins” -Property Member -ShowMemberTimeToLive


Figura 6: Verifica dell’appartenenza al gruppo Domain Admins

Come si può notare dalla figura sopra, il risultato riporta:

Member : {<TTL=1068>,CN=Ettore Ferrini,CN=Users,DC=demo,DC=lab, <TTL=1068>,CN=Nicola Ferrini,CN=Users,DC=demo,DC=lab, CN=Administrator,CN=Users,DC=demo,DC=lab}

Accanto ai nomi dei due utenti aggiunti al gruppo Domain Admins c’è un campo TTL (espresso in secondi), che indica la durata rimanente dell’appartenenza al gruppo stesso.

Conclusioni

Privileged Access Management (PAM) è una funzionalità concepita appositamente per gli account amministrativi. Gli amministratori (o gli script) che necessitano solo occasionalmente dell’accesso per gruppi con privilegi, possono richiedere questo accesso e mantenerlo per un periodo limitato di tempo, garantendo la modalità amministrativa del Least Administrative Privilege ed aumentando di fatto la sicurezza della nostra infrastruttura di Active Directory.

Per maggiori informazioni vi rimando all’articolo https://docs.microsoft.com/it-it/microsoft-identity-manager/pam/privileged-identity-management-for-active-directory-domain-services

Nuova funzionalità di Windows Server 2016: Azure Sql Db per il Connection Broker in High Availability Environment

Con Windows Server 2016 si può ora usare Azure SQL, o qualsiasi altro SQL DB in shared environment usando l’autenticazione di SQL per il DB del  Remote Desktop Connection Broker.

Questa funzionalità apre diversi scenari:

  1. Facile delployment e facile gestione, tutto quello che c’è da fare è creare un Azure SQL DB e ottenere la stringa di connessione.
  2. Riduzione dei costi, non c’è bisogno di un SQL Server full (richiesto fino alla versione precedente), Inoltre si ha un modello di consumo e fatturazione che è quello di Azure: pay-as-you.go.
  3. Facile gestione, l’RD Connection Broker può ora connettersi ad Azure SQL DB che è domain-independent

 

Prerequisite 

Il punto di partenza per abilitare questa feature è quello di avere già almeno un RD Connection Broker server e un deploy virtual machine-based o session-based.

A questo punto il server può essere configurato in Active/Active Broker e poi aggiunti altri Connection Broker.

Qui sotto elencati i prerequisiti obbligatori da fare prima di abilitare la feature: 

-> You must have a SQL Server setup that can be used by the RD Connection Broker servers to store data. At least SQL Server 2008 R2 must be used, and the minimum recommended SQL Server SKU for this is Standard with at least 4GB of RAM. For more information about the sizing guidance of SQL Server 2012, see http://msdn.microsoft.com/en-us/library/ms143506.aspx.

-> The RD Connection Broker servers must have full permissions on the SQL Server. To do so you can create a security group, add all the RD Connection Broker servers to it, and give this group full permission to the SQL Server by using SQL Server Management Studio’s “Security” configuration.

-> Configure the Windows Firewall on the SQL Server computer to “Allow SQL Server Access” as described in http://msdn.microsoft.com/en-us/library/cc646023.aspx. You can create the exception for “sqlservr.exe.”

-> Pre-create a folder to store the SQL database files. This folder can be local on the SQL Server computer or a UNC path of a network location.

-> Install SQL Client on all the RD Connection Broker servers so that they can communicate with the SQL Server. For more information about installing the SQL Client, see http://msdn.microsoft.com/en-us/library/ms131321.aspx.

-> Assign static IP addresses to all the RD Connection Broker servers that will be a part of the Active/Active Broker deployment, and create a DNS Round Robin entry with these IP addresses.

-> If you have an RD Gateway server in the deployment, ensure that you create a Remote Desktop resource authorization policy (RD RAP) with an RD Gateway-managed group that includes the DNS RR name of the RD Connection Broker server. This will allow access to the RD Connection Broker servers through the gateway for clients that are connecting by using the DNS RR name. In the following screenshot, the DNS RR name is assumed as ha-rdcb.contoso.com

Come si abilita la nuova funzionalità

 

  • Aprire il Server Manager sul Connection Broker server –> Gestione –> “Aggiungi server”, e aggiungere gli altri RD CB servers.

image

  • Spostarsi in Panoramica (Overview), fare click col pulsante destro sull’icona RD Connection Broker e selezionare “Configura disponibilità elevata”

image

Selezionare “Server di database condiviso”

image image

Completare i seguenti campi:

  • Il nome del DNS Round Robin del cluster di Broker che farà routing nell’Azure load balancer o nel DNS name usato nel DNS round-robin.
  • la connection string del database di SQL. La sintassi è la seguente:
    Driver={SQL Server Native Client 13.0};Server=tcp:cb-sqls1.database.windows.net,1433;Database=CB-DB1;Uid=sqladmin@contoso;Pwd={your_password_here};Encrypt=yes;TrustServerCertificate=no;Connection Timeout=30 
    -> Sostituire la stringa “your_password_here” con la password corretta.

    Fare riferimento a questo articolo : Create an Azure SQL database for the RD Connection Broker

    Dopo aver completato il wizard il database per il RD Connection Broker verrà creato e tutti i dati locali del server broker verranno spostati nel database di SQL Da questo momento il CB Broker comincerà ad usare il SQL server DB. Si ha appena completato la configurazione del server in high availability.
    image

  • Per aggiungere altri RD Connection Broker servers al deployment fare clico col destro sull’icona del RD Connection Broker e selezionare “Aggiungi un server RD Connection Broker”. LA procedura installerà anche il ruolo di CB se non è stato precedentemente installato.
  • Ora si hanno 2 CB in HA configurati in Active/Active Broker mode.

Link Utili:

Use an Azure SQL database to enable high availability for your Connection Broker:

High Availability Solutions (SQL Server)

VeeamON 2017 Recap

Si è da poco conclusa la seconda Keynote del VeeamON 2017, che ha visto diversi annunci e novità presentate. Oltre 2500 professionisti IT sono presenti alla più importante conferenza dedicata all’Availability, con tantissimi partner presenti e sponsor di alto profilo, che hanno presentato le loro soluzioni per l’Always Connect. Ecco gli annunci più importanti presentati durante le due Keynote:

Veeam Agent for Microsoft Windows v2

Il prodotto era già stato rilasciato settimana scorsa ma da ieri il prodotto è ufficialmente sul mercato. La nuova versione consente di effettuare la protezione più avanzata delle proprie macchine fisiche e virtuali, rispetto al precedente Endpoint Backup. Confermati i tre livelli di licensing: Free, Workstation e Server, con diverse funzionalità ed integrazioni.

Veeam Availability for AWS

Grazie alla collaborazione con N2WS, la soluzione permette di proteggere applicazioni e dati presenti all’interno di Amazon Web Services, il tutto in modo agentless. Attualmente l’intera gestione è demandata al partner ma prossimamente si dovrebbero vedere dei cambiamenti.

Veeam Backup for Office 365 v1.5

Nuova build della soluzione dedicata alla protezione delle mailbox posizionate in Office 365. La v1.5 introduce le seguenti novità:

  • Multi-Tenant
  • Multi-Repository con retention differenziate
  • Supporto a RestAPI e PowerShell per automatizzare e creare script per backup e restore

Durante la seconda giornata è stato annunciato il supporto a SharePoint e OneDrive for Business a partire dalla versione 2.0. Un grande colpo che permette di mettere in sicurezza anche i dati aziendali e personali, soprattutto in ottica Ransomware.

Veeam Management Pack v8 Update 4

L’aggiornamento di MP v8 introdurrà nuove dashboard e strumenti per offrire informazioni sempre più dettagliate e utili agli amministratori IT, che utilizzato System Center Operations Manager, oltre al supporto per Hyper-V 2016 e VMware vSphere v6.5. La grande novità riguarda l’estensione delle informazioni all’interno di Microsoft Operations Management Suite, la piattaforma di monitoring basata sul cloud. Le dashboard attualmente disponibili saranno:

Veeam Disaster Recovery in Microsoft Azure

La soluzione si compone di due elementi: Direct Restore for Azure e Veeam Power Network. Quest’ultimo è un prodotto gratuito che si può attivare all’interno dell’Azure Marketplace che permette di creare VPN in modo facile e di rendere le operazioni di Disaster Recovery più semplici e rapide. Nel momento in cui effettuate il Failover di una vostra macchina locale su Azure, potete attivare la connessione VPN, tramite una console web presente on-premises, per fare in modo che i vostri utenti possano collegarsi sempre alle risorse aziendali. La configurazione globale delle varie VPN viene gestita tramite una console web e file XML.

Veeam PN for Microsoft Azure è già disponibile a questo link: https://www.veeam.com/cloud-disaster-recovery-azure-download.html

Il dettaglio della soluzione è disponibile a questo link: https://www.veeam.com/cloud-disaster-recovery-azure.html

Veeam Availability Console v2

Sbarca la versione 2.0 del VAC che introduce diverse funzionalità, tra cui la gestione remota delle console Veeam Backup & Replication, tramite Cloud Connect, ma anche di quelli che sono gli Agent Windows e Linux. Il prodotto nasce prevalentemente per i Service Provider ed è implementato all’interno di una soluzione Cloud (Azure o AWS) per poter garantire sempre la disponibilità del gateway primario. Tra le altre novità troviamo la possibilità di avere più report, poter gestire meglio gli storage tier dei vari clienti e nuove policy di configurazione.

Veeam Backup & Replication v10

Non poteva non esserci la presentazione ufficiale della versione 10 del software più famoso della casa di San Pietroburgo. Molte le novità introdotte, tra cui:

Built-in management for Veeam Agent

Finalmente sarà possibile distribuire gli Agent su macchine fisiche e virtuali dalla console di B&R, sia Windows che Linux, andando a creare le relative policy di retention, scegliendo se configurare l’agent per essere centralizzato o stand-alone. La discovery degli oggetti può essere fatta tramite IP Range, file .csv e tramite Active Directory.

NAS backup support for SMB and NFS shares

Uno dei tasselli mancanti di Backup & Replication era la possibilità di proteggere share di rete presenti all’interno dei NAS, sia SMB che NFS. Con la versione 10 questo sarà possibile, grazie all’utilizzo di un File Proxy, una macchina Windows che ha il compito di recuperare i file dal NAS e spostarli dentro il Repository di destinazione. Molto utile la possibilità di effettuare una doppia retention e di poter creare delle shadow copies delle copie a retention lunga, per evitare la corruzione del dato (sempre in ottica CryptoLocker).

Scale-Out Backup Repository Archive Tier

Sarà possibile andare ad estendere il proprio Scale-Out Repository con uno storage posizionato su cloud, ad esempio Azure Blob Storage o Amazon S3, per ridurre i costi di gestione interna e spostare esternamente tutto quello che può essere definito “vecchio”. Questa funzionalità è molto utile per quelle aziende che non hanno una tape library ma che vogliono avere un sito di disastro con un costo più limitato.

Veeam CDP (Continuous Data Protection)

Il Continuous Data Protection è una modalità che consente di replicare una macchina virtuale all’interno di un altro sito, anche di un partner, con un tempo di RTO ed RPO bassissimi. Questo significa avere una consistenza del dato e dell’applicazione praticamente in realtime, garantendo appunto la Business Continuity. Vista la complessità dell’architettura, Veeam CDP è attualmente disponibile solo per ambienti VMware e la buona notizia è che non vengono utilizzate le snapshot.

Universal Storage Integration API

IBM, Lenovo e Infinidat, queste sono le tre nuove aziende partner di Veeam per la parte di storage. Proprio per invogliare le aziende ad offrire soluzioni integrate con Backup & Replication, è stato creato un nuovo framework chiamato Universal Storage Integration API. La validazione finale di tutto il processo rimane sempre in carico a Veeam e quindi non c’è il rischio che un vendor rilasci una soluzione non supportata.

La Technical Preview dovrebbe essere rilasciata a breve, mentre la RTM è attesa per la fine dell’anno.

Veeam Availability Orchestrator

Annunciata una nuova Preview di VAO, che in questo momento ha ancora dei limiti tecnici, tra cui il fatto di poter gestire solo ambienti VMware. Per chi non lo conoscesse, Orchestrator è la soluzione di gestione DR tra due siti in modo di tenere allineate le varie macchine virtuali e ridurre al minimo l’interruzione di servizio. La logica è quella già presente in Microsoft Azure Site Recovery.

Veeam Agent for Microsoft Windows 2.0

Da ieri è disponibile in GA la versione 2.0 di Veeam Agent for Windows, la soluzione di backup per ambienti fisici client e server. Del prodotto ne abbiamo già parlato all’interno di questo articolo. Tra le funzionalità più importanti troviamo:

  • Active full backups
  • Application-aware processing
  • File indexing and search
  • Instant Recovery to Microsoft Hyper-V VM
  • Integration with Veeam Backup & Replication
  • Server-specific scheduling and retention
  • Synthetic full backups
  • Transaction log backup for databases
  • Back up off site through Veeam Cloud Connect
  • Direct Restore to Microsoft Azure
  • Source-side encryption

Rispetto alla precedente versione, chiamata Endpoint, il supporto alle versioni server è dato a pieno grazie all’application-aware processing. Altre due funzionalità interessanti sono il backup su device USB con disconnessione automatica, o su cloud tramite Cloud Connect. Veeam Agent è disponibile in 3 licenze diverse, che abilitano funzionalità diverse tra di loro, come mostra la figura 2.

Download Veeam Agent for Windows 2.0

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

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