Cette page décrit un exemple de configuration de Kerberos pour que le serveur Zabbix effectue la surveillance web de www.example.com avec un principal Kerberos pour le processus Zabbix sur Debian/Ubuntu.

Configuration

1. Installer KDC et les utilitaires client :

sudo apt update
sudo apt install krb5-kdc krb5-admin-server krb5-user

Lors de la configuration des paquets, répondez aux invites, par exemple :

Default Kerberos version 5 realm: EXAMPLE.COM
Kerberos servers for your realm: localhost (or your FQDN)
Administrative server for your Kerberos realm: localhost (or your FQDN)

2. Mapper un nom d’hôte convivial (facultatif, pour les tests locaux).

Modifiez /etc/hosts et ajoutez une entrée pour votre contrôleur de domaine et votre serveur web si vous ne disposez pas de DNS :

sudo vi /etc/hosts

Exemple de ligne à ajouter :

192.168.1.100  dc01.example.com dc01

3. Configurer le client Kerberos et le domaine KDC :

sudo vi /etc/krb5.conf

Exemple de configuration :

[libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false
    rdns = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

[realms]
    EXAMPLE.COM = {
        kdc = dc01.example.com
        admin_server = dc01.example.com
    }

[domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM

Si vous prévoyez d’utiliser .localdomain ou d’autres noms non publics, ajoutez des mappages explicites domaine→domaine Kerberos afin que le mappage nom d’hôte→domaine Kerberos fonctionne. Les incohérences à ce niveau provoquent des erreurs Server not found in Kerberos database.

4. Initialiser la base de données Kerberos (une seule fois, sur l’hôte KDC). Définissez un mot de passe principal sécurisé lorsque vous y êtes invité :

sudo krb5_newrealm

5. Créer le principal HTTP/host.fqdn@REALM en utilisant le nom d’hôte exact que les clients utiliseront ; privilégiez les minuscules (par exemple, HTTP/[email protected]). Une différence de casse ou de nom provoque l’erreur Server not found in Kerberos database.

sudo kadmin.local

Dans kadmin.local :

addprinc [email protected]     # principal administratif
addprinc -randkey HTTP/[email protected]
ktadd -k /etc/apache2/http.keytab HTTP/[email protected]
quit

Déplacez le keytab vers l’hôte web (ou conservez-le localement s’il s’agit de la même machine) et définissez des permissions permettant à Apache de l’utiliser :

chown www-data:www-data /etc/apache2/http.keytab
chmod 600 /etc/apache2/http.keytab
# vérifier
sudo -u www-data -k /etc/apache2/http.keytab

6. Installer et activer le module GSSAPI d’Apache :

sudo apt install libapache2-mod-auth-gssapi
sudo a2enmod auth_gssapi
sudo a2enmod headers
sudo systemctl restart apache2

Toutes les versions de mod_auth_gssapi ne prennent pas en charge chaque directive Gssapi*. Si Apache échoue avec Invalid command 'GssapiCredStore', supprimez la directive non prise en charge ou mettez à niveau le module.

7. Configurer un VirtualHost (adaptez DocumentRoot / le chemin vers votre interface Zabbix) :

sudo vi /etc/apache2/sites-available/zabbix.conf

Dans zabbix.conf :

<VirtualHost *:80>
    ServerName dc01.example.com
    DocumentRoot /usr/share/zabbix/ui
    <Directory /usr/share/zabbix/ui>
        Options FollowSymLinks
        AllowOverride None
        Require all granted
        AuthType GSSAPI
        AuthName "Kerberos Login"
        GssapiCredStore keytab:/etc/apache2/http.keytab
        GssapiLocalName On
        Require valid-user
    </Directory>
    RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER
    RequestHeader unset Authorization
</VirtualHost>

Redémarrer Apache :

sudo systemctl restart apache2

8. Activer/démarrer les services KDC et vérifier les ports en écoute (hôte KDC) :

sudo systemctl enable --now krb5-kdc krb5-admin-server
ss -tnlp | grep :80    # ou : sudo netstat -tnlp | grep :80

9. Obtenir un TGT pour les tests (exécutez cette commande avec l’utilisateur qui utilisera le ticket).

Vous devez voir krbtgt/[email protected] dans la liste des tickets. Exécutez kinit avec le même utilisateur du système d’exploitation que celui qui a besoin du ticket (par exemple, zabbix pour les vérifications web ou www-data/Apache pour les tests SSO dans un navigateur interactif). Les tickets attribués à un autre utilisateur du système d’exploitation ne seront pas visibles, sauf si KRB5CCNAME et les permissions sont ajustés.

kinit [email protected]
klist

10. Tester l’échange SPNEGO avec curl (depuis un client disposant d’un TGT valide). Une réponse 200 OK (ou une redirection vers l’application) indique que SPNEGO a réussi :

curl -v --negotiate -u : http://dc01.example.com/

11. Facultatif : si l’interface Zabbix doit accepter les connexions authentifiées via HTTP, activez l’authentification HTTP dans l’interface Zabbix (ui/conf/zabbix.conf.php) :

$ALLOW_HTTP_AUTH = true;

Dans l’interface web, accédez à Utilisateurs > Authentification et ouvrez l’onglet Paramètres HTTP. Cochez Activer l’authentification HTTP, puis cliquez sur OK dans la fenêtre contextuelle. Sélectionnez « Formulaire de connexion HTTP » dans la liste déroulante Formulaire de connexion par défaut. Déterminez si l’option Connexion sensible à la casse correspond à la politique de votre annuaire. Cliquez sur le bouton Mettre à jour pour terminer.

12. Configuration du navigateur (Firefox est utilisé comme exemple) : définissez network.negotiate-auth.trusted-uris sur le ou les hôtes effectuant la négociation (dc01.example.com) afin que le navigateur envoie automatiquement les jetons Kerberos.

Dans about:config :

network.negotiate-auth.trusted-uris = dc01.example.com

En accédant maintenant à http://dc01.example.com, vous devriez être connecté directement à Zabbix sans passer par le formulaire.

13. Maintenir les clés et les tickets à jour. La durée de vie par défaut d’un ticket Kerberos est d’environ 10 heures. Ajoutez une tâche cron ou un minuteur systemd pour éviter les expirations :

#pour le service web
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#pour l’utilisateur de supervision
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Vérifications de maintenance :

klist -k /etc/apache2/http.keytab - vérifier que le principal de service est présent dans le keytab.
sudo tail -f /var/log/apache2/error.log - surveiller les erreurs GSSAPI (gss_acquire_cred[_from]() failed to get server creds signifie un problème de keytab/permissions ou l’absence du principal).
Si curl --negotiate renvoie 401/403, cela signifie souvent que le principal est incorrect, qu’aucun ticket n’est disponible, que l’en-tête d’hôte ne correspond pas ou qu’un problème de permissions du système de fichiers est présent ; vérifiez les journaux et les mappages de domaines dans /etc/krb5.conf.

Remarques sur la sécurité et les permissions des fichiers

Les fichiers keytab doivent être lisibles uniquement par le compte qui en a besoin. Exemples de permissions : 0400, avec zabbix:zabbix comme propriétaire pour un keytab utilisateur zabbix, ou 0440, avec root:www-data comme propriétaire pour un keytab Apache.

Évitez de stocker des mots de passe en clair à longue durée de validité sur l’hôte. Utilisez des keytabs ou des principaux de machine joints au domaine lorsque cela est possible.

Lors de l’exécution de tests ou de scripts qui définissent KRB5CCNAME ou copient des keytabs, vérifiez à nouveau le propriétaire et les permissions après l’opération : lorsqu’un serveur web rejette des identifiants, le problème provient souvent des permissions d’un fichier.

Quelle est la prochaine étape ?

14 paramètres de modbus.get

Docs

13 Configuration de Kerberos avec Zabbix

Aperçu

Configuration

Remarques sur la sécurité et les permissions des fichiers

Quelle est la prochaine étape ?

Suggérer une modification

Suggérer un exemple

Merci !