▶ BLOG

KB 2782: KERBEROS AUTHENTICATION AND LOAD BALANCING/HIGH AVAILABILITY:

KB OLFEO On-Premise
November 27, 2023

Background

Procedure for setting up Kerberos authentication in a High Availability/Load Balancing environment

Kerberos AD authentication allows users from an Active Directory directory to be authenticated transparently to the user in an explicit proxy integration mode.

Kerberos relies on Service Principal Names (SPNs) that are associated with objects in Active Directory.

In a load-balanced, high-availability environment, client devices access the proxy through a "generic" FQDN that may be different from the one used by the Olfeo device.

This can happen, for example, in the following situations:

  • Third-party equipment (HAProxy, NetScaler, Kemp, F5, nginx, etc.) is used to manage high availability and/or load balancing between multiple Olfeo devices.
  • An Olfeo cluster with virtual IP addresses is used for high availability.
  • A proxy script with a round-robin DNS load balancing algorithm is exploited.

Please note: When integrating with a third-party load balancer (HAProxy, NetScaler, etc.), do not use the virtual IP addresses of the Olfeo servers; use their real IP addresses instead.

In the following example, client workstation browsers are configured to access the Internet through third-party load balancing equipment with the address loadbalancer.lab.lan.olfeo.com. The load balancer then transmits HTTP traffic to two Olfeo devices named proxy1.lab.lan.olfeo.com and proxy2.lab.lan.olfeo.com.

Each Olfeo device must be able to decrypt Kerberos tickets when requested by clients from the loadbalancer.lan.lan.olfeo.com address instead of (or in addition to) being requested directly by clients from their FQDN (e.g., proxy1.lab.lan.olfeo.com).

Therefore, each Olfeo device must have the private key (keytab) corresponding to the SPN (that of the FQDN loadbalancer.lan.lan.olfeo.com) in order to decrypt Kerberos tickets and authenticate users.

 

Procedure

The commands below should be run on PowerShell (or in an MS-DOS command prompt with administrator privileges) on one domain controller:

1. Create an AD service account (to be adapted according to your domain name):

New-ADUser -Name "Compte Olfeo authentification Kerberos" -UserPrincipalName olfeo-krb@lab.lan.olfeo.com -SamAccountName "olfeo-krb" -PasswordNeverExpires $true -Enabled $true -AccountPassword (ConvertTo-SecureString -AsPlainText "P@ssw0rd" -Force)

Note: The password must be adjusted if there are restrictions on the complexity of directory users' passwords.

Note: If you want to use AES256 or AES128 for Kerberos encryption, you must enable them for this Kerberos service account in your Active Directory.

2. Modify user properties to add the SPN Host (to be adapted according to your domain name):

Set-AdUser -Identity olfeo-krb -ServicePrincipalNames @{Add="HOST/loadbalancer.lab.lan.olfeo.com"}

3. Create the keytab file (adapt it according to your domain name):                                                                                                             

ktpass -princ HTTP/loadbalancer.lab.lan.olfeo.com@LAB.LAN.OLFEO.COM -mapuser olfeo-krb@lab.lan.olfeo.com -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass P@ssw0rd -out C:\HTTP_new.keytab -setupn +dumpsalt -rawsalt LAB.LAN.OLFEO.COMolfeo-krb

Note: Since KB5082142 (April 2026)

Note : If an error occurs, check that the user olfeo-krb is present in the directory and move them to the users OU.

Note: In the command above, P@ssword must match the Kerberos service account created earlier.

At this stage, we have the C:\HTTP_new.keytab file on the domain controller. We can merge it with the existing /etc/squid/HTTP.keytab file on the proxy1.lab.lan.olfeo.com and proxy2.lab.lan.olfeo.com so that client workstations can address the proxies via the two FQDNs proxy1.lab.lan.olfeo.com / proxy2.lab.lan.olfeo.com and loadbalancer.lab.lan.olfeo.com while ensuring functional Kerberos authentication.

Transfer the HTTP_new.keytab file to each Olfeo machine, in the /etc/squid/ directory (or /etc/squid3/ if you have a version of Olfeo earlier than v6.4). If the Olfeo equipment is a virtual machine or a physical machine with a software installation, the file must be copied to the /opt/olfeo/chroot/etc/squid/ directory in version 6 and /etc/squid/ in version 7.

4. Connect to the Olfeo device via SSH (enter the chroot directory if you are using Olfeo version 6: root@proxy1:~# chroot /opt/olfeo/chroot/)

5. Access the Squid directory:

root@proxy1:/# cd /etc/squid/

6. Merge the two keytab files (the one with the machine account’s SPN and the one created with the generic SPN, which is necessary for migrating from one to the other without any issues):

root@proxy1:/etc/squid# ktutil

ktutil: rkt HTTP keytab

ktutil: rkt HTTP_new.keytab

ktutil: wkt HTTP_merge.keytab

ktutil: quit

7. Change the properties of the generated file:

root@proxy1:/etc/squid# chmod 640 HTTP_merge.keytab

root@proxy1:/etc/squid# chown root:proxy HTTP_merge.keytab

8. Replacing the file in use:

root@proxy1:/etc/squid# move HTTP.keytab to HTTP_ori.keytab

root@proxy1:/etc/squid# ln -s HTTP_merge.keytab HTTP.keytab

9. Display the list of keys and the timestamp for each entry in the keytab file. Verify that the SPN HTTP/FQDN@DOMAIN is present for accessing the service using the "generic" name:

root@proxy1:/etc/squid# klist -kt HTTP.keytab













10. Restart the Squid proxy service:

root@proxy1:/etc/squid# service squid restart

Once these operations have been completed, you will be able to access the Internet through the proxy infrastructure from client workstations by entering the generic name in the proxy settings.