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

Du legger til auth-user-pass i en profil, kobler til på nytt, og klienten ber om et brukernavn og et passord. Det ser ut som om MFA er på. Så skriver du inn en kode fra feil konto, eller en kode som utløp for ti minutter siden, og tunnelen kommer likevel opp. Det er symptomet: klienten endret seg, serveren gjorde det ikke. Et engangspassord er bare en faktor når en verifiserer på serveren avgjør om det er gyldig for identiteten som krever det.

Ledeteksten beviser bare at klienten spurte, ikke mer

En .ovpn-fil er et dokument på klientsiden. Den kan fortelle klienten å be om påloggingsinformasjon, bufre den eller slutte å bufre den. Den kan ikke registrere en bruker, installere en PAM-modul eller få serveren til å kreve en annen faktor som den ikke sjekker i dag.

Det skaper heller ikke forholdet å installere en autentiseringsapp på en telefon. Google Authenticator PAM-prosjektet er en OTP-verifiseringskomponent som kan sitte bak OpenVPN; det er ikke en måte å lime Google-kontopålogging på en importert profil.

Registrering er den delen en profil ikke klarer

TOTP trenger registreringsmateriale som deles mellom autentiseringsappen og verifisereren. De seks sifrene på telefonen er utdata; frøet bak dem er hemmeligheten, og det tilhører én identitet.

Derfor trenger operatøren en registreringsprosess som binder det riktige frøet til den riktige VPN-identiteten, pluss en verifisert erstatningsvei for en mistet telefon. Når brukere selv kan laste opp en fil oppkalt etter seg, blir registrering en mulighet for kontoovertakelse, og kryptering av opplastingen endrer ikke det.

En PAM-basert utforming trenger ikke opprette en egen Unix-konto per VPN-bruker. Moduldokumentasjonen støtter alternative hemmelige stier og en dedikert konto for filtilgang, som er en filsystemidentitet og ikke påloggingsidentiteten som verifiseres.

Den vanlige feilen er en fast hemmelig sti som ender på ett brukernavn, kopiert fra et eksempel med én bruker. Det er en demonstrasjon av én identitet, ikke et oppslag per bruker, og å bruke den for hver forespørsel gir ingen en uavhengig registrert autentiseringsapp. Skriv ned identitetstilordningen, beskytt frøfilene og hold passord-, sertifikat- og kontokontrollene i samme autentiseringsstakk.

Les PAM-stakken for å se hva som faktisk kreves

En linje som account required pam_permit.so implementerer ikke kontoberettigelse og legger ikke til en faktor. Den tillater det PAM-kontoadministrasjonstrinnet, som er en uttalelse om et trinn og ikke om brukerne dine.

Det samme gjelder lemfeldige registreringsvalg. Å godta brukere uten et registrert frø kan være et bevisst utrullingsvalg, men det er ikke bevis for at MFA er obligatorisk, og det bør skrives ned som et midlertidig unntak med en sluttdato.

Tilpass klientens samhandling til serverens utforming

auth-user-pass

Det direktivet ber om brukernavn og passord. Det konfigurerer ikke PAM, oppretter ikke en registreringspost og forteller ikke serveren at passordfeltet inneholder en TOTP-verdi. Serverintegrasjonen og klienten må bli enige om en samhandling som utrullingen faktisk støtter: en utfordring, et dokumentert kombinert påloggingsformat eller en produktspesifikk flyt.

Ikke legg til en kode i passordet bare fordi klienten viser ett felt. Det virker bare der serverens plugin forventer nøyaktig det formatet, og det feiler forvirrende alle andre steder.

Hold frø og QR-materiale unna delte profiler og rutinemessige diagnostiske logger. En kode sendt over den autentiserte påloggingskanalen er ikke samme objekt som frøet som ble utlevert under kontrollert registrering, og å blande dem i en støttebillett er måten hemmeligheter slipper ut.

Gjenoppkoblinger, tokens og testen som avgjør saken

Planlegg hva som skjer etter den første vellykkede påloggingen. En tidligere godtatt kode kan være utløpt eller avvist som en gjentakelse ved neste autentisering. auth-nocache styrer oppbevaring av påloggingsinformasjon og installerer ikke MFA, og reneg-sec 0 er ikke en definisjon av TOTP-støtte, uansett hvor ofte den dukker opp i forumtråder.

Noen utrullinger utsteder autentiseringstokens etter den første kontrollen, slik at gjenoppkoblinger ikke spør igjen. Det er et designvalg med sitt eget gyldighetsvindu og sin egen tilbakekallingshistorie, ikke en standardverdi du arver.

Test deretter adgangspolitikken med klienten folk faktisk bruker. En registrert bruker med riktig passord, sertifikat og gjeldende kode bør kunne koble til. En feil kode, en bruker uten registrering og en forbudt konto bør hver for seg feile, og årsaken bør være synlig i serverloggen. Inntil du har sett de avvisningene, har du en ledetekst, ikke en politikk.