Proč úprava souboru .ovpn nezapne MFA na serveru

Přidáte auth-user-pass do profilu, znovu se připojíte a klient si vyžádá uživatelské jméno a heslo. Vypadá to, že MFA je zapnuté. Pak zadáte kód z jiného účtu nebo kód, kterému před deseti minutami vypršela platnost, a tunel přesto naskočí. To je příznak: klient se změnil, server ne. Jednorázové heslo je faktorem jen tehdy, když ověřovatel na serveru rozhodne, zda je platné pro identitu, která ho uplatňuje.

Výzva dokazuje jen to, že se klient zeptal, nic víc

Soubor .ovpn je dokument na straně klienta. Může klientovi říct, aby si vyžádal přihlašovací údaje, ukládal je do mezipaměti nebo to přestal dělat. Nemůže zaregistrovat uživatele, nainstalovat modul PAM ani přimět server vyžadovat druhý faktor, který právě teď neověřuje.

Ani instalace autentizační aplikace do telefonu tento vztah nevytvoří. Projekt Google Authenticator PAM je komponenta pro ověřování OTP, která může stát za OpenVPN; není to způsob, jak na importovaný profil přilepit přihlášení k účtu Google.

Registrace je část, kterou profil nezvládne

TOTP potřebuje registrační materiál sdílený mezi autentizační aplikací a jejím ověřovatelem. Šest číslic v telefonu je výstup; semínko za nimi je tajemství a patří jedné identitě.

Operátor tedy potřebuje registrační proces, který spojí správné semínko se správnou identitou VPN, a k tomu ověřenou cestu náhrady za ztracený telefon. Když uživatelům dovolíte nahrát soubor pojmenovaný po nich, proměníte registraci v příležitost k převzetí účtu, a šifrování nahrávaného souboru to nezmění.

Návrh založený na PAM nemusí vytvářet samostatný unixový účet pro každého uživatele VPN. Dokumentace modulu podporuje alternativní cesty k tajemstvím a vyhrazený účet pro přístup k souborům, což je identita v souborovém systému, nikoli přihlašovací identita, která se ověřuje.

Častou chybou je pevná cesta k tajemství končící jedním uživatelským jménem, zkopírovaná z příkladu pro jednoho uživatele. To je ukázka jedné identity, ne vyhledávání podle uživatele, a použití pro každý požadavek nikomu nedá nezávisle registrovanou autentizační aplikaci. Zapište mapování identit, chraňte soubory se semínky a udržujte kontroly hesla, certifikátu a účtu ve stejném autentizačním zásobníku.

Přečtěte si zásobník PAM a zjistěte, co se skutečně vyžaduje

Řádek jako account required pam_permit.so neimplementuje způsobilost účtu a nepřidává faktor. Povoluje tu fázi správy účtů v PAM, což je tvrzení o fázi, ne o vašich uživatelích.

Totéž platí pro benevolentní možnosti registrace. Přijímání uživatelů bez registrovaného tajemství může být záměrná volba při zavádění, ale není to důkaz, že MFA je povinné, a mělo by to být zapsáno jako dočasná výjimka s datem konce.

Slaďte interakci klienta s návrhem serveru

auth-user-pass

Tato direktiva žádá zadání uživatelského jména a hesla. Nekonfiguruje PAM, nevytváří registrační záznam a neříká serveru, že pole hesla obsahuje hodnotu TOTP. Integrace serveru a klient se musí dohodnout na interakci, kterou nasazení skutečně podporuje: výzva, dokumentovaný kombinovaný formát přihlašovacích údajů nebo tok specifický pro produkt.

Nepřipojujte kód k heslu jen proto, že klient zobrazuje jedno pole. Funguje to jen tam, kde plugin serveru očekává přesně tento formát, a všude jinde to selhává matoucím způsobem.

Držte semínka a QR materiál mimo sdílené profily a běžné diagnostické záznamy. Kód odeslaný ověřeným přihlašovacím kanálem není stejný objekt jako semínko vydané při řízené registraci, a jejich smíchání v podpůrném tiketu je cesta, kterou tajemství unikají.

Opětovná připojení, tokeny a test, který to rozsekne

Naplánujte, co se stane po prvním úspěšném přihlášení. Dříve přijatý kód může být při další autentizaci prošlý nebo odmítnutý jako opakování. auth-nocache řídí uchovávání přihlašovacích údajů a neinstaluje MFA a reneg-sec 0 není definicí podpory TOTP, ať se ve vláknech fóra objevuje jakkoli často.

Některá nasazení vydávají po počáteční kontrole autentizační tokeny, aby se opětovná připojení znovu neptala. To je designové rozhodnutí s vlastním oknem platnosti a historií odvolání, ne výchozí hodnota, kterou dědíte.

Potom otestujte politiku přijetí s klientem, který lidé skutečně používají. Registrovaný uživatel se správným heslem, certifikátem a aktuálním kódem se má připojit. Špatný kód, uživatel bez registrace a zakázaný účet mají každý selhat a důvod má být viditelný v protokolu serveru. Dokud ta odmítnutí neuvidíte, máte výzvu, ne politiku.