How to
KB N°2782

Authentification Kerberos et Répartition des charges / Haute Disponibilité

Version: V6.x
Publié le mercredi 25 septembre 2019
Modifié le mercredi 16 octobre 2019

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

 

CONTEXTE

 

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é

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 

 

 

PROCEDURE

 

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)

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

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.

Avez-vous trouvé cet article utile ?
Revenir à la liste des articles
En visitant ce site, vous acceptez l'utilisation de cookies. Nous utilisons des cookies pour améliorer votre navigation sur notre site. En savoir plus.Ok