RouterOS OpenVPN i NPS: ustaw user-auth-method, nie auth

W RouterOS auth wybiera skrót tunelu, a user-auth-method decyduje, jak sprawdzane jest żądanie RADIUS. Dopasuj drugie do polityki NPS.

RouterOS może dotrzeć do NPS z logowaniem OpenVPN i mimo to zostać odrzucony, a zwykłą przyczyną są dwa ustawienia, których nazwy oba brzmią jak uwierzytelnianie. Jedno wybiera skrót kryptograficzny tunelu; drugie decyduje, jak dane logowania użytkownika są przedstawiane RADIUS. Zmiana skrótu nigdy nie zamieni żądania PAP w MS-CHAPv2, niezależnie od liczby restartów usługi. Poniższa lista kontrolna rozdziela oba, a następnie śledzi jedno nieudane logowanie przez politykę NPS, która je oceniła.

Krok 1: przeczytaj oba ustawienia, zanim zmienisz którekolwiek

Wydrukuj obowiązującą konfigurację serwera OpenVPN na routerze kończącym tunel, a nie z kopii zapasowej ani skopiowanego wpisu z forum. Dwa interesujące cię pola zwykle znajdują się w tym samym menu i czytają się tak, jakby były alternatywami. Nie są: jedno dotyczy kanału danych, drugie wymiany danych logowania.

/interface ovpn-server server print
/interface ovpn-server server export

Pole auth wymienia skróty, takie jak sha1 i sha256, i steruje HMAC, który uwierzytelnia pakiety tunelu. Pole user-auth-method wybiera pap lub mschap2 i decyduje, jak router przedstawia dane logowania użytkownika RADIUS. Zmiana skrótu nie może zmienić drugiego zachowania, dlatego to samo odrzucenie przeżywa każdą korektę pierwszego.

Zatrzymaj się tutaj, jeśli twoje wydanie w ogóle nie udostępnia user-auth-method. Starsze kompilacje RouterOS mogą go nie oferować na serwerze OpenVPN, a poprawka należy do wydania, które możesz wspierać, a nie do polecenia skopiowanego z nowszego.

Krok 2: znajdź politykę, która naprawdę odrzuciła logowanie

Po stronie NPS żądanie połączenia jest oceniane według polityk sieciowych, a metoda uwierzytelniania wskazana w pasującej polityce musi być tą, którą klient rzeczywiście zaoferował. Skoreluj jedno nieudane logowanie według czasu i użytkownika, zamiast czytać zbiorczą liczbę. Dziennik zabezpieczeń zapisuje żądania przyznane i odrzucone z kodem przyczyny, co mówi znacznie więcej niż ogólny wiersz błędu routera.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Przeczytaj trzy rzeczy w zdarzeniu: nazwę pasującej polityki, metodę uwierzytelniania i kod przyczyny. Polityka wymagająca MS-CHAPv2 odrzuca żądanie PAP nawet przy poprawnym haśle, a polityka wymagająca konta domenowego odrzuca konto lokalne. Wpis klienta RADIUS musi również odpowiadać adresowi źródłowemu routera, inaczej żądanie jest odrzucane, zanim jakakolwiek polityka zostanie sprawdzona. Nic z tego nie pojawia się w dzienniku OpenVPN.

Zatrzymaj się tutaj, jeśli żądanie nigdy nie dociera do NPS. To problem wspólnego sekretu, adresu klienta lub UDP 1812, a zmiana metod uwierzytelniania go nie naprawi.

Krok 3: zmień jedną metodę, po obu stronach

Jeśli zatwierdzonym projektem jest MS-CHAPv2, ustaw go na routerze i potwierdź, że pasująca polityka go akceptuje. Zmień jedną stronę, przetestuj ponownie, a następnie zmień drugą; zmiana obu naraz uniemożliwia stwierdzenie, która miała znaczenie.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Nie włączaj na NPS każdej słabszej metody, aby błąd zniknął. Zaplecze musi mieć materiał, który wybrana metoda może zweryfikować: MS-CHAPv2 wymaga dostępu do hasła lub domeny, a polityka nie może tego materiału wymyślić. Rozszerzanie polityki rozszerza też to, czego atakujący może spróbować wobec tego samego konta. Zapisz razem metodę, nazwę polityki i odniesienie zmiany, aby następna osoba odziedziczyła decyzję, a nie przypuszczenie.

Pozostaw walidację certyfikatu tunelu dokładnie taką, jaka była. Metoda danych logowania nie zastępuje tożsamości serwera, a obniżanie kontroli TLS, aby test przeszedł, zamienia jeden problem na gorszy.

Krok 4: przetestuj trzy logowania i jedno uprawnienie

Przetestuj dozwolonego użytkownika, błędne hasło i wykluczonego użytkownika, każdego w nowej sesji. Pierwsze dowodzi ścieżki, drugie dowodzi, że sprawdzanie danych logowania jest prawdziwe, a trzecie dowodzi, że polityka nadal wyklucza tych, których powinna. Sesja w pamięci podręcznej może ukryć wszystkie trzy, więc rozłączaj się między próbami.

/log print where topics~"ovpn"
/radius monitor 0

Skuteczne uwierzytelnienie nie jest końcem listy kontrolnej. Sprawdź adres, który otrzymał klient, oraz zasoby, do których ten adres może dotrzeć, ponieważ użytkownik może uwierzytelnić się poprawnie i mimo to trafić do niewłaściwej puli. Jeśli przypisany adres jest błędny, problem leży w profilu lub atrybutach odpowiedzi RADIUS, a nie w metodzie. Potwierdź oba przed zamknięciem zgłoszenia.

Lista kontrolna jest gotowa, gdy ustawienie routera i polityka NPS nazywają tę samą metodę, dozwolony użytkownik łączy się w nowej sesji, błędne hasło jest odrzucane, wykluczony użytkownik pozostaje wykluczony, a przypisany adres odpowiada zamierzonej puli. Cokolwiek mniej pozostawia następne logowanie przypadkowi.

Powiązane artykuły