RouterOS OpenVPN og NPS: set user-auth-method, ikkje auth

RouterOS kan nå NPS med ei OpenVPN-innlogging og likevel bli avvist, og den vanlege årsaka er to innstillingar der namna begge høyrest ut som autentisering. Den eine vel ein kryptografisk digest for tunnelen; den andre avgjer korleis brukaren si legitimasjon blir presentert for RADIUS. Ei digestendring vil aldri gjere ein PAP-førespurnad om til MS-CHAPv2, uansett kor ofte tenesta startar på nytt. Sjekklista nedanfor skil dei to, og følgjer deretter éi mislukka innlogging gjennom NPS-policyen som vurderte ho.

Trinn 1: les både innstillingane før du endrar nokon av dei

Skriv ut den effektive OpenVPN-serverkonfigurasjonen på rutaren som avsluttar tunnelen, ikkje frå ein sikkerheitskopi eller eit kopiert foruminnlegg. Dei to felta du bryr deg om, står vanlegvis i same meny og blir lesne som om dei var alternativ. Det er dei ikkje: det eine handlar om datakanalen, det andre om utvekslinga av legitimasjon.

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

Feltet auth listar opp digestar som sha1 og sha256 og styrer HMAC-en som autentiserer tunnelpakkar. Feltet user-auth-method vel pap eller mschap2 og avgjer korleis rutaren presenterer brukaren sin legitimasjon for RADIUS. Ei digestendring kan ikkje endre den andre åtferda, og difor overlever den same avvisinga kvar justering av den første.

Stopp her viss versjonen din ikkje eksponerer user-auth-method i det heile. Eldre RouterOS-bygg tilbyr det kanskje ikkje på OpenVPN-serveren, og rettinga høyrer heime i ein versjon du kan støtte, ikkje i ein kommando kopiert frå ein nyare.

Trinn 2: finn policyen som faktisk avviste innlogginga

På NPS-sida blir ein tilkoplingsførespurnad vurdert mot nettverkspolicyar, og autentiseringsmetoden som er namngitt i den samsvarande policyen, må vere ein klienten faktisk tilbaud. Korreler éi mislukka innlogging etter tid og brukar i staden for å lese eit samla tal. Tryggleiksloggen registrerer innvilga og avviste førespurnader med ein årsakskode, noko som fortel deg mykje meir enn den generiske feillinja til rutaren.

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

Les tre ting i hendinga: namnet på den samsvarande policyen, autentiseringsmetoden og årsakskoden. Ein policy som krev MS-CHAPv2, avviser ein PAP-førespurnad sjølv når passordet er rett, og ein policy som krev ein domenekonto, avviser ein lokal. RADIUS-klientoppføringa må også samsvare med kjeldeadressa til rutaren, elles blir førespurnaden droppa før nokon policy blir konsultert. Ingenting av dette viser seg i OpenVPN-loggen.

Stopp her viss førespurnaden aldri når NPS. Det er eit problem med den delte løyndomen, klientadressa eller UDP 1812, og endring av autentiseringsmetodar vil ikkje rette det.

Trinn 3: endre éin metode, på begge sider

Viss det godkjende designet er MS-CHAPv2, set det på rutaren og stadfest at den samsvarande policyen godtek det. Endre den eine sida, test på nytt og endre deretter den andre; endrar du begge samtidig, kan du ikkje seie kva som betydde noko.

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

Ikkje aktiver alle svakare metodar på NPS for å få feilen til å forsvinne. Backenden må ha materiale som den valde metoden kan verifisere: MS-CHAPv2 treng tilgang til passordet eller domenet, og ein policy kan ikkje finne opp det materialet. Å utvide policyen utvidar også kva ein åtakar kan prøve mot den same kontoen. Skriv ned metoden, policynamnet og endringsreferansen saman, slik at neste person arvar ei avgjerd i staden for ei gjetting.

Hald sertifikatvalideringa til tunnelen nøyaktig som ho var. Ein legitimasjonsmetode er ikkje ei erstatning for serveridentitet, og å senke TLS-kontrollar for å få ein test til å gå gjennom byter eitt problem mot eit verre.

Trinn 4: test tre innloggingar og éi tillating

Test ein tillaten brukar, eit feil passord og ein utestengd brukar, kvar i ei fersk økt. Den første beviser vegen, den andre beviser at legitimasjonskontrollen er ekte, og den tredje beviser at policyen framleis stenger ute dei han skal. Ei bufra økt kan skjule alle tre, så kople frå mellom forsøka.

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

Vellykka autentisering er ikkje slutten på sjekklista. Kontroller adressa klienten fekk, og ressursane den adressa kan nå, fordi ein brukar kan autentisere rett og likevel hamne i feil basseng. Viss den tildelte adressa er feil, ligg problemet i profilen eller i RADIUS-svaret sine attributtar, ikkje i metoden. Stadfest begge før du lukkar saka.

Sjekklista er ferdig når ruterinnstillinga og NPS-policyen namngir same metode, éin tillaten brukar koplar til med ei fersk økt, eitt feil passord blir avvist, éin utestengd brukar framleis er utestengd, og den tildelte adressa samsvarar med det tiltenkte bassenget. Alt mindre overlèt den neste innlogginga til tilfeldet.