[comment]: # ({930fae3b-930fae3b}) # 13 Configurazione di Kerberos con Zabbix [comment]: # ({/930fae3b-930fae3b}) [comment]: # ({bfbefd40-5be9f534}) #### 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. [comment]: # ({/bfbefd40-5be9f534}) [comment]: # ({e94370cd-edb96e72}) #### Configurazione 1\. Installa KDC e le utility client: ```bash sudo apt update sudo apt install krb5-kdc krb5-admin-server krb5-user ``` Durante la configurazione del pacchetto, rispondi ai prompt, ad esempio: ```default 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: ```bash sudo vi /etc/hosts ``` Esempio di riga che potresti aggiungere: ```ini 192.168.1.100 dc01.example.com dc01 ``` 3\. Configura il client Kerberos e il realm KDC: ```bash sudo vi /etc/krb5.conf ``` Impostazioni di esempio: ```ini [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 dominio→realm in modo che il mapping hostname→realm funzioni. Eventuali discrepanze qui causano errori `Server not found in Kerberos database`. 4\. Inizializza il database Kerberos (operazione una tantum, host KDC). Quando richiesto, imposta una master password sicura: ```bash 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/web.example.com@EXAMPLE.COM`). Una discrepanza di maiuscole/minuscole o di nome causa `Server not found in Kerberos database`. ```bash sudo kadmin.local ``` Dentro `kadmin.local`: ```bash addprinc kerb-admin@EXAMPLE.COM # administrative principal addprinc -randkey HTTP/dc01.example.com@EXAMPLE.COM ktadd -k /etc/apache2/http.keytab HTTP/dc01.example.com@EXAMPLE.COM quit ``` Sposta il keytab sull'host web (oppure lascialo in locale se è la stessa macchina) e imposta permessi utilizzabili da Apache: ```bash 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: ```bash sudo apt install libapache2-mod-auth-gssapi sudo a2enmod auth_gssapi sudo a2enmod headers sudo systemctl restart apache2 ``` :::noteimportant 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 Zabbix UI): ```bash sudo vi /etc/apache2/sites-available/zabbix.conf ``` Dentro `zabbix.conf`: ```apache ServerName dc01.example.com DocumentRoot /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 RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER RequestHeader unset Authorization ``` Riavvia Apache: ```bash sudo systemctl restart apache2 ``` 8\. Abilita/avvia i servizi KDC e verifica le porte in ascolto (host KDC): ```bash 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 userà il ticket). Dovresti vedere `krbtgt/EXAMPLE.COM@EXAMPLE.COM` 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 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 adattati. ```bash kinit kerb-admin@EXAMPLE.COM klist ``` 10\. Verifica lo scambio SPNEGO con curl (da un client con un TGT valido). Un `200 OK` (o un redirect all'app) indica che SPNEGO è riuscito: ```bash curl -v --negotiate -u : http://dc01.example.com/ ``` 11\. Facoltativamente, se la Zabbix UI deve accettare login autenticati via HTTP, abilita l'autenticazione HTTP nel frontend di Zabbix (ui/conf/zabbix.conf.php): ```php $ALLOW_HTTP_AUTH = true; ``` Nella web UI vai su *Users* > *Authentication* e spostati nella scheda [*HTTP settings*](/manual/web_interface/frontend_sections/users/authentication/http). Seleziona la casella *Enable HTTP authentication* e fai clic su *Ok* nel popup. Seleziona "HTTP login form" nel menu a discesa *Default login form*. Decidi 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. Dentro `about:config`: ```default network.negotiate-auth.trusted-uris = dc01.example.com ``` A questo punto, visitando `http://dc01.example.com` dovresti accedere direttamente a Zabbix senza il form. 13\. Mantieni aggiornate chiavi/ticket. La durata predefinita dei ticket Kerberos è di circa 10 ore. Aggiungi un cron/systemd timer per evitare scadenze: ```bash #for the web service kinit -kt /etc/apache2/http.keytab HTTP/dc01.example.com@EXAMPLE.COM #for the monitoring user kinit -kt /var/lib/zabbix/kerb.keytab kerb-admin@EXAMPLE.COM ``` 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` — controlla eventuali errori GSSAPI (`gss_acquire_cred[_from]() failed to get server creds` indica problemi di keytab/permessi o principal mancante). - Se `curl --negotiate` restituisce 401/403, spesso significa principal errato, ticket assente, mismatch dell'host header o problema di permessi del filesystem; controlla i log e i mapping dominio in `/etc/krb5.conf`. [comment]: # ({/e94370cd-edb96e72}) [comment]: # ({32287407-notes}) #### 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. [comment]: # ({/32287407-notes})