Wi-Fi 802.1X EAP-TLS avec Intune : concevoir une configuration fiable

Position recommandée

Je déploie d’abord les autorités de confiance, puis le certificat client, et enfin le profil Wi-Fi. Cette séquence évite qu’un poste tente de rejoindre le réseau sans pouvoir valider le serveur ou présenter son identité.

Le choix utilisateur ou appareil doit être cohérent de bout en bout : affectation Intune, magasin de certificat, sujet/SAN, règle NPS, moment de connexion et besoin d’accès avant ouverture de session.

Je configure explicitement la validation du certificat serveur et les noms attendus. Désactiver cette validation expose l’utilisateur à un point d’accès ou un serveur RADIUS usurpé.

Je déploie d’abord les autorités de confiance, puis le certificat client, et enfin le profil Wi-Fi. Cette séquence évite qu’un poste tente de rejoindre le réseau sans pouvoir valider le serveur ou présenter son identité.

Besoin, cas d’usage et périmètre de la recommandation

Le profil Enterprise Wi-Fi décrit SSID, nom de connexion, connexion automatique, méthode EAP et paramètres de confiance. EAP-TLS réalise une authentification mutuelle : le poste valide le serveur et le serveur valide le certificat client.

Le profil Trusted certificate utilisé pour reconnaître l’autorité du certificat serveur RADIUS peut différer de la chaîne qui signe les certificats clients. Je déploie chaque chaîne nécessaire et j’évite de placer un intermédiaire dans le magasin Trusted Root.

Le besoin opérationnel doit être défini avant de choisir un profil ou un outil. Il faut distinguer le résultat attendu, l’expérience utilisateur, le propriétaire de la configuration et les contrôles qui confirmeront son application. La présence d’un paramètre dans une console ne justifie pas son activation.

L’intention configurée dans le cloud, son applicabilité, l’état reçu par Windows et le résultat observé correspondent à quatre informations différentes. Une affectation réussie, un état vert ou une requête HTTP acceptée ne prouve pas à lui seul que tout le parcours fonctionne.

Critères de décision et options possibles

La recommandation concernant « Wi-Fi 802.1X EAP-TLS avec Intune » dépend des licences, du niveau de risque, des dépendances réseau, des responsabilités de support, des populations visées et de la maturité opérationnelle. Une même valeur ne convient pas automatiquement à tous les environnements.

Lorsque plusieurs méthodes sont supportées, je compare leur simplicité, leur réversibilité, leur observabilité et le risque d’autorités concurrentes. La méthode retenue doit rendre explicites la propriété du paramètre, les exceptions acceptées et la façon de prouver le résultat.

Le déploiement avance par anneaux. Les critères GO et NO-GO, la durée d’observation, les seuils et le responsable de la décision sont définis avant le pilote. Le rollback doit être réellement testé.

La valeur recommandée et la politique qui la distribue sont deux décisions différentes. Settings Catalog, Endpoint Security, baseline, CSP, GPO ou outil tiers peuvent parfois porter la même intention. Le choix dépend du propriétaire attendu, du reporting disponible et du risque de conflit.

Une exception possède un motif, un responsable, une mesure compensatoire et une date de revue. Sans ces informations, une exclusion de dépannage risque de devenir une configuration permanente.

Architecture cible et répartition des responsabilités

Le profil Enterprise Wi-Fi décrit SSID, nom de connexion, connexion automatique, méthode EAP et paramètres de confiance. EAP-TLS réalise une authentification mutuelle : le poste valide le serveur et le serveur valide le certificat client.

Le profil Trusted certificate utilisé pour reconnaître l’autorité du certificat serveur RADIUS peut différer de la chaîne qui signe les certificats clients. Je déploie chaque chaîne nécessaire et j’évite de placer un intermédiaire dans le magasin Trusted Root.

Un profil SCEP ou PKCS fournit l’identité cliente. Le certificat doit contenir Client Authentication, le sujet ou SAN attendu par NPS, une chaîne valide, une clé privée et un magasin correspondant au contexte d’authentification.

Prérequis, gouvernance et préparation

Avant de créer la configuration, je définis le propriétaire fonctionnel, le propriétaire technique, la population pilote, les exclusions, la durée d’observation et la personne habilitée à déclencher le rollback.

Je capture aussi l’état initial : licences, versions, affectations, autorités, dépendances et métriques. Cette baseline rend la recommandation mesurable et évite de confondre amélioration réelle et variation naturelle du parc.

• SSID Enterprise et infrastructure 802.1X
• NPS/RADIUS avec certificat serveur valide
• PKI et révocation accessibles
• profil de confiance Intune
• profil SCEP ou PKCS testé
• mapping identité défini
• réseau de secours pour le pilote

Fonctionnement détaillé et responsabilités

Le profil Enterprise Wi-Fi décrit SSID, nom de connexion, connexion automatique, méthode EAP et paramètres de confiance. EAP-TLS réalise une authentification mutuelle : le poste valide le serveur et le serveur valide le certificat client.

Le profil Trusted certificate utilisé pour reconnaître l’autorité du certificat serveur RADIUS peut différer de la chaîne qui signe les certificats clients. Je déploie chaque chaîne nécessaire et j’évite de placer un intermédiaire dans le magasin Trusted Root.

Un profil SCEP ou PKCS fournit l’identité cliente. Le certificat doit contenir Client Authentication, le sujet ou SAN attendu par NPS, une chaîne valide, une clé privée et un magasin correspondant au contexte d’authentification.

• SSID Enterprise et infrastructure 802.1X
• NPS/RADIUS avec certificat serveur valide
• PKI et révocation accessibles
• profil de confiance Intune

Configuration, exploitation et cas limites

L’authentification appareil permet la connectivité avant ouverture de session pour joindre AD, traiter certaines stratégies ou démarrer un VPN. L’authentification utilisateur porte l’identité personnelle mais n’est disponible qu’après chargement du profil ; le choix dépend du besoin réel.

NPS ou le RADIUS tiers valide chaîne, date, révocation, EKU et mapping, puis applique sa Network Policy. Les journaux NPS disent pourquoi l’accès est refusé ; le profil Intune n’a pas cette visibilité.

Je limite les noms de serveurs RADIUS attendus et sélectionne l’autorité racine appropriée dans le profil. La validation doit échouer si le certificat serveur ne correspond pas, même si le SSID paraît légitime.

• Affecter le profil Wi-Fi
• Tester plusieurs sites et contextes
• Retirer l’ancien profil par anneaux

Lire les états et les résultats

Le déploiement utilise un groupe pilote disposant d’un chemin réseau de secours. Je vérifie les dépendances et la convergence avant de rendre le nouveau profil prioritaire ou de retirer l’ancien SSID.

Le roaming, les réseaux multi-sites et les solutions NAC doivent être testés avec plusieurs points d’accès, plusieurs NPS et les délais de CRL. Un test près d’un seul AP ne représente pas l’exploitation.

Je mesure succès d’authentification, temps d’association, renouvellement du certificat, incidents de mot de passe sans effet attendu et comportement hors ligne. Le rollback conserve un réseau d’administration séparé.

Une configuration décrit ce qui devrait arriver. L’inventaire montre un état observé à un instant donné, tandis qu’un log d’exécution indique ce que le composant a réellement tenté. Les horodatages et les contextes doivent correspondre avant de relier ces informations.

Les états non applicable, pending, conflict, error et success doivent rester séparés. L’absence d’un poste dans un rapport ne permet pas de conclure : il peut être hors ligne, non éligible, non ciblé, en retard de télémétrie ou exclu de la collecte.

Pilote, généralisation et maintien en conditions opérationnelles

Le pilote couvre plusieurs modèles matériels, versions de Windows, profils réseau, populations utilisateur et exceptions métier. Une cohorte témoin aide à distinguer l’effet du changement d’une évolution globale du service, d’une mise à jour applicative ou d’un incident réseau.

Les critères GO sont définis avant le début : couverture, taux de succès, délai de convergence, incidents, tickets support, régressions et temps de rollback. Une moyenne satisfaisante ne masque pas un sous-groupe en échec ; les résultats sont donc segmentés par version, modèle, site et mode de gestion.

Les cas négatifs sont testés volontairement : appareil hors ligne, licence absente, identité non éligible, règle non applicable, réseau filtré et retour arrière. Un design exploitable doit échouer de manière visible, sûre et compréhensible pour le support.

Après généralisation, les exceptions, permissions, versions de profil et dépendances doivent être revues régulièrement. Le service cloud et Windows évoluent ; une décision correcte aujourd’hui doit rester traçable et être revalidée lorsqu’un prérequis ou une interface change.

Configuration recommandée et déploiement par étapes

La procédure applique la méthode recommandée sur un périmètre pilote. Chaque étape précise où agir, quoi configurer, le résultat attendu, la façon de le vérifier, l’impact et la méthode de retour arrière.

Je ne poursuis pas si le résultat attendu manque. Une extension réalisée sur un état partiellement compris rendrait les écarts plus coûteux à isoler et à corriger.

Paramètres, commandes et automatisation

Les commandes présentées servent à vérifier ou illustrer la configuration. Les diagnostics restent en lecture seule. Toute remédiation doit borner sa cible, proposer une simulation lorsque l’action s’y prête, journaliser les changements et définir le retour arrière avant son utilisation réelle.

Je documente le contexte utilisateur ou SYSTEM, les permissions, les valeurs attendues et les effets de bord. Un extrait ne doit jamais introduire un paramètre implicite ou masquer une modification d’état.

# Exemple de collecte en lecture seule — à adapter avant utilisation
$ErrorActionPreference = 'Stop'
try {
  netsh.exe wlan show interfaces
  netsh.exe wlan show profiles
  Get-ChildItem Cert:\LocalMachine\My,Cert:\CurrentUser\My |
    Where-Object EnhancedKeyUsageList -match 'Client Authentication' |
    Select-Object Subject,Issuer,Thumbprint,NotAfter,HasPrivateKey
} catch { Write-Error "Collecte Wi-Fi impossible : $($_.Exception.Message)"; exit 1 }

Validation, indicateurs et critères GO / NO-GO

La validation combine un contrôle technique local, la donnée de service et un indicateur d’usage ou d’exploitation adapté. Un état vert dans le portail ne prouve pas à lui seul que le besoin initial est satisfait.

Le passage à la vague suivante exige des seuils atteints, aucune régression critique, des exceptions documentées et un rollback disponible. Toute divergence inexpliquée maintient la décision en NO-GO.

• Cartographier chaînes et identités.
• Configurer NPS et son certificat.
• Déployer les racines.
• Déployer le certificat client.
• Affecter le profil Wi-Fi
• Tester plusieurs sites et contextes
• Retirer l’ancien profil par anneaux

Exploitation, journaux et contrôle continu

La chronologie relie l’heure de la demande, le check-in, l’événement local, la décision du composant et la remontée dans le portail. Conservez l’heure UTC et l’heure locale. Avant tout partage, anonymisez les UPN, DeviceId, TenantId, noms internes, certificats, adresses et contenus métiers.

La collecte initiale reste en lecture seule. Ne videz pas un cache, ne supprimez pas une clé, ne réinitialisez pas un agent et ne forcez pas un enrôlement avant d’avoir capturé les informations utiles. Ces actions changent l’état et peuvent faire disparaître la cause initiale.

Les scripts publiés ici illustrent la collecte décrite dans l’article et restent en lecture seule. Une remédiation doit proposer une simulation, limiter sa cible, expliquer son impact et restaurer l’état précédent. Une opération privilégiée ou à grande échelle exige en plus une validation formelle et un pilote représentatif.

• Cartographier chaînes et identités.
• Configurer NPS et son certificat.
• Déployer les racines.
• Déployer le certificat client.
• Affecter le profil Wi-Fi
• Tester plusieurs sites et contextes
• Retirer l’ancien profil par anneaux

Exceptions, erreurs connues et traitement

Une recommandation exploitable doit prévoir les exceptions et les échecs. Je relie chaque symptôme à une cause à confirmer et à une preuve ; la correction n’est appliquée que lorsque cette preuve est obtenue.

Les exceptions durables ont un propriétaire, une justification, une date de révision et une mesure compensatoire. Elles ne sont pas dissimulées dans un groupe d’exclusion sans gouvernance.

Rollback, gestion du changement et points de vigilance

Le rollback est préparé avant le pilote et restaure explicitement la valeur, l’affectation ou l’autorité précédente. Je vérifie ensuite la convergence locale et la remontée du nouvel état au lieu de m’arrêter à la suppression de la configuration.

La recommandation doit être réévaluée lors d’une évolution de licence, de version, de support ou de responsabilité. Une validation locale ne constitue jamais une qualification de production.