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 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 hostname amigável (opcional, para testes locais).
Edite /etc/hosts e adicione uma entrada para seu DC e webserver 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ê pretende usar .localdomain ou outros nomes não públicos, adicione mapeamentos explícitos de domain→realm para que o mapeamento hostname→realm funcione.
Incompatibilidades aqui causam erros Server not found in Kerberos database.
4. Inicialize o banco de dados Kerberos (uma vez, no host do KDC). Defina uma senha mestra segura quando solicitado:
sudo krb5_newrealm
5. Crie o principal HTTP/host.fqdn@REALM usando exatamente o hostname 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] # administrative principal
addprinc -randkey HTTP/[email protected]
ktadd -k /etc/apache2/http.keytab HTTP/[email protected]
quit
Mova o keytab para o host web (ou mantenha localmente 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
# verify
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
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 DocumentRoot / caminho para sua interface web 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 # or: 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 sistema 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 sistema 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 redirecionamento para o aplicativo) indica que o SPNEGO foi bem-sucedido:
curl -v --negotiate -u : http://dc01.example.com/
11. Opcionalmente, se a interface web do 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 Users > Authentication e abra a aba HTTP settings. Marque a caixa Enable HTTP authentication e clique em Ok no pop-up. Selecione "HTTP login form" na lista suspensa Default login form. Decida se Case-sensitive login atende à política do seu diretório. Clique no botão Update para finalizar.
12. Configuração do navegador (Firefox é usado como exemplo): defina network.negotiate-auth.trusted-uris para o(s) host(s) que realizam 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, ao visitar http://dc01.example.com, você deverá entrar diretamente no Zabbix sem o formulário.
13. Mantenha chaves/tickets atualizados. O tempo de vida padrão do ticket Kerberos é de aproximadamente 10 horas. Adicione um cron/systemd timer para evitar expirações:
#for the web service
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#for the monitoring user
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 de serviço está presente no keytab.sudo tail -f /var/log/apache2/error.log— observe erros GSSAPI (gss_acquire_cred[_from]() failed to get server credssignifica problema de keytab/permissões ou principal ausente).curl --negotiateretornando 401/403 geralmente significa principal incorreto, ausência de ticket, incompatibilidade no host header 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.