RouterOS OpenVPN și NPS: setați user-auth-method, nu auth

În RouterOS, auth alege digestul tunelului, iar user-auth-method decide cum este verificată cererea RADIUS. Aliniați al doilea cu politica NPS.

RouterOS poate ajunge la NPS cu o autentificare OpenVPN și totuși fi respins, iar cauza obișnuită sunt două setări ale căror nume sună amândouă ca autentificare. Una alege un digest criptografic pentru tunel; cealaltă decide cum sunt prezentate acreditările utilizatorului către RADIUS. Schimbarea digestului nu va transforma niciodată o cerere PAP în MS-CHAPv2, indiferent de câte ori repornește serviciul. Lista de verificare de mai jos separă cele două, apoi urmărește o singură autentificare eșuată prin politica NPS care a judecat-o.

Pasul 1: citiți ambele setări înainte de a schimba vreuna

Tipăriți configurația efectivă a serverului OpenVPN pe routerul care termină tunelul, nu dintr-o copie de siguranță sau dintr-o postare de forum copiată. Cele două câmpuri care vă interesează stau de obicei în același meniu și se citesc ca și cum ar fi alternative. Nu sunt: unul privește canalul de date, celălalt schimbul de acreditări.

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

Câmpul auth listează digesturi precum sha1 și sha256 și controlează HMAC-ul care autentifică pachetele tunelului. Câmpul user-auth-method alege pap sau mschap2 și decide cum prezintă routerul acreditările utilizatorului către RADIUS. O schimbare de digest nu poate modifica al doilea comportament, motiv pentru care aceeași respingere supraviețuiește fiecărei ajustări a primului.

Opriți-vă aici dacă versiunea dumneavoastră nu expune deloc user-auth-method. Compilările mai vechi de RouterOS s-ar putea să nu îl ofere pe serverul OpenVPN, iar remedierea aparține unei versiuni pe care o puteți susține, nu unei comenzi copiate dintr-una mai nouă.

Pasul 2: găsiți politica ce a respins efectiv autentificarea

Pe partea NPS, o cerere de conexiune este evaluată față de politicile de rețea, iar metoda de autentificare menționată în politica potrivită trebuie să fie una pe care clientul a oferit-o efectiv. Corelați o singură autentificare eșuată după oră și utilizator în loc să citiți un număr sumar. Jurnalul de securitate înregistrează cererile acordate și refuzate cu un cod de motiv, ceea ce vă spune mult mai mult decât linia generică de eroare a routerului.

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

Citiți trei lucruri în eveniment: numele politicii potrivite, metoda de autentificare și codul de motiv. O politică ce cere MS-CHAPv2 respinge o cerere PAP chiar și când parola este corectă, iar o politică ce cere un cont de domeniu respinge unul local. Intrarea de client RADIUS trebuie să corespundă și adresei sursă a routerului, altfel cererea este eliminată înainte de a fi consultată vreo politică. Nimic din toate acestea nu apare în jurnalul OpenVPN.

Opriți-vă aici dacă cererea nu ajunge niciodată la NPS. Este o problemă de secret partajat, adresă de client sau UDP 1812, iar schimbarea metodelor de autentificare nu o va rezolva.

Pasul 3: schimbați o metodă, pe ambele părți

Dacă proiectul aprobat este MS-CHAPv2, setați-l pe router și confirmați că politica potrivită îl acceptă. Schimbați o parte, retestați, apoi schimbați cealaltă; schimbarea ambelor simultan vă lasă incapabil să spuneți care a contat.

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

Nu activați fiecare metodă mai slabă pe NPS pentru ca eroarea să dispară. Backendul trebuie să dețină material pe care metoda aleasă îl poate verifica: MS-CHAPv2 are nevoie de acces la parolă sau la domeniu, iar o politică nu poate inventa acel material. Lărgirea politicii lărgește și ce poate încerca un atacator împotriva aceluiași cont. Înregistrați împreună metoda, numele politicii și referința schimbării, pentru ca următoarea persoană să moștenească o decizie, nu o presupunere.

Lăsați validarea certificatului tunelului exact cum era. O metodă de acreditări nu înlocuiește identitatea serverului, iar scăderea verificărilor TLS pentru ca un test să treacă schimbă o problemă cu una mai rea.

Pasul 4: testați trei autentificări și o permisiune

Testați un utilizator permis, o parolă greșită și un utilizator exclus, fiecare într-o sesiune nouă. Primul dovedește calea, al doilea dovedește că verificarea acreditărilor este reală, iar al treilea dovedește că politica îi exclude în continuare pe cei care trebuie. O sesiune din cache poate ascunde toate trei, așa că deconectați-vă între încercări.

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

Succesul autentificării nu este sfârșitul listei. Verificați adresa primită de client și resursele pe care acea adresă le poate atinge, deoarece un utilizator se poate autentifica corect și totuși ajunge în pool-ul greșit. Dacă adresa atribuită este greșită, problema este în profil sau în atributele răspunsului RADIUS, nu în metodă. Confirmați ambele înainte de a închide tichetul.

Lista este completă când setarea routerului și politica NPS numesc aceeași metodă, un utilizator permis se conectează cu o sesiune nouă, o parolă greșită este respinsă, un utilizator exclus rămâne exclus și adresa atribuită corespunde pool-ului dorit. Orice mai puțin lasă următoarea autentificare la voia întâmplării.

Articole similare