Vous avez hérité d'un parc informatique au Royaume-Uni où le mot de passe du réseau WiFi de l'entreprise est imprimé dans un classeur d'arrière-boutique, partagé par la réception, le personnel d'entretien, les sous-traitants et les anciens employés. Le réseau invité est géré séparément, l'intégration des appareils dépend de processus manuels, et un auditeur souhaite savoir quelle personne physique a autorisé chaque connexion. Parallèlement, l'organisation a migré l'identité de ses applications vers Microsoft Entra ID et s'attend à ce que le réseau WiFi suive le même chemin.
Cette attente est compréhensible, mais l'architecture est souvent décrite de manière incorrecte. Microsoft Entra ID ne fournit pas de service RADIUS natif. La position documentée de Microsoft est que les appareils joints à Entra ne peuvent pas utiliser l'authentification RADIUS basée sur un objet ordinateur et un certificat locaux, de sorte que les conceptions modernes s'appuient plutôt sur EAP-TLS, des certificats émis par Intune et une couche RADIUS distincte (Directives Entra RADIUS de Microsoft). Une fois cette distinction claire, le déploiement devient beaucoup plus facile à concevoir, à tester et à prendre en charge.
Pourquoi l'authentification WiFi Microsoft Entra ID en vaut la peine
Une clé pré-partagée partagée peut fonctionner à l'ouverture, puis rester active après le départ d'un employé, lorsqu'un sous-traitant la copie sur un appareil personnel ou lorsqu'un invité accède à un réseau destiné au personnel. Modifier cette clé crée son propre problème opérationnel. Chaque ordinateur portable, combiné, caisse, tablette et autre appareil géré doit recevoir le nouveau secret, souvent dans différents hôtels, hôpitaux et points de vente.
L'authentification WiFi avec Microsoft Entra ID déplace l'unité de confiance du mot de passe vers l'identité et l'appareil. EAP-TLS utilise une connexion adossée à un certificat pour identifier un utilisateur ou un appareil autorisé. Intune contrôle quels terminaux gérés reçoivent ce certificat et le profil WiFi correspondant. Le point d'accès nécessite toujours RADIUS, Microsoft Entra ID est donc la source d'annuaire et de politique, et non le point d'authentification sans fil. Cette lacune d'architecture est le détail que de nombreux guides simplifiés omettent.
Règle pratique : Considérez le WiFi comme un service lié à l'identité : exigez un certificat et un périmètre Intune, jamais un copier-coller d'un identifiant et mot de passe Microsoft Entra ID.
L'intégration devient reproductible. Un profil Intune correctement ciblé peut configurer l'SSID, la chaîne de certificats approuvés et la sélection de certificats sans demander au personnel de saisir ou de partager une clé. L'exclusion bénéficie également d'un chemin de contrôle défini. Le retrait d'un appareil peut déclencher des actions sur le cycle de vie des certificats, plutôt que de laisser les administrateurs rechercher chaque emplacement où un mot de passe partagé était stocké.
La question de la conformité est tout aussi pratique. Les organisations au Royaume-Uni doivent séparer le personnel, les invités, les fournisseurs et les équipements non gérés au sein d'environnements réglementés et de locaux partagés. Un enterprise WiFi security guide dédié fournit des bases utiles, tandis que la conception de la production nécessite des décisions claires : séparer l'accès invité du protocole EAP-TLS du personnel, enregistrer l'identité présentée au serveur RADIUS et définir la méthode de révocation des accès.
Le centre d'administration Entra ne fournit pas de commutateur unique pour cette conception. La PKI, Intune, la politique RADIUS et les paramètres sans fil doivent fonctionner ensemble, et les anciens appareils Apple, Windows, Android et partagés peuvent exposer différents comportements de certificat ou de profil. Ce travail d'intégration est réel, mais il remplace un secret partagé fragile par un contrôle reproductible qui peut s'appliquer à l'ensemble d'un parc mixte au Royaume-Uni.
Les éléments fondamentaux dont vous avez besoin
Un réseau invité d'hôtel, une salle d'hôpital ou une succursale de vente au détail peuvent échouer dès la première vérification de certificat alors que le point d'accès indique toujours un SSID sain. Évitez cette confusion en définissant l'architecture avant d'ouvrir l'assistant Intune. Quatre composants doivent s'accorder sur une chaîne d'identité unique :
- Une autorité de certification. Commencez par une PKI Microsoft, AD CS, ou un fournisseur de certificats gérés. L'AC doit émettre des certificats avec l'EKU Client Authentication avant que la politique RADIUS ne soit ajustée, et le service RADIUS doit faire confiance à la chaîne d'émission.
- Une couche RADIUS. NPS, Aruba ClearPass, Cisco ISE ou une plateforme RADIUS-as-a-Service met fin à l'échange 802.1X depuis les points d'accès. Entra ID n'a pas de fonctionnalité RADIUS native. L'extension NPS adapte les requêtes RADIUS aux vérifications basées sur Entra, plutôt que de transformer Entra en serveur RADIUS, comme expliqué dans la Q&R Microsoft sur la limitation RADIUS.
- Intune. Intune fournit la racine de confiance, le profil de certificat SCEP ou PKCS et la configuration WiFi. Ses affectations contrôlent également la portée des appareils, afin qu'un profil incomplet ne touche pas l'ensemble du parc.
- Politique réseau. RADIUS doit définir ce qu'un certificat réussi autorise. Il peut s'agir d'un VLAN personnel, d'un segment clinique, d'un réseau de vente au détail restreint ou d'une ACL spécifique à l'appareil.
Construire selon l'ordre des dépendances
Publiez et validez le modèle d'autorité de certification avant d'ajuster le RADIUS. Vérifiez l'émetteur, le sujet ou le SAN, la chaîne de certificats et l'EKU d'authentification du client. Sinon, des échecs de négociation peuvent ressembler à un défaut RF ou SSID alors que l'appareil ne dispose d'aucun certificat utilisable.
La confiance doit fonctionner dans les deux sens. Les appareils gérés font confiance à l'autorité de certification (CA) qui a signé le certificat du serveur RADIUS, tandis que le serveur RADIUS fait confiance à l'autorité de certification qui a émis le certificat client. Les points d'accès ont besoin de l'adresse du serveur RADIUS et du secret partagé. Ils ne s'authentifient pas directement auprès d'Entra.
Décider de l'emplacement des politiques
NPS, ClearPass et ISE peuvent appliquer des politiques sans fil, mais leurs modèles de règles et leur gestion des attributs diffèrent. Sélectionnez une seule source de vérité pour le mappage de SSID-à-VLAN, documentez-la, et évitez que les tableaux de bord des points d'accès et les règles RADIUS ne produisent des résultats conflictuels.
Une fiche du secteur public britannique décrit le support de Entra ID pour l'authentification par clé publique, y compris les certificats clients TLS, ainsi que la fédération et l'authentification à double facteur (fiche Entra ID du secteur public britannique). Le modèle de certificat dépend toujours des composants PKI et RADIUS distincts.
Émettre des certificats et déployer des profils WiFi via Intune
Pour les appareils gérés, la réussite ou l'échec de EAP-TLS repose sur la sélection du certificat. Intune peut distribuer le profil sans interaction de l'utilisateur, mais il ne peut pas compenser un modèle de certificat auquel il manque l'usage, l'émetteur ou le mappage de sujet correct.
Établir le chemin du certificat
Déployez d'abord le profil de l'autorité de certification racine de confiance. Avec SCEP, créez un profil de certificat qui pointe vers le service NDES et utilise le connecteur de certificat Intune. Le profil doit faire référence au point de terminaison SCEP publié, au modèle de certificat correct et à un mécanisme de challenge qui empêche les requêtes non autorisées.
Le certificat lui-même nécessite l'authentification client (Client Authentication) dans l'utilisation étendue de sa clé. Décidez si le sujet et le SAN identifient l'appareil, l'utilisateur ou les deux. Cette décision affecte le mappage RADIUS, le comportement des appareils partagés et la façon dont vous analyserez un événement d'authentification ultérieurement.
Un profil PFX peut fonctionner lorsque les certificats sont générés et packagés via un flux de travail approuvé, mais SCEP est généralement plus simple à exploiter sur un parc géré hétérogène car l'appareil peut demander et renouveler son propre certificat. L'essentiel est la cohérence. Chaque plateforme doit recevoir une chaîne et un certificat que la politique RADIUS comprend.
Configurer la charge utile WiFi
Créez le profil WiFi avec l'exact SSID, le mode de sécurité et la méthode EAP. Sélectionnez EAP-TLS, associez le profil au certificat émis par la configuration SCEP, et activez la validation du certificat du serveur. Ajoutez les noms de serveurs RADIUS exacts afin qu'un appareil n'accepte pas un service similaire lors de la décision de confiance. Les directives de déploiement britanniques alignées sur Microsoft recommandent une racine de confiance, un profil de certificat client SCEP et des noms RADIUS précis dans le profil WiFi (Directives de configuration WiFi Entra ID au Royaume-Uni).
Le champ qui provoque des échecs répétés est la correspondance des certificats. Sur Windows, macOS, iOS et Android, le profil WiFi doit sélectionner le certificat émis par l'autorité de certification attendue et contenant l'EKU prévu. Si le profil est déployé mais que le système d'exploitation ne peut pas sélectionner ce certificat, l'appareil peut se rabattre sur une méthode inadaptée ou rejeter la connexion.
Attribuez les profils SCEP et WiFi au même groupe d'appareils pilotes. Vérifiez les journaux des appareils pour l'installation du certificat, confirmez que la racine est fiable, puis inspectez le certificat client sélectionné avant de modifier la politique RADIUS. Un outil de vérification de l'état des certificats, tel que ce vérificateur de certificat SSL, peut aider à valider la partie publique du certificat, mais le dépannage interne de EAP-TLS dépend toujours des journaux des appareils et de RADIUS.
Raccorder le tout à votre réseau et à la couche RADIUS
Le point d'accès détecte un suppliant 802.1X. Il ne détecte pas Microsoft Entra ID. L'appareil présente son certificat client, le point d'accès transfère l'échange EAP au RADIUS, et le service RADIUS valide la chaîne de certificats puis applique la politique réseau.
Le flux habituel est le suivant :
- L'appareil s'associe à l'SSID d'entreprise.
- L'AP transfère le trafic EAP-TLS vers NPS, ClearPass, ISE ou un service RADIUS hébergé.
- Le RADIUS valide le certificat client par rapport à l'AC émettrice de confiance.
- Le moteur de politique associe l'identité du certificat à un compte, un appareil ou un groupe.
- La réponse RADIUS attribue le VLAN ou la politique d'accès autorisé.
Différences de configuration selon les constructeurs
Les tableaux de bord Meraki nécessitent généralement les détails du serveur RADIUS, le secret partagé et les paramètres de validation de certificat, avec un contournement AAA utilisé lorsque la réponse RADIUS contrôle la segmentation. Les déploiements Aruba dépendent souvent d'un groupe de serveurs RADIUS et de règles de dérivation de serveur. Ruckus SmartZone nécessite une configuration AAA avec EAP-TLS sélectionné, tandis que les modèles WLAN de Juniper Mist pointent vers le cluster RADIUS. UniFi Network utilise un profil RADIUS et peut nécessiter une gestion prudente lorsque l'ancien EAP-TTLS coexiste avec EAP-TLS.
Le RADIUS-as-a-Service de Purple est une option hébergée pour les parcs qui souhaitent une couche RADIUS distincte sans gérer l'infrastructure complète du serveur. NPS, ClearPass, ISE et d'autres services hébergés peuvent tous convenir, mais ils n'interpréteront pas chaque attribut de certificat ou condition de politique de manière identique.
| Fournisseur | Serveur d'authentification RADIUS | Type EAP | Attribut de certificat | Piège courant |
|---|---|---|---|---|
| Meraki | NPS, ISE, ClearPass ou RADIUS hébergé | EAP-TLS | Émetteur et SAN | La surcharge AAA peut placer un utilisateur valide dans le mauvais VLAN |
| Aruba | NPS, ClearPass, ISE ou RADIUS hébergé | EAP-TLS | SAN ou UPN | L'ordre des règles de dérivation du serveur peut envoyer le personnel vers la politique invité |
| Ruckus | RADIUS connecté à SmartZone | EAP-TLS | Sujet et émetteur | L'incohérence du type EAP est facile à manquer dans les paramètres AAA |
| Juniper Mist | Cluster RADIUS | EAP-TLS | SAN ou identité mappée | Le modèle WLAN peut faire référence à un groupe de serveurs incomplet |
| UniFi | Profil RADIUS de l'application réseau | EAP-TLS ou méthode héritée contrôlée | Identité du certificat | Des méthodes EAP mixtes peuvent masquer la défaillance réelle |
Sur NPS, inspectez les propriétés du certificat EAP-TLS et définissez si l'émetteur, le sujet ou le SAN fournit le mappage de compte. Une erreur fréquente consiste à supposer que le nom commun est le nom d'utilisateur alors que le service RADIUS analyse le SAN comme un UPN. Cela interrompt le mappage des utilisateurs et peut également perturber les flux d'appareils dédiés ou d'appareils partagés.
Utilisez un cluster RADIUS équilibré en charge lorsque le parc nécessite de la résilience, et configurez des temporisateurs de basculement par SSID cohérents. Ne supposez pas qu'un service RADIUS cloud applique la révocation en temps réel. Certains équipements hébergés manquent de validation CRL ou OCSP accessible, de sorte que le certificat peut rester accepté même après la modification d'un compte d'annuaire.
Révocation instantanée et accès conditionnel pour le WiFi du personnel
La question difficile n'est pas de savoir si un appareil peut s'enregistrer. C'est de savoir ce qui se passe après que les RH ont désactivé un compte.
L'Accès Conditionnel évalue les connexions prises en charge par Entra. Il n'intervient pas au sein d'une session 802.1X déjà établie pour y mettre fin sous le seul prétexte qu'un statut d'annuaire a changé. Un certificat déjà installé sur un ordinateur portable peut rester cryptographiquement valide jusqu'à son expiration ou jusqu'à ce que le service RADIUS le rejette via une vérification de révocation de certificat. C'est pourquoi la conception de la révocation s'avère plus importante que la simple démonstration de l'enrôlement.
Réduire la fenêtre de validité du certificat
La première mesure d'atténuation est de définir une courte durée de validité des certificats. Les profils SCEP d'Intune peuvent émettre des certificats renouvelés régulièrement, limitant ainsi la période durant laquelle un appareil retiré peut présenter des identifiants par ailleurs valides. La fenêtre appropriée dépend de votre modèle de menace, de la disponibilité des appareils et de votre tolérance opérationnelle. Une durée de vie plus courte augmente la dépendance envers un renouvellement fiable ; testez donc les appareils qui passent du temps hors ligne ou fonctionnent derrière des réseaux restreints.
La deuxième mesure d'atténuation est la vérification active de la révocation. Publiez une CRL accessible ou exploitez un OCSP, puis confirmez que les serveurs RADIUS la consultent. Les configurations NPS et ClearPass peuvent sembler saines tout en ignorant la révocation si la vérification est désactivée ou si le point de distribution est inaccessible depuis le réseau RADIUS.
La mesure opérationnelle essentielle est le délai entre la désactivation dans l'annuaire et le premier paquet sans fil rejeté.
Les flux de travail de retrait et d'effacement d'Intune sont toujours précieux, en particulier pour les appareils perdus ou partagés, mais ils n'effacent pas comme par magie un certificat d'un terminal hors tension. Le certificat devient inutilisable par expiration, révocation ou suppression lorsque l'appareil reçoit ses prochaines instructions de gestion. Les équipes doivent documenter ce délai et le tester lors des exercices de départ.
L'évaluation continue de l'accès de Microsoft Entra ID prend en charge des décisions de contrôle rapides pour certains scénarios d'applications cloud. Elle ne transforme pas actuellement EAP-TLS en une transaction d'accès conditionnel de type navigateur, le WiFi dépend donc toujours de la validité du certificat et du comportement de révocation RADIUS. Pour les lecteurs qui étudient le modèle d'authentification global, ce guide MFA pour les utilisateurs d'Edmonton fournit un contexte utile sur la différence entre une assurance de connexion renforcée et l'authentification réseau par certificat.
L'accès invité a besoin de son propre plan de contrôle. Les pratiques du secteur public au Royaume-Uni, y compris GovWifi, confirment que les visiteurs et l'accès partagé ne doivent pas être contraints de suivre le même flux de travail de certificat que le personnel (guide d'intégration Microsoft Entra ID WiFi au Royaume-Uni).
Tester et dépanner les modes de défaillance courants
Un test en laboratoire prouve qu'un appareil peut se connecter. Un déploiement en production prouve que le mauvais appareil ne peut pas se connecter, qu'un certificat révoqué est rejeté et qu'un invité ne peut pas hériter de la politique du personnel.
Commencer par le certificat
En cas d'échec EAP-TLS, inspectez le certificat client avant de modifier le point d'accès. Confirmez la chaîne, l'émetteur, le SAN, l'expiration et l'EKU d'authentification du client. Vérifiez ensuite si le profil WiFi sélectionne ce certificat et si l'appareil fait confiance au certificat du serveur RADIUS.
Les boucles SCEP indiquent généralement un décalage entre Intune, NDES et le modèle de certificat. Vérifiez l'URL de défi, confirmez que le compte du connecteur NDES dispose des autorisations de modèle requises, et comparez l'URI du profil SCEP avec l'URL NDES publiée, y compris son barre oblique de fin. Un certificat émis à partir du mauvais modèle peut s'apparenter à un enregistrement réussi tout en restant inutilisable pour le WiFi.
Tester la confiance et la segmentation
Une attaque de type "Evil Twin" peut diffuser le même SSID avant que la validation du certificat n'ait lieu. Configurez la validation du certificat du serveur, spécifiez les noms RADIUS attendus dans le profil WiFi d'Intune et utilisez des paramètres réseau gérés afin que le système d'exploitation ne se connecte pas automatiquement à un point d'accès imposteur. Activez les cadres de gestion protégés (PMF) là où le parc de clients et de points d'accès le permet, et utilisez un SSID propre à l'organisation plutôt qu'un nom générique.
Un certificat révoqué qui continue de s'authentifier provient généralement du serveur RADIUS, pas de Microsoft Entra ID. Vérifiez que la validation CRL est activée, puis confirmez que le sous-réseau RADIUS peut résoudre et atteindre le point de distribution. Si OCSP est utilisé, inspectez le délai d'expiration et l'accessibilité du répondeur plutôt que de supposer que le service effectue la vérification automatiquement.
Le chevauchement entre invités et personnel provient souvent de l'ordre des politiques. Placez les règles du personnel EAP-TLS avant les règles d'invités basées sur PSK ou MAC, puis vérifiez les attributs VLAN renvoyés dans le journal RADIUS. Une authentification valide avec le mauvais VLAN est un échec de politique, pas un échec d'enrôlement.
Utiliser un ordre de tri fixe
La lenteur des premières connexions peut résulter du moment de renouvellement du certificat, de points de terminaison de révocation inaccessibles ou de la sélection du mauvais SSID par le système d'exploitation. Ne commencez pas par reconstruire le profil.
- Inspecter le certificat de l'appareil : Vérifier la chaîne, l'EKU, l'émetteur, le SAN et la validité.
- Capturer l'échange sans fil : Confirmer que le point d'accès transmet le trafic EAP vers la cible RADIUS prévue.
- Lire le journal des événements RADIUS : Utiliser les journaux NPS, les enregistrements d'événements ISE ou le suivi des accès ClearPass pour identifier l'attribut rejeté.
- Vérifier l'état d'Intune : Confirmer que l'appareil est inscrit, reçoit les profils et reste dans le groupe d'attribution prévu.
- Vérifier la politique renvoyée : Confirmer que les sessions du personnel et des invités reçoivent le bon VLAN et la bonne ACL.
Cet ordre permet de mener une investigation basée sur des preuves. Modifier trois couches à la fois masque souvent la faille d'origine.
Une liste de contrôle de déploiement et les prochaines étapes
Gérez le déploiement comme un changement de service contrôlé, et non comme une simple expérience de certification. Commencez par un groupe restreint d'appareils représentatifs de votre parc : un ordinateur portable Windows récent, des terminaux Apple, du matériel Android, des appareils partagés et tout équipement opérationnel devant rester connecté. La réception d'un hôtel, un service hospitalier et un point de vente peuvent tous utiliser la même plateforme d'identité, mais présenter des exigences de reprise d'activité très différentes.
La séquence de déploiement
- Cadrage du pilote : Sélectionnez des utilisateurs, des sites et des types d'appareils représentatifs, y compris des sites ayant une connectivité faible ou des chemins d'accès de gestion restreints.
- Préparation de l'AC : Confirmez la chaîne d'émission, les autorisations de modèle, l'EKU et les points de terminaison de révocation avant de créer le profil WiFi.
- Création du profil Intune : Créez la racine de confiance, le profil de certificat SCEP ou PFX et le profil WiFi EAP-TLS sous forme de jeu assorti.
- Intégration RADIUS : Ajoutez les points d'accès, les secrets partagés, la confiance des certificats et les règles de mappage d'identité à la plateforme RADIUS sélectionnée.
- Ciblage des appareils : Attribuez les profils au groupe pilote et maintenez l'ancien SSID disponible comme solution de repli documentée.
- Déploiement de masse : Élargissez par site ou par groupe d'appareils uniquement après la réussite des tests d'émission de certificats, d'affectation de VLAN et de désinscription.
- Cadence d'audit : Examinez les authentifications échouées, l'expiration des certificats, l'accessibilité de la révocation et les résultats des politiques employés par rapport aux invités.
- Retrait du PSK : Supprimez les SSID à clé partagée uniquement après que les équipes d'assistance ont testé une procédure de secours d'urgence et que le parc d'appareils a migré.
Les vérifications spécifiques au Royaume-Uni sont faciles à omettre. Confirmez que les appareils BYOD d'Apple font confiance à la chaîne d'émission via le chemin de gestion prévu. Définissez comment les secrets partagés RADIUS font l'objet d'une rotation, notez où la télémétrie des certificats est stockée pour l'examen GDPR, et alignez les journaux d'authentification avec le PSN de l'organisation ou les exigences d'audit spécifiques au secteur. Les hôpitaux et les parcs immobiliers partagés du secteur public ont également besoin d'un processus documenté de panne de SSID ou d'accès alternatif qui ne devienne pas un réseau non géré permanent.
Les clés d'accès (passkeys) devraient devenir la méthode d'authentification par défaut pour la connexion Entra en 2026, selon la mise à jour de l'écosystème de Microsoft (Mise à jour Microsoft Entra passkeys). Cela ne rend pas pour autant le travail actuel sur EAP-TLS obsolète. Les passkeys gèrent la connexion d'identité interactive, tandis que le WiFi nécessite toujours un identifiant réseau vérifiable par la machine, une décision de politique et un échange RADIUS. L'autorité de certification (CA), la gestion des appareils et la discipline de politique établies pour les certificats restent des bases utiles pour le prochain modèle d'identité.
Si votre parc dépend encore d'une clé partagée ou suppose que Microsoft Entra ID peut répondre directement aux requêtes RADIUS, documentez d'abord les SSIDs actuels, l'autorité de certification, les groupes d'appareils et la politique RADIUS. Pilotez ensuite EAP-TLS avec Intune sur un échantillon d'appareils, testez la révocation avant de déployer à grande échelle, et séparez l'accès invité de l'identité du personnel.
Purple fournit une plateforme RADIUS cloud et de WiFi basé sur l'identité qui peut connecter l'accès du personnel basé sur Microsoft Entra ID aux politiques réseau sur des parcs multi-constructeurs. Visitez Purple pour découvrir comment ses fonctionnalités de WiFi pour le personnel de niveau certificat et d'accès invité s'intègrent dans votre déploiement au Royaume-Uni.
