RouterOS sa môže prihlásiť do NPS cez OpenVPN a napriek tomu byť odmietnutý, a obvyklou príčinou sú dve nastavenia, ktorých názvy obe znejú ako autentifikácia. Jedno vyberá kryptografický digest tunela; druhé určuje, ako sa prihlasovacie údaje používateľa predkladajú RADIUSu. Zmena digestu nikdy nezmení požiadavku PAP na MS-CHAPv2, nech sa služba reštartuje akokoľvek často. Kontrolný zoznam nižšie obe oddeľuje a potom sleduje jedno neúspešné prihlásenie cez politiku NPS, ktorá o ňom rozhodla.

Krok 1: prečítajte obe nastavenia, kým niektoré zmeníte

Vypíšte platnú konfiguráciu servera OpenVPN na routeri, ktorý ukončuje tunel, nie zo zálohy ani z kopírovaného príspevku na fóre. Obe polia, ktoré vás zaujímajú, bývajú v tej istej ponuke a čítajú sa, akoby išlo o alternatívy. Nie sú: jedno sa týka dátového kanála, druhé výmeny prihlasovacích údajov.

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

Pole auth vypisuje digesty ako sha1 a sha256 a riadi HMAC, ktorý autentifikuje pakety tunela. Pole user-auth-method volí pap alebo mschap2 a určuje, ako router predkladá prihlasovacie údaje používateľa RADIUSu. Zmena digestu nemôže zmeniť druhé správanie, a preto rovnaké odmietnutie prežije každú úpravu prvého.

Zastavte sa tu, ak vaše vydanie user-auth-method vôbec nesprístupňuje. Staršie zostavenia RouterOS ho na serveri OpenVPN nemusia ponúkať a oprava patrí do vydania, ktoré môžete podporovať, nie do príkazu skopírovaného z novšieho.

Krok 2: nájdite politiku, ktorá prihlásenie skutočne odmietla

Na strane NPS sa požiadavka na pripojenie vyhodnocuje podľa sieťových politík a metóda autentifikácie uvedená v zodpovedajúcej politike musí byť tá, ktorú klient skutočne ponúkol. Spárujte jedno neúspešné prihlásenie podľa času a používateľa, namiesto čítania súhrnného počtu. Bezpečnostný protokol zaznamenáva povolené aj zamietnuté požiadavky s kódom dôvodu, čo vám povie oveľa viac ako všeobecný riadok chyby routera.

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

V udalosti čítajte tri veci: názov zodpovedajúcej politiky, metódu autentifikácie a kód dôvodu. Politika vyžadujúca MS-CHAPv2 odmietne požiadavku PAP aj pri správnom hesle a politika vyžadujúca doménový účet odmietne miestny. Záznam klienta RADIUS musí tiež zodpovedať zdrojovej adrese routera, inak sa požiadavka zahodí skôr, než sa preskúma akákoľvek politika. Nič z toho sa v protokole OpenVPN neobjaví.

Zastavte sa tu, ak požiadavka nikdy nedorazí do NPS. To je problém spoločného tajomstva, adresy klienta alebo UDP 1812 a zmena metód autentifikácie to neopraví.

Krok 3: zmeňte jednu metódu na oboch stranách

Ak je schválený návrh MS-CHAPv2, nastavte ho na routeri a potvrďte, že zodpovedajúca politika ho prijíma. Zmeňte jednu stranu, otestujte znova a potom zmeňte druhú; zmena oboch naraz vám nedovolí povedať, ktorá bola dôležitá.

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

Nezapínajte na NPS každú slabšiu metódu, aby chyba zmizla. Backend musí mať materiál, ktorý zvolená metóda dokáže overiť: MS-CHAPv2 potrebuje prístup k heslu alebo doméne a politika tento materiál nemôže vymyslieť. Rozšírenie politiky rozširuje aj to, čo môže útočník skúsiť proti tomu istému účtu. Zapíšte metódu, názov politiky a referenciu zmeny spolu, aby ďalší človek zdedil rozhodnutie, nie domnienku.

Nechajte overovanie certifikátu tunela presne také, aké bolo. Metóda prihlasovacích údajov nenahrádza identitu servera a znižovanie kontrol TLS, aby test prešiel, vymieňa jeden problém za horší.

Krok 4: otestujte tri prihlásenia a jedno oprávnenie

Otestujte povoleného používateľa, nesprávne heslo a vylúčeného používateľa, každého v novej relácii. Prvé dokazuje cestu, druhé dokazuje, že kontrola prihlasovacích údajov je skutočná, a tretie dokazuje, že politika stále vylučuje toho, koho má. Relácia vo vyrovnávacej pamäti môže skryť všetky tri, preto sa medzi pokusmi odpojte.

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

Úspešná autentifikácia nie je koniec kontrolného zoznamu. Skontrolujte adresu, ktorú klient dostal, a prostriedky, ktoré táto adresa môže dosiahnuť, pretože používateľ sa môže správne autentifikovať a napriek tomu skončiť v nesprávnom fonde. Ak je pridelená adresa nesprávna, problém je v profile alebo v atribútoch odpovede RADIUS, nie v metóde. Potvrďte oboje pred uzavretím tiketu.

Kontrolný zoznam je hotový, keď nastavenie routera a politika NPS uvádzajú rovnakú metódu, povolený používateľ sa pripojí v novej relácii, nesprávne heslo je odmietnuté, vylúčený používateľ zostáva vylúčený a pridelená adresa zodpovedá zamýšľanému fondu. Čokoľvek menej necháva ďalšie prihlásenie na náhodu.

Súvisiace články