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.

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, licence et rôles

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

Sophos Fusion (anciennement 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 Fusion 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.

Avant toute modification, vérifiez que ZTNA > Resources & Access est disponible dans le tenant et que le compte administrateur utilisé est autorisé à y ajouter et modifier des ressources. Si l’élément de menu ou le bouton manque, ne poursuivez pas en supposant un rôle ou une licence : clarifiez l’autorisation ZTNA et l’étendue souscrite dans votre tenant ou auprès du partenaire Sophos responsable.

Comment ajouter des ressources : créer chaque contrôleur de domaine

Créez chaque DC séparément comme Domain Controller avec une méthode d’accès basée sur un agent :

Dans Sophos Fusion, 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.
Laissez Show resource in user portal activé selon l’accès utilisateur souhaité.
Sélectionnez la Gateway responsable.
Pour Access method, sélectionnez Agent et 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 automatiquement 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, déplacez de Available User Groups vers Assigned User Groups tous les groupes ayant besoin de ressources derrière ce DC.
Sélectionnez Save, puis testez le DC avec un appareil Windows pilote.

Les ressources sans agent et les ressources basées sur un agent nécessitent des enregistrements DNS différents. Sophos ne crée pas de domaine 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. L’accès basé sur l’adresse IP n’est pas automatiquement intercepté par ce mécanisme.

Vérifier les enregistrements DNS et 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.

Sophos indique en outre les ports suivants pour ce type de ressource :

TCP: 53, 80, 88, 135, 139, 389, 443, 464, 636, 3268, 3269, 49152-65535
UDP: 88, 389, 464, 636, 4389, 63664 (dans l’aide Sophos en allemand, cette ligne est libellée UCP)

Le formulaire général de ressource demande de Specify the port type and port number (par exemple HTTPS et 443 pour une application web). Pour un contrôleur de domaine, ce sont plutôt les services TCP et UDP requis qui s’appliquent.

Ne reprenez pas sans vérification les valeurs UDP inhabituelles comme recommandation AD générale. Elles proviennent du guide de ressources Sophos actuel ; les éléments déterminants restent les services réellement proposés par votre DC et les connexions nécessaires à votre fonction AD. Une ressource peut contenir au total jusqu’à 20 entrées de ports TCP et UDP. Saisissez les plages avec un trait d’union et séparez plusieurs entrées par des virgules, par exemple 49152-65535.

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 Fusion 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.

Pour les partages de fichiers CIFS ou SMB sensibles à la latence, Sophos recommande une passerelle locale. Cela ne modifie pas les vérifications requises des ports et fonctions, mais raccourcit le chemin des données par rapport à une Cloud Gateway.

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. N’arrêtez pas les DC de production. Utilisez plutôt deux règles réseau temporaires limitées à l’appareil pilote afin d’isoler les chemins vers dc01.example.com et dc02.example.com sans affecter les autres clients. Le TTL ainsi que les caches DNS et DC locaux peuvent retarder le basculement ; prévoyez donc le TTL configuré et le délai des caches dans le calendrier du test.

Pendant que les deux DC de Priority 1 sont isolés, utilisez Resolve-DnsName pour confirmer que la réponse SRV contient dc03.example.com avec la Priority 2, puis nltest /dsgetdc:example.com /force pour prouver que dc03 est sélectionné, et exécutez avec succès le véritable processus de connexion ou d’application dépendant d’AD. Supprimez ensuite les deux règles de test, tenez de nouveau compte du délai des caches et confirmez, à l’aide de la résolution SRV, de nltest et du même processus, que la sélection revient à dc01 ou dc02 dans le groupe de Priority 1.

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 Fusion ?

L’accès par FQDN échoue, mais l’accès par adresse IP fonctionne

Le ZTNA Agent intercepte les ressources uniquement sur la base du FQDN. Un accès direct par IP peut donc contourner ZTNA et ne constitue pas un test ZTNA réussi. Répétez l’accès avec le nom saisi sous External FQDN. Si les utilisateurs doivent impérativement accéder aux ressources internes via ZTNA, bloquez également le chemin IP direct avec des règles de pare-feu adaptées.

Un groupe Entra ID renommé n’a plus accès

Si un groupe Microsoft Entra ID déjà attribué est renommé ultérieurement, Sophos ne met pas automatiquement à jour la liste de groupes de la ressource. Réattribuez le groupe concerné sous Assign User Groups, enregistrez, puis testez l’accès avec un membre de ce groupe.

Le FQDN externe est résolu publiquement

Pour une ressource basée sur un agent, le FQDN externe ne doit pas être accessible publiquement. C’est l’inverse d’une ressource sans agent, dont le FQDN externe doit être accessible publiquement. Vérifiez donc conjointement la publication DNS et l’Access method ; pour la ressource de DC décrite ici, la méthode d’accès reste Agent.

Plusieurs utilisateurs perdent sporadiquement la connexion AD

ZTNA Gateway 2.2 présente le problème connu NZT-10022 : le serveur websocket de la gateway peut rejeter par intermittence les paquets AD volumineux. Plusieurs utilisateurs peuvent alors perdre la connectivité AD de façon apparemment aléatoire, ou Kerberos, RDP, les partages de fichiers Windows et d’autres applications adossées à AD peuvent ralentir ou échouer. La solution de contournement limitée consiste à définir une MTU de 1420 octets sur l’adaptateur Sophos ZTNA TAP de l’endpoint concerné ; n’appliquez pas préventivement cette valeur à tous les appareils.

Effectuez d’abord la modification sur un appareil pilote dans une session PowerShell exécutée en tant qu’administrateur. Au préalable, notez l’alias et la MTU d’origine pour IPv4 et IPv6 :

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

Remplacez <TAP-ALIAS> par l’alias affiché, définissez la MTU et contrôlez la valeur effective :

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

Reconnectez ensuite ZTNA et répétez plusieurs fois l’opération Kerberos, RDP ou de partage de fichiers qui échouait auparavant. Si l’échec persiste ou si d’autres problèmes de connectivité apparaissent, restaurez les valeurs notées ; remplacez <ORIGINAL_MTU> par la valeur d’origine de chaque famille d’adresses :

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

Si la première requête ne renvoie aucun adaptateur, utilisez Get-NetAdapter pour identifier l’alias exact et ne modifiez pas une autre interface. Si la MTU revient à sa valeur précédente après une reconnexion ou un redémarrage, ou si 1420 n’apporte pas d’amélioration nette, ne continuez pas à la réduire. Collectez plutôt les versions de la gateway et de l’endpoint, les utilisateurs et services concernés, les horodatages, la MTU avant et après la modification ainsi qu’une capture de paquets, puis escaladez le cas avec NZT-10022.

Microsoft décrit les exigences de ports pour les services Windows utilisés sous Service overview and network port requirements.

Retour arrière sécurisé et retrait

Ne supprimez pas une ressource de DC pendant une connexion en cours ou un test de basculement en production. Notez d’abord les groupes d’utilisateurs, ports, enregistrements SRV, Priority et Weight attribués, puis vérifiez qu’au moins un DC testé du même groupe de priorité ou le DC de secours prévu reste accessible.

Pour annuler une modification, ouvrez My Products > ZTNA > Resources & Access et sélectionnez le resource name. Vous pouvez y modifier les détails de la ressource ou la supprimer. Commencez par rétablir les valeurs initiales notées pour toute modification incorrecte des ports, valeurs SRV ou groupes, puis enregistrez. Ne supprimez une ressource que lorsque son FQDN n’est plus nécessaire aux utilisateurs ou aux applications.

Sur l’appareil pilote, vérifiez ensuite à nouveau la résolution SRV, nltest /dsgetdc:example.com /force et le processus de connexion ou d’application concerné. Si aucun DC testé ne reste accessible, arrêtez-vous avant la suppression et escaladez le cas avec les valeurs sauvegardées. Une suppression terminée ne peut pas être annulée. Si la ressource a déjà été supprimée, seul un administrateur qualifié peut la recréer manuellement à partir des paramètres consignés, réattribuer les groupes, puis répéter la validation complète. Si l’identité ou l’état de la ressource doit être préservé, ou si les relevés sont incomplets, ne la recréez pas et escaladez le cas.

Exploitation, révision et cycle de vie

Priority, Weight et TTL doivent figurer dans la documentation d’exploitation de l’environnement AD. Réexaminez l’attribution après toute modification des sites de DC, FQDN, services proposés, ports ou groupes d’utilisateurs. La réattribution d’un groupe Entra ID renommé constitue une étape d’exploitation distincte ; aucune mise à jour automatique n’a lieu.

Aucune instruction spécifique de migration, de retrait ou de fin de vie n’est documentée pour cette fonction. Après une mise à jour du produit, consultez d’abord l’aide actuelle sur les ressources et les champs visibles dans le tenant, puis validez de nouveau les modifications sur un appareil pilote limité.

Guides existants connexes

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.