Quelle adresse enregistrez-vous comme client RADIUS pour NPS ?

Une passerelle VPN qui délègue l'authentification à Windows NPS a besoin d'un objet côté NPS avant qu'une politique utilisateur puisse s'exécuter : une entrée de client RADIUS pour la passerelle. La plupart des tentatives échouées enregistrent la mauvaise adresse, car l'adresse qui compte est celle que la passerelle utilise sur son chemin backend, et non le nom d'hôte que le personnel saisit dans son application VPN. Si cette valeur est fausse, NPS écarte la requête en silence, ce qui, côté client, ressemble à un mot de passe erroné. Trois conditions décident quelle adresse appartient au champ, alors tranchez-les avant d'ouvrir la console.

Enregistrez la passerelle, pas les portables ni le pool

L'objet client RADIUS représente l'équipement d'accès réseau qui envoie les requêtes d'authentification. C'est la passerelle VPN, pas chaque portable exécutant le client, ni la plage d'adresses distribuées à l'intérieur des tunnels.

Ces adresses de tunnel n'apparaissent jamais comme source d'une requête RADIUS, car la requête emprunte le chemin réseau propre à la passerelle. Enregistrer une entrée de pool de clients produit une politique qui ne peut jamais correspondre, tandis que la vraie requête arrive d'une adresse dont NPS n'a jamais entendu parler. La même confusion pousse à ajouter l'IP domestique de chaque salarié, ce qui est à la fois ingérable et faux.

Trois conditions décident de l'adresse que vous saisissez

D'abord, trouvez l'adresse source que la passerelle utilise réellement vers NPS. Une passerelle à plusieurs interfaces émet souvent depuis une interface d'administration ou de backend plutôt que depuis son écouteur VPN public. Ensuite, vérifiez s'il y a du NAT entre les deux : si la requête est traduite, NPS voit l'adresse traduite, et c'est la valeur à enregistrer. Enfin, si deux passerelles partagent le rôle, chaque source de requête a besoin de sa propre entrée de client, car un seul objet avec une adresse n'en couvre qu'une.

Une fiche à deux extrémités garde la paire droite. Le tableau ci-dessous utilise des adresses privées pour l'illustration, remplacez-les par celles que votre chemin utilise réellement.

Confirmez la source au lieu de la deviner. Observez le journal de NPS ou du pare-feu pendant une tentative, ou capturez sur l'hôte NPS avec sudo tcpdump -ni any udp port 1812. L'adresse de cette capture est la seule réponse défendable pour l'entrée de client. Si la passerelle a plusieurs sources possibles, enregistrez chacune sous son propre nom convivial.

Le secret partagé est une valeur entre la passerelle et NPS

Le secret partagé authentifie la relation entre les équipements. Ce n'est pas un mot de passe utilisateur et il n'est jamais distribué au personnel ni intégré aux profils de clients.

Choisissez une valeur, saisissez-la aux deux endroits et conservez-la là où vit la sauvegarde de configuration de la passerelle. Une discordance produit une requête que NPS rejette sans erreur utile, ce qui, dans le journal de la passerelle, ne se distingue pas d'un serveur injoignable. Faites-la tourner pendant une fenêtre de maintenance et mettez à jour les deux extrémités dans le même changement.

Confirmez avec une requête autorisée

Utilisez un compte contrôlé et corrélez une seule tentative des deux côtés. Sur la passerelle, confirmez que la requête est partie vers le serveur prévu ; sur NPS, qu'elle est arrivée du client enregistré et qu'elle correspondait à la politique de demande de connexion attendue. Un délai d'attente et un rejet signifient des choses différentes, et traiter les deux comme un problème d'identifiants fait perdre l'heure suivante. Testez ensuite un compte valide mais non éligible et un mot de passe erroné, car une politique qui accepte tout passe aussi le premier test.

Enfin, vérifiez ce que la passerelle fait de l'autorisation renvoyée. Enregistrer un client RADIUS permet seulement à l'équipement de participer ; cela n'accorde pas à chaque session résultante l'accès au LAN.

Gardez la sortie de diagnostic encadrée : aucun secret partagé, aucun mot de passe utilisateur, aucune charge utile complète de paquet dans un ticket d'assistance. Si la conception exige que le serveur NPS lise des attributs d'annuaire, cette permission est une tâche administrative distincte de l'enregistrement du client, et lorsqu'elle manque, elle échoue autrement.