Af hverju að breyta .ovpn skrá getur ekki kveikt á MFA á netþjóninum

Þú bætir auth-user-pass við sniðmát, tengist aftur, og biðlarinn biður um notandanafn og lykilorð. Það lítur út fyrir að MFA sé kveikt. Síðan slærðu inn kóða af röngum reikningi, eða kóða sem rann út fyrir tíu mínútum, og göngin koma samt upp. Það er einkennið: biðlarinn breyttist, netþjónninn ekki. Einskiptislykilorð er aðeins þáttur þegar sannprófandi á netþjóninum ákveður hvort það gildi fyrir auðkennið sem krefst þess.

Beiðnin sannar aðeins að biðlarinn bað um, ekkert meira

.ovpn skrá er skjal á biðlarahlið. Hún getur sagt biðlaranum að biðja um skilríki, setja þau í skyndiminni eða hætta því. Hún getur ekki skráð notanda, sett upp PAM einingu eða látið netþjóninn krefjast annars þáttar sem hann athugar ekki núna.

Að setja auðkenningarforrit í síma skapar ekki þetta samband heldur. Google Authenticator PAM verkefnið er OTP staðfestingarhluti sem getur staðið á bak við OpenVPN; það er ekki leið til að líma Google reikningsinnskráningu á innflutt sniðmát.

Skráning er sá hluti sem sniðmát getur ekki gert

TOTP þarf skráningarefni sem er deilt milli auðkenningarforritsins og sannprófandans. Sex tölustafirnir í símanum eru úttak; fræið á bak við þá er leyndarmálið, og það tilheyrir einu auðkenni.

Því þarf rekstraraðilinn skráningarferli sem bindur rétta fræið við rétta VPN auðkennið, auk staðfestrar skiptileiðar fyrir týndan síma. Að leyfa notendum að hlaða upp skrá sem heitir eftir þeim gerir skráningu að tækifæri til að yfirtaka reikning, og dulkóðun upphleðslunnar breytir því ekki.

PAM byggt hönnun þarf ekki að búa til sérstakan Unix reikning fyrir hvern VPN notanda. Skjöl einingarinnar styðja aðra leyndarmálsslóð og sérstakan reikning fyrir skráaraðgang, sem er auðkenni skráakerfisins en ekki innskráningarauðkennið sem er staðfest.

Algenga mistökin eru föst leyndarmálsslóð sem endar á einu notandanafni, afrituð af einnotenda dæmi. Það er sýning á einu auðkenni, ekki uppfletting á hvern notanda, og að nota hana fyrir hverja beiðni gefur engum sjálfstætt skráð auðkenningarforrit. Skrifaðu auðkennakortlagninguna niður, verndaðu fræskrárnar og haltu lykilorðs-, skírteinis- og reikningsathugunum í sama auðkenningarstakknum.

Lestu PAM stakkinn til að sjá hvað er raunverulega krafist

Lína eins og account required pam_permit.so útfærir ekki reikningshæfi og bætir ekki við þætti. Hún leyfir það PAM reikningsstjórnunarstig, sem er fullyrðing um stig en ekki um notendurna þína.

Sama gildir um umburðarlyndar skráningarmöguleika. Að samþykkja notendur án skráðs leyndarmáls getur verið viljandi uppsetningarákvörðun, en það er ekki sönnun þess að MFA sé skylt, og ætti að skrá það sem tímabundna undantekningu með lokadagsetningu.

Lagaðu samskipti biðlarans að hönnun netþjónsins

auth-user-pass

Þessi tilskipun biður um innslátt notandanafns og lykilorðs. Hún stillir ekki PAM, býr ekki til skráningarfærslu og segir netþjóninum ekki að lykilorðsreiturinn innihaldi TOTP gildi. Samþætting netþjónsins og biðlarinn verða að sammælast um samskipti sem uppsetningin styður í raun: áskorun, skjalfest sameinað skilríkjasnið eða ferli sem er sérstakt fyrir vöruna.

Bættu ekki kóða við lykilorðið bara af því að biðlarinn sýnir einn reit. Það virkar aðeins þar sem viðbót netþjónsins býst við nákvæmlega því sniði, og mistekst ruglingslega alls staðar annars staðar.

Haltu fræjum og QR efni utan sameiginlegra sniðmáta og venjubundinna greiningarskráa. Kóði sem er sendur um auðkennda innskráningarrásina er ekki sami hluturinn og fræið sem var afhent við stýrða skráningu, og að blanda þeim í stuðningsmiða er leiðin sem leyndarmál sleppa út.

Endurtengingar, tóken og prófið sem ræður úrslitum

Skipuleggðu hvað gerist eftir fyrstu vel heppnuðu innskráninguna. Kóði sem var samþykktur áður getur verið útrunninn eða hafnað sem endurtekning við næstu auðkenningu. auth-nocache stjórnar varðveislu skilríkja og setur ekki upp MFA, og reneg-sec 0 er ekki skilgreining á TOTP stuðningi, hversu oft sem það birtist í þráðum á spjallborðum.

Sumar uppsetningar gefa út auðkenningartóken eftir fyrstu athugun svo endurtengingar spyrji ekki aftur. Það er hönnunarákvörðun með eigin gildistíma og afturköllunarsögu, ekki sjálfgefið gildi sem þú erfir.

Prófaðu síðan aðgangstefnuna með þeim biðlara sem fólk notar í raun. Skráður notandi með rétta lykilorðið, skírteinið og núverandi kóða ætti að tengjast. Rangur kóði, notandi án skráningar og bannaður reikningur ættu hver um sig að mistakast, og ástæðan ætti að vera sýnileg í skrá netþjónsins. Þangað til þú hefur séð þessar synjanir hefurðu beiðni, ekki stefnu.