Hvorfor redigering af en .ovpn-fil ikke kan slå MFA til på serveren

Du tilføjer auth-user-pass til en profil, genopretter forbindelsen, og klienten beder om et brugernavn og en adgangskode. Det ser ud som om MFA er slået til. Så indtaster du en kode fra den forkerte konto, eller en kode der udløb for ti minutter siden, og tunnelen kommer stadig op. Det er symptomet: klienten ændrede sig, serveren gjorde ikke. En engangskode er kun en faktor, når en verifikator på serveren afgør, om den er gyldig for den identitet, der gør krav på den.

Prompten beviser kun, at klienten spurgte, ikke mere

En .ovpn-fil er et dokument på klientsiden. Den kan fortælle klienten at bede om legitimationsoplysninger, cache dem eller holde op med at cache dem. Den kan ikke registrere en bruger, installere et PAM-modul eller få serveren til at kræve en anden faktor, som den ikke kontrollerer i dag.

Det skaber heller ikke forholdet at installere en godkendelsesapp på en telefon. Google Authenticator PAM-projektet er en OTP-verifikationskomponent, der kan sidde bag OpenVPN; det er ikke en måde at klistre Google-kontologin på en importeret profil.

Registrering er den del, en profil ikke kan klare

TOTP kræver registreringsmateriale, der deles mellem godkendelsesappen og dens verifikator. De seks cifre på telefonen er output; frøet bag dem er hemmeligheden, og det tilhører én identitet.

Operatøren har derfor brug for en registreringsproces, der binder det rigtige frø til den rigtige VPN-identitet, plus en verificeret erstatningsvej for en mistet telefon. Når brugere selv må uploade en fil opkaldt efter sig, bliver registrering en mulighed for kontoovertagelse, og kryptering af uploadet ændrer ikke det.

Et PAM-baseret design behøver ikke oprette en separat Unix-konto pr. VPN-bruger. Moduldokumentationen understøtter alternative hemmelige stier og en dedikeret konto til filadgang, hvilket er en filsystemidentitet snarere end den loginidentitet, der verificeres.

Den almindelige fejl er en fast hemmelig sti, der ender med ét brugernavn, kopieret fra et eksempel med én bruger. Det er en demonstration af én identitet, ikke et opslag pr. bruger, og at bruge den til hver anmodning giver ingen en uafhængigt registreret godkendelsesapp. Skriv identitetsmappingen ned, beskyt frøfilerne, og hold adgangskode-, certifikat- og kontokontrollen i samme godkendelsesstak.

Læs PAM-stakken for at se, hvad der faktisk kræves

En linje som account required pam_permit.so implementerer ikke kontoberettigelse og tilføjer ikke en faktor. Den tillader det PAM-kontoadministrationstrin, hvilket er en udtalelse om et trin og ikke om dine brugere.

Det samme gælder lempelige registreringsindstillinger. At acceptere brugere uden et registreret frø kan være et bevidst udrulningsvalg, men det er ikke bevis på, at MFA er obligatorisk, og det bør skrives ned som en midlertidig undtagelse med en slutdato.

Tilpas klientens interaktion til serverens design

auth-user-pass

Den direktiv anmoder om brugernavn og adgangskode. Den konfigurerer ikke PAM, opretter ikke en registreringspost og fortæller ikke serveren, at adgangskodefeltet indeholder en TOTP-værdi. Serverintegrationen og klienten skal blive enige om en interaktion, som udrulningen faktisk understøtter: en udfordring, et dokumenteret kombineret legitimationsformat eller et produktspecifikt flow.

Føj ikke en kode til adgangskoden, bare fordi klienten viser ét felt. Det virker kun der, hvor serverens plugin forventer præcis det format, og det fejler forvirrende alle andre steder.

Hold frø og QR-materiale ude af delte profiler og rutinemæssige diagnostiske logfiler. En kode indsendt over den godkendte login-kanal er ikke det samme objekt som det frø, der blev udleveret under kontrolleret registrering, og at blande dem i en supportbillet er, hvordan hemmeligheder slipper ud.

Genoprettede forbindelser, tokens og den test, der afgør sagen

Planlæg, hvad der sker efter det første vellykkede login. En tidligere accepteret kode kan være udløbet eller afvist som en gentagelse ved næste godkendelse. auth-nocache styrer opbevaring af legitimationsoplysninger og installerer ikke MFA, og reneg-sec 0 er ikke en definition på TOTP-understøttelse, uanset hvor ofte den optræder i forumtråde.

Nogle udrulninger udsteder godkendelsestokens efter den første kontrol, så genoprettede forbindelser ikke spørger igen. Det er en designbeslutning med sit eget gyldighedsvindue og sin egen tilbagekaldelseshistorie, ikke en standard, du arver.

Test derefter adgangspolitikken med den klient, folk faktisk bruger. En registreret bruger med den rigtige adgangskode, certifikat og aktuelle kode bør kunne forbinde. En forkert kode, en bruger uden registrering og en forbudt konto bør hver især fejle, og årsagen bør være synlig i serverloggen. Indtil du har set de afvisninger, har du en prompt, ikke en politik.