Pse redaktimi i një skedari .ovpn nuk mund të aktivizojë MFA në server

Shtoni auth-user-pass në një profil, rilidheni dhe klienti kërkon një emër përdoruesi dhe një fjalëkalim. Duket sikur MFA është aktiv. Më pas shkruani një kod nga llogaria e gabuar, ose një kod që skadoi dhjetë minuta më parë, dhe tuneli ngrihet gjithsesi. Ky është simptomi: klienti ndryshoi, serveri jo. Një fjalëkalim njëpërdorimësh është faktor vetëm kur një verifikues në server vendos nëse është i vlefshëm për identitetin që e kërkon.

Kërkesa provon vetëm se klienti pyeti, asgjë më shumë

Një skedar .ovpn është një dokument në anën e klientit. Ai mund t'i thotë klientit të kërkojë kredenciale, t'i ruajë ato në cache ose të ndalojë së bëri këtë. Nuk mund të regjistrojë një përdorues, të instalojë një modul PAM ose ta detyrojë serverin të kërkojë një faktor të dytë që nuk e kontrollon tani.

As instalimi i një aplikacioni vërtetimi në telefon nuk e krijon atë lidhje. Projekti Google Authenticator PAM është një komponent verifikimi OTP që mund të qëndrojë pas OpenVPN; nuk është një mënyrë për të ngjitur hyrjen në llogarinë Google në një profil të importuar.

Regjistrimi është pjesa që një profil nuk mund ta bëjë

TOTP ka nevojë për material regjistrimi të përbashkët midis aplikacionit të vërtetimit dhe verifikuesit të tij. Gjashtë shifrat në telefon janë dalja; fara pas tyre është sekreti, dhe i përket një identiteti të vetëm.

Prandaj operatori ka nevojë për një proces regjistrimi që lidh farën e duhur me identitetin e duhur VPN, plus një rrugë zëvendësimi të verifikuar për një telefon të humbur. Të lejosh përdoruesit të ngarkojnë një skedar të emërtuar sipas tyre e kthen regjistrimin në një mundësi për marrjen e llogarisë, dhe kriptimi i ngarkimit nuk e ndryshon këtë.

Një dizajn i bazuar në PAM nuk duhet të krijojë një llogari të veçantë Unix për çdo përdorues VPN. Dokumentacioni i modulit mbështet rrugë alternative për sekretet dhe një llogari të dedikuar për aksesin në skedarë, që është një identitet i sistemit të skedarëve dhe jo identiteti i hyrjes që verifikohet.

Gabimi i zakonshëm është një rrugë fikse sekreti që përfundon me një emër përdoruesi, e kopjuar nga një shembull për një përdorues të vetëm. Ky është një demonstrim i një identiteti, jo një kërkim për çdo përdorues, dhe përdorimi i tij për çdo kërkesë nuk i jep askujt një aplikacion vërtetimi të regjistruar në mënyrë të pavarur. Shkruani hartëzimin e identiteteve, mbroni skedarët e farës dhe mbani kontrollet e fjalëkalimit, certifikatës dhe llogarisë në të njëjtin stivë vërtetimi.

Lexoni stivën PAM për të parë çfarë kërkohet në të vërtetë

Një rresht si account required pam_permit.so nuk zbaton përshtatshmërinë e llogarisë dhe nuk shton një faktor. Ai lejon atë fazë të menaxhimit të llogarive PAM, që është një deklaratë për një fazë dhe jo për përdoruesit tuaj.

E njëjta gjë vlen edhe për opsionet lejuese të regjistrimit. Pranimi i përdoruesve pa një sekret të regjistruar mund të jetë një zgjedhje e qëllimshme e vendosjes, por nuk është provë që MFA është e detyrueshme, dhe duhet të shënohet si një përjashtim i përkohshëm me datë përfundimi.

Përputhni ndërveprimin e klientit me dizajnin e serverit

auth-user-pass

Ai direktivë kërkon futjen e emrit të përdoruesit dhe fjalëkalimit. Ai nuk konfiguron PAM, nuk krijon një regjistrim regjistrimi dhe nuk i thotë serverit që fusha e fjalëkalimit përmban një vlerë TOTP. Integrimi i serverit dhe klienti duhet të bien dakord për një ndërveprim që vendosja me të vërtetë mbështet: një sfidë, një format i dokumentuar i kredencialeve të kombinuara, ose një rrjedhë specifike për produktin.

Mos shtoni një kod në fjalëkalim vetëm sepse klienti shfaq një fushë. Kjo funksionon vetëm aty ku shtojca e serverit pret saktësisht atë format, dhe dështon në mënyrë konfuze kudo tjetër.

Mbani farat dhe materialin QR larg profileve të përbashkëta dhe regjistrave rutinë të diagnostikimit. Një kod i dorëzuar përmes kanalit të hyrjes së vërtetuar nuk është i njëjti objekt si fara e dhënë gjatë një regjistrimi të kontrolluar, dhe përzierja e tyre në një biletë mbështetjeje është mënyra se si arratisen sekretet.

Rilidhjet, tokenët dhe testi që e zgjidh çështjen

Planifikoni çfarë ndodh pas hyrjes së parë të suksesshme. Një kod i pranuar më parë mund të ketë skaduar ose të refuzohet si përsëritje në vërtetimin tjetër. auth-nocache kontrollon mbajtjen e kredencialeve dhe nuk instalon MFA, dhe reneg-sec 0 nuk është një përkufizim i mbështetjes së TOTP, sado shpesh të shfaqet në temat e forumit.

Disa vendosje lëshojnë tokenë vërtetimi pas kontrollit fillestar, në mënyrë që rilidhjet të mos pyesin përsëri. Ky është një vendim dizajni me dritaren e tij të vlefshmërisë dhe historinë e revokimit, jo një vlerë e paracaktuar që trashëgoni.

Më pas provoni politikën e pranimit me klientin që njerëzit përdorin vërtet. Një përdorues i regjistruar me fjalëkalimin, certifikatën dhe kodin aktual të saktë duhet të lidhet. Një kod i gabuar, një përdorues pa regjistrim dhe një llogari e ndaluar duhet të dështojnë secili, dhe arsyeja duhet të jetë e dukshme në regjistrin e serverit. Derisa t'i keni parë ato refuzime, keni një kërkesë, jo një politikë.