Squid3+SquidGuard ACL par groupe AD



  • Bonjour à tous, voici mon petit soucis concernant mon config PFSENSE 2.2.6-RELEASE (amd64)

    Contexte : milieu pro PME, mon niveau est débutant (en formation),  l'age de la solution est environs 5 mois, c'est en période de test

    Besoin : Un proxy facile d'administration pour du filtrage HTTP et HTTPS par users , facilité de lecture des logs.

    WAN : 2 routeurs orange business mpls géré par notre prestataire avec firewall

    LAN : DHCP fournis autre que pfsense

    WIFI : pas de wifi

    Règles Firewall : utilisation de PFSENSE pas en tant que firewall ( pas taper svp ;) )

    Packages ajoutés : squid3+squidguard , Lightsquid , Open-VM-Tools , File Manager

    Autres fonctions assignées au pfSense : filtrage url par authentification active directory.
    Question : Ma config squid3+squidguard fonctionne par users avec les authentification. Je souhaiterais configurer le filtrage par groupe et non pas user ( j'ai 300 users cela me parait un petit long à rentrer à la mano )

    j'ai effectué des "groups acl" dans squidguard :

    PROXY_ADMINISTRA
    PROXY_DIRECTION
    PROXY_TECHNIQUE
    PROXY_RH

    Dans chaque groupe acl il y a des users AD par exemple

    PROXY_ADMINISTRA : 'FORMATION1'
    PROXY_DIRECTION : 'TEST' 'TOTO' 'TATA'

    Tout fonctionne je n'ai pas de soucis

    Pistes imaginées

    Donc au lieu de mettre des users dans "groups acl" je souhaiterais mettre un groupe AD
    exemple dans mon groupe AD : FILTRE_DIRECTION il y a :

    TEST
    TOTO
    TATA

    Logs et tests : complément de "Recherches" : j'ai essayer de mettre le groupe FILTRE_DIRECTION dans une des groups acl au niveau de "client (source)" mais cela ne fonctionne pas.

    j'ai aussi trouvé une piste (peut être que cela n'a rien avoir) sur ce lien mais je vous avouerais que j'ai du mal a comprendre :

    www.technet.az/2015/08/22/pfsense-squidguardldap-filter/

    J'espère avoir été lisible, merci par avance.

    N.B. : schéma de l'ad

    ![proxy groupe.JPG](/public/imported_attachments/1/proxy groupe.JPG)
    ![proxy groupe.JPG_thumb](/public/imported_attachments/1/proxy groupe.JPG_thumb)



  • pfSense juste pour faire du proxy HTTP… ce n'est pas le meilleur choix à mon avis.



  • Bonjour
    C'est possible Chris, mais pour le moment j'ai mis 10 users cela fait 5 mois qui sont sur ce proxy je n'ai pas rencontré de soucis ! Cela correspond à mes besoins.
    juste ce petit paramétrage par groupe qui me facilitera mon déploiement.

    j'ai test Squid sur un debian j'ai buté sur la liaison LDAP et le couple squid3+squidguard :/

    Avec Pfsense ça facilite grandement.



  • Je comprends bien que le coté "package" de pfSense + l'interface graphique rendent les choses plus attrayantes et accessibles mais ça ait quand même beaucoup de fonctions supplémentaires inutiles juste pour gérer juste un proxy.
    Bref, c'est toi qui voit  :P  ;D

    En faisant abstraction de cet aspect:

    • quelle est ta conf pfSense pour le serveur LDAP ?
    • je sais bien que ton serveur LDAP c'est AD et donc c'est à peut-près impossible à gérer en tant que serveur LDAP mais si tu trouves un moyen d'activer un mode de log ou de debug suffisant, il serait intéressant de regarder la requête faite par pfSense. Tu peux avoir des tas de petits problème stupides comme une baseDN qui ne correspond pas ou un filtre, ou objectclass pas adapté.


  • Lol ici on aime pas trop utiliser le proxy de squid sur pfsense ;)

    Sinon je t'ai mis mon arborescence de mon AD ( c'est un labo ) ainsi que les screens de conf pfsense + squid + squidgard.

    Merci pour ton aide ;)







    ![squid auth.png](/public/imported_attachments/1/squid auth.png)
    ![squid auth.png_thumb](/public/imported_attachments/1/squid auth.png_thumb)



  • Lol ici on aime pas trop utiliser le proxy de squid sur pfsense

    Il y a de multiples raisons pour préférer d'autres solutions !

    La première des raisons est que Squid n'est qu'un package : cela ne fait pas partie de 'pfsense' proprement dit, et c'est donc sans garantie !

    Mais dans votre cas, il est particulièrement anormal d'installer un pfsense juste pour utiliser le package.

    Il est incontestable, qu'avec le dimensionnement qui est le votre (300 users), un proxy dédié s'impose …

    NB : anecdocte : Chris4916 est un de ceux qui tolère les packages et, là, il souligne la même incohérence !



  • @jdh:

    NB : anecdocte : Chris4916 est un de ceux qui tolère les packages et, là, il souligne la même incohérence !

    ça n'a rien d'anecdotique  ;D ;D

    C'est juste que je n'ai pas de dogme et que, tout étant une affaire de compromis, il y a des situations où ce design (proxy "dans" pfsense) est un choix acceptable voire parfois le meilleur choix.

    En l’occurrence, il n'y a absolument pas besoin de pfSense donc je m'interroge sur la finalité  ;)



  • Je ne comprends pas ta conf LDAP ni pourquoi elle fonctionne.
    A la lecture (certes un peu rapide) de tes screen-copy et du DIT, j'a l'impression que tes comptes utilisateurs sont dans
    OU=utilisateurs, ou=societe, dc=domain,dc=local

    mais dans le baseDN du serveur LDAP, tu as configuré une seule branche
    ou=groupes,ou=socite,dc=domain,dc=local

    tu peux (mais je ne l'ai pas expérimenté), mettre plusieurs branches dans le champ containers, en les séparant par des ";"
    par exemple:
    ou=groupes;ou=utilisateurs

    mais si je comprends bien les labels, tu aurais plutôt envie de mettre:
    ou=groupes;ou=actives,ou=utilisateurs

    et encore, uniquement si il y a des comptes "utilisateurs" dans la branche groupe.
    Dans le cas contraire, le baseDN suivant devrait suffire:
    ou=active,ou=utilisateurs,ou=societe,dc=domain,dc=local



  • Je voudrais en profiter pour faire une petite digression à propos de la couche LDAP de pfSense :
    la volonté d'intégrer un back-end LDAP dès lors qu'on offre des services qui ne sont pas strictement relatifs à du firewall (comme le VPN ou le portail captif pour ne parler que de ce qui n'est pas "package" et donc plus largement admis dans cette section  8)) est assez naturelle.
    Mais je trouve que c'est assez mal fait au niveau de pfSense (ou alors je ne sais pas m'en servir et c'est la raison pour laquelle je n'y comprends rien ;D ;D)

    Ceci étant, comme LDAP c'est mon cœur de métier, je m'interroge sur la logique qui conduit à une telle interface  ::)

    par exemple le fait de définir plusieurs "préfixes" à ajouter avec le baseDN laisse croire que la requête d’authentification, d'un point de vue utilisateur, peut se transformer en plusieurs requêtes LDAP  :o

    ou encore la fonction de "stripping" de ce qui se situe "à la droite du caractère @" ??? ???  :o  la notion de domaine de Kerberos s'efface pour laisser la place à un bind avec un login qui match quel que soit le domaine ?

    Le commentaire RFC2307 vs. 2307bis, c'est juste n'importe quoi. La différence entre ces 2 RFC n'a rien à voir avec l'implémentation, au niveau de l'entrée utilisateur, d'un attribut de type 'IsMemberOf"

    Bref, la vision de LDAP par pfSense est largement discutable, à mon humble avis.
    Ce qui, dans ton cas où tu n'as pas besoin de pfSense, justifie pleinement que tu construises une solution plus flexible.



  • Bonjour dans User MANAGER j'ai exactement ça :

    au niveau des containers

    OU=ACTIVE,OU=UTILISATEURS,OU=SOCIETE,DC=domain,DC=local;OU=GROUPES,OU=SOCIETE,DC=domain,DC=local;OU=SOCIETE,DC=domain,DC=local

    Désolé ancien screen sans modif de ma part sur l'état actuel de mon labo.



  • à plusieurs reprise j'ai essayé d'installer squid sur un debian ou autre distribution et je bloque à la liaison LDAP et aussi au moment d'intégrer Squidguard.
    Si j'avais les compétences je pense que je serais venus sur cette solution mais j'ai passé énormément de temps et malheureusement je ne peux rester trop longtemps dessus.



  • @tupiware:

    Bonjour dans User MANAGER j'ai exactement ça au niveau des containers:

    OU=ACTIVE,OU=UTILISATEURS,OU=SOCIETE,DC=domain,DC=local;OU=GROUPES,OU=SOCIETE,DC=domain,DC=local;OU=SOCIETE,DC=domain,DC=local

    Ma compréhension des "labels" sur cette page est que ce champ "containers" est utilisé pour le ldapsearch de l’authentification. Du coup, comme le scope est à "sub" (full tree), si tu mets à la fois :

    
    ou=active,ou=utilisateurs,ou=socité,dc=domain,dc=local
    

    et

    ou=socité,dc=domain,dc=local
    

    le deuxième étant plus large que le premier (et donc le premier totalement inclu dans le deuxième), ça ne sert à rien (c'est redondant)


Log in to reply