RouterOS OpenVPN og NPS: sæt user-auth-method, ikke auth

RouterOS kan nå NPS med et OpenVPN-login og alligevel blive afvist, og den sædvanlige årsag er to indstillinger, hvis navne begge lyder som autentificering. Den ene vælger en kryptografisk digest til tunnelen; den anden afgør, hvordan brugerens legitimationsoplysninger præsenteres for RADIUS. Ændring af digesten gør aldrig en PAP-anmodning til MS-CHAPv2, uanset hvor ofte tjenesten genstarter. Tjeklisten nedenfor adskiller de to og følger derefter et enkelt mislykket login gennem den NPS-politik, der vurderede det.

Trin 1: læs begge indstillinger, før du ændrer nogen af dem

Udskriv den effektive OpenVPN-serverkonfiguration på den router, der afslutter tunnelen, ikke fra en sikkerhedskopi eller et kopieret forumindlæg. De to felter, du interesserer dig for, står normalt i samme menu og læses, som om de var alternativer. Det er de ikke: det ene handler om datakanalen, det andet om udvekslingen af legitimationsoplysninger.

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

Feltet auth viser digests som sha1 og sha256 og styrer den HMAC, der autentificerer tunnelpakker. Feltet user-auth-method vælger pap eller mschap2 og afgør, hvordan routeren præsenterer brugerens legitimationsoplysninger for RADIUS. En digestændring kan ikke ændre den anden adfærd, og derfor overlever den samme afvisning enhver justering af den første.

Stop her, hvis din version slet ikke eksponerer user-auth-method. Ældre RouterOS-builds tilbyder det måske ikke på OpenVPN-serveren, og rettelsen hører til en version, du kan understøtte, ikke i en kommando kopieret fra en nyere.

Trin 2: find den politik, der faktisk afviste login

På NPS-siden vurderes en forbindelsesanmodning mod netværkspolitikker, og den godkendelsesmetode, der er nævnt i den matchende politik, skal være en, klienten faktisk tilbød. Korrelér et enkelt mislykket login efter tid og bruger i stedet for at læse et samlet antal. Sikkerhedsloggen registrerer tilladte og afviste anmodninger med en årsagskode, hvilket fortæller dig langt mere end routerens generiske fejlmeddelelse.

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

Læs tre ting i hændelsen: navnet på den matchende politik, godkendelsesmetoden og årsagskoden. En politik, der kræver MS-CHAPv2, afviser en PAP-anmodning, selv når adgangskoden er korrekt, og en politik, der kræver en domænekonto, afviser en lokal. RADIUS-klientposten skal også matche routerens kildeaddresse, ellers droppes anmodningen, før nogen politik konsulteres. Intet af det vises i OpenVPN-loggen.

Stop her, hvis anmodningen aldrig når NPS. Det er et problem med den delte hemmelighed, klientadressen eller UDP 1812, og ændring af godkendelsesmetoder løser det ikke.

Trin 3: ændr én metode på begge sider

Hvis det godkendte design er MS-CHAPv2, skal du indstille det på routeren og bekræfte, at den matchende politik accepterer det. Ændr den ene side, test igen, og ændr derefter den anden; ændrer du begge på én gang, kan du ikke sige, hvilken der betød noget.

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

Aktivér ikke enhver svagere metode på NPS for at få fejlen til at forsvinde. Backenden skal have materiale, som den valgte metode kan verificere: MS-CHAPv2 kræver adgang til adgangskoden eller domænet, og en politik kan ikke opfinde det materiale. At udvide politikken udvider også, hvad en angriber kan forsøge mod den samme konto. Skriv metoden, politiknavnet og ændringsreferencen ned sammen, så den næste person arver en beslutning i stedet for en gættegang.

Behold tunnelens certifikatvalidering præcis som den var. En legitimationsmetode erstatter ikke serveridentitet, og at sænke TLS-kontroller for at få en test til at bestå bytter et problem for et værre.

Trin 4: test tre logins og én tilladelse

Test en tilladt bruger, en forkert adgangskode og en udelukket bruger, hver i en frisk session. Den første beviser stien, den anden beviser, at legitimationskontrollen er reel, og den tredje beviser, at politikken stadig udelukker dem, den skal. En cachelagret session kan skjule alle tre, så afbryd mellem forsøgene.

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

Vellykket godkendelse er ikke slutningen på tjeklisten. Kontroller den adresse, klienten fik, og de ressourcer, som den adresse kan nå, fordi en bruger kan godkende korrekt og alligevel ende i den forkerte pulje. Hvis den tildelte adresse er forkert, ligger problemet i profilen eller i RADIUS-svarets attributter, ikke i metoden. Bekræft begge, før du lukker sagen.

Tjeklisten er færdig, når routerindstillingen og NPS-politikken angiver den samme metode, én tilladt bruger forbinder med en frisk session, én forkert adgangskode afvises, én udelukket bruger stadig er udelukket, og den tildelte adresse matcher den tilsigtede pulje. Alt mindre overlader det næste login til tilfældet.