Najpierw metoda EAP: którego skrótu hasła może użyć VPN
VPN weryfikuje sekret, a nie skrót z sieci. Przeczytaj metodę, a potem sprawdź, co przechowuje magazyn, zanim obiecasz, że te same hasła nadal będą działać.
Wiele zespołów ma działające logowanie sieciowe i VPN, która odrzuca każde hasło z tej samej tabeli. Aplikacja sieciowa porównuje skrót, który sama obliczyła, podczas gdy tunel prosi klienta o wykazanie posiadania sekretu w sposób, który serwer musi umieć sprawdzić. To różne wymagania wobec przechowywanego materiału. Właśnie w luce między nimi większość takich projektów utyka.
Najpierw metoda, potem schemat
Zapisz, jakiego dowodu wymaga wybrana metoda, zanim spojrzysz na jakikolwiek schemat. Metoda wyzwanie-odpowiedź potrzebuje materiału, z którego serwer może obliczyć oczekiwaną odpowiedź, co w praktyce oznacza hasło lub zgodną formę pochodną. Metoda, która przenosi hasło w chronionym tunelu, potrzebuje samego hasła po stronie weryfikatora. Czytaj dokumentację metody pod kątem wymogu weryfikatora, a nie konfiguracji klienta, bo wymagania klienta są zwykle łatwiejszą częścią.
Skrót z solą wytworzony przez nowoczesny framework sieciowy nie daje ani jednego, ani drugiego. Sprawdza jedno konkretne porównanie i nie da się go odwrócić do sekretu, z którego powstał.
Wyzwanie-odpowiedź nie może użyć skrótu z solą
MSCHAPv2 to wymiana typu wyzwanie-odpowiedź, więc serwer nigdy nie otrzymuje hasła i nie może porównać przechowywanego łańcucha. Musi wyprowadzić oczekiwaną odpowiedź z materiału, który już ma, i dlatego zgodne formy przechowywania są tak wąskie. Wartość bcrypt lub Argon2 z solą na użytkownika jest jednokierunkowa w sposób, który całkowicie wyklucza wymianę. Tabela poniżej wychodzi od formy przechowywania, a nie od nazwy metody, bo to forma przechowywania rozstrzyga odpowiedź.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Dokumentacja wtyczki SQL dla strongSwana definiuje własny schemat konfiguracji i poświadczeń, a projekt nadal oznacza tę wtyczkę jako eksperymentalną. Nic w niej nie dopasowuje się do tabeli użytkowników aplikacji ani nie zgaduje, który schemat skrótu wytworzył przechowywaną wartość. Realistyczne opcje to zatem migracja do magazynu, którego brama może użyć, albo usługa uwierzytelniania przed istniejącym magazynem, która potrafi wykonać wymianę. Wszystko inne to łącznik z ukrytym założeniem w środku.
RADIUS przenosi pracę, nie wymóg
Delegowanie EAP do serwera RADIUS zmienia miejsce weryfikacji i zwykle poprawia ślad audytu. Nie odzyskuje hasła z jednokierunkowego skrótu, więc usługa uwierzytelniania nadal potrzebuje materiału zgodnego z metodą, którą kończy. Zespoły dowiadują się o tym po zbudowaniu ścieżki RADIUS i napotkaniu tej samej ściany po drugiej stronie.
Tam, gdzie serwer RADIUS może czytać katalog ze zgodnymi poświadczeniami, projekt działa, a brama VPN pozostaje prosta. Tam, gdzie nie może, uczciwą odpowiedzią jest zmiana rejestracji, a nie kolejny łącznik. Nadawanie i odbieranie uprawnień należy do tego, kto posiada tożsamość, więc skopiowana tabela bez wspieranego procesu synchronizacji to drugi cykl życia poświadczeń, a nie jednokrotne logowanie. Rozjeżdża się za pierwszym razem, gdy ktoś zresetuje hasło tylko w jednym miejscu, a rozjazd jest cichy, dopóki konto istniejące w obu systemach nie zacznie zachowywać się inaczej w każdym z nich.
Ogranicz konto czytające katalog tylko do tego odczytu i trzymaj je osobno od konta, którego brama używa do własnej konfiguracji. Wspólne konto administracyjne zamienia projekt tylko do odczytu w znacznie szerszy promień rażenia.
Gdzie powinno mieszkać konto
Gdy kwestia materiału jest rozstrzygnięta, zostają dwie architektury. Brama może mieć mały magazyn poświadczeń, który czyta tylko ona, albo delegować do usługi uwierzytelniania stojącej przed katalogiem firmowym.
Pierwsza jest łatwiejsza do przemyślenia i gorsza dla użytkownika, któremu zostaje drugie hasło do utrzymania. Druga zachowuje jedną tożsamość i dodaje zależność od usługi, która teraz musi działać, zanim ktokolwiek się połączy. Żadna nie jest błędna, ale wybór warto zapisać obok konfiguracji bramy, bo inaczej następny inżynier założy, że wybrano tę drugą. Cokolwiek wybierzesz, dwa polecenia poniżej to te, które pokazują stan obecny przed zmianą.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsUwierzytelnianie konta nie rozstrzyga też autoryzacji. Członkostwo w grupach, stan urządzenia i uprawnienie sieciowe nadal wymagają jawnego mapowania po tym, jak użytkownik udowodnił wymaganą tożsamość. Połączenie, które uwierzytelnia się doskonale i niczego nie autoryzuje, jest wynikiem polityki, a nie błędem w metodzie.