RouterOS OpenVPN e NPS: configura user-auth-method, non auth

RouterOS pode chegar a NPS cun inicio de sesión OpenVPN e aínda así ser rexeitado, e a causa habitual son dous axustes cuxos nomes soan ambos a autenticación. Un elixe un resumo criptográfico para o túnel; o outro decide como se presentan as credenciais do usuario a RADIUS. Cambiar o resumo nunca converterá unha solicitude PAP en MS-CHAPv2, por moitas veces que se reinicie o servizo. A lista de comprobación seguinte separa os dous e despois segue un único inicio de sesión fallido pola política de NPS que o xulgou.

Paso 1: le ambos os axustes antes de cambiar calquera

Imprime a configuración efectiva do servidor OpenVPN no router que remata o túnel, non desde unha copia de seguridade nin desde unha mensaxe de foro copiada. Os dous campos que che importan adoitan estar no mesmo menú e len coma se fosen alternativas. Non o son: un trata da canle de datos, o outro do intercambio de credenciais.

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

O campo auth enumera resumos como sha1 e sha256 e controla o HMAC que autentica os paquetes do túnel. O campo user-auth-method elixe pap ou mschap2 e decide como presenta o router as credenciais do usuario a RADIUS. Un cambio de resumo non pode alterar o segundo comportamento, e por iso o mesmo rexeitamento sobrevive a cada axuste do primeiro.

Detente aquí se a túa versión non expón user-auth-method en absoluto. As compilacións antigas de RouterOS poden non ofrecelo no servidor OpenVPN, e a solución pertence a unha versión que poidas soportar, non a un comando copiado dunha máis nova.

Paso 2: atopa a política que realmente rexeitou o inicio de sesión

No lado de NPS, unha solicitude de conexión avalíase contra as políticas de rede, e o método de autenticación indicado na política coincidente debe ser un que o cliente ofrecese realmente. Correlaciona un inicio de sesión fallido por hora e usuario en lugar de ler un reconto resumido. O rexistro de seguridade anota as solicitudes concedidas e denegadas cun código de motivo, o que che di moito máis que a liña xenérica de fallo do router.

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

Le tres cousas no evento: o nome da política coincidente, o método de autenticación e o código de motivo. Unha política que esixe MS-CHAPv2 rexeita unha solicitude PAP mesmo cando o contrasinal é correcto, e unha política que esixe unha conta de dominio rexeita unha local. A entrada de cliente RADIUS tamén debe coincidir co enderezo de orixe do router, ou a solicitude descártase antes de consultar calquera política. Nada diso aparece no rexistro de OpenVPN.

Detente aquí se a solicitude nunca chega a NPS. Iso é un problema de segredo compartido, enderezo de cliente ou UDP 1812, e cambiar os métodos de autenticación non o arranxará.

Paso 3: cambia un método, nos dous lados

Se o deseño aprobado é MS-CHAPv2, configúrao no router e confirma que a política coincidente o acepta. Cambia un lado, volve probar e despois cambia o outro; cambiar ambos á vez déixache sen poder dicir cal importaba.

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

Non actives todos os métodos máis febles en NPS para que o erro desapareza. O backend debe ter material que o método elixido poida verificar: MS-CHAPv2 necesita acceso ao contrasinal ou ao dominio, e unha política non pode inventar ese material. Ampliar a política tamén amplía o que un atacante pode intentar contra a mesma conta. Anota o método, o nome da política e a referencia do cambio xuntos, para que a seguinte persoa herde unha decisión e non unha suposición.

Deixa a validación do certificado do túnel exactamente como estaba. Un método de credenciais non substitúe a identidade do servidor, e baixar as comprobacións TLS para que pase unha proba cambia un problema por outro peor.

Paso 4: proba tres inicios de sesión e un permiso

Proba un usuario permitido, un contrasinal incorrecto e un usuario excluído, cada un nunha sesión nova. O primeiro demostra a ruta, o segundo demostra que a comprobación de credenciais é real e o terceiro demostra que a política segue excluíndo a quen debe. Unha sesión na caché pode ocultar os tres, así que desconéctate entre intentos.

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

O éxito da autenticación non é o final da lista. Comproba o enderezo que recibiu o cliente e os recursos que ese enderezo pode acadar, porque un usuario pode autenticarse correctamente e acabar igualmente no grupo incorrecto. Se o enderezo asignado é incorrecto, o problema está no perfil ou nos atributos de resposta RADIUS, non no método. Confirma ambas as cousas antes de pechar o ticket.

A lista está rematada cando o axuste do router e a política de NPS nomean o mesmo método, un usuario permitido se conecta cunha sesión nova, un contrasinal incorrecto se rexeita, un usuario excluído segue excluído e o enderezo asignado coincide co grupo previsto. Calquera cousa menos deixa o seguinte inicio de sesión ao azar.