Rechercher

3.3. Configurer Squid comme proxy de mise en cache avec authentification kerberos

download PDF

Cette section décrit une configuration de base de Squid en tant que proxy de mise en cache qui authentifie les utilisateurs d'un Active Directory (AD) à l'aide de Kerberos. La procédure prévoit que seuls les utilisateurs authentifiés peuvent utiliser le proxy.

Conditions préalables

  • La procédure suppose que le fichier /etc/squid/squid.conf est tel qu'il est fourni par le paquet squid. Si vous avez déjà modifié ce fichier, supprimez-le et réinstallez le paquet.
  • Le serveur sur lequel vous voulez installer Squid est membre du domaine AD.

Procédure

  1. Install the following packages:

    # dnf install squid krb5-workstation
  2. S'authentifier en tant qu'administrateur du domaine AD :

    # kinit administrator@AD.EXAMPLE.COM
  3. Créer un keytab pour Squid et le stocker dans le fichier /etc/squid/HTTP.keytab:

    # export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
    # net ads keytab CREATE -U administrator
  4. Ajouter le principal du service HTTP à la base de données de clés :

    # net ads keytab ADD HTTP -U administrator
  5. Définir le propriétaire du fichier keytab à l'utilisateur squid:

    # chown squid /etc/squid/HTTP.keytab
  6. En option, vérifiez que le fichier keytab contient le principal de service HTTP pour le nom de domaine complet (FQDN) du serveur proxy :

      klist -k /etc/squid/HTTP.keytab
    Keytab name: FILE:/etc/squid/HTTP.keytab
    KVNO Principal
    ---- ---------------------------------------------------
    ...
       2 HTTP/proxy.ad.example.com@AD.EXAMPLE.COM
    ...
  7. Modifiez le fichier /etc/squid/squid.conf:

    1. Pour configurer l'utilitaire d'aide negotiate_kerberos_auth, ajoutez l'entrée de configuration suivante au début de /etc/squid/squid.conf:

      auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/squid/HTTP.keytab -s HTTP/proxy.ad.example.com@AD.EXAMPLE.COM

      Les paramètres transmis à l'utilitaire negotiate_kerberos_auth dans l'exemple ci-dessus sont décrits ci-dessous :

      • -k file définit le chemin d'accès au fichier key tab. L'utilisateur Squid doit avoir les droits de lecture sur ce fichier.
      • -s HTTP/host_name@kerberos_realm définit le principal Kerberos utilisé par Squid.

        En option, vous pouvez activer la journalisation en passant l'un ou les deux paramètres suivants à l'utilitaire d'aide :

      • -i enregistre les messages d'information, tels que l'authentification de l'utilisateur.
      • -d active la journalisation de débogage.

        Squid enregistre les informations de débogage de l'utilitaire d'aide dans le fichier /var/log/squid/cache.log.

    2. Ajoutez l'ACL et la règle suivantes pour configurer Squid de manière à ce que seuls les utilisateurs authentifiés puissent utiliser le proxy :

      acl kerb-auth proxy_auth REQUIRED
      http_access allow kerb-auth
      Important

      Spécifiez ces paramètres avant la règle http_access deny all.

    3. Supprimez la règle suivante pour désactiver le contournement de l'authentification par proxy à partir des plages d'adresses IP spécifiées dans les ACL localnet:

      http_access allow localnet
    4. L'ACL suivante existe dans la configuration par défaut et définit 443 comme un port qui utilise le protocole HTTPS :

      acl SSL_ports port 443

      Si les utilisateurs doivent pouvoir utiliser le protocole HTTPS également sur d'autres ports, ajoutez une ACL pour chacun de ces ports :

      acl SSL_ports port port_number
    5. Mettez à jour la liste des règles acl Safe_ports pour configurer les ports sur lesquels Squid peut établir une connexion. Par exemple, pour configurer que les clients utilisant le proxy ne peuvent accéder aux ressources que sur les ports 21 (FTP), 80 (HTTP) et 443 (HTTPS), ne conservez que les déclarations acl Safe_ports suivantes dans la configuration :

      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443

      Par défaut, la configuration contient la règle http_access deny !Safe_ports qui définit le refus d'accès aux ports qui ne sont pas définis dans les ACL Safe_ports.

    6. Configurez le type de cache, le chemin d'accès au répertoire du cache, la taille du cache et d'autres paramètres spécifiques au type de cache dans le paramètre cache_dir:

      cache_dir ufs /var/spool/squid 10000 16 256

      Avec ces paramètres :

      • Squid utilise le type de cache ufs.
      • Squid stocke son cache dans le répertoire /var/spool/squid/.
      • La mémoire cache peut atteindre 10000 MB.
      • Squid crée des sous-répertoires de niveau 1 16 dans le répertoire /var/spool/squid/.
      • Squid crée des sous-répertoires 256 dans chaque répertoire de niveau 1.

        Si vous ne définissez pas de directive cache_dir, Squid stocke le cache en mémoire.

  8. Si vous définissez un répertoire de cache différent de /var/spool/squid/ dans le paramètre cache_dir:

    1. Créer le répertoire du cache :

      # mkdir -p path_to_cache_directory
    2. Configurez les permissions pour le répertoire du cache :

      # chown squid:squid path_to_cache_directory
    3. Si vous utilisez SELinux en mode enforcing, définissez le contexte squid_cache_t pour le répertoire de cache :

      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory

      Si l'utilitaire semanage n'est pas disponible sur votre système, installez le paquet policycoreutils-python-utils.

  9. Ouvrez le port 3128 dans le pare-feu :

    # firewall-cmd --permanent --add-port=3128/tcp
    # firewall-cmd --reload
  10. Activez et démarrez le service squid:

    # systemctl enable --now squid

Verification steps

Pour vérifier que le proxy fonctionne correctement, téléchargez une page web à l'aide de l'utilitaire curl:

# curl -O -L "https://www.redhat.com/index.html" --proxy-negotiate -u : -x "proxy.ad.example.com:3128"

Si curl n'affiche aucune erreur et que le fichier index.html existe dans le répertoire actuel, le proxy fonctionne.

Étapes de dépannage

Pour tester manuellement l'authentification Kerberos :

  1. Obtenir un ticket Kerberos pour le compte AD :

    # kinit user@AD.EXAMPLE.COM
  2. Il est possible d'afficher le ticket :

    # klist
  3. Utilisez l'utilitaire negotiate_kerberos_auth_test pour tester l'authentification :

    # /usr/lib64/squid/negotiate_kerberos_auth_test proxy.ad.example.com

    Si l'utilitaire d'aide renvoie un jeton, l'authentification a réussi :

    Token : YIIFtAYGKwYBBQUCoIIFqDC...
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.