Miks .ovpn-faili muutmine ei saa serveris MFA-d sisse lülitada

Lisate profiilile auth-user-pass, ühendate uuesti ja klient küsib kasutajanime ja parooli. Tundub, et MFA on sees. Seejärel sisestate koodi valelt kontolt või koodi, mis aegus kümme minutit tagasi, ja tunnel tõuseb ikkagi. See ongi sümptom: klient muutus, server mitte. Ühekordne parool on faktor alles siis, kui serveri kontrollija otsustab, kas see kehtib identiteedi jaoks, mis seda nõuab.

Küsimus tõestab ainult seda, et klient küsis, mitte rohkemat

.ovpn fail on kliendipoolne dokument. See võib käskida kliendil volitusi küsida, neid vahemällu salvestada või seda lõpetada. See ei saa kasutajat registreerida, PAM-moodulit paigaldada ega panna serverit nõudma teist faktorit, mida see praegu ei kontrolli.

Ka autentimisrakenduse paigaldamine telefoni ei loo seda seost. Google Authenticator PAM projekt on OTP-kontrolli komponent, mis võib seista OpenVPN-i taga; see ei ole viis Google’i konto sisselogimise kleepimiseks imporditud profiili külge.

Registreerimine on see osa, mida profiil teha ei saa

TOTP vajab registreerimismaterjali, mida jagavad autentimisrakendus ja selle kontrollija. Telefoni kuus numbrit on väljund; nende taga olev seeme on saladus ja kuulub ühele identiteedile.

Seega vajab operaator registreerimisprotsessi, mis seob õige seemne õige VPN-identiteediga, pluss kontrollitud asendustee kadunud telefoni jaoks. Kui lasta kasutajatel üles laadida enda nimega fail, muutub registreerimine konto ülevõtmise võimaluseks, ja üleslaadimise krüpteerimine ei muuda seda.

PAM-il põhinev lahendus ei pea looma iga VPN-kasutaja jaoks eraldi Unixi kontot. Mooduli dokumentatsioon toetab alternatiivseid saladuste teid ja failidele juurdepääsuks eraldi kontot, mis on failisüsteemi identiteet, mitte kontrollitav sisselogimisidentiteet.

Levinud viga on fikseeritud saladustee, mis lõpeb ühe kasutajanimega, kopeeritud ühe kasutaja näitest. See on ühe identiteedi demonstratsioon, mitte kasutajapõhine otsing, ja selle kasutamine iga päringu jaoks ei anna kellelegi iseseisvalt registreeritud autentimisrakendust. Kirjutage identiteedivastendus üles, kaitske seemnefaile ja hoidke parooli-, sertifikaadi- ja kontokontrollid samas autentimispinus.

Lugege PAM-pinu, et näha, mida tegelikult nõutakse

Rida nagu account required pam_permit.so ei rakenda konto õiguspärasust ega lisa faktorit. See lubab seda PAM-i kontohalduse etappi, mis on väide etapi, mitte teie kasutajate kohta.

Sama kehtib lubavate registreerimisvalikute kohta. Registreerimata saladusega kasutajate vastuvõtmine võib olla teadlik kasutuselevõtu otsus, kuid see ei tõesta, et MFA on kohustuslik, ja see tuleks kirja panna ajutise erandina koos lõppkuupäevaga.

Sobitage kliendi suhtlus serveri disainiga

auth-user-pass

See direktiiv küsib kasutajanime ja parooli sisestamist. See ei seadista PAM-i, ei loo registreerimiskirjet ega ütle serverile, et parooliväli sisaldab TOTP-väärtust. Serveri integratsioon ja klient peavad kokku leppima suhtluses, mida juurutus tegelikult toetab: väljakutse, dokumenteeritud kombineeritud volituste vorming või tootespetsiifiline voog.

Ärge lisage paroolile koodi ainult seetõttu, et klient näitab ühte välja. See töötab ainult seal, kus serveri plugin ootab täpselt seda vormingut, ja ebaõnnestub kõikjal mujal segadust tekitavalt.

Hoidke seemned ja QR-materjal jagatud profiilidest ja rutiinsetest diagnostikalogidest eemal. Autenditud sisselogimiskanali kaudu esitatud kood ei ole sama objekt kui kontrollitud registreerimise käigus väljastatud seeme, ja nende segamine tugipiletis on viis, kuidas saladused välja pääsevad.

Taasühendused, tokenid ja test, mis asja selgitab

Planeerige, mis juhtub pärast esimest edukat sisselogimist. Varem vastu võetud kood võib järgmisel autentimisel olla aegunud või kordusena tagasi lükatud. auth-nocache kontrollib volituste säilitamist ega paigalda MFA-d, ja reneg-sec 0 ei ole TOTP-toe määratlus, ükskõik kui sageli see foorumilõimedes esineb.

Mõned juurutused väljastavad pärast esmast kontrolli autentimistokenid, et taasühendused ei küsiks uuesti. See on disainiotsus oma kehtivusakna ja tühistamislooga, mitte vaikeväärtus, mille te pärite.

Seejärel testige vastuvõtupoliitikat kliendiga, mida inimesed tegelikult kasutavad. Registreeritud kasutaja õige parooli, sertifikaadi ja kehtiva koodiga peaks ühenduma. Vale kood, registreerimata kasutaja ja keelatud konto peaksid igaüks ebaõnnestuma ning põhjus peaks olema serveri logis nähtav. Kuni te neid tagasilükkamisi näinud ei ole, on teil küsimus, mitte poliitika.