RouterOS OpenVPN et NPS : définir user-auth-method, pas auth

Sous RouterOS, auth choisit le condensat du tunnel tandis que user-auth-method décide comment la requête RADIUS est vérifiée. Alignez le second sur la stratégie NPS.

RouterOS peut joindre NPS avec une connexion OpenVPN et être quand même rejeté, et la cause habituelle est deux réglages dont les noms sonnent tous deux comme authentification. L'un choisit un condensat cryptographique pour le tunnel ; l'autre décide comment les identifiants de l'utilisateur sont présentés à RADIUS. Changer le condensat ne transformera jamais une requête PAP en MS-CHAPv2, quel que soit le nombre de redémarrages du service. La liste ci-dessous sépare les deux, puis suit une seule connexion échouée à travers la stratégie NPS qui l'a jugée.

Étape 1 : lisez les deux réglages avant d'en changer un seul

Affichez la configuration effective du serveur OpenVPN sur le routeur qui termine le tunnel, pas depuis une sauvegarde ni un message de forum recopié. Les deux champs qui vous intéressent se trouvent généralement dans le même menu et se lisent comme s'ils étaient des alternatives. Ils ne le sont pas : l'un concerne le canal de données, l'autre l'échange des identifiants.

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

Le champ auth énumère des condensats comme sha1 et sha256 et pilote le HMAC qui authentifie les paquets du tunnel. Le champ user-auth-method choisit pap ou mschap2 et décide comment le routeur présente les identifiants de l'utilisateur à RADIUS. Un changement de condensat ne peut pas modifier le second comportement, et c'est pourquoi le même rejet survit à chaque ajustement du premier.

Arrêtez-vous ici si votre version n'expose pas du tout user-auth-method. Les anciennes versions de RouterOS peuvent ne pas l'offrir sur le serveur OpenVPN, et le correctif appartient à une version que vous pouvez prendre en charge, pas à une commande copiée d'une version plus récente.

Étape 2 : trouvez la stratégie qui a réellement rejeté la connexion

Côté NPS, une demande de connexion est évaluée par rapport aux stratégies réseau, et la méthode d'authentification nommée dans la stratégie correspondante doit être l'une de celles que le client a réellement proposées. Corrélez une connexion échouée par heure et par utilisateur au lieu de lire un décompte global. Le journal de sécurité enregistre les demandes accordées et refusées avec un code de motif, ce qui vous en dit bien plus que la ligne d'échec générique du routeur.

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

Lisez trois choses dans l'événement : le nom de la stratégie correspondante, la méthode d'authentification et le code de motif. Une stratégie qui exige MS-CHAPv2 rejette une requête PAP même lorsque le mot de passe est correct, et une stratégie qui exige un compte de domaine rejette un compte local. L'entrée de client RADIUS doit aussi correspondre à l'adresse source du routeur, sinon la demande est abandonnée avant que la moindre stratégie soit consultée. Rien de cela n'apparaît dans le journal OpenVPN.

Arrêtez-vous ici si la demande n'atteint jamais NPS. C'est un problème de secret partagé, d'adresse de client ou d'UDP 1812, et changer les méthodes d'authentification ne le réglera pas.

Étape 3 : changez une méthode, des deux côtés

Si la conception approuvée est MS-CHAPv2, définissez-la sur le routeur et confirmez que la stratégie correspondante l'accepte. Changez un côté, retestez, puis changez l'autre ; changer les deux à la fois vous empêche de dire lequel comptait.

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

N'activez pas toutes les méthodes plus faibles sur NPS pour faire disparaître l'erreur. Le backend doit détenir la matière que la méthode choisie peut vérifier : MS-CHAPv2 a besoin d'un accès au mot de passe ou au domaine, et une stratégie ne peut pas inventer cette matière. Élargir la stratégie élargit aussi ce qu'un attaquant peut tenter contre le même compte. Consignez ensemble la méthode, le nom de la stratégie et la référence du changement, afin que la personne suivante hérite d'une décision et non d'une supposition.

Laissez la validation du certificat du tunnel exactement comme elle était. Une méthode d'identifiants ne remplace pas l'identité du serveur, et abaisser les contrôles TLS pour faire passer un test échange un problème contre un pire.

Étape 4 : testez trois connexions et une autorisation

Testez un utilisateur autorisé, un mauvais mot de passe et un utilisateur exclu, chacun dans une session neuve. Le premier prouve le chemin, le second prouve que la vérification des identifiants est réelle, et le troisième prouve que la stratégie exclut toujours qui elle doit. Une session en cache peut masquer les trois, alors déconnectez-vous entre les tentatives.

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

Le succès de l'authentification n'est pas la fin de la liste. Vérifiez l'adresse reçue par le client et les ressources que cette adresse peut atteindre, car un utilisateur peut s'authentifier correctement et atterrir quand même dans le mauvais pool. Si l'adresse attribuée est erronée, le problème se situe dans le profil ou dans les attributs de réponse RADIUS, pas dans la méthode. Confirmez les deux avant de clôturer le ticket.

La liste est terminée lorsque le réglage du routeur et la stratégie NPS nomment la même méthode, qu'un utilisateur autorisé se connecte avec une session neuve, qu'un mauvais mot de passe est rejeté, qu'un utilisateur exclu reste exclu et que l'adresse attribuée correspond au pool prévu. Tout ce qui est moins laisse la prochaine connexion au hasard.

Articles similaires