Cet article a été traduit automatiquement. La traduction peut contenir des imprécisions.
Passer à la version originale en anglais.
Ctrlk

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

  • Vérifiez vos journaux. Il existe une description détaillée de l’erreur. Il se peut que ce soit un ceci problème.

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 :

Affichage de l’attribut SAN (FQDN) et du 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 CA

    • Votre 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 CA

    • Votre 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 :

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 ?