13 Konfiguration von Kerberos mit Zabbix

Übersicht

Kerberos-Authentifizierung kann in der Web-Überwachung und in HTTP-Datenpunkten in Zabbix verwendet werden.

Diese Seite beschreibt ein Beispiel für die Konfiguration von Kerberos für den Zabbix Server, damit dieser die Web-Überwachung von www.example.com mit einem Kerberos-Prinzipal für den Zabbix-Prozess unter Debian/Ubuntu durchführen kann.

Konfiguration

1. Installieren Sie KDC und Client-Dienstprogramme:

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

Beantworten Sie während der Paketinstallation die Abfragen, z. B.:

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. Ordnen Sie optional einen benutzerfreundlichen Hostnamen zu, für lokale Tests.

Bearbeiten Sie /etc/hosts und fügen Sie einen Eintrag für Ihren DC und Webserver hinzu, wenn Sie kein DNS haben:

sudo vi /etc/hosts

Beispielzeile, die Sie hinzufügen könnten:

192.168.1.100  dc01.example.com dc01

3. Konfigurieren Sie den Kerberos-Client und den KDC-Realm:

sudo vi /etc/krb5.conf

Beispiel-Einstellungen:

[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

Wenn Sie .localdomain oder andere nicht öffentliche Namen verwenden möchten, fügen Sie explizite Domain→Realm-Zuordnungen hinzu, damit die Zuordnung von Hostname→Realm funktioniert. Abweichungen hier führen zu Fehlern wie Server not found in Kerberos database.

4. Initialisieren Sie die Kerberos-Datenbank (einmalig, auf dem KDC-Host). Legen Sie auf Aufforderung ein sicheres Master-Passwort fest:

sudo krb5_newrealm

5. Erstellen Sie den Principal HTTP/host.fqdn@REALM mit genau dem Hostnamen, den die Clients verwenden werden; bevorzugen Sie Kleinbuchstaben (z. B. HTTP/[email protected]). Eine Abweichung bei Groß-/Kleinschreibung oder Name führt zu Server not found in Kerberos database.

sudo kadmin.local

In kadmin.local:

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

Verschieben Sie die Keytab auf den Web-Host (oder lassen Sie sie lokal, wenn es derselbe Rechner ist) und setzen Sie Berechtigungen, die von Apache verwendet werden können:

chown www-data:www-data /etc/apache2/http.keytab
chmod 600 /etc/apache2/http.keytab
# prüfen
sudo -u www-data -k /etc/apache2/http.keytab

6. Installieren und aktivieren Sie das Apache-GSSAPI-Modul:

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

Nicht alle Versionen von mod_auth_gssapi unterstützen jede Gssapi*-Direktive. Wenn Apache mit Invalid command 'GssapiCredStore' fehlschlägt, entfernen Sie die nicht unterstützte Direktive oder aktualisieren Sie das Modul.

7. Konfigurieren Sie einen VirtualHost (passen Sie DocumentRoot / den Pfad zu Ihrer Zabbix-UI an):

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

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

Starten Sie Apache neu:

sudo systemctl restart apache2

8. Aktivieren/starten Sie die KDC-Dienste und prüfen Sie die lauschenden Ports (KDC-Host):

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

9. Holen Sie sich zum Testen ein TGT (führen Sie dies als der Benutzer aus, der das Ticket verwenden wird).

Erwarten Sie, krbtgt/[email protected] in der Ticketliste zu sehen. Führen Sie kinit als derselbe OS-Benutzer aus, der das Ticket benötigt (z. B. zabbix für Web-Checks oder www-data/Apache für interaktive Browser-SSO-Tests). Tickets, die für einen anderen OS-Benutzer ausgestellt wurden, sind nicht sichtbar, sofern KRB5CCNAME und Berechtigungen nicht angepasst werden.

kinit [email protected]
klist

10. Testen Sie den SPNEGO-Austausch mit curl (von einem Client mit gültigem TGT). Ein 200 OK (oder eine Weiterleitung zur Anwendung) zeigt an, dass SPNEGO erfolgreich war:

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

11. Optional: Wenn die Zabbix-UI HTTP-authentifizierte Anmeldungen akzeptieren soll, aktivieren Sie HTTP-Auth im Zabbix-Frontend (ui/conf/zabbix.conf.php):

$ALLOW_HTTP_AUTH = true;

Gehen Sie in der Weboberfläche zu Benutzer > Authentifizierung und wechseln Sie zum Tab HTTP-Einstellungen. Aktivieren Sie das Kontrollkästchen HTTP-Authentifizierung aktivieren und klicken Sie im Pop-up auf Ok. Wählen Sie im Dropdown Standard-Anmeldeformular die Option "HTTP login form" aus. Entscheiden Sie, ob Groß-/Kleinschreibung bei Anmeldung beachten zu Ihrer Verzeichnisrichtlinie passt. Klicken Sie zum Abschluss auf die Schaltfläche Aktualisieren.

12. Browser-Konfiguration (Firefox wird als Beispiel verwendet): Setzen Sie network.negotiate-auth.trusted-uris auf den oder die Hosts, die Negotiate ausführen (dc01.example.com), damit der Browser Kerberos-Tokens automatisch sendet.

In about:config:

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

Wenn Sie nun http://dc01.example.com aufrufen, sollten Sie direkt ohne Formular bei Zabbix angemeldet werden.

13. Halten Sie Schlüssel/Tickets aktuell. Die Standard-Lebensdauer eines Kerberos-Tickets beträgt ungefähr 10 Stunden. Fügen Sie einen Cron-/systemd-Timer hinzu, um Ablaufzeiten zu vermeiden:

#für den Webdienst
kinit -kt /etc/apache2/http.keytab HTTP/[email protected]
#für den Monitoring-Benutzer
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Prüfungen zur Wartung:

  • klist -k /etc/apache2/http.keytab — prüfen, ob der Service-Principal in der Keytab vorhanden ist.
  • sudo tail -f /var/log/apache2/error.log — auf GSSAPI-Fehler achten (gss_acquire_cred[_from]() failed to get server creds bedeutet Keytab-/Berechtigungsproblem oder fehlender Principal).
  • Wenn curl --negotiate 401/403 zurückgibt, bedeutet das oft einen falschen Principal, kein Ticket, eine Host-Header-Abweichung oder ein Problem mit Dateisystemberechtigungen; prüfen Sie die Logs und die Domain-Zuordnungen in /etc/krb5.conf.

Sicherheits- und Dateiberechtigungshinweise

Keytab-Dateien dürfen nur von dem Konto lesbar sein, das sie benötigt. Beispielberechtigungen: 0400 mit Eigentümer zabbix:zabbix für eine Keytab-Datei eines zabbix-Benutzers oder 0440 und root:www-data für eine Apache-Keytab-Datei.

Vermeiden Sie es, langlebige Klartextpasswörter auf dem Host zu speichern. Verwenden Sie nach Möglichkeit Keytabs oder in die Domäne aufgenommene Maschinenprinzipale.

Wenn Sie Tests oder Skripte ausführen, die KRB5CCNAME setzen oder Keytabs kopieren, überprüfen Sie nach dem Vorgang Eigentümer und Berechtigungen doppelt — dass ein Webserver Anmeldedaten ablehnt, ist häufig ein Problem mit Dateiberechtigungen.