13 Configuring Kerberos with Zabbix

Overview

Kerberos authentication can be used in web monitoring and HTTP items in Zabbix.

This page describes an example of configuring Kerberos for Zabbix server to perform web monitoring of www.example.com with a Kerberos principal for Zabbix process on Debian/Ubuntu.

Configuration

1. Install KDC and client utilities:

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

During package setup answer the prompts, e.g.:

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. Map a friendly hostname (optional, for local testing).

Edit /etc/hosts and add an entry for your DC and webserver if you don't have DNS:

sudo vi /etc/hosts

Example line you might add:

192.168.1.100  dc01.example.com dc01

3. Configure the Kerberos client and KDC realm:

sudo vi /etc/krb5.conf

Example settings:

[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

If you plan to use .localdomain or other non-public names, add explicit domain→realm mappings so hostname→realm mapping works. Mismatches here cause Server not found in Kerberos database errors.

4. Initialize the Kerberos database (one-time, KDC host). Set a secure master password when prompted:

sudo krb5_newrealm

5. Create the HTTP/host.fqdn@REALM principal using the exact hostname clients will use; prefer lowercase (e.g. HTTP/[email protected]). A case/name mismatch causes Server not found in Kerberos database.

sudo kadmin.local

Inside kadmin.local:

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

Move the keytab to the web host (or keep local if same machine) and set permissions usable by 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. Install and enable Apache GSSAPI module:

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

7. Configure a VirtualHost (adjust DocumentRoot / path to your Zabbix UI):

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

Inside 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>

Restart Apache:

sudo systemctl restart apache2

8. Enable/start KDC services and verify listening ports (KDC host):

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

9. Obtain a TGT for testing (run as the user that will use the ticket).

Expect to see krbtgt/[email protected] in the ticket list. Run kinit as the same OS user that needs the ticket (e.g., zabbix for web checks or www-data/Apache for interactive browser SSO tests). Tickets issued to a different OS user won't be visible unless KRB5CCNAME and permissions are adjusted.

kinit [email protected]
       klist

10. Test SPNEGO exchange with curl (from a client with a valid TGT). A 200 OK (or redirect to app) indicates SPNEGO succeeded:

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

11. Optionally, if Zabbix UI should accept HTTP-authenticated logins, enable HTTP auth in Zabbix front end (ui/conf/zabbix.conf.php):

$ALLOW_HTTP_AUTH = true;

In the web UI go to Users > Authentication and move to HTTP settings tab. Mark Enable HTTP authentication checkbox and click Ok in the pop-up. Select "HTTP login form" in the Default login form drop-down. Decide whether Case-sensitive login fits your directory policy. Click on Update button to finish.

12. Browser configuration (Firefox is used as an example): set network.negotiate-auth.trusted-uris to the host(s) performing Negotiate (dc01.example.com) so the browser will send Kerberos tokens automatically.

Inside about:config:

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

Now visiting http://dc01.example.com should log you straight into Zabbix without the form.

13. Keep keys/tickets fresh. Default Kerberos ticket lifetime is approximately 10 hours. Add a cron/systemd timer to avoid expirations:

#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. Housekeeping checks:

• klist -k /etc/apache2/http.keytab — verify service principal present in keytab.
• sudo tail -f /var/log/apache2/error.log — watch for GSSAPI errors (gss_acquire_cred[_from]() failed to get server creds means keytab/permissions or missing principal).
• curl --negotiate returning 401/403 often means wrong principal, no ticket, host header mismatch, or filesystem permission issue; check logs and /etc/krb5.conf domain mappings.

Security and file-permission notes

Keytab files must be readable only by the account that needs them. Example permissions: 0400 owned by zabbix:zabbix for a zabbix user keytab, or 0440 and root:www-data for an Apache keytab.

Avoid storing long-lived plaintext passwords on the host. Use keytabs or domain-joined machine principals where possible.

When running tests or scripts that set KRB5CCNAME or copy keytabs, double-check ownership and permissions after the operation — a webserver rejecting credentials is commonly a file-permission problem.