Archivi categoria: guida

Rinominare un dominio di Active Directory

Facebooktwittergoogle_plusredditlinkedin

È possibile rinominare un dominio Active Directory? La risposta è affermativa ma spesso sottovalutata. A seconda delle dimensioni del dominio da rinominare, questa azione si può rivelare un incubo anche per il sysadmin più esperto: nel caso di procedura errata il rischio di bloccare un utente o di dover rifare le operazioni di join di una macchina al dominio è elevatissimo.

Contestualmente esistono numerosissime applicazioni incompatibili con tali attività.

Nel caso in cui foste costretti ad intraprendere questa strada, Microsoft ha rilasciato una lunga checklist che, se compresa e verificata attentamente, facilita di molto l’attività in oggetto.

Punti critici

Prima di prendere in considerazione l’azione di cambio nome, è necessario sapere che:

  • Il livello funzionale della foresta deve essere almeno Windows Server 2003;
  • Exchange Server 2003 è l’unico che supporta questa procedura;
  • Dopo aver rinominato il dominio è verranno rinominati anche i nomi degli host joinati;
  • In caso di foresta con domini figli, a seguito del cambio di nome e quindi di posizione del domain controller padre, sarà necessario ricreare le relazioni di trust affinché possano parlarsi nuovamente;
  • Le zone DNS dovranno essere create manualmente per il nuovo dominio;
  • Ogni membro del dominio deve essere riavviato due volte a seguito dell’aggiornamento del domain controller;
  • Il suffisso DNS dei membri del dominio rinominato potrebbe non essere corretto per un certo periodo di tempo. Di solito questa configurazione DNS viene aggiornata automaticamente in caso di modifiche al dominio. Il periodo di tempo per il quale potrebbe non essere corretto è proporzionale alle dimensioni del dominio.

Applicazioni non compatibili

  • Microsoft Exchange 2000
  • Microsoft Exchange 2007
  • Microsoft Exchange 2010
  • Microsoft Internet Security and Acceleration (ISA) Server 2004
  • Microsoft Live Communications Server 2005
  • Microsoft Operations Manager 2005
  • Microsoft SharePoint Portal Server 2003
  • Microsoft Systems Management Server (SMS) 2003
  • Microsoft Office Communications Server 2007

Preparazione ed esecuzione

Come prima cosa, assicuriamoci che la feature Remote Server Administration Tools sia installata.

Figura 1: Server Manager – Roles and features

Dobbiamo rinominare il dominio da contoso.local a laboratorio.local.

Predisponiamo, nel DNS primario, la nuova zona per il dominio:

Figura 2: DNS Manager – Creazione nuova zona

Figura 3: DNS Manager – Wizard – Tipo di zona

Figura 4: DNS Manager – Wizard – Replication scope

Figura 5: DNS Manager – Wizard – Nome zona

Figura 6: DNS Manager – Wizard – Gestione aggiornamenti

Figura 7: DNS Manager – Wizard – Riepilogo

Rimuoviamo l’associazione DNS con il vecchio dominio

Figura 8: DNS Manager – Rimozione zona

Figura 9: DNS Manager – Rimozione zona

Successivamente, da una macchina a dominio utilizzando il domain admin, eseguiamo una shell elevata ed eseguiamo il comando

rendom /list

Figura 10: Command line – Download XML

Il risultato sarà la generazione di un file xml, nel path dove viene eseguito il comando, che dovremo modificare

Figura 11: Modifica delle configurazioni

Modifichiamo ii nomi DNS e NetBios con quelli desiderati, nel mio caso:

Figura 12: XML – Modifica delle configurazioni

Verifichiamo le informazioni del dominio con il comando

rendom /showforest

Figura 13: Command line – Verifica configurazioni

Effettuiamo l’upload con il comando

rendom /upload

Figura 14: Command line – Upload

Verifichiamo che il dominio sia pronto ad effettuare il processo di ridenominazione con il comando

rendom /prepare

Figura 15: Command line – Preparazione ridenominazione

Eseguiamo la procedura con il comando

rendom /execute

Figura 16: Command line – Esecuzione

A questo punto il domain controller viene riavviato in maniera automatica.

A seguito del riavvio verifichiamo che la procedura sia andata a buon fine

Figura 17: Server Manager – Verifica dominio

Diverse configurazioni relative al nuovo nome dovranno essere eseguite a mano:

Figura 18: System Properties – Hostname errato

Il Full computer name del DC deve essere cambiato a mano. Per effettuare la ridenominazione, eseguire il comando

netdom computername LabDC.contoso.local /add:LabDC.laboratorio.local

Figura 19: Command line – Modifica hostname

Seguito dal comando

netdom computername LabDC.contoso.local /makeprimary:LabDC.laboratorio.local

Figura 20: Command line – Modifica hostname

Riavviamo il server, successivamente verifichiamo che sia stato rinominato correttamente

Figura 21: System Properties – Verifica hostname

Apriamo la console delle GPO

Cliccando sul nuovo nome configurato notiamo che punta ancora al vecchio dominio

Figura 22: Group Policy Management – Errore

Per correggere questo problema utilizziamo il comando

gpfixup /olddns:contoso.local /newdns:laboratorio.local

Figura 23: Command line – Fix GPO

seguito da

gpfixup /oldnb:CONTOSO /newnb:LABORATORIO

Figura 24: Command line – Fix GPO

A questo punto è necessario riavviare almeno due
volte tutti i server joinati al vecchio dominio in modo che recepiscano i cambiamenti avvenuti con la ridenominazione. Riavviare due volte assicura che ogni computer recepisca il cambio di dominio e propaghi a tutte le applicazioni le modifiche necessarie.

Attenzione: Il riavvio deve essere effettuato dopo aver fatto login sulla macchina. In caso di Power off e successivo avvio la procedura non funzionerà.

Una volta assicurati che tutti i membri del dominio siano allineati, proseguiamo con i comandi

rendom /clean

Figura 25: Command line – Pulizia dei riferimenti al vecchio dominio

infine

rendom /end

Figura 26: Command line – Termine delle configurazioni

In questo modo verranno rimossi i riferimenti al vecchio dominio.

Verifichiamo che lato DNS siano stati creati i record correttamente

Figura 27: DNS Manager – Verifica zona

Exchange

In caso di ridenominazione di AD con versioni di Exchange non supportate, sarà necessario creare una nuova foresta, installare nuovamente Exchange ed effettuare una migrazione dei contenuti esistenti.

Maggiori informazioni possono essere recuperate qui.

Una possibile soluzione in caso di Exchange incompatibile è registrare un nuovo dominio e creare delle regole di redirect in modo che le email inviate al vecchio dominio vengano inoltrate automaticamente ai nuovi indirizzi. In questo modo si evitano impatti agli utenti i quali utilizzeranno esclusivamente il nuovo indirizzo di posta.

Conclusioni

Con la dovuta attenzione ed una corretta analisi è possibile rinominare un dominio AD. In alcune situazioni attività del genere sono preferibili al rifacimento dell’intera infrastruttura ma se affrontate nel modo sbagliato possono diventare un incubo.

Per fortuna Microsoft fornisce tutte le informazioni necessarie per affrontare questa attività in sicurezza.

Implementare una VPN site-to-site in Azure con Veeam PN

Facebooktwittergoogle_plusredditlinkedin

Quando un’organizzazione decide di adottare servizi offerti da cloud pubblici si trova spesso a dover affrontare la sfida di interconnettere in modo sicuro e gestito utenti e servizi della propria rete con le risorse ospitate nel cloud.

Tipicamente, questo scenario implica mettere in conto i costi del servizio VPN offerto dal vendor del cloud pubblico e il dover configurare un appliance locale seguendo indicazioni e prescrizioni in termini di compatibilità legate a tale servizio.

Ad esempio, nel caso di Microsoft Azure, realizzare una VPN site-to-site prevede la disponibilità nella propria rete locale di un dispositivo VPN “convalidato” (vedi https://docs.microsoft.com/it-it/azure/vpn-gateway/vpn-gateway-about-vpn-devices).

Talvolta potrebbe essere necessario dover collegare una o più sedi della nostra organizzazione a virtual machine o applicazioni che abbiamo collocato su Azure non disponendo però del numero o del tipo di apparati necessari, oppure non essendo possibile alterare la configurazione di quelli esistenti…

In questo articolo vedremo come creare una VPN fra la rete locale aziendale e una subnet in Azure utilizzando il componente gratuito Veeam PN realizzato da Veeam Software (https://www.veeam.com).

Veeam Powered Network (PN)

Veeam PN è un tool di Software Defined Networking (basato su una distro Linux Ubuntu 16.04.1 LTS) che consente di creare in maniera molto semplice e lineare tunnel VPN fra reti aziendali (“site-to site”) o fra un client e la rete aziendale (“point-to-site”).

Si basa sulla tecnologia OpenVPN (https://openvpn.net/index.php/open-source/333-what-is-openvpn.html) la cui implementazione è semplificata da un’interfaccia web che permette di applicare intuitivamente configurazioni e politiche amministrative.

Si può scaricare, previa registrazione gratuita, da qui: https://www.veeam.com/cloud-disaster-recovery-azure-download.html

Il download consiste in un file .ova di circa 1 Gb.

Nota: I file .ova sono “pacchetti” che contengono descrizioni e informazioni di certificazione relative ad una macchina virtuale (nel nostro caso l’appliance Veeam PN) che possono agilmente essere importate in ambiente VMware.

Come anticipato, Veeam PN può aiutarci (e possiamo dire che il tool sia nato proprio per questo scopo) nel creare connessioni protette verso nostre risorse collocate in Azure risolvendo il problema di dover modificare la configurazione di apparati VPN esistenti in conformità con le specifiche indicate da Microsoft:

  • VPN site-to-site, fra una o più sedi della nostra organizzazione ed una nostra subnet in Azure;
  • VPN point-to-site, fra uno o più client ed una nostra subnet in Azure.

Figura 1 – Scenari di implementazione di Veeam PN

Il ruolo svolto da Veeam PN, e quindi la relativa configurazione, dipende dalla collocazione nell’architettura:

  • Network Hub: gestisce il traffico fra la rete che offre i servizi e le reti o i client che devono accedervi in modo protetto; nel nostro schema il ruolo Network Hub di Veeam PN è collocato in Azure.
  • Site Gateway: stabilisce il tunnel VPN fra la rete che offre i servizi ed una rete remota; nel nostro schema, il ruolo Site Gateway è collocato on-premise.

Per consentire ad un singolo computer di accedere ad una rete gestita dal ruolo Network Hub, occorre installare sul PC Windows o Linux il client OpenVPN (https://openvpn.net/index.php/open-source/downloads.html). Per OS X e MacOS seguire le indicazioni riportate qui: https://openvpn.net/index.php/access-server/docs/admin-guides/183-how-to-connect-to-access-server-from-a-mac.html.

Requisiti di Veeam PN

Per installare l’appliance on-premise si raccomanda di utilizzare VMware vSphere versione 5.x o successive. La virtual machine dovrà disporre di almeno 1 CPU, 1GB di RAM e di un disco thin-provisioned di 4 GB. Per fare qualche sperimentazione è anche possibile utilizzare VMware Workstation o Virtual Box, ma non se ne raccomanda l’impiego in produzione.

Per installare l’appliance in Azure, dovremo prevedere una virtual machine almeno di dimensioni A1 (1 core, 1,75GB di RAM, 70 GB di spazio disco.

L’amministrazione di Veeam PN si effettua via browser: le versioni più recenti di Internet Explorer, Edge, Firefox, Chrome sono tutte supportate.

Informazioni sui requisiti e le indicazioni relative all’installazione del client OpenVPN sono disponibili qui: https://openvpn.net/index.php/open-source/documentation/install.html.

Porte utilizzate da Veeam PN:

Da Verso Protocollo Porta
Site Gateway Network Hub TCP/UDP 1194
Computer client Network Hub TCP/UDP 6179
Browser Network Hub o Site Gateway HTTPS 443

Installazione del ruolo Network Hub

Il primo ruolo di Veeam PN da installare è quello di Network Hub su Azure.

Una volta fatto accesso alla sottoscrizione Azure sulla quale abbiamo privilegi amministrativi, selezionare l’opzione Create a Resource e, nella casella di testo, digitare veeam pn, poi premere Invio.

Figura 2 – Create a Resource

Nei risultati della ricerca, fare clic su Veeam PN for Microsoft Azure.

Figura 3 – Veeam PN for Microsoft Azure, trovato!

Nella pagina successiva, fare clic su Create.

Figura 4 – Avvio creazione risorsa

Viene presentata la prima delle schede di configurazione della virtual machine che ospiterà il network appliance.

Fornire un nome per la virtual machine, un nome ed una password per l’account amministrativo, selezionare la sottoscrizione Azure in cui collocare la risorsa, decidere se utilizzare un Resource Group esistente (ma privo di risorse) o se crearne uno ad hoc e la regione Azure in cui desideriamo operare.

Infine, clic su OK.

Figura 5 – Informazioni di base

Nella scheda Veeam PN Settings:

  • Selezionare la dimensione della virtual machine: una Standard A1 può essere sufficiente per sperimentazioni o piccoli carichi di lavoro; in produzione si raccomanda di selezionare almeno una Dv2;
  • Specificare o creare uno Storage Account in cui verrà creato il disco della virtual machine;
  • Dare un nome univoco alla virtual machine;
  • Selezionare la Virtual Network a cui l’appliance sarà connesso (tipicamente la stessa Virtual Network in cui si trovano le risorse che dovranno essere raggiunte tramite VPN) e la relativa Subnet;
  • Fare clic su OK.

Figura 6 – Veeam PN Settings

Nella scheda successiva, Security Settings, selezionare la lunghezza della chiave di cifratura adottata per la generazione del canale sicuro e fare clic su OK.

Figura 7 – Security Settings

Nella scheda VPN Information è possibile selezionare le funzionalità con cui sarà configurato l’appliance Veeam PN e quindi stabilire se sarà possibile consentire connessioni site-to-site o point-to-site o entrambe. È anche possibile specificare protocolli e porte non di default. I valori predefiniti sono UDP 1194 per le connessioni site-to-site e UDP 6179 per le connessioni point-to-site.

Effettuate le scelte, fare clic su OK.

Figura 8 – VPN Information

Nella scheda Summary, dopo una verifica finale dei parametri impostati, è possibile fare clic su OK.

Figura 9 – Summary

Nella scheda successiva fare clic su Create.

Il processo di creazione delle risorse e della macchina virtuale dura pochi minuti.

Figura 10 – Fasi della creazione appliance Veeam PN

Configurazione del ruolo Network Hub

Al termine della creazione della macchina virtuale Veeam PN, è necessario effettuare alcune configurazioni preliminari.

Dal portale amministrativo di Azure, fare clic su Virtual Machines, poi sul nome della macchina virtuale Veeam PN appena creata per visualizzarne le proprietà.

Figura 11 – Indirizzo pubblico appliance

Annotare il Public IP Address (nel nostro caso 40.127.163.70), avviare un browser e connettersi via https.

Effettuare il login con le credenziali amministrative specificate al momento della creazione della virtual machine.

Figura 12 – Login

Nella scheda Azure Setup, fare clic su Next.

Figura 13 – Avvio wizard

Veeam PN richiede che ci si autentichi su Microsoft Azure Active Directory. Copiare il codice di autenticazione fornito e accedere al link indicato nella scheda.

Figura 14 – Codice di autenticazione (CTRL+C)

Incollare il codice nella casella di testo della pagina Web e, se il codice fornito risulta corretto, fare clic su Continua.

Figura 15 – Codice di autenticazione (CTRL+V)

Qualora richiesto, selezionare l’account corrente o specificarne uno diverso che abbia accesso alla sottoscrizione Azure.

Figura 16 – Conferma account

Tornare alla pagina di configurazione di Veeam PN e fare clic su Next.

Figura 17 – Il wizard prosegue

Al termine della configurazione automatica, fare clic su Finish.

Figura 18 – Azure setup completato

Configurazione dell’accesso dalla rete remota

È ora necessario consentire l’accesso al Veeam PN con il ruolo Network Hub da parte del Veeam PN con il ruolo Site Gateway che sarà installato e configurato successivamente.

Nella pagina principale del portale amministrativo di Veeam PN, fare clic su Clients.

Figura 19 – Portale amministrativo Veeam PN

Fare clic su Add.

Figura 20 – Aggiunta client

Nella scheda Add Client selezionare l’opzione Entire
Site e fare clic su Next.

Figura 21 – Opzione Entire Site

Specificare un nome identificativo e la subnet (nel formato CIDR) a cui appartengono gli host on-premise che dovranno connettersi ad Azure tramite VPN. Poi fare clic su Next.

Figura 22 – Informazioni sulla subnet on-premise

Nella scheda di riepilogo, fare clic su Finish.

Figura 23 – Completamento aggiunta client

Viene proposta la finestra di dialogo per il salvataggio del file (.xml) di configurazione che sarà poi necessario importare durante la configurazione del Veeam PN con il ruolo di Site Gateway.

Salvare il file in una posizione successivamente accessibile.

Nel portale amministrativo di Veeam PN è ora presente la rete che abbiamo appena definito come client.

Figura 24 – Conferma dell’aggiunta client

Installazione del ruolo Site Gateway

Passiamo ora a configurare Veeam PN on-premise per poter connettere con un tunnel VPN la rete aziendale ad Azure.

Collocare il pacchetto .ova scaricato dal sito Veeam (https://www.veeam.com/cloud-disaster-recovery-azure-download.html) in una posizione accessibile dall’ambiente VMware.

Per istruzioni dettagliate su come effettuare il deployment di un template OVA in ambiente vSphere: https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-AFEDC48B-C96F-4088-9C1F-4F0A30E965DE.html

Figura 25 – Package OVA caricato in vSphere

Qui https://spaces.uncc.edu/display/CKB/Importing+OVA+File+into+VMware+Workstation+14 una guida su come procedere utilizzando invece VMware Workstation (scenario consigliato unicamente nel caso di laboratori o sperimentazioni).

Completato il deployment del pacchetto .ova, dal client vSphere o dalla console di VMware Workstation, ricavare l’indirizzo IP dell’appliance Veeam PN (nel nostro caso 192.168.1.94) e accedervi via browser con le credenziali di default:

  • Utente: root
  • Password: VeeamPN

Figura 26 – Login al Veeam PN on-premise

Viene immediatamente richiesto di cambiare la password di default.

Figura 27 – Cambio password

Nella scheda successiva, Initial Configuration, è possibile scegliere il ruolo che dovrà svolgere questo appliance o se ripristinare la configurazione da un precedente backup.

Nel nostro caso, selezionare l’opzione Site gateway, poiché il ruolo Network Hub è stato precedentemente collocato su Azure, e fare clic su Next.

Figura 28 – Configurazione ruolo

Occorre ora effettuare l’upload del file .xml di configurazione generato durante la configurazione del ruolo Network Hub.

Fare clic su Browse e selezionare il file. Poi fare clic su Finish.

Figura 29 – Completamento configurazione

Dopo qualche secondo, nel portale amministrativo del Veeam PN on-premise viene segnalata l’effettuata connessione con il Veeam PN collocato su Azure.

Figura 30 – Conferma connessione lato on-premise…

Connettersi con il browser al Veeam PN su Azure e verificare che anche da quel lato gli indicatori siano “verdi”,

Figura 31 – …e conferma connessione lato Azure

Test della connessione VPN

Nello schema qui dis eguito, lo scenario oggetto della verifica: il client aziendale appartenente alla sede di Roma (indirizzo IP 192.168.1.246) deve potersi connettere tramite VPN al server AZRSRV01 collocato su Azure (indirizzo IP privato 10.1.0.4).

Figura 32 – Schema scenario da verificare

Nel portale amministrativo di Azure, fare clic su Virtual Machines, poi sulla macchina virtuale Veeam PN. Infine fare clic su Networking. Prendere nota dell’indirizzo IP privato (nel nostro caso 10.1.0.5).

Figura 33 – Rilevamento IP privato appliance Veeam PN su Azure

Accedere al client aziendale collocato nella rete on-premise, aprire una sessione Command Prompt con privilegi amministrativi elevati.

Eseguire il comando:

route -p add x.x.x.x mask y.y.y.y z.z.z.z

Dove:

  • x.x.x.x è l’indirizzo della subnet Azure a cui si desidera accedere
  • y.y.y.y è la relativa Subnet Mask
  • z.z.z.z è l’indirizzo IP del Veeam PN on-premise

Nel nostro caso:

route -p add 10.1.0.0 mask 255.225.255.0 192.168.1.94

Effettuare un tracert verso l’IP privato del Veeam PN su Azure.

Figura 34 – Tracert OK!

Vogliamo ora verificare di poter accedere anche al server collocato nella subnet Azure.

Il server ha come indirizzo privato 10.1.0.4 e non è raggiungibile (per regole di firewall) tramite il suo indirizzo IP pubblico.

Figura 35 – Rilevamento IP privato VM server su Azure

Proviamo ad accedere in RDP al server AZRSRV01 attraverso il suo IP privato 10.1.0.4.

Figura 36 – RDP OK!

WOW!

Instradamento automatico

Si noti che non è stato necessario modificare la routing table del server su Azure, grazie ad uan configurazione effettuata automaticamente dal Veeam PN con il ruolo Network Hub.

Accedere al portale amministrativo di Azure, fare clic su Resource Groups e poi sul nome del Resource Group in cui è stato collocato l’appliance Veeam PN.

Tra i vari elementi presenti, ne è elencato anche uno di tipo Route table.

Figura 37 – Route table creata da Veeam PN

Facendo clic su questo elemento si evidenza come sia stata automaticamente creata una route che inoltra attraverso l’host 10.1.0.5 (il Veeam PN) il traffico indirizzato verso la rete 192.168.1.0/24 (la subnet on-premise).

Tale route è applicata alla subnet su cui sono attestati sia l’appliance Veeam PN che il server AZRSRV01.

Figura 38 – Caratteristiche route table

Magia!

Conclusioni

In questo articolo abbiamo visto, passo per passo, come sia possibile, grazie ad un appliance gratuito realizzato da Veeam, realizzare una VPN site-to-site fra una sede aziendale e una subnet su Azure senza implicare modifiche agli apparati di networking esistenti o dover configurare un VPN Gateway su Azure.

Implementare Azure AD Domain Services

Facebooktwittergoogle_plusredditlinkedin

Gli Azure AD Domain Services permettono di poter aggiungere (joinare) macchine virtuali ad un dominio gestito senza la necessità di distribuire e manutenere i domain controller. Abilitando gli Azure AD Domain Services, verranno create in Azure due macchine virtuali che diventeranno i domain controller del dominio che vorrete creare. Queste due macchine saranno collegate ad una Azure Virtual Network (VNET) e sarà possibile aggiungere computer sia ospitati in macchine virtuali Azure sia ospitati on-premises, se la vostra rete virtuale è collegata in modalità Site-to-Site alla vostra infrastruttura aziendale. Per poter accedere alle applicazioni potrete utilizzare le vostre credenziali di Azure AD.

Sfruttando le funzionalità offerte, sarà possibile utilizzare LDAP, NTLM (NT LAN Manager) e l’autenticazione Kerberos, ampiamente usate nelle aziende, per eseguire la migrazione in Azure di applicazioni legacy compatibili con le directory.

Per abilitare le funzionalità di Azure AD Domain Services è necessario prima avere una directory di Azure AD (sincronizzata con una directory locale oppure solo cloud).

Una volta abilitata la funzionalità di Azure AD Domain Services sarà possibile eseguire i seguenti compiti amministrativi:

  • Aggiungere computer al dominio gestito.
  • Configurare le Group Policy per le unità organizzative (OU) “AADDC Computers” e “AADDC Users” nel dominio gestito.
  • Amministrare il DNS nel dominio gestito.
  • Creare e amministrare unità organizzative (OU) personalizzate nel dominio gestito.
  • Ottenere l’accesso amministrativo ai computer aggiunti al dominio gestito.

Privilegi amministrativi non disponibili in un dominio gestito

Il dominio viene gestito da Microsoft, incluse le attività quali applicazione di patch, monitoraggio ed esecuzione di backup. Il dominio è bloccato e non si hanno privilegi per eseguire alcune attività amministrative. Ecco alcuni esempi di attività che non è possibile eseguire:

  • Non vengono concessi privilegi di amministratore di dominio (Domain Admin) o amministratore dell’organizzazione (Enterprise Admin) per il dominio gestito.
  • Non è possibile estendere lo Schema del dominio gestito.
  • Non è possibile connettersi ai controller di dominio per il dominio gestito usando Desktop remoto.
  • Non è possibile aggiungere controller di dominio al dominio gestito.

Configurazione della directory di Azure

In questo articolo utilizzerò una directory di Azure che utilizza un dominio personalizzato chiamato “demolab.it”. Per aggiungere un dominio personalizzato alla vostra Azure Active Directory potete seguire le indicazioni contenute nell’articolo Aggiungere un nome di dominio personalizzato ad Azure Active Directory

Figura 1: Dominio personalizzato da utilizzare per gli Azure AD Domain Services

Poiché sto utilizzando un Directory esistente, ho anche alcuni gruppi ed alcuni utenti attivi. Agli utenti ho cambiato il logon name (username) in modo tale che utilizzino il dominio personalizzato “demolab.it”.

Figura 2: Utenti già esistenti in Azure AD

Abilitazione della funzionalità di Azure AD Domain Services

Dal portale di Azure scegliete di creare una nuova risorsa di tipo Azure AD Domain Services e scegliete quale sarà il DNS Domain Name che verrà utilizzato per creare il dominio gestito. Come già anticipato, io utilizzerò il dominio “demolab.it”. Indicate la sottoscrizione, il Resource Group e la Location dove creare le risorse.

Figura 3: Scelta del nome di dominio ce dovrà utilizzare Azure AD Domain Services

Nella schermata successiva scegliete a quale Virtual Network vorrete collegare i vostri Azure AD Domain Services ed il dominio gestito. Potete utilizzare una rete esistente oppure crearne una nuova. Nel mio caso ho deciso di creare una nuova rete virtuale.

Figura 4: Creazione di una nuova VNET da utilizzare con gli Azure AD Domain Services

Alla VNET verrà associato anche un Network Security Group, ottimizzato per proteggere gli Azure AD Domain Services.

Figura 5: Scelta della VNET e creazione di un Network Security Group associato

Nel passaggio successivo dovrete aggiungere gli utenti al gruppo AAD DC Administrators, uno speciale gruppo che avrà i privilegi nel dominio gestito che verrà creato. Questo gruppo verrà aggiunto al gruppo Administrators locale di tutte le macchine che verranno aggiunte al dominio gestito, come succede ai Domain Admins in Active Directory on-premises, e potranno connettersi in Desktop remoto alle macchine che verranno successivamente aggiunte (joinate) al dominio gestito.

NOTA: In un dominio gestito con Azure AD Domain Services non ci sono né Domain Admins né Enterprise Admins.

Figura 6: Aggiunta degli utenti al gruppo degli AAD DC Administrators

Controllate le configurazioni e cliccate su OK per completare la creazione degli Azure AD Domain Services. Ci vorranno circa 30 minuti per completare la creazione dei due domain controller.

Figura 7: Configurazione completata

Dopo circa 30 minuti sarà possibile verificare l’avvenuta creazione degli Azure AD Domain Services e sarà possibile aggiornare i DNS della vostra Virtual Network in modo tale che puntino agli indirizzi IP dei due domain controller creati per il dominio gestito. Cliccate su Configure e nel giro di pochi secondi la VNET verrà configurata automaticamente con i due IP da utilizzare per la risoluzione DNS.

Figura 8: Creazione completata e configurazione dei DNS

Infatti, se controllate le configurazioni della VNET vedrete che saranno stati modificati i server DNS.

Figura 9: Modifica dei server DNS della VNET compleltata

Nota: Durante il processo di provisioning, Azure AD Domain Services crea le applicazioni “Domain Controller Services” e “AzureActiveDirectoryDomainControllerServices” all’interno della directory dell’organizzazione. Queste applicazioni sono necessarie per far funzionare il dominio gestito ed è fondamentale che non vengono mai eliminate.

Figura 10: Applicazioni create per la gestione di Azure AD Domain Services

Connessione al dominio gestito

Per utilizzare il dominio gestito e per configurarlo è possibile creare una nuova VM e collegarla alla VNET utilizzata.

Figura 11: Creazione di una nuova VM per gestire Azure AD Domain Services

Terminata la creazione della VM potete collegarvi col le credenziali di amministratore locale che avete indicato al momento della creazione. Se controllate le configurazioni di rete della VM noterete che ha ottenuto i DNS corretti e quindi sarà capace di connettersi al dominio gestito “demolab.it”

Figura 12: La macchina virtuale ha ottenuto le configurazioni di rete corrette e può risolvere il nome del dominio gestito “demolab.it”

Per poter aggiungere la macchina al dominio gestito potete utilizzare le credenziali di un utente del gruppo AAD DC Administrators, come mostrato in figura:

Figura 13: aggiunta della VM al dominio gestito utilizzando le credenziali di un utente membro del gruppo AAD DC Administrators

Per autenticare gli utenti nel dominio gestito, Azure Active Directory Domain Services necessita dell’hash delle password in un formato idoneo per l’autenticazione NTLM e Kerberos. Azure AD non genera o archivia l’hash delle password nel formato necessario per l’autenticazione NTLM o Kerberos finché non si abilita Azure Active Directory Domain Services per il tenant. Per ovvi motivi di sicurezza, Azure AD non archivia nemmeno le credenziali di tipo password in un formato non crittografato. Azure AD quindi non può generare automaticamente questi hash delle password NTLM o Kerberos in base alle credenziali esistenti degli utenti.

Se avete configurato Azure AD per avere account utente solo cloud, tutti gli utenti che devono usare Azure Active Directory Domain Services devono cambiare le proprie password.

Se Azure Ad è sincronizzata con una directory on-premises (per mezzo di Azure AD Connect), è necessario abilitare la sincronizzazione degli hash NTLM e Kerberos per usare il dominio gestito. Fate riferimento all’articolo Abilitare la sincronizzazione password nel dominio gestito per gli account utente sincronizzati con l’istanza locale di AD per abilitare la sincronizzazione degli hash delle password.

Poiché l’utente che sto utilizzando per aggiungere la macchina virtuale al dominio gestito “demolab.it” era già presente in Azure AD (nel mio caso è solo Cloud) prima della creazione degli Azure AD Domain Services, non riesco a joinare la macchina al dominio gestito e ricevo un messaggio di errore (in realtà non chiarissimo).

Figura 14:Messaggio di errore dovuto alla mancanza di un hash delle password in formato corretto

Procedo quindi al cambiamento della password per l’utente admin@demolab.it, che avevo aggiunto al gruppo AAD DC Administrators. Il processo di modifica delle password determina la generazione in Azure AD degli hash delle password richiesti da Azure Active Directory Domain Services per l’autenticazione Kerberos e NTLM. È possibile impostare come scadute le password per tutti gli utenti del tenant che devono usare Azure Active Directory Domain Services oppure richiedere a tali utenti di cambiare le proprie password.

In questo caso mi sono collegato alla pagina https://mypass.microsoft.com e ho cambiato la password dell’utente admin@demolab.it, che stavo utilizzando per joinare la VM al dominio gestito.

Figura 15: Modifica della password dell’utente del gruppo AAD DC Administrators che stavo utilizzando per joinare la VM al dominio gestito

Dopo circa 20 minuti dalla modifica, la nuova password è utilizzabile in Azure Active Directory Domain Services. Ho riprovato ad aggiungere la VM al dominio gestito e questa volta non ho ricevuto nessun errore.

Figura 16: Dopo la modifica della password e l’attesa di qualche minuto, il join al dominio gestito avviene senza problemi

Gestione di Azure AD Domain Services

Adesso che avete aggiunto la VM al dominio gestito potete installare le console per la gestione. Io ho aggiunto la Group Policy Console, tutti gli AD DS Tools ed anche la console per la gestione del DNS.

Figura 17: Aggiunta degli strumento di amministrazione

Come si può vedere nelle schermate successive, è ora possibile amministrare il dominio gestito. Potete utilizzare la console Active Directory Users and Computers, L’Active Directory Administrative Center oppure AD PowerShell.

Figura 18: Console Active Directory Users and Computers e visualizzazione dei Domain Controllers del dominio gestito

Nella OU AADDC Users potrete vedere tutti gli utenti che avere creato in Azure AD (sia che siano solo cloud, sia che siano sincronizzati con Active Directory on-premises). Si può notare che i pulsanti di creazione dei nuovi utenti e dei nuovi gruppi non sono abilitati. La gestione degli utenti dovrà continuare ad essere effettuata da Azure AD.

Figura 19: Utenti del dominio gestito, gli stessi presenti in Azure AD

Per creare un nuovo utente o un nuovo gruppo dovete collegarvi al Portale di Azure e effettuare l’operazione dal nodo Azure Active Directory. Come già detto prima, siate pazienti perché ci vorranno circa 20 minuti per sincronizzare Azure AD con Azure AD Domain Services e per vedere il nuovo utente apparire nella console di Active Directory Users and Computers.

Figura 20: Utenti di Azure AD

Per amministrare il DNS potete invece collegarvi ad uno dei domain controller che sono stati creati nel dominio gestito (recuperate i nomi nella OU dei DC)), come mostrato in figura:

Figura 21: Console di gestione del DNS

È possibile utilizzare la console Group Policy Management nella macchina virtuale aggiunta al dominio per amministrare le Group Policy (GPO) nel dominio gestito, a patto che siate membri del gruppo AAD DC Administrators.

Sono presenti diverse GPO nel dominio gestito, tra cui la Default Domain Policy, AADDC Computers GPO e AADDC users GPO. È possibile personalizzare queste GPO o crearne delle altre. Io ho creato una nuova Organizational Unit (OU) e una nuova Group policy (GPO), come mostrato in figura:

Figura 22: Console di gestione delle GPO del dominio gestito

Conclusioni

Molto spesso in azienda si usano applicazioni che usano LDAP per l’accesso in lettura o scrittura alla directory aziendale oppure usano l’autenticazione integrata di Windows (autenticazione NTLM o Kerberos) per autenticare gli utenti finali. Per spostare le applicazioni locali nel cloud, è necessario risolvere le dipendenze da Active Directory. Spesso gli amministratori adottano una delle soluzioni seguenti:

  • Creano una connessione VPN da sito a sito tra Azure e l’infrastruttura on-premises.
  • Creano un domain controller aggiuntivo dell’Active Directory aziendale in una VM di Azure
  • Creano in Azure un dominio separato, utilizzando una o più VM promosse a domain controller

Tutti questi approcci tuttavia prevedono costi elevati e un carico di lavoro amministrativo significativo. Gli amministratori devono distribuire i controller di dominio tramite macchine virtuali in Azure. In più, devono gestire, proteggere, applicare patch, monitorare, eseguire il backup e risolvere i problemi relativi a tali macchine virtuali. L’utilizzo di connessioni VPN alla directory locale rende i carichi di lavoro distribuiti in Azure suscettibili a errori o interruzioni di rete temporanee.

Azure Active Directory Domain Services è pensata per offrire un’alternativa più semplice.

Utilizzare un server RADIUS per autenticare le connessioni VPN Point-to-Site verso le Azure Virtual Network

Facebooktwittergoogle_plusredditlinkedin

Le connessioni Point-to-Site (P2S) consentono ai computer client di potersi collegare alle reti virtuali in Azure (VNET) ed sono utili per tutti quei telelavoratori che quando sono a casa o sono in trasferta da un cliente hanno necessità di accedere alle risorse su Azure o alle risorse aziendali.

Per accedere anche alle risorse aziendali è necessario però che sia stata configurata anche una connessione Site-to-Site (S2S) tra la Azure VNet e la rete on-premises.

Figura 1: Schema di una connessione Point-to-Site

Gia in passato ho scritto la procedura per Creare una connessione Point to Site in Azure Resource Manager usando Powershell, anche se l’operazione è possibile effettuarla direttamente dal portale di Azure. Per l’autenticazione del client mi sono servito dei certificati digitali, che nonostante offrano un livello di sicurezza maggiore, sono più difficili da gestire.

Da qualche mese è però possibile utilizzare anche un server RADIUS per l’autenticazione degli utenti, a patto che utilizziate un Virtual Network Gateway di tipo VpnGw1, VpnGw2 o VpnGw3.

Quali SKU del gateway supportano la connessione VPN da punto a sito?

SKU Connessioni P2S Benchmark della velocità effettiva aggregata Autenticazione RADIUS VPN da punto a sito IKEv2
VpnGw1 128 650 Mbps Supportato Supportato
VpnGw2 128 1 Gbps Supportato Supportato
VpnGw3 128 1,25 Gbps Supportato Supportato
Basic 128 100 Mbps Non supportato Non supportato

Il server RADIUS potrà trovarsi nella stessa VNET di Azure, ospitato all’interno di una VM, oppure potrà essere contattato tramite una connessione Site-to-Site nella rete on-premises.

La modalità Point-to-Site (P2S) crea una connessione VPN tramite SSTP (Secure Sockets Tunneling Protocol) o IKEv2.

  • SSTP è un tunnel VPN basato su SSL supportato solo nelle piattaforme client Windows. Può penetrare i firewall e per questo è l’opzione ideale per connettersi ad Azure ovunque. Usa solo la porta 443
  • IKEv2 è una soluzione VPN IPsec basata su standard e può essere usato per connettersi da dispositivi Mac (versioni OSX 10.11 e successive). Usa la porta UDP 500 e 4500 e il protocollo IP 50. Molti proxy e firewall bloccano queste porte.

I client supportti sono:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows Server 2016 (64-bit only)
  • Windows 10
  • Mac OS X version 10.11 (El Capitan)
  • Mac OS X version 10.12 (Sierra)
  • Linux (StrongSwan)
  • iOS

Per configurare il Virtual Network Gateway ad utilizzare il server RADIUS per l’autenticazione degli utenti vi basterà selezionare dal portale di Azure il Virtual Network Gateway e nel ramo Point-to-site configuration sarà possibile dichiarare, oltre all’Address Pool da utilizzare, anche quale server RADIUS dovrà essere contatatto per l’autenticazione e lo Shared Secret da utilizzare per connettersi al server RADIUS.

Figura 2: Configurazione della RADIUS Authentication

Per connettersi alla VNET in Azure attraverso al connessione Point-to-Site (P2S) gli utenti dovranno inserire le proprie credenziali di dominio (o credenziali di utenti locali del server RADIUS). È anche possibile integrare un server RADIUS con la Multi-facotr Authentication (MFA) in modo tale da aumentare il livello di sicurezza dell’accesso. Per la configurazione MFa vi rimando alla lettura dell’articolo Integrate your existing NPS infrastructure with Azure Multi-Factor Authentication

Figura 3: Schema di funzionamento dell’autenticazione con server RADIUS on-premises

Configurazione del server RADIUS

Il server RADIUS che ho utilizzato è il Network Policy Server di Windows Server. La configurazione del ruolo è molto semplice e dura pochi secondi. Al termine dell’installazione sarà necessario configurare il server per accettare le connessioni VPN e per autenticarle. Dalla console del Network Policy Server potete effettuare il wizard per la creazione di una Configurazione Standard, come quella mostrata in figura:

Figura 4: Wizard per la creazione di una configurazione per una RADIUS server per le connessioni VPN

Scegliete di configurare una connessione VPN e date un nome alle policy che verranno configurate alla fine del wizard.

Figura 5: Scelta del tipo di connessione e del nome

Nel passaggio successivo inserite i RADIUS Client, cioè il vostro Azure Virtual Network Gateway. Inserite la Gateway Subnet che avete associato al momento della creazione del Gateway e lo Shared Secret che avete configurato nella Point-to-Site configuration.

Figura 6: Configurazione del RADIUS Client

Figura 7: RADIUS Client aggiunto

È possibile utilizzare due tipi di autenticazione con la connessione Point-to-Site (P2S): EAP-MSCHAPv2 ed EAP-TLS. In questo caso ho deciso di utilizzare EAP-MSCHAPv2 e l’ho aggiunto nella pagina degli Authentication Methods, come mostrato in ffigura:

Figura 8: Aggiunta di EAP-MSCHAPv2 agli Authentication Methods

Selezionate il gruppo di utenti che potranno autenticarsi e procedete con il wizard. Io ho creato un gruppo dedicato che possa connettersi alla VNET tramite P2S.

Figura 9: Scelta del gruppo di utenti autorizzati ad autenticarsi tramite VPN

Lasciate invariate le altre configurazioni

Figura 10: Packet filtering per limitare il tipo di traffico

Figura 11: Encryption settings

Figura 12: Realm name

Completate la configurazione facendo clic su Finish.

Figura 13: Configurazione del server RADIUS completata

Download del client di connessione Point-to-Site

Terminata la configurazione del server RADIUS dovete soltanto provare a connettervi. Collegatevi al portale Azure e scaricate il client di connessione, come mostrato in figura, scegliendo anche il protocollo di autenticazione che volete utilizzare. Io ho scelto EAP-MSCHAPv2.

Figura 14: Download del client di connessione P2S

Verrà scaricato un file .zip all’interno del quale troverete gli installer per Windows 32 e 64 bit e per Mac OSx. Procedete all’installazione della connessione per il tipo di sistema operativo che state utilizzando.

Figura 15: Installazione della configurazione del client VPN per la P2S

Terminata la configurazione sarà possibile lanciare la connessione VPN P2S, inserendo le credenziali di un utente che appartenga al gruppo che avete autorizzato nel server RADIUS.

Figura 16: Connessione P2S alla VNET con le credenziali di dominio o locali del server RADIUS

Se volete personalizzare la configurazione del client e se volete aggiungere delle rotte alla connessione VPN (per esempio per raggiungere anche la rete on-premises) vi invito a leggere l’articolo Personalizzare il client di una connessione Point to Site su Azure

Conclusioni

Utilizzare un server RADIUS per autenticare i nostri utenti quando effettuano una connessione Point-to-Site è decisamente facile e vantaggioso, perché sfrutta le credenziali di dominio dell’utente e si può integrare con la Multi-Factor Authentication.

Creare rapidamente laboratori di test per Windows 10, Windows Server 2016 e Windows Server 2019 utilizzando PowerShell

Facebooktwittergoogle_plusredditlinkedin

Da qualche mese è presente su GitHub un progetto Microsoft gratuito che permette con una serie di script PowerShell di configurare rapidamente dei laboratori di test basati su Hyper-V (io ho utilizzato la mia macchina con Windows 10 e con Client Hyper-V per i lab), partendo soltanto dalla ISO di Windows Server 2016 e di Windows 10. È anche possibile testare la versione Insider dei due sistemi operativi ed il prossimo Windows Server 2019.

Si possono creare decine di scenari diversi, alcuni anche complessi, frutto dell’esperienza dei Premier Field Engineer di Microsoft, che li usano proprio per realizzare delle demo per i clienti.

Ho trovato particolarmente facile la creazione dei laboratori con gli script messi a disposizione, visto che in fin dei conti dovevo solo fornire la ISO del sistema operativo da utilizzare e attendere la creazione del lab!

Gli script sono stati realizzati solo per creare alcuni scenari, molti di questi dedicati alle funzioni di Storage di Windows Server, ma offrono la possibilità di essere modificati e quindi possono anche essere adattati alle nostre esigenze.

Collegandosi alla pagina https://github.com/Microsoft/WSLab/tree/master/Scenarios troverete un elenco di scenari che attualmente sono stati sviluppati, ma ne vengono creati sempre di nuovi.

Se invece volete testare le nuove funzionalità della prossima versione di Windows 10 e di Windows Server 2019 potete collegarvi alla pagina https://github.com/Microsoft/WSLab/tree/master/Insider , dove c’è il file di configurazione per creare le macchine del lab utilizzando la ISO del programma Insider.

Nella pagina dei progetti sono anche presenti dei video esplicativi che vi possono aiutare nelle prime fasi, raggiungibili direttamente al link https://github.com/Microsoft/WSLab/#videos

Download dei prerequisiti

Per cominciare abbiamo bisogno di scaricare alcuni prerequisiti fondamentali:

Estraete gli script in una cartella del vostro computer oppure di una macchina virtuale su Azure che supporti la Nested Virtualization, cioè della famiglia Dv3 ed Ev3. Ho già avuto modo in passato di scrivere l’articolo Abilitare la nested virtualization con le nuove Azure VM Dv3 ed Ev3 che citava proprio questa nuova ed utilissima funzionalità.

Figura 1: Estrazione degli script utili per la creazione del laboratorio

Eseguite quindi il file 1_Prereq.ps1 con privilegi amministrativi e scaricate i prerequisiti richiesti, come mostrato in figura, che verranno poi salvati nella cartella Tools:

Figura 2: Download dei prerequisiti richiesti

Al termine del download dei prerequisiti, eseguite con privilegi amministrativi il file 2_CreateParentDisks.ps1. Vi verrà richiesta la ISO di Windows Server 2016 e vi verranno chiesti i file MSU che volete utilizzare per l’aggiornamento dell’immagine. Verranno creati diversi VHDX, con l’installazione di Windows Server 2016 Datacenter Full, Core e Nano. L’operazione dura diversi minuti e i dischi saranno salvati nella sottocartella ParentDisks, che verrà creata dallo script.

Figura 3: Richiesta dei file MSU per aggiornare l’installazione di Windows Server

Figura 4: Creazione dei dischi che verranno utilizzati dalle VM completata

Dopo la creazione dei VHDX, lo script procede in automatico e crea una macchina virtuale dentro la quale verranno installati i ruoli di Domain Controller e di DHCP utilizzando PowerShell Desired State Configuration (DSC). L’operazione dura diversi minuti, quindi siate pazienti 😊
La macchina virtuale creata verrà poi eliminata dalla console di Hyper-V e sarà riutilizzata nel momento in cui creerete il laboratorio secondo lo scenario che avete scelto.

Per ingannare l’attesa potete leggere l’articolo Introduzione a PowerShell Desired State Configuration o gli altri articoli che trattano dello stesso argomento https://www.ictpower.it/?s=PowerShell+Desired+State+Configuration

Figura 5: Installazione del Domain Controller tramite PowerShell Desired State Configuration

Figura 6: esecuzione dello script 2_ CreateParentDisks.ps1 terminata

Figura 7: Il Domain Controller che verrà utilizzato nei laboratori

Terminata l’esecuzione dello script 2_CreateParentDisks.ps1 vi verrà chiesto se volete eliminare i primi 2 script. Rispondente come preferite perché la vostra scelta non inficerà sulla creazione del laboratorio e sui successivi passaggi.

Se volete creare un’immagine di Windows 10 vi basterà lanciare lo script che troverete nella cartella Tools e scegliere la ISO di Windows 10 oppure di Windows 10 Insider, con gli eventuali Update che volete installare (file .MSU). Vi verrà chiesto quale versione di Windows volete installare, come mostrato in figura:

Figura 8: Creazione di un VHDX con Windows 10

Figura 9: Installazione del sistema operativo nel VHDX

Al termine della creazione sarà necessario spostare il VHDX dalla cartella Tools alla cartella ParentDisks.

Figura 10: Spostamento del VHDX di Windows 10 nella cartella ParentDisks

Creazione di un laboratorio utilizzando uno Scenario

Come già anticipato, diversi sono gli scenari che possono essere utilizzati per la creazione dei laboratori e sono tutti visibili al link https://github.com/Microsoft/WSLab/tree/master/Scenarios

In questo articolo utilizzerò lo Scenario S2D and Windows Admin Center, che creerà 6 macchine virtuali. Copiate la configurazione presente nella pagina nella sezione LabConfig and Prerequisites e incollatela nel file LabConfig.ps1, come mostrato in figura. Salvate il file LabConfig.ps1

Figura 11: Modifica della configurazione del file LabConfig.ps1 per adattarlo allo scenario scelto

A questo punto, per creare le macchine virtuali, lanciate lo script Deploy.ps1 (o 3_Deploy.ps1 se non lo avete rinominato). Verrà prima creata la macchina virtuale che ospita il Domain Controller e lo script aspetterà che il servizio di Active Directory sia online prima di procedere alla creazione delle altre VM, che verranno tutte automaticamente joinate al dominio (corp.contoso.com). Nell’attesa che il DC sia online potrete ricevere nello script dei messaggi di errore, ma non preoccupatevene perché questi errori sono “by design”.

Figura 12: Creazione delle VM del laboratorio utilizzando lo script Deploy.ps1

Figura 13: Creazione delle VM completata

Figura 14: Macchine virtuali create in Hyper-V

Le macchine virtuali sono state create. Accendetele e procedete con la configurazione dello scenario scelto. La creazione dell’infrastruttura sarà completata in meno di 5 minuti!

Da questo momento in poi le altre operazioni saranno fatte dall’interno delle VM e potete procedere con la configurazione delle funzionalità di Windows Server. A me interessa, con questo articolo, solo farvi vedere come creare facilmente l’infrastruttura di test e quanto sia facile passare da uno scenario all’altro, seguendo le indicazioni presenti su GitHub https://github.com/Microsoft/WSLab/tree/master/Scenarios

Rimozioni del laboratorio

Se volete rimuovere il laboratorio e tutte le macchine virtuali create, compreso i virtual switch, vi basterà lanciare lo script Cleanup.ps1. Le VM vengono individuate tramite il prefisso che avete deciso nel file LabConfig.ps1 e quindi non c’è possibilità che vengano rimosse altre macchine virtuali presenti nella vostra infrastruttura.

Figura 15: La rimozione del laboratorio viene completata in pochissimi secondi

Conclusioni

Davvero interessante creare dei laboratori di test ed eseguire delle configurazioni particolarmente complesse soltanto lanciando pochissimi script PowerShell e partendo dalla ISO di Windows. Utilissimo per le demo da fare ai nostri clienti, utilissimo per lo studio delle nuove funzionalità, utilissimo per risparmiare tantissimo tempo per i nostri test. Grazie Microsoft!

Introduzione ai Cluster Sets in Windows Server 2019

Facebooktwittergoogle_plusredditlinkedin

I Cluster Sets sono una funzionalità che sarà disponibile il prossimo autunno nella nuova versione di Windows che si chiamerà Windows Server 2019. Si tratta di una tecnologia pensata per poter gestire diversi cluster contemporaneamente, al fine di aumentare la scalabilità orizzontale e di permettere di avere un numero maggiore di nodi del cluster in un singolo Datacenter. Da molti anni si parla infatti di Software Defined Datacenter (SDDC), che altro non sono che una serie di tecnologie che permettono di ottenere prestazioni e configurazioni migliorate grazie al fatto di non dipendere dall’hardware che gestiscono.

Attualmente Windows Server 2019 è in Preview ed è possibile partecipare al programma Insider per poterlo provare in anteprima. Coloro che volessero cimentarsi possono collegarsi all’indirizzo https://insider.windows.com/en-us/for-business-getting-started-server/ e dopo essersi registrati possono scaricare una copia Insider di Windows Server 2019 e di Windows 10.

Dopo aver scaricato la versione più recente di Windows Server Insider Preview dal link https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver potete cominciare fin da subito a testarne le nuove funzionalità.

Io utilizzerò in questo articolo la Build 17709 di Windows Server 2019 che è stata rilasciata un paio di giorni fa e mi servirò, per configurare il mio laboratorio, di una serie di script presenti al link https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

È presente su GitHub un progetto Microsoft che consiste in una serie di script utili a configurare dei laboratori di test basati su Hyper-V (io ho utilizzato la mia macchina con Windows 10 e con Client Hyper-V per i lab), partendo soltanto dalla ISO di Windows Server e di Windows 10 e creando decine di scenari diversi, alcuni anche complessi (come quello che descriverò in questo articolo).

Scenario

Poiché Windows Server 2019 Cluster Sets servirà a gestire diversi cluster di Windows Server e ad amministrare alcune VM che gireranno nei cluster, è necessario creare un ambiente di laboratorio complesso. In questo ambiente verranno creati tre cluster (Member Clusters) configurati con Storage Spaces Direct (S2D), di cui ho già parlato nell’articolo Implementare Storage Spaces Direct in Windows Server 2016 con Microsoft Azure, in cui verranno distribuite delle macchine virtuali ed un cluster di gestione (Management Cluster) che si occuperà di gestire il Cluster Set Namespace SOFS, uno Scale-Out File Server dove verranno ospitate le VM.

Figura 1: Schema di funzionamento di Windows Server 2019 Cluster Sets

Uno degli obiettivi di Windows Server 2019 Cluster Sets è infatti quello di aumentare la scalabilità dei cluster che ospitano le VM e di fare in modo che cluster piccoli vengano raggruppato in una infrastruttura più grande. Le VM potranno essere spostate da un cluster ad un altro se è necessario fare della manutenzione o addirittura dismettere alcuni cluster, perché alla fine del ciclo di vita dell’hardware.

Figura 2: Le VM vengono posizionate su uno dei nomi dei diversi cluster e vengono memorizzate in uno Scale-Out File Server

Figura 3: Effettuare la manutenzione e la rimozione di un intero cluster diventa un’operazione molto semplice

Creazione del laboratorio di test

Dopo aver scaricato l’ultima build di Windows Server 2019 da https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewserver (la funzionalità Cluster Sets funziona solo con Windows Server Insider Preview build 17650 e successive), collegatevi alla pagina https://github.com/Microsoft/WSLab e scaricate gli script per la creazione del lab. Seguite dettagliatamente tutte le istruzioni riportate (ci sono anche dei video esplicativi).

Estraete gli script in una cartella e procuratevi il file di configurazione che sarà necessario per il laboratorio dei Cluster Sets dal link https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

Figura 4: File necessari alla realizzazione del laboratorio

Modificate il file Labconfig.ps1 con il contenuto dello scenario che volete realizzare, come mostrato in figura:

Figura 5: Modifica del file Labconfig.ps1 con le configurazioni dello scenario da realizzare

Eseguite quindi il file 1_Prereq.ps1 con privilegi amministrativi e scaricate i prerequisiti richiesti, come mostrato in figura:

Figura 6: Download dei prerequisiti

Al termine del download dei prerequisiti eseguite con privilegi amministrativi il file 2_CreateParentDisks.ps1. Vi verrà richiesta la ISO di Windows Server 2019 e verranno creati due VHDX, uno con l’installazione di Windows Server 2019 Datacenter Full ed uno con l’installazione di Windows 2019 Datacenter Core. L’operazione dura diversi minuti e i due dischi si troveranno nella sottocartella ParentDisks, che verrà creata dallo script.

Figura 7: Esecuzione dello script 2_CreateParentDisks.ps1

Figura 8: Creazione dei due VHDX completata

Dopo la creazione dei VHDX, in automatico verrà creata una macchina virtuale dentro la quale verranno installati i ruoli di Domain Controller e di DHCP. L’operazione dura diversi minuti.

Figura 9: Creazione e configurazione della macchina virtuale che farà da Domain Controller

Alla fine della configurazione del Domain Controller sarà presente una cartella con la macchina virtuale creata. Il Domain controller potrà essere riutilizzato tutte le volte che volete, se desiderate provare scenari di laboratorio diversi, disponibili al link https://github.com/Microsoft/WSLab/tree/master/Scenarios .

Figura 10: Esecuzione dello script 2_CreateParentDisks.ps1 completata

Figura 11: Creazione del Domain Controller completata

Creazione delle VM da utilizzare nel laboratorio per Cluster Sets

Terminati i prerequisiti è ora possibile passare alla creazione delle VM che saranno utilizzate nel laboratorio. Eseguite lo script Deploy.ps1, che utilizzerà le configurazioni presenti nel file Labconfig.ps1. Modificate il file Labconfig.ps1 con il contenuto dello scenario che volete realizzare. Trovate lo scenario per la creazione e configurazione dei Cluster Sets al link https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

Figura 12: Esecuzione dello Script Deploy.ps1

Dopo qualche minuto, saranno automaticamente create le 10 VM necessarie al nostro lab! Avviatele e aspettale il completamento della prima accensione. Le macchine sono state aggiunte al dominio corp.contoso.com, creato dal lab.

Figura 13: Esecuzione dello Script Deploy.ps1 completata

Figura 14: Creazione delle VM necessarie al lab di Windows Server 2019 Cluster Sets

Collegatevi ora alla macchina WSLabInsider17709-DC (il Domain Controller del laboratorio) con le credenziali che si trovano nel file Labconfig.ps1 (corp\LabAdmin con relativa password LS1setup!) e dall’interno della VM eseguite lo script PowerShell che si trova alla pagina https://github.com/Microsoft/WSLab/tree/master/Scenarios/S2D%20and%20Cluster%20Sets

Lo script provvederà ad installare sulle VM tutte le funzionalità richieste. Procuratevi un VHDX che verrà utilizzato per creare le macchine virtuali che gireranno nel Cluster (sotto forma di Nested VMs). Io ho usato Windows 2016 Nano Server, che non richiede troppe risorse. Durante l’esecuzione dello script vi verrà chiesto di fornire il percorso dove avete copiato il VHDX da usare come immagine master per le Nested VM e poi proseguirà tutto in maniera automatica. Verranno così creati i quattro Cluster richiesti dal nostro scenario (3 Member Cluster ed un Management Cluster). Fantastico!

Figura 15: Creazione dei Cluster dall’interno della VM WSLabInsider17709-DC

La creazione dei 3 cluster (Cluster1, Cluster2 e Cluster3) richiede diversi minuti e qualche riavvio, soprattutto a causa dell’installazione di Hyper-V all’interno delle VM del lab. Il quarto cluster, quello di Management, verrà creato in seguito.

Se dal Domain Controller lanciate la console del Failover Cluster Manager potrete amministrare i tre Cluster creati. Un avviso però vi consiglia di utilizzare Windows Admin Center, la console di management gratuita che è stata rilasciata qualche mese fa e di cui abbiamo parlato nell’articolo Windows Server 2019 e Windows Admin Center: le novità previste per il prossimo autunno

Figura 16: Console di Failover Cluster Manager e Windows Admin Center

Figura 17: Cluster creati dallo script di configurazione

Figura 18: Macchine virtuali creati nei nodi del Cluster

Potete scaricare Windows Admin Center dal link https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/understand/windows-admin-center. Io ho scaricato la versione Windows Admin Center Preview 1806, ma ho dovuto installarla su un’altra macchina perché non è possibile installarla su un Domain Controller.

Figura 19: Gestione del cluster effettuata dal Windows Admin Center

Creazione del Management Cluster

Il Management Cluster in un Cluster Set si occupa di rendere altamente disponibili le funzionalità che servono a gestire l’intero Cluster Set e il referral SOFS per il Cluster Storage Namespace. In più è completamente distinto dai diversi Member Server che si occupano di far girare le macchine virtuali. Per creare il Management Cluster (che chiameremo MgmtCluster) nel nostro laboratorio è sufficiente lanciare dal Domain Controller i seguenti comandi PowerShell:

$ClusterName=“MgmtCluster”
$ClusterIP=“10.0.0.220”
$ClusterNodes=1..3% {“Mgmt$_}
Invoke-Command -ComputerName $ClusterNodes -ScriptBlock {
Install-WindowsFeature -Name “Failover-Clustering”
}
New-Cluster -Name $ClusterName -Node $ClusterNodes -StaticAddress $ClusterIP

Successivamente eseguite il comando New-ClusterSet -name “MyClusterSet” -NamespaceRoot “MC-SOFS” -CimSession “MgmtCluster” -StaticAddress “10.0.0.221” per creare il Cluster Set Master su “MgmtCluster”.

Il Cluster Set Master si occuperà di coordinare le comunicazioni tra i diversi Member Cluster ed è anch’esso un ruolo altamente disponibile. In più verrà creato il Root Namespace chiamato MC-SOFS che sarà poi utilizzato per puntare alle condivisioni di rete SOFS offerte dai diversi nodi dei Member Cluster.

Figura 20: Management Cluster e relativi ruoli installati

A questo punto è necessario aggiungere i Member Cluster da gestire (Cluster1, Cluster2 e Cluster3) utilizzando il comando PowerShell

Add-ClusterSetMember -ClusterName Cluster1 -CimSession MyClusterSet -InfraSOFSName CL1-SOFS
Add-ClusterSetMember -ClusterName Cluster2 -CimSession MyClusterSet -InfraSOFSName CL2-SOFS
Add-ClusterSetMember -ClusterName Cluster3 -CimSession MyClusterSet -InfraSOFSName CL3-SOFS

Figura 21: Ruoli aggiunti al Cluster1 relativi al Cluster Set

In questo modo le condivisioni di rete sono tutte visibili dal percorso \\MC-SOFS

Figura 22: Tutte le condivisioni di rete offerte dal Member Cluster sono visibili dal percorso \\MC-SOFS

Spostamento delle VM nel Root Namespace

Adesso che abbiamo creato il Cluster Set è necessario spostare le VM che erano già ospitate dai Member Cluster, utilizzando la Storage Live Migration. Potete spostare tutte le VM con un semplice script ma nel nostro laboratorio la partenza e la destinazione dei dischi delle VM coincidono e per questo motivo utilizzeremo un workaround che semplicemente spegnerà le macchine, le rimuoverà mantenendo le configurazioni, cambierà il percorso dei dischi e ri-registrerà le VM nel Cluster.

$ClusterSet=“MyClusterSet”
$ClusterSetSOFS=“\\MC-SOFS”

#Grab all VMs from all nodes
$VMs=Get-VM -CimSession (Get-ClusterSetNode -CimSession $ClusterSet).Name

<# does not work
#perform storage migration to \\MC-SOFS
foreach ($VM in $VMs){
$NewPath=($vm.path).Replace(“c:\ClusterStorage”,$ClusterSetSOFS)
$VM | Move-VMStorage -DestinationStoragePath $NewPath
}
#>

#remove VMs and import again, but from \\MC-SOFS
#Shut down VMs

$VMs Stop-VM

#Remove VMs from cluster resources

Foreach ($VM in $VMs){
Remove-ClusterGroup -Cluster $VM.ComputerName -Name $VM.name -RemoveResources -Force
}

#remove VMs and keep VM config

Foreach ($VM in $VMs){
invoke-command -computername $VM.ComputerName -scriptblock {
$path=$using:VM.Path
Copy-Item -Path $path\Virtual Machines” -Destination $path\Virtual Machines Bak” -recurse
Get-VM -Id $Using:VM.id Remove-VM -force
Copy-Item -Path $path\Virtual Machines Bak\*” -Destination $path\Virtual Machines” -recurse
Remove-Item -Path $path\Virtual Machines Bak” -recurse
}
}

#Import again, but replace path to \\MC-SOFS

Invoke-Command -ComputerName (get-clustersetmember -CimSession $ClusterSet).ClusterName -ScriptBlock{
get-childitem c:\ClusterStorage -Recurse Where-Object {($_.extension -eq ‘.vmcx’ -and $_.directory -like ‘*Virtual Machines*’) -or ($_.extension -eq ‘.xml’ -and $_.directory -like ‘*Virtual Machines*’)} ForEach-Object -Process {
$Path=$_.FullName.Replace(“C:\ClusterStorage”,$using:ClusterSetSOFS)
Import-VM -Path $Path
}
}

#Add VMs as Highly available and Start

$ClusterSetNodes=Get-ClusterSetNode -CimSession $ClusterSet
foreach ($ClusterSetNode in $ClusterSetNodes){
$VMs=Get-VM -CimSession $ClusterSetNode.Name
$VMs.Name ForEach-Object {Add-ClusterVirtualMachineRole -VMName $_ -Cluster $ClusterSetNode.Member}
$VMs 
Start-VM
}

Figura 23: Posizione del disco PRIMA della Storage Migration

Figura 24: Posizione del disco DOPO la Storage Migration

Abilitazione della Kerberos Authentication per permettere la Live Migration

Per far in modo tale che le VM possano essere spostate accese da un nodo ad un altro è necessario abilitare la Kerberos Authentication su tutti i nodi dei Member Cluster, come ben documentato dall’articolo Set up hosts for live migration without Failover Clustering. È possibile farlo in maniera molto semplice lanciando lo script PowerShell:



#configure kerberos for shared-nothing live migration between all clusters
# https://technet.microsoft.com/en-us/windows-server-docs/compute/hyper-v/deploy/set-up-hosts-for-live-migration-without-failover-clustering

$ClusterSet=“MyClusterSet”
$Clusters=(get-clustersetmember -CimSession $ClusterSet).ClusterName
$Nodes=Get-ClusterSetNode -CimSession $ClusterSet
foreach ($Cluster in $Clusters){
$SourceNodes=($nodes where member -eq $Cluster).Name
$DestinationNodes=($nodes where member -ne $Cluster).Name

Foreach ($DestinationNode in $DestinationNodes){
$HostName $DestinationNode

$HostFQDN = (Resolve-DnsName $HostName).name Select-Object -First 1
Foreach ($SourceNode in $SourceNodes){
Get-ADComputer $SourceNode Set-ADObject -Add @{“msDS-AllowedToDelegateTo”=“Microsoft Virtual System Migration Service/$HostFQDN, “Microsoft Virtual System Migration Service/$HostName, “cifs/$HostFQDN, “cifs/$HostName}
}
}
}

#Switch to any authentication protocol https://blogs.technet.microsoft.com/virtualization/2017/02/01/live-migration-via-constrained-delegation-with-kerberos-in-windows-server-2016/

Foreach ($Node in $Nodes){
$GUID=(Get-ADComputer $Node.Name).ObjectGUID
$comp=Get-ADObject -identity $Guid -Properties “userAccountControl”

#Flip the ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION bit using powershell bitwise OR operation (-bor)

$Comp.userAccountControl = $Comp.userAccountControl -bor 16777216
Set-ADObject -Instance $Comp
}

#Switch to kerberos authentication for live migration

Set-VMHost -CimSession $Nodes.Name -VirtualMachineMigrationAuthenticationType Kerberos

Figura 25: Abilitazione della Kerberos Trusted Delegation su tutti i nodi dei Member Cluster

Come ultima operazione aggiungiamo l’account macchina di MyClusterSet al gruppo amministratori locali dei singoli nodi dei Member Cluster con il comando PowerShell

$ClusterSet=“MyClusterSet”
$MgmtClusterterName=(Get-ClusterSet -CimSession $ClusterSet).ClusterName
Invoke-Command -ComputerName (Get-ClusterSetNode -CimSession $ClusterSet).Name -ScriptBlock {
Add-LocalGroupMember -Group Administrators -Member $using:MgmtClusterterName$”
}

Figura 26: L’account macchina di MyClusterSet è stato aggiunto al gruppo amministratori locali dei singoli nodi dei Member Cluster

Registrazione delle VM al Cluster Set

Adesso è possibile registrare tutte le VM all’interno del Cluster Set in modo tale che possano essere gestite centralmente, eseguendo il comando PowerShell

#Register all existing VMs

$ClusterSet=“MyClusterSet”
Get-ClusterSetMember -CimSession $ClusterSet Register-ClusterSetVM -RegisterAll

Figura 27: registrazione delle VM nel Cluster Set completata

Conclusioni

I Cluster Sets permettono di scalare orizzontalmente il numero di nodi gestibili da un singolo cluster e permettono ai Datacenter di poter utilizzare migliaia di nodi, riducendo di fatto i punti di rottura e portando ad un nuovo livello il Software Defined Datacenter (SDDC), ottimizzando le risorse hardware e semplificandone di molto la gestione.

Come funziona la risoluzione DNS nei sistemi operativi Windows

Facebooktwittergoogle_plusredditlinkedin

Tutti sappiamo quanto sia importante la risoluzione dei nomi DNS. Il processo di tradurre un indirizzo IP assegnato ad un computer, difficile da ricordare, in un nome che gli utenti possano leggere e capire semplifica di molto l’utilizzo delle risorse di rete. Il DNS ci permette, come una rubrica telefonica, di recuperare gli indirizzi dei server web, dei file server e di tutti i dispositivi presenti nella rete aziendale o in Internet in maniera davvero semplice.

Abbiamo già parlato in altri articoli delle novità del servizio DNS in Windows Server 2016 oppure delle funzionalità avanzate relative al DNSSEC, ma in questo articolo mi voglio soffermare sul funzionamento del DNS LATO CLIENT e sulle configurazioni da fare sulle macchine. Durante i corsi che tengo mi è capitato spesso infatti di trovare gente, anche con una certa “anzianità di servizio”, che aveva difficoltà a comprendere bene come funzionasse la risoluzione lato client.

Risoluzione dei nomi DNS per Windows Server e Windows Client

Il set di protocolli TCP/IP identifica i computer sorgente e destinazione tramite i propri indirizzo IP. Tuttavia gli utenti trovano più facile ricordare i nomi piuttosto che i numeri e per questo motivo gli amministratori assegnano un nome ai computer. I nomi assegnati agli indirizzi IP vengono poi scritti nel DNS. Il formato tipico di questi nomi è dc1.demo.com, dove DC1 è il nome del computer (hostname) e DEMO.COM è il nome del dominio. L’unione dell’hostname e del dominio formano il Fully Qualified Domain Name (FQDN).

Figura 1: Fully Qualified Domain Name (FQDN)

Un hostname può essere lungo fino a 255 caratteri e può contenere lettere, numeri, punti e trattini.

Come i Client risolvono i nomi DNS interni

Tutti i sistemi operativi Windows utilizzano diversi metodi per risolvere i nomi dei computer: DNS, WINS e NETBIOS. WINS è un database centralizzato che serve a risolvere i nomi NETBIOS. I nomi NETBIOS sono fondamentalmente solo i nomi host, senza il suffisso DNS, limitati ai primi 15 caratteri del nome macchina.

Quando un’applicazione richiede di raggiungere un certo hostname, il TCP/IP utilizza la DNS Resolver Cache per cercare di risolvere il nome host. Se NETBIOS over TCP/IP è abilitato nella configurazione della scheda di rete, il protocollo TCP/IP utilizza la risoluzione NETBIOS per risolvere i nomi.

Figura 2: Configurazione del NETBIOS attiva in maniera predefinita in Windows

I sistemi operativi Windows risolvono gli hostname utilizzando le seguenti operazioni in questo specifico ordine:

  1. Controllano se l’hostname cercato è lo stesso del pc da cui facciamo la richiesta (loopback)
  2. Controllano se il nome sia già stato risolto verificando la presenza nella cache locale del computer / Controllano se ci sono dei nomi computer scritti nel file HOSTS
  3. Inviano una richiesta al server DNS che è configurato nella scheda di rete
  4. Utilizzano, se è abilitato, il protocollo Link-Local Multicast Name Resolution (LLMNR)
  5. Convertono il nome host in un nome NETBIOS e controllano la presenza del nome nella cache NETBIOS locale del computer
  6. Inviano una richiesta al server WINS che è configurato nella scheda di rete
  7. Mandano una richiesta in BROADCAST nella stessa sottorete dove si trova
  8. Controllano se ci sono dei nomi computer scritti nel file LMHOSTS

Figura 3: Risoluzione dei nomi da parte di un Client Windows

Pertanto, se sto cercando di risolvere il nome fileserver1 (NETBIOS) la risoluzione avverrà in maniera diversa se cerco di risolvere il nome fileserver1.demo.com (FQDN).

Risoluzione DNS di nomi pubblici

Se cerchiamo di risolvere nomi DNS che non siano presenti nel nostro server DNS interno, come ad esempio i nomi Internet, la risoluzione DNS si comporta in modo completamente diverso. In questo caso, poiché il server DNS interno della nostra rete non ospita lo spazio di nomi cercato si dice che non è autoritativo per la zona DNS. Deve quindi rivolgersi ad un server DNS esterno per la risoluzione dei nomi, comportandosi quindi come un client.

Se il server DNS interno
non è autoritativo allora la risoluzione dei nomi viene effettuata dal server in uno di questi 3 modi:

  • Controlla nella propria cache di aver già risolto il nome cercato
  • Inoltra la richiesta ad un server esterno che abbiamo configurato (Forwarder). In questo caso effettua una query ricorsiva
  • Usa i Root Hints per conoscere chi sono i server autoritativi per la zona da cercare. In questo caso effettua una query iterativa

Il DNS è organizzato in maniera gerarchica e alla radice c’è la zona (.) (punto), chiamata Root. I Root Hints sono i 13 server mondiali che ospitano il livello gerarchico delle zone Internet, cioè la radice.

Figura 4: I Root Hints contengono gli indirizzi IP dei DNS Root Server

NOTA: Sia che il server DNS interno sia configurato con o senza Forwarder, la risoluzione dei nomi DNS pubblici avviene sempre e comunque tramite i Root Hints, che sono gli unici a sapere quali sono i server autoritativi per la zona cercata (ad esempio ictpower.it).

Ci sarebbe davvero molto da dire sul funzionamento dei server DNS e sulle loro configurazioni. Consiglio quindi vivamente di partire dal documento DNS Physical Structure per cominciare ad approfondire l’argomento e successivamente di leggere il documento DNS Processes and Interactions

Figura 5: Query DNS ricorsiva e iterative effettuate dal server DNS interno

Figura 6: Query DNS ricorsiva e iterative effettuate dal server DNS interno configurato con un Forwarder

Come configurare correttamente la scheda di rete per la risoluzione DNS

Per configurare correttamente la scheda di rete per la risoluzione DNS bisogna inserire i parametri dei server DNS, che variano a seconda che la macchina stia lavorando in dominio o in workgroup. Supponendo che la macchina sia stata aggiunta al dominio, dovremo inserire come server DNS l’indirizzo (o meglio gli indirizzi) dei domain controller aziendali. I Domain controller aziendali saranno capaci di risolvere sia i nomi interni sia i nomi pubblici. Se abbiamo due server con indirizzi 192.168.11.10 e 192.168.11.11 la configurazione corretta sarà:

Figura 7: Configurazione di una scheda di rete di una macchina in DOMINIO con gli IP dei Domain Controller, che fanno anche da DNS Server

Se la macchina è invece in workgroup, non ci saranno domain controller né server DNS interni e quindi sarà necessario configurare la scheda di rete con un indirizzo IP di un server DNS pubblico, come nell’esempio mostrato nella figura sotto:

Figura 8: Configurazione di una scheda di rete di una macchina in WORKGROUP con IP di DNS pubblici

Quali sono gli errori più comuni che vengono commessi?

Uno degli errori più comuni che vengono commessi è mischiare tra di loro indirizzi IP di DNS interni (domain controller) e di DNS pubblici. Per fare un esempio, una delle configurazioni che vedo più spesso è quella mostrata nella figura sotto:

Figura 9: Configurazione DNS errata

Quando viene utilizzato il DNS alternativo?

Quando il server DNS Preferito non risponde (è SPENTO o NON RAGGIUNGIBILE, non quando non sa rispondere ad una query DNS). Quindi la giustificazione che mi viene data per questo tipo di configurazione è che se sto riavviando il Domain Controller (molto spesso nelle piccole aziende ce n’è solo uno!) o il Domain controller non è raggiungibile, viene utilizzato il DNS secondario, che è capace di risolvere i nomi Internet. Così gli utenti navigano e non mi creano problemi!

Per capire dopo quanto tempo viene utilizzato il DNS server secondario vi spiego in che modo avviene una query DNS:

  1. Se il server DNS primario è disponibile la query viene immediatamente risolta
  2. Se il DNS primario NON è disponibile, la query viene effettuata sul server DNS alternativo dopo un time-out di circa 1 secondo

La situazione si complica quando avete diverse schede di rete sulla stessa macchina. Un ottimo articolo che spiega l’ordine di ricerca dei DNS alternativi ed il time-out che ne consegue è DNS Clients and Timeouts (part 2)

Quando viene utilizzato nuovamente il server DNS preferito?

È importante saperlo perché nell’esempio sopra il Domain Controller è l’unico in grado di risolvere i nomi interni del dominio e assicura il corretto funzionamento di servizi che dipendono da Active Directory. Quindi se non posso contattare il domain controller e continuo ad utilizzare il DNS pubblico potrei non essere in grado di poter utilizzare tutti i servizi interni del mio dominio.

La risposta è che di default ci vogliono 15 minuti. Passati i 15 minuti il server DNS alternativo viene cancellato dalla DNS Cache e la successiva query potrà ricominciare a contattare il server DNS preferito.

È però possibile modificare questo time-out agendo sulla chiave di registro Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters e modificando il valore REG_DWORD chiamato ServerPriorityTimeLimit. Se impostate il valore a 0, le priorità nella scelta dei server vengono cancellate dalla cache del DNS Client e quindi l’ordine di utilizzo dei server DNS viene controllato ogni volta che effettuate una nuova query.

Figura 10: modifica della chiave di registro per il ServerPriorityTimeLimit

Quindi, se proprio volete mettere un DNS server esterno come DNS secondario, tenete ben presente il time-out di 15 minuti ed eventualmente modificate la chiave di registro indicata.

Conclusioni

Conoscere il funzionamento della risoluzione DNS e delle configurazioni da effettuare sulla scheda di rete ci permette di evitare grossolani errori e ci aiuta nel troubleshooting della risoluzione dei nomi, che è uno dei più importanti concetti da capire per la gestione di un’infrastruttura di rete.

Utilizzare certificati gratuiti di Let’s Encrypt in una Azure Web App

Facebooktwittergoogle_plusredditlinkedin

Da quando è nata, il 12 aprile 2016, abbiamo avuto modo di parlare in diversi articoli della Certification Authority gratuita Let’s Encrypt. In questo articolo voglio far vedere come ottenere un certificato digitale gratuito generato da Let’s Encrypt da utilizzare con una Web App di Azure.

È infatti disponibile nelle Azure Web App un’estensione, creata da Simon J.K. Pedersen, che permette di ottenere e di rinnovare i certificati digitali da utilizzare con i Custom Domains delle Azure Web App.

Darò per scontato che abbiate già creato una Azure Web App e vi farò vedere come attivare l’estensione per Let’s Encrypt.

Creazione del Service Principal (Registered App)

La prima operazione che faremo sarà quella di creare un Service Principal in Azure AD. Si tratta fondamentalmente di un service account che viene utilizzato per ottenere un accesso alle risorse di Azure e che ci permetterà di richiedere e rinnovare il certificato digitale di Let’s Encrypt senza che sia necessario alcun intervento manuale. La creazione del Service Principal può essere effettuata dal portale di Azure selezionando la directory dentro la quale lo volete creare, scegliendo il nodo App Registrations e cliccando su + New application registration, come mostrato in figura:

Figure 1: Creazione di un nuovo Service Principal in Azure AD

Nel blade che si aprirà digitate il nome che volete dare al Service Principal (io ho scelto nicferr) e l’url della Web App, come mostrato in figura:

Figure 2: configurazione di un nuovo Service Principal in Azure AD

Una volta che avrete creato la Registered App sarà necessario creare una Secret Key (password). Infatti, per le autenticazioni utilizzeremo la combinazione Application ID e Secret Key per permettere all’estensione di Let’S Encrypt di potersi autenticare ed effettuare le operazioni di richiesta e rinnovo del certificato. Cliccate quindi su Settings e scegliete il nodo Keys. Creare una nuova password semplicemente scrivendo la description e la data di scadenza, come mostrato in figura. Quando cliccherete su Save la chiave verrà generata automaticamente.

Figure 3: Creazione di una nuova chiave di accesso per la Registered App

Dopo il salvataggio sarà possibile copiare la chiave generata automaticamente. Ricordatevi di salvarla perché non sarà successivamente visibile, come avrà modo di suggerirvi il banner mostrato in figura:

Figure 4: Generazione della chiave completata

Terminata la creazione del Service Principal (Registered App) sarà necessario assegnargli i giusti permessi per poter eseguire l’estensione. Andate nel Resource Group che ospita la vostra Web App e dal nodo Access Control (IAM), cliccate su Add e date il ruolo di Contributor alla Registered App che avete creato. La Registered App non sarà visibile nell’elenco, ma vi basterà scriverla nel campo Select e sarà subito trovata, come mostrato in figura

Figure 5: Aggiunta dei privilegi al Service Principal (Registered App)

ATTENZIONE: Se la Web App e l’App Service Plan si trovano in due Resource Group differenti, sarà necessario dare il permesso di Contributor ad ENTRAMBI

Installazione dell’estensione Let’s Encrypt

Terminata la fase preparatoria, siamo pronti per installare le due estensioni necessarie a far funzionare Let’S Encrypt con una Azure Web App. Dal portale di Azure, selezionate la Web App e dal nodo Extensions cliccate su Add per aggiungere l’estensione, come mostrato in figura:

Figure 6: Aggiunta di una estensione alla Web App di Azure

Scegliete l’estensione Azure Let’s Encrypt dalla lista delle estensioni disponibili e procedete all’installazione

Figure 7: Scelta dell’estensione Azure LEt’s Encrypt

Questa estensione NON è supportata da Microsoft. È bene tenerne conto nel caso ci siano malfunzionamenti, perché l’autore non da garanzie, come esplicitamente dichiarato nei termini legali.

Figure 8: Accettazione dei termini legali di utilizzo

L’estensione sarà subito visibile tra quelle installate

Figure 9: Installazione dell’estensione completata

Aggiungete anche l’estensione Azure Let’s Encrypt (no Web Jobs)

Figure 10: Aggiunta dell’estensione Azure Let’s Encrypt (no Web Jobs)

Se vi spostate nel modo WebJobs della vostra Web App potrete notare che sarà stata installato un nuovo webjobs, che servirà a rinnovare il certificato prima della scadenza.

Figure 11: Creazione del WebJob nella Web App

Configurazione dell’estensione di Azure Let’s Encrypt

Siamo ora pronti per configurare l’estensione. Cliccate sul tasto Browse dell’estensione Azure Let’s Encrypt per aprire la pagina di configurazione, come mostrato in figura:

Figure 12: Configurazione dell’estensione

Nella nuova pagina del browser vi apparirà la possibilità di configurare in maniera completamente automatica la richiesta e il rinnovo del certificato. Completate tutti i campi come richiesto. Maggiori dettagli su quello che deve essere inserito nei diversi campi sono anche disponibili alla pagina https://github.com/sjkp/letsencrypt-siteextension/wiki/How-to-install

Figure 13: inserimento delle informazioni necessarie per configurare l’estensione

Cliccando su Next si avvierà il processo di richiesta del certificato. Se non avete aggiunto dei Custom Domain alla vostra Web App vi apparirà l’errore mostrato in figura 15:

Figure 14: Prima richiesta del certificato

Figure 15: Errore relativo alla mancanza di un Custom Domain per cui richiedere il certificato

Aggiunta di un host name per il Custom Domain

Aggiungere un Custom Domain alla Web App richiede pochi semplici passaggi, ben descritti nell’esercitazione Eseguire il mapping di un nome DNS personalizzato esistente ad una Web App di Azure

Figure 16: Aggiunta di un host name personalizzato alla Web App

Una volta che avrete aggiunto il Custom Domain, rilanciando la configurazione dell’estensione di Let’s Encrypt, vedrete che il wizard potrà proseguire e vi chiederà per quale hostname volete generare il certificato, come mostrato in figura:

Figure 17: Il wizard ha riconosciuto gli hostname personalizzati

Figure 18: Scelta del nome host per cui richiedereil certificato

Dopo qualche secondo, il certificato sarà stato creato e associato (binding) all’hostname che avete scelto nel wizard.

Figure 19: Creazione del certificato completata

Se provate a caricare la vostra Web App infatti vedrete che starà utilizzando un certificato emesso da Let’s Encrypt, come mostrato in figura:

Figure 20: La Web App utilizza il certificato emesso da Let’s Encrypt

Conclusioni

Sono decisamente notevoli I vantaggi offerti da Let’s Encrypt, che ci permette di avere certificati digitali gratuiti ed automaticamente rinnovati. Poterli integrare con le Azure Web App ed avere la possibilità di utilizzare il protocollo HTTPS anche per gli hostname personalizzati garantisce i migliori livelli di sicurezza per la navigazione web.