Procedure

1. Install the httpd package:

   # yum install httpd

2. Open the TCP port 80 in the local firewall:

   # firewall-cmd --permanent --add-port=80/tcp
   # firewall-cmd --reload

3. Enable and start the httpd service:

   # systemctl enable --now httpd

4. Optional: Add HTML files to the /var/www/html/ directory.

Procedure

1. Install the httpd package:

   # yum install httpd

2. Edit the /etc/httpd/conf/httpd.conf file:

   1. Append the following virtual host configuration for the example.com domain:

      <VirtualHost *:80>
          DocumentRoot "/var/www/example.com/"
          ServerName example.com
          CustomLog /var/log/httpd/example.com_access.log combined
          ErrorLog /var/log/httpd/example.com_error.log
      </VirtualHost>

      These settings configure the following:

      • All settings in the <VirtualHost *:80> directive are specific for this virtual host.
      • DocumentRoot sets the path to the web content of the virtual host.

      • ServerName sets the domains for which this virtual host serves content.

        To set multiple domains, add the ServerAlias parameter to the configuration and specify the additional domains separated with a space in this parameter.

      • CustomLog sets the path to the access log of the virtual host.

      • ErrorLog sets the path to the error log of the virtual host.

        Note

        Apache uses the first virtual host found in the configuration also for requests that do not match any domain set in the ServerName and ServerAlias parameters. This also includes requests sent to the IP address of the server.

3. Append a similar virtual host configuration for the example.net domain:

   <VirtualHost *:80>
       DocumentRoot "/var/www/example.net/"
       ServerName example.net
       CustomLog /var/log/httpd/example.net_access.log combined
       ErrorLog /var/log/httpd/example.net_error.log
   </VirtualHost>

4. Create the document roots for both virtual hosts:

   # mkdir /var/www/example.com/
   # mkdir /var/www/example.net/

5. If you set paths in the DocumentRoot parameters that are not within /var/www/, set the httpd_sys_content_t context on both document roots:

   # semanage fcontext -a -t httpd_sys_content_t "/srv/example.com(/.*)?"
   # restorecon -Rv /srv/example.com/
   # semanage fcontext -a -t httpd_sys_content_t "/srv/example.net(/.\*)?"
   # restorecon -Rv /srv/example.net/

   These commands set the httpd_sys_content_t context on the /srv/example.com/ and /srv/example.net/ directory.

   Note that you must install the policycoreutils-python-utils package to run the restorecon command.

6. Open port 80 in the local firewall:

   # firewall-cmd --permanent --add-port=80/tcp
   # firewall-cmd --reload

7. Enable and start the httpd service:

   # systemctl enable --now httpd

Verification steps

1. Create a different example file in each virtual host’s document root:

   # echo "vHost example.com" > /var/www/example.com/index.html
   # echo "vHost example.net" > /var/www/example.net/index.html

2. Use a browser and connect to http://example.com. The web server shows the example file from the example.com virtual host.
3. Use a browser and connect to http://example.net. The web server shows the example file from the example.net virtual host.

Procedure

1. Edit the /etc/httpd/conf/httpd.conf file and add the following settings to the <VirtualHost> directive for which you want to configure client authentication:

   <Directory "/var/www/html/Example/">
     SSLVerifyClient require
   </Directory>

   The SSLVerifyClient require setting defines that the server must successfully validate the client certificate before the client can access the content in the /var/www/html/Example/ directory.

2. Restart the httpd service:

   # systemctl restart httpd

Verification steps

1. Use the curl utility to access the https://example.com/Example/ URL without client authentication:

   $ curl https://example.com/Example/
   curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

   The error indicates that the web server requires a client certificate authentication.

2. Pass the client private key and certificate, as well as the CA certificate to curl to access the same URL with client authentication:

   $ curl --cacert ca.crt --key client.key --cert client.crt https://example.com/Example/

   If the request succeeds, curl displays the index.html file stored in the /var/www/html/Example/ directory.

Procedure

1. Install the httpd-manual package:

   # yum install httpd-manual

2. Optional: By default, all clients connecting to the Apache HTTP Server can display the manual. To restrict access to a specific IP range, such as the 192.0.2.0/24 subnet, edit the /etc/httpd/conf.d/manual.conf file and add the Require ip 192.0.2.0/24 setting to the <Directory "/usr/share/httpd/manual"> directive:

   <Directory "/usr/share/httpd/manual">
   ...
       Require ip 192.0.2.0/24
   ...
   </Directory>

3. Restart the httpd service:

   # systemctl restart httpd

Verification steps

1. To display the Apache HTTP Server manual, connect with a web browser to http://host_name_or_IP_address/manual/

Procedure

1. List the certificates in the NSS database:

   # certutil -d /etc/httpd/alias/ -L
   Certificate Nickname           Trust Attributes
                                  SSL,S/MIME,JAR/XPI
   
   Example CA                     C,,
   Example Server Certificate     u,u,u

   You need the nicknames of the certificates in the next steps.

2. To extract the private key, you must temporarily export the key to a PKCS #12 file:

   1. Use the nickname of the certificate associated with the private key, to export the key to a PKCS #12 file:

      # pk12util -o /etc/pki/tls/private/export.p12 -d /etc/httpd/alias/ -n "Example Server Certificate"
      Enter password for PKCS12 file: password
      Re-enter password: password
      pk12util: PKCS12 EXPORT SUCCESSFUL

      Note that you must set a password on the PKCS #12 file. You need this password in the next step.

   2. Export the private key from the PKCS #12 file:

      # openssl pkcs12 -in /etc/pki/tls/private/export.p12 -out /etc/pki/tls/private/server.key -nocerts -nodes
      Enter Import Password: password
      MAC verified OK

   3. Delete the temporary PKCS #12 file:

      # rm /etc/pki/tls/private/export.p12

3. Set the permissions on /etc/pki/tls/private/server.key to ensure that only the root user can access this file:

   # chown root:root /etc/pki/tls/private/server.key
   # chmod 0600 /etc/pki/tls/private/server.key

4. Use the nickname of the server certificate in the NSS database to export the CA certificate:

   # certutil -d /etc/httpd/alias/ -L -n "Example Server Certificate" -a -o /etc/pki/tls/certs/server.crt

5. Set the permissions on /etc/pki/tls/certs/server.crt to ensure that only the root user can access this file:

   # chown root:root /etc/pki/tls/certs/server.crt
   # chmod 0600 /etc/pki/tls/certs/server.crt

6. Use the nickname of the CA certificate in the NSS database to export the CA certificate:

   # certutil -d /etc/httpd/alias/ -L -n "Example CA" -a -o /etc/pki/tls/certs/ca.crt

7. Follow Section 1.6, “Configuring TLS encryption on an Apache HTTP Server” to configure the Apache web server, and:

   • Set the SSLCertificateKeyFile parameter to /etc/pki/tls/private/server.key.
   • Set the SSLCertificateFile parameter to /etc/pki/tls/certs/server.crt.
   • Set the SSLCACertificateFile parameter to /etc/pki/tls/certs/ca.crt.

Procedure

1. Display the available NGINX module streams:

   # yum module list nginx
   Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
   Name        Stream        Profiles        Summary
   nginx       1.14 [d]      common [d]      nginx webserver
   nginx       1.16          common [d]      nginx webserver
   ...
   
   Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

2. If you want to install a different stream than the default, select the stream:

   # yum module enable nginx:stream_version

3. Install the nginx package:

   # yum install nginx

4. Open the ports on which NGINX should provide its service in the firewall. For example, to open the default ports for HTTP (port 80) and HTTPS (port 443) in firewalld, enter:

   # firewall-cmd --permanent --add-port={80/tcp,443/tcp}
   # firewall-cmd --reload

5. Enable the nginx service to start automatically when the system boots:

   # systemctl enable nginx

6. Optionally, start the nginx service:

   # systemctl start nginx

   If you do not want to use the default configuration, skip this step, and configure NGINX accordingly before you start the service.

Verification steps

1. Use the yum utility to verify that the nginx package is installed:

   # yum list installed nginx
   Installed Packages
   nginx.x86_64    1:1.14.1-9.module+el8.0.0+4108+af250afe    @rhel-8-for-x86_64-appstream-rpms

2. Ensure that the ports on which NGINX should provide its service are opened in the firewalld:

   # firewall-cmd --list-ports
   80/tcp 443/tcp

3. Verify that the nginx service is enabled:

   # systemctl is-enabled nginx
   enabled

Procedure

1. Edit the /etc/nginx/nginx.conf file:

   1. By default, the /etc/nginx/nginx.conf file already contains a catch-all configuration. If you have deleted this part from the configuration, re-add the following server block to the http block in the /etc/nginx/nginx.conf file:

      server {
          listen       80 default_server;
          listen       [::]:80 default_server;
          server_name  _;
          root         /usr/share/nginx/html;
      }

      These settings configure the following:

      • The listen directive define which IP address and ports the service listens. In this case, NGINX listens on port 80 on both all IPv4 and IPv6 addresses. The default_server parameter indicates that NGINX uses this server block as the default for requests matching the IP addresses and ports.
      • The server_name parameter defines the host names for which this server block is responsible. Setting server_name to _ configures NGINX to accept any host name for this server block.
      • The root directive sets the path to the web content for this server block.

   2. Append a similar server block for the example.com domain to the http block:

      server {
          server_name  example.com;
          root         /var/www/example.com/;
          access_log   /var/log/nginx/example.com/access.log;
          error_log    /var/log/nginx/example.com/error.log;
      }

      • The access_log directive defines a separate access log file for this domain.
      • The error_log directive defines a separate error log file for this domain.

   3. Append a similar server block for the example.net domain to the http block:

      server {
          server_name  example.net;
          root         /var/www/example.net/;
          access_log   /var/log/nginx/example.net/access.log;
          error_log    /var/log/nginx/example.net/error.log;
      }

2. Create the root directories for both domains:

   # mkdir -p /var/www/example.com/
   # mkdir -p /var/www/example.net/

3. Set the httpd_sys_content_t context on both root directories:

   # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.com(/.*)?"
   # restorecon -Rv /var/www/example.com/
   # semanage fcontext -a -t httpd_sys_content_t "/var/www/example.net(/.\*)?"
   # restorecon -Rv /var/www/example.net/

   These commands set the httpd_sys_content_t context on the /var/www/example.com/ and /var/www/example.net/ directories.

   Note that you must install the policycoreutils-python-utils package to run the restorecon commands.

4. Create the log directories for both domains:

   # mkdir /var/log/nginx/example.com/
   # mkdir /var/log/nginx/example.net/

5. Restart the nginx service:

   # systemctl restart nginx

Verification steps

1. Create a different example file in each virtual host’s document root:

   # echo "Content for example.com" > /var/www/example.com/index.html
   # echo "Content for example.net" > /var/www/example.net/index.html
   # echo "Catch All content" > /usr/share/nginx/html/index.html

2. Use a browser and connect to http://example.com. The web server shows the example content from the /var/www/example.com/index.html file.
3. Use a browser and connect to http://example.net. The web server shows the example content from the /var/www/example.net/index.html file.
4. Use a browser and connect to http://IP_address_of_the_server. The web server shows the example content from the /usr/share/nginx/html/index.html file.

Procedure

1. Edit the /etc/nginx/nginx.conf file, and add the following server block to the http block in the configuration:

   server {
       listen              443 ssl;
       server_name         example.com;
       root                /usr/share/nginx/html;
       ssl_certificate     /etc/pki/tls/certs/example.com.crt;
       ssl_certificate_key /etc/pki/tls/private/example.com.key;
   }

2. For security reasons, configure that only the root user can access the private key file:

   # chown root:root /etc/pki/tls/private/example.com.key
   # chmod 600 /etc/pki/tls/private/example.com.key

   Warning

   If the private key was accessed by unauthorized users, revoke the certificate, create a new private key, and request a new certificate. Otherwise, the TLS connection is no longer secure.

3. Restart the nginx service:

   # systemctl restart nginx

Procedure

1. Edit the /etc/nginx/nginx.conf file and add the following settings to the server block that should provide the reverse proxy:

   location /example {
       proxy_pass https://example.com;
   }

   The location block defines that NGINX passes all requests in the /example directory to https://example.com.

2. Set the httpd_can_network_connect SELinux boolean parameter to 1 to configure that SELinux allows NGINX to forward traffic:

   # setsebool -P httpd_can_network_connect 1

3. Restart the nginx service:

   # systemctl restart nginx

Procedure

1. Edit the /etc/nginx/nginx.conf file and add the following settings:

   http {
       upstream backend {
           least_conn;
           server server1.example.com;
           server server2.example.com;
           server server3.example.com backup;
       }
   
       server {
           location / {
               proxy_pass http://backend;
           }
       }
   }

   The least_conn directive in the host group named backend defines that NGINX sends requests to server1.example.com or server2.example.com, depending on which host has the least number of active connections. NGINX uses server3.example.com only as a backup in case that the other two hosts are not available.

   With the proxy_pass directive set to http://backend, NGINX acts as a reverse proxy and uses the backend host group to distribute requests based on the settings of this group.

   Instead of the least_conn load balancing method, you can specify:

   • No method to use round robin and distribute requests evenly across servers.
   • ip_hash to send requests from one client address to the same server based on a hash calculated from the first three octets of the IPv4 address or the whole IPv6 address of the client.
   • hash to determine the server based on a user-defined key, which can be a string, a variable, or a combination of both. The consistent parameter configures that NGINX distributes requests across all servers based on the user-defined hashed key value.
   • random to send requests to a randomly selected server.

2. Restart the nginx service:

   # systemctl restart nginx

Procedure

1. Run the testparm utility as the root user:

   # testparm
   Load smb config files from /etc/samba/smb.conf
   rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
   Unknown parameter encountered: "log levell"
   Processing section "[example_share]"
   Loaded services file OK.
   ERROR: The idmap range for the domain * (tdb) overlaps with the range of DOMAIN (ad)!
   
   Server role: ROLE_DOMAIN_MEMBER
   
   Press enter to see a dump of your service definitions
   
   # Global parameters
   [global]
   	...
   
   [example_share]
   	...

   The previous example output reports a non-existent parameter and an incorrect ID mapping configuration.

2. If testparm reports incorrect parameters, values, or other errors in the configuration, fix the problem and run the utility again.

Procedure

1. Edit the /etc/samba/smb.conf file, add the server min protocol parameter, and set the parameter to the minimum SMB protocol version the server should support. For example, to set the minimum SMB protocol version to SMB3, add:

   server min protocol = SMB3

2. Restart the smb service:

   # systemctl restart smb

Procedure

1. To make sure the proper NFS RPC-based services are enabled for rpcbind, use the following command:

   # rpcinfo -p

   Example 4.2. rpcinfo -p command output

   The following is sample output from this command:

      program vers proto   port  service
       100000    4   tcp    111  portmapper
       100000    3   tcp    111  portmapper
       100000    2   tcp    111  portmapper
       100000    4   udp    111  portmapper
       100000    3   udp    111  portmapper
       100000    2   udp    111  portmapper
       100005    1   udp  20048  mountd
       100005    1   tcp  20048  mountd
       100005    2   udp  20048  mountd
       100005    2   tcp  20048  mountd
       100005    3   udp  20048  mountd
       100005    3   tcp  20048  mountd
       100024    1   udp  37769  status
       100024    1   tcp  49349  status
       100003    3   tcp   2049  nfs
       100003    4   tcp   2049  nfs
       100227    3   tcp   2049  nfs_acl
       100021    1   udp  56691  nlockmgr
       100021    3   udp  56691  nlockmgr
       100021    4   udp  56691  nlockmgr
       100021    1   tcp  46193  nlockmgr
       100021    3   tcp  46193  nlockmgr
       100021    4   tcp  46193  nlockmgr

   If one of the NFS services does not start up correctly, rpcbind will be unable to map RPC requests from clients for that service to the correct port.

2. In many cases, if NFS is not present in rpcinfo output, restarting NFS causes the service to correctly register with rpcbind and begin working:

   # systemctl restart nfs-server

Procedure

1. To allow clients to access NFS shares behind a firewall, set which ports the RPC services run on in the [mountd] section of the /etc/nfs.conf file:

   [mountd]
   
   port=port-number

   This adds the -p port-number option to the rpc.mount command line: rpc.mount -p port-number.

2. To allow clients to access NFS shares behind a firewall, configure the firewall by running the following commands on the NFS server:

   firewall-cmd --permanent --add-service mountd
   firewall-cmd --permanent --add-service rpc-bind
   firewall-cmd --permanent --add-service nfs
   firewall-cmd --permanent --add-port=<mountd-port>/tcp
   firewall-cmd --permanent --add-port=<mountd-port>/udp
   firewall-cmd --reload

   In the commands, replace <mountd-port> with the intended port or a port range. When specifying a port range, use the --add-port=<mountd-port>-<mountd-port>/udp syntax.

3. To allow NFSv4.0 callbacks to pass through firewalls, set /proc/sys/fs/nfs/nfs_callback_tcpport and allow the server to connect to that port on the client.

   This step is not needed for NFSv4.1 or higher, and the other ports for mountd, statd, and lockd are not required in a pure NFSv4 environment.

4. To specify the ports to be used by the RPC service nlockmgr, set the port number for the nlm_tcpport and nlm_udpport options in the /etc/modprobe.d/lockd.conf file.

5. Restart the NFS server:

   #  systemctl restart nfs-server

   If NFS fails to start, check /var/log/messages. Commonly, NFS fails to start if you specify a port number that is already in use.

6. Confirm the changes have taken effect:

   # rpcinfo -p

Procedure

1. Enable and start the rpc-rquotad service:

   # systemctl enable --now rpc-rquotad

   Note

   The rpc-rquotad service is, if enabled, started automatically after starting the nfs-server service.

2. To make the quota RPC service accessible behind a firewall, the TCP (or UDP, if UDP is enabled) port 875 need to be open. The default port number is defined in the /etc/services file.

   You can override the default port number by appending -p port-number to the RPCRQUOTADOPTS variable in the /etc/sysconfig/rpc-rquotad file.

3. By default, remote hosts can only read quotas. If you want to allow clients to set quotas, append the -S option to the RPCRQUOTADOPTS variable in the /etc/sysconfig/rpc-rquotad file.

4. Restart rpc-rquotad for the changes in the /etc/sysconfig/rpc-rquotad file to take effect:

   # systemctl restart rpc-rquotad

Procedure

1. Install the rdma-core package:

   # yum install rdma-core

2. To enable automatic loading of NFSoRDMA server modules, add the SVCRDMA_LOAD=yes option on a new line in the /etc/rdma/rdma.conf configuration file.

   The rdma=20049 option in the [nfsd] section of the /etc/nfs.conf file specifies the port number on which the NFSoRDMA service listens for clients. The RFC 5667 standard specifies that servers must listen on port 20049 when providing NFSv4 services over RDMA.

   The /etc/rdma/rdma.conf file contains a line that sets the XPRTRDMA_LOAD=yes option by default, which requests the rdma service to load the NFSoRDMA client module.

3. Restart the nfs-server service:

   # systemctl restart nfs-server

Procedure

1. • Create the nfs/hostname.domain@REALM principal on the NFS server side.
   • Create the host/hostname.domain@REALM principal on both the server and the client side.
   • Add the corresponding keys to keytabs for the client and server.

2. On the server side, use the sec= option to enable the wanted security flavors. To enable all security flavors as well as non-cryptographic mounts:

   /export *(sec=sys:krb5:krb5i:krb5p)

   Valid security flavors to use with the sec= option are:

   • sys: no cryptographic protection, the default
   • krb5: authentication only
   • krb5i: integrity protection
   • krb5p: privacy protection

3. On the client side, add sec=krb5 (or sec=krb5i, or sec=krb5p, depending on the setup) to the mount options:

   # mount -o sec=krb5 server:/export /mnt

Procedure

1. On the server, mount the XFS file system created on the SCSI device.

2. Configure the NFS server to export NFS version 4.1 or higher. Set the following option in the [nfsd] section of the /etc/nfs.conf file:

   [nfsd]
   
   vers4.1=y

3. Configure the NFS server to export the XFS file system over NFS with the pnfs option:

   Example 6.2. An entry in /etc/exports to export pNFS SCSI

   The following entry in the /etc/exports configuration file exports the file system mounted at /exported/directory/ to the allowed.example.com client as a pNFS SCSI layout:

   /exported/directory allowed.example.com(pnfs)

Procedure

1. Query an existing reservation on the server:

   # sg_persist --read-reservation path-to-scsi-device

   Example 6.3. Querying a reservation on /dev/sda

   # sg_persist --read-reservation /dev/sda
   
     LIO-ORG   block_1           4.0
     Peripheral device type: disk
     PR generation=0x8, Reservation follows:
       Key=0x100000000000000
       scope: LU_SCOPE,  type: Exclusive Access, registrants only

2. Remove the existing registration on the server:

   # sg_persist --out \
                --release \
                --param-rk=reservation-key \
                --prout-type=6 \
                path-to-scsi-device

   Example 6.4. Removing a reservation on /dev/sda

   # sg_persist --out \
                --release \
                --param-rk=0x100000000000000 \
                --prout-type=6 \
                /dev/sda
   
     LIO-ORG   block_1           4.0
     Peripheral device type: disk

Procedure

1. Install the squid package:

   # yum install squid

2. Edit the /etc/squid/squid.conf file:

   1. Adapt the localnet access control lists (ACL) to match the IP ranges that should be allowed to use the proxy:

      acl localnet src 192.0.2.0/24
      acl localnet 2001:db8:1::/64

      By default, the /etc/squid/squid.conf file contains the http_access allow localnet rule that allows using the proxy from all IP ranges specified in localnet ACLs. Note that you must specify all localnet ACLs before the http_access allow localnet rule.

      Important

      Remove all existing acl localnet entries that do not match your environment.

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

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

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

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

4. Open the 3128 port in the firewall:

   # firewall-cmd --permanent --add-port=3128/tcp
   # firewall-cmd --reload

5. Enable and start the squid service:

   # systemctl enable --now squid

Procedure

1. Install the squid package:

   # yum install squid

2. Edit the /etc/squid/squid.conf file:

   1. To configure the basic_ldap_auth helper utility, add the following configuration entry to the top of /etc/squid/squid.conf:

      auth_param basic program /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389

      The following describes the parameters passed to the basic_ldap_auth helper utility in the example above:

      • -B base_DN sets the LDAP search base.
      • -D proxy_service_user_DN sets the distinguished name (DN) of the account Squid uses to search for the authenticating user in the directory.
      • -W path_to_password_file sets the path to the file that contains the password of the proxy service user. Using a password file prevents that the password is visible in the operating system’s process list.

      • -f LDAP_filter specifies the LDAP search filter. Squid replaces the %s variable with the user name provided by the authenticating user.

        The (&(objectClass=person)(uid=%s)) filter in the example defines that the user name must match the value set in the uid attribute and that the directory entry contains the person object class.

      • -ZZ enforces a TLS-encrypted connection over the LDAP protocol using the STARTTLS command. Omit the -ZZ in the following situations:

        • The LDAP server does not support encrypted connections.
        • The port specified in the URL uses the LDAPS protocol.
      • The -H LDAP_URL parameter specifies the protocol, the host name or IP address, and the port of the LDAP server in URL format.

   2. Add the following ACL and rule to configure that Squid allows only authenticated users to use the proxy:

      acl ldap-auth proxy_auth REQUIRED
      http_access allow ldap-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.

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

4. Store the password of the LDAP service user in the /etc/squid/ldap_password file, and set appropriate permissions for the file:

   # echo "password" > /etc/squid/ldap_password
   # chown root:squid /etc/squid/ldap_password
   # chmod 640 /etc/squid/ldap_password

5. Open the 3128 port in the firewall:

   # firewall-cmd --permanent --add-port=3128/tcp
   # firewall-cmd --reload

6. Enable and start the squid service:

   # systemctl enable --now squid

1. Manually start the helper utility with the same settings you used in the auth_param parameter:

   # /usr/lib64/squid/basic_ldap_auth -b "cn=users,cn=accounts,dc=example,dc=com" -D "uid=proxy_user,cn=users,cn=accounts,dc=example,dc=com" -W /etc/squid/ldap_password -f "(&(objectClass=person)(uid=%s))" -ZZ -H ldap://ldap_server.example.com:389

2. Enter a valid user name and password, and press Enter:

   user_name password

   If the helper utility returns OK, authentication succeeded.

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

    # systemctl enable --now squid

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

Procedure

1. Edit the /etc/squid/squid.conf file and add the following settings:

   acl domain_blacklist dstdomain "/etc/squid/domain_blacklist.txt"
   http_access deny all domain_blacklist

   Important

   Add these entries before the first http_access allow statement that allows access to users or clients.

2. Create the /etc/squid/domain_blacklist.txt file and add the domains you want to block. For example, to block access to example.com including subdomains and to block example.net, add:

   .example.com
   example.net

   Important

   If you referred to the /etc/squid/domain_blacklist.txt file in the squid configuration, this file must not be empty. If the file is empty, Squid fails to start.

3. Restart the squid service:

   # systemctl restart squid