Context

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

Kerberos AD authentication is used to authenticate users from an Active Directory directory, transparently for the user, in an explicit proxy integration mode.

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

In a load-balanced, high-availability environment, client equipment accesses the proxy via a "generic" FQDN, which may be different from that carried by the Olfeo equipment.

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

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

Caution: In the case of integration with third-party load balancers (HAProxy, NetScaler, etc.), the Olfeo's virtual IP addresses should not be used as a basis, but their real IP addresses.

In the following example, client browsers are configured to access the Internet via a third-party load balancer whose address is lba.formation.local:

The dispatcher then transmits the HTTP flows to the 2 Olfeo devices named proxy1.formation.local and proxy2.formation.local :

Procedure

Each Olfeo device must be able to decrypt Kerberos tickets when requested by customers from the address lba.formation.local instead of (or in addition to) being requested directly by customers from their FQDN (e.g. proxy1.formation.local).

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

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

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

Note: the password must be adapted if there are restrictions on the complexity of directory user passwords.

2. Modify user properties to add SPN Host (adapt to your domain name) :

Set-AdUser -Identity olfeo-krb -ServicePrincipalNames @{Add="HOST/lba.formation.local"}

3. Creation of the keytab file (to be adapted to your domain name) :

ktpass -princ HTTP/lba.formation.local@FORMATION.LOCAL -mapuser olfeo-krb@formation.local -crypto all -ptype KRB5_NT_PRINCIPAL -pass P@ssw0rd -out c:\HTTP_new.keytab -setupn

Note : in the event of an error, check the presence of the user olfeo-krb in the directory and move it to the user OU.

At this stage we have the C:\HTTP_new.keytab file on the domain controller, which we can merge with the existing /etc/squid/HTTP.keytab file on the proxy1.formation.local and proxy2.formation.local machines, so that client workstations can address the proxies via the 2 FQDNs proxy1.formation.local / proxy2.formation.local and lba.formation.local, 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 prior to Olfeo v6.4). If the Olfeo device 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.

1. Connect to the Olfeo device via SSH, and access the chroot if it is a virtual machine or a physical machine with a software installation:

root@proxy1:~# chroot /opt/olfeo/chroot/

2. Access the squid directory :

[Olfeo] root@proxy1:/# cd /etc/squid/

Merge the 2 keytab files (the one with the machine account SPN and the one created with the generic SPN, necessary for migration from one to the other without impact):

[Olfeo] root@proxy1:/etc/squid# ktutil

ktutil: rkt HTTP.keytab

ktutil: rkt HTTP_new.keytab

ktutil: wkt HTTP_merge.keytab

ktutil: quit

3. Change the properties of the generated file :

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

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

4. Replacing the file used :

[Olfeo] root@proxy1:/etc/squid# mv HTTP.keytab HTTP_ori.keytab

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

5. Display the list of keys and the timestamp of each entry in the keytab file. Check that the SPN HTTP/FQDN@DOMAINE is present for access to the service from the "generic" name:

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

6. Restart the squid proxy service:

[Olfeo] root@proxy1:/etc/squid# service squid restart

Once these operations have been carried out, you can access the Internet via the proxy infrastructure from client workstations by entering the generic name in the proxy parameters.