Archivi categoria: Datacenter

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.

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

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

Implementare il Single Sign-On (SSO) con Azure AD

La maggior parte degli utenti vuole utilizzare un’unica password per poter accedere sia all’Active Directory locale che ai servizi che usano Azure AD, come ad esempio Office 365. Abbiamo visto in un precedente articolo, Come funziona Azure AD Pass-through Authentication, come poter fare in modo che l’autenticazione avvenga utilizzando il domain controller locale, nel caso non vogliamo replicare le nostre password in Azure AD. Utilizzare la stessa username e password sia all’interno che all’esterno della propria infrastruttura aziendale prende il nome di SAME SIGN-ON.

In questo articolo vedremo invece come implementare il SINGLE SIGN-ON (SSO), un’opzione che consente agli utenti di non dover digitare la password, ma solo il nome utente, per accedere ad Azure Active Directory.

SSO è una funzionalità che viene abilitata tramite il tool Azure AD Connect e funziona sia con la sincronizzazione delle password sia con l’autenticazione pass-through. Questo tipo di funzionalità però è disponibile solo se il computer da cui effettuiamo la connessione è joinato al dominio.

Vantaggi del Single Sign-on con autenticazione Pass-through di Azure AD

Sicuramente tra i vantaggi più evidenti di questo tipo di autenticazione spicca quello di evitare l’uso dei Federation Services, che prevedono una farm di almeno 2 Server ADFS nel Backend e 2 Server Web Application Proxy nella DMZ, per un totale di 4 server! Per avere un’idea di quanto sia complicata l’infrastruttura che usa ADFS potete dare un’occhiata all’articolo Checklist: Use AD FS to implement and manage single sign-on.

Come funziona

Il principio di funzionamento del Single Sign-On con Azure AD è molto semplice. Quando l’utente tenta di accedere ad una risorsa che usa Azure AD per l’autenticazione, come ad esempio il portale di Office 365, gli vengono chieste le credenziali. L’utente viene reindirizzato al portale di autenticazione https://login.microsoftonline.com e dopo aver inserito la propria username, viene reindirizzato verso il proprio domain controller. Active Directory restituisce un ticket Kerberos al client. Il client invia il ticket Kerberos acquisito da Active Directory ad Azure AD. Azure AD decrittografa il ticket Kerberos e restituisce un token all’utente, che lo riutilizza per poter accedere alla risorsa, come ad esempio il portale di Office365.

Il tutto avviene in maniera completamente trasparente per l’utente, che dopo aver inserito la username si ritrova autenticato senza aver dovuto inserire la password.

Figura 1: Principio di funzionamento del Single Sign-On (SSO)

Abilitazione di SSO con autenticazione pass-through

Single Sign-On è un’opzione che può essere abilitata utilizzando il tool Azure AD Connect tramite sincronizzazione delle password o autenticazione pass-through.

In questo articolo ci occuperemo di implementare il SSO con l’autenticazione pass-through.

Procediamo all’installazione di Azure AD Connect scaricando l’eseguibile dal 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 e mettiamo il segno di spunta su Enable single sign-on, come mostrato in figura:

Figura 4: Single Sign-On con autenticazione pass-through

Inseriamo a questo punto le credenziali da Global Admin del nostro Tenant di Azure AD. Usate un utente creato nel Cloud, possibilmente un account del dominio onmicrosoft.com.

Figura 5: Connessione ad Azure AD

Nella schermata successiva inseriamo le credenziali di Enterprise Admin del nostro dominio di Active Directory locale.

Per poter utilizzare le stesse credenziali sia per il login in Active Directory che per il login in Azure AD è necessario che gli username e i suffissi UPN (User Principal Name) coincidano. Per questo motivo nella schermata successiva vi verranno mostrati i domini che sono stati verificati nel vostro Tenant di Azure AD. Verificate che i domini siano corretti, altrimenti procedete alla regsitrazione dei suffisso UPN utilizzando la console di Active Directory Domains and Trusts.

Figura 6: Verifica dei suffissi UPN e del domini verificati in Azure AD

Di default vengono sincronizzati tutti i domini della foresta e tutte le unità organizzative (OU). Per escludere alcuni domini o unità organizzative dalla sincronizzazione con Azure AD, è possibile deselezionarli. Io ho deciso di sincronizzare solo la OU chiamata Office365.

Figura 7: Scelta dei domini e delle OU da sincronizzare

Nella schermata relativa all’Identificazione univoca degli utenti lasciamo le configurazioni predefinite e facciamo clic su Next. Lasciamo tutte le impostazioni di default anche per la schermata Filter Users and Devices.

Figura 8: Parametri per l’identificazione univoca degli utenti

Figura 9: Scelta degli utenti o del gruppo da sincronizzare

Nella schermata delle Optional Features, poiché abbiamo scelto l’autenticazione Pass-through, l’opzione di sincronizzazione delle password è abilitata di default. Questa opzione non è obbligatoria e per alcune aziende è importante che le password non vengano portate nel Cloud. Decidiamo quindi di non selezionarla, come mostrato in figura:

Figura 10: Optional features

Quando si abilita Single Sign-On in Azure AD Connect, viene creato un account computer denominato AZUREADSSOACCT nell’Active Directory locale e la chiave di decrittografia di Kerberos è condivisa con Azure AD. Inoltre vengono creati due Service Principal Name (SPN) Kerberos per indicare gli URL del cloud usati durante l’autenticazione tra il client e Azure AD. Inseriamo a questo punto le credenziali di Domain admin appropriate per il nostro dominio, in modo tale che venga creato l’account computer AZUREADSSOACCT , come mostrato in figura:

Figura 11: Inserimento delle credenziali per la configurazione del computer account nell’ Active Directory locale

Cliccando su Next avremo completato la configurazione e subito dopo inizierà il processo di sincronizzazione con il nostro Tenant di Azure AD.

Figura 12: Completamento del processo di configurazione

Figura 13: Installazione completata

Figura 14: Account computer AZUREADSSOACCT creato nell’Active Directory locale

Per poter testare il funzionamento del Single SIGN-On ci basterà loggarci su uno dei client del dominio e accedere al portale di autenticazione di Azure AD https://login.microsoftonline.com

Per poter garantire l’accesso automatico del client è prima necessario impostare nella Local Intranet del browser i due url:

Questa impostazione consente al browser di inviare automaticamente le credenziali dell’utente connesso sotto forma di un ticket Kerberos per Azure AD.

Apriamo Internet Explorer, clicchiamo sul simbolo della rotellina per aprire le Internet Options, spostiamoci nella scheda Security e selezioniamo Local Intranet. Dopo aver cliccato su Sites, clicchiamo su Advanced e si aprirà la schermata dove potremo inserire i due URL, come mostrato in figura:

Figura 15: Aggiunti esplicita all’area Intranet del computer dei due siti di autenticazione

Figura 16: Particolare dei due URL aggiunti alla Local Intranet

Se non usate Internet Explorer ma usate Google Chrome non avrete problemi perché per impostazione predefinita Chrome usa lo stesso insieme di URL di siti attendibili di Internet Explorer.

È anche possibile utilizzare una Group Policy per poter automatizzare questa impostazione. Ci basterà creare una nuova GPO da collegare al dominio e in User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page dobbiamo modificare la voce Site to Zone Assignment List

Facendo clic sul pulsante Show potremo inserire i due URL richiesti, come mostrato in figura:

Figura 17: URL e valori da inserire

Conclusioni

Il SINGLE SIGN-ON, in associazione all’autenticazione Pass-through, ci permette di avere le stesse funzionalità che fino ad ora erano possibili sono utilizzando gli Active Directory Federation Services, che richiedono diverse macchine per poter funzionare. Davvero una grossa novità ed un grosso vantaggio per autenticarsi in Azure AD senza dover sincronizzare le password in Azure AD.

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.

Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA

L’implementazione di una Certification Authority (CA) Two-Tier (a due livelli) si conclude con l’installazione della Subordinate CA anche detta issuing CA. La trattazione delle componenti di una PKI e della configurazione di un server web per la pubblicazione della CRL e dei certificati delle CA è disponibile nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1, mentre nell’articolo Deploy PKI in Windows Server 2016 – Parte 2 è stata descritta l’installazione e la configurazione della Root CA Offline.

Di seguito analizzeremo quindi l’installazione e la configurazione della Subordinate CA Offline, nell’ipotesi di voler realizzare una CA Two-Tier (a due livelli) facendo riferimento al seguente schema che verrà utilizzato come scenario di esempio.

La Subordinate CA sarà di tipo Enterprise in modo da poter essere utilizzata in modo integrato con Active Diectory e poter utilizzare i modelli di certificato, quindi il server che assolverà il ruolo di Subordinate CA dovrà essere membro del dominio Active Directory.

Per ulteriori informazioni si vedano:

Installazione e configurazione della Subordinate CA

Per configurare il servizio di CA occorre aggiungere il ruolo Active Directory Certificate Services selezionando l’installazione del servizio Certification Autority.

Terminata l’installazione è possibile configurare il servizio della CA in base alle seguenti impostazioni utilizzando le credenziali di un account membro del gruppo Enterprise Admin di Active Directory. Durante la procedura di configurazione verrà creata una richiesta di certificato per generare il certificato della Subordinate CA che dovrà poi essere gestito dalla Root CA.

Tipo installazione CA Enteprise
Tipo CA Subordinate
Provider servizio di crittografia RSA#Microsoft Software Key Storage Provider
Lunghezza chiave 4096
Algoritmo hash per firma certificati SHA512
Nome ICTPower Issuing CA
Validità certificato CA 10 anni
Validità certificati emessi dalla CA 5 anni
Path database e logs S:\Windows\system32\CertLog
Path certificato CA e CRL C:\Windows\System32\CertSrv\CertEnroll

Configurazione dell’accesso al server Web per la pubblicazione della CRL

Per consentire l’accesso al server web da parte della Subordinate CA l’approccio più corretto è quello di creare sul server web un account con privilegi di lettura e scrittura su una share che punti alla cartella che conterrà le CRL e i certificati delle CA come illustrato nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1. Nello scenario di esempio sul server web Web01 si ipotizza che siano state eseguite le seguenti configurazioni:

  1. Creazione di un record DNS crl di tipo A per il server web consenta l’accesso a quest’ultimo tramite il nome crl.ictpower.local
  2. Creazione di un account CAUpdate che verrà utilizzato dal server Root CA e Subordinate CA per accedere alla cartella condivisa in cui copiare CRL e certificato CA.
  3. Creazione della share CertEnroll per concedere l’accesso in lettura e scrittura alla cartella S:\CertEnroll tramite l’account CAUpdate.

Sul server Subordinate CA occorre quindi memorizzare sull’account che verrà utilizzato per aggiornare CRL e certificato CA sul server web le credenziali dell’account CAUpdate specificando come indirizzo del server crl.ictpower.local.

Richiesta del certificato per Subordinate CA

Dalla Root CA sottomette la richiesta della Subordinate CA che nel processo di configurazione è stata memorizzata sul disco di sistema C: e volendo è raggiungibile dalla Root CA tramite il percorso URL \\casub.ictpower.local\c$.

Emettere il certificato per la Subordinate CA.

Esportare il certificato per la Subordinate CA in formato PKCS #7 (.PB7) selezionando l’opzione di includere tutti i certificati (ovvero il certificato della Root CA) nel percorso URL \\casub.ictpower.local\c$.

Installazione del certificato della Subordinate CA

Prima di installare il certificato della CA aggiungere l’url http://crl.ictpower.local all’elenco dei Trusted Sites sul server Subordinate CA.

Installare il certificato della CA precedente generato dalla Root CA ed esportato in C:\ CASub.ictpower.local_ictpower-CASUB-CA.p7b.

Avviare il servizio della Subordinate CA.

Configurazione Estensioni della Subordinate CA per impostare i CRL (Certificate Revocation List) Distribution Points (CDP)

Lo scopo delle estensioni CRL CDP è quello di indicare ai client dove trovare le CRL aggiornate firmate dalla CA, tali informazioni verranno poi inserite nei certificati generati dalla CA.

Per impostazione predefinita vi sono quattro CRL CDP già configurati e su alcuni di essi occorre eseguire alcune impostazioni affinché l’unico riferimento alla CRL che verrà inserito nei certificati rilasciati sia quello dell’URL del server Web che pubblica la CRL. Nello scenario di esempio l’URL di pubblicazione della CRL è http://crl.ictpower.local/CertEnroll.

Come riportato in Optimizing the Revocation Experience conviene però gestire la CRL solo tramite http disabilitando quindi le opzioni di pubblicazioni nel CDP relativo a LDAP:

“Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.”

Il CRL CDP locale è usato dalla CA e non necessita di essere modificato.

Il CRL CDP ldap deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP http è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP file è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Creare un CRL CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl.

Applicare le modifiche riavviando i servizi della CA.

Configurazione Estensioni della Subordinate CA per impostare gli Access Information Access (AIA) Distribution Points (CDP)

Lo scopo delle estensioni AIA CDP è quello di indicare ai client dove trovare il certificato della CA per eseguire la verifica dell’attendibilità nel caso in cui il certificato non contenga al suo interno la catena dei certificati, tali informazioni verranno poi inserite nei certificati generati dalla CA.

L’ AIA CDP locale per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato.

L’AIA CDP ldap deve essere modificato in modo da non essere utilizzato per pubblicare i certificati, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP http per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP file per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

Creare un AIA CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt.

Applicare le modifiche confermando il riavvio dei servizi delle CA.

Pubblicazione della CRL e del certificato della Subordinate CA

E’ possibile pubblicare la CRL della Subordinate CA tramite interfaccia grafica

Oppure tramite il comando:

certutil –CRL

Copiare sul server web d pubblicazione la CRL e il certificato tramite i comandi:

copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crl” \\crl.ictpower.local\CertEnroll
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crt” \\crl.ictpower.local\CertEnroll

Configurazione della validità dei certificati emessi

Per default la validità dei certificati emessi da una CA Enterprise è di due anni, ma tale impostazione è modificabile tramite certutil che a sua volta modificherà le impostazioni nel registro.

Dal momento che la durata del certificato della CA è stato impostato a 10 anni con previsione di rinnovo ogni 5 anni la validità dei certificati emessi verrà impostata a 5 anni tramite il comando:

certutil -setreg ca\ValidityPeriodUnits “5”

La chiave di registro in cui vene mantenuta tale impostazione è:

HKLM\System\CurrentControlSet\Configuration\CAName\ValidityPeriodUnitis

Al termine della configurazione riavviare il servizio della CA, ad esempio tramite il comando:

net stop certsvc & net start certsvc

Verifica della configurazione della CA

Terminata l’installazione e la configurazione della Subordinate CA occorre verificare che la PKI funzioni correttamente, uno strumento utile per eseguire tale verifica è il tool pkiview.msc:

Deploy PKI in Windows Server 2016 – Parte 2 – Installazione e configurazione di una Root CA Offline

L’implementazione di una Certification Authority (CA) nella propria infrastruttura prevede una preventiva analisi della struttura della Public Key Infrastructure (PKI) più adatta alla propria organizzazione e la predisposizione dei prerequisiti necessari. La trattazione delle componenti di una PKI e della configurazione di un server web per la pubblicazione della CRL e dei certificati delle CA è disponibile nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1.

Di seguito analizzeremo l’installazione e la configurazione di una Root CA Offline, nell’ipotesi di voler realizzare una CA Two-Tier (a due livelli) facendo riferimento al seguente schema che verrà utilizzato come scenario di esempio.

La Root CA viene mantenuta normalmente spenta, di conseguenza è preferibile che non sia integrata in Active Directory e quindi dovrà essere Standalone e non Enterprise, mentre la Subordinate CA a cui verrà demandano il compito di rilasciare i certificati sarà di tipo Enterprise per beneficiare dell’utilizzo dei modelli di certificato e dell’integrazione con Active Directory.

Sebbene spesso la giustificazione del fatto che la Root CA Offline è preferibile che sia non joinata ad un domino Active Directory, e quindi Standalone e non Enterprise, sia imputata al fatto che la scadenza della password dell’account computer che per default avviene ogni 30 giorni, causando l’impossibilità di utilizzare il secure channel. In realtà come indicato nel post Machine Account Password Process dal momento che il processo di rinnovo della password dell’account computer è avviato dal client non vi alcun rischio che il secure channel non possa essere utilizzato anche se la Root CA viene mantenuta spenta per lunghi periodi.

“Question: If a workstation does not change its password, will it not be allowed to log onto the network?

Answer: Machine account passwords as such do not expire in Active Directory. They are exempted from the domain’s password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time.

Before we set the new password locally, we ensure we have a valid secure channel to the DC. If the client was never able to connect to the DC (where never is anything prior the time of the attempt – time to refresh the secure channel), then we will not change the password locally.”

In realtà il vero motivo per cui è preferibile la Root CA sia Standalone è che per avere un’elevata sicurezza non dovrebbe essere connessa alla rete neppure quando viene avviata saltuariamente per installare gli aggiornamenti automatici, ma attestata su una rete separata che consenta la comunicazione con l’infrastruttura solo per permettere l’aggiornamento della CRL e del certificato della CA sul server web che si occupa di pubblicarli.

Per ulteriori informazioni si vedano:

Installazione e configurazione della Root CA Offline

Per configurare il servizio di CA occorre aggiungere il ruolo Active Directory Certificate Services selezionando l’installazione del servizio Certification Autority.

Terminata l’installazione è possibile configurare il servizio della CA in base alle seguenti impostazioni utilizzando le credenziali di amministratore locale.

Tipo installazione CA Standalone
Tipo CA Root
Provider servizio di crittografia RSA#Microsoft Software Key Storage Provider
Lunghezza chiave 4096
Algoritmo hash per firma certificati SHA512
Nome ICTPower Root CA
Validità certificato CA 20 anni
Validità certificati emessi dalla CA 10 anni
Path database e logs S:\Windows\system32\CertLog
Path certificato CA e CRL C:\Windows\System32\CertSrv\CertEnroll

Per sicurezza il nome della CA non fa alcun riferimento all’hostname del server e il database dei certificati viene mantenuto in un disco separato da quello di sistema.

Configurazione Estensioni della Root CA Offline per impostare i CRL (Certificate Revocation List) Distribution Points (CDP)

Lo scopo delle estensioni CRL CDP è quello di indicare ai client dove trovare le CRL aggiornate firmate dalla CA, tali informazioni verranno poi inserite nei certificati generati dalla CA.

Per impostazione predefinita vi sono quattro CRL CDP già configurati e su alcuni di essi occorre eseguire alcune impostazioni affinché l’unico riferimento alla CRL che verrà inserito nei certificati rilasciati sia quello dell’URL del server Web che pubblica la CRL. Nello scenario di esempio l’URL di pubblicazione della CRL è http://crl.ictpower.local/CertEnroll.

Il CRL CDP locale è usato dalla CA e non necessita di essere modificato.

Il CRL CDP ldap deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP http è già impostato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Il CRL CDP file deve essere modificato in modo da non pubblicare la CRL, volendo è anche possibile rimuovere tale CRL CDP dal momento che di fatto non verrà utilizzato.

Creare un CRL CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.ictpower.local/CertEnroll/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl.

Applicare le modifiche riavviando i servizi della CA.

Configurazione Estensioni della Root CA Offline per impostare gli Access Information Access (AIA) Distribution Points (CDP)

Lo scopo delle estensioni AIA CDP è quello di indicare ai client dove trovare il certificato della CA per eseguire la verifica dell’attendibilità nel caso in cui il certificato non contenga al suo interno la catena dei certificati, tali informazioni verranno poi inserite nei certificati generati dalla CA.

L’ AIA CDP locale per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato.

L’AIA CDP ldap per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP http per impostazione predefinita non viene incluso nei certificati e quindi non necessita di essere modificato, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

L’AIA CDP file deve essere modificato in modo da non essere incluso nei certificati, volendo è anche possibile rimuovere tale AIA CDP dal momento che di fatto non verrà utilizzato.

Creare un AIA CDP per l’URL http con le opzioni di inclusione nella CRL per l’URL http://crl.
ictpower.local/CertEnroll/<ServerDNSName>_<CaName><CertificateName>.crt.

Applicare le modifiche confermando il riavvio dei servizi delle CA.

Configurazione della CRL della Root CA Offline

Impostare la pubblicazione della CRL ad un periodo superiore a quello a cui si prevede di avviare periodicamente la Root CA Offline che normalmente sarà mantenuta spenta. Tramite le proprietà dei Certificati revocati si imposta un intervallo di pubblicazione di 4 settimane ipotizzando che settimanalmente la CA sarà avviata per installare eventuali aggiornamenti del sistema.

Verificare in C:\Windows\System32\CertSrv\CertEnroll che la CRL sia stata pubblicata, è possibile avviare la pubblicazione della CRL tramite la voce del menu contestuale All Tasks\Pubblish dei Certificati revocati, oppure mediante il comando:

certutil -CRL

Configurazione della validità dei certificati emessi dalla Root CA Offline

Per default la validità dei certificati emessi da una CA Standalone è di un anno, ma tale impostazione è modificabile tramite certutil che a sua volata modificherà le impostazioni nel registro.

Dal momento che la durata del certificato della CA è stato impostato a 20 anni con previsione di rinnovo ogni 10 anni la validità dei certificati emessi verrà impostata a 10 anni tramite il comando:

certutil -setreg ca\ValidityPeriodUnits “10”

La chiave di registro in cui vene mantenuta tale impostazione è:

HKLM\System\CurrentControlSet\Configuration\CAName\ValidityPeriodUnitis

Al termine della configurazione riavviare il servizio della CA, ad esempio tramite il comando:

net stop certsvc & net start certsvc

Copia della CRL e del certificato della Root CA Offline su server Web per la pubblicazione della CRL

Per consentire l’accesso al server web da parte della Root CA Offline l’approccio più corretto è quello di creare sul server web un account con privilegi di lettura e scrittura su una share che punti alla cartella che conterrà le CRL e i certificati delle CA come illustrato nel precedente articolo Deploy PKI in Windows Server 2016 – Parte 1. Nello scenario di esempio sul server web Web01 si ipotizza che siano state eseguite le seguenti configurazioni:

  1. Creazione di un record DNS crl di tipo A per il server web consenta l’accesso a quest’ultimo tramite il nome crl.ictpower.local
  2. Creazione di un account CAUpdate che verrà utilizzato dal server Root CA e Subordinate CA per accedere alla cartella condivisa in cui copiare CRL e certificato CA.
  3. Creazione della share CertEnroll per concedere l’accesso in lettura e scrittura alla cartella S:\CertEnroll tramite l’account CAUpdate.

Sul server Root CA occorre quindi memorizzare sull’account che verrà utilizzato per aggiornare CRL e certificato CA sul server web le credenziali dell’account CAUpdate specificando come indirizzo del server crl.ictpower.local.

Aggiornare la CRL e copiare sul server web la CRL e il certificato CA della Root CA Offline tramite i comandi che possono anche essere eseguiti tramite un’operazione schedulata all’avvio della Root CA:

certutil -CRL
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crl” \\crl.ictpower.local\CertEnroll
copy /Y “C:\Windows\System32\CertSrv\CertEnroll\*.crt” \\crl.ictpower.local\CertEnroll

Windows Server 2016 Highlights: Hyper-converged Cluster

Tra le novità di Windows Server 2016 spiccano quelle relative all’iperconvergenza dello storage e dell’hypervisor. Per iperconvergenza o per infrastruttura iperconvergente si intende una infrastruttura IT basata su risorse hardware offerte da un unico vendor, che integra calcolo, memorizzazione, virtualizzazione e networking. Tutte le risorse vengono gestite tramite software e l’espansione del sistema è fortemente semplificata.

Avevamo già parlato in un precedente articolo su come implementare Storage Spaces Direct. La nuova funzionalità S2D di Windows Server 2016 permette infatti di creare sistemi di storage ad alta disponibilità utilizzando dischi locali. Se poi sugli stessi nodi fisici utilizzati per creare l’infrastruttura S2D installiamo anche Hyper-V, abbiamo la possibilità di creare un cluster hyper-convergente.

Figura 1: Schema di funzionamento di una soluzione Hyper-convergente

In questo articolo vi voglio mostrare queste due funzionalità e realizzare un laboratorio di test per provare la soluzione di Hyper-convergenza offerta da Microsoft. L’obiettivo è quello di creare un cluster a 2 nodi di Hyper-V che usa Storage Spaces Direct.

Figura 2: Schema del laboratorio da realizzare

Nel mio laboratorio, realizzato su un computer con Windows 10 Anniversary Update e con il ruolo Hyper-V installato, ho creato due macchine virtuali, chiamate HV1 ed HV2, all’interno delle quali ho installato Hyper-V. Questo mi permette anche di farvi vedere come funziona la Nested Virtualization, un’altra novità disponibile in Windows 10 Anniversary Update e in Windows Server 2016.

Dopo aver creato le due macchine virtuali HV1 ed HV2 ed aver assegnato loro almeno 4GB di RAM staticamente (controllate i prerequisiti per la Nested Virtualization), ho lanciato (a VM spente) una PowerShell con privilegi elevati e ho abilitato la nested virtualization con i comandi:

#Abilitazione della Nested Virtualization

Set-VMProcessor -VMName HV1 -ExposeVirtualizationExtensions 1

Set-VMProcessor -VMName HV2 -ExposeVirtualizationExtensions 1

Figura 3: Creazione sulla macchina Windows 10 delle due macchine virtuali che faranno da host Hyper-V

Ho installato Windows Server 2016 all’interno di HV1 ed HV2 e ho abilitato il ruolo di Hyper-V. È possibile abilitare il ruolo anche utilizzando la nuova funzionalità di PowerShell Direct. Questa funzionalità permette di eseguire delle cmdlet di PowerShell dalla macchina host verso le VM, anche se le VM non hanno una scheda di rete o la scheda di rete è disconnessa. I comandi che ho usato sono:

#Installazione del ruolo Hyper-V utilizzando PowerShell Direct

$cred Get-Credential

Invoke-Command -VMName HV1 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Invoke-Command -VMName HV2 -Credential $cred -ScriptBlock {Install-WindowsFeature -Name hyper-v -IncludeManagementTools -Restart}

Terminata l’installazione del ruolo ho provveduto a creare sullo storage locale dei due nodi Hyper-V due machine virtuali che utilizzerò come Domain controller e che ho chiamato DC1 e DC2. I due domain controller rimarranno ognuno assegnato al proprio nodo Hyper-v e verranno messi in esecuzione automatica, in modo tale che il dominio sia sempre disponibile. Poiché il servizio cluster dipende da Active Directory i due domain controller non verranno “clusterizzati”, ma rimarranno delle semplici macchine virtuali.

Figura 4: Due Domain controller annidati sugli Host virtuali HV1 ed HV2

Per far parlare tra di loro i due domain controller ho provveduto a creare sui due nodi HV1 ed HV2 un virtual switch di tipo External e successivamente ho abilitato sulle schede di rete di HV1 ed HV2 il MAC Address Spoofing dalle proprietà avanzate delle schede, in quanto le due macchine DC1 e DC2 stanno utilizzando la Nested Virtualization e senza abilitazione del MAC Address Spoofing i pacchetti di rete non riuscirebbero a superare i due Virtual Switch.

Figura 5: Abilitazione del MAC Address Spoofing

L’abilitazione del MAC Address Spoofing si può effettuare anche da PowerShell usando il comando:

#Abilitazione del MAC Address Spoofing

Get-VMNetworkAdapter -VMName HV1,HV2 | Set-VMNetworkAdapter -MacAddressSpoofing On

Dopo aver creato il dominio su DC1 e aver aggiunto DC2 come domain controller aggiuntivo, ho provveduto ad aggiungere al dominio anche i nodi HV1 ed HV2. Ho configurato anche le virtual machine DC1 e DC2 in modo tale che possano partire automaticamente quando parte l’host di virtualizzazione.

Figura 6: Autostart dei due Domanin controller DC1 e DC2

Abilitazione delle funzionalità di Storage Spaces Direct

Prima di abilitare la funzionalità S2D vi invito a dare un’occhiata agli Storage Spaces Direct hardware requirements. Tra le configurazioni supportate io ho scelto quella in cui ci sono 4 dischi SSD per ogni singolo nodo.

Drive types present

Minimum number required

All NVMe (same model)

4 NVMe

All SSD (same model)

4 SSD

NVMe + SSD

2 NVMe + 4 SSD

NVMe + HDD

2 NVMe + 4 HDD

SSD + HDD

2 SSD + 4 HDD

NVMe + SSD + HDD

2 NVMe + 4 Others

Per questo motivo ho aggiunto ad entrambi i nodi HV1 ed HV2 4 dischi da 512 GB. Per semplicità ho effettuato l’operazione lanciando dalla macchina fisica con Windows 10 eseguendo le seguenti cmdlet:

#Aggiunta dei dischi alla macchina HV1

1..4% { New-VHD -Path “C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX” -Dynamic –Size 512GB}

1..4% { Add-VMHardDiskDrive -VMName HV1 -ControllerType SCSI -Path “C:\LAB\HV1\Virtual Hard Disks\DISCO$_.VHDX” }

#Aggiunta dei dischi alla macchina HV2

1..4% { New-VHD -Path “C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX” -Dynamic –Size 512GB}

1..4% { Add-VMHardDiskDrive -VMName HV2 -ControllerType SCSI -Path “C:\LAB\HV2\Virtual Hard Disks\DISCO$_.VHDX” }

Una volta che i dischi sono stati aggiunti sarà possibile utilizzarli per attivare la funzionalità di Storage Spaces Direct. Ho installato su entrambi i nodi HV1 ed HV2 la feature di Failover Clustering e terminata l’operazione di installazione ho aperto un prompt di PowerShell con privilegi elevati su uno dei due nodi ed ho effettuato un test per verificare se fosse possibile configurare il cluster ed utilizzare S2D eseguendo la cmdlet:

#Test della configurazione dei nodi che formeranno il Cluster

Test-Cluster –Node HV1,HV2 –Include “Storage Spaces Direct”Inventory, Network“System Configuration”

Figura 7: Test della configurazione dei nodi che formeranno il Cluster

Se tutti i test sono andati a buon fine e non avete ricevuto errori potete procedere alla creazione del cluster. Non avendo ricevuto errori ho eseguito su uno dei nodi del cluster HV1 oppure HV2 la seguente cmdlet:

#Creazione di un nuovo cluster

New-Cluster -Name S2DCluster -Node HV1,HV2 –NoStorage –StaticAddress 10.10.10.100

Figura 8: Creazione del Cluster S2DCluster

Al termine della creazione del cluster ho ricevuto un warning. Controllate il contenuto del report creato e verificate che, poiché abbiamo scelto di utilizzare solo 2 nodi e di non aggiungere nessuno storage condiviso al cluster, sarà necessario configurare un witness, come mostrato in figura:

Figura 9: warning presente nel report, riferito al quorum witness

Per questo laboratorio ho preferito usare una novità del cluster di Windows Server 2016: Il Cloud Witness. Aprendo la console Failover Cluster Manager su HV1 sarà infatti possibile cambiare la modalità di quorum selezionando il nome del cluster e scegliendo More Actions à Configure Cluster Quorum Settings…

Figura 10: Modifica della funzionalità di Quorum del Cluster

Ho seguito il wizard di configurazione ed ho inserito il nome dello Storage Account e la Primary Access Key del mio account di archiviazione di Microsoft Azure. Per maggiori informazioni sugli Azure Storage Account potete visitare il link https://docs.microsoft.com/en-us/azure/storage/storage-create-storage-account

Figura 11: configurazione del Cloud Witness

Dopo aver configurato tutto a dovere 🙂 ho ottenuto una situazione come quella mostrata nella figura sotto:

Figura 12: Creazione del Cluster completata

Storage Spaces Direct

Siamo pronti per abilitare la funzionalità di Storage Spaces Direct (S2D). Ho notato che sia in Hyper-V che in Microsoft Azure i dischi collegati alle macchine riportano come MediaType il valore Unspecified. Storage Spaces Direct utilizza i due valori BusType e MediaType per configurare automaticamente lo storage pool, lo storage tiering e la cache. Infatti lanciando la cmdlet su uno dei nodi del cluster

#Verifica dei dischi collegati

Get-PhysicalDisk CanPool -EQ FT FriendlyName, BusType, MediaType, Size

ottengo il seguente risultato:

Figura 13: verifica dei dischi collegati

Per ovviare a questo problema ho abilitato Storage Spaces Direct lanciando la seguente cmdlet su uno dei nodi del cluster:

#Abilitazione di Storage Spaces Direct

Enable-ClusterS2D -CacheState Disabled -AutoConfig:0 -SkipEligibilityChecks

Rispondete Yes to All al prompt che vi apparirà, come mostrato in figura:

Figura 14: Abilitazione della funzionalità di Storage Spaces Direct

Terminata la configurazione del cluster potreste ricevere un messaggio di avviso, come mostrato in figura:

Figura 15: Abilitazione completata con warning

Se aprite il report potrete verificare che ci sarà soltanto l’avviso relativo ai dischi che non sono stati aggiunti al cluster, in quanto durante la creazione abbiamo specificato il parametro -SkipEligibilityChecks

Figura 16: Warning relativi ai dischi non aggiunti al cluster

Figura 17: Funzionalità S2D abilitata

Dopo aver abilitato la funzionalità di Storage Spaces Direct noterete che nella console del Failover Clustering sono apparsi 2 Enclosures, ognuno dei quali fa riferimento a ogni singolo nodo del cluster:

Figura 18: Enclosure con 1 dischi aggiunti al Cluster S2D

Il passaggio successivo consiste nel creare uno Storage Pool utilizzando i dischi che sono stati aggiunti al cluster attraverso gli Enclosure dei due nodi. Ho creato uno Storage Pool semplicemente eseguendo su uno dei due nodi HV1 oppure HV2 il comando:

#Creazione dello storage pool

New-StoragePool -StorageSubSystemFriendlyName *Cluster* -FriendlyName S2D -ProvisioningTypeDefault Fixed -PhysicalDisk (Get-PhysicalDisk CanPool -eq $true)

Nel mio caso ho scelto di creare uno storage pool utilizzando tutti i dischi disponibili: il risultato è mostrato in figura:

Figura 19: Storage Pool creato con tutti i dischi disponibili

Siamo pronti ora per creare un nuovo volume (da 1 TB), formattarlo REFS e trasformarlo in un Cluster Shared Volume. All’interno del volume CSV andremo poi a salvare tutte le macchine virtuali che creeremo in seguito. Per farlo basta eseguire su uno dei nodi del cluster la cmdlet:

#Creazione del nuovo volume

New-Volume -StoragePoolFriendlyName S2D* -FriendlyName VDisk01 -FileSystem CSVFS_REFS -Size 1TB

Il risultato ottenuto è quello mostrato in figura:

Figura 20: Volume da 1TB creato nel Cluster S2D

Se volete potete modificare il percorso predefiniti per il salvataggio delle macchine virtuali, eseguendo su uno dei due host HV1 oppure HV2 la seguente cmdlet:

#Modifica dei percorsi di deafult per il salvataggio delle VM

Set-VMHOST –Computername HV1,HV2 –Virtualharddiskpath ‘C:\ClusterStorage\Volume1’

Set-VMHOST –Computername HV1,HV2 -VirtualMachinePath ‘C:\ClusterStorage\Volume1’

Test del cluster Hyper-Convergente

Per testare il cluster basta utilizzare la console del Failover Cluster Manager per creare una nuova VM altamente disponibile. Ho lanciato il wizard di configurazione della nuova VM, ho inserito come percorso del salvataggio della VM il CSV creato prima e non ho avuto problemi a terminare le altre configurazioni.

Figura 21: Creazione della VM altamente disponibile

Terminato il wizard di configurazione avrete una VM altamente disponibile, che sarà visualizzata come ruolo del Cluster.

Figura 22: Nuova VM creata all’interno del cluster S2D

Provando a spegnere uno dei due nodi, nel mio caso ho spento il nodo chiamato HV2, il cluster continua a funzionare e la macchina virtuale rimane accesa.

Figura 23: Anche con un nodo spento la macchina continua a funzionare

Conclusioni

Creare un cluster Hyper-V con 2 nodi ed utilizzare la nuova funzionalità Storage Spaces Direct ci permette di creare una infrastruttura iperconvergente altamente performante e scalabile, massimizzando l’utilizzo dell’hardware. Semplicemente collegando i due nodi con schede di rete a 10 GBit abbiamo semplificato di molto la creazione del cluster e le configurazioni necessarie per renderlo operativo.

Per approfondire le configurazioni presentate in questo articolo potete visitare le pagine

Buon lavoro!

Nic

Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier

Prima di implementare una Certification Authority (CA) occorre pianificare attentamente la infrastruttura della Public Key Infrastructure (PKI) più adatta alla propria organizzazione. La prima valutazione che occorre fare è quella del numero di CA necessarie valutando le il grado di sicurezza necessario per la PKI, le necessità di alta disponibilità e il carico amministrativo necessario per la gestione.

Una CA in ambiente Windows può essere di tipo Standalone, che non richiedere l’integrazione con Active Directory, ma più complessa da amministrare in quanto non consente l’utilizzo dei modelli di certificato. In alternativa è possibile avere CA di tipo Enterprise che devono essere integrate in Active Directory, ma la cui gestione è più semplice grazie ai modelli di certificato.

Inoltre le CA si suddividono ancora in Root CA o Subordinate CA. Le Root CA sono in cima alla catena dei certificati e rilasciano i certificati alle Subordinate CA. Dal momento che il primo obbiettivo durante la pianificazione di una PKI è quello di preservarne la sicurezza evitandone la compromissione, una struttura PKI che ben si concilia con tali esigenze di sicurezza con carico amministrativo di gestione non elevato è quella Two-Tier (a due livelli) riportata nel seguente schema che verrà utilizzato come scenario di esempio.

La Root CA viene mantenuta normalmente spenta di conseguenza è preferibile che non sia integrata in Active Directory di conseguenza dovrà essere Standalone e non Enterprise, mentre la Subordinate CA a cui verrà demandano il compito di rilasciare i certificati sarà di tipo Enterprise per beneficiare dell’utilizzo dei modelli di certificato e dell’integrazione con Active Directory.

Come riportato in Optimizing the Revocation Experience conviene però gestire la Certificate Revocation List (CRL) solo tramite HTTP anziché tramite LDAP configurando un server web che si occuperà della pubblicazione evitando di assegnare tale ruolo alla Subordinate CA per ragioni di sicurezza soprattutto nel caso in cui la CRL debba essere pubblicata in Internet:

“Although AD DS enables publication of CRLs to all domain controllers in the forest, we recommend implementing HTTP instead of LDAP for revocation information publication. Only HTTP enables the use of the ETag and Cache-Control: Max-age headers providing better support for proxies and more timely revocation information. In addition, HTTP provides better heterogeneous support as HTTP is supported by most Linux, UNIX, and network device clients.”

Per ulteriori informazioni si vedano:

Installazione e configurazione del server web per la distribuzione della CRL

Prima di procedere all’installazione delle CA occorre provvedere a installare e configurare il server web che si occuperà di pubblicare la CRL e i certificati delle CA necessari nei casi in cui i certificati distribuiti non contengano la catena dei certificati.

Il server web che pubblicherà la CRL può essere un server in Workgroup per il quale è stato configurato un record DNS di tipo A relativo all’Hostname e un record DNS di tipo CANAME per evitare l’URL della CRL che sarà contenuto all’interno di ogni certificato faccia riferimento all’hostname del server sia per consentire la configurazione dell’alta disponibilità della CRL che per ragioni di sicurezza in modo da evitare di diffondere informazioni sull’infrastruttura interna.

Nello scenario di esempio saranno creati i seguenti record DNS:

Nome Tipo record DNS Valore
web01

A

10.0.0.40
crl

CNAME

Web01.ictpower.local

Aggiungere sul server il ruolo Web Server (IIS) con le impostazioni di default.

Creare una cartella dedicata a contenere le CRL e i certificati delle CA che saranno poi pubblicati dal server web, per sicurezza creare tale cartella in disco dedicato diverso dal disco di sistema. Nello scenario di esempio verrà creata la cartella CertEnroll sul volume S:. Creare sul server web un account locale che non sia membro di alcun gruppo locale a cui condividere tale cartella in scrittura, tale account verrà poi utilizzato dalle CA per caricare le CRL e i certificati delle CA in modo che il server web li possa pubblicare. Nello scenario di esempio verrà creato un account CAUser.

Configurare in IIS una Virtual Directory nel Default Web Site che punta alla cartella S:\CertEnroll con accesso anonimo, nello scenario di esempio la Virtual Directory sarà denominata CertEnroll. Per configurare l’accesso anonimo alla Virtual Directory aggiungere gli utenti ANONYMOUS LOGON e Everyone nel tab Security che per default avranno i privilegi di accesso in lettura.

Configurare delle Regole di Filtro per la Virtual Directory per consentire il double escaping per evitare che il carattere “+” che è contenuto nel URI delle delta CRL venga bloccato, a riguardo si veda AD CS: Web server should allow URI containing the “+” character to enable publishing of delta CRLs:

“The certificate revocation list (CRL) distribution point extension on this certification authority (CA) includes a URI for a remote Web server. If the Web server is running IIS 7.0 with the default configuration, then delta CRL URIs that contain the plus sign (+) will be blocked.

Request filtering in Internet Information Services (IIS) scans the content of incoming requests, which can be blocked or allowed to meet the requirements of an organization’s security policy. In IIS 7.0, the default request filtering configuration blocks requests that include the plus sign (+) in the URI. The plus sign (+) is present in the URI of delta CRLs and must be allowed by the Web server.”

Riavviare IIS tramite Internet Service Manager o tramite il comando:

iisreset /restart

Per pubblicare la CRL e il Certificato della CA non è possibile utilizzare HTTPS a riguardo si vedano i post How to Publish the CRL on a Separate Web Server (di Carol Bailey dipente Microsoft) e Designing CRL Distribution Points and Authority Information Access locations (Vadims Podāns Microsoft MVP Cloud and Datacenter Management).

“Certificate revocation lists cannot be accessed over HTTPS so to add HTTP access to one of your Internet-based site system servers would greatly increase the risk of an attacker connecting to this server.”

“NEVER use HTTPS protocol for CRT/CRL file retrieval, because CryptoAPI will permanently fail to fetch this URL.”