PFSENSE - Webdav SSL et certificats



  • Bonjour,
    Je bute sur un problème : impossible d’accéder au webdav du serveur AD en montant un lecteur réseau depuis Internet. Voici la configuration :

    Sur le LAN seveurAD (2008)
    IIS 7.5
    Autorité de certification Installé
    Certificat (autosigné) créé et associé a la liaison SSL du Webdav
    liaison SSL s'effectue sur le port 4435 (SSL obligatoire)
    "Authentification de base" et "authentification Microsoft" activées.

    Sur PFSense : règle NAT qui redirige les requêtes https vers le serveurAD sur le port 4435.

    Si je tente de connecter un lecteur réseau depuis l'extérieur (Internet) j'ai systématiquement un message d’erreur.
    Sur le LAN je n'arrive pas à me connecter avec l'IP du serveur AD
    Chemin du lecteur réseau à monter = https://...:4435/toto -> ERREUR
    Cependant j'arrive a me connecter avec son nom :
    Chemin du lecteur réseau à monter = https://ServeurAD:4435/toto -> OK

    J’émets l'hypothèse qu'il s'agit alors d'un problème lié au certificat qui connait le nom ServeurAD mais pas son IP et encore moins celle de la pfsense. Si c'est le cas existe-t-il une solution au niveau de la pfsense qui me permette de contourner ce problème (je pensais quelque chose du genre emmètre un certificat pfsense et l'installer sur ServeurAD - Là j'ai peur de dire une grosse bêtise) ?
    (J'exclue des solutions le VPN client à site. trop compliqué à gérer et à utiliser)

    Cordialement.



  • Tout d'abord, ne te méprends pas, le VPN c'est à la fois simple à gérer et à utiliser.
    Après, si tu ne veux absolument pas utiliser de VPN mais que tu préfères exposer ton service "LAN" à l'extérieur sans précaution particulière et que tu le fais en connaissance de cause, pas de soucis  :-X

    Donc en supposant que le but soit d'exposer le service sur le web (puisqu'il s'agit de webdav) :

    • il y a 2 manières de faire :

    1 - pfSense ne fait que du port forwarding : dans ce cas, il n'est pas nécessaire d'avoir de certificat coté pfSense. Tout se passe en terme de réseau pour rediriger les requêtes des clients externes vers l'IP intertne. Attention, selon le type de certificat sur le serveur WebDAV, il faut bien que le client fasse une requête avec le bon FQDN, donc que celui-ci soit résolvable avec le DNS publique

    2 - pfSense s'intercale en tant que reverse proxy (HTTPS) et dans ce cas, les points précédents restent valides mais il faut en plus un certificat sur pfSense. Le reverse proxy peut prendre en charge de la réécriture d'URL et du filtrage  ;)

    Il est assez normal que en interne tu n'arrives pas à accéder à ton service en utilisant un autre nom que celui assigné au certificat qui établi le tunnel SSL. Si tu as un client qui fait un "VERIFY = NO", tu peux accéder en tapant une IP plutôt qu'un nom mais est-ce bien souhaitable ?



  • 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.



  • @mal2tête:

    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.



  • @mal2tête:

    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.local

    Là 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)

    @mal2tête:

    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

    pas 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)



  • @mal2tête:

    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

    Je 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)


Log in to reply