Boîte à Outils Informatique
Procédure

Mettre en place un contrôle RADIUS pour un VPN

Intégrer un VPN à RADIUS/NPS avec client RADIUS, secret partagé, Network Policy, groupe dédié, pilote et logs, sans ouvrir l’accès à tous les comptes valides.

Réseau & Sécurité
ThématiqueRéseau informatique →
⌚ Environ 6 min de lecture
Voir mes favoris
DomaineRéseau & SécuritéNiveauAvancéDurée60-180 minRisqueÉlevé

Objectif

Mettre en place une authentification RADIUS pour un VPN en séparant clairement le rôle du serveur d’accès VPN et du serveur RADIUS/NPS, en limitant l’autorisation à un groupe pilote et en validant les requêtes Access-Accept et Access-Reject avant généralisation.

Prérequis

  • Serveur NPS/RADIUS opérationnel et joint au domaine si l’authentification s’appuie sur AD DS.
  • Adresse IP source ou NAS
  • Groupe pilote dédié aux utilisateurs VPN et un compte de test non autorisé.
  • Méthode d’authentification choisie et compatible entre VPN, NPS et clients.
  • Sauvegarde ou export de la configuration NPS et du firewall avant modification.

Procédure pas à pas

1

Définir le modèle d’authentification et d’autorisation

Décidez si NPS effectue localement l’authentification et l’autorisation ou agit comme proxy RADIUS. Pour un VPN adossé à AD DS, NPS peut vérifier l’identité puis appliquer une Network Policy. Documentez le groupe autorisé, la méthode EAP ou MSCHAP selon le scénario, l’éventuel MFA et le comportement attendu pour un utilisateur valide mais hors groupe.

Résultat attendu
  • Le rôle du serveur RADIUS et les critères d’autorisation sont définis avant configuration.
2

Ajouter le firewall ou VPN comme client RADIUS dans NPS

Dans NPS, créez un RADIUS Client correspondant à l’équipement VPN. Utilisez l’adresse IP que NPS verra réellement comme source ; en présence de NAT ou d’un NAS-IP explicitement défini, cette valeur doit correspondre. Configurez un secret fort et identique côté VPN. Donnez un nom explicite au client pour faciliter l’analyse des logs.

Résultat attendu
  • NPS reconnaît l’équipement VPN comme client RADIUS autorisé.
3

Créer une Network Policy limitée au groupe VPN

Créez une stratégie réseau qui cible le type de connexion et le groupe pilote. L’ordre des policies NPS est important : NPS évalue les règles de haut en bas. Évitez une policy permissive placée avant la nouvelle règle qui accepterait plus d’utilisateurs que prévu. Documentez aussi les contraintes d’heure, méthode ou type de tunnel si elles sont utilisées.

Résultat attendu
  • Seul le groupe prévu peut recevoir un Access-Accept pour le scénario VPN.
4

Configurer le serveur RADIUS sur le FortiGate ou le NAS

Sur FortiGate, créez l’objet RADIUS dans User & Authentication > RADIUS Servers ou via config user radius. Renseignez l’adresse ou FQDN, le secret et la méthode adaptée. Ne copiez jamais un secret réel dans la documentation. Si plusieurs serveurs existent, documentez clairement le comportement primaire/secondaire et les timeouts.

config user radius
    edit "<RADIUS-NAME>"
        set server "<NPS-IP-OR-FQDN>"
        set auth-type auto
    next
end
show user radius
Résultat attendu
  • L’objet RADIUS est présent sans exposer le secret dans la documentation.
5

Créer un groupe VPN qui référence RADIUS

Associez le serveur RADIUS à un groupe utilisé par le VPN. Si plusieurs groupes doivent être distingués, utilisez les attributs ou VSA prévus par la plateforme plutôt qu’un groupe qui accepte tout utilisateur RADIUS valide. Sur FortiGate, le Fortinet-Group-Name VSA peut servir à faire correspondre des groupes sélectifs lorsque NPS est configuré pour le retourner.

Résultat attendu
  • Le groupe VPN correspond uniquement aux utilisateurs autorisés par la stratégie.
6

Appliquer le groupe au tunnel ou à la policy

Liez le groupe à la configuration d’accès VPN appropriée. Vérifiez qu’un ancien groupe local ou une règle plus permissive ne contourne pas le contrôle RADIUS. Si le changement touche un accès distant critique, conservez un compte break-glass local testé, protégé par MFA si possible et exclu de l’usage quotidien.

Résultat attendu
  • Le VPN utilise RADIUS pour le groupe pilote sans supprimer le mécanisme de secours prévu.
7

Tester un utilisateur autorisé puis un refus attendu

Effectuez un test avec un compte du groupe pilote puis avec un compte valide mais non autorisé. Le premier doit produire un Access-Accept et le second un Access-Reject. Cette double validation prouve que l’autorisation est réellement appliquée, pas seulement l’authentification. Notez l’heure exacte de chaque test pour retrouver les événements NPS.

Résultat attendu
  • Le résultat diffère selon l’appartenance au groupe, comme prévu.
8

Lire les logs NPS et firewall en cas d’échec

Sur NPS, examinez les événements d’authentification et le motif de rejet : client RADIUS inconnu, secret incorrect, policy non matchée, méthode incompatible ou groupe absent. Côté FortiGate, activez un debug d’authentification uniquement pendant le test et désactivez-le immédiatement après afin d’éviter une sortie continue.

diagnose debug reset
diagnose debug application fnbamd -1
diagnose debug enable
diagnose debug disable
diagnose debug reset
Résultat attendu
  • Le motif du refus est identifié sans laisser le debug actif.
9

Étendre et superviser

Après validation, étendez le groupe progressivement et surveillez les taux d’Access-Reject, les délais et les timeouts. Si le VPN est critique, configurez un second serveur RADIUS selon le comportement documenté par le constructeur et testez réellement le failover. Un serveur secondaire non testé n’est pas une vraie redondance.

Résultat attendu
  • Le service reste disponible et les refus anormaux sont détectables.

Validation

La procédure est validée lorsque :

  • Le firewall ou serveur VPN apparaît comme client RADIUS légitime dans NPS.
  • Un membre du groupe pilote obtient un Access-Accept et un compte non autorisé reçoit un Access-Reject.
  • Le groupe VPN ne permet pas à tous les utilisateurs valides du serveur RADIUS de se connecter.
  • Les logs NPS et firewall permettent d’identifier les échecs et le compte break-glass prévu reste disponible.

Retour arrière

  • Retirer temporairement le groupe RADIUS du tunnel ou de la policy et rétablir le mécanisme d’authentification précédent documenté.
  • Désactiver la nouvelle Network Policy NPS plutôt que la supprimer pendant la période de retour arrière.
  • Conserver les logs de test et retirer les comptes ou règles temporaires créés uniquement pour le pilote.

Dépannage / erreurs fréquentes

  • Aucune requête dans NPS : vérifier IP source/NAS-IP, routage, firewall UDP et définition du client RADIUS.
  • Access-Reject immédiat : contrôler l’ordre et les conditions des Network Policies ainsi que le groupe AD.
  • Timeout côté VPN : rechercher secret incorrect, serveur non joignable ou mauvaise adresse RADIUS.
  • Tous les comptes RADIUS passent : vérifier le groupe FortiGate et les conditions ou VSA de la stratégie au lieu de se limiter à l’authentification.
  • Échec après bascule vers le serveur secondaire : vérifier que le client RADIUS et le secret sont configurés de façon cohérente sur les deux NPS.

Références officielles

♡ 0