Avis important : |
Cet article fournit une vue d'ensemble détaillée de la configuration d'un serveur Active Directory (AD) via un tunnel VPN L2TP en utilisant la méthode d'authentification VPN USG FLEX/ATP. En outre, les conseils présentés ici sont applicables aux configurations VPN IPsec IKEv2 et IKEv1.
Les tunnels VPN sont un élément essentiel lors de l'établissement de réseaux qui sont par nature étendus, tels que les réseaux d'entreprise mondiaux ou les sites principaux interconnectés avec des sites subsidiaires.
Une caractéristique fondamentale des réseaux d'entreprise est le processus d'authentification des utilisateurs auprès d'un serveur, ce qui permet de démontrer la fiabilité et d'obtenir l'accès aux ressources internes. Ce tutoriel a pour but de vous fournir les outils nécessaires pour configurer l'authentification à un serveur d'authentification via un tunnel VPN.
Deux pare-feux sont connectés via un VPN site à site, et sur le site principal A, il y a un serveur RADIUS dans le LAN. Sur le site B, il peut y avoir plusieurs clients qui veulent s'authentifier auprès du serveur RADIUS du site A. Sur le site B, nous trouvons soit des clients locaux qui ont besoin d'une connexion vers le serveur RADIUS du site A, soit des clients VPN L2TP qui ont besoin d'une authentification auprès du serveur RADIUS du site A.
Nous devons ici faire une distinction importante entre le client VPN et le client local sur le site B - alors qu'il est très probable que le client du site B puisse s'authentifier sans problème auprès du serveur RADIUS du site A, les clients VPN L2TP ne seront probablement pas en mesure de le faire. Comment cela se fait-il ?
Les VPN site à site sont configurés avec une politique locale et une politique distante. Ces politiques déterminent les routes de réseau qui sont créées lors de la création du tunnel, c'est-à-dire les réseaux qui sont autorisés à "se parler". Dans ce cas, nous supposons que le routage entre 192.168.10.0/24 et 192.168.20.0/24 est correct. Le VPN L2TP, qui par nature doit être un sous-réseau différent des sous-réseaux locaux du site B, n'est pas autorisé à communiquer vers le site A parce qu'il n'est pas inclus dans la stratégie locale ou distante.
En d'autres termes, si nous n'ajoutons pas de routes de politique supplémentaires. Avec l'aide de ce type de routes, nous pouvons forcer toute tentative d'authentification provenant du VPN L2TP vers une destination sur le site A. Tout d'abord, nous devons définir que les authentifications sur le site B sont dirigées vers le RADIUS du site A.
Configurez le serveur AAA
Configuration > Objet > Serveur AAAet configurer un objet d'authentification vers l'IP 192.168.10.100 :
Testez votre authentification AD
Configuration -> Objet -> Serveur AAAVeillez à sauvegarder votre configuration avant de tester la validation de la configuration.
| Bon résultat | Mauvais résultat |
Configurez la méthode Auth. Méthode
Cet objet serveur AAA doit maintenant être combiné à une méthode d'authentification, qui à son tour est définie comme l'authentification principale pour notre VPN. Tout d'abord, naviguez vers le menu
Configuration > Objet > Auth. Méthode d'authentificationet ajoutez le serveur AAA nouvellement créé à la méthode d'authentification par défaut Auth. par défaut :
Faire en sorte que le pare-feu rejoigne le serveur AD
L'USG doit ensuite rejoindre le domaine AD avec le nom de domaine du serveur AD.
Naviguer vers Configuration -> Système -> Nom d'hôte
Le domaine est le nom de domaine du serveur AD et le nom NetBIOS est le domaine.
Pour diriger le pare-feu vers le serveur AD, nous devons créer un enregistrement DNS pour trouver le serveur AD via l'adresse IP du serveur AD :
Configurer le VPN
Via IKEv2
Configuration -> VPN -> VPN IPSec -> Passerelle VPN - Ajouter/ModifierCliquez sur "Show Advanced Settings" et activez "Extended Authentication Protocol" et sélectionnez Server mode.
Sélectionnez ensuite la méthode AAA (méthode d'authentification) et l'utilisateur autorisé.
Via L2TP
Ensuite, nous sélectionnons cette méthode Auth. à utiliser via le VPN L2TP via
Configuration > VPN > L2TP over IPSec VPN(Veuillez noter que le pool d'adresses IP ne correspond pas à la topologie dessinée ci-dessus, puisqu'il s'agit simplement d'un exemple sur la façon de configurer le tunnel L2TP).
Maintenant que le VPN L2TP est configuré avec une authentification qui doit être transmise au RADIUS sur le site A, nous devons créer des routes de politique :
La première route de politique poussera tout ce qui vient de n'importe quelle source, qui veut se déplacer vers l'IP 192.168.10.100, dans le tunnel vers le Site A - ce qui signifie aussi la tentative d'authentification de notre VPN L2TP. La seconde route de politique repoussera tout ce qui est destiné au sous-réseau du VPN L2TP dans le VPN L2TP.
Sur l'autre site, il suffit maintenant de compléter cela par une règle correspondante, qui repoussera tout ce qui provient de sous-réseaux différents du LAN du site B (comme la tentative de notre sous-réseau VPN L2TP) dans le tunnel vers le site B, en déclenchant la route de politique que nous avons définie sur ce site.
En suivant ce guide simple, vous devriez maintenant être en mesure d'authentifier vos clients vers un RADIUS sur un autre site VPN distant.
Configurer la redirection DNS pour le domaine AD (recommandé)
Pour garantir une résolution correcte des noms AD, configurez une redirection DNS en plus de l'entrée DNS locale :
Allez dans Configuration → Système → DNS → Domaine Zone Forwarder, ajoutez votre domaine AD (par exemple,
company.local) et définissez le serveur DNS AD en tant que forwarder.Dans Connexion VPN → Paramètres du client, affectez le serveur DNS AD (ou l'IP LAN du pare-feu si le transfert est activé) en tant que premier serveur DNS.
(Facultatif) Ajoutez une route de stratégie si les requêtes DNS doivent être forcées à travers le VPN.
Vérifiez avec : nslookup dc1.company.local.
Dépannage et test du résultat
Naviguez vers
Monitor -> Network Status -> Login UsersNaviguez vers
Moniteur -> Moniteur VPN -> IPSecRésolution des problèmes
Accédez à la console Web du pare-feu ou connectez-vous au pare-feu via SSH et exécutez la commande suivante
debug domain-auth test profile-name [ad profile name] username [username] password [password]Remplacez ad profile name par le nom "AD Server Summary" d'Active Directory et utilisez le nom d'utilisateur et le mot de passe de l'authentification de domaine via MSCHAP.
Plus d'articles ici :
Vérification de l'authentification de l'utilisateur AD (active directory)
Comment rejoindre un domaine Active Directory avec USG/ATP/VPN
Comment faire l'authentification à deux facteurs avec les utilisateurs d'Active Directory

Commentaires
0 commentaireVous devez vous connecter pour laisser un commentaire.