Authentifier les utilisateurs AP6 avec Microsoft Entra ID

Sophos Fusion Wireless peut utiliser Microsoft Entra ID comme fournisseur d’identité pour les SSID AP6 avec chiffrement Enterprise. La procédure comprend trois éléments distincts : une application mono-locataire dans Entra ID, un objet IdP externe dans Sophos Fusion (anciennement Sophos Central) et un profil EAP adapté sur les terminaux.

Procédure rapide : inscrire dans Entra ID une application sans Redirect URI, relever les ID client et locataire, créer un secret client, puis définir exactement Domain.Read.All comme autorisation Application et User.Read comme autorisation Delegated. Dans Sophos Fusion, ouvrir ensuite My Products > Wireless > SSIDs > RADIUS > Add > Add external identity provider, saisir les quatre valeurs, lancer Test connection et affecter l’IdP à un SSID Enterprise AP6.

⚠️ Limite importante : cet IdP ne prend ici en charge que EAP-TTLS avec PAP comme authentification interne. Les VLAN attribués par RADIUS, RADIUS Accounting et l’authentification backend d’un Captive Portal ne sont pas pris en charge. Si l’une de ces fonctions est nécessaire, cette procédure Entra ne convient pas.

Prérequis et choix pour les clients

Les comptes utilisateurs prévus doivent exister et être utilisables dans Entra ID avant l’inscription de l’application. Microsoft documente la création, l’invitation et la suppression des comptes dans le guide lié. Pour le pilote, utiliser un compte de test autorisé, et non une identité d’administrateur privilégiée.

L’existence d’un compte ne prouve pas sa compatibilité. Avant le déploiement, établissez une matrice pilote propre au tenant pour les stratégies et types d’identité réellement concernés : MFA et Conditional Access, comptes sans mot de passe, invités et identités fédérées. TTLS/PAP ne peut pas afficher de demande interactive dans un navigateur. Ne déduisez pas la prise en charge des autorisations Graph. Si un cas ne réussit pas une connexion pilote réelle ou si Sophos n’en a pas confirmé le flux d’authentification, arrêtez ce cas et transmettez-le au support Sophos et au responsable des identités.

Le parc client détermine le mode de chiffrement :

Windows et Android : selon Sophos, ces appareils ne prennent pas en charge TTLS/PAP avec WPA3 Enterprise. Le SSID doit donc utiliser WPA2/WPA3 Enterprise.
Appareils Apple : ils nécessitent un profil de configuration Wi-Fi installé avec EAP method: TTLS et Inner authentication: PAP. Sophos renvoie à Apple Configurator pour sa création et son installation.
Autres clients : la page Sophos ne donne aucune garantie de compatibilité. Tester EAP-TTLS/PAP et le mode Enterprise choisi sur les modèles et versions de système réellement utilisés avant le déploiement.

⚠️ Condition d’arrêt pour protéger les identifiants : PAP transmet un mot de passe réutilisable dans le tunnel TTLS. Chaque client doit donc valider la chaîne de certificats serveur attendue et l’identité du serveur au moyen de paramètres MDM ou client approuvés. Ne désactivez jamais la validation et n’acceptez jamais un certificat inconnu. Sophos ne publie ni l’identité serveur, ni la chaîne de confiance propres à l’environnement, ni toutes les valeurs du profil. Sans valeurs approuvées fournies par le responsable des identités, le déploiement est bloqué ; ne les devinez pas.

Inscrire l’application Entra et protéger ses valeurs

Se connecter au Microsoft Entra admin center.
Ouvrir Entra ID > App registrations, puis New registration.
Saisir un nom unique, par exemple Sophos-Central-AP6-Auth.
Dans Supported account types, sélectionner Single tenant only.
Laisser Redirect URI vide sauf exigence propre à l’environnement, puis sélectionner Register.
Dans Overview, relever les valeurs Application (client) ID et Directory (tenant) ID.
Ouvrir Certificates & secrets > Client secrets > New client secret, saisir une description, choisir une durée compatible avec la rotation interne, puis sélectionner Add.
Utiliser immédiatement Copy to clipboard pour déposer la valeur du secret dans le coffre approuvé. Elle ne sera plus affichée ; en cas de perte, il faut en créer une nouvelle.
Ouvrir Entra ID > Domain names > Custom domain names, relever le Name du domaine prévu et vérifier que son Status est Verified.

Sophos Fusion nécessite maintenant quatre valeurs propres à l’environnement : Client ID, Client secret, Domain name vérifié et Tenant ID. Les ID sont saisis dans la configuration prévue, mais le secret ne doit apparaître ni dans un ticket, ni dans une capture d’écran, ni dans une conversation, ni dans le contrôle de version.

Définir uniquement les autorisations Graph documentées

Dans l’application enregistrée, ouvrez API permissions > Add a permission > Microsoft Graph. Ajoutez les autorisations séparément afin de choisir explicitement leur type :

Sélectionnez Application permissions, recherchez Domain.Read.All, cochez-la, puis sélectionnez Add permissions.
Ouvrez de nouveau Add a permission > Microsoft Graph, sélectionnez Delegated permissions, recherchez User.Read, cochez-la, puis sélectionnez Add permissions.

Permission	Type	Admin consent required
`Domain.Read.All`	`Application`	Yes
`User.Read`	`Delegated`	Yes

Sélectionnez Grant admin consent for , puis Yes. Dans la liste finale, vérifiez que Domain.Read.All affiche Application, User.Read affiche Delegated et que les deux affichent Granted. Sophos impose cette combinaison exacte ; n’ajoutez aucune autorisation Graph par précaution. Les droits de configuration et de consentement dépendent de votre administration Entra ; ce guide n’invente aucun rôle d’annuaire.

Ajouter Entra ID comme IdP dans Sophos Fusion

Se connecter à Sophos Fusion sur https://fusion.sophos.com, puis ouvrir My Products > Wireless > SSIDs > RADIUS.
Sélectionner Add > Add external identity provider.
Sous Name, saisir un nom unique, par exemple HQ-Entra-ID. Il apparaît sur la page RADIUS et dans la liste des serveurs d’un SSID AP6.
Saisir Application (client) ID dans Client ID.
Saisir la valeur sécurisée dans Client secret.
Saisir le domaine personnalisé vérifié dans Domain name.
Saisir Directory (tenant) ID dans Tenant ID.
Sélectionner Test connection. N’utiliser Save qu’après le message de réussite.

Traitez la recette comme trois contrôles distincts. Test connection vérifie uniquement la configuration de Fusion vers l’IdP. Une connexion réelle d’un client vérifie l’échange d’authentification TTLS/PAP et la stratégie du tenant pour l’identité pilote. Seul le trafic utilisateur après authentification vérifie l’adressage, DHCP, DNS, les VLAN, la passerelle et les règles de pare-feu. La réussite d’un niveau ne prouve pas les suivants ; ce guide n’affirme rien de non documenté sur le trajet cloud des identifiants.

Affecter l’IdP à un SSID pilote AP6

Inventoriez d’abord chaque SSID Enterprise déjà affecté à l’AP pilote envisagé, avec ses bandes de fréquences et son serveur RADIUS ou IdP sélectionné. AP6 ne prend en charge qu’une configuration RADIUS par bande. Si un autre SSID Enterprise utilise un serveur ou IdP différent sur une bande commune, l’enregistrement de la nouvelle affectation peut écraser la configuration existante de cette bande ; la nouvelle sélection principale peut alors affecter les deux SSID. Préférez un AP sans SSID Enterprise conflictuel.

Créez ou modifiez le SSID Enterprise avec la procédure AP6 RADIUS et WPA3 Enterprise, sélectionnez HQ-Entra-ID et affectez-le d’abord à un seul AP pilote sans conflit. Pour Windows ou Android, choisissez WPA2/WPA3 Enterprise. Laissez désactivés RADIUS VLAN assignment, l’accounting RADIUS et le backend de portail captif. Avant Save, consignez pour chaque SSID concerné l’ancien IdP/RADIUS, les bandes et les AP affectés. Arrêtez-vous avant Save si une bande recouvre une sélection différente ou si l’état initial est ambigu ; choisissez un autre AP ou contactez le support Sophos.

Valider avant le déploiement

Fusion vers l’IdP : Test connection doit réussir.
Authentification client réelle : connectez une identité pilote Entra approuvée avec le profil TTLS/PAP approuvé ; la chaîne de certificats et l’identité du serveur doivent être validées sans accepter d’invite ni de certificat inconnu.
Matrice des stratégies du tenant : effectuez une connexion réelle pour chaque combinaison prévue de MFA/Conditional Access, sans mot de passe, invité et fédéré. Consignez les cas acceptés et refusés. Arrêtez et transmettez tout cas ambigu ou non pris en charge ; un compte standard ne prouve aucune compatibilité Entra générale.
Test négatif : vérifiez qu’un compte de test dédié, désactivé ou inutilisable, n’obtient aucun accès Wi-Fi. Ne bloquez pas de compte de production par des échecs répétés.
Trafic utilisateur : vérifiez la configuration IP, DNS, le trajet VLAN, la passerelle et uniquement les destinations autorisées. L’association ou l’authentification seule ne suffit pas.
Matrice client et régression : testez séparément chaque OS, type d’appareil et cas de stratégie, puis retestez chaque SSID Enterprise existant sur l’AP pilote. N’ajoutez des AP que par petits lots après avoir consigné la réussite.

Diagnostiquer par symptôme

Test connection échoue : comparer Client ID et Tenant ID avec Overview, le domaine avec son état Verified et le secret avec la valeur copiée lors de sa création. Vérifier ensuite le type des deux autorisations Graph et l’état Granted. Remplacer un secret expiré ou perdu, puis mettre également à jour l’IdP Fusion.

Test connection réussit, mais la connexion Wi-Fi échoue : cela réduit la probabilité d’un défaut de l’intégration Fusion sans prouver le fonctionnement du client. Vérifier TTLS/PAP, l’état utilisateur et le chiffrement du SSID. Windows et Android exigent WPA2/WPA3 Enterprise.

Un appareil Apple demande des paramètres ou d’approuver un certificat : vérifier que le bon profil Wi-Fi est installé et cible le bon SSID. Ne pas contourner le problème en acceptant sans contrôle un certificat inconnu ; faire clarifier les valeurs manquantes par le processus Apple ou MDM responsable.

L’authentification réussit, mais DHCP, DNS ou les destinations échouent : le défaut se situe après l’authentification, dans le chemin de données. Contrôler adresse client, chemin VLAN/switch, DHCP, passerelle, DNS et règles firewall. Ne pas ajouter d’autorisations Graph pour corriger un problème réseau.

Revenir en arrière et revoir les autorisations

Si le pilote échoue, n’affectez aucun AP supplémentaire. Retirez la nouvelle affectation, puis comparez chaque SSID Enterprise concerné à l’état initial consigné. Le retrait seul peut ne pas restaurer automatiquement la configuration par bande. Restaurez explicitement l’ancien IdP/RADIUS, les bandes d’origine et les affectations d’AP, enregistrez, puis retestez l’authentification connue et le trafic utilisateur. Si l’état antérieur ou la procédure de restauration est ambigu, arrêtez-vous et contactez le support Sophos plutôt que de modifier davantage la production.

Ne supprimer l’objet IdP de la page RADIUS de Fusion que lorsque son SSID count ou ses affectations indiquent qu’aucun SSID ne l’utilise. Ne révoquer ou supprimer le secret client ou l’application Entra qu’ensuite, en coordination avec son responsable ; sinon des affectations restantes perdraient leur authentification. Vérifier après le retrait que l’objet n’est plus sélectionnable et que l’accès existant fonctionne toujours.

En exploitation, revoir périodiquement l’expiration du secret, le responsable de l’application, les deux autorisations Graph et les SSID affectés. Supprimer toute autorisation supplémentaire devenue inutile ; cette intégration ne doit conserver que la combinaison documentée par Sophos.