Pourquoi modifier un fichier .ovpn ne peut pas activer le MFA sur le serveur

Vous ajoutez auth-user-pass à un profil, vous vous reconnectez, et le client demande un nom d’utilisateur et un mot de passe. On dirait que le MFA est actif. Puis vous saisissez un code provenant du mauvais compte, ou un code expiré depuis dix minutes, et le tunnel monte quand même. C’est le symptôme : le client a changé, le serveur non. Un mot de passe à usage unique n’est un facteur que lorsqu’un vérificateur sur le serveur décide s’il est valide pour l’identité qui le revendique.

L’invite prouve seulement que le client a demandé, rien de plus

Un fichier .ovpn est un document côté client. Il peut demander au client de réclamer des identifiants, de les mettre en cache ou d’arrêter de le faire. Il ne peut pas enrôler un utilisateur, installer un module PAM ni faire exiger au serveur un second facteur qu’il ne vérifie pas actuellement.

Installer une application d’authentification sur un téléphone ne crée pas non plus cette relation. Le projet Google Authenticator PAM est un composant de vérification OTP qui peut se placer derrière OpenVPN ; ce n’est pas un moyen de greffer la connexion au compte Google sur un profil importé.

L’enrôlement est la partie qu’un profil ne peut pas faire

TOTP a besoin d’un matériel d’enrôlement partagé entre l’application d’authentification et son vérificateur. Les six chiffres du téléphone sont la sortie ; la graine derrière eux est le secret, et elle appartient à une seule identité.

L’opérateur a donc besoin d’un processus d’enrôlement qui lie la bonne graine à la bonne identité VPN, plus un chemin de remplacement vérifié pour un téléphone perdu. Laisser les utilisateurs téléverser un fichier à leur nom transforme l’enrôlement en occasion d’appropriation de compte, et chiffrer le téléversement n’y change rien.

Une conception fondée sur PAM n’a pas besoin de créer un compte Unix distinct par utilisateur VPN. La documentation du module prend en charge d’autres chemins de secrets et un compte dédié à l’accès aux fichiers, c’est-à-dire une identité de système de fichiers et non l’identité de connexion vérifiée.

L’erreur courante est un chemin de secret fixe se terminant par un seul nom d’utilisateur, copié d’un exemple mono-utilisateur. C’est une démonstration pour une seule identité, pas une recherche par utilisateur, et l’utiliser pour chaque requête ne donne à personne une application d’authentification enrôlée indépendamment. Écrivez la correspondance des identités, protégez les fichiers de graines et gardez les contrôles de mot de passe, de certificat et de compte dans la même pile d’authentification.

Lisez la pile PAM pour voir ce qui est réellement exigé

Une ligne comme account required pam_permit.so n’implémente pas l’éligibilité du compte et n’ajoute pas de facteur. Elle autorise cette étape de gestion des comptes PAM, ce qui est une affirmation sur une étape et non sur vos utilisateurs.

Il en va de même pour les options d’enrôlement permissives. Accepter des utilisateurs sans secret enrôlé peut être un choix de déploiement délibéré, mais ce n’est pas la preuve que le MFA est obligatoire, et cela devrait être consigné comme une exception temporaire avec une date de fin.

Alignez l’interaction du client sur la conception du serveur

auth-user-pass

Cette directive demande la saisie d’un nom d’utilisateur et d’un mot de passe. Elle ne configure pas PAM, ne crée pas d’enregistrement d’enrôlement et ne dit pas au serveur que le champ mot de passe contient une valeur TOTP. L’intégration côté serveur et le client doivent s’accorder sur une interaction que le déploiement prend réellement en charge : un défi, un format d’identifiants combiné documenté, ou un flux propre au produit.

N’ajoutez pas un code au mot de passe simplement parce que le client affiche un seul champ. Cela ne fonctionne que là où le greffon du serveur attend exactement ce format, et cela échoue de façon déroutante partout ailleurs.

Gardez les graines et le matériel QR hors des profils partagés et des journaux de diagnostic courants. Un code soumis par le canal de connexion authentifié n’est pas le même objet que la graine fournie lors d’un enrôlement contrôlé, et les mélanger dans un ticket de support est la façon dont les secrets s’échappent.

Reconnexions, jetons et le test qui tranche

Prévoyez ce qui se passe après la première connexion réussie. Un code accepté auparavant peut être expiré ou rejeté comme rejeu lors de l’authentification suivante. auth-nocache contrôle la conservation des identifiants et n’installe pas le MFA, et reneg-sec 0 n’est pas une définition de la prise en charge de TOTP, quel que soit le nombre de fois où il apparaît dans les fils de forum.

Certains déploiements émettent des jetons d’authentification après le contrôle initial pour que les reconnexions ne redemandent pas. C’est une décision de conception avec sa propre fenêtre de validité et sa propre histoire de révocation, pas un réglage par défaut que vous héritez.

Testez ensuite la politique d’admission avec le client que les gens utilisent réellement. Un utilisateur enrôlé avec le bon mot de passe, le bon certificat et le code courant devrait se connecter. Un code erroné, un utilisateur sans enrôlement et un compte interdit devraient chacun échouer, et la raison devrait être visible dans le journal du serveur. Tant que vous n’avez pas vu ces refus, vous avez une invite, pas une politique.