Configurer Microsoft Entra ID SSO pour Sophos Connect et le portail VPN

Avec Microsoft Entra ID SSO, le Sophos Firewall peut authentifier les utilisateurs pour le portail VPN ainsi que pour l’accès à distance via Sophos Connect contre Microsoft Entra ID. Pour de nombreux environnements Microsoft 365, cela est plus logique que des mots de passe locaux distincts pour le pare-feu, car l’identité, l’accès conditionnel et le MFA sont gérés de manière centralisée dans le fournisseur d’identité.

Cependant, cet avantage n’est réel que si toute la chaîne est bien planifiée : l’application Entra, les URI de redirection, le portail VPN, Sophos Connect, les méthodes d’authentification, les groupes, l’accès aux appareils et les profils clients doivent être compatibles. Cet article décrit le processus pratique pour le portail VPN, SSL VPN et l’accès à distance IPsec avec Sophos Connect.

Pour la configuration générale de Sophos Connect, commencez par Configurer Sophos Connect sur Sophos Firewall. Cet article complète les étapes spécifiques à l’identité et au SSO.

Choix de la version : Les chemins de navigation, noms de champs et fichiers journaux propres aux services présentés jusqu’ici dans cet article se rapportent à SFOS 22. Pour SFOS 23.0, utilisez la procédure OpenID Connect décrite ci-dessous et les journaux qui y sont indiqués. Les autorisations de l’application, les politiques VPN, le provisionnement, le MFA, les tests pilotes et les tests de retour arrière restent des étapes du même processus ; le seul changement de formulaire de configuration du serveur ne donne pas accès au VPN. La disponibilité de l’aide SFOS 23 ne permet pas de déduire une date de disponibilité générale (GA).

Ce que fait Entra ID SSO sur le pare-feu

Sophos Firewall intègre Microsoft Entra ID SSO via OAuth 2.0 et OpenID Connect. Le pare-feu utilise Entra ID comme serveur d’authentification et peut connecter des utilisateurs à plusieurs services.

Pour l’accès à distance, ces services sont particulièrement pertinents :

• Portail VPN
• SSL VPN via Sophos Connect
• Accès à distance IPsec via Sophos Connect

Pour le portail captif, la procédure est différente : l’utilisateur se trouve déjà sur le réseau local et s’authentifie dans le navigateur afin que les règles basées sur l’utilisateur s’appliquent. Ce cas est décrit séparément dans Configurer Microsoft Entra ID SSO pour le portail captif de Sophos Firewall.

Le SSO direct de Microsoft Entra ID ne couvre pas toutes les connexions classiques au pare-feu. Pour User Portal et Client Authentication Agent, Sophos renvoie vers Microsoft Entra ID Domain Services. Il s’agit d’une architecture d’annuaire distincte compatible avec AD ou LDAP, et non d’une option supplémentaire de l’objet serveur OAuth/OIDC. Si User Portal ou CAA sont nécessaires, il ne faut donc pas supposer que l’application SSO configurée ici authentifie automatiquement ces services.

Il est important de faire la distinction : le pare-feu continue de gérer le VPN, les politiques, la correspondance des groupes d’utilisateurs et l’accès via les règles du pare-feu. Entra ID gère la vérification d’identité, le SSO et le MFA basé sur Entra.

Un serveur Entra ID, plusieurs services

Le serveur Microsoft Entra ID est créé une seule fois sur Sophos Firewall sous Authentication > Servers. Le même objet serveur peut ensuite être sélectionné sous Authentication > Services pour différents services, par exemple le portail VPN, SSL VPN, l’accès à distance IPsec, Captive Portal ou la connexion des administrateurs.

Cela ne signifie pas que tous les services fonctionnent automatiquement de la même manière. Chaque service a besoin de l’URI de redirection adaptée, de la bonne méthode d’authentification et de son propre test. Pour le portail VPN, SSL VPN et l’accès à distance IPsec, l’URL pertinente est VPN portal and remote access URL. Si Captive Portal ou WebAdmin utilisent également Entra ID SSO, leurs URLs de service doivent aussi être ajoutées dans l’application Entra et testées séparément.

Le service d’administration nécessite en plus des rôles ou groupes Entra, des profils de droits locaux et un accès de secours testé. La procédure dédiée est décrite dans Configurer Microsoft Entra ID SSO pour WebAdmin de Sophos Firewall.

Une seule instance Microsoft Entra ID peut être utilisée par méthode d’authentification. Avec Sophos Connect Provisioning, le portail VPN, SSL VPN et IPsec doivent donc utiliser volontairement le même serveur Entra ID afin que la valeur gateway, l’URI de redirection et le profil client correspondent.

Quand Entra ID SSO est pertinent

Entra ID SSO est pertinent lorsque les utilisateurs travaillent déjà avec Microsoft 365 et que l’organisation utilise l’accès conditionnel ou Entra-MFA comme contrôle de sécurité central.

Raisons typiques :

• Les utilisateurs ne doivent pas gérer de mots de passe de pare-feu séparés.
• Le MFA doit être géré via Entra ID plutôt que via Sophos OTP.
• L’accès à distance doit être plus étroitement lié au statut de l’utilisateur, aux groupes et à l’accès conditionnel.
• Le helpdesk et l’équipe de sécurité doivent gérer les processus d’identité de manière centralisée dans Entra ID.
• Les utilisateurs locaux du pare-feu doivent être réduits.

Tous les environnements ne doivent pas être immédiatement convertis. Dans les petites installations sans modèle de groupe Entra propre, le MFA propre à Sophos peut être plus simple. Pour la variante OTP classique, consultez Activer le MFA pour Sophos Firewall WebAdmin, le portail VPN et l’accès à distance.

Prérequis et limites

Avant la configuration, ces points doivent être remplis :

• Sophos Firewall avec une version SFOS prise en charge.
• Tenant Microsoft Entra avec l’autorisation de créer un enregistrement d’application.
• FQDN public pour le portail VPN ou l’accès à distance.
• Certificat valide pour le nom public.
• Le portail VPN est accessible via la zone requise.
• Sophos Connect 2.4 ou plus récent sur Windows, si le SSO doit être utilisé dans le client.
• Les utilisateurs ou groupes sont correctement présents dans Entra ID.
• Le pare-feu et Entra ID ont l’heure correcte.
• Les URL de connexion Microsoft sont accessibles depuis les clients et, selon le chemin du trafic, depuis le pare-feu.

Limitations importantes :

• Pour Sophos Connect SSO, Sophos mentionne les points de terminaison Windows avec Sophos Connect 2.4 ou plus récent.
• Lorsqu’on utilise Microsoft Entra ID SSO, on utilise le MFA dans le fournisseur d’identité. Le MFA propre au pare-feu Sophos ne peut pas être utilisé en plus pour cette méthode d’authentification.
• Sous SFOS 22, un seul serveur Microsoft Entra ID peut être sélectionné par méthode d’authentification. Sous SFOS 23, cette limite concerne un seul serveur IdP OpenID Connect, et non un serveur Entra en plus d’un autre fournisseur OIDC.
• Les utilisateurs du même domaine ne doivent pas être synchronisés simultanément via AD et Microsoft Entra ID.
• Dans les clusters HA, on ne doit pas supposer actuellement que Microsoft Entra ID SSO fonctionne pour le WebAdmin du pare-feu auxiliaire.

⚠️ Conditional Access nécessite une version de firmware corrigée : Sous SFOS 21.5 GA Build 171, Sophos Connect pouvait réutiliser une session SSO existante sans réévaluer le MFA ni les autres conditions de Conditional Access. La déconnexion puis la reconnexion du tunnel VPN ne suffisait pas nécessairement. Sophos répertorie ce problème sous NC-167126 et ne fournit aucun contournement officiel. Il est corrigé à partir de SFOS 21.5 MR2 Build 323 et de SFOS 22.0 MR1 Build 490, selon la branche de version. Lorsqu’un environnement utilise Conditional Access comme frontière de sécurité, le pare-feu doit d’abord être mis à niveau vers au moins l’une de ces versions. Force SSO re-login réduit le risque sur les anciens systèmes, mais ne remplace pas le correctif.

⚠️ Une mise à niveau vers SFOS 22 peut activer automatiquement le SSO : Si VPN Portal, Remote Access IPsec ou SSL VPN utilisaient Same as firewall sous Authentication > Services avant la mise à niveau, SFOS 22.0 ou version ultérieure active automatiquement Microsoft Entra ID SSO pour ces services. Les méthodes effectives sont consignées avant la mise à niveau. Si Entra SSO est prévu, inscrire ensuite dans l’application Entra la VPN portal and remote access URL exacte de l’objet serveur Entra et la vérifier avec une connexion réelle. Ne pas utiliser l’URL reverse SSO de Sophos Fusion (anciennement Sophos Central). Si le SSO n’est pas prévu, définir explicitement la méthode voulue au lieu d’accepter l’état hérité sans contrôle.

Planifier l’architecture

Avant la configuration technique, il faut déterminer quels services utiliseront le SSO.

• Portail VPN: L’authentification au portail doit-elle se faire via Entra ID ?
• SSL VPN: Le SSL VPN doit-il être utilisé via Sophos Connect avec Entra SSO ?
• Accès à distance IPsec: L’accès à distance IPsec doit-il être utilisé via Sophos Connect avec Entra SSO ?
• Fichier de provisionnement: Un fichier de provisionnement automatique sera-t-il utilisé ?
• Groupes: Quels groupes Entra peuvent utiliser le VPN ?
• MFA: Quelles règles d’accès conditionnel et de MFA s’appliquent à l’accès à distance ?
• Fallback: Que se passe-t-il si Entra ID ou l’accès Internet à Microsoft n’est pas disponible ?

Si un fichier de provisionnement est utilisé, la valeur gateway définie doit correspondre au FQDN ou à l’IP utilisé dans la configuration Microsoft Entra ID du pare-feu comme URI de redirection. Après des modifications à Entra ID ou à la configuration du pare-feu, les utilisateurs doivent réimporter la configuration mise à jour.

Avant toute modification, consignez Authentication > Services, l’ordre des serveurs, les groupes et stratégies VPN, Device Access et les profils distribués. Prévoyez un administrateur local dont la connexion ne dépend pas d’Entra ID : ce chemin break-glass doit être protégé, surveillé et testé séparément. Les licences Entra requises par les stratégies Conditional Access doivent être disponibles. SFOS 22 : Microsoft 365 Government Community Cloud High (GCC High) n’est pas pris en charge pour cette intégration SSO. L’aide SFOS 23 ne mentionne plus cette limitation ; cela ne permet toutefois pas de conclure ici à une prise en charge confirmée de GCC High. Pour un tel tenant, la prise en charge doit être vérifiée séparément avant le déploiement.

Préparer l’application Entra pour le pare-feu

Sophos recommande une application dédiée. Dans App registrations > New registration, créez une application Accounts in this organizational directory only avec plateforme Web, puis copiez Application (client) ID et Directory (tenant) ID. Sous API permissions > Microsoft Graph, accordez avec Admin Consent les autorisations déléguées User.Read.All et Group.Read.All ; ajoutez Group.Read.All comme Application permission uniquement pour l’import SFOS. Créez ensuite un Client secret, copiez immédiatement sa Value dans un stockage sûr et planifiez sa rotation.

Sous Enterprise application > Properties, définissez Assignment required? sur Yes et n’affectez que le groupe pilote/VPN et les administrateurs nécessaires. Cette affectation est la première barrière ; la stratégie SSL/IPsec reste la seconde. Microsoft détaille l’affectation des utilisateurs et groupes et les URI de redirection. SFOS lit automatiquement les attributs du jeton ; choisissez un Fallback user group sans droits VPN étendus afin qu’un groupe importé manquant n’accorde pas trop d’accès.

L’affectation d’une application par groupe nécessite Microsoft Entra ID P1 ou P2 et ne s’étend pas aux membres d’un groupe imbriqué. Sans cette licence ou avec des groupes imbriqués, affectez directement les utilisateurs pilotes ; sinon Entra refuse la connexion alors que l’appartenance au groupe VPN peut sembler correcte.

Créer un serveur Microsoft Entra ID sur le pare-feu

SFOS 23.0 : OpenID Connect avec Microsoft Entra ID

Sous SFOS 23, Entra ID est configuré comme fournisseur dans l’objet serveur OpenID Connect commun. L’application Entra existante reste nécessaire ; il ne faut pas créer une seconde application simplement parce que le formulaire a été renommé. Avant toute modification, documentez l’objet serveur existant, ses affectations aux services et les URI de redirection. Une mise à niveau n’est validée qu’après un nouveau test du portail et du tunnel.

1. Ouvrir Authentication > Servers > Add et sélectionner OpenID Connect sous Server type.
2. Définir Server name et sélectionner IdP vendor: Microsoft Entra ID.
3. Sous Client ID, saisir l’Application (client) ID de l’application Entra et, sous Client secret, la valeur de son secret.
4. Sous OpenID Connect URLs > Issuer URL, saisir le Directory (tenant) ID. Pour ce fournisseur, le champ SFOS documenté attend l’ID du tenant ; il ne faut pas le remplacer par une URL d’émetteur construite manuellement. Les autres paramètres d’URL ne s’appliquent pas à Microsoft Entra ID.
5. Sous Redirect URIs, sélectionner Use firewall URL ou saisir le FQDN ou l’adresse IP prévus pour le pare-feu avec Enter manually. Si un pare-feu individuel est géré via Sophos Fusion, définir manuellement le nom d’hôte ; l’URL reverse SSO n’est pas une URL de rappel de l’appliance.
6. Ouvrir Show URLs et enregistrer la VPN portal and remote access URL exacte comme URI de redirection Web dans l’application Entra. Avec le provisionnement, la valeur gateway doit correspondre au FQDN ou à l’adresse IP du pare-feu utilisés ici. Toute modification nécessite de réimporter la configuration du client.
7. Sous User attributes, conserver les valeurs par défaut Display name: name, Username: upn et Email address: email. Seul un jeton effectivement structuré différemment et pris en charge justifie d’autres attributs.
8. Laisser IdP authentication for firewall administrators désactivé pour les services réservés aux utilisateurs VPN et choisir un Fallback group aux droits restreints. Le mappage des administrateurs constitue une étape distincte dans l’article WebAdmin.
9. Exécuter Test connection, enregistrer uniquement si le test réussit, puis affecter le serveur au portail VPN, à SSL VPN et, si nécessaire, à IPsec sous Authentication > Services. Exécuter Apply pour chaque service. SSL VPN et le portail VPN utilisent toujours le même serveur ; avec le provisionnement, cette exigence s’applique aussi à IPsec.

Après une mise à niveau, vérifier également l’avertissement existant concernant Same as firewall : l’activation automatique pour les méthodes VPN héritées s’applique à SFOS 22.0 et versions ultérieures, donc également lors du passage correspondant à SFOS 23. Une migration de serveur documentée ne remplace ni la vérification des méthodes effectives ni une connexion réelle avec contrôle de la redirection, des groupes, du MFA et du tunnel.

SFOS 22 : Microsoft Entra ID SSO

Le formulaire serveur ci-dessous, avec Directory (tenant) ID, User attribute mapping et Fallback user group, concerne SFOS 22. Pour SFOS 23, utilisez les champs de la procédure précédente.

Le chemin de menu est :

Authentication > Servers

Procédure sur le pare-feu :

1. Ouvrir Add.
2. Sélectionner l’option Microsoft Entra ID SSO comme Server type.
3. Attribuer un nom de serveur explicite.
4. Entrer l’Application (client) ID de l’application Entra.
5. Entrer le Directory (tenant) ID.
6. Entrer le Client secret.
7. Vérifier ou définir manuellement le FQDN de l’URI de redirection.
8. Définir le groupe de secours.
9. Si le SSO WebAdmin est nécessaire, planifier le mappage des rôles ou des groupes sur les profils administrateurs.
10. Exécuter Test connection.
11. Enregistrer.

Pour les scénarios de SSO VPN purs, il n’est pas nécessaire de mapper les rôles administrateurs. Le serveur doit alors être planifié comme service utilisateur, et non comme accès administrateur général.

⚠️ Les secrets clients sont des informations d’identification productives. La date d’expiration, la rotation, la responsabilité et la documentation doivent être clarifiées avant le déploiement.

Définir les méthodes d’authentification

Après avoir créé le serveur Microsoft Entra ID, il doit être associé aux services appropriés sous Authentication > Services.

Pour l’accès à distance, ces domaines sont pertinents :

• VPN portal authentication methods
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods
• SSL VPN authentication methods

Si un fichier de provisionnement est utilisé, le même serveur Microsoft Entra ID doit être utilisé pour le portail VPN, IPsec et SSL VPN. Pour les fichiers de provisionnement, le même choix de serveur pour les méthodes d’authentification est important pour que le profil client, le portail et la méthode d’accès à distance soient compatibles.

Sans fichier de provisionnement, SSL VPN et VPN Portal doivent toujours utiliser le même serveur Microsoft Entra ID ; Remote Access IPsec peut alors utiliser un autre objet serveur Entra. Avec un fichier de provisionnement, VPN Portal, SSL VPN et IPsec doivent en revanche pointer vers le même objet. Cette distinction doit être documentée explicitement et non déduite ultérieurement d’une erreur de tenant dans la boîte de dialogue SSO.

Après chaque modification :

1. Sélectionner le serveur dans la méthode respective.
2. Déplacer le serveur à la bonne position s’il y a plusieurs serveurs.
3. Exécuter Apply pour chaque service modifié.
4. Utiliser un utilisateur de test avant de déployer largement la modification.

Enregistrer les URI de redirection dans Microsoft Entra ID

Pour que le SSO fonctionne, les URL du pare-feu doivent être enregistrées dans l’application Entra comme URI de redirection.

Procédure :

1. Ouvrir Authentication > Servers sur le pare-feu.
2. Ouvrir le serveur Microsoft Entra ID.
3. Copier les URL nécessaires :
   • URL de la console d’administration Web, si le SSO WebAdmin est utilisé
   • URL du portail captif, si le portail captif est utilisé
   • URL du portail VPN et de l’accès à distance pour le portail VPN, l’accès à distance IPsec et SSL VPN
4. Dans le portail Azure, aller à Microsoft Entra ID > App registrations.
5. Ouvrir l’application pour le Sophos Firewall.
6. Sous Manage > Authentication, ajouter une plateforme Web ou modifier la plateforme Web existante.
7. Coller les URI de redirection copiées.
8. Enregistrer.

Une erreur fréquente est un autre nom d’hôte dans le profil client, l’URI de redirection, le certificat et le DNS public. Ces valeurs doivent être consciemment alignées avant le déploiement.

Si ce n’est pas l’accès à distance mais le portail captif qui est protégé, le processus spécifique au portail captif doit également être vérifié : accès aux appareils pour la zone client, méthode d’authentification du portail captif, groupe d’utilisateurs et correspondance ultérieure des règles du pare-feu.

Autoriser le portail VPN via Device Access

Microsoft Entra ID SSO pour l’accès à distance utilise le port du portail VPN pour communiquer avec le pare-feu. Pour un accès depuis Internet, autorisez donc VPN Portal sur la ligne WAN sous Administration > Device access. N’activez d’autres zones que si les clients doivent réellement atteindre le portail depuis celles-ci.

Cela ne signifie pas qu’il faut ouvrir le portail VPN mondialement sans réfléchir. L’accès à distance est une surface d’attaque accessible au public. Pour les environnements de production, il convient également de vérifier :

• certificat public valide
• MFA et accès conditionnel dans Entra ID
• limitation géographique ou de source aussi étroite que possible, si réaliste
• journalisation et révision des tentatives de connexion
• désactivation claire des utilisateurs non nécessaires

Le renforcement des services locaux du pare-feu est décrit dans Device Access et Local Service ACL sur Sophos Firewall.

Si de nombreux échecs de connexion, des sources distribuées ou des verrouillages de compte Entra se produisent déjà, Détecter et contenir les attaques par force brute contre le VPN Portal associe les logs du firewall au contrôle Entra, à une restriction ACL sûre et au contrôle final.

Autoriser les URL de connexion Microsoft

Les clients et les chemins de pare-feu concernés doivent pouvoir atteindre les points de terminaison Microsoft Entra ID. Cela inclut plusieurs URL de connexion et CDN Microsoft, par exemple login.microsoftonline.com, login.microsoft.com, *.login.live.com, *.msauth.net et d’autres domaines Azure/Microsoft Online.

Dans les environnements restrictifs, il ne faut pas découvrir lors du déploiement que les pages de connexion, les JavaScript ou les points de terminaison de jetons sont bloqués. Il est judicieux de :

• utiliser la liste d’autorisation des connexions Microsoft Entra complète pour les hôtes FQDN et les exceptions de proxy.
• nommer correctement les hôtes FQDN ou les groupes d’hôtes FQDN.
• définir consciemment la règle de pare-feu pour DNS et HTTPS.
• en cas de proxy Web direct, vérifier également les exceptions Web.
• activer la journalisation jusqu’à ce que la connexion SSO soit stable.

Avec un Direct Web Proxy, la règle Allow vers le FQDN Host Group ne suffit pas à elle seule. L’article lié sur la liste d’autorisation indique les motifs d’URL exacts et la procédure à suivre dans Web > Exceptions. Limitez l’exception aux motifs de connexion et de CDN requis.

Vérifier les groupes et les autorisations VPN

Le SSO seul ne donne pas accès au VPN. L’utilisateur doit également être autorisé dans la configuration d’accès à distance appropriée.

Importer les groupes Entra de manière ciblée

Pour importer des groupes, l’application du pare-feu doit disposer de l’autorisation Microsoft Graph Group.Read.All comme Application permission, avec Admin Consent accordé. Ouvrir ensuite Assistant for importing groups pour le serveur Entra sous Authentication > Servers. Au lieu d’importer tous les groupes sans contrôle, l’assistant peut filtrer, par exemple, sur Display name ou Description.

Lors de l’importation, Surfing quota, Access time, Network traffic et Traffic shaping peuvent être attribués à tous les groupes ou à certains groupes. N’attribuer ces politiques que si le groupe en a réellement besoin. L’heure du pare-feu et celle de Microsoft Entra ID doivent être synchronisées, sinon l’importation elle-même peut échouer.

Si le groupe Entra existe sur le pare-feu, SFOS y affecte l’utilisateur. Dans le cas contraire, le Fallback user group configuré sur le serveur Entra s’applique. Cela reste vrai lorsque le serveur Entra est utilisé sous Firewall authentication methods ; le Default group de cette section ne remplace pas le groupe de repli. Après l’importation, le nouveau groupe doit également être autorisé dans la politique IPsec ou SSL VPN concernée.

À vérifier :

• Le groupe Entra a été importé dans le pare-feu ou est correctement mappé.
• Le groupe est sélectionné sous Allowed users and groups pour l’accès à distance IPsec.
• Le groupe est sélectionné sous Policy members pour SSL VPN.
• Les règles du pare-feu autorisent le trafic de la zone VPN uniquement vers les destinations nécessaires.
• L’utilisateur est non seulement authentifié, mais reçoit également la politique attendue.

Si le tunnel est connecté mais qu’aucun trafic ne circule, la cause n’est souvent pas le SSO, mais les règles, le routage, le DNS ou le NAT. Pour l’analyse, consultez Tester les règles du pare-feu avec Log Viewer, Policy Test et Packet Capture.

Vérifier UPN, e-mail et correspondance des groupes

Avec Microsoft Entra ID SSO, il est important de vérifier soigneusement l’identité de l’utilisateur et la correspondance des groupes. Une connexion peut réussir au fournisseur d’identité et être mal attribuée sur le pare-feu si l’UPN, l’adresse e-mail, le groupe importé ou l’identifiant utilisateur local ne correspondent pas.

Cela est particulièrement pertinent dans les environnements où les utilisateurs ont historiquement des valeurs différentes :

• Nom principal de l’utilisateur : max.muster@example.com est souvent utilisé comme nom de connexion.
• Adresse e-mail : m.muster@example.com peut être différente et prêter à confusion lors de l’attribution ou de la connexion au portail.
• Nom d’affichage : Max Muster est lisible par les utilisateurs, mais ne convient pas comme identifiant technique.
• Groupe : VPN-Users doit être importé sur le pare-feu et utilisé dans la bonne configuration d’accès à distance.

Le format de connexion compte également lors d’une migration d’Active Directory local vers Entra ID. AD utilise souvent sAMAccountName@domain, tandis qu’Entra ID utilise UserPrincipalName@domain. SFOS traite des chaînes différentes comme des objets utilisateur distincts, même lorsqu’elles appartiennent à la même personne. Aligner le format avant la migration lorsque cela est possible. Si des noms différents sont utilisés volontairement, des doublons sont créés ; supprimer les anciens utilisateurs AD uniquement après avoir vérifié les règles, les groupes, les rapports et la nouvelle connexion Entra.

L’ancien problème connu NC-157635 entraînait l’échec des connexions au portail SSL VPN ou IPsec lorsque l’adresse e-mail et l’UPN étaient différents. Sophos l’a corrigé dans SFOS 21.0 MR2 Build 349, 21.5 MR1 Build 261 et 22.0 EAP0 Build 274. La vérification des attributs utilisateur reste utile lorsque seuls certains comptes rencontrent des problèmes, car elle permet de détecter des objets utilisateur locaux ou des autorisations de groupe qui ne correspondent pas.

Procédure de vérification pratique :

1. Ouvrir l’utilisateur de test dans Microsoft Entra ID.
2. Comparer l’UPN et l’adresse e-mail.
3. Vérifier si l’utilisateur est membre du groupe VPN prévu.
4. Sur le pare-feu, ouvrir le groupe importé et vérifier si l’utilisateur y apparaît comme prévu.
5. Sous Authentication > Services, vérifier si le bon serveur Microsoft Entra ID est sélectionné pour le portail VPN, SSL VPN et IPsec.
6. Effectuer un test de connexion et vérifier Log Viewer ainsi que oauth_sso_vpn.log.

Si seuls certains utilisateurs sont concernés, un problème d’attribut ou de groupe est plus probable qu’une erreur générale du serveur Entra ID. Si tous les utilisateurs sont concernés, vérifier d’abord l’ID du tenant, l’ID du client, le secret client, les URI de redirection, l’heure et les points de terminaison Microsoft.

Pour les règles utilisateur après une connexion VPN réussie, il est également important que la règle du pare-feu voie l’utilisateur ou le groupe dans le trafic réel. Si le tunnel est établi mais que la règle utilisateur prévue ne correspond pas, l’analyse de La règle Sophos Firewall ne s’applique pas : vérifier les causes est appropriée.

Introduire MFA et Conditional Access de manière contrôlée

Ciblez l’Enterprise Application du pare-feu et commencez avec des pilotes ou le mode Report-only. Testez chaque condition et MFA avec un cas autorisé et un cas refusé dans les journaux Entra. Microsoft recommande de planifier et évaluer les stratégies avant de les appliquer.

Conservez au moins deux comptes d’urgence Entra cloud-only, séparés, surveillés et exclus de Conditional Access. Ils ne remplacent pas l’administrateur local, indépendant d’Internet, d’Entra et de l’application, et ne doivent pas être affectés au VPN simplement pour tester un contournement. Voir Manage emergency access accounts.

Tester Sophos Connect et le provisionnement

Pour Sophos Connect : après la configuration Entra ID ou après des modifications de la configuration SSO, la configuration du client doit être réimportée.

Tester macOS séparément : Pour Microsoft Entra ID SSO avec Sophos Connect 2.1 ou ultérieur sur macOS (pas 2.0), suivez le parcours de connexion dans le navigateur sur macOS. auto commence dans le navigateur intégré et passe au navigateur système lorsque les exigences pertinentes de Conditional Access l’imposent ; embedded ne prévoit aucun basculement automatique. Le choix de system via un fichier .pro approuvé relève du schéma de provisionnement, et non de modifications manuelles de .ovpn ou .scx. Terminez la connexion, MFA compris, dans le navigateur ouvert par le client, revenez au client et vérifiez le tunnel, DNS et l’accès. Changer de navigateur ne contourne pas la conformité de l’appareil : respectez les exigences ou contactez le service informatique, sans affaiblir Conditional Access. Le test Windows ci-dessous reste applicable à Sophos Connect 2.4 ou ultérieur.

Procédure de test :

1. Installer le client Sophos Connect actuel sur Windows.
2. Importer la configuration de provisionnement ou VPN appropriée.
3. Vérifier si l’option SSO est visible et cliquable dans le client.
4. Se connecter avec Entra ID.
5. Déclencher le MFA ou l’accès conditionnel comme prévu et vérifier le résultat dans les journaux de connexion Entra.
6. Vérifier l’état du tunnel.
7. Vérifier l’IP VPN, le DNS, les cibles internes et la correspondance des règles du pare-feu.
8. Sur un appareil partagé, tester une reconnexion SSO forcée.

Pour le dernier test, ouvrir le menu en haut à droite du client Sophos Connect, sélectionner Force SSO re-login et confirmer avec OK. Ce n’est qu’ensuite que l’utilisateur suivant doit se connecter avec ses propres identifiants Entra. Une simple déconnexion du tunnel n’est pas équivalente. Sur les appareils Windows partagés, cette étape fait partie d’un changement d’utilisateur correctement effectué, même avec un firmware à jour.

Pour chaque test, consignez heure, utilisateur, type de VPN et résultat attendu. Les journaux Entra (application, utilisateur, MFA/Conditional Access, code d’erreur) doivent correspondre à oauth_sso_vpn.log ou au module Authentication du Log Viewer. Avant le déploiement, vérifiez : pilote affecté et utilisateur non affecté au portail ; chaque profil SSL/IPsec utilisé avec adresse VPN, DNS et destinations autorisées ; utilisateur sans groupe VPN ; Force SSO re-login sur un poste partagé ; et connexion de l’administrateur break-glass par son chemin restreint. Il s’agit de tests à exécuter dans votre environnement, pas de résultats déjà constatés.

Pour l’installation du client sur Windows, consultez Installer le client Sophos Connect sur Windows. Pour SSL VPN avec Sophos Connect, consultez également Configurer Sophos SSL VPN avec Sophos Connect sur Windows.

Retour arrière avec conservation de l’état

Ne retirez pas l’ancienne authentification avant la validation du pilote et du retour arrière. Conservez les anciens profils sous contrôle. En cas de problème, connectez-vous avec l’administrateur local et restaurez sous Authentication > Services les serveurs et leur ordre consignés pour VPN Portal, SSL VPN et IPsec ; cliquez sur Apply pour chaque service. Réimportez l’ancien profil sur un poste pilote et vérifiez portail, tunnel, DNS et une destination autorisée.

Ne supprimez l’application Entra, le nouvel objet serveur, les groupes importés et le secret qu’après confirmation du rétablissement dans les journaux. Si Device Access n’avait été élargi que pour SSO, restaurez-le ensuite seulement afin de ne pas bloquer le chemin VPN rétabli.

Exploitation et sécurité

Entra ID SSO déplace davantage la sécurité de connexion vers le fournisseur d’identité. C’est bien si Entra ID est correctement géré. C’est problématique si les groupes, l’accès conditionnel ou les secrets d’application sont gérés de manière négligente.

En exploitation, ces points doivent être vérifiés régulièrement :

• Le secret de l’application n’expire pas de manière inattendue.
• Les groupes Entra ne contiennent que des utilisateurs autorisés.
• L’accès conditionnel s’applique à l’accès à distance.
• Les accès de secours et de repli sont documentés.
• Le portail VPN est accessible uniquement dans la mesure nécessaire.
• Les versions de Sophos Connect sont à jour.
• Les anciens profils clients sont retirés après des modifications.
• Les journaux sont vérifiés rapidement en cas de problèmes de connexion.

Pour le côté client, un processus de mise à jour distinct doit également exister. L’article Vérifier et mettre à jour en toute sécurité la version du client Sophos Connect résume les sujets Windows, macOS, SSO, OTP et de provisionnement à vérifier avant un déploiement.

Dépannage

SFOS 23.0 : Pour le flux de connexion OIDC, utilisez /log/oauth_sso_svc.log ; les erreurs de Test connection avec x509: certificate signed by unknown authority sont à vérifier dans /log/sfos-macro-cfg.log. Dans Log Viewer, le module Authentication reste pertinent pour le portail VPN, IPsec et SSL VPN. Les références ci-dessous à oauth_sso_vpn.log et le redémarrage du service spécifique concernent SFOS 22.

Après correction d’une chaîne d’autorités de certification dont l’incomplétude a été démontrée, exécutez d’abord de nouveau Test connection. Uniquement si un redémarrage reste nécessaire et qu’une interruption des services de connexion OIDC utilisés est acceptable pendant la fenêtre de maintenance, la commande Advanced Shell documentée par Sophos pour SFOS 23 est la suivante :

service oauth_sso_svc:restart -ds nosync

Vérifiez ensuite de nouveau Test connection, une nouvelle connexion au portail VPN et le tunnel effectivement utilisé. Le redémarrage de ce service commun ne concerne pas uniquement le VPN ; les autres services utilisant cet objet OIDC doivent également être retestés séparément. Aucun redémarrage ne remplace la vérification du DNS, de l’heure, des autorisations ou des autorités de certification.

Le bouton SSO n’est pas utilisable dans le client Sophos Connect

Si le client indique que le SSO n’est pas configuré, tester d’abord la connexion au serveur Microsoft Entra ID sur le pare-feu. Ensuite, sous Authentication > Services, vérifier si le serveur Entra ID est correctement défini pour SSL VPN ou IPsec et le portail VPN.

L’utilisateur ne peut pas se connecter au portail VPN

Le SSO peut fonctionner fondamentalement, mais l’autorisation VPN peut manquer. Vérifier si le groupe Entra est inclus dans la configuration d’accès à distance IPsec sous Allowed users and groups ou dans SSL VPN sous Policy members.

Seuls certains utilisateurs ne peuvent pas se connecter

Vérifier d’abord l’UPN, l’adresse e-mail, l’appartenance au groupe et le groupe de pare-feu importé. Surtout pour les utilisateurs avec une adresse e-mail différente, des noms modifiés ou des comptes migrés, l’identifiant technique peut être différent de ce qui est attendu.

Microsoft signale un tenant ou une application non valide

Souvent, les méthodes d’authentification, l’application Entra, l’ID du tenant ou le choix du serveur sur le pare-feu ne correspondent pas. Surtout avec plusieurs serveurs Entra ID, il faut vérifier si le portail VPN, SSL VPN et IPsec utilisent le même serveur attendu.

La redirection ou la connexion se termine sur une page d’erreur

Comparer le FQDN, le certificat, le DNS public, l’URI de redirection et la valeur de passerelle du fichier de provisionnement. Même de petites différences dans le nom d’hôte, le port ou le chemin peuvent perturber le flux OAuth/OIDC.

Test connection échoue avec une erreur x509

Si oauth_sso_vpn.log affiche l’erreur x509: certificate signed by unknown authority, une autorité de certification racine ou intermédiaire peut manquer dans la chaîne de certificats vers Microsoft Entra ID. Le problème connu NC-176806 a été corrigé dans SFOS 22.0 MR2 Build 546 ; d’autres chaînes de certificats incomplètes ou erreurs TLS restent possibles.

Dans l’Advanced Shell, vérifier la chaîne fournie par Microsoft :

openssl s_client -connect login.microsoftonline.com:443 -showcerts

1. Vérifier la chaîne de certificats et l’émetteur dans la sortie.
2. Obtenir uniquement l’autorité de certification racine ou intermédiaire manquante auprès d’une source fiable. Ne pas importer un certificat de serveur en tant qu’autorité de certification.
3. Ajouter et appliquer l’autorité de certification sous Certificates > Certificate Authority.
4. Ouvrir le serveur Entra ID sous Authentication > Servers, puis exécuter de nouveau Test connection.
5. Seulement si le test échoue encore et qu’une brève interruption des connexions SSO VPN en cours est acceptable, redémarrez le service VPN SSO dans l’Advanced Shell :

service oauth_sso_vpn:restart -ds nosync

Exécuter ensuite de nouveau Test connection. Le redémarrage du service est une dernière étape facultative, et non la première mesure à prendre en cas d’erreur x509.

L’importation de groupes ne fonctionne pas

Vérifier l’heure du pare-feu, les données du tenant, les autorisations de l’application, le secret client et l’accessibilité des points de terminaison Microsoft. Si les groupes locaux existants ne correspondent pas aux groupes Entra, il faut décider s’ils doivent être nettoyés, mappés ou gérés manuellement.

La connexion est établie, mais les systèmes internes ne sont pas accessibles

L’authentification n’est probablement plus la principale erreur. Vérifier l’IP VPN, le DNS, les règles du pare-feu, le NAT, le routage et le système cible. Dans le Log Viewer, il devrait être visible quelle règle touche le trafic de la zone VPN.

Liste de contrôle

• L’application Entra avec l’ID client, l’ID du tenant et le secret client est documentée.
• Les URI de redirection pour le portail VPN et l’accès à distance sont enregistrées dans Entra ID.
• Le FQDN public, le certificat et la passerelle de provisionnement correspondent.
• Le portail VPN est consciemment autorisé sous Device Access.
• Les URL de connexion Microsoft sont accessibles.
• Les services d’authentification utilisent le bon serveur Entra ID.
• Les groupes VPN sont importés et autorisés dans les politiques SSL/IPsec.
• L’UPN, l’adresse e-mail et l’appartenance au groupe ont été vérifiés avec un utilisateur de test.
• Sophos Connect 2.4 ou plus récent est utilisé sur Windows.
• Les profils clients ont été réimportés après des modifications.
• Entra-MFA et l’accès conditionnel ont été vérifiés avec un utilisateur de test.
• oauth_sso_vpn.log, Log Viewer et les journaux du serveur d’accès sont connus pour le dépannage.

Questions fréquentes