13 Configurazione di Kerberos con Zabbix

Panoramica

L'autenticazione Kerberos può essere utilizzata nel monitoraggio web e negli item HTTP in Zabbix.

Questa pagina descrive un esempio di configurazione di Kerberos per il server Zabbix, in modo da eseguire il monitoraggio web di www.example.com con un principal Kerberos per il processo Zabbix su Debian/Ubuntu.

Configurazione

1. Installare KDC e le utility client:

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

Durante la configurazione dei pacchetti, rispondere alle richieste, ad esempio:

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. Mappare un hostname descrittivo (opzionale, per test locali).

Modificare /etc/hosts e aggiungere una voce per il proprio DC e webserver se non si dispone di DNS:

sudo vi /etc/hosts

Esempio di riga da aggiungere:

192.168.1.100  dc01.example.com dc01

3. Configurare il client Kerberos e il realm KDC:

sudo vi /etc/krb5.conf

Esempio di impostazioni:

[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

Se si prevede di usare .localdomain o altri nomi non pubblici, aggiungere mappature esplicite dominio→realm in modo che la mappatura hostname→realm funzioni. Le incongruenze in questo punto causano errori Server not found in Kerberos database.

4. Inizializzare il database Kerberos (una sola volta, sul host KDC). Impostare una password master sicura quando richiesto:

sudo krb5_newrealm

5. Creare il principal HTTP/host.fqdn@REALM usando l'hostname esatto che i client utilizzeranno; preferire lettere minuscole (ad esempio HTTP/[email protected]). Una mancata corrispondenza tra maiuscole/minuscole o nomi causa Server not found in Kerberos database.

sudo kadmin.local

All'interno di kadmin.local:

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

Spostare il keytab sul web host (oppure lasciarlo in locale se si tratta della stessa macchina) e impostare permessi utilizzabili da Apache:

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

6. Installare e abilitare il modulo Apache GSSAPI:

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

Non tutte le versioni di mod_auth_gssapi supportano ogni direttiva Gssapi*. Se Apache fallisce con Invalid command 'GssapiCredStore', rimuovere la direttiva non supportata oppure aggiornare il modulo.

7. Configurare un VirtualHost (adattare DocumentRoot / il percorso alla propria UI di Zabbix):

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

All'interno di 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>

Riavviare Apache:

sudo systemctl restart apache2

8. Abilitare/avviare i servizi KDC e verificare le porte in ascolto (host KDC):

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

9. Ottenere un TGT per il test (eseguire come l'utente che userà il ticket).

Ci si aspetta di vedere krbtgt/[email protected] nell'elenco dei ticket. Eseguire kinit come lo stesso utente del sistema operativo che necessita del ticket (ad esempio zabbix per i controlli web oppure www-data/Apache per test SSO interattivi nel browser). I ticket emessi per un utente del sistema operativo diverso non saranno visibili a meno che KRB5CCNAME e i permessi non vengano adattati.

kinit [email protected]
klist

10. Testare lo scambio SPNEGO con curl (da un client con un TGT valido). Un 200 OK (oppure un reindirizzamento all'applicazione) indica che SPNEGO è riuscito:

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

11. Facoltativamente, se la UI di Zabbix deve accettare accessi autenticati via HTTP, abilitare l'autenticazione HTTP nel frontend di Zabbix (ui/conf/zabbix.conf.php):

$ALLOW_HTTP_AUTH = true;

Nella web UI andare in Users > Authentication e passare alla scheda HTTP settings. Selezionare la casella Enable HTTP authentication e fare clic su Ok nella finestra pop-up. Selezionare "HTTP login form" nell'elenco a discesa Default login form. Decidere se Case-sensitive login è adatto alla propria policy di directory. Fare clic sul pulsante Update per completare.

12. Configurazione del browser (Firefox è usato come esempio): impostare network.negotiate-auth.trusted-uris sugli host che eseguono Negotiate (dc01.example.com) in modo che il browser invii automaticamente i token Kerberos.

In about:config:

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

Ora, visitando http://dc01.example.com si dovrebbe accedere direttamente a Zabbix senza il modulo di login.

13. Mantenere chiavi/ticket aggiornati. La durata predefinita di un ticket Kerberos è di circa 10 ore. Aggiungere un timer cron/systemd per evitare scadenze:

#per il servizio web
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#per l'utente di monitoraggio
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Controlli di manutenzione:

  • klist -k /etc/apache2/http.keytab — verificare che il principal di servizio sia presente nel keytab.
  • sudo tail -f /var/log/apache2/error.log — monitorare eventuali errori GSSAPI (gss_acquire_cred[_from]() failed to get server creds indica keytab/permessi errati o principal mancante).
  • curl --negotiate che restituisce 401/403 spesso indica principal errato, ticket assente, mancata corrispondenza dell'header host oppure un problema di permessi del filesystem; controllare i log e le mappature di dominio in /etc/krb5.conf.

Note sulla sicurezza e sui permessi dei file

I file keytab devono essere leggibili solo dall'account che ne ha bisogno. Esempi di permessi: 0400 con proprietario zabbix:zabbix per un keytab dell'utente zabbix, oppure 0440 e root:www-data per un keytab di Apache.

Evitare di memorizzare password in chiaro a lunga durata sul host. Quando possibile, utilizzare keytab o principal di macchina aggiunti al dominio.

Quando si eseguono test o script che impostano KRB5CCNAME o copiano keytab, ricontrollare proprietà e permessi dopo l'operazione: il rifiuto delle credenziali da parte di un webserver è spesso dovuto a un problema di permessi dei file.