Sophos AP6 : connexion Wi-Fi avec Microsoft Entra ID

De nombreuses entreprises gèrent déjà leurs utilisateurs dans Microsoft Entra ID. Pourtant, leur réseau Wi-Fi professionnel dépend encore d’un serveur d’authentification dédié, parfois accompagné d’un Active Directory local qui n’est presque plus utilisé pour le reste. C’est précisément ce que vise la nouvelle connexion Wi-Fi avec Microsoft Entra ID pour Sophos AP6 : les identités cloud existantes peuvent aussi servir à accéder au réseau sans fil.

Sophos a introduit cette fonction avec AP6 MR10, version 1.10.3192. Elle se configure dans Sophos Fusion Wireless, la plateforme d’administration auparavant appelée Sophos Central. Notre présentation de Sophos Fusion explique ce changement de nom et son rapport avec les produits existants.

Cette nouveauté peut réduire l’infrastructure locale. Sa capacité à remplacer une authentification Wi-Fi existante dépend toutefois des appareils utilisés, des politiques d’identité et des fonctions réseau nécessaires. Une vérification attentive s’impose avant la migration, notamment en présence d’une authentification des appareils par certificat ou de VLAN dynamiques.

Ce qui change pour l’accès Wi-Fi

Un mot de passe Wi-Fi partagé se distribue rapidement, mais reste difficile à gérer au quotidien. Lorsqu’une personne quitte l’entreprise, ses appareils conservent ce mot de passe. Le modifier affecte en revanche tous les autres appareils. Un réseau Wi-Fi Enterprise permet d’accorder un accès fondé sur des identités individuelles.

Dans la nouvelle intégration AP6, Microsoft Entra ID devient le fournisseur d’identité, ou IdP. Ce fonctionnement ne nécessite pas de serveur RADIUS ou NPS local dédié. RADIUS est le service que les réseaux Wi-Fi Enterprise classiques utilisent souvent pour vérifier les identifiants et attribuer les règles d’accès.

L’annonce MR10 de Sophos présente explicitement cette intégration comme un moyen d’éviter une infrastructure d’authentification locale. Elle peut intéresser une entreprise qui dispose d’identités cloud et d’exigences Wi-Fi limitées. Un compte Entra ne garantit cependant pas, à lui seul, une connexion réussie sur tous les appareils.

Prérequis pour Sophos AP6 et Microsoft Entra ID

Administration, firmware et licence

Il faut des points d’accès AP6 administrés dans Sophos Fusion et un firmware prenant en charge l’intégration Entra. MR10 est la version avec laquelle Sophos a introduit cette fonction. Pour une nouvelle installation, il convient de vérifier la version actuellement approuvée du firmware plutôt que de choisir une ancienne version uniquement pour cette fonction. Le guide des mises à jour du firmware AP6 décrit la préparation et la vérification d’un déploiement progressif.

Chaque AP6 administré de manière centralisée nécessite un abonnement AP6 Support and Services Subscription valide. Celui-ci comprend notamment l’administration via Sophos Fusion et les mises à jour du firmware. L’interface web locale d’un AP6 ne remplace pas cette intégration cloud. La présentation de l’administration et des licences AP6 explique les différences.

Les fournisseurs d’identité créés de manière centralisée pour ce fonctionnement sont destinés aux SSID AP6. Cette prise en charge des AP6 ne constitue pas une garantie équivalente pour les APX ou pour un réseau Wi-Fi administré par Sophos Firewall. Sophos documente ce périmètre sur la page RADIUS.

Tenant Entra et inscription d’application

Les utilisateurs concernés doivent exister dans Entra ID. Il faut également une inscription d’application pour le tenant de l’entreprise, un domaine personnalisé vérifié et les droits nécessaires pour accorder le consentement administrateur requis.

La connexion nécessite les valeurs Client ID, Tenant ID, nom de domaine et Client Secret. Sophos indique les autorisations Microsoft Graph Domain.Read.All de type Application et User.Read de type Delegated. Le guide de configuration consulté ne mentionne aucune obligation supplémentaire de disposer d’Entra ID P1 ou P2 ; les exigences de licence propres aux politiques d’identité de l’entreprise doivent être vérifiées séparément.

Le Client Secret doit avoir un responsable et une date de renouvellement planifiée. Une configuration fonctionnelle le premier jour ne suffit pas si personne ne surveille ensuite sa date d’expiration. La configuration complète est décrite dans le guide de la base de connaissances sur l’authentification AP6 avec Entra ID.

Des profils Wi-Fi adaptés sur les terminaux

Pour cette intégration, Sophos prend en charge uniquement EAP-TTLS avec PAP comme authentification interne. Pour Windows et Android, le fabricant exige le mode SSID WPA2/WPA3 Enterprise, car la combinaison TTLS/PAP documentée n’y est pas prise en charge avec le seul WPA3 Enterprise. Les appareils Apple nécessitent un profil Wi-Fi installé utilisant TTLS et PAP ; Sophos renvoie à Apple Configurator pour sa création.

Ces exigences proviennent du guide de configuration Sophos pour Entra ID. Dans un parc hétérogène, il convient donc de préparer une petite matrice de compatibilité : appareil, version du système d’exploitation, profil Wi-Fi et résultat du test de connexion. Un test réussi sous Windows ne préjuge pas du résultat sur un téléphone Android ou un Mac.

EAP-TTLS/PAP : pourquoi la confiance dans le certificat est essentielle

EAP-TTLS établit un tunnel TLS. La vérification du mot de passe avec PAP s’effectue à l’intérieur de ce tunnel protégé. La sécurité dépend donc largement de la capacité du client à vérifier de manière fiable l’identité du serveur d’authentification.

Si la vérification du certificat est désactivée ou si un certificat inconnu est accepté sans contrôle, l’appareil pourrait transmettre les identifiants à un faux serveur. Microsoft explique ce risque dans sa documentation sur EAP et la validation des certificats serveur.

Pour une exploitation administrée, les profils Wi-Fi doivent définir la chaîne de confiance approuvée et l’identité attendue du serveur. Ces valeurs doivent correspondre à l’environnement réel et être clarifiées avant le déploiement. Des demandes répétées de validation de certificat ne signalent pas une configuration terminée normalement, mais justifient une vérification du profil.

Il ne faut pas non plus supposer que les identifiants de connexion Windows seront repris automatiquement. Microsoft documente l’option EAP-TTLS correspondante pour MS-CHAP v2, mais pas pour PAP. Cette intégration ne garantit donc pas automatiquement un accès Wi-Fi en SSO pour un appareil Windows joint à Entra.

Les limites à prendre en compte avant une migration

Un mot de passe utilisateur plutôt qu’une authentification des appareils par certificat

Le fonctionnement TTLS/PAP documenté utilise un mot de passe. Il ne remplace pas une authentification EAP-TLS existante avec des certificats d’appareil. Une entreprise qui authentifie aujourd’hui ses appareils indépendamment de la connexion d’un utilisateur doit traiter cette différence comme une décision d’architecture.

Un ordinateur portable administré peut, par exemple, avoir besoin d’un accès réseau avant la connexion de l’utilisateur. Les imprimantes et autres appareils sans identité utilisateur adaptée ne s’intègrent pas non plus automatiquement à ce même fonctionnement. Pour ces besoins, une solution RADIUS ou NAC appropriée reste une alternative possible. Le guide AP6 pour un serveur RADIUS externe et un réseau Wi-Fi Enterprise décrit cette configuration distincte.

La MFA et Conditional Access ne deviennent pas automatiquement des fonctions Wi-Fi

Le fait qu’un compte Entra déclenche une demande de MFA dans Microsoft 365 ne prouve pas que TTLS/PAP la prend en charge. La connexion Wi-Fi ne propose pas de dialogue Microsoft interactif dans un navigateur. Une vérification réussie du mot de passe n’équivaut donc pas à une authentification MFA confirmée.

Pour la MFA, Conditional Access, les comptes sans mot de passe, les comptes invités et les identités fédérées, le guide Sophos consulté ne fournit pas de garantie complète de compatibilité. Les cas prévus doivent être testés avec les politiques réellement appliquées au tenant. Si une exigence de sécurité empêche la connexion, il convient d’abord de clarifier le fonctionnement pris en charge avec Sophos plutôt que d’assouplir globalement la politique de protection.

Ni VLAN dynamiques, ni accounting, ni backend de portail captif

Sophos exclut trois fonctions de ce fonctionnement Fusion RADIUS/Entra :

• RADIUS-assigned VLAN : aucune attribution dynamique de VLAN via ce service.
• RADIUS Accounting : aucune fonction d’accounting via ce service.
• Captive Portal backend authentication : aucune utilisation comme backend d’authentification d’un portail captif.

Une entreprise qui affecte, par exemple, ses employés à différents VLAN selon une politique RADIUS ne peut pas simplement remplacer le service existant par l’IdP Entra. Cette limite concerne l’attribution dynamique, et non l’utilisation, en général, d’un VLAN statique prévu pour un SSID. Une conception distincte des SSID et des VLAN reste nécessaire pour que le client connecté n’accède qu’aux réseaux prévus.

Plusieurs SSID Enterprise nécessitent une vérification des bandes de fréquences

L’interface permet de gérer les choix RADIUS par SSID. Sophos documente toutefois une seule configuration de serveur RADIUS par bande de fréquences sur les AP6. Un SSID Enterprise supplémentaire utilisant un autre serveur peut remplacer le choix existant sur une bande commune.

Un SSID de test ajouté à un AP en production n’est donc pas automatiquement isolé de la configuration existante. Avant son affectation, il faut vérifier tous les SSID Enterprise, les bandes de fréquences et les sources d’authentification. Pour le premier essai, un AP pilote distinct constitue un choix plus simple à maîtriser. Sophos décrit ce comportement et l’interruption lors de l’enregistrement dans les paramètres des SSID.

Configuration et validation en pratique

La configuration relie trois éléments : l’application dans Entra ID, l’objet IdP dans Sophos Fusion et le profil Wi-Fi sur le client. Dans Fusion, le point d’entrée est My Products > Wireless > SSIDs > RADIUS > Add > Add external identity provider. Les valeurs Entra préparées y sont saisies, vérifiées avec Test connection, puis enregistrées. L’IdP est ensuite affecté à un SSID Enterprise AP6.

Test connection est une vérification préliminaire, pas une validation complète du Wi-Fi. Seule une véritable connexion client vérifie le fonctionnement conjoint du profil EAP et de l’identité utilisateur. L’adressage IP, DHCP, DNS et les accès réseau autorisés doivent ensuite fonctionner eux aussi.

Les vérifications suivantes sont recommandées pour un pilote :

1. Choisir un AP et un SSID dont la modification n’affecte aucune authentification existante.
2. Se connecter avec un compte de test ordinaire et les profils clients prévus. La validation de l’identité du serveur doit fonctionner sans acceptation d’un certificat non vérifié.
3. Tester tous les types d’appareils et toutes les politiques d’identité prévus, y compris un test négatif contrôlé avec un compte de test désactivé. Le blocage d’un compte ne met pas nécessairement fin immédiatement à une session Wi-Fi déjà établie ; évaluer séparément une nouvelle connexion et une session en cours.
4. Vérifier l’adressage, DNS, les destinations autorisées et la segmentation réseau prévue. Tester à nouveau les SSID existants après les modifications.
5. Ajouter d’autres AP uniquement après avoir documenté le succès des tests. Intégrer le renouvellement du secret, les changements de politiques Entra et le comportement en cas d’indisponibilité de la connexion au cloud dans le plan d’exploitation.

Pour les entreprises qui gèrent déjà leurs utilisateurs dans Entra ID et n’ont pas besoin de fonctions RADIUS avancées, l’intégration AP6 peut simplifier l’infrastructure Wi-Fi. La comparaison décisive porte toutefois sur le concept d’accès existant : quelles identités sont vérifiées, quels appareils doivent fonctionner et quelles règles doivent être conservées lors de la migration ? Ces questions doivent trouver une réponse avant l’arrêt d’un service d’authentification local.

Questions fréquentes