Contexte

Procédure de mise en place de l’authentification Kerberos dans un environnement avec Haute Disponibilité / Répartition des charges

L’authentification Kerberos AD permet d’authentifier des utilisateurs issus d’un annuaire Active Directory, de façon transparente pour l’utilisateur, dans un mode d’intégration proxy explicite.

Kerberos se repose sur les Service Principal Names (SPNs) qui sont associés à des objets dans Active Directory.

Dans un environnement avec répartition des charges et haute disponibilité, les équipements clients accèdent au proxy au travers d’un nom FQDN « générique » qui peut être différent de celui porté par l’équipement Olfeo.

Cela peut se produire, par exemple, dans les situations suivantes :

• Un équipement tiers (HAProxy, NetScaler, Kemp, F5, nginx, etc.) est exploité pour gérer la haute disponibilité et/ou la répartition des charges entre plusieurs équipements Olfeo
• Un cluster Olfeo avec des adresses IP virtuelles est exploité pour la haute disponibilité
• Un script de proxy avec un algorithme de répartition des charges basé sur du round-robin (tourniquet) DNS est exploité

Attention : Dans le cas d’une intégration avec répartiteur de charge tiers (HAProxy, NetScaler, ect…), il ne faut pas se baser sur les adresses IP virtuelles des Olfeo mais sur leurs adresses IP réelles.

Dans l’exemple suivant, les navigateurs des postes clients sont configurés pour accéder à Internet au travers d’un équipement tiers de type répartiteur de charge dont l’adresse est lba.formation.local :

Le répartiteur transmets ensuite les flux HTTP aux 2 équipements Olfeo nommés proxy1.formation.local et proxy2.formation.local :

Procédure

Chaque équipement Olfeo doit pouvoir déchiffrer les tickets Kerberos lorsqu’il est sollicité par les clients depuis l’adresse lba.formation.local à la place (ou en +) d’être sollicité directement par les clients depuis leur FQDN (ex : proxy1.formation.local).

Les commandes ci-dessous sont à exécuter sur PowerShell (ou dans une invite de commande MS-DOS avec les privilèges administrateur) sur 1 contrôleur de domaine :

1. Création d’un compte de service AD (à adapter en fonction de votre nom de domaine) :

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 : le mot de passe doit être adapté en présence de restrictions sur la complexité des mots de passe des utilisateurs de l’annuaire.

2. Modification des propriétés de l’utilisateur pour ajout du SPN Host (à adapter en fonction de votre nom de domaine) :

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

3. Création du fichier keytab (à adapter en fonction de votre nom de domaine) :

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 : en cas d’erreur, vérifiez la présence de l’utilisateur olfeo-krb dans l’annuaire et déplacez-le dans l’OU des utilisateurs

A cette étape nous disposons du fichier C:\HTTP_new.keytab sur le contrôleur de domaine, nous pouvons le fusionner avec le fichier existant /etc/squid/HTTP.keytab sur les machines proxy1.formation.local et proxy2.formation.local pour que les postes clients puissent s’adresser aux proxy via les 2 FQDN proxy1.formation.local / proxy2.formation.local et lba.formation.local tout en assurant  une authentification Kerberos fonctionnelle.

Transférer le fichier HTTP_new.keytab sur chaque machine Olfeo, dans le répertoire /etc/squid/ (ou /etc/squid3/ si vous disposez d’une version antérieure à la v6.4 d’Olfeo). Si l’équipement Olfeo est une machine virtuelle ou une machine physique avec une installation logicielle, le fichier doit être copié dans le répertoire /opt/olfeo/chroot/etc/squid/.

1. Connectez-vous en SSH à l’équipement Olfeo, et accédez au chroot s’il s’agit d’une machine virtuelle ou d’une machine physique avec une installation logicielle :

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

2. Accéder au répertoire de squid :

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

Fusionner les 2 fichiers keytab (celui avec le SPN du compte machine et celui créé avec le SPN générique, nécessaire à la migration de l’un vers l’autre sans impact) :

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

ktutil: rkt HTTP.keytab

ktutil: rkt HTTP_new.keytab

ktutil: wkt HTTP_merge.keytab

ktutil: quit

3. Changer les propriétés du fichier généré :

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

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

4. Remplacement du fichier utilisé :

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

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

5. Afficher la liste des clés et l’horodatage de chaque entrée du fichier keytab. Assurez-vous de la présence du SPN HTTP/FQDN@DOMAINE pour l’accès au service depuis le nom « générique »:

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

6. Redémarrer le service du proxy squid :

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

Une fois ces opérations effectuées, vous pourrez accéder à Internet au travers de l’infrastructure proxy depuis les postes clients en renseignant le nom générique dans les paramètres proxy.