Précédent Remonter Suivant

3  Squid

On ne verra ici qu'une utilisation de Squid dans le cadre d'une authentification par groupes simple, pour une configuration plus avancée il faudra voir par exemple les documentations officielles.

3.1  Installation

L'installation de Squid à partir des binaires ne pose pas de problème particulier. Pour une installation à partir des sources, se référer à la documentation accessible depuis le site de Squid (http://www.squid-cache.org ).

3.2  Configuration

On configure Squid en modifiant le fichier /etc/squid/squid.conf.

On passe sur tous les paramètres classiques (http_port, cache_effective_user...).

Pour configurer l'authentification, on utilise squid_ldap_auth et squid_ldap_group .

3.2.1  squid_ldap_auth

squid_ldap_auth est ce qu'on appelle un authentication helper, c'est-à-dire un petit programme qui détermine si un couple login/pass est correct : dans ce cas-ci, il communique avec un annuaire LDAP afin de voir s'il existe une entrée dans l'annuaire ayant le login indiqué dans un champ uid (ou cn ou autre si on le précise), et le pass correspondant dans un champ userPassword, mais un autre authentication helper pourrait tout aussi bien regarder si le couple login/pass se trouve dans un fichier contenant une liste de login/pass, voire même renvoyer toujours OK... Ce programme doit renvoyer la chaîne de caractères "OK" en cas de succès et "ERR" en cas d'échec.

Pour utiliser squid_ldap_auth , on ajoute dans squid.conf les lignes suivantes : 
auth_param basic program /usr/lib/squid/squid_ldap_auth -b ou=Users,dc=example,dc=com -u cn localhost
auth_param basic children 5
auth_param basic realm Identification proxy
auth_param basic credentialsttl 2 hours
Les paramètres ici utilisés pour squid_ldap_auth sont : On peut se demander à quoi servent les 3 lignes suivantes. Dans le cas d'une authentification par individus, il ne reste qu'à ajouter une règle ACL (Access Control List) qui indique l'utilisation du mécanisme d'authentification. Cette règle a la forme suivante :
acl password proxy_auth REQUIRED

Explications : Une fois cette règle ACL définie, on peut l'utiliser dans des règles d'accès, comme par exemple : 
http_access allow password

Cette règle indique que tous les utilisateurs authentifiés auront un accès http (suivant sa position par rapport à d'autres règles d'accès, cet accès sera peut-être restreint).

On notera que la règle ACL d'authentification acl password proxy_auth REQUIRED devient inutile dès qu'on utilise l'authentification par groupes.

3.2.2  squid_ldap_group

squid_ldap_group est aussi un helper, mais il interroge un annuaire LDAP pour savoir si un utilisateur donné appartient bien à un groupe donné, indépendamment d'un quelconque mot de passe. C'est un complément à squid_ldap_auth qui permet d'établir des règles d'accès au proxy selon des groupes définis dans l'annuaire.

Pour l'utiliser, on ajoute dans squid.conf la ligne : 
external_acl_type ldap_group ttl=3600 %LOGIN /usr/lib/squid/squid_ldap_group
    -b ou=Groups,dc=example,dc=com
    -B ou=Users,dc=example,dc=com
    -f "(&(cn=%g)(objectClass=groupOfNames)(member=%u))"
    -F "(&(cn=%s)(objectClass=person))"
    localhost
Attention, cette ligne a été découpée pour une lecture plus commode, mais dans le fichier de configuration, il ne faut pas la couper par des retours à la ligne.

Explications : Pour mieux comprendre le sens de ces paramètres, lire la section suivante.

Pour utiliser l'authentification par groupes, il faut également définir une règle ACL par groupe, du type :
acl group_Parents external ldap_group Parents

où : puis il faut définir des règles d'accès, comme par exemple :
http_access allow group_Parents

qui autorise l'accès http à tous les utilisateurs vérifiant l'ACL group_Parents, c'est-à-dire les utilisateurs authentifiés appartenant au groupe Parents dans l'annuaire LDAP.

3.3  Utilisation

Une fois que le proxy est configuré, on peut le lancer, ce qui se fait dans le cas d'une installation à partir des binaires Redhat 9 par la commande :
/etc/init.d/squid start

Si on doit le relancer (suite à une modification de squid.conf), on tape : 
/etc/init.d/squid restart

On peut maintenant tester le proxy.

3.4  Exemple

On retourne sur son poste client, et on indique à son navigateur préféré que l'on utilise ce proxy, en lui donnant l'ip de l'ordinateur faisant office de serveur proxy, ainsi que le port utilisé (défini dans squid.conf par http_port).

Ensuite, lorsqu'on essaie d'accéder à une page nécessitant une authentification, une fenêtre devrait s'ouvrir, demandant un nom d'utilisateur et un mot de passe.

Figure 2 : Dialogue d'authentification

On notera qu'on retrouve bien la chaîne de caractères passée en argument à auth_param basic realm dans squid.conf.

Rentrons par exemple l'utilisateur homer et le mot de passe azerty. On accède bien à la page demandée, et on n'a plus besoin de rentrer son login/pass à nouveau (comportement de la plupart des navigateurs, indépendant de Squid ).

Si maintenant on relance le navigateur et si on réessaie d'accéder à la même page, la plupart des navigateurs vont redemander le login/pass. Rentrons cette fois-ci le couple bart/azerty, et on arrive à une page nous indiquant que l'accès est interdit. Pour accéder à la page, il faut donc relancer le navigateur et entrer un couple login/pass ayant les droits d'accès suffisants (en théorie chaque utilisateur ne connaît qu'un seul login/pass bien évidemment).

Pour bien comprendre le fonctionnement de l'authentification, on peut analyser les transmissions de paquets avec un outil comme Ethereal.

3.5  Fonctionnement

Ethereal est un outil d'analyse de protocoles réseau (http://www.ethereal.com ). Il permet d'observer les paquets échangés sur un réseau, de les classer par protocole... On ne s'intéresse ici qu'aux paquets LDAP échangés, entre le moment où on rentre un couple login/pass et le moment où une page s'affiche.

3.5.1  Identifiant incorrect

Dans le cas d'un utilisateur rentrant un mauvais login ou mot de passe, on observe la succession des paquets suivants :

3.5.2  Identifiant correct - Personne autorisée

Dans le cas d'un utilisateur autorisé rentrant correctement ses identifiants, on a d'abord les 3 mêmes paquets que précédemment, avec la nuance que le champ Result Code du paquet Bind Result indique Success, puis les paquets suivants :

3.5.3  Identifiant correct - Personne non autorisée

Enfin, dans le cas d'un utilisateur non autorisé rentrant correctement ses identifiants, on a exactement le même type de paquets échangés jusqu'au deuxième Search Request, qui, ayant un filtre ne correspondant à aucune entrée de l'annuaire, n'entraîne pas d'émission de paquet Search Entry.

Figure 7 : Search Request de groupe inexistant

Le deuxième paquet Search Request est donc immédiatement suivi en réponse d'un paquet Search Result indiquant que la recherche s'est effectuée sans problème (en effet le fait de ne pas avoir de réponse n'est pas une erreur), puis d'un paquet Unbind Request.

3.5.4  Remarques

ttl de squid_ldap_auth
Dans squid.conf, nous avons mis la ligne suivante : 
auth_param basic credentialsttl 2 hours

Lorsqu'on s'est identifié correctement auprès du proxy (que l'on soit autorisé ou non), si on s'identifie une nouvelle fois avant la fin de la durée associée à credentialsttl, Squid ne fera pas d'échange avec le serveur LDAP. Squid possède en quelque sorte un cache d'identifiants, ce qui évite de solliciter le serveur LDAP trop souvent (en effet si on réduit cette durée à une seconde, on se rend compte en utilisant Ethereal que Squid effectue un Bind Request/Result/Unbind à chaque nouvelle page demandée par l'utilisateur). En contrepartie, si on modifie le mot de passe dans l'annuaire, le changement ne sera pas perçu avant la fin de la durée choisie ici, l'utilisateur n'aura donc pas besoin de se ré-authentifier avant la fin de cette durée (que ce soit l'utilisateur lui-même ou quelqu'un qui lui a volé son mot de passe et qui se sert de son compte), par contre une fois que la durée sera écoulée, Squid saura que le mot de passe n'est plus valide, et donc l'utilisateur devra s'authentifier à nouveau.

ttl de squid_ldap_group
De même, dans la ligne appelant squid_ldap_group de squid.conf, nous avons mis le paramètre 
ttl=3600

Ce paramètre a le même rôle concernant squid_ldap_group que credentialsttl avec squid_ldap_auth . Ainsi, si on modifie l'annuaire LDAP de sorte à rajouter un utilisateur non autorisé dans un groupe autorisé, le changement ne sera pas perçu avant la fin de cette durée, et l'utilisateur ne sera donc pas autorisé selon Squid avant qu'il ne refasse sa requête au serveur LDAP.

(Remarque : ttl signifie time to live, c'est-à-dire le temps, la durée qu'il reste à vivre...)

Précédent Remonter Suivant