13 Configurando o Kerberos com o Zabbix

Visão geral

A autenticação Kerberos pode ser usada no monitoramento da web e em items HTTP no Zabbix.

Esta página descreve um exemplo de configuração do Kerberos para o servidor Zabbix realizar o monitoramento da web de www.example.com com um principal Kerberos para o processo Zabbix no Debian/Ubuntu.

Configuração

1. Instale o KDC e as utilitários do cliente:

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

Durante a configuração do pacote, responda às perguntas, por exemplo:

Default Kerberos version 5 realm: EXAMPLE.COM
       Kerberos servers for your realm: localhost (ou seu FQDN)
       Administrative server for your Kerberos realm: localhost (ou seu FQDN)

2. Mapeie um hostname amigável (opcional, para testes locais).

Edite /etc/hosts e adicione uma entrada para seu DC e servidor web se você não tiver DNS:

sudo vi /etc/hosts

Exemplo de linha que você pode adicionar:

192.168.1.100  dc01.example.com dc01

3. Configure o cliente Kerberos e o realm do KDC:

sudo vi /etc/krb5.conf

Exemplo de configurações:

[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 você planeja usar .localdomain ou outros nomes não públicos, adicione mapeamentos explícitos de domínio→realm para que o mapeamento de hostname→realm funcione. Inconsistências aqui causam erros Server not found in Kerberos database.

4. Inicialize o banco de dados Kerberos (uma vez, no host KDC). Defina uma senha mestre segura quando solicitado:

sudo krb5_newrealm

5. Crie o principal HTTP/host.fqdn@REALM usando exatamente o hostname que os clientes usarão; prefira minúsculas (por exemplo, HTTP/[email protected]). Uma diferença de maiúsculas/minúsculas ou nome causa Server not found in Kerberos database.

sudo kadmin.local

Dentro do kadmin.local:

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

Mova o keytab para o host web (ou mantenha local se for a mesma máquina) e defina permissões utilizáveis pelo 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 e habilite o módulo Apache GSSAPI:

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

7. Configure um VirtualHost (ajuste o DocumentRoot / caminho para sua interface Zabbix):

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

Dentro do 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 o Apache:

sudo systemctl restart apache2

8. Habilite/inicie os serviços KDC e verifique as portas de escuta (host KDC):

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

9. Obtenha um TGT para teste (execute como o usuário que usará o ticket).

Espere ver krbtgt/[email protected] na lista de tickets. Execute kinit como o mesmo usuário do SO que precisa do ticket (por exemplo, zabbix para verificações web ou www-data/Apache para testes interativos de SSO no navegador). Tickets emitidos para um usuário diferente do SO não serão visíveis a menos que KRB5CCNAME e permissões sejam ajustados.

kinit [email protected]
       klist

10. Teste a troca SPNEGO com curl (de um cliente com um TGT válido). Um 200 OK (ou redirecionamento para o app) indica que o SPNEGO foi bem-sucedido:

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

11. Opcionalmente, se a interface Zabbix deve aceitar logins autenticados por HTTP, habilite a autenticação HTTP no frontend do Zabbix (ui/conf/zabbix.conf.php):

$ALLOW_HTTP_AUTH = true;

Na interface web, vá para Usuários > Autenticação e vá para a guia Configurações HTTP. Marque a caixa Habilitar autenticação HTTP e clique em Ok no pop-up. Selecione "Formulário de login HTTP" no menu suspenso Formulário de login padrão. Decida se Login com diferenciação de maiúsculas/minúsculas se encaixa na política do seu diretório. Clique no botão Atualizar para finalizar.

12. Configuração do navegador (Firefox é usado como exemplo): defina network.negotiate-auth.trusted-uris para o(s) host(s) que executam Negotiate (dc01.example.com) para que o navegador envie tokens Kerberos automaticamente.

Dentro do about:config:

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

Agora, ao visitar http://dc01.example.com, você deve entrar diretamente no Zabbix sem o formulário.

13. Mantenha as chaves/tickets atualizados. O tempo de vida padrão do ticket Kerberos é de aproximadamente 10 horas. Adicione um cron/timer systemd para evitar expirações:

#para o serviço web
       kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
       #para o usuário de monitoramento
       kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Verificações de manutenção:

• klist -k /etc/apache2/http.keytab — verifique se o principal do serviço está presente no keytab.
• sudo tail -f /var/log/apache2/error.log — observe erros do GSSAPI (gss_acquire_cred[_from]() failed to get server creds significa keytab/permissões ou principal ausente).
• curl --negotiate retornando 401/403 geralmente significa principal errado, nenhum ticket, incompatibilidade do cabeçalho do host ou problema de permissão no sistema de arquivos; verifique os logs e os mapeamentos de domínio em /etc/krb5.conf.

Notas de segurança e permissões de arquivos

Os arquivos keytab devem ser legíveis apenas pela conta que precisa deles. Permissões de exemplo: 0400 pertencente a zabbix:zabbix para um keytab de usuário zabbix, ou 0440 e root:www-data para um keytab do Apache.

Evite armazenar senhas em texto simples de longa duração no host. Use keytabs ou principais de máquina associados ao domínio sempre que possível.

Ao executar testes ou scripts que definem KRB5CCNAME ou copiam keytabs, verifique novamente a propriedade e as permissões após a operação — um servidor web rejeitando credenciais geralmente é um problema de permissão de arquivo.