Connecter Active Directory à Sophos Firewall

Active Directory reste la source centrale pour les utilisateurs, les groupes et l’authentification dans beaucoup d’environnements Sophos Firewall. La liaison AD sert par exemple aux règles basées sur les utilisateurs, au Remote Access VPN, au Captive Portal, au User Portal, au reporting ou aux scénarios de Single Sign-On.

Cet article explique comment ajouter un serveur Active Directory dans Sophos Firewall, quels champs sont vraiment importants et comment vérifier la connexion ensuite. Pour de nouveaux designs Remote Access, il faut aussi décider si AD classique, RADIUS ou Microsoft Entra ID SSO pour Sophos Connect et VPN Portal est le meilleur choix.

Si Active Directory devient la cible d’un environnement eDirectory existant, il faut d’abord planifier la migration contrôlée d’eDirectory, avec vérification des groupes, bascule service par service et retour arrière.

La vidéo Sophos Techvids suivante montre le processus de base en complément visuel. Elle a été réalisée avec SFOS v21. La logique reste utile, mais certaines interfaces peuvent être légèrement différentes dans SFOS 22.

Le déroulement pratique se compose de quatre parties. Un test de connexion réussi n’est qu’un début ; VPN, portail, règles utilisateur et SSO doivent être validés séparément.

1. Ajouter le serveur : renseigner correctement le Domain Controller, le domaine NetBIOS, la base de recherche et le compte de service.
2. Protéger la connexion : planifier consciemment LDAPS, la validation du certificat et la résolution DNS interne.
3. Importer les groupes : importer uniquement les groupes AD nécessaires et comprendre la Main Group.
4. Tester l’utilisation : vérifier login, MFA, VPN, User Portal, Captive Portal, SSO et Log Viewer.

Vue d’ensemble

Sophos Firewall peut utiliser plusieurs sources d’authentification. Active Directory est utile lorsque les utilisateurs et les groupes sont déjà gérés dans un domaine Windows local et que la firewall doit utiliser directement ces identités.

Cas d’utilisation typiques :

• synchronisation des utilisateurs et groupes depuis l’Active Directory local
• règles firewall avec référence à des utilisateurs ou des groupes
• Remote Access VPN avec des utilisateurs AD
• User Portal ou Captive Portal avec des comptes de domaine
• reporting par utilisateur au lieu d’une simple adresse IP
• Active Directory SSO avec NTLM ou Kerberos

Une liaison AD ne résout cependant pas automatiquement toutes les questions d’authentification. Il faut distinguer si la firewall interroge seulement les utilisateurs via LDAP/LDAPS, si des groupes sont importés, si SSO est utilisé ou si Remote Access nécessite aussi MFA. Pour les bases MFA, voir Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access.

Décisions importantes avant la configuration

Avant d’ajouter le serveur, il faut clarifier les points suivants :

• Connexion : utiliser si possible LDAPS avec SSL/TLS sur le port 636.
• Compte de service : utiliser un compte AD dédié avec droits de lecture au lieu d’un Domain Admin.
• Base de recherche : rechercher uniquement les OUs nécessaires, pas tout le domaine sans raison.
• Attribut d’affichage : choisir consciemment sAMAccountName, userPrincipalName ou displayName.
• Groupes : importer uniquement les groupes réellement utilisés pour firewall, VPN ou portail.
• MFA : protéger Remote Access et les portails avec MFA.
• Ordre des serveurs : définir consciemment l’ordre d’interrogation si plusieurs serveurs AD existent.
• Exploitation : Contrôler régulièrement les auth logs, l’import des groupes, les certificats et l’expiration du mot de passe.

Il faut aussi définir le routage et le chemin source entre la firewall et le Domain Controller. LDAPS nécessite TCP 636, STARTTLS TCP 389 ; la résolution DNS interne et une chaîne de certificats complète et valide doivent fonctionner depuis le chemin réellement utilisé par la firewall. Avant la modification, créer et télécharger une sauvegarde chiffrée de la configuration sous Backup and firmware > Backup and restore, puis conserver son mot de passe en lieu sûr.

⚠️ La connexion entre la firewall et le serveur d’authentification doit être chiffrée. LDAP non chiffré sur le port 389 peut fonctionner en laboratoire, mais ce n’est pas une bonne solution durable en production.

L’intégration AD prend aussi en charge d’anciennes versions de Windows Server. Dans les environnements actuels, Windows Server 2016, 2019, 2022 et 2025 sont toutefois les versions les plus pertinentes. Depuis SFOS 21.5 MR1, Active Directory SSO avec Windows Server 2025 est possible pour NTLM et Kerberos. SFOS 22 contient des composants Samba mis à jour pour l’authentification Kerberos et NTLM et supprime d’anciens algorithmes de chiffrement. Après une mise à niveau de firewall ou de Domain Controller, il faut donc tester explicitement AD SSO, l’import des groupes et Remote Access.

Important : l’application stricte de LDAP Channel Binding et LDAP Signing n’est actuellement pas prise en charge par Sophos Firewall. Si les Domain Controllers imposent des règles LDAP très strictes, la liaison AD doit être testée dans une fenêtre de maintenance avant une bascule productive.

Ajouter un serveur Active Directory

La configuration se fait dans le WebAdmin de Sophos Firewall :

Authentication > Servers

Créer un nouveau serveur d’authentification avec Add et sélectionner Active Directory comme Server Type.

Champs de la configuration Active Directory

La numérotation dans la capture d’écran est volontaire : les champs importants sont expliqués de haut en bas. Selon la version SFOS, l’ordre peut varier légèrement. Dans les versions récentes, on voit aussi Validate server certificate si la validation du certificat doit être activée pour LDAPS.

1. Server type : pour un domaine Windows classique, utiliser Active Directory. Les autres types comme RADIUS, LDAP ou Microsoft Entra ID sont d’autres modes d’intégration et ne doivent pas être mélangés.
2. Server name : nom d’affichage interne sur la firewall. Il n’a pas d’influence sur DNS ou AD, mais doit être clair, par exemple AD-ZH-DC01 ou AD-HQ-LDAPS. Avec plusieurs Domain Controllers, un nom propre aide dans le Log Viewer et le troubleshooting.
3. Server IP/domain : adresse IP ou nom DNS du Domain Controller. Un nom DNS est plus propre si le certificat, la résolution DNS interne et le failover sont cohérents. Une IP est plus simple à déboguer, mais lie directement la firewall à un Domain Controller précis.
4. Port : port de la connexion LDAP. En production, 636 avec SSL/TLS est la variante préférée. 389 est utilisé pour LDAP non chiffré ou STARTTLS, mais ne devrait pas être la solution durable lorsque l’authentification utilisateur est utilisée en production.
5. NetBIOS domain : nom NetBIOS court du domaine AD, par exemple AVANET. Ce n’est pas le nom DNS du domaine. Un mauvais NetBIOS provoque souvent des problèmes où les utilisateurs existent mais ne sont pas correctement trouvés ou associés.
6. ADS user name : nom du compte utilisé pour les requêtes AD. Sophos emploie le nom court administrator dans son exemple. En production, Avanet recommande plutôt un compte de service dédié autorisé à rechercher, lire et interroger l’appartenance aux groupes, et non un compte Domain Admin. Sophos ne confirme pas de manière générale que le nom court, DOMAIN\user et l’UPN sont équivalents dans toutes les configurations ; il faut donc employer et documenter le format testé dans son propre environnement AD.
7. Password : mot de passe du compte de service. S’il expire ou est modifié, les requêtes utilisateurs, l’import des groupes, les connexions VPN ou les portails peuvent cesser de fonctionner. Le compte doit donc être documenté et surveillé.
8. Connection security : définit si et comment la connexion est protégée. Pour LDAPS, utiliser SSL/TLS avec le port 636. STARTTLS utilise normalement le port 389, mais suppose que le Domain Controller le propose correctement. Plaintext est non chiffré et devrait être réservé aux tests.
9. Display name attribute : attribut AD utilisé pour le nom affiché sur la firewall. Sa valeur doit correspondre au schéma de l’annuaire et être validée avec un utilisateur de test ; la documentation générale de Sophos ne présente pas de valeurs standard qui seraient interchangeables dans tous les cas. Pour Microsoft Entra Domain Services, Sophos indique explicitement DisplayName.
10. Email address attribute : attribut pour l’adresse e-mail. Généralement mail. Ce champ n’est utile que si les adresses e-mail sont réellement maintenues dans l’AD. Sinon, les informations utilisateur restent vides ou incohérentes.
11. Domain name : nom DNS du domaine AD, par exemple ad.example.com. Ce n’est pas le nom NetBIOS. Il doit correspondre au domaine, à la base de recherche et au Domain Controller utilisé.
12. Search queries : base de recherche pour les requêtes utilisateurs et groupes. On saisit ici des Distinguished Names comme DC=ad,DC=example,DC=com ou, de manière plus ciblée, OU=Users,OU=Company,DC=ad,DC=example,DC=com. Une OU ciblée limite les utilisateurs visibles et garde l’import lisible.

Seuls les utilisateurs couverts par au moins une Search query peuvent apparaître pour ce serveur AD sous Current activities > Live users. Si un utilisateur attendu manque malgré un Test connection réussi, vérifier d’abord que le Base DN et le périmètre de l’OU incluent son objet réel dans l’annuaire. La base de recherche n’est pas élargie préventivement à tout le domaine.

Si plusieurs Domain Controllers existent, il faut décider consciemment si la firewall contacte un DC précis ou si un nom DNS interne stable pointe vers une infrastructure AD adaptée. DNS, certificat, routage et règles firewall doivent être cohérents.

Automatisation AD lors du passage de SFOS 22 à SFOS 23 : La documentation API pour l’ajout et la modification d’un serveur AD utilise dans SFOS 23 des libellés de tableau plus restreints que dans SFOS 22 : ServerIpDomain/ServerAddress devient ServerAddress, ServerName/NetBIOSDomain devient NetBIOSDomain et ADSUsername/Administrator/Username devient ADSUsername/Administrator. En revanche, l’exemple XML utilise sans changement dans les deux versions les éléments ServerAddress, NetBIOSDomain et ADSUsername. Cela atteste d’un changement des libellés dans la documentation, et non du rejet des anciens alias par la firewall ou d’un changement de nom des champs WebAdmin expliqués ci-dessus. L’exemple, qui présente des incohérences internes, n’est pas un modèle API vérifié et directement exécutable.

Les libellés de sécurité de connexion restent eux aussi distincts : Plaintext est le libellé WebAdmin ; la documentation API indique pour ConnectionSecurity les valeurs Simple, SSL et StartTLS. Les libellés de l’interface graphique ne doivent pas être repris comme valeurs API sans vérification.

Les tableaux de statuts et de messages documentés pour Add et Edit diffèrent également entre SFOS 22 et SFOS 23. À eux seuls, ces tableaux ne garantissent ni les codes de réponse réels ou les textes des messages renvoyés, ni les statuts de transport HTTP, ni la possibilité de réessayer sans risque. Lors de la migration de l’automatisation AD, il faut donc vérifier l’interprétation des réponses à partir de la documentation API de la version utilisée et de réponses réellement enregistrées, plutôt que de reprendre sans changement les anciennes correspondances d’erreurs. Il faut ensuite contrôler la configuration AD enregistrée et la connexion d’un utilisateur de test normal au service prévu.

Validate server certificate

Dans les versions SFOS actuelles, Validate server certificate peut être activé. C’est judicieux pour LDAPS, car la firewall ne fait alors pas seulement une connexion chiffrée : elle vérifie aussi si elle fait confiance au certificat du Domain Controller.

Les points suivants doivent être corrects :

1. Le certificat serveur du Domain Controller est téléversé sous Certificates > Certificates > Add > Upload certificate. Un certificat de CA seul doit en revanche être importé sous Certificates > Certificate authorities ; il ne faut pas confondre ces deux listes.
2. Conformément aux instructions de Sophos, saisir le CNAME dans Server IP/domain ; ce nom DNS doit figurer dans le Subject Alternative Name du certificat serveur.
3. La firewall peut résoudre le CNAME en interne.
4. La date et l’heure de la firewall et du Domain Controller sont correctes.

Si la résolution DNS interne ne résout pas correctement un CNAME ou le nom du Domain Controller, une entrée DNS Host Entry sous Network > DNS > DNS host entry peut aider.

Domaine NetBIOS et nom de domaine

Sophos Firewall a besoin à la fois du domaine NetBIOS et du nom DNS du domaine. Ces valeurs doivent correspondre exactement au domaine AD.

On peut par exemple trouver le domaine NetBIOS dans Active Directory Users and Computers, dans les propriétés du domaine.

Le nom de domaine est le nom DNS du domaine, par exemple ad.example.com.

Erreurs fréquentes à cet endroit :

• le nom NetBIOS et le nom DNS du domaine sont confondus ;
• le Domain Controller saisi appartient à un autre domaine ;
• la firewall ne peut pas résoudre le nom DNS du Domain Controller ;
• une firewall réseau ou Windows bloque la connexion entre la firewall et le Domain Controller.

Compte de service et mot de passe

Pour accéder à Active Directory, il faut utiliser un compte de service dédié. Un compte Domain Admin n’est pas nécessaire pour une requête LDAP normale et augmente inutilement le risque.

Bonnes pratiques :

• compte dédié pour la firewall, par exemple svc-sophos-fw-ldap
• uniquement les droits de lecture nécessaires
• owner documenté pour les changements de mot de passe
• mot de passe long et unique
• pas de connexion interactive si les règles AD le permettent proprement
• monitoring ou rappel avant expiration du mot de passe

Si le mot de passe du compte de service expire ou est modifié, la firewall ne peut plus interroger les utilisateurs et groupes. Cela apparaît ensuite souvent comme un problème VPN, portail ou règle utilisateur, alors que la cause se trouve dans la liaison AD.

Sécurité de connexion et LDAPS

En production, il faut privilégier LDAPS. Le Domain Controller doit disposer d’un certificat serveur approprié. Lorsque Validate server certificate est activé, suivre la procédure Sophos décrite ci-dessus pour importer le certificat serveur ; tout certificat de CA également nécessaire s’importe séparément comme Certificate Authority.

Points à vérifier :

• le port 636 est joignable depuis l’interface de la firewall vers le Domain Controller ;
• le certificat du Domain Controller est valide ;
• le nom du certificat correspond au nom DNS utilisé ;
• le certificat serveur et, le cas échéant, la CA émettrice sont importés dans leurs listes de certificats respectives
• l’heure et la date sont correctes sur la firewall et le Domain Controller.

Une limite importante du produit subsiste : SFOS 22 ne prend actuellement pas en charge l’application stricte de LDAP Channel Binding et de LDAP Signing. LDAPS avec validation du certificat protège la connexion, mais ne prouve pas la conformité à une stratégie de sécurité AD qui impose le channel binding ou le signing. Si l’organisation exige cette application, valider l’intégration par rapport à la stratégie AD précise avant le déploiement et ne pas l’approuver sur la seule base d’un Test connection réussi.

Pour les sujets liés aux certificats, la distribution de la CA est aussi importante. Pour distribuer la CA Sophos Firewall aux clients, voir Distribuer le certificat CA Sophos Firewall pour HTTPS Scanning. Pour LDAPS, c’est en revanche la CA du Domain Controller ou de la PKI interne qui est déterminante.

Connecter Microsoft Entra Domain Services

Un domaine géré Microsoft Entra Domain Services peut être connecté comme un serveur Active Directory. Sophos cite WebAdmin, Captive Portal, User Portal, Client Authentication Agent et Remote Access SSL VPN pour cette intégration. Il ne s’agit pas d’une connexion SSO directe à Entra ID ; cette documentation n’en déduit notamment pas une prise en charge du VPN Portal.

Pour la production, activer Secure LDAP et autoriser le port 636 depuis le chemin choisi de la firewall vers le domaine géré. Le certificat serveur doit contenir l’Extended Key Usage Server Authentication. Si possible, utiliser une connexion privée via les réseaux Azure ou IPsec plutôt que de rendre LDAPS accessible publiquement, puis limiter l’accès dans la Network Security Group à l’adresse source requise.

La configuration d’exemple officielle de Sophos utilise l’adresse IP Secure LDAP publique, SSL/TLS, le port 636, DisplayName et mail, et désactive Validate server certificate. La connexion privée via les réseaux Azure ou IPsec constitue une recommandation de sécurité supplémentaire de Sophos. En revanche, la validation du certificat avec un nom correspondant et une chaîne de confiance correcte est une recommandation de durcissement d’Avanet qui doit être testée dans l’environnement concerné avant la production ; elle ne doit pas être présentée comme faisant partie de l’exemple officiel. Les utilisateurs Entra doivent auparavant se connecter et changer leur mot de passe afin que les hashes Kerberos/NTLM soient créés et synchronisés ; le compte de bind doit appartenir au groupe d’administrateurs Entra Domain Services configuré.

Attribut d’affichage et attribut e-mail

L’attribut d’affichage détermine comment les utilisateurs apparaissent dans Sophos Firewall. Les attributs d’annuaire que l’on peut rencontrer et qu’il faut vérifier dans son propre environnement avant de les utiliser comprennent :

• sAMAccountName
• userPrincipalName
• displayName
• name

Ces valeurs ne sont pas interchangeables de manière générale. Le schéma de l’annuaire, l’unicité et le résultat avec un utilisateur de test sont déterminants. Pour Entra Domain Services, Sophos documente DisplayName ; cela ne constitue pas une règle générale pour l’AD local.

Les attributs peuvent être vérifiés dans Active Directory Users and Computers si Advanced Features est activé.

L’attribut e-mail est généralement mail. Il est surtout pertinent lorsque la firewall doit associer des informations liées aux e-mails aux utilisateurs.

Base de recherche et groupes

La base de recherche définit quelle partie de l’Active Directory la firewall parcourt. Pour tout un domaine, un exemple serait :

DC=ad,DC=example,DC=com

Pour une seule OU, le chemin peut ressembler à ceci :

OU=Users,OU=Company,DC=ad,DC=example,DC=com

Le Distinguished Name d’une OU se trouve dans les attributs de l’OU dans Active Directory Users and Computers.

Une base de recherche trop large fonctionne souvent, mais rend la configuration moins lisible. En production, il vaut mieux :

• utiliser une OU dédiée ou une base de recherche claire pour les utilisateurs pertinents ;
• créer des groupes AD séparés pour VPN, portails ou règles firewall ;
• éviter de réutiliser au hasard de grands groupes de département ;
• tester l’import des groupes après chaque changement ;
• supprimer régulièrement les groupes anciens ou vides.

Des imports de groupes trop larges peuvent aussi surcharger à long terme la gestion interne des utilisateurs de la firewall. Si de très nombreux anciens utilisateurs ou groupes apparaissent et que les téléchargements du VPN Portal échouent de manière inattendue, il faut vérifier la limite User-ID de Sophos Firewall.

Important pour Remote Access : dans SFOS 21.5 MR1, Sophos a modifié le comportement afin que L2TP et PPTP ne soient plus automatiquement activés lors de l’import de groupes depuis Active Directory et Microsoft Entra ID. Cela réduit la surface d’attaque involontaire, mais doit être vérifié après une mise à niveau si d’anciens processus Remote Access dépendaient de ce comportement. Configurer L2TP Remote Access sur Sophos Firewall explique l’affectation explicite des membres, la limite du groupe principal et la validation.

Importer les groupes et comprendre les utilisateurs

Après l’ajout du serveur AD, les groupes AD ne sont pas automatiquement tous présents dans la firewall. Les groupes sont importés via l’assistant d’import :

Authentication > Servers > Import

Le processus est le suivant :

1. Sélectionner le serveur AD et lancer Import.
2. Choisir le Base DN pour la recherche des groupes.
3. Sélectionner les groupes AD nécessaires.
4. Vérifier les Group Policies communes.
5. Contrôler la sélection et terminer l’import.
6. Vérifier sous Authentication > Groups que les groupes sont bien présents.

Si AD doit être la méthode d’authentification principale de cette procédure, aller sous Authentication > Services, sélectionner le serveur AD configuré dans Firewall authentication methods, le déplacer en première position dans la liste des serveurs sélectionnés et cliquer sur Apply. Vérifier ensuite les groupes importés sous Authentication > Groups et demander à un utilisateur de test de se reconnecter pour actualiser son affectation aux groupes. Cette première position concerne la procédure avec AD comme méthode principale, et non tous les ordres de serveurs existants.

Les utilisateurs apparaissent sous Authentication > Users seulement lorsqu’ils se connectent à un service, par exemple au User Portal, VPN Portal, Captive Portal ou via Remote Access VPN. À chaque connexion, la firewall vérifie de nouveau quelles groupes importés correspondent à l’utilisateur et met l’association à jour.

Si aucun groupe AD d’un utilisateur n’existe sur la firewall, celui-ci reçoit la Default group configurée sous Authentication > Services. La valeur par défaut du produit est Open group. Il faut néanmoins vérifier la valeur effective avant le déploiement, car elle peut avoir été modifiée et détermine directement les paramètres hérités.

Dans les environnements HA, les groupes AD sont importés sur l’équipement Primary. Cela vaut aussi pour le nettoyage des anciens utilisateurs AD avec Purge AD users.

La procédure complète pour exploiter et tester les stratégies de groupe, le Default Group, le groupe principal, les exceptions utilisateur et le comportement des groupes multiples selon la fonction figure dans Gérer correctement les groupes d’utilisateurs et le groupe principal sur Sophos Firewall.

Main Group, ordre des groupes et groupes imbriqués

Un utilisateur AD peut appartenir à plusieurs groupes. Sophos Firewall distingue alors :

• Group : premier groupe correspondant dans la liste des groupes de la firewall. C’est la Main Group de l’utilisateur.
• Other group memberships : autres groupes importés dont l’utilisateur est également membre.
• Group order : ordre sous Authentication > Groups. Cette valeur décide quel groupe devient la Main Group lorsqu’il y a plusieurs correspondances.

C’est important, car toutes les fonctions n’évaluent pas les groupes multiples. Certaines utilisent uniquement la Main Group. Si un utilisateur est dans plusieurs groupes AD, une autre policy peut donc s’appliquer que celle attendue.

L’ordre des groupes se modifie ici :

Authentication > Groups > Reorder

Les groupes AD imbriqués ne sont pas pris en charge. Si une firewall policy doit s’appliquer à un sous-groupe, ce sous-groupe doit être importé lui-même. Il ne suffit pas d’importer uniquement le groupe AD parent.

Le groupe AD primaire d’un utilisateur n’est pas non plus repris comme une appartenance de groupe normale. Cela concerne particulièrement le groupe standard AD Domain Users. Pour les firewall policies, il faut donc utiliser des groupes de sécurité explicites et ajouter les utilisateurs directement à ces groupes.

Fonctions qui prennent en charge plusieurs groupes

Pour l’exploitation, cette distinction est particulièrement importante.

Plusieurs groupes AD peuvent être pris en compte pour :

• Firewall rules : l’ordre des règles firewall reste déterminant.
• SSL/TLS inspection rules : la première règle d’inspection correspondante s’applique.
• Web policies : la règle firewall s’applique d’abord, puis la règle Web Policy correspondante.
• IPS policies : la policy de la règle correspondante est appliquée.
• Application control policies : l’évaluation se fait via la règle firewall correspondante.
• SD-WAN routes : les critères utilisateur ou groupe peuvent tenir compte de plusieurs groupes.
• Policy test : utile pour vérifier le matching des groupes et des policies.
• Remote access SSL VPN : les autorisations des policies Full Tunnel et Split Tunnel correspondantes sont prises en compte. Avec Full Tunnel, Full Tunnel a la priorité.
• Clientless SSL VPN : les autorisations des groupes correspondants sont combinées.

Seule la Main Group ou des utilisateurs explicites sont pris en compte pour :

• WAF rules
• Remote access IPsec VPN
• L2TP et PPTP
• Hotspots
• MFA, si MFA est appliqué spécifiquement à des groupes
• Surfing quota, Access time, Network traffic et Traffic shaping
• Quarantine digest, MAC binding et Sign-in restriction

Access Time Sophos Firewall pour les utilisateurs et les groupes montre comment vérifier le groupe principal pour un accès utilisateur dépendant de l’heure et distinguer les exceptions utilisateur.

La même limite de Main Group s’applique aux crédits de temps et de données basés sur la consommation. Surfing Quota et Network Traffic Quota sur Sophos Firewall présente la procédure complète.

Exemple pratique : un utilisateur est dans VPN-Users et Firewall-Admins. Pour SSL VPN, l’appartenance multiple peut fonctionner. Pour IPsec Remote Access ou l’association MFA par groupe, seule la Main Group peut toutefois compter. C’est pourquoi il faut tester consciemment quel groupe est défini comme Group dans l’objet utilisateur pour Remote Access et les accès administratifs.

Plusieurs serveurs Active Directory

On peut configurer plusieurs serveurs AD. Pour les Firewall authentication methods, une règle importante s’applique : la firewall ne passe au serveur suivant que si le précédent est injoignable ; un refus d’identifiants ne déclenche pas de fallback normal. Cet ordre n’est donc ni un mécanisme de répartition de charge ni un substitut à une architecture AD correctement planifiée.

Recommandations :

• définir consciemment l’ordre des serveurs sous Authentication > Services ;
• documenter proprement la base de recherche et le domaine par serveur ;
• éviter les groupes contradictoires portant le même nom dans différentes sources ;
• planifier proprement DNS et AD avec plusieurs UPNs ou plusieurs domaines ;
• tester le failover non seulement avec Test connection, mais avec une vraie connexion utilisateur ;
• si un serveur AD tombe en panne, le message d’erreur côté utilisateur peut ressembler à un mauvais mot de passe.

Si plusieurs UPNs appartiennent à la même infrastructure de domaine, les entrées DNS et la configuration du serveur AD doivent correspondre au domaine concerné. L’important est que base de recherche, Domain Name et résolution du serveur aillent ensemble.

Pour plusieurs domaines UPN sur le même serveur de domaine, Sophos décrit cette configuration précise : créer une entrée DNS pour chaque domaine pointant vers l’adresse IP de ce serveur et une configuration de serveur AD distincte sur la firewall pour chaque domaine. Utiliser le domaine AD concerné comme Search query au format DN LDAP, par exemple DC=ad,DC=example,DC=com pour ad.example.com. Remplacer ces valeurs par les domaines de l’environnement et vérifier la connexion et l’affectation aux groupes pour chaque domaine UPN. Il ne s’agit pas d’une procédure de répartition de charge ou de basculement entre plusieurs contrôleurs de domaine ; avec LDAPS, le nom de serveur utilisé doit toujours convenir à la validation du certificat.

Tester la connexion

Après l’enregistrement, la connexion doit être testée directement. Le test vérifie si la firewall atteint le serveur et si les données saisies sont globalement correctes.

Un test réussi ne signifie pas automatiquement que les règles utilisateur, SSO ou VPN fonctionnent déjà. Ensuite, au minimum, les points suivants doivent être vérifiés :

1. Les utilisateurs ou groupes AD sont trouvés correctement.
2. Un utilisateur de test peut se connecter à l’endroit prévu.
3. L’appartenance au groupe correspond à l’autorisation firewall ou VPN attendue.
4. Le Log Viewer affiche des événements d’authentification compréhensibles.
5. Remote Access VPN, User Portal ou Captive Portal fonctionnent avec un utilisateur de test normal.
6. MFA est demandé si c’est prévu pour le cas d’utilisation.
7. Le serveur AD est placé à la bonne position sous Authentication > Services dans les Firewall Authentication Methods.

S’il reste ensuite difficile de déterminer si l’échec concerne la sélection du service, l’identité de l’utilisateur, la Main Group, le quota ou seulement la règle firewall ultérieure, Résoudre méthodiquement les erreurs d’authentification sur Sophos Firewall sépare ces niveaux à l’aide d’un cas de test reproductible.

Pour Remote Access avec Sophos Connect, l’étape suivante est Configurer Sophos Connect Client sur Sophos Firewall.

Validation selon le cas d’utilisation

Après la liaison AD, il ne faut pas documenter uniquement un test de connexion. Les fonctions utilisent l’intégration AD de manière différente. Il faut donc effectuer un test séparé pour chaque cas d’utilisation prévu.

• Import de groupes : chercher le groupe AD pertinent et l’importer sur la firewall. Si quelque chose ne correspond pas, le groupe n’est pas trouvé ou contient des utilisateurs inattendus.
• User Portal : tester la connexion avec un utilisateur AD normal. Un symptôme typique est un login qui échoue alors que le test serveur est réussi.
• Remote Access VPN : vérifier login VPN, autorisation de groupe, MFA et accès aux destinations internes. En cas d’erreur, l’utilisateur peut s’authentifier sans recevoir la bonne policy ou sans obtenir l’accès.
• Règle firewall basée sur l’utilisateur : générer du trafic de test et vérifier utilisateur, groupe et Rule ID dans le Log Viewer. Si l’association ne fonctionne pas, le trafic apparaît seulement avec l’adresse IP ou touche une autre règle.
• Captive Portal : tester le login navigateur puis le trafic suivant. Les erreurs se manifestent souvent par un login réussi, mais une association utilisateur incorrecte ensuite.
• AD SSO ou STAS : vérifier Live Users et Log Viewer après la connexion Windows. En cas de problème, l’utilisateur reste inconnu ou est associé à une mauvaise IP.

Cette séparation fait gagner du temps en exploitation. Un test LDAP réussi prouve seulement que serveur, port, compte Bind et base de recherche sont globalement joignables. Il ne prouve pas que les groupes VPN sont correctement associés, que MFA s’applique ou que le trafic utilisateur est évalué avec identité dans les règles firewall.

Pour les règles basées sur les utilisateurs, il faut toujours générer un vrai test de trafic et vérifier dans le Log Viewer si le nom d’utilisateur, le groupe, la Firewall Rule ID et l’action correspondent à l’attente. Si seule l’adresse IP est visible, la cause se trouve souvent dans SSO, STAS, Captive Portal ou dans l’ordre des règles firewall. Pour les environnements STAS, voir Configurer STAS sur Sophos Firewall.

Si Sophos Endpoint envoie déjà Security Heartbeat, Synchronized User ID Authentication peut transmettre au pare-feu un utilisateur de domaine Windows 10 sans agent d’authentification supplémentaire. Le processus nécessite toujours la validation AD correspondante et un test réel de la règle.

Attention à Active Directory SSO

Active Directory SSO est un domaine d’exploitation distinct. La simple connexion au serveur AD en est une base, mais SSO nécessite aussi des conditions correctes côté client, navigateur, DNS, Kerberos ou NTLM.

Pour Web Authentication, Sophos Firewall prend en charge l’AD SSO classique avec Kerberos et NTLM. Kerberos est plus propre et plus rapide, mais il impose davantage d’exigences sur FQDN, DNS, SPN et confiance du navigateur. NTLM est plus tolérant et peut être un fallback pragmatique dans d’anciens environnements, mais il ne devrait pas devenir silencieusement la seule méthode qui fonctionne.

Sophos place NTLM, initié par le navigateur, après General Authentication Client, Clientless single sign-on et Client-based single sign-on. NTLM ne sert de fallback que lorsque ces attributions ne s’appliquent pas ; si NTLM échoue également, Captive Portal s’affiche. Si un utilisateur apparaît avec une méthode inattendue sous Current activities > Live users, il faut d’abord vérifier le Client type affiché et les sources d’identité déjà actives avant de modifier le SPN ou Web Authentication.

Le réglage Kerberos & NTLM propose les deux méthodes au navigateur, et le client décide laquelle utiliser. Il n’existe pas de mode Kerberos uniquement, car la spécification HTTP ne le prend pas en charge. Pour le trafic web transparent, la firewall redirige l’authentification vers le port TCP 8091.

Lorsque plusieurs utilisateurs partagent la même IP RDS ou de serveur de terminaux, l’association IP normale ne suffit pas. Pour le trafic HTTP et HTTPS envoyé exclusivement via un proxy explicite, Per-Connection AD SSO pour les hôtes multi-utilisateurs explique la procédure dédiée et sa distinction par rapport à SATC.

⚠️ Remarque de mise à niveau pour SFOS 22 : Après une mise à niveau de SFOS 21.5 ou antérieur vers SFOS 22.0 GA, l’AD SSO avec Kerberos et NTLM peut cesser de fonctionner. Les règles basées sur l’identité ne reconnaissent alors plus les utilisateurs de domaine concernés, tandis que les autres flux firewall continuent de passer. Sophos a corrigé l’erreur dans SFOS 22.0 MR1 Build 490. Il faut tester AD SSO avec un véritable trafic utilisateur avant et immédiatement après la mise à niveau. Réparer AD SSO après une mise à niveau SFOS 22 explique comment vérifier nasm.log, exécuter le nettoyage NASM ciblé et contrôler le résultat avec un véritable trafic utilisateur.

Le déroulement AD SSO est donc plus qu’un simple Test connection sur le serveur AD :

Sophos décrit l’enregistrement de la firewall dans le domaine Windows comme la création d’un objet pour la firewall sur le contrôleur de domaine principal. Ce contexte relève de la jonction au domaine pour AD SSO ; de simples requêtes d’annuaire LDAP/LDAPS ne nécessitent pas automatiquement cette jonction. Les droits nécessaires à la jonction restent distincts des droits de lecture du compte de liaison LDAP.

1. Définir un hostname ou FQDN sous Administration > Admin and user settings. Pour Kerberos, utiliser un FQDN en minuscules dont la partie hôte ne dépasse pas 15 caractères, afin que NetBIOS name, objet ordinateur AD et SPN ne divergent pas.

   Exemple : la firewall est configurée comme fw01.edge.example.com et le domaine AD s’appelle corp.example.com. Lors du Domain Join, SFOS associe le hostname NetBIOS fw01 au domaine AD. Le nom connu dans AD est donc fw01.corp.example.com, et non automatiquement le FQDN configuré sur la firewall. Le nom de redirection pour Kerberos transparent doit correspondre au SPN HTTP enregistré dans AD et être résolu par DNS.

2. Sous Administration > Admin and user settings, définir la Redirection Location de sorte que les clients puissent résoudre le nom et faire confiance à la cible. Dans les scénarios Kerberos transparents, ce nom doit correspondre au SPN. Un compte disposant d’un accès en lecture à AD peut exécuter cette requête ciblée et en lecture seule sur un système Windows :

   setspn -Q HTTP/fw01.corp.example.com
   

   Remplacer l’exemple par son propre FQDN de redirection. Le résultat doit indiquer exactement le SPN et l’objet ordinateur attendus ; avant le déploiement, clarifier avec le responsable AD l’absence de résultat ou un résultat associé à un autre objet.

3. Enregistrer le serveur AD sous Authentication > Servers et exécuter Test connection. Ce test vérifie la connectivité et les identifiants, mais ne prouve pas encore que l’AD SSO fonctionne.

4. Sous Authentication > Services, placer le serveur AD à la position souhaitée dans Firewall authentication methods. AD SSO ne passe au serveur suivant que si le précédent est injoignable, et non lorsque les identifiants sont refusés.

5. Sous Administration > Device access, activer AD SSO pour les zones nécessaires. Il s’agit généralement de LAN ou d’un réseau client interne clairement défini, pas de toutes les zones.

6. Sous Authentication > Web authentication, définir If Active Directory (AD) SSO is configured sur Kerberos & NTLM ou consciemment sur NTLM only.

7. Dans les règles firewall concernées, vérifier si Match known users et, pour les requêtes web inconnues, Use web authentication for unknown users correspondent au déroulement souhaité. Une règle séparée et clairement nommée pour HTTP et HTTPS est souvent plus simple à exploiter.

Sous Authentication > Services, HTTP challenge redirect on intranet zone devrait rester activé. Si un site web hébergé sur Internet déclenche un challenge NTLM, la firewall gère alors l’échange via son adresse IP d’interface locale dans la zone intranet. Si l’option est désactivée, le navigateur peut envoyer des identifiants via Internet. Il ne s’agit pas d’un réglage de compatibilité anodin.

Lorsque Use web authentication for unknown users authentifie du trafic HTTPS en mode transparent, la firewall déchiffre la connexion pour l’authentification, indépendamment des réglages de la règle firewall ou de la règle SSL/TLS Inspection. Cela doit correspondre au design TLS Inspection et certificats ; sinon AD SSO ressemble vite à un problème de navigateur, de certificat ou de webfilter.

Pour la validation, Log Viewer est décisif. Sous Log viewer > Authentication, le démarrage de la connexion AD SSO devrait afficher des messages comme Kerberos authentication initialized successfully et NTLM authentication channel established successfully. Les messages Cannot initialize Kerberos authentication ou Cannot establish NTLM authentication channel sont problématiques. La colonne Log Comp montre aussi si un client utilise Kerberos ou NTLM.

Sophos Firewall ne propose l’une des deux méthodes au navigateur qu’après l’initialisation réussie de Kerberos et de NTLM sur la firewall. Un fallback NTLM visible ne justifie donc pas de sauter le contrôle Kerberos. DNS, SPN et heure système doivent correspondre ; par défaut, les horloges impliquées dans Kerberos ne doivent pas différer de plus de cinq minutes.

Il faut distinguer les rôles des comptes. Le compte de liaison LDAP n’a besoin que des droits de lecture requis pour les requêtes d’annuaire. L’opération de jonction au domaine pour AD SSO exige en revanche un compte Domain Admin ou un compte disposant de droits délégués pour créer l’objet ordinateur ou le SPN. Une nouvelle jonction peut être nécessaire dans un environnement HA, avec plusieurs serveurs AD ou après une mise à niveau ; des identifiants de jonction adaptés doivent donc être disponibles, sans accorder ces droits élevés au compte de liaison LDAP.

Depuis SFOS 21.5 MR1, Windows Server 2025 est pris en charge pour Active Directory SSO avec NTLM et Kerberos. SFOS 22 apporte aussi des composants Samba mis à jour et supprime d’anciens algorithmes de chiffrement. Pour les administrateurs, cela signifie :

• tester explicitement AD SSO après les mises à niveau des Domain Controllers ;
• vérifier l’authentification et l’association utilisateur après les mises à niveau SFOS ;
• documenter les dépendances Kerberos/NTLM dans les anciens environnements ;
• ne pas prévoir d’ancien chiffrement comme solution durable ;
• vérifier les DNS request routes pour les domaines AD si la firewall ne trouve pas les service records AD via le résolveur normal ;
• ne pas confondre SSO avec Entra ID SSO pour Sophos Connect.

Si Entra ID SSO est prévu pour VPN ou VPN Portal, utiliser l’article séparé Configurer Microsoft Entra ID SSO pour Sophos Connect et VPN Portal. Il s’agit d’un autre modèle d’authentification que la liaison AD locale classique.

Troubleshooting

Le test de connexion échoue

Commencer par vérifier la joignabilité, le port, le routage et DNS. Contrôler ensuite la sécurité de connexion, le certificat, le compte de service et le mot de passe.

Contrôles pratiques :

• La firewall peut-elle atteindre le Domain Controller par IP ?
• Le nom DNS est-il correctement résolu ?
• Le port 389 ou 636 est-il joignable ?
• SSL/TLS correspond-il vraiment au port et au certificat ?
• Le compte de service est-il actif et non verrouillé ?
• Existe-t-il côté Windows des règles firewall ou des exigences LDAP Signing ?

L’utilisateur n’est pas trouvé

La base de recherche est alors souvent fausse ou trop restrictive. Vérifier le distinguishedName de l’OU et s’assurer que l’utilisateur se trouve réellement dans la base de recherche. L’orthographe, les accents, les caractères spéciaux et l’attribut d’affichage choisi peuvent aussi compliquer la recherche.

Le groupe est importé, mais l’accès ne fonctionne pas

Il faut alors vérifier toute la chaîne d’autorisation : groupe AD, groupe firewall importé, règle VPN/portail/firewall affectée, MFA et position de la règle. Pour Remote Access, la configuration VPN correspondante doit aussi être liée au groupe.

Si l’utilisateur est dans plusieurs groupes AD, vérifier également la Main Group sous Authentication > Users. MFA, Remote access IPsec VPN, WAF, Hotspots et plusieurs réglages liés aux utilisateurs tiennent notamment compte uniquement de la Main Group.

Les nouveaux utilisateurs AD ne peuvent pas se connecter au VPN Portal

Si un utilisateur AD existant peut utiliser le VPN Portal, mais qu’un utilisateur nouvellement créé avec des autorisations comparables ne le peut pas, il faut d’abord comparer l’affectation des groupes, la méthode de Remote Access et la version du firmware. Sous Authentication > Users, Group affiche la Main Group ; les autres groupes importés figurent sous Other group memberships. SSL VPN peut prendre en compte plusieurs appartenances à des groupes, tandis qu’IPsec Remote Access tient compte uniquement de la Main Group ou d’un utilisateur sélectionné explicitement.

Pour le diagnostic :

1. Comparer le nouvel utilisateur concerné à un utilisateur existant qui fonctionne.
2. Contrôler la Main Group et Other group memberships.
3. Sous Authentication > Services, vérifier les VPN portal authentication methods ; sous Administration > Device access, la zone source autorisée ; et dans la policy de Remote Access, l’utilisateur ou le groupe.
4. Relever la version et le build SFOS.

Sophos a corrigé avec NC-180824 un problème qui empêchait les nouveaux utilisateurs AD appartenant à une Secondary AD Group de se connecter au VPN Portal. Le correctif est inclus dans SFOS 22.0 MR2 Build 546, publié le 14 juillet 2026. Sophos n’indique ni la version dans laquelle le problème a été introduit ni un workaround officiel. Si la configuration et la logique des groupes sont correctes, il faut mettre à jour une ancienne installation concernée vers SFOS 22.0 MR2 ou une version ultérieure, puis refaire le test avec un utilisateur AD se connectant à la firewall pour la première fois et dont l’autorisation VPN est accordée exclusivement via la Secondary Group concernée dans une policy SSL VPN.

⚠️ Ne pas réordonner les groupes sur la base d’un soupçon, ne pas purger prématurément les utilisateurs avec Purge AD users et ne pas recréer les groupes. Sophos ne documente pas ces mesures comme solutions à NC-180824, et elles peuvent modifier d’autres autorisations.

Un nouveau groupe AD n’apparaît pas automatiquement

Les groupes AD nouvellement créés ne sont pas synchronisés automatiquement dans la firewall. Le groupe doit être réimporté via l’assistant d’import ou créé manuellement comme groupe correspondant. Ensuite, un utilisateur de test doit se reconnecter afin que la firewall réévalue les appartenances aux groupes.

Un utilisateur supprimé dans l’AD reste visible sur la firewall

Les utilisateurs AD qui se sont déjà connectés peuvent rester visibles sur la firewall. Si des utilisateurs ont été supprimés dans l’AD, il faut d’abord les supprimer dans l’AD puis utiliser Purge AD users sur la firewall. Dans les environnements HA, cela se fait sur l’équipement Primary.

La connexion fonctionne, mais la règle utilisateur ne s’applique pas

Dans ce cas, LDAP n’est généralement pas le problème. La cause se trouve plutôt dans l’association utilisateur, SSO, la position de la règle ou le logging. Dans le Log Viewer, il faut voir si le trafic est évalué avec une identité utilisateur ou seulement avec une adresse IP. Pour analyser les règles, voir Tester une règle firewall avec Log Viewer, Policy Test et Packet Capture.

AD SSO retombe sur Captive Portal ou NTLM

Si AD SSO ne fonctionne pas de manière transparente, la Redirection URL, le SPN, la résolution DNS ou la confiance du navigateur sont généralement impliqués. Pour Kerberos, le nom vers lequel la firewall redirige doit appartenir au HTTP SPN correspondant et être résolvable par le client. Pour NTLM, le navigateur doit considérer le nom cible comme fiable, sinon il demande des identifiants ou retombe sur le Captive Portal.

En pratique, vérifier d’abord Administration > Admin and user settings, la résolution DNS du nom de redirection, setspn -Q HTTP/fw01.corp.example.com sur un client Windows et Log viewer > Authentication. Si seul NTLM apparaît au lieu de Kerberos, c’est souvent un signe de problème SPN ou de confiance du navigateur, pas forcément d’une connexion AD serveur défectueuse.

Le certificat sélectionné sous Admin console and end-user interaction > Certificate doit couvrir le hostname ou le FQDN de redirection et être approuvé par les endpoints. Le certificat autosigné préinstallé de la firewall ne remplit normalement aucune de ces deux conditions pour un nouveau nom. Un avertissement de certificat ne doit pas être ignoré, mais résolu avec un certificat public ou interne correspondant.

Pour NTLM, la confiance peut être limitée au nom de redirection interne. Sous Windows, Microsoft Edge et Google Chrome reprennent le réglage de Internet Options > Security > Local intranet > Sites > Advanced. Dans Firefox, ajouter le même FQDN à network.automatic-ntlm-auth.trusted-uris sous about:config. Autoriser uniquement le nom interne réellement utilisé, et non un domaine large ou des sites web quelconques.

Après une mise à niveau, certains logins ne fonctionnent plus

Après une mise à niveau SFOS ou Domain Controller, il faut porter une attention particulière à SSO, Kerberos/NTLM, anciens algorithmes de chiffrement, certificats et import des groupes. Si seuls certains utilisateurs sont concernés, vérifier aussi les caractères spéciaux, espaces, UPN, appartenances aux groupes et état du mot de passe.

Pour les logs d’authentification et de services, voir Sophos Firewall Troubleshooting : services et logs.

La connexion ne fonctionne pas avec validation du certificat activée

Si Validate server certificate est activé, certificat, CNAME, résolution DNS et confiance CA doivent être cohérents. Les causes fréquentes sont un certificat avec un autre nom, une CA interne manquante sur la firewall ou un CNAME que la firewall ne peut pas résoudre.

Annuler la modification et poursuivre l’exploitation en sécurité

Avant toute modification, documenter l’ordre des serveurs, les services utilisés, les groupes et les paramètres de certificat. Si la recette échoue, rétablir d’abord l’ordre précédent ainsi que le mode de connexion chiffré et le port d’origine. Un essai en Plaintext sur le port 389 reste exclusivement un bref diagnostic et ne doit jamais devenir la configuration de production après le retour arrière.

Si toute la configuration doit être restaurée, utiliser la sauvegarde téléchargée auparavant sous Backup and firmware > Backup and restore. Cette opération remplace la configuration actuelle, annule les changements ultérieurs et redémarre la firewall ; elle doit donc avoir lieu dans une fenêtre de maintenance. Un rollback firmware démarre la partition précédente avec sa configuration et coupe également les sessions. Le rollback automatique du firmware ne s’applique qu’à l’échec d’une migration de configuration, pas à une panne AD SSO qui n’apparaît qu’en exploitation.

Après chaque retour arrière, répéter Test connection, une connexion normale à un service, le contrôle de l’effet des groupes et, pour SSO, un accès utilisateur réel avec vérification de Log viewer > Authentication. En HA, l’import des groupes et Purge AD users s’effectuent sur l’équipement Primary ; ne tester la panne du DC secondaire prévu que dans une fenêtre de maintenance autorisée, en confirmant que le premier serveur est réellement injoignable et que la connexion réussit via le second.

Checklist d’exploitation

Avant la configuration :

• Domain Controller, port et nom DNS définis.
• LDAPS et chaîne de certificats vérifiés.
• Compte de service dédié créé.
• Base de recherche et groupes pertinents définis.
• Design MFA et Remote Access clarifié.

Après la configuration :

• Test de connexion réussi.
• Serveur AD placé comme Authentication Method primaire ou adaptée.
• Utilisateur et groupe de test vérifiés.
• Groupes AD importés via l’assistant d’import.
• Main Group d’un utilisateur de test contrôlée.
• En cas de groupes multiples : connexion au VPN Portal testée avec un utilisateur existant et un utilisateur se connectant à la firewall pour la première fois, dont l’autorisation est accordée exclusivement via une Secondary Group dans une policy SSL VPN.
• Remote Access, portail ou règle utilisateur testés avec un utilisateur normal.
• Le Log Viewer affiche les événements d’authentification attendus.
• Pour AD SSO, les messages Kerberos/NTLM ont été vérifiés dans l’Authentication log.
• L’expiration du mot de passe du compte de service est documentée.
• Test de mise à niveau prévu pour AD SSO, import des groupes et processus VPN.

En exploitation :

• Supprimer les groupes qui ne sont plus nécessaires.
• Importer activement les nouveaux groupes AD, ne pas attendre une synchronisation automatique.
• Vérifier régulièrement le compte de service.
• Renouveler les certificats LDAPS avant expiration.
• Contrôler l’ordre des groupes après des changements AD.
• Utiliser des Named Admins et MFA pour les accès administratifs.
• Ne pas traiter les erreurs d’authentification uniquement comme un problème utilisateur : vérifier aussi AD, réseau, certificats et règles firewall.

FAQ