RouterOS OpenVPN og NPS: sett user-auth-method, ikke auth

RouterOS kan nå NPS med en OpenVPN-innlogging og likevel bli avvist, og den vanlige årsaken er to innstillinger hvis navn begge høres ut som autentisering. Den ene velger en kryptografisk digest for tunnelen; den andre avgjør hvordan brukerens legitimasjon presenteres for RADIUS. En digestendring vil aldri gjøre en PAP-forespørsel om til MS-CHAPv2, uansett hvor ofte tjenesten starter på nytt. Sjekklisten nedenfor skiller de to, og følger deretter én mislykket innlogging gjennom NPS-policyen som vurderte den.

Trinn 1: les begge innstillingene før du endrer noen av dem

Skriv ut den effektive OpenVPN-serverkonfigurasjonen på ruteren som avslutter tunnelen, ikke fra en sikkerhetskopi eller et kopiert foruminnlegg. De to feltene du bryr deg om, står vanligvis i samme meny og leses som om de var alternativer. Det er de ikke: det ene handler om datakanalen, det andre om utvekslingen av legitimasjon.

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

Feltet auth lister opp digester som sha1 og sha256 og styrer HMAC-en som autentiserer tunnelpakker. Feltet user-auth-method velger pap eller mschap2 og avgjør hvordan ruteren presenterer brukerens legitimasjon for RADIUS. En digestendring kan ikke endre den andre atferden, og derfor overlever den samme avvisningen hver justering av den første.

Stopp her hvis versjonen din ikke eksponerer user-auth-method i det hele tatt. Eldre RouterOS-bygg tilbyr det kanskje ikke på OpenVPN-serveren, og rettelsen hører hjemme i en versjon du kan støtte, ikke i en kommando kopiert fra en nyere.

Trinn 2: finn policyen som faktisk avviste innloggingen

På NPS-siden vurderes en tilkoblingsforespørsel mot nettverkspolicyer, og autentiseringsmetoden som er navngitt i den samsvarende policyen, må være en klienten faktisk tilbød. Korreler én mislykket innlogging etter tid og bruker i stedet for å lese et samlet antall. Sikkerhetsloggen registrerer innvilgede og avviste forespørsler med en årsakskode, noe som forteller deg mye mer enn ruterens generiske feillinje.

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

Les tre ting i hendelsen: navnet på den samsvarende policyen, autentiseringsmetoden og årsakskoden. En policy som krever MS-CHAPv2, avviser en PAP-forespørsel selv når passordet er riktig, og en policy som krever en domenekonto, avviser en lokal. RADIUS-klientoppføringen må også samsvare med ruterens kildeadresse, ellers blir forespørselen droppet før noen policy konsulteres. Ingenting av dette vises i OpenVPN-loggen.

Stopp her hvis forespørselen aldri når NPS. Det er et problem med den delte hemmeligheten, klientadressen eller UDP 1812, og endring av autentiseringsmetoder vil ikke fikse det.

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

Hvis det godkjente designet er MS-CHAPv2, setter du det på ruteren og bekrefter at den samsvarende policyen godtar det. Endre den ene siden, test på nytt og endre deretter den andre; endrer du begge samtidig, kan du ikke si hvilken som betydde noe.

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

Ikke aktiver alle svakere metoder på NPS for å få feilen til å forsvinne. Backenden må ha materiale som den valgte metoden kan verifisere: MS-CHAPv2 trenger tilgang til passordet eller domenet, og en policy kan ikke finne opp det materialet. Å utvide policyen utvider også hva en angriper kan prøve mot den samme kontoen. Skriv ned metoden, policynavnet og endringsreferansen sammen, slik at neste person arver en beslutning i stedet for en gjetning.

Hold tunnelens sertifikatvalidering nøyaktig som den var. En legitimasjonsmetode er ikke en erstatning for serveridentitet, og å senke TLS-kontroller for å få en test til å bestå bytter ett problem mot et verre.

Trinn 4: test tre innlogginger og én tillatelse

Test en tillatt bruker, et feil passord og en utestengt bruker, hver i en fersk økt. Den første beviser veien, den andre beviser at legitimasjonskontrollen er ekte, og den tredje beviser at policyen fortsatt utestenger dem den skal. En bufret økt kan skjule alle tre, så koble fra mellom forsøkene.

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

Vellykket autentisering er ikke slutten på sjekklisten. Kontroller adressen klienten fikk, og ressursene den adressen kan nå, fordi en bruker kan autentisere riktig og likevel havne i feil basseng. Hvis den tildelte adressen er feil, ligger problemet i profilen eller i RADIUS-svarets attributter, ikke i metoden. Bekreft begge før du lukker saken.

Sjekklisten er ferdig når ruterinnstillingen og NPS-policyen navngir samme metode, én tillatt bruker kobler til med en fersk økt, ett feil passord avvises, én utestengt bruker fortsatt er utestengt, og den tildelte adressen samsvarer med det tiltenkte bassenget. Alt mindre overlater den neste innloggingen til tilfeldighetene.