Miért nem kapcsolhatja be egy .ovpn fájl szerkesztése az MFA-t a kiszolgálón

Hozzáadod a auth-user-pass sort egy profilhoz, újracsatlakozol, és az ügyfél felhasználónevet és jelszót kér. Úgy tűnik, mintha az MFA be lenne kapcsolva. Aztán beírsz egy kódot a rossz fiókból, vagy egy tíz perccel ezelőtt lejárt kódot, és az alagút mégis feljön. Ez a tünet: az ügyfél megváltozott, a kiszolgáló nem. Az egyszeri jelszó csak akkor tényező, ha a kiszolgálón egy ellenőrző eldönti, érvényes-e az azt igénylő identitás számára.

A kérés csak azt bizonyítja, hogy az ügyfél kérdezett, semmi többet

A .ovpn fájl ügyféloldali dokumentum. Megmondhatja az ügyfélnek, hogy kérjen hitelesítő adatokat, gyorsítótárazza azokat, vagy hagyja abba. Nem tud felhasználót regisztrálni, PAM modult telepíteni, vagy rávenni a kiszolgálót egy olyan második tényező megkövetelésére, amelyet jelenleg nem ellenőriz.

Egy hitelesítő alkalmazás telefonra telepítése sem hozza létre ezt a kapcsolatot. A Google Authenticator PAM projekt egy OTP-ellenőrző komponens, amely állhat OpenVPN mögött; ez nem módja annak, hogy a Google-fiók bejelentkezését egy importált profilhoz ragasszuk.

A regisztráció az a rész, amelyet egy profil nem tud elvégezni

A TOTP-hez a hitelesítő alkalmazás és ellenőrzője között megosztott regisztrációs anyag kell. A telefonon lévő hat számjegy a kimenet; a mögötte lévő mag a titok, és egyetlen identitáshoz tartozik.

Ezért a kezelőnek olyan regisztrációs folyamatra van szüksége, amely a megfelelő magot a megfelelő VPN-identitáshoz köti, valamint egy ellenőrzött csereútra elveszett telefon esetén. Ha a felhasználók a saját nevükre elnevezett fájlt tölthetnek fel, a regisztráció fiókátvételi lehetőséggé válik, és a feltöltés titkosítása ezen nem változtat.

A PAM-alapú tervezésnek nem kell külön Unix-fiókot létrehoznia minden VPN-felhasználóhoz. A modul dokumentációja támogatja az alternatív titkos útvonalakat és a fájlhozzáféréshez dedikált fiókot, ami fájlrendszer-identitás, nem az ellenőrzött bejelentkezési identitás.

A gyakori hiba egyetlen felhasználónévre végződő, fix titkos útvonal, amelyet egy egyfelhasználós példából másoltak. Ez egyetlen identitás bemutatása, nem felhasználónkénti keresés, és minden kéréshez használva senkinek sem ad függetlenül regisztrált hitelesítő alkalmazást. Írd le az identitásleképezést, védd a magfájlokat, és tartsd a jelszó-, tanúsítvány- és fiókellenőrzéseket ugyanabban a hitelesítési veremben.

Olvasd el a PAM vermet, hogy lásd, mi is szükséges valójában

Egy olyan sor, mint a account required pam_permit.so, nem valósítja meg a fiók jogosultságát, és nem ad hozzá tényezőt. Engedélyezi azt a PAM-fiókkezelési szakaszt, ami egy szakaszról szóló állítás, nem a felhasználóidról.

Ugyanez vonatkozik az engedékeny regisztrációs beállításokra. A regisztrált mag nélküli felhasználók elfogadása szándékos bevezetési döntés lehet, de nem bizonyítja, hogy az MFA kötelező, és ideiglenes kivételként kell rögzíteni, záró dátummal.

Igazítsd az ügyfél interakcióját a kiszolgáló tervezéséhez

auth-user-pass

Ez az utasítás felhasználónév és jelszó bevitelét kéri. Nem konfigurálja a PAM-ot, nem hoz létre regisztrációs rekordot, és nem mondja meg a kiszolgálónak, hogy a jelszómező TOTP-értéket tartalmaz. A kiszolgálóintegrációnak és az ügyfélnek meg kell állapodnia egy olyan interakcióban, amelyet a telepítés valóban támogat: kihívás, dokumentált kombinált hitelesítőadat-formátum vagy termékspecifikus folyamat.

Ne fűzz kódot a jelszóhoz csak azért, mert az ügyfél egy mezőt mutat. Ez csak ott működik, ahol a kiszolgáló bővítménye pontosan azt a formátumot várja, mindenhol máshol pedig zavaróan meghiúsul.

Tartsd a magokat és a QR-anyagot a megosztott profilokon és a rutin diagnosztikai naplókon kívül. A hitelesített bejelentkezési csatornán benyújtott kód nem ugyanaz az objektum, mint a kontrollált regisztráció során kiadott mag, és ezek összekeverése egy támogatási jegyben az, ahogyan a titkok kiszöknek.

Újracsatlakozások, tokenek és a döntő teszt

Tervezd meg, mi történik az első sikeres bejelentkezés után. Egy korábban elfogadott kód lejárhat, vagy visszajátszásként elutasítható a következő hitelesítéskor. A auth-nocache a hitelesítő adatok megőrzését szabályozza, és nem telepít MFA-t, a reneg-sec 0 pedig nem a TOTP-támogatás meghatározása, akárhányszor is jelenik meg fórumtémákban.

Egyes telepítések a kezdeti ellenőrzés után hitelesítési tokeneket bocsátanak ki, hogy az újracsatlakozások ne kérdezzenek újra. Ez saját érvényességi ablakkal és visszavonási történettel rendelkező tervezési döntés, nem pedig örökölt alapértelmezés.

Aztán teszteld a belépési szabályzatot azzal az ügyféllel, amelyet az emberek valóban használnak. Egy regisztrált felhasználónak a helyes jelszóval, tanúsítvánnyal és aktuális kóddal csatlakoznia kell. Egy rossz kódnak, egy regisztráció nélküli felhasználónak és egy tiltott fióknak külön-külön meg kell buknia, és az oknak láthatónak kell lennie a kiszolgáló naplójában. Amíg nem láttad ezeket az elutasításokat, van egy kérésed, nem egy szabályzatod.