Buscar

Este contenido no está disponible en el idioma seleccionado.

16.3. Setting up Squid as a Caching Proxy With Kerberos Authentication

download PDF
This section describes a basic configuration of Squid as a caching proxy that authenticates users to an Active Directory (AD) using Kerberos. The procedure configures that only authenticated users can use the proxy.

Prerequisites

  • The procedure assumes that the /etc/squid/squid.conf file is as provided by the squid package. If you edited this file before, remove the file and reinstall the package.
  • The server on which you want to install Squid is a member of the AD domain. For details, see Setting up Samba as a Domain Member in the Red Hat Enterprise Linux 7 System Administrator's Guide.

Procedure

  1. Install the following packages:
    # yum install squid krb5-workstation
  2. Authenticate as the AD domain administrator:
    # kinit administrator@AD.EXAMPLE.COM
  3. Create a keytab for Squid and store it in the /etc/squid/HTTP.keytab file:
    # export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
    # net ads keytab CREATE -U administrator
  4. Add the HTTP service principal to the keytab:
    # net ads keytab ADD HTTP -U administrator
  5. Set the owner of the keytab file to the squid user:
    # chown squid /etc/squid/HTTP.keytab
  6. Optionally, verify that the keytab file contains the HTTP service principal for the fully-qualified domain name (FQDN) of the proxy server:
    #  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. Edit the /etc/squid/squid.conf file:
    1. To configure the negotiate_kerberos_auth helper utility, add the following configuration entry to the top of /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
      The following describes the parameters passed to the negotiate_kerberos_auth helper utility in the example above:
      • -k file sets the path to the key tab file. Note that the squid user must have read permissions on this file.
      • -s HTTP/host_name@kerberos_realm sets the Kerberos principal that Squid uses.
      Optionally, you can enable logging by passing one or both of the following parameters to the helper utility:
      • -i logs informational messages, such as the authenticating user.
      • -d enables debug logging.
      Squid logs the debugging information from the helper utility to the /var/log/squid/cache.log file.
    2. Add the following ACL and rule to configure that Squid allows only authenticated users to use the proxy:
      acl kerb-auth proxy_auth REQUIRED
      http_access allow kerb-auth

      Important

      Specify these settings before the http_access deny all rule.
    3. Remove the following rule to disable bypassing the proxy authentication from IP ranges specified in localnet ACLs:
      http_access allow localnet
    4. The following ACL exists in the default configuration and defines 443 as a port that uses the HTTPS protocol:
      acl SSL_ports port 443
      If users should be able to use the HTTPS protocol also on other ports, add an ACL for each of these port:
      acl SSL_ports port port_number
    5. Update the list of acl Safe_ports rules to configure to which ports Squid can establish a connection. For example, to configure that clients using the proxy can only access resources on port 21 (FTP), 80 (HTTP), and 443 (HTTPS), keep only the following acl Safe_ports statements in the configuration:
      acl Safe_ports port 21
      acl Safe_ports port 80
      acl Safe_ports port 443
      By default, the configuration contains the http_access deny !Safe_ports rule that defines access denial to ports that are not defined in Safe_ports ACLs.
    6. Configure the cache type, the path to the cache directory, the cache size, and further cache type-specific settings in the cache_dir parameter:
      cache_dir ufs /var/spool/squid 10000 16 256
      With these settings:
      • Squid uses the ufs cache type.
      • Squid stores its cache in the /var/spool/squid/ directory.
      • The cache grows up to 10000 MB.
      • Squid creates 16 level-1 sub-directories in the /var/spool/squid/ directory.
      • Squid creates 256 sub-directories in each level-1 directory.
      If you do not set a cache_dir directive, Squid stores the cache in memory.
  8. If you set a different cache directory than /var/spool/squid/ in the cache_dir parameter:
    1. Create the cache directory:
      # mkdir -p path_to_cache_directory
    2. Configure the permissions for the cache directory:
      # chown squid:squid path_to_cache_directory
    3. If you run SELinux in enforcing mode, set the squid_cache_t context for the cache directory:
      # semanage fcontext -a -t squid_cache_t "path_to_cache_directory(/.*)?"
      # restorecon -Rv path_to_cache_directory
      If the semanage utility is not available on your system, install the policycoreutils-python-utils package.
  9. Open the 3128 port in the firewall:
    # firewall-cmd --permanent --add-port=3128/tcp
    # firewall-cmd --reload
  10. Start the squid service:
    # systemctl start squid
  11. Enable the squid service to start automatically when the system boots:
    # systemctl enable squid

Verification Steps

To verify that the proxy works correctly, download a web page using the curl utility:
# curl -O -L "https://www.redhat.com/index.html" --proxy-negotiate -u : -x "proxy.ad.example.com:3128"
If curl does not display any error and the index.html file exists in the current directory, the proxy works.

Troubleshooting Steps

To manually test Kerberos authentication:
  1. Obtain a Kerberos ticket for the AD account:
    # kinit user@AD.EXAMPLE.COM
  2. Optionally, display the ticket:
    # klist
  3. Use the negotiate_kerberos_auth_test utility to test the authentication:
    # /usr/lib64/squid/negotiate_kerberos_auth_test proxy.ad.example.com
    If the helper utility returns a token, the authentication succeeded.
    Token: YIIFtAYGKwYBBQUCoIIFqDC...
Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.