Archivi categoria: Windows Server 2016

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.

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.

Veeam Backup & Replication: recuperare le GPO

Facebooktwittergoogle_plusredditlinkedin

Uno degli scenari più frequenti che mi capita dover affrontare, quando mi trovo dai clienti, è il recupero delle Group Policy Object che vengono eliminate. Microsoft mette a disposizione diverse armi da questo punto di vista, a cominciare dal Recycle Bin di Active Directory, presente da Windows Server 2008 R2, che permette di recuperare gli oggetti eliminati entro un certo periodo di tempo.

Figura 1 – Recycle Bin AD

Un altro modo per proteggersi, è creare dei backup direttamente dalla console delle GPO, che permette di ripristinare le policy con il valore aggiunto di fare un rollback in caso si sia modificata una policy in modo errato.

Figura 2 – Backup GPO

Esiste anche una terza via, che è quella di utilizzare Microsoft Advanced Group Policy Management, un prodotto presente all’interno della suite MDOP, che permette di effettuare backup avanzati, fare restore, comparazioni e molto altro ancora.

Veeam Restore for Active Directory

Per chi volesse la vita semplificata, è possibile utilizzare Veeam Backup & Replication per fare il recupero degli oggetti Active Directory. Grazie all’integrazione nativa, introdotta dalla versione 8, è possibile ripristinare non solo utenti e gruppi, ma anche GPO eliminate.

NB: il restore funziona solo se si attiva l’Application-Aware Support.

Figura 3 – Ripristino AD Objects

La procedura di recupero è identica a quella adottata per gli altri oggetti, perciò avremo la nostra timeline in cui effettuare il restore, con annesse note.

Figura 4 – Timeline

Figura 5 – Elenco Oggetti

La cosa interessante della soluzione, sta nel poter effettuare le seguenti operazioni:

  • Restore su un Domain Controller
  • Export
  • Compare

Proprio il compare è una di quelle funzioni che può aiutare gli IT admin a fare non solo un ripristino, ma volendo è possibile recuperare solo la parte modificata. Ad esempio, potremmo avere la necessità di ripristinare solo le security policy perché qualcuno ha cancellato i target users.

Figura 6 – Confronto GPO

Non è possibile verificare cosa sia cambiato, ma di sicuro questa funzionalità aiuta parecchio a recuperare gli oggetti eliminati o modificati.

Conclusioni

Veeam Backup & Replication, se utilizzato al meglio, è sicuramente un valido alleato nel ripristino di tutte le tipologie di oggetti della propria infrastruttura IT. Grazie all’integrazione nativa, diventa facile e veloce recuperare gli elementi e riposizionarli all’interno della loro locazione iniziale.

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!

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.