Configuración de Kerberos con Zabbix

Descripción general

La autenticación Kerberos puede utilizarse en la monitorización web y en los items HTTP en Zabbix.

Esta página describe un ejemplo de configuración de Kerberos para que el servidor Zabbix realice la monitorización web de www.example.com con un principal Kerberos para el proceso Zabbix en Debian/Ubuntu.

Configuración

1. Instale KDC y las utilidades del cliente:

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

Durante la configuración del paquete, responda a las indicaciones, por ejemplo:

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. Asigne un nombre de host descriptivo (opcional, para pruebas locales).

Edite /etc/hosts y añada una entrada para su DC y webserver si no dispone de DNS:

sudo vi /etc/hosts

Ejemplo de línea que puede añadir:

192.168.1.100  dc01.example.com dc01

3. Configure el cliente Kerberos y el realm de KDC:

sudo vi /etc/krb5.conf

Ejemplo de configuración:

[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

Si planea utilizar .localdomain u otros nombres no públicos, añada asignaciones explícitas de dominio→realm para que funcione la asignación de nombre de host→realm.
Las discrepancias aquí provocan errores Server not found in Kerberos database.

4. Inicialice la base de datos de Kerberos (una sola vez, en el host de KDC).
Establezca una contraseña maestra segura cuando se le solicite:

sudo krb5_newrealm

5. Cree el principal HTTP/host.fqdn@REALM utilizando el nombre de host exacto que usarán los clientes; se recomienda utilizar minúsculas (por ejemplo, HTTP/[email protected]).
Una discrepancia en las mayúsculas/minúsculas o en el nombre provoca el error Server not found in Kerberos database.

sudo kadmin.local

Dentro de kadmin.local:

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

Mueva el keytab al web host (o manténgalo local si se trata de la misma máquina) y establezca permisos que Apache pueda utilizar:

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

6. Instale y habilite el módulo GSSAPI de Apache:

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

No todas las versiones de mod_auth_gssapi admiten todas las directivas Gssapi*. Si Apache falla con Invalid command 'GssapiCredStore', elimine la directiva no compatible o actualice el módulo.

7. Configure un VirtualHost (ajuste DocumentRoot / la ruta a su interfaz de Zabbix):

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

Dentro de 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>

Reinicie Apache:

sudo systemctl restart apache2

8. Habilite/inicie los servicios de KDC y verifique los puertos en escucha (host de KDC):

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

9. Obtenga un TGT para realizar pruebas (ejecútelo como el usuario que utilizará el ticket).

Debería aparecer krbtgt/[email protected] en la lista de tickets.
Ejecute kinit como el mismo usuario del sistema operativo que necesita el ticket (por ejemplo, zabbix para las comprobaciones web o www-data/Apache para las pruebas interactivas de SSO en el navegador).
Los tickets emitidos para otro usuario del sistema operativo no serán visibles a menos que se ajusten KRB5CCNAME y los permisos.

kinit [email protected]
klist

10. Pruebe el intercambio SPNEGO con curl (desde un cliente con un TGT válido).
Un 200 OK (o una redirección a la aplicación) indica que SPNEGO se realizó correctamente:

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

11. Opcionalmente, si la interfaz de Zabbix debe aceptar inicios de sesión autenticados mediante HTTP, habilite la autenticación HTTP en el frontend de Zabbix.

En el archivo de configuración del frontend (zabbix.conf.php), establezca:

$ZBX_FEATURE_FLAGS['http_auth_enabled'] = true;

A continuación, configure la autenticación HTTP en la interfaz web.

12. Configuración del navegador (Firefox se utiliza como ejemplo): establezca network.negotiate-auth.trusted-uris en los hosts que realizan Negotiate (dc01.example.com) para que el navegador envíe automáticamente los tokens de Kerberos.

Dentro de about:config:

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

Ahora, al visitar http://dc01.example.com, debería iniciar sesión directamente en Zabbix sin mostrar el formulario.

13. Mantenga actualizadas las claves y los tickets.
La duración predeterminada de un ticket de Kerberos es de aproximadamente 10 horas.
Añada un temporizador de cron/systemd para evitar que caduquen:

#para el servicio web
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#para el usuario de monitorización
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Comprobaciones de mantenimiento:

  • klist -k /etc/apache2/http.keytab - verifique que el principal del servicio esté presente en el keytab.
  • sudo tail -f /var/log/apache2/error.log - supervise los errores de GSSAPI (gss_acquire_cred[_from]() failed to get server creds significa que hay un problema con el keytab o los permisos, o que falta el principal).
  • Si curl --negotiate devuelve 401/403, normalmente significa que el principal es incorrecto, que no hay ningún ticket, que el encabezado de host no coincide o que existe un problema con los permisos del sistema de archivos; compruebe los registros y las asignaciones de dominio de /etc/krb5.conf.

Notas sobre seguridad y permisos de archivos

Los archivos keytab solo deben ser legibles por la cuenta que los necesita. Ejemplos de permisos: 0400, con propietario zabbix:zabbix, para un keytab del usuario zabbix; o 0440, con propietario root:www-data, para un keytab de Apache.

Evite almacenar contraseñas de texto plano de larga duración en el host. Utilice keytabs o principales de máquina unidos al dominio siempre que sea posible.

Al ejecutar pruebas o scripts que establezcan KRB5CCNAME o copien keytabs, vuelva a comprobar el propietario y los permisos después de la operación: que un servidor web rechace las credenciales suele deberse a un problema de permisos de archivo.