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

Dodate auth-user-pass u profil, ponovno se povežete i klijent traži korisničko ime i zaporku. 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, poslužitelj nije. Jednokratna zaporka je čimbenik samo kada provjeravatelj na poslužitelju odluči je li valjana za identitet koji je traži.

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

Datoteka .ovpn dokument je na strani klijenta. Može reći klijentu da zatraži vjerodajnice, da ih predmemorira ili da to prestane činiti. Ne može registrirati korisnika, instalirati PAM modul niti natjerati poslužitelj da zahtijeva drugi čimbenik koji trenutačno ne provjerava.

Ni instalacija aplikacije za autentifikaciju na telefon ne stvara taj odnos. Projekt Google Authenticator PAM komponenta je za provjeru OTP-a koja može stajati iza OpenVPN; to nije način da prijavu u Google račun prikvačite na uvezeni profil.

Registracija je dio koji profil ne može obaviti

TOTP treba registracijski materijal koji dijele aplikacija za autentifikaciju i njezin provjeravatelj. Šest znamenki na telefonu izlaz je; sjeme iza njih tajna je i pripada jednom identitetu.

Zato operateru treba proces registracije koji veže 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 učitanog to ne mijenja.

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

Uobičajena pogreš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 neovisno registriranu aplikaciju za autentifikaciju. Zapišite mapiranje identiteta, zaštitite datoteke sa sjemenom i držite provjere zaporke, certifikata i računa u istom autentifikacijskom stogu.

Pročitajte PAM stog da vidite što se doista zahtijeva

Redak poput account required pam_permit.so ne provodi podobnost računa i ne dodaje čimbenik. Dopušta taj stupanj upravljanja računima u PAM-u, što je izjava o stupnju, a ne o vašim korisnicima.

Isto vrijedi i za popustljive mogućnosti registracije. Prihvaćanje korisnika bez registrirane tajne može biti svjesna odluka o uvođenju, ali nije dokaz da je MFA obavezan i to treba zapisati kao privremenu iznimku s datumom završetka.

Uskladite interakciju klijenta s dizajnom poslužitelja

auth-user-pass

Ta direktiva traži unos korisničkog imena i zaporke. Ne konfigurira PAM, ne stvara zapis o registraciji i ne govori poslužitelju da polje zaporke sadrži TOTP vrijednost. Integracija poslužitelja i klijent moraju se dogovoriti o interakciji koju implementacija doista podržava: izazov, dokumentiran kombinirani format vjerodajnica ili tijek specifičan za proizvod.

Ne dodajte kod zaporki samo zato što klijent prikazuje jedno polje. To radi samo tamo gdje dodatak poslužitelja očekuje točno taj format, a svugdje drugdje pada zbunjujuće.

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

Ponovna povezivanja, tokeni i test koji sve rješava

Planirajte što se događa nakon prve uspješne prijave. Ranije prihvaćen kod može biti istekao ili odbijen kao ponavljanje pri sljedećoj autentifikaciji. auth-nocache kontrolira zadržavanje vjerodajnica 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 ponovno pitala. To je dizajnerska odluka s vlastitim rokom valjanosti i pričom o opozivu, a ne zadano stanje koje nasljeđujete.

Zatim testirajte politiku prijema s klijentom koji ljudi doista koriste. Registrirani korisnik s pravom zaporkom, certifikatom i aktualnim kodom trebao bi se povezati. Pogrešan kod, korisnik bez registracije i zabranjeni račun trebali bi svaki pasti, a razlog bi trebao biti vidljiv u zapisu poslužitelja. Dok ne vidite ta odbijanja, imate upit, a ne politiku.