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.