RouterOS OpenVPN e NPS: defina user-auth-method, não auth

O RouterOS pode alcançar o NPS com um login OpenVPN e ainda assim ser rejeitado, e a causa habitual são duas configurações cujos nomes soam ambos a autenticação. Uma escolhe um digest criptográfico para o túnel; a outra decide como as credenciais do usuário são apresentadas ao RADIUS. Alterar o digest nunca transformará uma solicitação PAP em MS-CHAPv2, por quantas vezes o serviço reinicie. A lista de verificação abaixo separa as duas e depois segue um único login com falha pela política do NPS que o julgou.

Passo 1: leia as duas configurações antes de alterar qualquer uma

Imprima a configuração efetiva do servidor OpenVPN no roteador que termina o túnel, não a partir de um backup ou de uma postagem de fórum copiada. Os dois campos que importam costumam ficar no mesmo menu e são lidos como se fossem alternativas. Não são: um trata do canal de dados, o outro da troca de credenciais.

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

O campo auth lista digests como sha1 e sha256 e controla o HMAC que autentica os pacotes do túnel. O campo user-auth-method escolhe pap ou mschap2 e decide como o roteador apresenta as credenciais do usuário ao RADIUS. Uma mudança de digest não pode alterar o segundo comportamento, e é por isso que a mesma rejeição sobrevive a cada ajuste do primeiro.

Pare aqui se a sua versão não expõe user-auth-method de forma alguma. Compilações mais antigas do RouterOS podem não oferecê-lo no servidor OpenVPN, e a correção pertence a uma versão que você possa suportar, não a um comando copiado de uma mais nova.

Passo 2: encontre a política que realmente rejeitou o login

No lado do NPS, uma solicitação de conexão é avaliada em relação às políticas de rede, e o método de autenticação indicado na política correspondente deve ser um que o cliente realmente ofereceu. Correlacione um login com falha por hora e usuário em vez de ler uma contagem resumida. O log de segurança registra as solicitações concedidas e negadas com um código de motivo, o que lhe diz muito mais do que a linha genérica de falha do roteador.

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

Leia três coisas no evento: o nome da política correspondente, o método de autenticação e o código de motivo. Uma política que exige MS-CHAPv2 rejeita uma solicitação PAP mesmo quando a senha está correta, e uma política que exige uma conta de domínio rejeita uma local. A entrada de cliente RADIUS também deve corresponder ao endereço de origem do roteador, ou a solicitação é descartada antes de qualquer política ser consultada. Nada disso aparece no log do OpenVPN.

Pare aqui se a solicitação nunca chega ao NPS. Isso é um problema de segredo compartilhado, endereço de cliente ou UDP 1812, e alterar os métodos de autenticação não o resolverá.

Passo 3: altere um método, nos dois lados

Se o projeto aprovado é MS-CHAPv2, defina-o no roteador e confirme que a política correspondente o aceita. Altere um lado, teste novamente e depois altere o outro; alterar os dois de uma vez deixa você sem saber qual importava.

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

Não habilite todos os métodos mais fracos no NPS para fazer o erro desaparecer. O backend precisa ter material que o método escolhido possa verificar: o MS-CHAPv2 exige acesso à senha ou ao domínio, e uma política não pode inventar esse material. Ampliar a política também amplia o que um atacante pode tentar contra a mesma conta. Registre o método, o nome da política e a referência da alteração juntos, para que a próxima pessoa herde uma decisão e não um palpite.

Deixe a validação do certificado do túnel exatamente como estava. Um método de credenciais não substitui a identidade do servidor, e baixar as verificações TLS para fazer um teste passar troca um problema por outro pior.

Passo 4: teste três logins e uma permissão

Teste um usuário permitido, uma senha errada e um usuário excluído, cada um em uma sessão nova. O primeiro prova o caminho, o segundo prova que a verificação de credenciais é real e o terceiro prova que a política ainda exclui quem deve. Uma sessão em cache pode esconder os três, então desconecte entre as tentativas.

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

O sucesso da autenticação não é o fim da lista de verificação. Verifique o endereço que o cliente recebeu e os recursos que esse endereço pode alcançar, porque um usuário pode autenticar corretamente e ainda assim cair no pool errado. Se o endereço atribuído estiver errado, o problema está no perfil ou nos atributos da resposta RADIUS, não no método. Confirme os dois antes de fechar o ticket.

A lista está concluída quando a configuração do roteador e a política do NPS nomeiam o mesmo método, um usuário permitido se conecta com uma sessão nova, uma senha errada é rejeitada, um usuário excluído continua excluído e o endereço atribuído corresponde ao pool pretendido. Qualquer coisa menos que isso deixa o próximo login ao acaso.