Squid3+SquidGuard ACL par groupe AD

[tupiware]

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.

[chris4916]

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

[tupiware]

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


[jdh]

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 !

[chris4916]

@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é  ;)

[chris4916]

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

[chris4916]

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.

[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

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

[tupiware]

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

[chris4916]

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