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 dispose d’un certificat pour s’authentifier et que vous utilisez le bon profil de configuration Wi-Fi ou XML.
Problèmes de racine de confiance
Impossible de se connecter à ce réseau.

Vérifiez que vous avez effectué les actions suivantes :
Indiqué à votre serveur RADIUS quels certificats sont autorisés à se connecter comme décrit ici
Importé le certificat actif du serveur RADIUS comme racine de confiance sur votre client comme décrit ici
Continuer la connexion ?
Continuer la connexion ? Si vous vous attendez à trouver Corporate WiFi à cet endroit, continuez 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 cette boîte de dialogue s’affiche :

Assurez-vous d’avoir référencé le certificat du serveur RADIUS dans votre profil Wi-Fi et fourni l’attribut SAN (FQDN) et le nom commun (CN) du certificat du serveur :

Vue serveur
AC inconnue
Si vos journaux contiennent des messages d’erreur similaires à ceux affichés ci-dessous
cela peut avoir les causes racines suivantes :
Le client renvoie une erreur
TLS Alert read:fatal:unknown CAVotre 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 modifié/ajouté un nouveau certificat du serveur et que votre profil XML sur le client utilise l’ancien. Dans ce cas, veuillez vérifier à nouveau que vous avez soit mis à jour votre profil Wi-Fi/filaire, soit régénéré votre XML après avoir ajouté les certificats, puis déployé celui-ci vers vos clients.
Le serveur renvoie une erreur
TLS Alert write:fatal:unknown CAVotre serveur RADIUS ne connaît pas l’émetteur du certificat utilisé pour l’authentification. Ajoutez votre AC 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 affiché ci-dessous
cela peut avoir les causes racines suivantes :
Il y a un caractère espace quelque part dans le nom du serveur du certificat dans votre WiFi ou Pour le profil XML filaire, cliquez profil de configuration.
Erreur de décryptage | Accès refusé
Si vos journaux contiennent des messages d’erreur similaires à ceux affichés ci-dessous
... alors il s’agit probablement d’un bug du logiciel TPM sur vos machines Windows. Vous trouverez plus d’informations à ce sujet dans la documentation SCEPman.
Si vous voyez quelque chose comme ceci dans vos journaux
... il peut y avoir deux raisons. La première est que votre profil Wi-Fi 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 Software KSP.
Le paramètre Key Storage Provider (KSP) détermine l’emplacement de stockage de la clé privée des certificats de l’utilisateur final. 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 empêcher le vol de clés. Cependant, il existe un bug dans certaines versions plus anciennes du microprogramme TPM qui invalide certaines signatures créées avec une clé privée prise en charge par TPM. Dans de tels cas, le certificat ne peut pas être utilisé pour l’authentification EAP, comme c’est le cas pour les connexions Wi-Fi et VPN. Les versions de microprogramme TPM concernées comprennent :
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 TPM avec ce microprogramme, mettez à jour votre microprogramme vers une version plus récente ou sélectionnez « Software KSP » comme fournisseur de stockage de 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 concernés.
Secret RADIUS partagé incorrect
Si votre (proxy) journaux contiennent des messages d’erreur similaires à ceux affichés ci-dessous
alors l’un de vos points d’accès ou commutateurs qui tente de se connecter à votre instance RADIUSaaS via un proxy RADIUS utilise un Secret partagé.
Pour identifier le point d’accès ou le commutateur concerné, commencez par déterminer 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 votre connaissance des emplacements ou groupes spécifiques d’appareils qui ne peuvent pas se connecter à votre réseau pour identifier l’équipement 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 de serveur, votre serveur RADIUS nécessite 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 ce message apparaît, copiez-collez soit le certificat de l’AC sous le certificat du serveur dans le champ de texte, soit créez un bundle de certificats PCKS8 incluant tous les certificats, de l’autorité racine jusqu’à la racine.
Problèmes du portail d’administration
Connexion
Afin de se connecter au portail web RADIUSaaS (« RADIUSaas Admin Portal »), les exigences suivantes doivent être remplies :
Le UPN/adresse e-mail que vous avez fourni en tant qu’administrateur technique doit pouvoir être authentifié auprès de un certain Microsoft Entra ID (Azure AD) (il n’est pas nécessaire qu’il s’agisse d’une identité du locataire 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
Conserver l’accès aux données que vous lui avez autorisé à consulter (autoriser la demande de jeton d’actualisation)

Si 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 ce problème, demandez à votre service informatique d’accorder à votre utilisateur les autorisations nécessaires.
Problèmes de configuration Intune
Attribution du profil
La configuration Wi-Fi ne sera pas déployée si les profils Wi-Fi, SCEP et certificat approuvé sont attribués à des groupes différents. Ils peuvent apparaître comme « En attente » ou il n’y a aucun statut du tout. Veuillez utiliser le même groupe ou « Tous les appareils » resp. « Tous les utilisateurs » pour tous les profils liés.
Vous pouvez attribuer le profil de certificat racine SCEP à la fois à « Tous les utilisateurs » et à « Tous les appareils » si vous utilisez un certificat d’appareil (attribué à « Tous les appareils ») et un certificat utilisateur (attribué à « Tous les utilisateurs »).
Certificat SCEP
Android
Android semble nécessiter un UPN dans le SAN (Subject Alternative Name) 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 de l’AC racine pour validation du serveur (important : ne téléversez pas le certificat du serveur de RADIUSaaS) - et -
définissez un nom du 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 sous-domaine, par exemple « radius-as-a-service.com » (au lieu de « contoso.radius-as-a-service.com »).
Développeurs Android indiquent : « [...] doivent configurer à la fois un certificat de l’AC racine, et soit une correspondance de suffixe de domaine soit 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 la confidentialité de l’identité est nécessaire (par ex. sur les appareils Android kiosque / Android Enterprise dédiés)
Mis à jour
Ce contenu vous a-t-il été utile ?