Configurando Kerberos com 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 os utilitários do cliente:

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

Durante a configuração do pacote, responda aos prompts, por exemplo:

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. Mapeie um nome de host amigável (opcional, para testes locais).

Edite /etc/hosts e adicione uma entrada para o DC e o webserver caso você não tenha 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 nome de host→realm funcione. Incompatibilidades aqui causam erros Server not found in Kerberos database.

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

sudo krb5_newrealm

5. Crie o principal HTTP/host.fqdn@REALM usando exatamente o nome de host que os clientes usarão; prefira letras minúsculas (por exemplo, HTTP/[email protected]). Uma incompatibilidade de maiúsculas/minúsculas ou de nome 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

Mova o keytab para o host web (ou mantenha-o local se for a mesma máquina) e defina permissões que possam ser usadas 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 GSSAPI do Apache:

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

Nem todas as versões do mod_auth_gssapi são compatíveis com todas as diretivas Gssapi*. Se o Apache falhar com Invalid command 'GssapiCredStore', remova a diretiva não compatível ou atualize o módulo.

7. Configure um VirtualHost (ajuste DocumentRoot / o caminho para a interface do 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 o Apache:

sudo systemctl restart apache2

8. Habilite/inicie os serviços do KDC e verifique as portas em escuta (host do 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).

Você deverá ver krbtgt/[email protected] na lista de tickets. Execute kinit como o mesmo usuário do sistema operacional que precisa do ticket (por exemplo, zabbix para verificações web ou www-data/Apache para testes de SSO do navegador interativo). Os tickets emitidos para um usuário diferente do sistema operacional não ficarão visíveis, a menos que KRB5CCNAME e as permissões sejam ajustados.

kinit [email protected]
klist

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

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

11. Opcionalmente, se a interface do Zabbix deverá aceitar logins autenticados por HTTP, habilite a autenticação HTTP no frontend do Zabbix.

No arquivo de configuração do frontend (zabbix.conf.php), defina:

$ZBX_FEATURE_FLAGS['http_auth_enabled'] = true;

Em seguida, configure a autenticação HTTP na interface web.

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

Dentro de about:config:

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

Agora, acessar http://dc01.example.com deverá fazer login diretamente no Zabbix, sem exibir o formulário.

13. Mantenha as chaves/tickets atualizados. A duração padrão de um ticket Kerberos é de aproximadamente 10 horas. Adicione um cron/timer do 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 - monitore os erros GSSAPI (gss_acquire_cred[_from]() failed to get server creds significa um problema no keytab/permissões ou um principal ausente).
  • O retorno 401/403 de curl --negotiate geralmente significa principal incorreto, ausência de ticket, incompatibilidade no 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.

Observações sobre segurança e permissões de arquivos

Os arquivos keytab devem ser legíveis somente pela conta que precisa deles. Exemplos de permissões: 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 o proprietário e as permissões após a operação — quando um servidor web rejeita credenciais, geralmente o problema está nas permissões do arquivo.