13 Configurando Kerberos con Zabbix

Descripción general

La autenticación Kerberos se puede utilizar 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 de 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 (o su FQDN)
       Administrative server for your Kerberos realm: localhost (o su FQDN)

2. Asigne un nombre de host amigable (opcional, para pruebas locales).

Edite /etc/hosts y agregue una entrada para su DC y servidor web si no tiene DNS:

sudo vi /etc/hosts

Ejemplo de línea que podría agregar:

192.168.1.100  dc01.example.com dc01

3. Configure el cliente Kerberos y el realm KDC:

sudo vi /etc/krb5.conf

Configuraciones de ejemplo:

[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 usar .localdomain u otros nombres no públicos, agregue asignaciones explícitas de dominio→realm para que la asignación de nombre de host→realm funcione. Las discrepancias aquí causan errores de Server not found in Kerberos database.

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

sudo krb5_newrealm

5. Cree el principal HTTP/host.fqdn@REALM usando el nombre de host exacto que usarán los clientes; prefiera minúsculas (por ejemplo, HTTP/[email protected]). Una discrepancia de mayúsculas/nombre causa 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 host web (o manténgalo local si es la misma máquina) y establezca permisos utilizables por Apache:

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 Apache GSSAPI:

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

7. Configure un VirtualHost (ajuste DocumentRoot / 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 KDC y verifique los puertos en escucha (host 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 pruebas (ejecute como el usuario que usará el ticket).

Espere ver krbtgt/[email protected] en la lista de tickets. Ejecute kinit como el mismo usuario del SO que necesita el ticket (por ejemplo, zabbix para comprobaciones web o www-data/Apache para pruebas SSO interactivas en el navegador). Los tickets emitidos a un usuario diferente del SO 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 redirección a la aplicación) indica que SPNEGO tuvo éxito:

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

11. Opcionalmente, si la interfaz de Zabbix debe aceptar inicios de sesión autenticados por HTTP, habilite la autenticación HTTP en el frontend de Zabbix (ui/conf/zabbix.conf.php):

$ALLOW_HTTP_AUTH = true;

En la interfaz web vaya a Usuarios > Autenticación y cambie a la pestaña Configuración HTTP. Marque la casilla Habilitar autenticación HTTP y haga clic en Ok en la ventana emergente. Seleccione "Formulario de inicio de sesión HTTP" en el desplegable Formulario de inicio de sesión predeterminado. Decida si Inicio de sesión sensible a mayúsculas se ajusta a la política de su directorio. Haga clic en el botón Actualizar para finalizar.

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

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 el formulario.

13. Mantenga las claves/tickets actualizados. La vida útil predeterminada del ticket Kerberos es de aproximadamente 10 horas. Agregue un cron/timer de systemd para evitar expiraciones:

#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 de servicio esté presente en el keytab.
• sudo tail -f /var/log/apache2/error.log — observe los errores de GSSAPI (gss_acquire_cred[_from]() failed to get server creds significa keytab/permisos o principal faltante).
• curl --negotiate devolviendo 401/403 a menudo significa principal incorrecto, sin ticket, discrepancia en el encabezado de host o problema de permisos de sistema de archivos; revise los registros y las asignaciones de dominio en /etc/krb5.conf.

Notas de seguridad y permisos de archivos

Los archivos keytab deben ser legibles solo por la cuenta que los necesita. Permisos de ejemplo: 0400 propiedad de zabbix:zabbix para un keytab de usuario zabbix, o 0440 y root:www-data para un keytab de Apache.

Evite almacenar contraseñas en 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 establecen KRB5CCNAME o copian keytabs, verifique la propiedad y los permisos después de la operación; un servidor web que rechaza credenciales suele ser un problema de permisos de archivos.