3.3. Setting up Squid as a caching proxy with kerberos authentication


You can configure 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.

Procedure

  1. Install the following packages:

    # dnf install squid krb5-workstation
  2. Authenticate as the AD domain administrator:

    # kinit administrator@AD.EXAMPLE.COM
  3. Create a keytab for Squid, store it in the /etc/squid/HTTP.keytab file and add the HTTP service principal to the keytab:

    # export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab
    # net ads keytab CREATE -U administrator
    # net ads keytab ADD HTTP -U administrator
  4. Optional: If system is initially joined to the AD domain with realm (via adcli), use following instructions to add HTTP principal and create a keytab file for squid:

    1. Add the HTTP service principal to the default keytab file /etc/krb5.keytab and verify:

      # adcli update -vvv --domain=ad.example.com --computer-name=PROXY --add-service-principal="HTTP/proxy.ad.example.com" -C
      # klist -kte /etc/krb5.keytab | grep -i HTTP
    2. Load the /etc/krb5.keytab file, remove all service principals except HTTP, and save the remaining principals into the /etc/squid/HTTP.keytab file:

      # ktutil
      ktutil:  rkt /etc/krb5.keytab
      ktutil:  l -e
      slot | KVNO | Principal
      -----------------------------------------------------------------------------
      1 |    2 |            PROXY$@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
      2 |    2 |            PROXY$@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      3 |    2 |         host/PROXY@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
      4 |    2 |         host/PROXY@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      5 |    2 | host/proxy.ad.example.com@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
      6 |    2 | host/proxy.ad.example.com@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      7 |    2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
      8 |    2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)

      In the interactive shell of ktutil, you can use the different options, until all unwanted principals are removed from keytab, for example:

      ktutil:  delent 1
      ktutil:  l -e
      
      slot | KVNO | Principal
      -------------------------------------------------------------------------------
      1 |   2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
      2 |   2 | HTTP/proxy.ad.example.com@AD.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
      
      ktutil:  wkt /etc/squid/HTTP.keytab
      ktutil:  q
      주의

      The keys in /etc/krb5.keytab might get updated if SSSD or Samba/winbind will update the machine account password. After the update, the key in /etc/squid/HTTP.keytab will stop working, and you will need to perform the ktutil steps again to copy the new keys into the keytab.

  5. Set the owner of the keytab file to the squid user:

    # chown squid /etc/squid/HTTP.keytab
  6. Optional: 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
      중요

      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. Enable and start the squid service:

    # systemctl enable --now squid

Verification

  • 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

  1. Obtain a Kerberos ticket for the AD account:

    # kinit user@AD.EXAMPLE.COM
  2. Optional: 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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동