Où va le code de défi statique dans une connexion OpenVPN

Le client affiche une seconde case après le champ du mot de passe, vous saisissez le code du jeton matériel, et la connexion échoue toujours avec une erreur d’authentification. Cette case existe, donc le profil l’a demandée. Que le serveur ait reçu la valeur dans une forme qu’il comprend est une autre question, et c’est celle à laquelle il vaut la peine de répondre d’abord.

Partez de l’invite que votre client affiche réellement

Un profil peut porter une directive de défi statique avec une chaîne d’invite et un indicateur qui contrôle si la réponse s’affiche pendant la saisie. L’invite est ce que vous voyez dans la boîte de dialogue ; l’indicateur est une préférence d’affichage pour cette même entrée. Ni l’un ni l’autre ne dit au serveur comment vérifier quoi que ce soit.

Comptez les champs qui vous ont réellement été donnés. Un champ pour un nom d’utilisateur plus un champ masqué, c’est une connexion par mot de passe ordinaire, sans aucun défi. Un second champ qui apparaît après le mot de passe, avec son propre libellé, c’est le client qui met en œuvre l’interaction de défi.

Si la seconde case n’apparaît jamais dans le client que vous utilisez, ce client n’implémente peut-être pas l’interaction, ou seulement via une autre interface, comme une interface de gestion. Vérifier le client coûte moins cher que réécrire le profil, et c’est généralement là que se trouve réellement l’écart.

Ce que le serveur doit déjà prendre en charge

Le profil décrit ce que le client doit recueillir. Il n’active pas la vérification côté serveur, et un serveur dépourvu de l’intégration d’authentification correspondante recevra simplement un mot de passe qu’il ne reconnaît pas. C’est pourquoi certains déploiements affichent l’invite et rejettent chaque code, et pourquoi la réponse de l’exploitant sur le mécanisme qui effectue le contrôle est celle qui compte.

Demandez à l’exploitant quel mécanisme effectue le contrôle. Il peut s’agir d’un greffon qui parle à PAM, d’un crochet de script qui valide la réponse auprès d’un service de jetons, ou d’une intégration fondée sur la gestion qui analyse elle-même la valeur empaquetée. Chacun attend une entrée légèrement différente.

C’est aussi ici qu’il faut calibrer les attentes. Une seconde invite est un mécanisme de saisie, pas la preuve qu’un second facteur est appliqué, car l’application se fait côté serveur et ne se voit que lorsque vous testez un code erroné.

Le champ encodé que l’interface de gestion envoie

Lorsqu’une interface pilote la connexion via l’interface de gestion, le mot de passe et la réponse au défi sont empaquetés dans une seule valeur avant l’envoi. La référence de l’interface de gestion documente le format : un préfixe, puis le mot de passe et la réponse comme composants Base64 distincts.

Base64 est un encodage, pas une protection. Il ne cache rien à qui peut lire le champ, et il ne transforme pas un code à usage unique en quelque chose de réutilisable. La valeur empaquetée mérite le même traitement qu’un mot de passe : hors des profils partagés, hors des lignes de commande et hors des journaux de diagnostic.

Cet encodage est aussi la source de confusion la plus courante, car il existe désormais trois formes qui se ressemblent et ne sont pas interchangeables. Un simple fichier d’identifiants contient un mot de passe. Une concaténation littérale du mot de passe et du code contient une autre chaîne. La réponse empaquetée d’un client de gestion en contient une troisième. Confirmez laquelle votre chemin de vérification attend avant de modifier un champ simplement parce qu’une erreur a disparu.

Statique contre dynamique : un moment différent

Un défi statique est connu avant l’envoi du premier identifiant, le client peut donc le demander d’emblée. Un défi dynamique arrive plus tard, envoyé par le flux d’authentification après qu’un échange a déjà commencé, et il exige un client capable de gérer une demande en pleine conversation.

La prise en charge de l’un ne vous donne pas l’autre. Une directive de profil qui configure une invite statique n’implémente pas un défi initié par le serveur, et une interface qui gère les demandes dynamiques peut toujours ne pas afficher une invite statique. Lire quel côté a initié la demande est le moyen le plus rapide de les distinguer.

Le fonctionnement sans surveillance est le moment où cela devient une question de conception plutôt que d’interface. Un code enregistré n’est pas un identifiant durable au démarrage, et une reconnexion des heures plus tard exigera une saisie fraîche, à moins que le déploiement prenne en charge un arrangement de jetons que l’exploitant a activé délibérément.

Testez le succès et l’échec, pas seulement la boîte de dialogue

Exécutez les deux moitiés du test. Des identifiants corrects avec une réponse valide devraient réussir ; des identifiants corrects avec une réponse délibérément erronée devraient être refusés. Si les deux réussissent, le client recueille une saisie que rien ne vérifie, et la boîte de dialogue a été prise pour un contrôle. Ce seul test attrape plus de déploiements que n’importe quelle revue de profil.

Répétez ensuite la connexion après une reconnexion, avec un compte qui n’est pas enrôlé, et via le client que vos utilisateurs exécutent réellement. L’apparition de l’invite est un comportement du client ; le refus d’un code erroné est le serveur qui applique quelque chose.