Vai al contenuto
Avanet

Configurare più domain controller con Sophos ZTNA

Zero Trust Network Access

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.

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.

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

Prima della configurazione devono essere soddisfatti i seguenti requisiti:

  • 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 Central 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.

Creare ogni domain controller come risorsa

Creare una risorsa separata per ogni DC:

  1. In Sophos Central, aprire My Products > ZTNA > Resources & Access e selezionare Add Resource.
  2. Inserire un nome univoco e una breve descrizione, ad esempio dc01-example e Domain controller sede di Zurigo.
  3. Selezionare il Gateway responsabile.
  4. Per Access method, selezionare Agent.
  5. Assegnare la Policy basata su agente appropriata.
  6. Per Resource type, selezionare Domain Controller (DC).
  7. In External FQDN, inserire il nome completo di questo DC, ad esempio dc01.example.com, non solo il dominio radice example.com.
  8. Inserire Internal FQDN/IP address solo se la destinazione interna differisce dall’External FQDN. In assenza di un valore, Sophos utilizza l’External FQDN.
  9. Verificare le porte aggiunte automaticamente e integrare solo i servizi effettivamente necessari per questo ambiente.
  10. In Advanced Domain Controller settings, controllare i record SRV.
  11. In Assign User Groups, assegnare i gruppi che necessitano dei servizi AD attraverso questo DC.
  12. Salvare e quindi testare il DC con un dispositivo Windows pilota.

Sophos non crea un Resource 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 diretto tramite indirizzo IP non viene intercettato automaticamente da questo meccanismo.

Verificare le porte adatte 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.

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 Central,
  • 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.

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. A questo scopo non va spento un DC di produzione: il percorso primario va invece interrotto in modo controllato e solo per il test. Controllare quindi nuovamente nltest, la risoluzione SRV e l’applicazione interessata. Dopo modifiche a Priority o Weight, il TTL e le cache DNS locali possono ritardare il risultato.

Quando nessun domain controller è raggiungibile

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

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

Per ZTNA Gateway 2.2, Sophos elenca inoltre NZT-10022 nell’attuale Known Issues List: i pacchetti AD di grandi dimensioni possono essere eliminati in modo intermittente. Tra i possibili sintomi figurano connessioni Kerberos, RDP o a condivisioni di file non affidabili. Come soluzione alternativa, Sophos indica una MTU di 1420 byte per l’adattatore TAP di Sophos ZTNA. Questa modifica si riferisce solo a questo problema specifico e non deve essere impostata preventivamente su tutti i dispositivi.

Sophos fornisce la descrizione ufficiale dei campi e l’interfaccia corrente in Add resources. Microsoft descrive i requisiti delle porte per i servizi Windows utilizzati in Service overview and network port requirements.