RouterOS OpenVPN i NPS: defineix user-auth-method, no auth

RouterOS pot arribar a NPS amb un inici de sessió OpenVPN i tot i així ser rebutjat, i la causa habitual són dos paràmetres els noms dels quals sonen tots dos com a autenticació. Un tria un resum criptogràfic per al túnel; l'altre decideix com es presenten les credencials de l'usuari a RADIUS. Canviar el resum mai convertirà una sol·licitud PAP en MS-CHAPv2, per moltes vegades que es reiniciï el servei. La llista de verificació següent separa les dues coses i després segueix un únic inici de sessió fallit per la política de NPS que el va jutjar.

Pas 1: llegiu tots dos paràmetres abans de canviar-ne cap

Imprimiu la configuració efectiva del servidor OpenVPN al router que acaba el túnel, no des d'una còpia de seguretat ni d'un missatge de fòrum copiat. Els dos camps que us interessen solen ser al mateix menú i es llegeixen com si fossin alternatives. No ho són: un tracta del canal de dades, l'altre de l'intercanvi de credencials.

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

El camp auth llista resums com sha1 i sha256 i controla l'HMAC que autentica els paquets del túnel. El camp user-auth-method tria pap o mschap2 i decideix com el router presenta les credencials de l'usuari a RADIUS. Un canvi de resum no pot alterar el segon comportament, i per això el mateix rebuig sobreviu a cada ajust del primer.

Atureu-vos aquí si la vostra versió no exposa user-auth-method en absolut. Les compilacions més antigues de RouterOS poden no oferir-lo al servidor OpenVPN, i la solució pertany a una versió que pugueu suportar, no a una ordre copiada d'una de més nova.

Pas 2: trobeu la política que realment va rebutjar l'inici de sessió

Al costat de NPS, una sol·licitud de connexió s'avalua contra les polítiques de xarxa, i el mètode d'autenticació esmentat a la política coincident ha de ser un que el client hagi ofert realment. Correlacioneu un inici de sessió fallit per hora i usuari en lloc de llegir un recompte resumit. El registre de seguretat enregistra les sol·licituds concedides i denegades amb un codi de motiu, cosa que us diu molt més que la línia genèrica de fallada del router.

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

Llegiu tres coses a l'esdeveniment: el nom de la política coincident, el mètode d'autenticació i el codi de motiu. Una política que requereix MS-CHAPv2 rebutja una sol·licitud PAP fins i tot quan la contrasenya és correcta, i una política que requereix un compte de domini rebutja un de local. L'entrada de client RADIUS també ha de coincidir amb l'adreça d'origen del router, o la sol·licitud es descarta abans de consultar cap política. Res d'això no apareix al registre d'OpenVPN.

Atureu-vos aquí si la sol·licitud no arriba mai a NPS. Això és un problema de secret compartit, adreça de client o UDP 1812, i canviar els mètodes d'autenticació no ho arreglarà.

Pas 3: canvieu un mètode, als dos costats

Si el disseny aprovat és MS-CHAPv2, definiu-lo al router i confirmeu que la política coincident l'accepta. Canvieu un costat, torneu a provar i després canvieu l'altre; canviar tots dos alhora us deixa sense poder dir quin era el que importava.

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

No activeu tots els mètodes més febles a NPS perquè l'error desaparegui. El backend ha de tenir material que el mètode triat pugui verificar: MS-CHAPv2 necessita accés a la contrasenya o al domini, i una política no pot inventar aquest material. Ampliar la política també amplia el que un atacant pot provar contra el mateix compte. Anoteu el mètode, el nom de la política i la referència del canvi junts, perquè la propera persona hereti una decisió i no una conjectura.

Deixeu la validació del certificat del túnel exactament com era. Un mètode de credencials no substitueix la identitat del servidor, i baixar les comprovacions TLS per fer passar una prova canvia un problema per un de pitjor.

Pas 4: proveu tres inicis de sessió i un permís

Proveu un usuari permès, una contrasenya incorrecta i un usuari exclòs, cadascun en una sessió nova. El primer demostra el camí, el segon demostra que la comprovació de credencials és real i el tercer demostra que la política encara exclou qui ha d'excloure. Una sessió en memòria cau pot amagar els tres, així que desconnecteu entre intents.

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

L'èxit de l'autenticació no és el final de la llista. Comproveu l'adreça que ha rebut el client i els recursos que aquesta adreça pot assolir, perquè un usuari es pot autenticar correctament i acabar igualment al grup incorrecte. Si l'adreça assignada és incorrecta, el problema és al perfil o als atributs de resposta RADIUS, no al mètode. Confirmeu les dues coses abans de tancar el tiquet.

La llista s'acaba quan el paràmetre del router i la política de NPS anomenen el mateix mètode, un usuari permès es connecta amb una sessió nova, una contrasenya incorrecta es rebutja, un usuari exclòs continua exclòs i l'adreça assignada coincideix amb el grup previst. Qualsevol cosa menys deixa el proper inici de sessió a l'atzar.