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 utilità client:

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

Durante la configurazione del pacchetto, 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 nome host intuitivo (facoltativo, per i test locali).

Modificare /etc/hosts e aggiungere una voce per il DC e il webserver se non si dispone del 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

Impostazioni di esempio:

[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 utilizzare .localdomain o altri nomi non pubblici, aggiungere mappature esplicite dominio→realm affinché la mappatura nome host→realm funzioni. Le discrepanze in questa configurazione causano errori Server not found in Kerberos database.

4. Inizializzare il database Kerberos (una sola volta, sull'host KDC). Quando richiesto, impostare una password master sicura:

sudo krb5_newrealm

5. Creare il principal HTTP/host.fqdn@REALM utilizzando il nome host esatto che verrà usato dai client; preferire le lettere minuscole (ad esempio, HTTP/[email protected]). Una differenza tra maiuscole/minuscole o nel nome causa l'errore 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 sull'host web (oppure mantenerlo localmente se si tratta della stessa macchina) e impostare autorizzazioni 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 GSSAPI di Apache:

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 restituisce l'errore Invalid command 'GssapiCredStore', rimuovere la direttiva non supportata oppure aggiornare il modulo.

7. Configurare un VirtualHost (adattare DocumentRoot / il percorso alla propria interfaccia 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 i test (eseguire come l'utente che utilizzerà il ticket).

Nell'elenco dei ticket dovrebbe essere visualizzato krbtgt/[email protected]. 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 i test SSO interattivi nel browser). I ticket rilasciati a un altro utente del sistema operativo non saranno visibili, a meno che non vengano modificati KRB5CCNAME e le autorizzazioni.

kinit [email protected]
klist

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

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

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

$ALLOW_HTTP_AUTH = true;

Nell'interfaccia web, accedere a 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. Stabilire se Case-sensitive login è compatibile con i criteri della directory. Fare clic sul pulsante Update per terminare.

12. Configurazione del browser (Firefox viene utilizzato 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.

All'interno di about:config:

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

Visitando ora http://dc01.example.com, si dovrebbe accedere direttamente a Zabbix senza visualizzare il modulo.

13. Mantenere aggiornati chiavi e ticket. La durata predefinita di un ticket Kerberos è di circa 10 ore. Aggiungere un timer cron/systemd per evitare le 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 del servizio sia presente nel keytab.
  • sudo tail -f /var/log/apache2/error.log - monitorare gli errori GSSAPI (gss_acquire_cred[_from]() failed to get server creds indica un problema con il keytab/le autorizzazioni oppure un principal mancante).
  • Se curl --negotiate restituisce 401/403, spesso la causa è un principal errato, l'assenza di un ticket, una mancata corrispondenza dell'header host oppure un problema di autorizzazioni del file system; controllare i log e le mappature dei domini 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 proprietario root:www-data per un keytab di Apache.

Evitare di memorizzare password in chiaro a lunga durata sul host. Utilizzare keytab o principal di macchine aggiunte al dominio, ove possibile.

Quando si eseguono test o script che impostano KRB5CCNAME o copiano keytab, verificare nuovamente il proprietario e i permessi dopo l'operazione: se un webserver rifiuta le credenziali, spesso il problema riguarda i permessi dei file.