RouterOS OpenVPN en NPS: stel user-auth-method in, niet auth

RouterOS kan NPS bereiken met een OpenVPN-login en toch worden geweigerd, en de gebruikelijke oorzaak zijn twee instellingen waarvan de namen allebei naar authenticatie klinken. De ene kiest een cryptografische digest voor de tunnel; de andere bepaalt hoe de inloggegevens van de gebruiker aan RADIUS worden gepresenteerd. Een digestwijziging maakt van een PAP-verzoek nooit MS-CHAPv2, hoe vaak de dienst ook opnieuw start. De checklist hieronder scheidt de twee en volgt daarna één mislukte login door het NPS-beleid dat erover oordeelde.

Stap 1: lees beide instellingen voordat je er een wijzigt

Druk de effectieve OpenVPN-serverconfiguratie af op de router die de tunnel beëindigt, niet uit een back-up of een gekopieerde forumpost. De twee velden die ertoe doen, staan meestal in hetzelfde menu en lezen alsof het alternatieven zijn. Dat zijn ze niet: het ene gaat over het datakanaal, het andere over de uitwisseling van inloggegevens.

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

Het veld auth somt digests op zoals sha1 en sha256 en bestuurt de HMAC die tunnelpakketten authenticiteert. Het veld user-auth-method kiest pap of mschap2 en bepaalt hoe de router de inloggegevens van de gebruiker aan RADIUS presenteert. Een digestwijziging kan het tweede gedrag niet veranderen, en daarom overleeft dezelfde weigering elke aanpassing van het eerste.

Stop hier als je release user-auth-method helemaal niet aanbiedt. Oudere RouterOS-builds bieden het misschien niet aan op de OpenVPN-server, en de oplossing hoort in een release die je kunt ondersteunen, niet in een commando dat uit een nieuwere is gekopieerd.

Stap 2: vind het beleid dat de login werkelijk heeft geweigerd

Aan de NPS-kant wordt een verbindingsverzoek beoordeeld tegen netwerkbeleid, en de authenticatiemethode die in het overeenkomende beleid wordt genoemd, moet er een zijn die de client werkelijk heeft aangeboden. Corroleer één mislukte login op tijd en gebruiker in plaats van een samenvattend aantal te lezen. Het beveiligingslog registreert toegekende en geweigerde verzoeken met een redencode, wat je veel meer vertelt dan de algemene foutregel van de router.

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

Lees drie dingen in de gebeurtenis: de naam van het overeenkomende beleid, de authenticatiemethode en de redencode. Een beleid dat MS-CHAPv2 vereist, weigert een PAP-verzoek zelfs wanneer het wachtwoord juist is, en een beleid dat een domeinaccount vereist, weigert een lokaal account. De RADIUS-clientvermelding moet ook overeenkomen met het bronadres van de router, anders wordt het verzoek verworpen voordat welk beleid dan ook wordt geraadpleegd. Niets daarvan verschijnt in het OpenVPN-log.

Stop hier als het verzoek NPS nooit bereikt. Dat is een probleem met het gedeelde geheim, het clientadres of UDP 1812, en het wijzigen van authenticatiemethoden lost dat niet op.

Stap 3: wijzig één methode, aan beide kanten

Als het goedgekeurde ontwerp MS-CHAPv2 is, stel het dan in op de router en bevestig dat het overeenkomende beleid het accepteert. Wijzig één kant, test opnieuw en wijzig dan de andere; beide tegelijk wijzigen laat je niet zeggen welke ertoe deed.

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

Schakel niet elke zwakkere methode op NPS in om de fout te laten verdwijnen. De backend moet materiaal hebben dat de gekozen methode kan verifiëren: MS-CHAPv2 heeft toegang tot het wachtwoord of het domein nodig, en een beleid kan dat materiaal niet verzinnen. Het beleid verbreden verbreedt ook wat een aanvaller tegen hetzelfde account kan proberen. Noteer de methode, de naam van het beleid en de wijzigingsreferentie samen, zodat de volgende persoon een beslissing erft en geen gok.

Laat de certificaatvalidatie van de tunnel precies zoals ze was. Een inloggegevensmethode vervangt de serveridentiteit niet, en TLS-controles verlagen om een test te laten slagen, ruilt één probleem voor een erger.

Stap 4: test drie logins en één toestemming

Test een toegestane gebruiker, een verkeerd wachtwoord en een uitgesloten gebruiker, elk in een nieuwe sessie. De eerste bewijst het pad, de tweede bewijst dat de inloggegevenscontrole echt is, en de derde bewijst dat het beleid nog steeds uitsluit wie het moet. Een gecachte sessie kan alle drie verbergen, dus verbreek de verbinding tussen pogingen.

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

Succesvolle authenticatie is niet het einde van de checklist. Controleer het adres dat de client heeft gekregen en de bronnen die dat adres kan bereiken, want een gebruiker kan correct authenticeren en toch in de verkeerde pool belanden. Als het toegewezen adres verkeerd is, zit het probleem in het profiel of in de RADIUS-antwoordattributen, niet in de methode. Bevestig beide voordat je het ticket sluit.

De checklist is klaar wanneer de routerinstelling en het NPS-beleid dezelfde methode noemen, één toegestane gebruiker verbindt met een nieuwe sessie, één verkeerd wachtwoord wordt geweigerd, één uitgesloten gebruiker nog steeds is uitgesloten en het toegewezen adres bij de bedoelde pool past. Alles minder laat de volgende login aan het toeval over.