Zakaj urejanje datoteke .ovpn ne more vklopiti MFA na strežniku

Dodate auth-user-pass v profil, se znova povežete in odjemalec zahteva uporabniško ime in geslo. Videti je, da je MFA vklopljen. Nato vnesete kodo iz napačnega računa ali kodo, ki je potekla pred desetimi minutami, in tunel se vseeno dvigne. To je simptom: odjemalec se je spremenil, strežnik ne. Enkratno geslo je dejavnik le takrat, ko se preverjevalec na strežniku odloči, ali je veljavno za identiteto, ki ga zahteva.

Zahteva dokazuje le, da je odjemalec vprašal, nič več

Datoteka .ovpn je dokument na strani odjemalca. Odjemalcu lahko naroči, naj zahteva poverilnice, jih shrani v predpomnilnik ali tega ne počne več. Ne more registrirati uporabnika, namestiti modula PAM ali doseči, da strežnik zahteva drugi dejavnik, ki ga zdaj ne preverja.

Tudi namestitev aplikacije za preverjanje pristnosti na telefon te povezave ne ustvari. Projekt Google Authenticator PAM je komponenta za preverjanje OTP, ki lahko stoji za OpenVPN; to ni način, kako prijavo v račun Google prilepiti na uvožen profil.

Registracija je tisti del, ki ga profil ne zmore

TOTP potrebuje registracijsko gradivo, ki si ga delita aplikacija za preverjanje pristnosti in njen preverjevalec. Šest števk na telefonu je izhod; seme za njimi je skrivnost in pripada eni identiteti.

Zato operater potrebuje postopek registracije, ki veže pravo seme na pravo identiteto VPN, poleg tega pa preverjeno pot zamenjave za izgubljeni telefon. Če uporabnikom dovolite nalaganje datoteke z njihovim imenom, se registracija spremeni v priložnost za prevzem računa, in šifriranje nalaganja tega ne spremeni.

Zasnova, ki temelji na PAM, ne potrebuje ločenega računa Unix za vsakega uporabnika VPN. Dokumentacija modula podpira alternativne poti do skrivnosti in namenski račun za dostop do datotek, kar je identiteta datotečnega sistema, ne pa identiteta prijave, ki se preverja.

Pogosta napaka je fiksna pot do skrivnosti, ki se konča z enim uporabniškim imenom, kopirana iz primera za enega uporabnika. To je predstavitev ene identitete, ne iskanje po uporabniku, in uporaba za vsako zahtevo nikomur ne da neodvisno registrirane aplikacije za preverjanje pristnosti. Zapišite preslikavo identitet, zaščitite datoteke s semeni in imejte preverjanja gesla, potrdila in računa v istem skladu za preverjanje pristnosti.

Preberite sklad PAM in poglejte, kaj se v resnici zahteva

Vrstica, kot je account required pam_permit.so, ne izvaja upravičenosti računa in ne doda dejavnika. Dovoli tisto stopnjo upravljanja računov PAM, kar je trditev o stopnji, ne o vaših uporabnikih.

Enako velja za popustljive možnosti registracije. Sprejemanje uporabnikov brez registrirane skrivnosti je lahko zavestna odločitev pri uvajanju, vendar ni dokaz, da je MFA obvezen, in to bi morali zapisati kot začasno izjemo z datumom konca.

Uskladite interakcijo odjemalca z zasnovo strežnika

auth-user-pass

Ta direktiva zahteva vnos uporabniškega imena in gesla. Ne konfigurira PAM, ne ustvari registracijskega zapisa in strežniku ne pove, da polje za geslo vsebuje vrednost TOTP. Integracija strežnika in odjemalec se morata dogovoriti o interakciji, ki jo uvajanje resnično podpira: izziv, dokumentirana kombinirana oblika poverilnic ali potek, specifičen za izdelek.

Ne dodajajte kode k geslu samo zato, ker odjemalec prikazuje eno polje. To deluje le tam, kjer vtičnik strežnika pričakuje natanko to obliko, in drugje zmedeno spodleti.

Semena in gradivo QR hranite zunaj skupnih profilov in rutinskih diagnostičnih dnevnikov. Koda, poslana po overjenem prijavnem kanalu, ni isti objekt kot seme, izdano med nadzorovano registracijo, in njuno mešanje v zahtevku za podporo je pot, po kateri skrivnosti uhajajo.

Ponovne povezave, žetoni in preizkus, ki razreši zadevo

Načrtujte, kaj se zgodi po prvi uspešni prijavi. Prej sprejeta koda lahko pri naslednjem preverjanju pristnosti poteče ali je zavrnjena kot ponovitev. auth-nocache nadzira shranjevanje poverilnic in ne namesti MFA, reneg-sec 0 pa ni opredelitev podpore TOTP, ne glede na to, kako pogosto se pojavi v forumskih nitih.

Nekatere uvedbe po prvem preverjanju izdajo žetone za preverjanje pristnosti, da se ponovne povezave ne sprašujejo znova. To je oblikovalska odločitev z lastnim oknom veljavnosti in lastno zgodbo o preklicu, ne privzeta vrednost, ki jo podedujete.

Nato preizkusite politiko sprejema z odjemalcem, ki ga ljudje resnično uporabljajo. Registriran uporabnik s pravilnim geslom, potrdilom in trenutno kodo bi se moral povezati. Napačna koda, uporabnik brez registracije in prepovedan račun bi morali vsak zase spodleteti, razlog pa bi moral biti viden v dnevniku strežnika. Dokler ne vidite teh zavrnitev, imate zahtevo, ne politike.