Kial redakti .ovpn-dosieron ne povas ŝalti MFA ĉe la servilo

Vi aldonas auth-user-pass al profilo, rekonektiĝas, kaj la kliento petas uzantnomon kaj pasvorton. Ŝajnas, ke MFA estas ŝaltita. Poste vi entajpas kodon de la malĝusta konto, aŭ kodon, kiu eksvalidiĝis antaŭ dek minutoj, kaj la tunelo tamen leviĝas. Tio estas la simptomo: la kliento ŝanĝiĝis, la servilo ne. Unufoja pasvorto estas faktoro nur tiam, kiam kontrolanto ĉe la servilo decidas, ĉu ĝi validas por la identeco, kiu ĝin postulas.

La peto pruvas nur, ke la kliento demandis, nenion pli

Dosiero .ovpn estas dokumento ĉe la klienta flanko. Ĝi povas diri al la kliento peti akreditaĵojn, kaŝmemorigi ilin aŭ ĉesi kaŝmemorigi ilin. Ĝi ne povas registri uzanton, instali PAM-modulon aŭ igi la servilon postuli duan faktoron, kiun ĝi nun ne kontrolas.

Ankaŭ instalado de aŭtentiga aplikaĵo en telefono ne kreas tiun rilaton. La projekto Google Authenticator PAM estas OTP-kontrola komponanto, kiu povas stari malantaŭ OpenVPN; ĝi ne estas maniero alkroĉi Google-kontan ensaluton al importita profilo.

Registrado estas la parto, kiun profilo ne povas fari

TOTP bezonas registran materialon komunan inter la aŭtentiga aplikaĵo kaj ĝia kontrolanto. La ses ciferoj sur la telefono estas eligo; la semo malantaŭ ili estas la sekreto, kaj ĝi apartenas al unu identeco.

Do la operatoro bezonas registran procezon, kiu ligas la ĝustan semon al la ĝusta VPN-identeco, plus kontrolita anstataŭa vojo por perdita telefono. Lasi uzantojn alŝuti dosieron nomitan laŭ ili mem igas registradon ŝanco por kontopreno, kaj ĉifrado de la alŝuto tion ne ŝanĝas.

PAM-bazita dizajno ne devas krei apartan Unix-konton por ĉiu VPN-uzanto. La dokumentaro de la modulo subtenas alternativajn vojojn por sekretoj kaj dediĉitan konton por dosiera aliro, kio estas dosiersistema identeco, ne la ensaluta identeco, kiu estas kontrolata.

La ofta eraro estas fiksa sekreta vojo finiĝanta per unu uzantnomo, kopiita el unuuzanta ekzemplo. Tio estas demonstro de unu identeco, ne serĉo laŭ uzanto, kaj uzi ĝin por ĉiu peto donas al neniu sendepende registritan aŭtentigan aplikaĵon. Skribu la identecmapadon, protektu la semodosierojn kaj tenu la kontrolojn de pasvorto, atestilo kaj konto en la sama aŭtentiga stako.

Legu la PAM-stakon por vidi, kio efektive estas postulata

Linio kiel account required pam_permit.so ne efektivigas kontan elekteblecon kaj ne aldonas faktoron. Ĝi permesas tiun PAM-kontoadministran stadion, kio estas aserto pri stadio, ne pri viaj uzantoj.

La samo validas por permesemaj registradaj opcioj. Akcepti uzantojn sen registrita sekreto povas esti konscia enkonduka decido, sed ĝi ne pruvas, ke MFA estas deviga, kaj ĝi devus esti skribita kiel portempa escepto kun findato.

Aguordigu la interagon de la kliento kun la dizajno de la servilo

auth-user-pass

Tiu direktivo petas enigon de uzantnomo kaj pasvorto. Ĝi ne agordas PAM, ne kreas registran rikordon kaj ne diras al la servilo, ke la pasvorta kampo enhavas TOTP-valoron. La servila integriĝo kaj la kliento devas interkonsenti pri interago, kiun la deplojo efektive subtenas: defio, dokumentita kombinita akreditaĵa formato aŭ produktspecifa fluo.

Ne aldonu kodon al la pasvorto nur ĉar la kliento montras unu kampon. Tio funkcias nur tie, kie la kromaĵo de la servilo atendas ĝuste tiun formaton, kaj ĝi malsukcesas konfuze ĉie alie.

Tenu semojn kaj QR-materialon ekster komunaj profiloj kaj rutinaj diagnostikaj protokoloj. Kodo sendita per la aŭtentigita ensaluta kanalo ne estas la sama objekto kiel la semo liverita dum kontrolita registrado, kaj miksi ilin en subtena bileto estas la maniero, kiel sekretoj elfuĝas.

Rekonektoj, ĵetonoj kaj la testo, kiu solvas la aferon

Planu, kio okazas post la unua sukcesa ensaluto. Antaŭe akceptita kodo povas esti eksvalidiĝinta aŭ malakceptita kiel ripeto ĉe la sekva aŭtentigo. auth-nocache regas la retenadon de akreditaĵoj kaj ne instalas MFA, kaj reneg-sec 0 ne estas difino de TOTP-subteno, kiom ajn ofte ĝi aperas en forumaj fadenoj.

Iuj deplojoj eldonas aŭtentigajn ĵetonojn post la komenca kontrolo, por ke rekonektoj ne demandu denove. Tio estas dizajna decido kun propra valideca fenestro kaj propra revoka historio, ne defaŭlto, kiun vi heredas.

Poste testu la akceptan politikon per la kliento, kiun homoj efektive uzas. Registrita uzanto kun la ĝusta pasvorto, atestilo kaj nuna kodo devus konektiĝi. Malĝusta kodo, uzanto sen registrado kaj malpermesita konto devus ĉiu malsukcesi, kaj la kialo devus esti videbla en la servila protokolo. Ĝis vi vidos tiujn rifuzojn, vi havas peton, ne politikon.