Waarom het bewerken van een .ovpn-bestand MFA op de server niet kan aanzetten

Je voegt auth-user-pass toe aan een profiel, maakt opnieuw verbinding, en de client vraagt om een gebruikersnaam en wachtwoord. Het lijkt erop dat MFA aan staat. Dan voer je een code van het verkeerde account in, of een code die tien minuten geleden is verlopen, en de tunnel komt toch omhoog. Dat is het symptoom: de client veranderde, de server niet. Een eenmalig wachtwoord is alleen een factor wanneer een verifieerder op de server beslist of het geldig is voor de identiteit die er aanspraak op maakt.

De prompt bewijst alleen dat de client heeft gevraagd, niets meer

Een .ovpn-bestand is een document aan de clientzijde. Het kan de client vertellen om inloggegevens op te vragen, ze te cachen of daarmee op te houden. Het kan geen gebruiker registreren, geen PAM-module installeren of de server een tweede factor laten eisen die hij nu niet controleert.

Het installeren van een authenticator-app op een telefoon schept die relatie ook niet. Het Google Authenticator PAM-project is een OTP-verificatiecomponent die achter OpenVPN kan staan; het is geen manier om de Google-accountlogin op een geïmporteerd profiel te plakken.

Registratie is het deel dat een profiel niet kan doen

TOTP heeft registratiemateriaal nodig dat tussen de authenticator-app en de verifieerder wordt gedeeld. De zes cijfers op de telefoon zijn de uitvoer; de seed erachter is het geheim, en die hoort bij één identiteit.

De operator heeft dus een registratieproces nodig dat de juiste seed aan de juiste VPN-identiteit koppelt, plus een geverifieerd vervangpad voor een verloren telefoon. Gebruikers een bestand laten uploaden dat naar henzelf is vernoemd, maakt van registratie een kans op accountovername, en het versleutelen van de upload verandert dat niet.

Een op PAM gebaseerd ontwerp hoeft niet per VPN-gebruiker een apart Unix-account te maken. De moduldocumentatie ondersteunt alternatieve geheime paden en een toegewijd account voor bestandstoegang, wat een bestandssysteemidentiteit is en niet de loginidentiteit die wordt geverifieerd.

De gebruikelijke fout is een vast geheim pad dat op één gebruikersnaam eindigt, gekopieerd uit een voorbeeld voor één gebruiker. Dat is een demonstratie van één identiteit, geen opzoeking per gebruiker, en het voor elk verzoek gebruiken geeft niemand een onafhankelijk geregistreerde authenticator-app. Schrijf de identiteitstoewijzing op, bescherm de seedbestanden en houd de wachtwoord-, certificaat- en accountcontroles in dezelfde authenticatiestack.

Lees de PAM-stack om te zien wat er werkelijk vereist is

Een regel als account required pam_permit.so implementeert geen accountgeschiktheid en voegt geen factor toe. Hij staat die PAM-accountbeheerfase toe, wat een uitspraak over een fase is en niet over je gebruikers.

Hetzelfde geldt voor soepele registratieopties. Gebruikers zonder geregistreerde seed accepteren kan een bewuste uitrolkeuze zijn, maar het is geen bewijs dat MFA verplicht is, en het zou moeten worden vastgelegd als een tijdelijke uitzondering met een einddatum.

Stem de interactie van de client af op het ontwerp van de server

auth-user-pass

Die richtlijn vraagt om invoer van gebruikersnaam en wachtwoord. Hij configureert geen PAM, maakt geen registratierecord aan en vertelt de server niet dat het wachtwoordveld een TOTP-waarde bevat. De serverintegratie en de client moeten het eens worden over een interactie die de uitrol echt ondersteunt: een uitdaging, een gedocumenteerd gecombineerd inloggegevensformaat of een productspecifieke flow.

Voeg geen code aan het wachtwoord toe alleen omdat de client één veld toont. Dat werkt alleen waar de plugin van de server precies dat formaat verwacht, en het mislukt overal elders verwarrend.

Houd seeds en QR-materiaal buiten gedeelde profielen en routinematige diagnostische logs. Een code die via het geauthenticeerde loginkanaal wordt ingediend is niet hetzelfde object als de seed die tijdens gecontroleerde registratie is verstrekt, en ze in een supportticket door elkaar halen is de manier waarop geheimen ontsnappen.

Herverbindingen, tokens en de test die de knoop doorhakt

Plan wat er gebeurt na de eerste geslaagde login. Een eerder geaccepteerde code kan verlopen zijn of bij de volgende authenticatie als herhaling worden geweigerd. auth-nocache beheert het bewaren van inloggegevens en installeert geen MFA, en reneg-sec 0 is geen definitie van TOTP-ondersteuning, hoe vaak het ook in forumposts opduikt.

Sommige uitrollen geven na de eerste controle authenticatietokens uit, zodat herverbindingen niet opnieuw vragen. Dat is een ontwerpbeslissing met een eigen geldigheidsvenster en intrekkingsverhaal, geen standaard die je erft.

Test daarna het toelatingsbeleid met de client die mensen echt gebruiken. Een geregistreerde gebruiker met het juiste wachtwoord, certificaat en de huidige code zou moeten kunnen verbinden. Een verkeerde code, een gebruiker zonder registratie en een verboden account zouden elk moeten mislukken, en de reden zou zichtbaar moeten zijn in de serverlog. Tot je die afwijzingen hebt gezien, heb je een prompt, geen beleid.