[comment]: # ({930fae3b-930fae3b}) # 13 Configurando o Kerberos com o Zabbix [comment]: # ({/930fae3b-930fae3b}) [comment]: # ({bfbefd40-5be9f534}) #### 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. [comment]: # ({/bfbefd40-5be9f534}) [comment]: # ({e94370cd-edb96e72}) #### Configuração 1\. Instale o KDC e as utilitários do cliente: ```bash 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 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: ```bash sudo vi /etc/hosts ``` Exemplo de linha que você pode adicionar: ```ini 192.168.1.100 dc01.example.com dc01 ``` 3\. Configure o cliente Kerberos e o realm do KDC: ```bash sudo vi /etc/krb5.conf ``` Exemplo de configurações: ```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 ``` 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: ```bash 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/web.example.com@EXAMPLE.COM`). Uma diferença de maiúsculas/minúsculas ou nome causa `Server not found in Kerberos database`. ```bash sudo kadmin.local ``` Dentro do `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 ``` Mova o keytab para o host web (ou mantenha local se for a mesma máquina) e defina permissões utilizáveis pelo 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 e habilite o módulo Apache GSSAPI: ```bash sudo apt install libapache2-mod-auth-gssapi sudo a2enmod auth_gssapi sudo a2enmod headers sudo systemctl restart apache2 ``` :::noteimportant Nem todas as versões do mod_auth_gssapi suportam todas as diretivas `Gssapi*`. Se o Apache falhar com `Invalid command 'GssapiCredStore'`, remova a diretiva não suportada ou atualize o módulo. ::: 7\. Configure um VirtualHost (ajuste o `DocumentRoot` / caminho para sua interface Zabbix): ```bash sudo vi /etc/apache2/sites-available/zabbix.conf ``` Dentro do `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 o Apache: ```bash sudo systemctl restart apache2 ``` 8\. Habilite/inicie os serviços KDC e verifique as portas de escuta (host KDC): ```bash 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/EXAMPLE.COM@EXAMPLE.COM` 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. ```bash kinit kerb-admin@EXAMPLE.COM 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: ```bash 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): ```php $ALLOW_HTTP_AUTH = true; ``` Na interface web, vá para *Usuários* > *Autenticação* e vá para a guia [*Configurações HTTP*](/manual/web_interface/frontend_sections/users/authentication/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`: ```default 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: ```bash #para o serviço web kinit -kt /etc/apache2/http.keytab HTTP/dc01.example.com@EXAMPLE.COM #para o usuário de monitoramento kinit -kt /var/lib/zabbix/kerb.keytab kerb-admin@EXAMPLE.COM ``` 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`. [comment]: # ({/e94370cd-edb96e72}) [comment]: # ({32287407-notes}) #### 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. [comment]: # ({/32287407-notes})