Varför redigering av en .ovpn-fil inte kan slå på MFA på servern

Du lägger till auth-user-pass i en profil, återansluter, och klienten frågar efter ett användarnamn och ett lösenord. Det ser ut som om MFA är på. Sedan skriver du in en kod från fel konto, eller en kod som gick ut för tio minuter sedan, och tunneln kommer ändå upp. Det är symptomet: klienten ändrades, servern gjorde det inte. Ett engångslösenord är bara en faktor när en verifierare på servern avgör om det är giltigt för den identitet som kräver det.

Prompten bevisar bara att klienten frågade, inget mer

En .ovpn-fil är ett dokument på klientsidan. Den kan säga åt klienten att begära inloggningsuppgifter, cachelagra dem eller sluta med det. Den kan inte registrera en användare, installera en PAM-modul eller få servern att kräva en andra faktor som den inte kontrollerar i dag.

Att installera en autentiseringsapp på en telefon skapar inte heller den relationen. Google Authenticator PAM-projektet är en OTP-verifieringskomponent som kan sitta bakom OpenVPN; det är inte ett sätt att klistra in Google-kontoinloggning på en importerad profil.

Registreringen är den del som en profil inte klarar

TOTP behöver registreringsmaterial som delas mellan autentiseringsappen och dess verifierare. De sex siffrorna på telefonen är utdata; fröet bakom dem är hemligheten, och det tillhör en enda identitet.

Därför behöver operatören en registreringsprocess som binder rätt frö till rätt VPN-identitet, plus en verifierad ersättningsväg för en förlorad telefon. När användare själva kan ladda upp en fil uppkallad efter sig blir registreringen en möjlighet till kontokapning, och kryptering av uppladdningen ändrar inte det.

En PAM-baserad design behöver inte skapa ett separat Unix-konto per VPN-användare. Moduldokumentationen stöder alternativa hemliga sökvägar och ett dedikerat konto för filåtkomst, vilket är en filsystemidentitet och inte den inloggningsidentitet som verifieras.

Det vanliga misstaget är en fast hemlig sökväg som slutar på ett användarnamn, kopierad från ett exempel med en användare. Det är en demonstration av en identitet, inte en uppslagning per användare, och att använda den för varje begäran ger ingen en oberoende registrerad autentiseringsapp. Skriv ned identitetsmappningen, skydda fröfilerna och håll lösenords-, certifikats- och kontokontrollerna i samma autentiseringsstack.

Läs PAM-stacken för att se vad som faktiskt krävs

En rad som account required pam_permit.so implementerar inte kontobehörighet och lägger inte till en faktor. Den tillåter det PAM-kontoadministrationssteget, vilket är ett uttalande om ett steg och inte om dina användare.

Samma sak gäller tillåtande registreringsalternativ. Att acceptera användare utan ett registrerat frö kan vara ett medvetet utrullningsval, men det är inte bevis för att MFA är obligatoriskt, och det bör skrivas ned som ett tillfälligt undantag med ett slutdatum.

Anpassa klientens interaktion till serverns design

auth-user-pass

Det direktivet begär inmatning av användarnamn och lösenord. Det konfigurerar inte PAM, skapar ingen registreringspost och talar inte om för servern att lösenordsfältet innehåller ett TOTP-värde. Serverintegrationen och klienten måste enas om en interaktion som utrullningen faktiskt stöder: en utmaning, ett dokumenterat kombinerat inloggningsformat eller ett produktspecifikt flöde.

Lägg inte till en kod i lösenordet bara för att klienten visar ett fält. Det fungerar bara där serverns plugin förväntar sig exakt det formatet, och det misslyckas förvirrande överallt annars.

Håll frön och QR-material borta från delade profiler och rutinmässiga diagnostikloggar. En kod som skickas över den autentiserade inloggningskanalen är inte samma objekt som det frö som delades ut vid kontrollerad registrering, och att blanda dem i ett supportärende är hur hemligheter läcker ut.

Återanslutningar, tokens och testet som avgör saken

Planera vad som händer efter den första lyckade inloggningen. En tidigare accepterad kod kan ha gått ut eller avvisas som en upprepning vid nästa autentisering. auth-nocache styr bevarandet av inloggningsuppgifter och installerar inte MFA, och reneg-sec 0 är inte en definition av TOTP-stöd, hur ofta det än dyker upp i forumtrådar.

Vissa utrullningar utfärdar autentiseringstoken efter den första kontrollen så att återanslutningar inte frågar igen. Det är ett designbeslut med sitt eget giltighetsfönster och sin egen återkallningshistoria, inte ett standardvärde du ärver.

Testa sedan åtkomstpolicyn med den klient som folk faktiskt använder. En registrerad användare med rätt lösenord, certifikat och aktuell kod bör kunna ansluta. En felaktig kod, en användare utan registrering och ett förbjudet konto bör var och en misslyckas, och orsaken bör synas i serverloggen. Tills du har sett de avvisningarna har du en prompt, inte en policy.