PFSENSE - Webdav SSL et certificats
-
Merci,
alors donc il vaudrait mieux que je fasse un VPN client à site,
- qui va utiliser l'authentification de l'annuaire AD
- dont les règles du VPN me permettrons (sans nuire à mes deux autres VPN) de limiter le trafic aux requêtes d'accès webdav
- qui peut exécuter un script pour monter un lecteur réseau vers le Webdav de l'utilisateur lors de la connexion et de démonter lors de la déconnexion, ceci devant tenir compte du système d'exploitation.
C'est faisable ?
concernant le point N°1, tout ça ça passe par achat d'un nom de domaine et d'un certificat auprès d'une autorité sur Internet ?
Concernant le point N°2, je vais creuser parce que là je n'y connais pas grand chose.
Concernant le "VERIFY=NO", firefox doit le faire puisqu'il se connecte lui. Sais tu comment changer ce paramètre pour le navigateur de fichier sous Windows ?
-
Oui tu peux configurer un serveur VPN qui va utiliser AD comme back-end à la fois pour l’authentification et la gestion des certificats pour les compte utilisateurs.
Et comme tu peux avoir plusieurs serveurs VPN différents, tu peux gérer des règles spécifiques.Ce qui me surprend, du coup, c'est que tu as déjà un serveur VPN et que tu penses que c'est compliqué.
A noter que le VPN ne va pas monter/démonter de lecteur réseau. ça ne se passe pas du tout dans la même couche.
Pour le point n°1, effectivement, il faut un nom de domaine. ça ne coute quelques euros par an :-*
Pour le point 2 : tu peux également déployer un "vrai" reverse proxy sur une DMZ pour gérer des accès HTTP(s) depuis internet vers des serveurs internes. Il y a pas mal de documentation sur le web à ce sujet avec plusieurs solutions techniques disponibles. pfSense reste dans sa fonction de FW et port forwarding et le reverse proxy prend en charge les aspects HTTP.
-
En fait je trouve que c'est surtout compliqué pour les utilisateurs. il y a pas mal de personnes que l'informatique rebute. Ensuite mes VPNs ne fonctionnent que depuis hier soir. Disons que c'est nouveau pour moi tout ça. C'est vrai qu'avec les informations trouvées sur le site de pfsense.org, je m'en suis sorti assez facilement.
Oui je me doute que le VPN en lui même ne monte pas les lecteurs réseaux. Mais je me demandais si une application comme OpenVPN ne peut pas exécuter de script, sinon il sera certainement possible d'exécuter un script qui lance OpenVPN puis qui monte le lecteur réseau une fois la connexion établie non ? Mon objectif est de facilité la vie de l'utilisateur.Pour la DMZ je suis embêté car ma pfsense ne reconnais pas toutes mes cartes réseau. Mais ça ce sera l'objet d'un travail futur. Chaque choses en son temps.
-
Mais je me demandais si une application comme OpenVPN ne peut pas exécuter de script
Non, ce n'est pas conçu pour fonctionner ainsi.
sinon il sera certainement possible d'exécuter un script qui lance OpenVPN puis qui monte le lecteur réseau une fois la connexion établie non ?
Vos lecteurs réseaux devrait se reconnecter automatiquement, sous réserve que votre gestion dns soit correcte, que le routage soit correct et que votre interface vpn (côté serveur) autorise les flux nécessaires.
-
Bonjour,
J'ai donc essayé le vpn avec authentification LDAP. En mode Auth aucun problème. Cependant en mode Auth + SSL je n'y arrive pas. J'ai cru comprendre que le "certificat serveur" doit contenir le CN=domaine.local de mon serveur LDAP. Alors voici ce que je fais : création d'une autorité de certification CA puis du "certificat serveur" qui en dépend avec le CN correspondant à mon domaine AD. Je vais voir l'onglet "Export client" et là rien !J'ajoute qu'il semble y avoir un petit bug car si je crée un second certificat serveur et que je l'associe au VPN alors dans l'onglet "Export Client" il devient possible de télécharger le fichier de configuration mais pour le certificat précédemment associé à ce VPN ! Bref ce qui s'affiche dans cette page semble avoir un temps de retard.
-
J'ajoute qu'il semble y avoir un petit bug …
C'est possible. Entre l'écran et la chaise. J'utilise Openvpn depuis un moment et (très) régulièrement (encore une configuration la semaine dernière) . Chaque fois qu'une configuration ne fonctionne pas c'est mon erreur.
-
J'ai donc essayé le vpn avec authentification LDAP. En mode Auth aucun problème. Cependant en mode Auth + SSL je n'y arrive pas. J'ai cru comprendre que le "certificat serveur" doit contenir le CN=domaine.local de mon serveur LDAP. Alors voici ce que je fais : création d'une autorité de certification CA puis du "certificat serveur" qui en dépend avec le CN correspondant à mon domaine AD. Je vais voir l'onglet "Export client" et là rien !
J'ajoute qu'il semble y avoir un petit bug car si je crée un second certificat serveur et que je l'associe au VPN alors dans l'onglet "Export Client" il devient possible de télécharger le fichier de configuration mais pour le certificat précédemment associé à ce VPN ! Bref ce qui s'affiche dans cette page semble avoir un temps de retard.
Je pense que tu mélanges un certain nombre de choses autour des certificats, de leur usage et de la structure du nommage ;)
LDAP peut effectivement service à l'authentification de l'utilisateur.
mais le fait que tu l'accèdes en LDAP ou LDAPS (STARTTLS ou SSL) n'a aucun impact sur la partie VPN coté serveur ou client VPN. C'est tout au plus le client LDAP qui doit éventuellement vérifier le CA qui à généré le certificat présenté par le serveur LDAP.En ce qui concerne le certificat dont il est question dans la partie VPN, il s'agit :
- du certificat du serveur VPN
- du certificat généré pour chaque client
Pour que, au niveau SSL, le client VPN valide le serveur, il faut que le client dispose de la partie publique de la clé, par exemple celle du certificate autority.
-
Il est certain que la première partie de mon message est la conséquence d'un manque de connaissance sur le sujet. Par contre concernant le petit bug j'insiste.
Clairement je cale sur l'authentification. J'ai beau fouiller sur les forums et tutos divers trouvés sur le web je ne comprends pas comment faire. Je reprends ma config pour que ce soit plus clair :
1- User manager ->Authentification servers :
Hostname or IP = IP du serveur AD ou nom du serveur AD (j'ai essayé les deux)
port = 636
Transport = SSL
Peer Certificate Autority = ici j'ai le CA que j'ai créé sur le pfsense dison CA-1
Base DN = DC="mondomaineAD",DC=local
Authentification = OU=Mesutilisateurs,OU=xxx,DC="mondomaineAD",DC=local
Bind credentials : CN=AccesVPN… (présent également dans l'ad)2- Sur Pfsense Certmanager
-> CAs :
CA-1 avec pour cn=autoriteCA
-> Certificates
ServeurAd-cert avec pour cn = serveurAD.mondomaineAD.localLà déjà si je fais Diagnostics ->Authentification, si je choisi le serveurAD et que je test avec un utilisateur (qui a normalement le droit de se connecter) ça ne marche pas. L’authentification sans SSL sur le port 389 fonctionne par contre, ce qui me permet de dire que ce n'est pas un problème de droit pour l'utilisateur.
Je suppose donc qu'il manque un lien entre le certificat serveur et LDAP mais franchement je ne vois pas comment faire. Les aides sur Technet ne m'ont pas non plus permis de résoudre mon problème.
Morale de l'histoire : Je me casse les dents sur une histoire de certificats pour mes webdav en accès direct et maintenant le me les casse sur un problème de certificats avec LDAP ! J'ai pas l'impression d'avancer c'est terriblement angoissant surtout au regard du temps que j'y passe.
Enfin pour finir avec les paramètres le VPN :
Serveur Mode : Remote Access (SSL/TLS + user Auth)
Backend : ServeurAD
proto : UDP
device : tun
interface : WAN
local port :1196
TLS auth : enable
Peer CA : CA-1
Server cert : ServeurAd-cert
le reste standard
Tunnel Setting / Client setting : OK car testé sans SSL et ça marche.Précision mon serveur AD est un W2008 R2
Voilà. Cela fait 3 jours que je lit, teste et teste encore et là ça me prend vraiment la tête. Je reconnais que les certificats c'est pas mon truc !
A+PS : je viens de lire la dernière réponse. En effet je pense que je ne suis pas au clair avec les certificats. Je crois avoir compris qu'avec une authentification LDAP sans SSL et les options SSL du VPN renseignée alors mon authentification n'est pas sécurisée mais une fois celle-ci établie le VPN lui est sécurisé. C'est ça ?
J'ai pu utiliser le VPN avec les paramétrages ci-dessus mais avec "serveur mode = User Auth" et avec User manager ->Authentification servers :
Hostname or IP = IP du serveur AD
port = 389 (389)
Transport = TCP standard
le reste ne change pas par rapport à ce que j'ai écrit en haut. -
Je vais tenter de t'apporter quelques éléments de réponse 8)
1- User manager ->Authentification servers :
Hostname or IP = IP du serveur AD ou nom du serveur AD (j'ai essayé les deux)
port = 636
Transport = SSLpas d'IP mais un hostname si tu veux faire du SSL (ce qui est très fortement conseillé) car, même si ce n'est techniquement pas obligatoire, le choix, à mon avis bon, de l'équipe pfSense est de vérifier que le nom du certificat présenté par le serveur LDAP en SSL correpsond au nom du serveur que le client LDAP reqête.
Peer Certificate Autority = ici j'ai le CA que j'ai créé sur le pfsense dison CA-1
Le "peer cetificate autority " c'est la partie publique du CA qui a signé le certificat du serveur LDAP (ici AD), que tu importes via le menu "certificat" de pfSense
Bind credentials : CN=AccesVPN… (présent également dans l'ad)
Donc tu as créé un compte spécifique pour accéder au serveur LDAP. Pourquoi pas…
Autre point :
le tunnel VPN "cache" uniquement ce qui passe entre le client VPN et le serveur VPN (pfSense) mais pas du tout ce qui se passe entre le serveur pfSense et le serveur LDAP. Sans SSL, quelqu'un sur le réseau pourrait assez facilement récupérer le mot de passe LDAP qui passe en base64 (autrement dit en clair) -
Enfin pour finir avec les paramètres le VPN :
Serveur Mode : Remote Access (SSL/TLS + user Auth)
Backend : ServeurAD
proto : UDP
device : tun
interface : WAN
local port :1196
TLS auth : enable
Peer CA : CA-1
Server cert : ServeurAd-certJe n’avais pas vu ça : le certificat serveur qu'il faut décrire dans le serveur VPN, c'est celui… du serveur VPN.
Ce qui se passe dans AD n'a rien à voir ici ;) (ou alors c'est un typo dans ton texte)