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. Installa KDC e le utility client:
sudo apt update
sudo apt install krb5-kdc krb5-admin-server krb5-user
Durante la configurazione dei pacchetti, rispondi ai prompt, 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. Mappa un hostname leggibile (opzionale, per test locali).
Modifica /etc/hosts e aggiungi una voce per il tuo DC e il webserver se non hai DNS:
sudo vi /etc/hosts
Esempio di riga che potresti aggiungere:
192.168.1.100 dc01.example.com dc01
3. Configura il client Kerberos e il realm del 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 prevedi di usare .localdomain o altri nomi non pubblici, aggiungi mapping espliciti domain→realm in modo che il mapping hostname→realm funzioni.
Eventuali incongruenze qui causano errori Server not found in Kerberos database.
4. Inizializza il database Kerberos (operazione una tantum, host KDC). Imposta una password master sicura quando richiesto:
sudo krb5_newrealm
5. Crea il principal HTTP/host.fqdn@REALM usando l'hostname esatto che i client utilizzeranno; preferisci il minuscolo (ad esempio HTTP/[email protected]).
Una mancata corrispondenza di maiuscole/minuscole o del nome causa Server not found in Kerberos database.
sudo kadmin.local
All'interno di kadmin.local:
addprinc [email protected] # administrative principal
addprinc -randkey HTTP/[email protected]
ktadd -k /etc/apache2/http.keytab HTTP/[email protected]
quit
Sposta il keytab sull'host web (oppure lascialo in locale se è la stessa macchina) e imposta permessi utilizzabili da Apache:
chown www-data:www-data /etc/apache2/http.keytab
chmod 600 /etc/apache2/http.keytab
# verify
sudo -u www-data -k /etc/apache2/http.keytab
6. Installa e abilita 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', rimuovi la direttiva non supportata oppure aggiorna il modulo.
7. Configura un VirtualHost (adatta DocumentRoot / il percorso alla tua 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>
Riavvia Apache:
sudo systemctl restart apache2
8. Abilita/avvia i servizi KDC e verifica le porte in ascolto (host KDC):
sudo systemctl enable --now krb5-kdc krb5-admin-server
ss -tnlp | grep :80 # or: sudo netstat -tnlp | grep :80
9. Ottieni un TGT per il test (esegui come utente che utilizzerà il ticket).
Dovresti vedere krbtgt/[email protected] nell'elenco dei ticket.
Esegui kinit come lo stesso utente OS che necessita del ticket (ad esempio zabbix per i controlli web oppure www-data/Apache per i test SSO interattivi nel browser).
I ticket emessi per un utente OS diverso non saranno visibili a meno che KRB5CCNAME e i permessi non vengano modificati.
kinit [email protected]
klist
10. Testa lo scambio SPNEGO con curl (da un client con un TGT valido).
Un 200 OK (o un redirect all'app) indica che SPNEGO è riuscito:
curl -v --negotiate -u : http://dc01.example.com/
11. Facoltativamente, se l'interfaccia Zabbix deve accettare login autenticati via HTTP, abilita l'autenticazione HTTP nel frontend Zabbix (ui/conf/zabbix.conf.php):
$ALLOW_HTTP_AUTH = true;
Nella web UI vai su Users > Authentication e spostati nella scheda HTTP settings. Seleziona la casella Enable HTTP authentication e fai clic su Ok nel pop-up. Seleziona "HTTP login form" nel menu a discesa Default login form. Valuta se Case-sensitive login è adatto alla policy della tua directory. Fai clic sul pulsante Update per завершare.
12. Configurazione del browser (Firefox è usato come esempio): imposta 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
A questo punto, visitando http://dc01.example.com dovresti accedere direttamente a Zabbix senza usare il modulo.
13. Mantieni chiavi/ticket aggiornati. La durata predefinita del ticket Kerberos è di circa 10 ore. Aggiungi un cron/systemd timer per evitare la scadenza:
#for the web service
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#for the monitoring user
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]
14. Controlli di manutenzione:
klist -k /etc/apache2/http.keytab— verifica che il service principal sia presente nel keytab.sudo tail -f /var/log/apache2/error.log— monitora gli errori GSSAPI (gss_acquire_cred[_from]() failed to get server credsindica problemi di keytab/permessi o principal mancante).- Se
curl --negotiaterestituisce 401/403, spesso significa principal errato, ticket assente, mismatch dell'host header o problema di permessi del filesystem; controlla i log e i mapping domain 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.