Dlaczego edycja pliku .ovpn nie może włączyć MFA na serwerze

Dodajesz auth-user-pass do profilu, łączysz się ponownie, a klient prosi o nazwę użytkownika i hasło. Wygląda to tak, jakby MFA było włączone. Potem wpisujesz kod z niewłaściwego konta albo kod, który wygasł dziesięć minut temu, a tunel i tak się podnosi. To jest objaw: klient się zmienił, serwer nie. Hasło jednorazowe jest czynnikiem tylko wtedy, gdy weryfikator na serwerze decyduje, czy jest ważne dla tożsamości, która się nim posługuje.

Monit dowodzi tylko, że klient zapytał, nic więcej

Plik .ovpn to dokument po stronie klienta. Może kazać klientowi poprosić o dane logowania, zapisać je w pamięci podręcznej albo przestać to robić. Nie może zarejestrować użytkownika, zainstalować modułu PAM ani sprawić, by serwer wymagał drugiego czynnika, którego teraz nie sprawdza.

Zainstalowanie aplikacji uwierzytelniającej na telefonie też nie tworzy tej relacji. Projekt Google Authenticator PAM to komponent weryfikacji OTP, który może stać za OpenVPN; to nie jest sposób na przyklejenie logowania do konta Google do zaimportowanego profilu.

Rejestracja to ta część, której profil nie potrafi wykonać

TOTP potrzebuje materiału rejestracyjnego współdzielonego między aplikacją uwierzytelniającą a jej weryfikatorem. Sześć cyfr na telefonie to wynik; ziarno za nimi jest tajemnicą i należy do jednej tożsamości.

Dlatego operator potrzebuje procesu rejestracji, który wiąże właściwe ziarno z właściwą tożsamością VPN, a także zweryfikowanej ścieżki wymiany dla utraconego telefonu. Pozwalanie użytkownikom na wgrywanie pliku nazwanego ich nazwiskiem zamienia rejestrację w okazję do przejęcia konta, a szyfrowanie wgranego pliku tego nie zmienia.

Projekt oparty na PAM nie musi tworzyć osobnego konta Unix dla każdego użytkownika VPN. Dokumentacja modułu obsługuje alternatywne ścieżki tajnych danych i dedykowane konto dostępu do plików, czyli tożsamość systemu plików, a nie weryfikowaną tożsamość logowania.

Częstym błędem jest stała ścieżka tajemnicy kończąca się jedną nazwą użytkownika, skopiowana z przykładu dla jednego użytkownika. To demonstracja jednej tożsamości, a nie wyszukiwanie według użytkownika, i używanie jej do każdego żądania nikomu nie daje niezależnie zarejestrowanej aplikacji uwierzytelniającej. Zapisz mapowanie tożsamości, chroń pliki ziaren i trzymaj sprawdzanie hasła, certyfikatu i konta w tym samym stosie uwierzytelniania.

Przeczytaj stos PAM, aby zobaczyć, czego naprawdę się wymaga

Linia taka jak account required pam_permit.so nie implementuje uprawnień konta i nie dodaje czynnika. Zezwala na ten etap zarządzania kontami PAM, co jest stwierdzeniem o etapie, a nie o twoich użytkownikach.

To samo dotyczy łagodnych opcji rejestracji. Akceptowanie użytkowników bez zarejestrowanego ziarna może być świadomą decyzją wdrożeniową, ale nie jest dowodem, że MFA jest obowiązkowe, i należy to zapisać jako tymczasowy wyjątek z datą końcową.

Dopasuj interakcję klienta do projektu serwera

auth-user-pass

Ta dyrektywa prosi o wprowadzenie nazwy użytkownika i hasła. Nie konfiguruje PAM, nie tworzy rekordu rejestracji i nie mówi serwerowi, że pole hasła zawiera wartość TOTP. Integracja serwera i klient muszą uzgodnić interakcję, którą wdrożenie naprawdę obsługuje: wyzwanie, udokumentowany połączony format danych logowania albo przepływ specyficzny dla produktu.

Nie dopisuj kodu do hasła tylko dlatego, że klient pokazuje jedno pole. To działa tylko tam, gdzie wtyczka serwera oczekuje dokładnie tego formatu, a wszędzie indziej zawodzi w mylący sposób.

Trzymaj ziarna i materiał QR z dala od współdzielonych profili i rutynowych logów diagnostycznych. Kod przesłany uwierzytelnionym kanałem logowania to nie ten sam obiekt co ziarno wydane podczas kontrolowanej rejestracji, a mieszanie ich w zgłoszeniu do pomocy technicznej to droga, którą wyciekają tajemnice.

Ponowne połączenia, tokeny i test, który rozstrzyga sprawę

Zaplanuj, co dzieje się po pierwszym udanym logowaniu. Wcześniej zaakceptowany kod może wygasnąć albo zostać odrzucony jako powtórzenie przy następnym uwierzytelnieniu. auth-nocache kontroluje przechowywanie danych logowania i nie instaluje MFA, a reneg-sec 0 nie jest definicją obsługi TOTP, niezależnie od tego, jak często pojawia się w wątkach forum.

Niektóre wdrożenia wydają tokeny uwierzytelniania po pierwszym sprawdzeniu, aby ponowne połączenia nie pytały ponownie. To decyzja projektowa z własnym oknem ważności i własną historią unieważniania, a nie domyślne ustawienie, które dziedziczysz.

Następnie przetestuj politykę dopuszczania z klientem, którego ludzie naprawdę używają. Zarejestrowany użytkownik z poprawnym hasłem, certyfikatem i bieżącym kodem powinien się połączyć. Błędny kod, użytkownik bez rejestracji i zablokowane konto powinny każde zawieść, a przyczyna powinna być widoczna w logu serwera. Dopóki nie zobaczysz tych odrzuceń, masz monit, a nie politykę.