De ce editarea unui fișier .ovpn nu poate activa MFA pe server

Adaugi auth-user-pass la un profil, te reconectezi, iar clientul cere un nume de utilizator și o parolă. Pare că MFA este activat. Apoi introduci un cod din contul greșit, sau un cod care a expirat acum zece minute, iar tunelul se ridică totuși. Acesta este simptomul: clientul s-a schimbat, serverul nu. O parolă de unică folosință este un factor doar atunci când un verificator de pe server decide dacă este validă pentru identitatea care o revendică.

Solicitarea dovedește doar că clientul a întrebat, nimic mai mult

Un fișier .ovpn este un document de pe partea clientului. Poate spune clientului să ceară acreditări, să le păstreze în cache sau să nu mai facă asta. Nu poate înregistra un utilizator, instala un modul PAM sau determina serverul să ceară un al doilea factor pe care nu îl verifică acum.

Nici instalarea unei aplicații de autentificare pe un telefon nu creează acea relație. Proiectul Google Authenticator PAM este o componentă de verificare OTP care poate sta în spatele OpenVPN; nu este o modalitate de a lipi autentificarea în contul Google de un profil importat.

Înregistrarea este partea pe care un profil nu o poate face

TOTP are nevoie de material de înregistrare partajat între aplicația de autentificare și verificatorul ei. Cele șase cifre de pe telefon sunt rezultatul; sămânța din spatele lor este secretul și aparține unei singure identități.

Prin urmare, operatorul are nevoie de un proces de înregistrare care leagă sămânța corectă de identitatea VPN corectă, plus o cale de înlocuire verificată pentru un telefon pierdut. Dacă utilizatorii pot încărca un fișier numit după ei, înregistrarea devine o oportunitate de preluare a contului, iar criptarea încărcării nu schimbă asta.

Un design bazat pe PAM nu trebuie să creeze un cont Unix separat pentru fiecare utilizator VPN. Documentația modulului acceptă căi alternative pentru secrete și un cont dedicat pentru accesul la fișiere, adică o identitate a sistemului de fișiere, nu identitatea de autentificare care este verificată.

Greșeala obișnuită este o cale fixă către secret care se termină cu un singur nume de utilizator, copiată dintr-un exemplu pentru un singur utilizator. Aceea este o demonstrație pentru o singură identitate, nu o căutare pe utilizator, iar folosirea ei pentru fiecare solicitare nu oferă nimănui o aplicație de autentificare înregistrată independent. Notează maparea identităților, protejează fișierele cu semințe și ține verificările parolei, certificatului și contului în aceeași stivă de autentificare.

Citește stiva PAM pentru a vedea ce se cere de fapt

O linie precum account required pam_permit.so nu implementează eligibilitatea contului și nu adaugă un factor. Permite acea etapă de gestionare a conturilor PAM, ceea ce este o afirmație despre o etapă, nu despre utilizatorii tăi.

Același lucru este valabil pentru opțiunile permisive de înregistrare. Acceptarea utilizatorilor fără un secret înregistrat poate fi o decizie deliberată de implementare, dar nu este dovada că MFA este obligatoriu și ar trebui notată ca o excepție temporară cu dată de încheiere.

Aliniază interacțiunea clientului la designul serverului

auth-user-pass

Această directivă cere introducerea numelui de utilizator și a parolei. Nu configurează PAM, nu creează o înregistrare de înscriere și nu îi spune serverului că câmpul parolei conține o valoare TOTP. Integrarea pe server și clientul trebuie să convină asupra unei interacțiuni pe care implementarea o susține cu adevărat: o provocare, un format combinat de acreditări documentat sau un flux specific produsului.

Nu adăuga un cod la parolă doar pentru că clientul afișează un singur câmp. Asta funcționează doar acolo unde pluginul serverului așteaptă exact acel format și eșuează confuz în toate celelalte locuri.

Ține semințele și materialul QR departe de profilurile partajate și de jurnalele de diagnosticare obișnuite. Un cod trimis prin canalul de autentificare autentificat nu este același obiect ca sămânța furnizată în timpul unei înregistrări controlate, iar amestecarea lor într-un tichet de asistență este modul în care secretele scapă.

Reconectări, tokenuri și testul care lămurește problema

Planifică ce se întâmplă după prima autentificare reușită. Un cod acceptat anterior poate fi expirat sau respins ca reluare la următoarea autentificare. auth-nocache controlează păstrarea acreditărilor și nu instalează MFA, iar reneg-sec 0 nu este o definiție a suportului TOTP, oricât de des ar apărea în firele de forum.

Unele implementări emit tokenuri de autentificare după verificarea inițială, astfel încât reconectările să nu mai întrebe. Este o decizie de design cu propria fereastră de valabilitate și propria poveste de revocare, nu o valoare implicită pe care o moștenești.

Apoi testează politica de admitere cu clientul pe care oamenii îl folosesc cu adevărat. Un utilizator înregistrat cu parola, certificatul și codul curent corecte ar trebui să se conecteze. Un cod greșit, un utilizator fără înregistrare și un cont interzis ar trebui să eșueze fiecare, iar motivul ar trebui să fie vizibil în jurnalul serverului. Până nu ai văzut acele respingeri, ai o solicitare, nu o politică.