Dépannage des problèmes d'authentification 802.1X sur Windows 11 : guide informatique d'entreprise

Réponse rapide : la plupart des échecs 802.1X sur Windows 11 après une mise à jour proviennent de l'une de ces quatre causes : le certificat du serveur RADIUS n'est plus validé (Event ID 12013), Credential Guard bloque le single sign-on PEAP-MSCHAPv2, un certificat client est manquant ou expiré pour EAP-TLS, ou le service Configuration automatique réseau câblé (dot3svc) n'est pas exécuté sur Ethernet. Consultez d'abord le journal opérationnel WLAN-AutoConfig ou Wired-AutoConfig, faites correspondre l'ID d'événement dans les tableaux ci-dessous, puis corrigez le profil de manière centralisée via une stratégie de groupe ou Intune plutôt qu'ordinateur portable par ordinateur portable.

Le déploiement et la maintenance de l'authentification réseau 802.1X dans les environnements d'entreprise nécessitent une interopérabilité fluide entre les systèmes d'exploitation clients, les points d'accès, l'infrastructure de commutation et les serveurs d'authentification RADIUS. À la suite des mises à jour de fonctionnalités de Windows 11, les services informatiques d'entreprise constatent fréquemment des pics soudains d'échecs d'authentification sur les réseaux sans fil WiFi et Ethernet câblés.

Ce guide technique fournit un cadre de diagnostic étape par étape pour identifier les causes profondes, résoudre les ruptures de confiance RADIUS, corriger les conflits Credential Guard et établir un contrôle d'accès réseau 802.1X fiable pour les terminaux Windows 11 gérés.

Comprendre les changements d'architecture 802.1X dans Windows 11

Windows 11 introduit des contrôles de sécurité renforcés qui modifient la façon dont le système d'exploitation gère la négociation EAP (Extensible Authentication Protocol), la validation des certificats et le stockage en cache des identifiants. Bien que ce renforcement de la sécurité protège les appareils de l'entreprise contre le vol d'identité, il expose des faiblesses de configuration sous-jacentes dans les objets de stratégie de groupe (GPO) et les charges utiles de gestion des appareils mobiles (MDM) existants.

Causes principales des échecs d'authentification 802.1X sur Windows 11

Lorsqu'un appareil Windows 11 ne parvient pas à s'authentifier sur un réseau d'entreprise 802.1X, le problème provient généralement de l'un des quatre vecteurs de défaillance principaux :

1. Rupture de la validation du certificat du serveur RADIUS

Lors de la poignée de main 802.1X EAP-TLS ou PEAP, le serveur RADIUS présente son certificat numérique X.509 pour prouver son identité au client. Windows 11 valide trois critères avant de poursuivre :

• Chaîne de confiance : Le certificat de l'AC racine émettrice doit résider dans le magasin Autorités de certification racines de confiance de l'ordinateur local du point de terminaison.
• Subject Alternative Name (SAN) : Le nom d'hôte ou FQDN du serveur RADIUS doit correspondre au nom de serveur spécifié dans la configuration XML du profil 802.1X du client.
• Expiration et révocation : Le certificat ne doit pas être expiré et doit passer les vérifications de la liste de révocation de certificats (CRL) ou OCSP.

Si l'un des critères échoue, Windows 11 met immédiatement fin à la session EAP pour empêcher la connexion à de potentiels points d'accès malveillants.

2. Conflits entre Credential Guard et PEAP-MSCHAPv2

Credential Guard utilise la sécurité basée sur la virtualisation (VBS) pour isoler les secrets stockés en mémoire. Les configurations 802.1X héritées reposant sur PEAP-MSCHAPv2 tentent d'extraire les hachages de connexion utilisateur pour s'authentifier automatiquement auprès d'Active Directory. Credential Guard bloque cet accès à la mémoire, entraînant des boucles d'invitation d'identifiants répétées ou un rejet explicite par le serveur RADIUS.

3. Certificats clients manquants ou expirés (EAP-TLS)

Dans les environnements zero-trust utilisant EAP-TLS, chaque appareil ou utilisateur présente un certificat individuel délivré par une autorité de certification interne (comme Microsoft ADCS). Les échecs de connexion surviennent lorsque les profils de certificats Intune SCEP ou PKCS ne se synchronisent pas, que les certificats clients expirent ou que les attributs d'utilisation étendue de la clé (EKU) de la clé privée ne contiennent pas Authentification du client (1.3.6.1.5.5.7.3.2).

4. État du service Configuration automatique réseau câblé (dot3svc)

Pour les environnements Ethernet câblés 802.1X, les installations de bureau Windows 11 n'activent pas le service dot3svc par défaut. Par conséquent, les cartes réseau (NIC) ne répondent pas aux trames EAPOL Start transmises par les ports de commutateur gérés, laissant l'appareil sans accès au réseau ou avec une adresse IP APIPA attribuée (169.254.x.x).

Flux de travail diagnostique étape par étape pour les administrateurs IT

Pour résoudre de manière systématique les échecs d'authentification sur les points de terminaison gérés, suivez cette séquence de diagnostic :

Phase 1 : Analyser les journaux de l'Observateur d'événements Windows

Windows enregistre tous les événements réseau 802.1X dans des journaux d'opérations spécialisés de l'Observateur d'événements :

• 802.1X sans fil : Accédez à Journaux des applications et des services > Microsoft > Windows > WLAN-AutoConfig > Opérationnel
• 802.1X câblé : Accédez à Journaux des applications et des services > Microsoft > Windows > Wired-AutoConfig > Opérationnel

Phase 2 : Exécuter des diagnostics en ligne de commande netsh

Ouvrez une session Invite de commandes ou PowerShell avec des privilèges élevés sur le terminal concerné pour inspecter les états réseau actifs et exporter les profils de configuration :

# Vérifier l'état de l'interface sans fil active et la qualité du signal
netsh wlan show interfaces

# Lister tous les profils sans fil 802.1X installés
netsh wlan show profiles

# Exporter un profil sans fil en XML pour inspection
netsh wlan export profile name="Corporate-WiFi" folder="C:\temp" key=clear

# Inspecter le statut 802.1X Ethernet filaire actif
netsh lan show state

# Vérifier l'installation du magasin de certificats de la CA racine locale
certutil -store Root "Your-Internal-Root-CA"

Phase 3 : Vérifier si la requête a atteint le serveur RADIUS

Les journaux Windows indiquent uniquement ce que le client a vu. Avant de modifier un profil, confirmez quel côté a échoué :

• Aucune requête dans les journaux RADIUS : l'appareil n'a jamais atteint le serveur. Vérifiez la configuration RADIUS du point d'accès ou du commutateur, le secret partagé et la joignabilité IP, ainsi que le fonctionnement de dot3svc ou WLAN AutoConfig sur le client.
• Access-Reject enregistré : le serveur a reçu la requête et l'a refusée. Sur Microsoft NPS, filtrez le journal de sécurité pour l'ID d'événement 6273 et lisez le code de raison.
• Access-Accept enregistré mais l'appareil n'a toujours pas de réseau : l'authentification a fonctionné. Examinez plutôt l'attribution de VLAN, l'étendue DHCP et la configuration des ports du commutateur.

Restaurer un profil 802.1X filaire qui a disparu après une mise à jour

Si l'onglet Authentification est vide après une mise à jour de fonctionnalités, réimportez le profil depuis un appareil fonctionnel :

# Sur un appareil fonctionnel : exporter le profil filaire
netsh lan export profile folder="C:\temp" interface="Ethernet"

# Sur l'appareil concerné : s'assurer que Configuration automatique réseau câblé est en cours d'exécution
Set-Service -Name dot3svc -StartupType Automatic
Start-Service dot3svc

# Import the exported profile
netsh lan add profile filename="C:\temp\Ethernet.xml" interface="Ethernet"

Cela permet de faire fonctionner un ordinateur portable. Pour éviter que le problème ne se reproduise, déployez le même profil via une stratégie de groupe (GPO) ou Intune comme décrit ci-dessous, afin que chaque mise à jour l'applique à nouveau.

Stratégies de résolution : GPO et Microsoft Intune

Une fois le mécanisme de défaillance identifié, déployez des mises à jour de stratégies à l'échelle de l'entreprise afin de standardiser la configuration des points d'accès sur tous les appareils Windows 11.

Résolution via les stratégies de groupe Active Directory (GPO)

Pour les appareils joints au domaine, configurez des stratégies centralisées pour réseaux sans fil et câblés :

1. Ouvrez la console de gestion des stratégies de groupe (gpmc.msc) et modifiez votre stratégie de référence pour les appareils.
2. Naviguez vers Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Services système. Localisez Configuration automatique de réseau câblé, définissez le mode de démarrage sur Automatique, puis démarrez le service.
3. Naviguez vers Stratégies de clé publique > Autorités de certification racines de confiance. Importez le certificat de l'autorité de certification racine émettrice pour votre serveur RADIUS.
4. Naviguez vers Stratégies de réseau sans fil (IEEE 802.11), ouvrez votre profil d'entreprise, sélectionnez l'onglet Sécurité, puis définissez l'authentification sur Microsoft : Carte à puce ou autre certificat (pour EAP-TLS) ou PEAP.
5. Cliquez sur Propriétés et cochez explicitement votre autorité de certification racine dans la liste Autorités de certification racines de confiance tout en spécifiant les FQDN de votre serveur RADIUS dans le champ Se connecter à ces serveurs.

Déploiement de profils MDM via Microsoft Intune

Pour les appareils gérés dans le cloud ou hybrides dans Intune :

1. Créez un profil de certificat de confiance contenant le certificat de votre autorité de certification racine d'entreprise et attribuez-le à Tous les appareils.
2. Créez un profil de certificat PKCS ou SCEP secondaire pour délivrer des certificats clients uniques aux appareils ou utilisateurs pour EAP-TLS.
3. Créez un profil de configuration WiFi avec EAP-TLS spécifié comme type d'EAP, en faisant référence au profil de certificat de confiance et au profil SCEP/PKCS.
4. Assurez-vous que l'ordre d'évaluation des stratégies permet l'installation du certificat de confiance avant l'application du profil WiFi.

Architecture de sécurité à long terme : Migration vers EAP-TLS et Passpoint

Bien que PEAP-MSCHAPv2 puisse être corrigé, les protocoles 802.1X basés sur des mots de passe restent intrinsèquement vulnérables à la collecte d'identifiants, aux attaques par dictionnaire hors ligne et à l'usurpation de points d'accès non autorisés. Les directives de sécurité du secteur émanant du NIST et de la Wi-Fi Alliance préconisent de migrer les réseaux d'entreprise vers l'authentification par certificat EAP-TLS ou Passpoint (Hotspot 2.0).

En savoir plus sur la mise en œuvre d'architectures de sécurité de bout en bout dans notre Enterprise WiFi Security Guide complet. Pour des comparaisons détaillées de protocoles, consultez notre analyse des méthodes EAP comparées (PEAP, EAP-TLS, EAP-TTLS et EAP-FAST) ou découvrez le déploiement automatisé de certificats dans notre guide sur le déploiement de certificats WiFi via Microsoft Intune.

En associant le 802.1X basé sur des certificats à la gestion automatisée de RADIUS dans le cloud, les équipes informatiques d'entreprise éliminent les demandes de mot de passe, simplifient l'intégration des terminaux Windows 11 et obtiennent un contrôle d'accès au réseau zero-trust sur l'ensemble des sites de l'entreprise.

Quand faire évoluer Windows 11 802.1X vers le RADIUS-as-a-Service

La plupart des échecs mentionnés dans ce guide proviennent d'une infrastructure qui doit être maintenue manuellement en phase avec Windows : un certificat de serveur NPS ou FreeRADIUS qui expire, une autorité de certification racine manquante dans les nouvelles builds, ou une politique PEAP-MSCHAPv2 qui n'est plus prise en charge par Credential Guard. Le transfert de l'authentification vers le cloud élimine le serveur de cette liste.

Purple RADIUS-as-a-Service authentifie les appareils Windows 11 avec EAP-TLS, PEAP, EAP-TTLS ou EAP-FAST, vérifie chaque requête auprès de votre fournisseur d'identité et attribue le bon VLAN, sur les points d'accès que vous utilisez déjà - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Il remplace Microsoft NPS, FreeRADIUS et Cisco ISE, et s'exécute sur plusieurs régions, de sorte qu'aucun serveur n'est à corriger après une mise à jour des fonctionnalités.

Choisissez la configuration qui correspond à votre annuaire :

• RADIUS avec Microsoft Intune - fournissez les certificats SCEP ou PKCS et le profil WiFi dans un seul jeu de règles.
• RADIUS avec Microsoft Entra ID - 802.1X basé sur des certificats pour les appareils hébergés uniquement dans le cloud, sans contrôleur de domaine.
• RADIUS avec Okta ou Google Workspace - le même modèle pour les annuaires non-Microsoft.

Vous préférez comparer les options d'abord ? Consultez notre comparatif des fournisseurs de cloud RADIUS et notre guide EAP-TLS vs PEAP.

Vous corrigez le même problème 802.1X après chaque mise à jour de Windows ? Réservez une démonstration et nous vous expliquerons comment faire évoluer votre parc Windows 11 vers un réseau WiFi basé sur des certificats via un RADIUS cloud, en utilisant vos points d'accès existants.