RouterOS OpenVPN a NPS: nastavte user-auth-method, ne auth

V RouterOS vybírá auth digest tunelu, zatímco user-auth-method určuje, jak se kontroluje požadavek RADIUS. Slučte druhé s politikou NPS.

RouterOS se může přihlásit k NPS přes OpenVPN a přesto být odmítnut, a obvyklou příčinou jsou dvě nastavení, jejichž názvy oba znějí jako autentizace. Jedno vybírá kryptografický digest pro tunel; druhé určuje, jak se přihlašovací údaje uživatele předkládají RADIUSu. Změna digestu nikdy nepřemění požadavek PAP na MS-CHAPv2, ať se služba restartuje jakkoli často. Kontrolní seznam níže obojí odděluje a poté sleduje jedno neúspěšné přihlášení přes politiku NPS, která o něm rozhodla.

Krok 1: přečtěte obě nastavení, než některé změníte

Vypište platnou konfiguraci serveru OpenVPN na routeru, který tunel ukončuje, ne ze zálohy ani z kopírovaného příspěvku na fóru. Obě pole, která vás zajímají, bývají ve stejné nabídce a čtou se, jako by šlo o alternativy. Nejsou: jedno se týká datového kanálu, druhé výměny přihlašovacích údajů.

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

Pole auth vypisuje digesty jako sha1 a sha256 a řídí HMAC, který autentizuje pakety tunelu. Pole user-auth-method volí pap nebo mschap2 a určuje, jak router předkládá přihlašovací údaje uživatele RADIUSu. Změna digestu nemůže změnit druhé chování, a proto stejné odmítnutí přežije každou úpravu prvního.

Zastavte se zde, pokud vaše verze user-auth-method vůbec nezpřístupňuje. Starší sestavení RouterOS jej na serveru OpenVPN nemusí nabízet a oprava patří do verze, kterou můžete podporovat, ne do příkazu zkopírovaného z novější.

Krok 2: najděte politiku, která přihlášení skutečně odmítla

Na straně NPS se požadavek na připojení vyhodnocuje podle síťových politik a metoda autentizace uvedená v odpovídající politice musí být ta, kterou klient skutečně nabídl. Spárujte jedno neúspěšné přihlášení podle času a uživatele, místo abyste četli souhrnný počet. Bezpečnostní protokol zaznamenává povolené i zamítnuté požadavky s kódem důvodu, což vám řekne mnohem víc než obecný řádek chyby routeru.

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

V události čtěte tři věci: název odpovídající politiky, metodu autentizace a kód důvodu. Politika vyžadující MS-CHAPv2 odmítne požadavek PAP i při správném heslu a politika vyžadující doménový účet odmítne místní. Záznam klienta RADIUS musí také odpovídat zdrojové adrese routeru, jinak se požadavek zahodí dřív, než se prozkoumá jakákoli politika. Nic z toho se v protokolu OpenVPN neobjeví.

Zastavte se zde, pokud požadavek nikdy nedorazí do NPS. To je problém sdíleného tajemství, adresy klienta nebo UDP 1812 a změna metod autentizace to neopraví.

Krok 3: změňte jednu metodu, na obou stranách

Pokud je schválený návrh MS-CHAPv2, nastavte jej na routeru a potvrďte, že odpovídající politika jej přijímá. Změňte jednu stranu, otestujte a poté změňte druhou; změna obou najednou vás nechá bez možnosti říci, která byla důležitá.

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

Nezapínejte na NPS každou slabší metodu, aby chyba zmizela. Backend musí mít materiál, který zvolená metoda dokáže ověřit: MS-CHAPv2 potřebuje přístup k heslu nebo k doméně a politika tento materiál nemůže vymyslet. Rozšíření politiky také rozšiřuje, co může útočník zkusit proti stejnému účtu. Zapište metodu, název politiky a referenci změny společně, aby další člověk zdědil rozhodnutí, ne domněnku.

Ověřování certifikátu tunelu nechte přesně takové, jaké bylo. Metoda přihlašovacích údajů nenahrazuje identitu serveru a snižování kontrol TLS, aby test prošel, mění jeden problém za horší.

Krok 4: otestujte tři přihlášení a jedno oprávnění

Otestujte povoleného uživatele, špatné heslo a vyloučeného uživatele, každého v nové relaci. První dokazuje cestu, druhý dokazuje, že kontrola údajů je skutečná, a třetí dokazuje, že politika stále vylučuje, koho má. Uložená relace může skrýt všechny tři, proto se mezi pokusy odpojte.

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

Úspěšná autentizace není konec kontrolního seznamu. Zkontrolujte adresu, kterou klient dostal, a prostředky, které tato adresa může dosáhnout, protože uživatel se může správně autentizovat a přesto skončit ve špatném fondu. Pokud je přidělená adresa špatná, problém je v profilu nebo v atributech odpovědi RADIUS, ne v metodě. Potvrďte obojí, než tiket uzavřete.

Kontrolní seznam je hotový, když nastavení routeru a politika NPS uvádějí stejnou metodu, povolený uživatel se připojí v nové relaci, špatné heslo je odmítnuto, vyloučený uživatel zůstává vyloučen a přidělená adresa odpovídá zamýšlenému fondu. Cokoli méně nechává další přihlášení na náhodě.

Související články