RouterOS OpenVPN och NPS: ställ in user-auth-method, inte auth

RouterOS kan nå NPS med en OpenVPN-inloggning och ändå bli avvisad, och den vanliga orsaken är två inställningar vars namn båda låter som autentisering. Den ena väljer en kryptografisk digest för tunneln; den andra avgör hur användarens autentiseringsuppgifter presenteras för RADIUS. En digeständring gör aldrig en PAP-förfrågan till MS-CHAPv2, oavsett hur ofta tjänsten startas om. Checklistan nedan skiljer de två åt och följer sedan en enda misslyckad inloggning genom NPS-policyn som bedömde den.

Steg 1: läs båda inställningarna innan du ändrar någon av dem

Skriv ut den effektiva OpenVPN-serverkonfigurationen på routern som avslutar tunneln, inte från en säkerhetskopia eller ett kopierat foruminlägg. De två fält du bryr dig om står vanligtvis i samma meny och läses som om de vore alternativ. Det är de inte: den ena handlar om datakanalen, den andra om utbytet av autentiseringsuppgifter.

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

Fältet auth listar digestar som sha1 och sha256 och styr HMAC:n som autentiserar tunnelpaket. Fältet user-auth-method väljer pap eller mschap2 och avgör hur routern presenterar användarens autentiseringsuppgifter för RADIUS. En digeständring kan inte ändra det andra beteendet, och därför överlever samma avvisning varje justering av det första.

Stanna här om din version inte exponerar user-auth-method alls. Äldre RouterOS-byggen erbjuder det kanske inte på OpenVPN-servern, och rättelsen hör hemma i en version du kan stödja, inte i ett kommando kopierat från en nyare.

Steg 2: hitta policyn som faktiskt avvisade inloggningen

På NPS-sidan utvärderas en anslutningsförfrågan mot nätverkspolicies, och autentiseringsmetoden som anges i den matchande policyn måste vara en som klienten faktiskt erbjöd. Korrelera en misslyckad inloggning efter tid och användare i stället för att läsa ett sammanlagt antal. Säkerhetsloggen registrerar beviljade och nekade förfrågningar med en orsakskod, vilket säger dig mycket mer än routerns allmänna felrad.

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

Läs tre saker i händelsen: namnet på den matchande policyn, autentiseringsmetoden och orsakskoden. En policy som kräver MS-CHAPv2 avvisar en PAP-förfrågan även när lösenordet är korrekt, och en policy som kräver ett domänkonto avvisar ett lokalt. RADIUS-klientposten måste också matcha routerns källadress, annars släpps förfrågan innan någon policy konsulteras. Inget av detta visas i OpenVPN-loggen.

Stanna här om förfrågan aldrig når NPS. Det är ett problem med den delade hemligheten, klientadressen eller UDP 1812, och att ändra autentiseringsmetoder löser det inte.

Steg 3: ändra en metod, på båda sidor

Om den godkända designen är MS-CHAPv2 ställer du in det på routern och bekräftar att den matchande policyn accepterar det. Ändra ena sidan, testa igen och ändra sedan den andra; att ändra båda samtidigt gör att du inte kan säga vilken som spelade roll.

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

Aktivera inte varje svagare metod på NPS för att få felet att försvinna. Backend måste ha material som den valda metoden kan verifiera: MS-CHAPv2 behöver åtkomst till lösenordet eller domänen, och en policy kan inte hitta på det materialet. Att vidga policyn vidgar också vad en angripare kan försöka mot samma konto. Skriv ner metoden, policyns namn och ändringsreferensen tillsammans, så att nästa person ärver ett beslut i stället för en gissning.

Låt tunnelns certifikatvalidering vara exakt som den var. En autentiseringsmetod ersätter inte serveridentitet, och att sänka TLS-kontroller för att få ett test att passera byter ett problem mot ett värre.

Steg 4: testa tre inloggningar och ett tillstånd

Testa en tillåten användare, ett felaktigt lösenord och en utesluten användare, var och en i en ny session. Den första bevisar vägen, den andra bevisar att autentiseringskontrollen är verklig och den tredje bevisar att policyn fortfarande utesluter dem den ska. En cachad session kan dölja alla tre, så koppla från mellan försöken.

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

Lyckad autentisering är inte slutet på checklistan. Kontrollera adressen som klienten fick och de resurser som den adressen kan nå, eftersom en användare kan autentisera korrekt och ändå hamna i fel pool. Om den tilldelade adressen är fel ligger problemet i profilen eller i RADIUS-svarets attribut, inte i metoden. Bekräfta båda innan du stänger ärendet.

Checklistan är klar när routerinställningen och NPS-policyn anger samma metod, en tillåten användare ansluter med en ny session, ett felaktigt lösenord avvisas, en utesluten användare fortfarande är utesluten och den tilldelade adressen matchar den avsedda poolen. Allt mindre överlämnar nästa inloggning åt slumpen.