[comment]: # translation:outdated [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\. Installare KDC e le utility client: ```bash sudo apt update sudo apt install krb5-kdc krb5-admin-server krb5-user ``` Durante la configurazione dei pacchetti, rispondere alle richieste, 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\. 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: ```bash sudo vi /etc/hosts ``` Esempio di riga da aggiungere: ```ini 192.168.1.100 dc01.example.com dc01 ``` 3\. Configurare il client Kerberos e il realm KDC: ```bash sudo vi /etc/krb5.conf ``` Esempio di impostazioni: ```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 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: ```bash 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/web.example.com@EXAMPLE.COM`). Una mancata corrispondenza tra maiuscole/minuscole o nomi causa `Server not found in Kerberos database`. ```bash sudo kadmin.local ``` All'interno di `kadmin.local`: ```bash addprinc kerb-admin@EXAMPLE.COM # principal amministrativo addprinc -randkey HTTP/dc01.example.com@EXAMPLE.COM ktadd -k /etc/apache2/http.keytab HTTP/dc01.example.com@EXAMPLE.COM quit ``` Spostare il keytab sul web host (oppure lasciarlo in locale se si tratta della stessa macchina) e impostare permessi utilizzabili da Apache: ```bash 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: ```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'`, rimuovere la direttiva non supportata oppure aggiornare il modulo. ::: 7\. Configurare un VirtualHost (adattare `DocumentRoot` / il percorso alla propria UI di Zabbix): ```bash sudo vi /etc/apache2/sites-available/zabbix.conf ``` All'interno di `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 ``` Riavviare Apache: ```bash sudo systemctl restart apache2 ``` 8\. Abilitare/avviare i servizi KDC e verificare le porte in ascolto (host KDC): ```bash 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/EXAMPLE.COM@EXAMPLE.COM` 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. ```bash kinit kerb-admin@EXAMPLE.COM 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: ```bash 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): ```php $ALLOW_HTTP_AUTH = true; ``` Nella web UI andare in *Users* > *Authentication* e passare alla scheda [*HTTP settings*](/manual/web_interface/frontend_sections/users/authentication/http). 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`: ```default 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: ```bash #per il servizio web kinit -kt /etc/apache2/http.keytab HTTP/dc01.example.com@EXAMPLE.COM #per l'utente di monitoraggio kinit -kt /var/lib/zabbix/kerb.keytab kerb-admin@EXAMPLE.COM ``` 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`. [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})