Dépannage Android 802.1X et EAP-TLS : une liste de contrôle de déploiement pour Intune et Microsoft Entra ID

Les téléphones Android gérés échouent généralement à la validation EAP-TLS pour l'une de ces quatre raisons. Le profil WiFi ne dispose pas d'un certificat d'autorité de certification (CA) ou d'un domaine, ce qui conduit Android à rejeter le serveur RADIUS. Le certificat client se trouve dans un profil différent. Le champ des noms de serveurs RADIUS ne correspond pas au certificat du serveur. Ou le profil racine de confiance n'a jamais atteint l'appareil.

À quoi ressemble un échec EAP-TLS sur Android ?

EAP-TLS (Extensible Authentication Protocol with Transport Layer Security) authentifie un appareil à l'aide d'un certificat plutôt que d'un mot de passe. Il s'exécute au sein de la norme IEEE 802.1X, le standard de contrôle d'accès basé sur les ports. 802.1X confie l'authentification à un serveur RADIUS (Remote Authentication Dial-In User Service).

En cas d'échec sur Android, vous constaterez généralement l'un de ces symptômes :

• Le réseau apparaît dans la liste mais ne dépasse jamais l'état "Connexion en cours", puis repasse à "Enregistré".
• L'appareil affiche une erreur d'authentification générique. La formulation varie selon le fabricant.
• Le réseau fonctionne sur les téléphones Samsung mais pas sur les Google Pixel, ou inversement.
• Le réseau fonctionne sur les téléphones d'entreprise mais échoue sur les appareils personnels enregistrés avec un profil professionnel.
• Rien n'apparaît du tout dans vos journaux RADIUS.

Ce dernier symptôme est le plus important. Un appareil qui n'atteint jamais le serveur RADIUS présente un problème de profil, et non un problème d'authentification.

Quelles sont les causes habituelles des échecs EAP-TLS sur Android ?

Validation de serveur plus stricte dans les versions récentes d'Android

Les versions récentes d'Android ont supprimé l'option "Ne pas valider" pour les nouveaux réseaux d'entreprise. Android a désormais besoin de deux éléments avant de transmettre son certificat : un certificat de CA de confiance et un domaine correspondant.

Sans ces deux éléments, l'appareil refuse de finaliser la liaison TLS. Des profils qui fonctionnaient depuis des années sur des versions plus anciennes peuvent échouer dès qu'un appareil reçoit une mise à jour du système d'exploitation.

Certificat dans le profil professionnel, réseau rejoint depuis le profil personnel

Android Enterprise sépare le profil professionnel du profil personnel, chacun possédant son propre magasin de certificats. Intune installe le certificat client et la racine de confiance dans le profil professionnel. Un collaborateur qui ajoute l'SSID manuellement depuis ses paramètres personnels ne peut pas accéder à ces certificats, ce qui entraîne l'échec de l'authentification.

Le champ des noms de serveurs RADIUS

Le profil WiFi Intune pour Android Enterprise comprend un champ pour les noms de serveurs RADIUS. La documentation de Microsoft demande d'y renseigner le nom DNS présent dans le certificat que votre serveur RADIUS présente. Android place cette valeur dans son champ de domaine et la compare avec le certificat du serveur. Si le champ est vide, mal orthographié ou contient une adresse IP, la validation échoue.

Le profil racine de confiance

Le profil WiFi pointe vers un profil de certificat de confiance Intune distinct. Ce profil doit contenir la CA racine ayant émis le certificat du serveur RADIUS. Une erreur fréquente consiste à déployer la racine associée à vos certificats clients alors qu'une CA différente a signé le certificat du serveur. Les deux profils doivent également cibler les mêmes groupes et le même type d'enregistrement Android Enterprise.

Différences entre fabricants

Samsung, Google Pixel et les versions d'autres fabricants étiquettent et organisent les paramètres WiFi d'entreprise différemment. Certains affichent des options supplémentaires, telles que la vérification en ligne du statut des certificats. Utilisez les appareils de votre propre parc comme référence, et non des captures d'écran d'une autre marque.

Comment identifier la cause de votre problème ?

Commencez par l'appareil, puis confirmez dans les journaux RADIUS. Le schéma récurrent dans les journaux indique généralement la cause.

Symptôme	Ce que montre le RADIUS	Cause probable	Première solution
Aucune tentative ne parvient au RADIUS	Aucune requête de l'appareil	Profil WiFi non appliqué, ou non-correspondance du nom de l'SSID	Vérifier le statut du profil par appareil dans Intune
Le handshake s'arrête après l'envoi du certificat par le serveur	Alerte TLS de la part du client, telle que "CA inconnue"	Racine de confiance incorrecte ou manquante, ou non-correspondance de domaine	Déployer l'autorité de certification (CA) racine du serveur et corriger les noms des serveurs RADIUS
Le handshake réussit côté serveur, puis échoue	Aucun certificat client présenté	Certificat SCEP ou PKCS manquant ou dans le mauvais profil	Confirmer que le profil de certificat a bien été appliqué pour cet appareil
Certificat accepté, puis rejeté	Access-Reject après validation du certificat	Mappage d'identité, révocation ou règle de stratégie	Vérifier le sujet du certificat ou le SAN par rapport au fournisseur d'identité
Échoue uniquement sur les appareils personnels	Aucune requête, ou aucun certificat client	Connexion à l'SSID effectuée depuis la session personnelle	Déployer le profil sur le profil professionnel et bloquer les connexions manuelles

Lire l'erreur sur l'appareil

Dans le centre d'administration Microsoft Intune, ouvrez l'appareil et vérifiez le statut de chaque profil de configuration. Un profil WiFi affiché comme étant en attente ou en erreur n'a jamais atteint l'appareil. Un profil de certificat en erreur signifie que la délivrance via SCEP (Simple Certificate Enrollment Protocol) ou PKCS (Public Key Cryptography Standards) a échoué. Corrigez cela avant de toucher au réseau.

Sur les appareils de test, les journaux Android Debug Bridge du demandeur WiFi indiquent l'alerte TLS exacte. Utilisez cette méthode pour un téléphone de test, pas pour un parc en production.

Lire les journaux RADIUS

FreeRADIUS, Microsoft Network Policy Server et les plateformes cloud RADIUS enregistrent tous l'endroit où l'échange EAP s'est arrêté. Effectuez une recherche par l'adresse MAC de l'appareil ou par l'identité du certificat. Une alerte TLS envoyée par le client signifie que le téléphone a rejeté votre serveur. Un Access-Reject après un certificat valide signifie que votre serveur a rejeté le téléphone.

Si les appareils s'authentifient puis se déconnectent lorsque le personnel se déplace d'un étage à l'autre, la cause est différente. Consultez Resolving Roaming Issues in Corporate WLANs. Les déconnexions qui coïncident avec des changements de canaux indiquent plutôt des événements radar. Voir DFS radar events on Cisco Meraki, HPE Aruba and Ruckus: a diagnostics checklist for channel changes.

Comment résoudre le problème dans Intune et sur chaque build Android ?

Dans Intune

1. Ouvrez le profil WiFi Android Enterprise correspondant au type d'enrôlement. Les appareils entièrement gérés, dédiés et appartenant à l'entreprise dotés d'un profil professionnel utilisent un type de profil. Les appareils personnels dotés d'un profil professionnel en utilisent un autre.
2. Définissez le type EAP sur EAP-TLS.
3. Saisissez le nom DNS du certificat du serveur RADIUS dans les noms de serveurs RADIUS. Le nom exact figurant sur le certificat est la valeur la plus sûre. Ne saisissez jamais d'adresse IP.
4. Sélectionnez le profil de certificat approuvé qui contient la CA racine du serveur.
5. Sélectionnez le profil SCEP ou PKCS pour l'authentification client.
6. Assignez les trois profils au même groupe.

Sur Samsung, Pixel et autres versions

Ne demandez pas au personnel de modifier manuellement les paramètres d'entreprise, quelle que soit la marque. Les modifications manuelles contournent Intune et se retrouvent du mauvais côté du profil professionnel. Si un fabricant échoue alors qu'un autre fonctionne, comparez d'abord l'état des profils. Testez ensuite la valeur du domaine par rapport à cette version dans votre laboratoire.

Du côté RADIUS

Confirmez que le certificat du serveur contient le nom DNS que vous avez saisi dans Intune. Confirmez que sa chaîne mène à la racine que vous avez déployée. Si vous utilisez Purple Staff WiFi, Purple fournit le service RADIUS cloud et se connecte à vos points d'accès via RadSec, c'est-à-dire RADIUS acheminé au sein de TLS. Les étapes de configuration du fournisseur se trouvent dans les articles d'assistance de Purple, par exemple Staff WiFi - Ubiquiti UniFi. Vérifiez les exigences des points d'accès dans Security and Hardware Compatibility.

Scénarios pratiques

Un hôtel de 200 chambres après une mise à jour Android

Prenons l'exemple d'un hôtel de 200 chambres disposant de 60 téléphones appartenant à l'entreprise pour le personnel de ménage et de maintenance. Après une mise à jour mensuelle, 40 téléphones ont cessé de se connecter au SSID du personnel. Les journaux RADIUS indiquaient des alertes TLS envoyées par les clients.

Le profil WiFi n'avait pas de valeur pour les noms de serveurs RADIUS, ce que les anciennes versions toléraient. L'équipe informatique a ajouté le nom DNS du certificat du serveur et a redéployé le profil. Les 60 téléphones se sont connectés après leur synchronisation Intune suivante, sans aucune réinitialisation d'usine. Les exploitants d'hôtels peuvent en savoir plus sur la connectivité du personnel sur notre page Hotels.

Une chaîne de vente au détail de 120 magasins avec des appareils personnels

Prenons l'exemple d'une chaîne de vente au détail (retail) de 120 magasins dont les directeurs de magasin possèdent des téléphones personnels enregistrés avec un profil professionnel. Les tickets d'assistance ont révélé que les téléphones de nombreux magasins ne contactaient jamais RADIUS.

Les directeurs avaient ajouté le SSID du magasin depuis leurs paramètres personnels, où aucun certificat n'existe. L'équipe a assigné le profil WiFi correspondant aux profils professionnels des appareils personnels et a demandé aux directeurs de supprimer les saisies manuelles. Les échecs de connexion ont cessé dès que chaque téléphone a reçu le profil géré.

Un opérateur ferroviaire renouvelant son certificat de serveur

Prenons l'exemple d'un opérateur ferroviaire qui gère le WiFi du personnel à bord et dans les dépôts (Trains). L'opérateur a renouvelé le certificat de son serveur RADIUS auprès d'une nouvelle autorité de certification (CA). Tous les appareils Android sont tombés en panne du jour au lendemain avec des alertes de type "CA inconnue". L'importation du nouveau certificat racine dans le profil de certificat approuvé avant la transition aurait permis d'éviter cette interruption. L'opérateur planifie désormais les modifications de racine deux semaines à l'avance.

Comment éviter que cela ne se reproduise ?

Liste de contrôle pour le déploiement des flottes Android dans Intune et Entra ID

• Cartographier les identités. Décidez si les certificats portent l'identifiant de l'appareil ou l'UPN du membre du personnel, à savoir leur nom de connexion Microsoft Entra ID. Configurez RADIUS pour qu'il corresponde à ce champ.
• Séparer par type d'enregistrement. Créez un ensemble de profils pour les appareils appartenant à l'entreprise et un autre pour les appareils personnels dotés d'un profil professionnel.
• Associer les profils. La racine de confiance, le certificat client et les profils WiFi doivent partager le même groupe d'attribution.
• Utiliser la bonne racine. Déployez la CA qui a signé le certificat du serveur RADIUS.
• Renseigner les noms des serveurs RADIUS. Utilisez le nom DNS du certificat du serveur, jamais une adresse IP.
• Tester sur plusieurs fabricants. Testez au moins un téléphone Samsung et un Pixel, ainsi que toute autre marque présente dans votre flotte.
• Interdire les connexions manuelles. Demandez au personnel de ne jamais ajouter l'SSID manuellement.
• Planifier le renouvellement des certificats. Déployez les nouvelles racines avant que le certificat du serveur ne change.
• Surveiller des deux côtés. Examinez l'état des profils Intune et les rejets RADIUS chaque semaine pendant le déploiement.

Pour l'intégration des fournisseurs d'identité, consultez Comment activer l'authentification unique.

Questions fréquentes

Est-ce que Purple Staff WiFi fonctionne avec les appareils Android gérés dans Intune ?

Oui. Purple Staff WiFi authentifie les appareils Android gérés à l'aide d'un protocole 802.1X basé sur des certificats auprès du RADIUS-as-a-Service cloud de Purple. Vous conservez Intune pour la distribution des certificats et des profils WiFi. Purple se connecte à Microsoft Entra ID, Okta et Google Workspace pour l'identité. Vos profils Intune pointent vers le certificat du serveur RADIUS de Purple au lieu d'un serveur sur site. Les règles relatives à Android présentées dans ce guide s'appliquent toujours : une racine de confiance et un domaine correspondant sont requis.

Ai-je besoin de nouveaux points d'accès pour exécuter EAP-TLS avec Purple ?

Non. Purple est indépendant du matériel et fonctionne comme une surcouche cloud sur les points d'accès que vous utilisez déjà. Les fabricants pris en charge incluent Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks et Fortinet. Chaque fabricant nécessite une configuration RADIUS pointant vers Purple. Les étapes de configuration se trouvent dans les articles d'assistance de Purple. Vérifiez les exigences relatives aux modèles dans l'article sur la compatibilité du matériel et de la sécurité avant de commencer.

Puis-je passer d'un NPS sur site à un RADIUS cloud sans réenregistrer les appareils Android ?Oui, dans la plupart des cas, vous le pouvez. Les appareils conservent leurs certificats clients existants si le nouveau service RADIUS fait confiance à votre CA émettrice. Vous mettez à jour le profil racine approuvé et les noms de serveurs RADIUS dans Intune pour qu'ils correspondent au nouveau certificat de serveur. Planifiez ces modifications de profil avant de basculer la cible RADIUS du SSID. Cela évite les échecs de type "CA inconnue" décrits dans ce guide qui surviennent du jour au lendemain.

Le protocole EAP-TLS est-il préférable à PEAP ou iPSK pour les appareils du personnel ?

Oui, pour les flottes gérées. EAP-TLS utilise un certificat par appareil ou par identité, il n'y a donc pas de mots de passe partagés susceptibles de fuiter. PEAP (Protected EAP) s'appuie sur un nom d'utilisateur et un mot de passe au sein d'un tunnel TLS. Le système iPSK (identity pre-shared key) attribue à chaque appareil ou groupe sa propre clé. L'iPSK convient aux appareils non gérés qui ne peuvent pas héberger de certificats. L'EAP-TLS est idéal pour les téléphones que vous gérez via Intune.

Quelles normes de conformité Purple respecte-t-il pour les données d'authentification du personnel ?

Purple est certifié ISO 27001 et Cyber Essentials, et est conforme au GDPR et à la CCPA. Le protocole 802.1X basé sur des certificats prend en charge le contrôle d'accès renforcé exigé par la norme PCI-DSS sur les réseaux proches des données des titulaires de cartes. Purple détient également la certification B Corp. Demandez les certificats actuels à votre équipe de compte si votre processus d'approvisionnement exige des copies.

Combien de temps prend un déploiement EAP-TLS sur Android ?

Attendez-vous à ce que l'essentiel de l'effort soit consacré à la PKI et à Intune, et non aux points d'accès. Pointer un SSID vers le RADIUS de Purple suit une courte liste de contrôle du fournisseur disponible dans le centre d'assistance. La création de profils SCEP ou PKCS, de profils de racine approuvée et de profils WiFi pour chaque type d'enregistrement prend plus de temps. Prévoyez du temps pour un projet pilote couvrant chaque fabricant de votre flotte avant le déploiement général.