Tutti gli articoli di Roberto Massa

RDS Gestione del Numero di Sessioni Utente Concorrenti

Facebooktwittergoogle_plusredditlinkedin

Normalmente in RDS ogni singolo utente che accede al servizio dispone di una singola sessione, quindi, rieseguendo un secondo accesso, la prima sessione verrà disconnessa.

In alcuni scenari di utilizzo, questo comportamento può essere un limite, si pensi ad ambienti dove l’autenticazione avviene a livello applicativo e l’accesso al Sistema è necessario esclusivamente per avviare l’applicazione.

In un contesto di questo genere è possibile modificare il comportamento di Default tramite una GPO di Macchina da applicare sui sistemi dell’infrastruttura RDS che ospitano il ruolo Session Host

La GPO che determina questo comportamento è in

  • Computer > Modelli Amministrativi > Componenti di Windows > Servizi Desktop Remoto > Host Sessione Desktop Remoto > Connessioni
  • Impostare “Limita gli Utenti di Servizi Desktop remoto a una sola sessione di Servizi Desktop remoto” a Disabilitato.


Conversione Fisico/Virtuale per mezzo di Disk2Vhd di un sistema con bios UEFI

Facebooktwittergoogle_plusredditlinkedin

 

Il tool Disk2Vhd permette agevolmente la conversione di sistemi fisici in VM pur non essendo un vero e proprio strumento di conversione.

Nei vari scenari affrontati, la conversione di sistemi legacy XP,2003 etc. può essere necessaria ( anche se ormai questi sistemi sono fuori supporto ).

Anche con sistemi operativi più recenti W7,10,2012 può essere necessario effettuare la conversione di installazioni fisiche.

Nel caso in cui queste siano in installate su HW con Bios UEFI, la conversione con Disk2Vhd, e la successiva creazione della VM non consentono al sistema un avvio corretto e la VM rimane inaccessibile con lo schermo completamente nero.

Figura 1 avvio fallito dopo la conversione del disco di sistema

 

Se ci si trova in questa situazione è sufficiente seguire alcuni passaggi per consentire il corretto avvio del sistema operativo.

Per prima cosa è necessario montare il disco convertito e verificare le partizioni esistenti, quasi certamente si vedrà un’organizzazione del disco simile a quella della figura sotto, ossia con un disco di tipo GPT ed una serie di partizioni che precedono la partizione di sistema vera e propria.

Nota. Per effettuare le operazioni descritte qui sotto possibile utilizzare numerosi tool, Free, OpenSource ed a pagamento, personalmente ho utilizzato Aomei Partition Assistant nella versione Free scaricabile dal sito

 

Figura 2 conversione VHDx

 

A questo punto è sufficiente effettuare la conversione del disco da GPT a MBR

 

Figura 3 Conversione ad MBR del disco

Successivamente, dopo aver applicato le modifiche, è necessario rimuovere tutte le partizioni che precedono quella di sistema ( chiaramente questa operazione dovrà essere valutata caso per caso se fossero presenti altre partizioni contenenti dati )

Figura 4 rimozione partizione

Ed al termine applicare, anche in questo caso le modifiche

 

 

A questo punto è possibile smontare il disco e creare una VM ( Gen1 ) con questo disco come disco principale.

 

La VM non sarà ancora avviabile, pertanto dovremo inserire un disco della versione di Sistema che è contenuta nel VHD ed avviare le procedure di ripristino, è da notare che possono esserci leggere differenza tra le varie versioni. ( in questo esempio un ripristino di un sistema W7)

Successivamente accedere al prompt comandi e con l’utility DISKPART eseguire i comandi di attivazione della partizione

 

  • diskpart
  • list disk
  • select disk 0
  • list partition
  • select partition 1
  • active
  • exit

Figura 5 impostazione della partizione attiva

 

e, dopo un ulteriore riavvio è necessario eseguire la ricostruzione delle componenti di boot con i comandi

 

  • bootrec /fixmbr
  • bootrec /fixboot

 

ed infine eseguire

  • bootrec /RebuildBcd

in modo da eseguire la scansione delle installazioni presenti sul disco e ricostruire l’archivio di configurazione di avvio…

 

Rilevazione degli errori di Assegnazione Siti ad Aree in IE impostati tramite Group Policy (Event ID 1805)

Facebooktwittergoogle_plusredditlinkedin

 

In Internet Explorer è la Sicurezza del browser è strutturata in 4 aree Internet / Intranet Locale / Siti Attendibili / Siti Con Restrizioni, per ognuna di queste aree è possibile la gestione delle impostazioni di sicurezza in modo indipendente.

 

Figura 1 Aree di Sicurezza di IE

L’appartenenza di un determinato sito ad un’area avviene inserendo direttamente l’url del sito all’interno di un elenco impostato nel browser (elenco che è disponibile per ogni area)

Figura 2 Assegnazione di un Sito ad un’Aera

Nella dichiarazione di un sito è possibile utilizzare caratteri jolly ed i vari nomi ma con una serie di vincoli. E’ anche possibile dichiarare un singolo indirizzo ip ( 10.0.0.1) oppure un range di indirizzi ( 10.0.0.1-100).

È inoltre possibile indicare un protocollo specifico per discriminare l’assegnazione ad un’area specifica includendo anche il protocollo stesso.

Nel momento in cui viene introdotto un valore questo viene automaticamente verificato in modo da evitare che il comportamento del browser non sia corretto. Ad esempio se viene impostato https://blogs.technet.microsoft.*com, che non è sintatticamente corretto, viene presentato il seguente messaggio

Figura 3 Warning Relativo ad un Errore Formale di Dichiarazione ( LOCALE )

 

Questo controllo è disponibile quando vengono inseriti i valori all’interno delle impostazioni del browser, in quanto viene effettuata la conversione in chiavi di registro delle impostazioni di IE dal browser stesso.

 

Gestione delle Assegnazioni tramite GPO

Nel momento in cui si effettua la gestione dell’ambiente di sicurezza direttamente dalle GPO, viene perso il controllo sulla correttezza del valore digitato, questo verrà passato al client all’atto dell’elaborazione della GPO, e solo in questo frangente verrà eseguita la conversione del valore impostato nella Group Policy verificandone la correttezza.

Nel caso venga impostato un valore in modo non corretto, e quindi non gestibile dal browser, viene riportato un evento ID 1085 all’interno del registro eventi della postazione.

 

Figura 4 Dichiarazione Errata nella GPO

Figura 5 Event ID 1805 Riportato sulla Postazione

 

Il registro tuttavia non riporta in modo puntuale dove è stato rilevato l’errore, nemmeno leggendo i dettagli dell’evento stesso.

Figura 6 Dettaglio Evento

 

Il livello di dettaglio che possiamo rilevare è nella descrizione dell’errore relativamente alla dicitura “Parametro non corretto”

Anche effettuando una “forzatura” tramite il comando GPUPDATE /FORCE sulla postazione otteniamo un avviso di errore

Figura 7 Comando Gpupdate

Tramite il tool di diagnostica GPRESULT /H <NomeFileDiOutput.html> possiamo ottenere informazioni più circostanziate e precise contenute all’interno del file di output.

A questo punto il report generato dal comando è disponibile nel file html e da qui è possibile verificare quali impostazioni sono state “passate” dalla GPO al client ed approfondire l’indagine.

Figura 8 Report in Formato HTML

Non viene tuttavia indicato quale sia il valore che genera l’errore.

 

IE Zone Analyzer TOOL

Uno strumento ulteriore per la diagnostica dei problemi legati a questo tipo di impostazioni è Zone Map Viewer
che è stato rilasciato ormai da alcuni anni ma ( sebbene non sia disponibile una informazione ufficiale di compatibilità con i sistemi recenti ) è ancora utilizzabile per la rilevazione delle impostazioni del browser.

Questo tool riporta la configurazione attiva sul browser tramite la funzione “Zone Map Viewer”

Figura 9 IE Zone Analyzer TOOL

 

E in dettaglio le impostazioni valide, che per differenza rispetto a quelle impostate tramite la GPO, individuano il settaggio non valido, in questo esempio https://www.bing.*com è il valore che non essendo coerente con i vincoli imposti dal browser, genera l’errore in applicazione della GPO, tramite Zone Analyzer infatti è applicato esclusivamente http://www.google.com

 

 

Figura 10 Report delle Impostazioni Effettivamente Attive

 

 

Riferimenti

https://blogs.msdn.microsoft.com/askie/2016/04/05/description-of-event-id-1085-from-internet-explorer-zonemapping/

https://blogs.technet.microsoft.com/fdcc/2011/09/22/iezoneanalyzer-v3-5-with-zone-map-viewer/

https://blogs.technet.microsoft.com/fdcc/2011/09/22/internet-explorers-explicit-security-zone-mappings/

 

 

 

 

 

 

Pubblicare applicazioni aziendali con Azure Active Directory Application Proxy

Facebooktwittergoogle_plusredditlinkedin

La necessità di rendere utilizzabili al di fuori del perimetro aziendale le applicazioni interne è un’esigenza ormai quotidiana, ma la disponibilità esterna di queste risorse costringe necessariamente chi amministra l’infrastruttura ad “aprire le porte” verso Internet, con tutte le implicazioni dal punto di vista della sicurezza che questo comporta.

Sono state e sono tutt’ora utilizzate una serie di tecniche di mitigazione, ad esempio l’impiego di proxy a reverse con l’utilizzo di sistemi di re-writing degli URL, che consentono una separazione netta delle connessioni in ingresso e forniscono una certa sicurezza sulle risorse esposte.

Questa architettura permette la collocazione in DMZ di sole macchine con il compito di gestire le richieste in ingresso e ridirigerle poi, con alcune regole di controllo all’interno. In questo modo le infrastrutture sensibili non hanno contatto diretto con l’esterno.

Contestualmente a questi accorgimenti l’adozione di sistemi IDS/IPS “garantiscono” un accettabile livello di sicurezza.

In ogni caso questo approccio ha richiesto e richiede che il firewall perimetrale consenta la connessione ed “apra” almeno una porta verso l’interno, richiede anche che i vari apparati posti a controllo del perimetro siano costantemente aggiornati e verificati

Azure Active Directory Application Proxy

In Microsoft Azure è disponibile un servizio che si lega in modo stretto con Azure Active Directory e che in maniera concettualmente del tutto nuova permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda.

Questo servizio è Azure Active Directory Application Proxy, disponibile con la versione BASIC o PEMIUM di Azure Active Directory.

Per poter utilizzare la funzione di Application Proxy, dal portale di Azure è sufficiente, selezionata la Directory di riferimento, attivare la funzionalità in prova valida per 30 giorni e successivamente terminata la fase di test, effettuarne l’acquisto.

Figura 1: Abilitazione servizi AAD Premium

Figura 2: Attivazione di Azure AD Premium P2 Trial

Attivata la funzionalità di Azure AD Premium è necessario installare il componente Application Proxy Connector. La scelta più corretta è quella di dedicare un sistema server a questa funzione, scelta che permette una migliore scalabilità delle risorse e di gestione.

Figura 3 Download componente Connector

Per configurare correttamente regole di uscita dell’Application Proxy è utile la lettura del documento Attività iniziali del proxy di applicazione e installazione del connettore

Mentre per un controllo diretto ed una verifica puntuale della configurazione è disponibile il tool Azure Active Directory Application Proxy Connector Ports Test Tool

È anche possibile permettere che il Connector interno utilizzi per collegarsi ad Azure un Web Proxy , questo qualora non fosse possibile agire direttamente sul Firewall per definire regole puntuali di uscita.

In questo caso è bene considerare che un possibile malfunzionamento del Web Proxy stesso si ripercuoterebbe necessariamente sulla raggiungibilità delle applicazioni.

L’aspetto interessante, relativo alla sicurezza del sistema, è che NON è richiesto che in ingresso venga definita alcuna regola sul Firewall.

L’applicazione che è utilizzata esternamente sarà disponibile tramite il portale Azure e sarà la componente Application Proxy che si occuperà di renderla accessibile e di “dialogare” con il Connector interno, che è la sola componente ad avere contatti con l’applicazione in rete locale.

Per analogia con il sistema tradizionale a Reverse Proxy il Connector è un Reverse Proxy, con la sola ma importante differenza che questo, come detto sopra, non ha contatti con l’esterno ma riceve e reindirizza le richieste dalla componente cloud.

Figura 4: Principio di funzionamento di Azure Active Directory Application Proxy

A questo punto è evidente che l’infrastruttura di sicurezza Aziendale può essere “alleggerita” in quanto come già detto non è richiesto che siano attivate porte in ascolto, questo compito è demandato ad Azure.

Pubblicazione di una applicazione interna tramite Azure AD Application Proxy

Dal portale di Azure selezionare la directory in cui si è abilitata la funzione e successivamente selezionare Configura un’app

Figura 5: Aggiunta dell’applicazione on-premises da esporre

Nella maschera successiva scegliere “Add your own on-premises application”

Verrà così proposta una ulteriore videata con le specifiche proprie dell’applicazione che si intende pubblicare

  • Nome serve ad identificare l’applicazione all’interno del portale di accesso e di configurazione
  • URL interno è l’effettivo URL che il connettore installato on premise contatterà (di norma l’Url dell’applicazione interna)
  • URL Esterno è il riferimento
    pubblico per la raggiungibilità dell’applicazione interna, nel caso si usi un dominio Custom, questo è selezionabile dalla casella
  • Metodo di Autenticazione Preliminare è effettivamente la modalità con cui gli utenti accederanno all’autenticazione dell’applicazione.

Con la modalità Azure AD l’utente verrà effettivamente autenticato con i servizi di Azure e quindi beneficiando anche di quelle che sono le prerogative di questi utenti: gestione Self-Service della password, possibilità di definire criteri di sblocco personalizzati, accesso da dispositivi con determinate caratteristiche etc.

Con la modalità Passtrough invece, all’utente viene proposto direttamente (se previsto) il login dell’applicazione interna.

Nel caso in cui sia impostata la modalità Azure AD e l’applicazione (tipicamente legacy) non sia in grado di utilizzare di questa modalità, verrà richiesta una seconda autenticazione.

A questo punto è possibile accedere all’applicazione, è da notare che di default tutto il traffico è in HTTPS e viene utilizzato un certificato generato per il nome host definito.

Tuttavia, siccome si possono anche gestire URL esposti in Azure con FQDN del proprio dominio pubblico è possibile effettuare l’upload di un certificato aziendale.

Controllo delle funzionalità del Connector Gateway

Questo oggetto non ha particolari opzioni di configurazione, all’atto dell’installazione, viene richiesto un account amministratore globale della directory e con questo il gateway si registra ed autentica sulla directory stessa.

È possibile all’interno del registro eventi rilevare eventuali errori o anomalie archiviate in AadApplicationProxy (fig.6)

Sono anche disponibili, al fine di valutare le performance di questo servizio alcuni Performance Counters (fig.7)

Figura 6: Contatori disponibili per la verifica delle performance del servizio

Figura 7: Aggiunta dei contatori

Considerazioni relative agli aspetti di sicurezza

Controllo tramite NMAP delle informazioni deducibili tramite un port SCAN

Al di là delle considerazioni espresse in precedenza, un piccolo e sicuramente approssimativo test relativo agli aspetti legati alla sicurezza è stato condotto utilizzando NMAP.

Tramite questo tool si è cercato di identificare il sistema operativo sul quale l’applicazione è installata.

Sono stati effettuati due TEST distinti, il primo verso una applicazione esposta in modo tradizionale FWàRev-ProxyàApplicazione

Figura 8: Scansione verso l’esposizione con Reverse Proxy tradizionale

Nmap seppure con una certa approssimazione ha rilevato un host Linux fig. sopra

Ed il secondo sempre verso la stessa applicazione ma esposta tramite AZURE con la struttura descritta sopra

Figura 9 Scansione verso l’esposizione con Azure Application Proxy

Nmap non è riuscito ad identificare il sistema verso il quale ha fatto la scansione.

Conclusioni

Partendo dall’assunto che non esiste LA soluzione perfetta, sicura e garantita e vista anche la velocità di implementazione e il discreto grado di sicurezza by-default dell’infrastruttura, la soluzione di Azure Application Proxy può essere un valido aiuto alle realtà che necessitano di rendere fruibili le proprie applicazioni all’esterno del perimetro aziendale.

Riferimenti:

Azure Application Proxy Connector

Azure Application Proxy Connector – connessione tramite proxy interno

Risoluzione dei problemi relativi alla pubblicazione di applicazioni tramite Azure

Sicurezza

Credssp vulnerabilità descritta in CVE-2018-0886

Facebooktwittergoogle_plusredditlinkedin

 

A partire da marzo 2018 secondo questo bollettino di sicurezza viene risolta la vulnerabilità relativa al Credential Security Support Provider protocol (CredSSP)

Con l’aggiornamento di sicurezza di maggio, installato sui vari sistemi che accedono in RDP ad un server non aggiornato, può essere visualizzato il seguente messaggio di errore

20180510-Credssp-Error

in quanto le seguenti KB

  • KB4103718 (Windows 7 Service Pack 1, Windows Server 2008 R2 Service Pack 1)
  • KB4103725 (Windows 8.1/Windows Server 2012R2)
  • KB4103726 (Windows Server 2012)
  • KB4103727 (Windows 10 version 1709)
  • KB4103723 (Windows 10 Version 1607, Windows Server 2016)

“forzano” client ad effettuare un collegamento in RDP esclusivamente verso server su cui sono state installate le patch di sicurezza rilasciate a marzo 2018 che risolvono la vulnerabilità.

l’evento è anche rilevabile sul client dove si è ottenuto l’errore, consultando il registro eventi di Sistema e rilevando l’error ID 6041 LSA

20180510-Credssp-Error-EventvWr

Con l’aggiornamento di sistema viene introdotta una chiave registry che è possibile modificare al fine di accedere ai server non ancora aggiornati, e per i quali risulta difficoltosa l’installazione della patch.

Essendo necessario un riavvio, la sua esecuzione può non essere immediata

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
“AllowEncryptionOracle”=dword:00000002

E’ fortemente consigliato di utilizzare il workaround riportato sopra esclusivamente per il tempo necessario alla completa applicazione delle patch lato server.

 

 

Riferimenti:

https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

https://blogs.technet.microsoft.com/askpfeplat/2018/05/07/credssp-rdp-and-raven/

https://blogs.technet.microsoft.com/yongrhee/2018/05/09/after-may-2018-security-update-rdp-an-authentication-error-occurred-this-could-be-due-to-credssp-encryption-oracle-remediation/

 

 

 

 

 

Watchguard Autenticazione Accesso su Active Directory

Facebooktwittergoogle_plusredditlinkedin

La gestione delle autenticazioni in un ambiente aziendale è utile in quanto consente in modo centralizzato di consentire ai vari utenti di accedere alle varie risorse anche per un limitato periodo di tempo.

In questo scenario Active Directory, in quanto repository centralizzato di utenti può essere utilizzato anche come sorgente di autenticazione per dispositivi quali Firewall, apparati di rete ed altro.

In questo articolo analizziamo come è possibile configurare Watchguard in modo che utilizzi l’Active Directory centralizzata al fine di definire utenti che possono effettuare l’amministrazione del Firewall stesso, oppure, sempre tramite AD consentire l’accesso tramite VPN SSL definite sul Watchguard.

Definizione delle sorgenti di autenticazione

Tramite l’accesso di gestione per mezzo del portale Web ( https://”ip-delFirewall”:8080) dal menù Authentication/Servers è possibile la scelta tra una serie di sorgenti di autenticazione, nel nostro caso utilizzeremo Active Directory.

Figura 1 Selezione Sorgente di Autenticazione su AD

A questo punto selezionando Active Directory procederemo con ADD e successivamente dovremo fornire le varie informazioni relative al dominio, o meglio ad un Domain Controller Primario e ad un DC secondario che verrà usato come alternativa in caso di indisponibilità del primario, dovremo poi specificare la “Search Base” relativa all’LDAP, è possibile specificare una particolare OU di ricerca per gli utenti.

I campi Group String e Login Attribute specificano le informazioni relative all’account di accesso sull’AD ( nel nostro esempio sono utilizzati i valori di dafault), è poi possibile specificare anche se la connessione avverrà tramite il protocollo LADP(s) ossia in modalità cifrata.

Figura 2 definizione del riferimento al Dominio di autenticazione

Se per ragioni di configurazione il FireBox non raggiungesse un DNS a conoscenza del dominio locale, è possibile specificare l’indirizzo IP dell’Domain Controller anziché il suo FQDN.

Proseguendo si procede al salvataggio della sorgente di autenticazione per il dominio, è comunque possibile definire più di un riferimento di autenticazione in modo da permettere ad utenti differenti di accedere tramite lo stesso dispositivo.

Verifica della configurazione

Terminato il salvataggio è possibile effettuare un test delle impostazioni, dove verranno richiesti utente/password di un account presente in AD

Figura 3 test dell’autenticazione su AD

Figura 4 risultato autenticazione corretta

Definizione dei permessi di accesso in VPN ad utenti AD

A questo punto si può procedere con l’attribuzione dei permessi di accesso in VPN SSL ad utenti residenti su Active Directory , con le impostazioni definite prima l’accesso avviene secondo l’appartenenza di un utente ad un gruppo definito in modo puntuale su AD, nel nostro esempio il gruppo i chiama SSLVpnAdmins

Figura 5 attivazione servizio VPN SSSL

Figura 6 impostazione del Gruppo e del server di autenticazione

Nelle impostazioni relative all’autenticazione, dovremo definire il gruppo AD sulla base del quale è consentito l’accesso agli utenti e dovremo anche configurare il server di autenticazione impostato in precedenza.

Figura 7 impostazione del nome gruppo

Nella figura 7 è riportata la modalità con cui è possibile definire il nome del gruppo che, in relazione al server di autenticazione verrà poi ricercato in Active Directory

Terminate le configurazioni viste sopra è possibile autenticarsi al Firebox direttamente al Portale Vpn Ssl con le credenziale definite su Active Directory è necessario in fase di accesso selezionare il dominio AD di riferimento nella forma.

Figura 8 accesso portale VPN

Definizione dei permessi di amministrazione del Firebox

Sempre sulla base delle autenticazioni analizzate in questo articolo è possibile fare si che determinati utenti di AD possano anche essere, o avere ruoli di amministrazione sul Firewall, i vari ruoli sono accessibili dal menù System/Users and Roles da cui è possibile attribuire i vari ruoli sulla base di un determinato utente dichiarato in Active Directory

Figura 9 definizione dei ruoli di gestione

Figura 10 impostazione del nome utente

Utilizzo di Azure DNS per la validazione automatica di Let’s Encrypt

Facebooktwittergoogle_plusredditlinkedin

In ICTPower ci siamo occupati a più riprese della Certification Authority Let’s Encrypt, ed abbiamo visto come è possibile utilizzarla in diversi scenari.

In Ambienti OpenSource, con la validazione basata su Apache, In un altro articolo abbiamo proposto lo scenario che si può utilizzare con IIS come base per la validazione.

In questo articolo vediamo quali sono le modalità di validazione per il rilascio ed il rinnovo dei certificati sulla base di ambienti DNS, in questo modo è possibile utilizzare un servizio DNS, anche in hosting, per la gestione del ciclo di vita dei certificati gestiti da Let’s Encrypt. Le procedure proposte si basano sul client Win-Acme (WACS) e quindi in ambiente Windows.

Let’s Encrypt utilizza, analogamente a quanto visto per la validazione tramite servizi WEB, un’automazione che provvede a gestire determinati record all’interno del DNS.

Figura 1 Validazione tramite servizio DNS generico

Nella figura 1 è riportato un esempio di come Win-Acme, tramite le opzioni avanzate, permette di utilizzare il DNS per la validazione.

Nell’esempio sopra Win-Acme ricerca uno script a cui passare “hostname, record name e token“, e se opportunamente eseguito interagisce con il servizio DNS in modo da “scrivere” all’interno queste informazioni che lette dalla CA prima del rilascio del certificato, attestano che il richiedente è il reale proprietario del dominio.

E’ quindi chiaro che la disponibilità da parte del fornitore del servizio DNS ad una gestione automatizzata è fondamentale.

Nel panorama Italiano, Aruba non permette questo tipo di automazione (almeno da richiesta fatta al supporto tecnico nel mese di febbraio 2018), ma come vedremo in seguito questo non è necessariamente un limite.

Esistono diversi gestori di servizi DNS che rilasciano nelle gallery relative alle automazioni, script nati per far interagire i client CertBot con il loro DNS in modo da automatizzare le richieste verso Let’s Encrypt.

La maggioranza delle automazioni finora sono relative ad ambienti Linux.

Nel nostro caso utilizziamo invece Azure-DNS per la validazione da parte della CA, non ci occuperemo di come effettuare la delega al servizio Azure della risoluzione per il dominio, questa attività è trattata in dettaglio in questo articolo e si presuppone sia già stata effettuata.

Prima di procedere con la richiesta del certificato vero e proprio è necessario configurare il servizio Azure-DNS in modo che permetta l’accesso ad un “utente” con le credenziali minime per poter creare e cancellare record all’interno del Database DNS.

Questa tipologia di accesso è possibile con la creazione di un Service Principal Account
che possiamo definire come una identità di livello applicativo.

     Assign permissions to the app identity that are different than your own permissions. Typically, these permissions are restricted to exactly what the app needs to do.

Per poter creare una identità di questo tipo possiamo utilizzare Azure Powershell e con l’utilizzo di alcune command let procedere alla sua creazione, l’accesso all’ambiente PS avviene direttamente dal portale Azure

Figura 2 accesso alla Cloud Shell

La preparazione dell’ambiente non è immediata e può richiedere anche più di un minuto, terminato l’accesso, disponiamo di un ambiente comandi direttamente sulla sottoscrizione.

Per procedere alla creazione del Principal account che verrà utilizzato per l’automazione è sufficiente utilizzare questi comandi

$Password = ConvertTo-SecureString -String “InserireQuiLaPassword” -AsPlainText -Force

New-AzureRmADServicePrincipal -DisplayName LetsEncrypt -Password $Password

Figura 3 creazione del service principal

In questo modo è stato creato l’account “Letsencrypt” con la relativa password ed è necessario assegnare i permessi di accesso alla zona DNS relativa al dominio per il quale stiamo richiedendo il certificato

Figura 4 attribuzione dei permessi

Accedendo alla gestione della zona robimassa.cloud tramite Access Control (IAM) si attribuisce il ruolo di DNS Zone Contributor al Service Principal Letsencrypt creato in precedenza.

La preparazione dell’ambiente relativo al servizio DNS è completata e prima di procedere alla generazione del certificato è utile recuperare alcune informazioni che saranno poi richieste dal client Win-Acme.

  • Tenant ID (directory ID) ossia l’identificativo della Directory a cui ci stiamo riferendo
  • Client ID l’identificativo del Service Principal creato prima
  • Secret la password definita per il Principal
  • DNS Subscription ID l’identificativo del Servizio DNS in questo caso (robimassa.cloud)
  • DNS Resource Group Name il resource group definito per la risorsa DNS pubblica

In questa guida si fa riferimento al dominio robimassa.cloud, forse è superfluo specificarlo, ma il dominio DEVE essere un dominio pubblico regolarmente raggiungibile e quindi acquistato tramite i normali canali commerciali, nello specifico questo dominio è stato acquistato da Aruba.

Generazione del certificato

Il client Win-Acme dovrà essere eseguito con l’opzione –centralsslstore in modo da permettere l’archiviazione dei certificati (SAN o singolo Host) all’interno di una cartella, questo è necessario nel nostro caso in quanto i certificati rilasciati non vengono associati in automatico ad un Host Web, ma sono archiviati per un utilizzo successivo.

letsencrypt.exe –centralsslstore C:\letsencrypt-san\

vengono richieste a questo punto le impostazioni di base che sono quelle viste in figura 1 ad eccezione della validazione, per la quale dovremo selezionare l’opzione 1 ossia [dns-01] Azure DNS

Figura 5 richiesta validazione su Azure DNS

Proseguendo dovremo fornire le indicazioni relative all’accesso automatico del client come riportato sopra, ed al termine completata l’esecuzione, verranno salvati i certificati nella directory.

Figura 6 richiesta certificato

A questo punto il certificato è correttamente salvato in formato pfx e disponibile ad essere utilizzato, può ancora essere definito un utente con cui verrà eseguita periodicamente la task di rinnovo.

Se fosse necessario verificare i certificati emessi è possibile, sempre client Win-Acme la procedure di verifica.

Figura 7 verifica dei certificati emessi

Riferimenti

Configurare e gestire Azure DNS

Facebooktwittergoogle_plusredditlinkedin

Nella varietà di scelta tra i servizi disponibili all’interno di Azure troviamo il servizio DNS, in realtà non è un vero e proprio servizio offerto come registrar, in quanto non permette la registrazione di un dominio, ma permette di operare come server delegato.

Per poter registrare un qualunque dominio, dovremo, come fatto finora, riferirci ad un operatore di mercato, presso il Nic è disponibile un elenco di Aziende che operano come Registrar a livello italiano.

Le varie Aziende che operano in questo settore mettono a disposizione i vari servizi di registrazione.

Normalmente viene anche messo a disposizione un pannello tramite il quale è possibile gestire i vari record riferiti al dominio.

Abbiamo già detto che Azure in questo contesto opera come “delegato” ossia vengono reindirizzate le varie query sui DNS server a fronte di una esplicita delega sul Name Server principale per mezzo della definizione di un NS record secondo la RFC 1035.

Apparentemente questa configurazione può apparire inutile ed effettivamente non sempre è necessario o utile attivare i Name server di Azure in delega. Tuttavia alcune necessità, come ad esempio l’automazione richiesta da Let’s Encrypt per la validazione sulla base DNS, possono richiedere che l’aggiunta, la cancellazione o la modifica di record possano avvenire in modo automatico.

Quindi se il registrar presso il quale abbiamo registrato il nostro dominio non avesse queste funzionalità, possiamo utilizzare Azure-DNS in quanto servizio completamente automatizzabile.

Nell’esempio utilizzato per questo articolo deleghiamo i Name Server di Azure per la risoluzione del dominio robimassa.cloud ospitato presso Aruba

Creazione della zona delegata su Azure

Dalla creazione risorse è necessario scegliere DNS zone

Figura 1 creazione zona delegata su Azure DNS

Nel campo nome è necessario specificare il nome completo del dominio, specificare la sottoscrizione di riferimento ed eventualmente il nome del resource group da creare per la risorsa DNS. Nel caso di una zona su cui sarà necessario definire script di automazione è possibile creare un resource group dedicato in modo da “confinare” la risorsa.

Figura 2 creazione zona delegata su Azure DNS

Terminata la configurazione della zona DNS è possibile procedere alla creazione dei vari record già presenti nel servizio “principale” in modo da non creare interruzioni nella risoluzione dei nomi quando verrà attivata la delega.

Figura 3 creazione dei record relativi al dominio

Sono anche disponibili le informazioni relative ai name server da impostare per la delega sul DNS principale che dovranno poi essere usate successivamente.

A questo punto la nuova zona delegata è pronta ed è sufficiente procedere con la configurazione dei record NS su name server del Registrar.

Configurazione del Record NS sul portale del Registrar

Il dominio robimassa.cloud è stato registrato tramite Aruba che ne è quindi il registrar e tramite il quale è possibile gestire i vari record. La prima impostazione è relativa a quale è il name server principale per la zona e quindi per attivare la delega è necessario impostare l’uso di name server esterni.

Figura 4 pannello di gestione del DNS per robimassa.cloud

E successivamente dovranno essere creati i vari record NS secondo le informazioni ricavabili dal servizio Azure-DNS per la zona robimassa.cloud

Figura 5 impostazione record NS

A questo punto, atteso il tempo di replica tra i vari DNS globali le nuove informazioni ed impostazioni diventano operative

Figura 6 verifica delega con Nslookup

Nel caso in cui sia necessario delegare la gestione del dominio DNS sarà sufficiente creare un utente e successivamente attribuire i permessi minimi sul servizio

Figura 7 definizione accesso al servizio

Controllo delle attività sulla zona DNS

Accedendo ad “Activity Log” è possibile consultare tutte le attività eseguite sulla zona

Figura 8 consultazione Log

Riferimenti

Azure Dns Prezzi

Informazioni generali su Azure DNS