EAP ou certificats clients ? Décider de l’authentification IKEv2

Votre passerelle peut prouver sa propre identité par certificat tout en prouvant la vôtre via EAP, et cette combinaison est courante plutôt que contradictoire. Les deux mécanismes répondent à des questions différentes : ce point de terminaison est-il celui que j’attends, et cet utilisateur ou appareil est-il autorisé. Voir EAP dans un profil ne désactive pas la validation du serveur. C’est lire le profil comme un réglage unique qui pousse les gens à réinitialiser le mauvais justificatif.

Déterminez quelle affirmation a échoué avant de toucher l’un ou l’autre objet. L’étape de l’échec vous le dit, si vous la lisez dans l’ordre.

Deux justificatifs, deux affirmations

Un certificat serveur lie un nom à une clé, et le client vérifie cette liaison par rapport à son magasin de confiance. Un certificat client lie une identité à une clé, et la passerelle vérifie que le certificat présenté s’enchaîne à quelque chose en quoi elle a confiance. EAP transporte un échange d’authentification dont le contenu dépend de la méthode choisie. Ce sont trois structures aux durées de vie, aux propriétaires et aux modes de défaillance différents.

Une phrase secrète qui déverrouille une clé privée n’est pas un mot de passe de compte, même lorsque les deux invites apparaissent à quelques secondes d’intervalle. L’une est locale au magasin de clés de l’appareil, et l’autre est validée par un serveur d’authentification derrière la passerelle.

EAP est un conteneur, pas une méthode

EAP est un cadre : la passerelle et le client négocient une méthode, et la méthode décide si un mot de passe, un jeton, un échange interne tunnelisé ou un certificat intervient, comme l’expose la documentation strongSwan sur IKEv2. C’est pourquoi EAP-TLS ne ressemble en rien à EAP-MSCHAPv2 côté client, bien que les deux apparaissent comme EAP dans un menu. Un profil qui ne nomme qu’EAP ne vous a pas dit ce qui sera demandé à l’utilisateur.

Lisez la méthode et le backend ensemble. Le backend détermine le format du compte, le comportement de verrouillage et ce qu’une réinitialisation de mot de passe change réellement, et rien de tout cela n’est visible dans le profil client.

Le déploiement mixte est normal

Certificat serveur plus EAP pour l’utilisateur est la forme que déploient la plupart des passerelles d’accès à distance, car elle donne au client un point de terminaison vérifiable et à l’opérateur une identité par utilisateur dans un magasin de comptes central. Des déploiements à certificats clients existent aussi, généralement là où l’identité de l’appareil compte plus qu’un mot de passe. Les deux sont légitimes, et l’erreur est de supposer que ce que vous avez vu la semaine dernière est ce qui se trouve devant vous.

Demandez à l’opérateur la méthode et le format de compte documentés au lieu de les déduire des noms de champs d’un client.

Décider à partir de l’étape de l’échec

Ordonnez les observations. Une erreur de confiance avant toute invite utilisateur est un problème de certificat serveur et aucun mot de passe ne le corrigera. Une invite suivie d’un rejet est un problème d’authentification utilisateur, avec la méthode EAP et le backend comme suspects. Une authentification réussie suivie d’un échec de child-SA n’est ni l’un ni l’autre.

Deux autres distinctions comptent. Un client qui refuse le certificat serveur signale généralement une inadéquation de nom ou une autorité inconnue, ce qui est une question de magasin de confiance. Une passerelle qui rejette l’utilisateur journalise souvent la méthode EAP et une catégorie de motif, ce qui est une question de compte ou de politique.

Exploiter les deux modèles

Pour les certificats, le travail est l’émission, le renouvellement, la révocation et le retrait des appareils perdus, et il se fait selon un calendrier que vous contrôlez. Pour EAP, le travail est le cycle de vie du compte, la prise en charge des méthodes sur chaque plateforme cliente et le second facteur que le backend exige. Aucun modèle n’est moins cher dans l’absolu ; ils chargent des équipes différentes. Notez lequel votre déploiement utilise réellement, car les scripts de support diffèrent plus que la configuration.

Gardez-les séparés dans vos notes. Une expiration de certificat produit une défaillance à une date, un verrouillage de compte produit une défaillance après un changement de mot de passe, et une inadéquation de méthode produit une défaillance sur une seule plateforme.

Une fois l’identité acceptée

L’authentification est une porte. L’association de sécurité enfant, les sélecteurs de trafic, le DNS et les permissions propres à l’application sont des portes ultérieures, et chacune échoue selon ses propres conditions. Une identité acceptée qui n’atteint rien n’est pas un problème d’authentification.

Consignez la méthode, le compte ou le certificat utilisé et l’étape qui a échoué. Cette note transforme l’incident suivant en recherche plutôt qu’en expérimentation.