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.

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 : vérifier régulièrement les logs d’authentification, l’import des groupes, les certificats et l’expiration du mot de passe.

⚠️ 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 de service utilisé par la firewall pour les requêtes AD. Il faut utiliser un compte dédié avec droits de lecture, pas un Domain Admin. Selon l’environnement, le nom court, DOMAIN\user ou un UPN comme svc-firewall-ldap@example.local peut fonctionner.
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. Simple est non chiffré et devrait être réservé aux tests.
9. Display name attribute : attribut AD utilisé par la firewall comme nom d’affichage. Les valeurs fréquentes sont sAMAccountName, userPrincipalName, displayName ou name. Pour l’exploitation et le troubleshooting, un attribut unique est plus important qu’un nom agréable à lire.
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 example.local ou 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 y entre des Distinguished Names comme DC=example,DC=local ou plus précisément OU=Users,OU=Company,DC=example,DC=local. Plus la base est ciblée, plus l’import reste clair et performant.

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.

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. La CA qui a émis le certificat du Domain Controller est connue sur la firewall sous Certificates > Certificates.
2. La valeur dans Server IP/domain correspond au nom du certificat ou à un Subject Alternative Name du certificat.
3. Si un CNAME est utilisé, la firewall peut résoudre ce nom 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 example.local ou 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

Pour les environnements de production, LDAPS est à privilégier. Le Domain Controller doit disposer d’un certificat adapté et la firewall doit faire confiance à la CA émettrice.

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é ;
• la CA émettrice est connue sur la firewall si la validation est activée ;
• l’heure et la date sont correctes sur la firewall et le Domain Controller.

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.

Attribut d’affichage et attribut e-mail

L’attribut d’affichage détermine la manière dont les utilisateurs sont affichés dans Sophos Firewall. Valeurs typiques :

• sAMAccountName
• userPrincipalName
• displayName
• name

sAMAccountName est souvent robuste et court dans les environnements AD classiques. userPrincipalName est plus proche des noms de connexion modernes et des identités cloud. displayName est agréable à lire, mais pas toujours assez unique pour l’exploitation et le troubleshooting.

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=example,DC=local

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

OU=Users,OU=Company,DC=example,DC=local

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.

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.

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 un utilisateur n’est trouvé dans aucun groupe AD importé, il est placé dans la Default Group. Cette Default Group se trouve sous Authentication > Services dans les Firewall Authentication Methods. Par défaut, il s’agit souvent de Open group.

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.

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

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. La firewall valide alors les utilisateurs dans l’ordre configuré dans le WebAdmin. Ce n’est pas un remplacement pour un design AD proprement planifié.

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.

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.

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.

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.

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

1. Définir un hostname ou FQDN sous Administration > Admin and user settings. Pour Kerberos, utiliser un FQDN, en minuscules, avec une partie hôte de 15 caractères au maximum afin que NetBIOS name, objet ordinateur AD et SPN restent cohérents.
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. Sur un client Windows, setspn -Q HTTP/* aide à vérifier les SPN HTTP existants.
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 utilise les serveurs dans cet ordre et ne passe au serveur suivant que si le précédent n’est pas joignable.
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.

Si Use web authentication for unknown users doit authentifier du trafic HTTPS en mode transparent, la firewall peut déchiffrer la connexion pour le processus d’authentification. 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.

La question du compte est importante. Pour des requêtes LDAP normales, un Domain User avec droits de lecture suffit souvent. Pour AD SSO, la firewall doit toutefois rejoindre le domaine et pouvoir créer un objet ordinateur ou un SPN. Il faut donc soit un compte Domain Admin, soit un compte avec des droits de domain join délégués proprement. Dans les environnements HA, avec plusieurs serveurs AD ou après des upgrades, la firewall peut devoir rejoindre de nouveau le domaine. Il ne faut donc pas rejoindre une fois avec Domain Admin puis passer à un compte plus faible si ce compte ne peut pas effectuer le rejoin plus tard.

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.

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/* 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.

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.

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.
• Remote Access, portail ou règle utilisateur testé avec un utilisateur normal.
• Log Viewer affiche les événements d’authentification attendus.
• Expiration du mot de passe du compte de service 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