Configurer plusieurs contrôleurs de domaine avec Sophos ZTNA

Lorsque des appareils Windows doivent accéder à Active Directory via Sophos ZTNA, un contrôleur de domaine unique constitue un point de défaillance unique évitable. À partir de Sophos Endpoint 2026.1, ZTNA prend en charge plusieurs ressources de DC avec une priorité et un poids. Il est ainsi possible d’utiliser deux contrôleurs de domaine en fonctionnement normal et de prévoir un autre DC comme cible de secours.

Chaque contrôleur de domaine est créé comme une ressource distincte basée sur un agent, de type Domain Controller (DC). Sophos ZTNA fournit la connexion et répond aux requêtes DNS SRV correspondantes sur le terminal. La structure AD existante, la résolution DNS et les relations d’approbation restent sous la responsabilité de l’environnement Active Directory.

Pour l’ordre général de configuration, commencez par Configurer Sophos ZTNA : vue d’ensemble et ordre des étapes. Planifier et créer une Sophos ZTNA Gateway explique la planification, le DNS et l’accessibilité de la passerelle.

Distinguer les ressources de DC de l’Identity Provider

Plusieurs ressources de DC ne signifient pas automatiquement que l’Identity Provider ZTNA peut authentifier des utilisateurs issus de plusieurs domaines AD indépendants.

Les ressources de DC transportent le trafic DNS, Kerberos, LDAP et les autres flux AD nécessaires à travers le tunnel ZTNA.
L’Identity Provider authentifie l’utilisateur pour ZTNA. Avec l’Identity Provider Microsoft AD local, Sophos ne prend toujours en charge qu’un seul domaine ; les Primary et Secondary AD Servers doivent appartenir au même domaine.
Le DNS AD et les relations d’approbation entre forêts doivent déjà fonctionner. ZTNA ne crée ni redirections DNS, ni relations d’approbation, ni synchronisation d’utilisateurs entre domaines.

Cette fonction convient donc directement à plusieurs DC d’un même domaine. Avec plusieurs domaines ou forêts, il faut également vérifier si l’Identity Provider, le DNS et les relations d’approbation existantes prennent effectivement en charge l’accès prévu.

Prérequis

Les éléments suivants doivent être en place avant la configuration :

Sophos Central avec une licence ZTNA active.
Une ZTNA Gateway configurée et accessible depuis le terminal.
Des appareils Windows équipés du ZTNA Agent et de Sophos Endpoint 2026.1 ou version ultérieure.
Des groupes d’utilisateurs synchronisés et une ZTNA Policy appropriée basée sur un agent.
Un FQDN unique par contrôleur de domaine, par exemple dc01.example.com.
L’accessibilité de chaque DC depuis la ZTNA Gateway via les services AD réellement nécessaires.
Une résolution DNS interne fonctionnelle ainsi que les relations d’approbation et redirections DNS existantes en présence de plusieurs domaines ou forêts.

La version du terminal apparaît dans Sophos Central sous My Environment > Computers & Servers > <Appareil> > Summary. Sous Assigned Products et Installed component versions, vérifiez si l’appareil pilote utilise déjà la version requise.

Créer chaque contrôleur de domaine comme ressource

Créez une ressource distincte pour chaque DC :

Dans Sophos Central, ouvrez My Products > ZTNA > Resources & Access, puis sélectionnez Add Resource.
Saisissez un nom unique et une brève description, par exemple dc01-example et Contrôleur de domaine site de Zurich.
Sélectionnez la Gateway responsable.
Pour Access method, sélectionnez Agent.
Attribuez la Policy appropriée basée sur un agent.
Pour Resource type, sélectionnez Domain Controller (DC).
Sous External FQDN, saisissez le nom complet de ce DC, par exemple dc01.example.com — et non uniquement le domaine racine example.com.
Renseignez Internal FQDN/IP address uniquement si la cible interne diffère de l’External FQDN. En l’absence de valeur, Sophos utilise l’External FQDN.
Vérifiez les ports ajoutés automatiquement et n’ajoutez que les services réellement nécessaires à cet environnement.
Sous Advanced Domain Controller settings, vérifiez les enregistrements SRV.
Sous Assign User Groups, attribuez les groupes qui ont besoin des services AD via ce DC.
Enregistrez, puis testez le DC avec un appareil Windows pilote.

Sophos ne crée pas de Resource Alias pour une ressource de DC basée sur un agent. Il ne faut donc créer ni CNAME public ni enregistrement DNS générique pour le DC, et l’External FQDN ne doit pas être accessible publiquement. Le CNAME de passerelle requis pour la Sophos Cloud Gateway n’est pas concerné. Le ZTNA Agent intercepte le FQDN configuré sur le terminal. Un accès direct par l’adresse IP n’est pas automatiquement intercepté par ce mécanisme.

Vérifier les ports adaptés à l’environnement

Le type de ressource Domain Controller (DC) ajoute automatiquement une série de ports. Cette liste constitue un point de départ, mais ne remplace pas la vérification des fonctions AD réellement utilisées. Un simple test LDAP nécessite des connexions différentes d’une connexion Kerberos, des stratégies de groupe, du DNS, de SMB ou de RPC dynamique.

Les listes de ports statiques ne doivent donc pas être reprises sans vérification. Les éléments déterminants sont :

les ports automatiquement préconfigurés dans l’interface Sophos Central actuelle,
les services et ports utilisés sous Advanced Domain Controller settings,
les exigences de ports Microsoft pour les fonctions AD utilisées dans cet environnement,
l’accessibilité de ces ports depuis la ZTNA Gateway vers le DC concerné.

Si un port requis manque dans le champ de ports normal de la ressource, un enregistrement SRV correspondant dans les paramètres avancés ne suffit pas à lui seul. La connexion peut alors échouer malgré une réponse DNS correcte.

Comprendre la priorité et le poids SRV

Active Directory utilise des enregistrements DNS SRV afin que les clients trouvent un service et un contrôleur de domaine appropriés. Sophos ZTNA reproduit ces enregistrements sous Advanced Domain Controller settings.

Les principaux champs sont :

Services: Service AD, par exemple LDAP ou Kerberos.
Domain name: Domaine DNS auquel l’enregistrement SRV s’applique.
Protocol: TCP ou UDP.
Port numbers: Port du service concerné, par exemple 389 pour LDAP ou 88 pour Kerberos.
Priority: Un nombre inférieur correspond à une priorité supérieure. Les DC ayant la valeur de priorité disponible la plus basse sont utilisés en premier.
Weight: Répartit la sélection entre les DC ayant la même priorité.
TTL: Durée, en secondes, pendant laquelle une réponse peut être mise en cache. La valeur par défaut 86400 correspond à 24 heures.

La priorité détermine donc le groupe préféré. Le poids influence uniquement la sélection au sein d’un même groupe. Il ne garantit pas une répartition exacte du trafic en pourcentage, car le cache DNS, le comportement du client et le nombre de requêtes influencent également le résultat.

Exemple avec deux DC actifs et un DC de secours

Pour le domaine example.com, la charge normale doit être répartie entre deux DC. Un troisième DC est utilisé uniquement comme cible de secours :

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

Avec la même Priority, dc01 et dc02 appartiennent au groupe préféré. Leur poids règle leur sélection approximative selon un rapport de 60 à 40. dc03, avec Priority 2, n’est pris en compte que lorsqu’aucun DC avec Priority 1 n’est disponible.

Les trois ressources nécessitent des enregistrements SRV adaptés au même domaine et aux services réellement nécessaires. Cependant, la valeur numérique supérieure 2, et donc la priorité de sélection inférieure, ne fait pas automatiquement de dc03 un remplacement complet : la réplication, le DNS, le rôle de catalogue global et les services AD accessibles doivent également correspondre au basculement prévu.

Tester le fonctionnement sur un appareil Windows

Commencez par vérifier la réponse SRV pour le domaine souhaité :

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

La réponse doit contenir les contrôleurs de domaine configurés avec leur Priority et leur Weight. Forcez ensuite une nouvelle recherche de DC :

nltest /dsgetdc:example.com /force

nltest affiche le DC accessible sélectionné, mais pas nécessairement toutes les cibles disponibles. Testez donc également la connexion aux différents services :

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

Dans cet exemple, le port 389 teste LDAP sur TCP. Kerberos, DNS, SMB ou RPC nécessitent des tests adaptés au cas d’usage réel. Une validation complète comprend également une véritable connexion Windows ou l’accès à l’application qui nécessite AD via ZTNA.

Pour une capture de paquets sur le terminal, ce filtre Wireshark affiche exclusivement les requêtes DNS SRV :

dns.qry.type == 33

Un test de basculement doit être effectué sur un appareil pilote et pendant une fenêtre de maintenance. Il ne faut pas arrêter un DC de production à cette fin ; interrompez plutôt le chemin principal de manière contrôlée et uniquement pour le test. Vérifiez ensuite à nouveau nltest, la résolution SRV et l’application concernée. Après une modification de Priority ou de Weight, le TTL et les caches DNS locaux peuvent retarder le résultat.

Lorsqu’aucun contrôleur de domaine n’est accessible

En cas de panne, vérifiez les points suivants dans cet ordre :

Chaque DC est-il créé comme ressource avec Access method: Agent et Resource type: Domain Controller (DC) ?
External FQDN utilise-t-il le nom concret du DC et non uniquement le domaine AD ?
Le domaine, le service, le protocole, le port, la Priority et le Weight des enregistrements SRV sont-ils corrects ?
Tous les ports utilisés sont-ils également présents dans le champ de ports normal de la ressource ?
La ZTNA Gateway peut-elle atteindre chaque DC via ces ports ?
Les utilisateurs pilotes, les groupes et la Policy sont-ils correctement attribués ?
L’appareil Windows exécute-t-il Sophos Endpoint 2026.1 ou version ultérieure ?
Resolve-DnsName, nltest et dns.qry.type == 33 affichent-ils les mêmes DC que Sophos Central ?

Pour ZTNA Gateway 2.2, Sophos répertorie également NZT-10022 dans la Known Issues List actuelle : les paquets AD volumineux peuvent être rejetés de manière intermittente. Des connexions Kerberos, RDP ou de partage de fichiers peu fiables font partie des symptômes possibles. Sophos indique comme solution de contournement une MTU de 1420 octets pour l’adaptateur Sophos ZTNA TAP. Cette modification s’applique uniquement à ce problème précis et ne doit pas être définie préventivement sur tous les appareils.

Sophos fournit la description officielle des champs et l’interface actuelle sous Add resources. Microsoft décrit les exigences de ports pour les services Windows utilisés sous Service overview and network port requirements.