[comment]: # ({930fae3b-930fae3b}) # 13 Configuración de Kerberos con Zabbix [comment]: # ({/930fae3b-930fae3b}) [comment]: # ({bfbefd40-5be9f534}) #### 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. [comment]: # ({/bfbefd40-5be9f534}) [comment]: # ({e94370cd-edb96e72}) #### Configuración 1\. Instale KDC y las utilidades de cliente: ```bash 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 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: ```bash sudo vi /etc/hosts ``` Ejemplo de línea que podría agregar: ```ini 192.168.1.100 dc01.example.com dc01 ``` 3\. Configure el cliente Kerberos y el realm KDC: ```bash sudo vi /etc/krb5.conf ``` Ejemplo de configuración: ```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 ``` 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 `Server not found in Kerberos database`. 4\. Inicialice la base de datos Kerberos (una sola vez, en el host KDC). Establezca una contraseña maestra segura cuando se le solicite: ```bash sudo krb5_newrealm ``` 5\. Cree el principal `HTTP/host.fqdn@REALM` usando el nombre de host exacto que los clientes usarán; prefiera minúsculas (por ejemplo, `HTTP/web.example.com@EXAMPLE.COM`). Una discrepancia de mayúsculas/nombre causa `Server not found in Kerberos database`. ```bash sudo kadmin.local ``` Dentro de `kadmin.local`: ```bash addprinc kerb-admin@EXAMPLE.COM # principal administrativo addprinc -randkey HTTP/dc01.example.com@EXAMPLE.COM ktadd -k /etc/apache2/http.keytab HTTP/dc01.example.com@EXAMPLE.COM quit ``` Mueva el keytab al host web (o manténgalo local si es la misma máquina) y establezca permisos utilizables por Apache: ```bash 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: ```bash sudo apt install libapache2-mod-auth-gssapi sudo a2enmod auth_gssapi sudo a2enmod headers sudo systemctl restart apache2 ``` :::noteimportant No todas las versiones de mod_auth_gssapi admiten todas las directivas `Gssapi*`. Si Apache falla con `Invalid command 'GssapiCredStore'`, elimine la directiva no admitida o actualice el módulo. ::: 7\. Configure un VirtualHost (ajuste `DocumentRoot` / ruta a su interfaz de Zabbix): ```bash sudo vi /etc/apache2/sites-available/zabbix.conf ``` Dentro de `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 ``` Reinicie Apache: ```bash sudo systemctl restart apache2 ``` 8\. Habilite/inicie los servicios KDC y verifique los puertos en escucha (host KDC): ```bash 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/EXAMPLE.COM@EXAMPLE.COM` 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. ```bash kinit kerb-admin@EXAMPLE.COM 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: ```bash 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): ```php $ALLOW_HTTP_AUTH = true; ``` En la interfaz web vaya a *Usuarios* > *Autenticación* y cambie a la pestaña [*Configuración HTTP*](/manual/web_interface/frontend_sections/users/authentication/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 y minú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 usa 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`: ```default 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: ```bash #para el servicio web kinit -kt /etc/apache2/http.keytab HTTP/dc01.example.com@EXAMPLE.COM #para el usuario de monitorización kinit -kt /var/lib/zabbix/kerb.keytab kerb-admin@EXAMPLE.COM ``` 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`. [comment]: # ({/e94370cd-edb96e72}) [comment]: # ({32287407-notes}) #### 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. [comment]: # ({/32287407-notes})