Zašto uređivanje .ovpn datoteke ne može uključiti MFA na serveru

Dodate auth-user-pass u profil, ponovo se povežete i klijent traži korisničko ime i lozinku. Izgleda kao da je MFA uključen. Zatim unesete kod s pogrešnog računa ili kod koji je istekao prije deset minuta, a tunel se ipak podiže. To je simptom: klijent se promijenio, server nije. Jednokratna lozinka je faktor samo kada verifikator na serveru odluči da li je važeća za identitet koji je traži.

Upit dokazuje samo da je klijent pitao, ništa više

Datoteka .ovpn je dokument na strani klijenta. Može reći klijentu da zatraži akreditive, da ih kešira ili da prestane da ih kešira. Ne može registrovati korisnika, instalirati PAM modul niti natjerati server da zahtijeva drugi faktor koji trenutno ne provjerava.

Instaliranje aplikacije za autentifikaciju na telefon takođe ne stvara tu vezu. Google Authenticator PAM projekat je komponenta za provjeru OTP-a koja može stajati iza OpenVPN; to nije način da prijavu na Google račun prikačite na uvezeni profil.

Registracija je dio koji profil ne može obaviti

TOTP zahtijeva registracioni materijal koji dijele aplikacija za autentifikaciju i njen verifikator. Šest cifara na telefonu je izlaz; sjeme iza njih je tajna i pripada jednom identitetu.

Zato operateru treba proces registracije koji vezuje pravo sjeme za pravi VPN identitet, plus provjereni put zamjene za izgubljeni telefon. Dopuštanje korisnicima da učitaju datoteku nazvanu po sebi pretvara registraciju u priliku za preuzimanje računa, a šifriranje uploada to ne mijenja.

Dizajn zasnovan na PAM-u ne mora stvarati poseban Unix račun za svakog VPN korisnika. Dokumentacija modula podržava alternativne putanje tajni i posvećen račun za pristup datotekama, što je identitet datotečnog sistema, a ne identitet prijave koji se provjerava.

Uobičajena greška je fiksna putanja tajne koja završava jednim korisničkim imenom, kopirana iz primjera za jednog korisnika. To je demonstracija jednog identiteta, a ne pretraga po korisniku, i korištenje za svaki zahtjev ne daje nikome nezavisno registrovanu aplikaciju za autentifikaciju. Zapišite mapiranje identiteta, zaštitite datoteke sjemena i držite provjere lozinke, certifikata i računa u istom autentifikacijskom steku.

Pročitajte PAM stek da vidite šta se zaista zahtijeva

Linija kao account required pam_permit.so ne implementira podobnost računa i ne dodaje faktor. Ona dopušta tu fazu upravljanja računima u PAM-u, što je izjava o fazi, a ne o vašim korisnicima.

Isto vrijedi i za popustljive opcije registracije. Prihvatanje korisnika bez registrovanog sjemena može biti svjesna odluka o uvođenju, ali to nije dokaz da je MFA obavezan i treba to zapisati kao privremeni izuzetak s datumom završetka.

Uskladite interakciju klijenta s dizajnom servera

auth-user-pass

Ta direktiva traži unos korisničkog imena i lozinke. Ona ne konfiguriše PAM, ne stvara registracioni zapis i ne govori serveru da polje lozinke sadrži TOTP vrijednost. Integracija servera i klijent moraju se dogovoriti o interakciji koju implementacija zaista podržava: izazov, dokumentovan kombinovani format akreditiva ili tok specifičan za proizvod.

Ne dodajte kod lozinci samo zato što klijent prikazuje jedno polje. To radi samo tamo gdje dodatak servera očekuje tačno taj format, a svuda drugdje pada zbunjujuće.

Držite sjeme i QR materijal izvan zajedničkih profila i rutinskih dijagnostičkih zapisa. Kod poslan autentifikovanim kanalom prijave nije isti objekt kao sjeme izdato tokom kontrolisane registracije, a miješanje njih u tiketu podrške je način na koji tajne izmiču.

Ponovna povezivanja, tokeni i test koji sve rješava

Planirajte šta se dešava nakon prve uspješne prijave. Ranije prihvaćen kod može biti istekao ili odbijen kao ponavljanje pri sljedećoj autentifikaciji. auth-nocache kontroliše zadržavanje akreditiva i ne instalira MFA, a reneg-sec 0 nije definicija TOTP podrške, koliko god se često pojavljivao u forumskim temama.

Neke implementacije izdaju autentifikacijske tokene nakon početne provjere kako ponovna povezivanja ne bi ponovo pitala. To je dizajnerska odluka s vlastitim rokom važenja i pričom o opozivu, a ne zadano stanje koje nasljeđujete.

Zatim testirajte politiku prijema s klijentom koji ljudi zaista koriste. Registrovani korisnik s pravom lozinkom, certifikatom i aktuelnim kodom treba da se poveže. Pogrešan kod, korisnik bez registracije i zabranjeni račun treba svaki da padne, a razlog treba da bude vidljiv u zapisu servera. Dok ne vidite ta odbijanja, imate upit, a ne politiku.