RouterOS OpenVPN ja NPS: aseta user-auth-method, ei auth

RouterOS voi päästä NPS:ään OpenVPN-kirjautumisella ja tulla silti hylätyksi, ja tavallinen syy on kaksi asetusta, joiden nimet molemmat kuulostavat todennukselta. Toinen valitsee tunnelille salaustiivisteen; toinen päättää, miten käyttäjän tunnistetiedot esitetään RADIUSille. Tiivisteen muuttaminen ei koskaan muuta PAP-pyyntöä MS-CHAPv2:ksi, riippumatta siitä, kuinka usein palvelu käynnistetään uudelleen. Alla oleva tarkistuslista erottaa nämä kaksi ja seuraa sitten yhtä epäonnistunutta kirjautumista sen arvioineen NPS-käytännön läpi.

Vaihe 1: lue molemmat asetukset ennen kuin muutat kumpaakaan

Tulosta tehokas OpenVPN-palvelinkokoonpano reitittimeltä, joka päättää tunnelin, ei varmuuskopiosta tai kopioidusta foorumiviestistä. Kaksi kiinnostavaa kenttää ovat yleensä samassa valikossa ja luetaan ikään kuin ne olisivat vaihtoehtoja. Ne eivät ole: toinen koskee datakanavaa, toinen tunnistetietojen vaihtoa.

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

Kenttä auth luettelee tiivisteitä, kuten sha1 ja sha256, ja ohjaa HMACia, joka todentaa tunnelin paketit. Kenttä user-auth-method valitsee papin tai mschap2:n ja päättää, miten reititin esittää käyttäjän tunnistetiedot RADIUSille. Tiivisteen muutos ei voi muuttaa jälkimmäistä toimintaa, minkä vuoksi sama hylkäys säilyy jokaisen ensimmäiseen tehdyn säädön jälkeen.

Pysähdy tähän, jos julkaisusi ei paljasta user-auth-method lainkaan. Vanhemmat RouterOS-versiot eivät ehkä tarjoa sitä OpenVPN-palvelimella, ja korjaus kuuluu julkaisuun, jota voit tukea, ei uudemmasta kopioituun komentoon.

Vaihe 2: etsi käytäntö, joka todella hylkäsi kirjautumisen

NPS:n puolella yhteyspyyntö arvioidaan verkkokäytäntöjä vastaan, ja vastaavassa käytännössä nimetyn todennusmenetelmän on oltava sellainen, jota asiakas todella tarjosi. Korreloi yksi epäonnistunut kirjautuminen ajan ja käyttäjän mukaan sen sijaan, että lukisit yhteenvetoluvun. Suojausloki kirjaa hyväksytyt ja hylätyt pyynnöt syykoodin kanssa, mikä kertoo paljon enemmän kuin reitittimen yleinen virherivi.

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

Lue tapahtumasta kolme asiaa: vastaavan käytännön nimi, todennusmenetelmä ja syykoodi. Käytäntö, joka vaatii MS-CHAPv2:n, hylkää PAP-pyynnön myös silloin, kun salasana on oikein, ja käytäntö, joka vaatii toimialuetilin, hylkää paikallisen tilin. RADIUS-asiakastietueen on myös vastattava reitittimen lähdeosoitetta, muuten pyyntö hylätään ennen kuin mitään käytäntöä tutkitaan. Mikään tästä ei näy OpenVPN-lokissa.

Pysähdy tähän, jos pyyntö ei koskaan saavu NPS:ään. Kyse on jaetusta salaisuudesta, asiakkaan osoitteesta tai UDP 1812:sta, eikä todennusmenetelmien muuttaminen korjaa sitä.

Vaihe 3: muuta yhtä menetelmää molemmilla puolilla

Jos hyväksytty suunnittelu on MS-CHAPv2, aseta se reitittimelle ja varmista, että vastaava käytäntö hyväksyy sen. Muuta toista puolta, testaa uudelleen ja muuta sitten toista; molempien muuttaminen kerralla jättää sinut kykenemättömäksi sanomaan, kumpi oli merkityksellinen.

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

Älä ota NPS:ssä käyttöön jokaista heikompaa menetelmää, jotta virhe katoaisi. Taustajärjestelmässä on oltava materiaalia, jonka valittu menetelmä voi vahvistaa: MS-CHAPv2 tarvitsee pääsyn salasanaan tai toimialueeseen, eikä käytäntö voi keksiä sitä materiaalia. Käytännön laajentaminen laajentaa myös sitä, mitä hyökkääjä voi yrittää samaa tiliä vastaan. Kirjaa menetelmä, käytännön nimi ja muutoksen viite yhteen, jotta seuraava henkilö perii päätöksen eikä arvausta.

Jätä tunnelin varmenteen validointi täsmälleen sellaiseksi kuin se oli. Tunnistetietomenetelmä ei korvaa palvelimen identiteettiä, ja TLS-tarkistusten laskeminen testin läpäisemiseksi vaihtaa yhden ongelman pahempaan.

Vaihe 4: testaa kolme kirjautumista ja yksi käyttöoikeus

Testaa sallittu käyttäjä, väärä salasana ja suljettu käyttäjä, kukin tuoreessa istunnossa. Ensimmäinen todistaa polun, toinen todistaa, että tunnistetietojen tarkistus on todellinen, ja kolmas todistaa, että käytäntö sulkee edelleen ne, jotka sen pitää sulkea. Välimuistiin tallennettu istunto voi piilottaa kaikki kolme, joten katkaise yhteys yritysten välillä.

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

Todennuksen onnistuminen ei ole tarkistuslistan loppu. Tarkista osoite, jonka asiakas sai, ja resurssit, joihin se osoite voi päästä, koska käyttäjä voi todentaa oikein ja päätyä silti väärään pooliin. Jos annettu osoite on väärä, ongelma on profiilissa tai RADIUS-vastauksen määritteissä, ei menetelmässä. Vahvista molemmat ennen lipun sulkemista.

Tarkistuslista on valmis, kun reitittimen asetus ja NPS-käytäntö nimeävät saman menetelmän, yksi sallittu käyttäjä yhdistää tuoreella istunnolla, yksi väärä salasana hylätään, yksi suljettu käyttäjä pysyy suljettuna ja annettu osoite vastaa aiottua poolia. Kaikki vähemmän jättää seuraavan kirjautumisen sattuman varaan.