Configurare più domain controller con Sophos ZTNA

Quando i dispositivi Windows devono raggiungere Active Directory tramite Sophos ZTNA, un singolo domain controller rappresenta un single point of failure evitabile. A partire da Sophos Endpoint 2026.1, ZTNA supporta più risorse DC con priorità e peso. In questo modo è possibile utilizzare due domain controller durante il normale funzionamento e prevederne un altro come destinazione di riserva.

Ogni domain controller viene creato come risorsa separata basata su agente di tipo Domain Controller (DC). Sophos ZTNA mette a disposizione la connessione e risponde alle relative query DNS SRV sull’endpoint. La struttura AD esistente, la risoluzione DNS e le relazioni di trust rimangono responsabilità dell’ambiente Active Directory.

Distinguere le risorse DC dall’Identity Provider

Più risorse DC non significano automaticamente che l’Identity Provider ZTNA possa autenticare utenti appartenenti a diversi domini AD indipendenti.

Le risorse DC trasportano il traffico DNS, Kerberos, LDAP e gli altri flussi AD necessari attraverso il tunnel ZTNA.
L’Identity Provider autentica l’utente per ZTNA. Con l’Identity Provider Microsoft AD locale, Sophos continua a supportare un solo dominio; i Primary e Secondary AD Servers devono appartenere allo stesso dominio.
Il DNS AD e le relazioni di trust tra foreste devono essere già funzionanti. ZTNA non crea inoltri DNS, relazioni di trust o sincronizzazioni degli utenti tra domini.

La funzione è quindi direttamente adatta a più DC dello stesso dominio. In presenza di più domini o foreste, occorre inoltre verificare che l’Identity Provider, il DNS e le relazioni di trust esistenti supportino effettivamente l’accesso pianificato.

Requisiti, licenza e ruoli

Prima della configurazione devono essere soddisfatti i seguenti requisiti:

Sophos Fusion (in precedenza Sophos Central) con una licenza ZTNA attiva.
Uno ZTNA Gateway configurato e raggiungibile dall’endpoint.
Dispositivi Windows con ZTNA Agent e Sophos Endpoint 2026.1 o versione successiva.
Gruppi di utenti sincronizzati e una ZTNA Policy basata su agente appropriata.
Un FQDN univoco per ogni domain controller, ad esempio dc01.example.com.
Raggiungibilità di ciascun DC dallo ZTNA Gateway tramite i servizi AD effettivamente necessari.
Risoluzione DNS interna funzionante, nonché trust e inoltri DNS esistenti in presenza di più domini o foreste.

La versione dell’endpoint è indicata in Sophos Fusion in My Environment > Computers & Servers > <Dispositivo> > Summary. In Assigned Products e Installed component versions è possibile verificare se il dispositivo pilota utilizza già la versione richiesta.

Prima della modifica, verificare che ZTNA > Resources & Access sia disponibile nel tenant e che l’account amministratore utilizzato possa aggiungere e modificare risorse in tale sezione. Se la voce di menu o il pulsante non è presente, non procedere ipotizzando un ruolo o una licenza: chiarire l’autorizzazione ZTNA e l’ambito sottoscritto nel proprio tenant o con il partner Sophos responsabile.

Come aggiungere risorse: creare ogni domain controller

Creare separatamente ogni DC come Domain Controller con metodo di accesso basato su agente:

In Sophos Fusion, aprire My Products > ZTNA > Resources & Access e selezionare Add Resource.
Inserire un nome univoco e una breve descrizione, ad esempio dc01-example e Domain controller sede di Zurigo.
Lasciare attiva l’opzione Show resource in user portal in base all’accesso utente desiderato.
Selezionare il Gateway responsabile.
Per Access method, selezionare Agent e assegnare la Policy basata su agente appropriata.
Per Resource type, selezionare Domain Controller (DC).
In External FQDN, inserire il nome completo di questo DC, ad esempio dc01.example.com, non solo il dominio radice example.com.
Inserire Internal FQDN/IP address solo se la destinazione interna differisce dall’External FQDN. In assenza di un valore, Sophos utilizza automaticamente l’External FQDN.
Verificare le porte aggiunte automaticamente e integrare solo i servizi effettivamente necessari per questo ambiente.
In Advanced Domain Controller settings, controllare i record SRV.
In Assign User Groups, spostare da Available User Groups a Assigned User Groups tutti i gruppi che necessitano delle risorse dietro questo DC.
Selezionare Save e quindi testare il DC con un dispositivo Windows pilota.

Le risorse senza agente e le risorse basate su agente richiedono record DNS diversi. Sophos non crea un dominio alias per una risorsa DC basata su agente. Per il DC non devono quindi essere creati né un CNAME pubblico né un record DNS wildcard; inoltre, l’External FQDN non deve essere disponibile pubblicamente. Questa indicazione non riguarda il CNAME del gateway necessario per Sophos Cloud Gateway. Lo ZTNA Agent intercetta sull’endpoint il FQDN configurato. L’accesso basato su IP non viene intercettato automaticamente da questo meccanismo.

Verificare record DNS e porte adatti all’ambiente

Il tipo di risorsa Domain Controller (DC) aggiunge automaticamente una serie di porte. L’elenco è un punto di partenza, ma non sostituisce la verifica delle funzioni AD effettivamente utilizzate. Un semplice test LDAP richiede connessioni diverse rispetto a un accesso con Kerberos, ai Criteri di gruppo, al DNS, a SMB o a RPC dinamico.

Sophos indica inoltre le porte seguenti per questo tipo di risorsa:

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (nella guida Sophos in tedesco, questa riga è etichettata UCP)

Il modulo generale delle risorse richiede di Specify the port type and port number (ad esempio HTTPS e 443 per un’applicazione web). Per un domain controller sono invece determinanti i servizi TCP e UDP necessari.

Non adottare senza verifica gli insoliti valori UDP come raccomandazione AD generale. Provengono dall’attuale guida alle risorse Sophos; ciò che conta è quali servizi offre effettivamente il proprio DC e quali connessioni richiede la funzione AD. Una risorsa può contenere complessivamente fino a 20 voci di porte TCP e UDP. Inserire gli intervalli con un trattino e separare più voci con virgole, ad esempio 49152-65535.

Gli elenchi statici di porte non devono quindi essere adottati senza verifica. Gli elementi decisivi sono:

le porte preconfigurate automaticamente nell’attuale interfaccia di Sophos Fusion,
i servizi e le porte utilizzati in Advanced Domain Controller settings,
i requisiti delle porte Microsoft per le funzioni AD utilizzate in questo ambiente,
la raggiungibilità di queste porte dallo ZTNA Gateway verso il rispettivo DC.

Se una porta necessaria manca nel normale campo delle porte della risorsa, il solo record SRV corrispondente nelle impostazioni avanzate non è sufficiente. La connessione può quindi non riuscire nonostante una risposta DNS corretta.

Per le condivisioni file CIFS o SMB sensibili alla latenza, Sophos consiglia un gateway locale. Ciò non modifica le necessarie verifiche di porte e funzioni, ma abbrevia il percorso dei dati rispetto a un Cloud Gateway.

Comprendere priorità e peso SRV

Active Directory utilizza i record DNS SRV affinché i client possano trovare un servizio e un domain controller appropriati. Sophos ZTNA rappresenta questi record in Advanced Domain Controller settings.

I campi principali sono:

Services: Servizio AD, ad esempio LDAP o Kerberos.
Domain name: Dominio DNS a cui si applica il record SRV.
Protocol: TCP o UDP.
Port numbers: Porta del servizio interessato, ad esempio 389 per LDAP o 88 per Kerberos.
Priority: Un numero inferiore indica una priorità maggiore. Vengono utilizzati per primi i DC con il valore di priorità disponibile più basso.
Weight: Distribuisce la selezione tra i DC con la stessa priorità.
TTL: Tempo in secondi per cui una risposta può rimanere nella cache. Il valore predefinito 86400 corrisponde a 24 ore.

La priorità determina quindi il gruppo preferito. Il peso influisce solo sulla selezione all’interno dello stesso gruppo. Non garantisce una distribuzione percentuale esatta del traffico, perché anche la cache DNS, il comportamento del client e il numero di richieste influenzano il risultato.

Esempio con due DC attivi e uno di riserva

Per il dominio example.com, il carico normale deve essere distribuito su due DC. Un terzo DC viene utilizzato solo come destinazione di riserva:

dc01.example.com: Priority 1, Weight 60
dc02.example.com: Priority 1, Weight 40
dc03.example.com: Priority 2

Poiché hanno la stessa Priority, dc01 e dc02 appartengono al gruppo preferito. Il peso ne determina la selezione approssimativa secondo un rapporto di 60 a 40. dc03, con Priority 2, viene preso in considerazione solo quando non è disponibile alcun DC con Priority 1.

Tutte e tre le risorse richiedono record SRV appropriati per lo stesso dominio e per i servizi effettivamente necessari. Il valore numerico più alto 2, e quindi la priorità di selezione inferiore, non rende tuttavia dc03 automaticamente un sostituto completo: anche replica, DNS, ruolo di catalogo globale e servizi AD raggiungibili devono essere adatti al failover previsto.

Verificare il funzionamento su un dispositivo Windows

Controllare innanzitutto la risposta SRV per il dominio desiderato:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.example.com

La risposta deve contenere i domain controller configurati con Priority e Weight. Forzare quindi una nuova ricerca del DC:

nltest /dsgetdc:example.com /force

nltest mostra il DC raggiungibile selezionato, ma non necessariamente tutte le destinazioni disponibili. È quindi opportuno verificare anche la connessione ai singoli servizi:

Test-NetConnection dc01.example.com -Port 389
Test-NetConnection dc02.example.com -Port 389
Test-NetConnection dc03.example.com -Port 389

In questo esempio, la porta 389 verifica LDAP su TCP. Per Kerberos, DNS, SMB o RPC sono necessari test adeguati al caso d’uso reale. Una verifica completa comprende inoltre un vero accesso a Windows o all’applicazione che necessita di AD tramite ZTNA.

Per un’acquisizione dei pacchetti sull’endpoint, questo filtro Wireshark mostra esclusivamente le query DNS SRV:

dns.qry.type == 33

Un test di failover deve essere svolto su un dispositivo pilota e durante una finestra di manutenzione. Non spegnere i DC di produzione. Utilizzare invece due regole di rete temporanee limitate al dispositivo pilota per isolare i percorsi verso dc01.example.com e dc02.example.com senza influire sugli altri client. Il TTL e le cache DNS e DC locali possono ritardare il failover; pertanto, includere nel piano del test il TTL configurato e il ritardo delle cache.

Mentre entrambi i DC con Priority 1 sono isolati, utilizzare Resolve-DnsName per confermare che la risposta SRV contenga dc03.example.com con Priority 2, utilizzare nltest /dsgetdc:example.com /force per dimostrare che viene selezionato dc03 e completare correttamente il reale flusso di accesso o dell’applicazione dipendente da AD. Rimuovere quindi entrambe le regole di test, tenere nuovamente conto del ritardo delle cache e confermare con la risoluzione SRV, nltest e lo stesso flusso che la selezione torni a dc01 o dc02 nel gruppo con Priority 1.

Quando nessun domain controller è raggiungibile

In caso di interruzione, verificare i seguenti punti nell’ordine indicato:

Ogni DC è stato creato come risorsa con Access method: Agent e Resource type: Domain Controller (DC)?
External FQDN utilizza il nome specifico del DC e non soltanto il dominio AD?
Dominio, servizio, protocollo, porta, Priority e Weight dei record SRV sono corretti?
Tutte le porte utilizzate sono incluse anche nel normale campo delle porte della risorsa?
Lo ZTNA Gateway può raggiungere ogni DC attraverso queste porte?
Gli utenti pilota, i gruppi e la Policy sono assegnati correttamente?
Sul dispositivo Windows è in esecuzione Sophos Endpoint 2026.1 o versione successiva?
Resolve-DnsName, nltest e dns.qry.type == 33 mostrano gli stessi DC di Sophos Fusion?

L’accesso tramite FQDN non riesce, ma quello tramite indirizzo IP funziona

Lo ZTNA Agent intercetta le risorse solo in base al FQDN. L’accesso IP diretto può quindi aggirare ZTNA e non costituisce un test ZTNA riuscito. Ripetere l’accesso con il nome inserito in External FQDN. Se gli utenti devono raggiungere le risorse interne esclusivamente tramite ZTNA, bloccare anche il percorso IP diretto con regole firewall appropriate.

Un gruppo Entra ID rinominato non ha più accesso

Se un gruppo Microsoft Entra ID già assegnato viene rinominato successivamente, Sophos non aggiorna automaticamente l’elenco dei gruppi della risorsa. Riassegnare il gruppo interessato in Assign User Groups, salvare e testare l’accesso con un membro del gruppo.

L’FQDN esterno è risolvibile pubblicamente

Per una risorsa basata su agente, l’FQDN esterno non deve essere disponibile pubblicamente. È il caso opposto rispetto a una risorsa senza agente, il cui FQDN esterno deve essere disponibile pubblicamente. Verificare quindi insieme la pubblicazione DNS e l’Access method; per la risorsa DC qui descritta, il metodo di accesso rimane Agent.

Più utenti perdono sporadicamente la connessione AD

ZTNA Gateway 2.2 presenta il problema noto NZT-10022: il server websocket del gateway può scartare in modo intermittente i pacchetti AD di grandi dimensioni. Di conseguenza, più utenti possono perdere la connettività AD in modo apparentemente casuale oppure Kerberos, RDP, le condivisioni file di Windows e altre applicazioni basate su AD possono rallentare o non funzionare. La soluzione alternativa limitata consiste nell’impostare una MTU di 1420 byte sull’adattatore TAP di Sophos ZTNA dell’endpoint interessato; non applicare preventivamente questo valore a tutti i dispositivi.

Eseguire prima la modifica su un dispositivo pilota da una sessione PowerShell con diritti di amministratore. Annotare in precedenza l’alias e la MTU originale per IPv4 e IPv6:

Get-NetIPInterface | Where-Object InterfaceAlias -Like '*Sophos*ZTNA*TAP*' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

Sostituire <TAP-ALIAS> con l’alias visualizzato, impostare la MTU e controllare il valore effettivo:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -NlMtuBytes 1420
Get-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' | Format-Table InterfaceAlias, AddressFamily, NlMtuBytes

Riconnettere quindi ZTNA e ripetere più volte l’operazione Kerberos, RDP o di condivisione file che in precedenza non riusciva. Se il problema persiste o compaiono altri problemi di connettività, ripristinare i valori annotati; sostituire <ORIGINAL_MTU> con il valore originale di ciascuna famiglia di indirizzi:

Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv4 -NlMtuBytes <ORIGINAL_MTU>
Set-NetIPInterface -InterfaceAlias '<TAP-ALIAS>' -AddressFamily IPv6 -NlMtuBytes <ORIGINAL_MTU>

Se la prima query non restituisce alcun adattatore, usare Get-NetAdapter per individuare l’alias esatto e non modificare un’altra interfaccia. Se la MTU torna al valore precedente dopo la riconnessione o il riavvio, oppure 1420 non offre un miglioramento evidente, non continuare a ridurla. Raccogliere invece le versioni di gateway ed endpoint, gli utenti e i servizi interessati, i timestamp, la MTU prima e dopo la modifica e una cattura dei pacchetti, quindi escalare il caso indicando NZT-10022.

Microsoft descrive i requisiti delle porte per i servizi Windows utilizzati in Service overview and network port requirements.

Ripristino sicuro e dismissione

Non rimuovere una risorsa DC durante un accesso in corso o un test di failover in produzione. Annotare prima i gruppi di utenti, le porte, i record SRV, Priority e Weight assegnati e verificare che rimanga raggiungibile almeno un DC testato dello stesso gruppo di priorità oppure il DC di riserva previsto.

Per annullare una modifica, aprire My Products > ZTNA > Resources & Access e selezionare il resource name. Qui è possibile modificare i dettagli della risorsa o rimuoverla. Ripristinare innanzitutto ai valori iniziali annotati qualsiasi modifica errata a porte, valori SRV o gruppi e salvare. Rimuovere una risorsa solo quando il relativo FQDN non è più necessario a utenti o applicazioni.

Sul dispositivo pilota, controllare quindi nuovamente la risoluzione SRV, nltest /dsgetdc:example.com /force e il flusso di accesso o dell’applicazione interessata. Se non rimane raggiungibile alcun DC testato, fermarsi prima della rimozione ed escalare il caso con i valori salvati. Una rimozione completata non può essere annullata. Se la risorsa è già stata rimossa, solo un amministratore qualificato può ricrearla manualmente dalle impostazioni annotate, riassegnare i gruppi e ripetere quindi la convalida completa. Se è necessario preservare l’identità o lo stato della risorsa, oppure le annotazioni sono incomplete, non ricrearla ed escalare il caso.

Gestione, revisione e ciclo di vita

Priority, Weight e TTL devono essere inclusi nella documentazione operativa dell’ambiente AD. Verificare nuovamente l’assegnazione dopo modifiche a sedi dei DC, FQDN, servizi offerti, porte o gruppi di utenti. La riassegnazione di un gruppo Entra ID rinominato è un’operazione distinta; non avviene alcun aggiornamento automatico.

Per questa funzione non è documentata alcuna istruzione specifica di migrazione, dismissione o fine vita. Dopo gli aggiornamenti del prodotto, controllare innanzitutto la guida aggiornata alle risorse e i campi visibili nel tenant, quindi convalidare nuovamente le modifiche su un dispositivo pilota limitato.

Guide esistenti correlate

Per la sequenza generale di configurazione, consultare innanzitutto Configurare Sophos ZTNA: panoramica e sequenza. Pianificare e creare un Sophos ZTNA Gateway descrive pianificazione, DNS e raggiungibilità del gateway.