Dépannage
Problèmes de connexion
Vue client
XML incorrect
Impossible de se connecter car vous avez besoin d’un certificat pour vous connecter. Contactez votre support informatique.
Vérifiez que votre client possède un certificat pour s’authentifier et que vous utilisez le profil de configuration WiFi ou XML.
Problèmes de racine de confiance
Impossible de se connecter à ce réseau.
Vérifiez que vous avez fait ce qui suit :
Indiqué à votre serveur RADIUS quels certificats sont autorisés à se connecter comme décrit ici
Importé le certificat RADIUS actif en tant que racine de confiance sur votre client comme décrit ici
Continuer la connexion ?
Continuer la connexion ? Si vous vous attendez à trouver le WiFi d’entreprise à cet emplacement, allez-y et connectez-vous. Sinon, il peut s’agir d’un autre réseau portant le même nom.
Afficher les détails du certificat.
Si vos clients doivent vérifier lors de la première connexion et que vous voyez cette boîte de dialogue :
Assurez-vous d’avoir référencé le certificat du serveur RADIUS dans votre profil WiFi et d’avoir fourni l’attribut SAN du certificat du serveur (FQDN) et le nom commun (CN) :
Vue serveur
CA inconnue
Si vos Journaux contiennent des messages d’erreur similaires à ceux montrés ci-dessous
cela peut avoir les causes profondes suivantes :
Le client renvoie une erreur
Alerte TLS lecture : fatal : CA inconnueVotre client ne connaît pas le certificat du serveur et rejette la connexion. Vérifiez que vous avez ajouté votre certificat du serveur comme décrit ici.
Vous avez changé/ajouté un nouveau certificat du serveur et votre profil XML sur le client utilise l’ancien. Dans ce cas, veuillez vérifier que vous avez soit mis à jour votre profil WiFi/Câblé soit régénéré votre XML après avoir ajouté les certificats et l’avoir poussé vers vos clients.
Le serveur renvoie une erreur
Alerte TLS écriture : fatal : CA inconnueVotre serveur RADIUS ne connaît pas l’émetteur du certificat utilisé pour l’authentification. Ajoutez votre CA comme décrit ici.
Certificat inconnu
Si vous utilisez macOS (et éventuellement d’autres plateformes Apple) et si vos Journaux contiennent des messages d’erreur similaires à celui montré ci-dessous
cela peut avoir les causes profondes suivantes :
Erreur de déchiffrement | Accès refusé
Si vos Journaux contiennent des messages d’erreur similaires à ceux montrés ci-dessous
... alors il s’agit probablement d’un bug du logiciel TPM sur vos machines Windows. Plus d’informations à ce sujet peuvent être trouvées dans la documentation SCEPman.
Si vous voyez quelque chose comme ceci dans vos Journaux
... il peut y avoir deux raisons. L’une est que votre profil WiFi référence le mauvais certificat racine pour la validation du serveur. Veuillez vous assurer que votre profil est correctement configuré. Si c’est le cas et que vous rencontrez toujours ce problème, essayez de définir votre KSP sur KSP logiciel.
Le paramètre Key Storage Provider (KSP) détermine l’emplacement de stockage de la clé privée pour les certificats utilisateur finaux. Le stockage dans le TPM est plus sûr que le stockage logiciel, car le TPM fournit une couche de sécurité supplémentaire pour prévenir le vol de clés. Cependant, il existe un bug dans certaines versions plus anciennes du firmware TPM qui invalide certaines signatures créées avec une clé privée prise en charge par le TPM. Dans de tels cas, le certificat ne peut pas être utilisé pour l’authentification EAP comme c’est courant pour les connexions Wi‑Fi et VPN. Les versions de firmware TPM affectées incluent :
STMicroelectronics : 71.12, 73.4.17568.4452, 71.12.17568.4100
Intel : 11.8.50.3399, 2.0.0.2060
Infineon : 7.63.3353.0
IFX : Version 3.19 / Spécification 1.2
Si vous utilisez un TPM avec ce firmware, mettez soit à jour votre firmware vers une version plus récente soit sélectionnez "KSP logiciel" comme fournisseur de stockage des clés.
Impossible de continuer, car le pair se comporte mal
Si vos journaux contiennent des rejets avec l’erreur "Impossible de continuer, car le pair se comporte mal" cela indique que le client a cessé de communiquer avec le service RADIUS, principalement parce que les paramètres de confiance sont incorrects. Dans ce cas, veuillez vérifier les certificats sur les appareils affectés.
Secret partagé RADIUS incorrect
Si votre (proxy) Journaux contiennent des messages d’erreur similaires à ceux montrés ci-dessous
alors un de vos points d’accès ou commutateurs essayant de se connecter à votre instance RADIUSaaS via un Proxy RADIUS utilise un Secret partagé.
Pour identifier le point d’accès ou le commutateur affecté, déterminez d’abord le proxy RADIUS en développant le message d’erreur et en recherchant la propriété proxyip Maintenant que vous connaissez le proxy, utilisez votre inventaire et vos connaissances des emplacements spécifiques ou des groupes d’appareils qui ne peuvent pas se connecter à votre réseau pour identifier l’appareil réseau mal configuré. Enfin, mettez à jour le secret partagé pour qu’il corresponde à la valeur configurée dans votre instance RADIUSaaS pour ce proxy.
Problèmes de certificat
La chaîne de certificats n’a pas pu être vérifiée
Lorsque vous souhaitez utiliser votre propre certificat serveur, votre serveur RADIUS requiert la chaîne complète de certificats afin de permettre aux autres participants (Proxy, clients RadSec, points de terminaison qui tentent de se connecter) de vérifier l’identité du serveur. Si vous voyez ce message, copiez et collez soit le certificat CA sous le certificat serveur dans le champ de texte, soit créez un bundle de certificats PKCS8 qui inclut tous les certificats depuis le certificat principal jusqu’à la racine.
Problèmes du portail d’administration
Connexion
Pour vous connecter au portail web RADIUSaaS ("Portail d’administration RADIUSaaS"), les exigences suivantes doivent être remplies :
Le UPN/adresse e-mail que vous avez fourni en tant qu’administrateur technique doit être authentifiable contre quelque Microsoft Entra ID (Azure AD) (il n’a pas besoin d’être une identité du tenant dont les utilisateurs utiliseront RADIUSaaS pour l’authentification réseau).
Le UPN/adresse e-mail que vous avez fourni en tant qu’administrateur technique doit avoir été enregistré sur votre instance RADIUSaaS comme décrit ici. Dans le cas où il s’agit de l’administrateur initial, veuillez nous contacter si vous pensez que nous avons enregistré le mauvais utilisateur.
L’objet utilisateur Microsoft Entra ID (Azure AD) derrière le UPN/l’adresse e-mail doit être habilité à accorder à l’application d’entreprise RADIUSaaS les autorisations suivantes (voir capture d’écran ci‑dessous) :
Lire le profil utilisateur de base
Maintenir accès aux données auxquelles vous lui avez donné accès (autoriser la demande de token d’actualisation)
Dans le cas où votre utilisateur Microsoft Entra ID (Azure AD) n’a pas les droits pour accorder les autorisations requises, aucune Application d’entreprise correspondante ne sera créée automatiquement dans votre Microsoft Entra ID (Azure AD). Pour contourner cela, demandez à votre service informatique d’accorder à votre utilisateur les permissions nécessaires.
Problèmes de configuration Intune
Affectation de profil
La configuration Wi‑Fi n’est pas déployée si les profils Wi‑Fi, SCEP et Certificat de confiance sont affectés à des groupes différents. Ils peuvent apparaître comme "En attente" ou il n’y a aucun état du tout. Veuillez utiliser le même groupe ou "Tous les appareils" resp. "Tous les utilisateurs" pour tous les profils liés.
Vous pouvez affecter le profil de certificat racine SCEP à la fois à "Tous les utilisateurs" et à "Tous les appareils" si vous avez un certificat d’appareil (affecté à "Tous les appareils") et un certificat utilisateur (affecté à "Tous les utilisateurs") en usage.
Certificat SCEP
Android
Android semble exiger un UPN dans le nom alternatif du sujet dans les versions récentes (même pour les certificats d’appareil). Veuillez ajouter cela dans votre profil SCEP (par ex. {{DeviceId}}@contoso.com) :
Profil Wi‑Fi
Android
Codes d’erreur courants : 0xc7d24fc5 ou -942518331
Les points clés sont :
sélectionnez le certificat Root CA pour validation du serveur (important : ne pas téléverser le certificat serveur de RADIUSaaS) - et -
définissez un nom de serveur radius
Remarque : Il semble y avoir une limite de caractères pour ce champ. Pour résoudre d’éventuels problèmes, vous pouvez simplement utiliser la partie domaine sans le sous‑domaine comme "radius-as-a-service.com" (au lieu de "contoso.radius-as-a-service.com").
Développeurs Android déclarent : "[...] doivent configurer à la fois un certificat Root CA, et soit un suffixe de domaine correspondant ou une correspondance de sujet alternative". Ainsi, le MDM peut utiliser "setAltSubjectMatch" ou "setDomainSuffixMatch" après avoir ajouté un certificat racine à la configuration Wi‑Fi. Intune semble utiliser "setDomainSuffixMatch" car "radius-as-a-service.com" suffit.
parfois confidentialité de l’identité est nécessaire (par ex. observé sur des appareils kiosk Android / Android Enterprise dédié)
Mis à jour
Ce contenu vous a-t-il été utile ?