Konfigurieren 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. KDC und Client-Dienstprogramme installieren:

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

Beantworten Sie während der Paketeinrichtung die Eingabeaufforderungen, zum Beispiel:

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. Einen benutzerfreundlichen Hostnamen zuordnen (optional, 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 verwenden:

sudo vi /etc/hosts

Beispiel für eine mögliche Zeile:

192.168.1.100  dc01.example.com dc01

3. Den Kerberos-Client und den KDC-Realm konfigurieren:

sudo vi /etc/krb5.conf

Beispieleinstellungen:

[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 Hostnamen zu Realms funktioniert. Nichtübereinstimmungen führen zu Fehlern vom Typ Server not found in Kerberos database.

4. Die Kerberos-Datenbank initialisieren (einmalig, auf dem KDC-Host). Legen Sie bei der Eingabeaufforderung ein sicheres Masterpasswort fest:

sudo krb5_newrealm

5. Den Principal HTTP/host.fqdn@REALM unter Verwendung des exakten Hostnamens erstellen, den die Clients verwenden; bevorzugt in Kleinbuchstaben (zum Beispiel 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-Datei auf den Web-Host (oder behalten Sie sie lokal, wenn es sich um denselben Rechner handelt) und legen Sie Berechtigungen fest, die von Apache verwendet werden können:

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

6. Das Apache-GSSAPI-Modul installieren und aktivieren:

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. Einen VirtualHost konfigurieren (DocumentRoot bzw. den Pfad zu Ihrer Zabbix-Benutzeroberfläche anpassen):

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>

Apache neu starten:

sudo systemctl restart apache2

8. KDC-Dienste aktivieren/starten und die lauschenden Ports überprüfen (KDC-Host):

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

9. Ein TGT zu Testzwecken abrufen (als der Benutzer ausführen, der das Ticket verwenden wird).

In der Ticketliste sollte krbtgt/[email protected] angezeigt werden. Führen Sie kinit als derselbe Betriebssystembenutzer aus, der das Ticket benötigt (zum Beispiel zabbix für Webprüfungen oder www-data/Apache für interaktive Browser-SSO-Tests). Tickets, die einem anderen Betriebssystembenutzer ausgestellt wurden, sind nicht sichtbar, sofern KRB5CCNAME und die Berechtigungen nicht angepasst werden.

kinit [email protected]
klist

10. Den SPNEGO-Austausch mit curl testen (von einem Client mit einem gültigen 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-Benutzeroberfläche HTTP-authentifizierte Anmeldungen akzeptieren soll, aktivieren Sie die HTTP-Authentifizierung im Zabbix-Frontend.

Setzen Sie in der Frontend-Konfigurationsdatei (zabbix.conf.php):

$ZBX_FEATURE_FLAGS['http_auth_enabled'] = true;

Konfigurieren Sie anschließend die HTTP-Authentifizierung in der Weboberfläche.

12. Browserkonfiguration (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 bei Zabbix angemeldet werden, ohne dass das Formular angezeigt wird.

13. Schlüssel/Tickets aktuell halten. Die standardmäßige Kerberos-Ticketlaufzeit 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 Monitoringbenutzer
kinit -kt /var/lib/zabbix/kerb.keytab [email protected]

14. Prüfungen zur Wartung:

  • klist -k /etc/apache2/http.keytab — überprüfen, ob der Service-Principal in der Keytab-Datei vorhanden ist.
  • sudo tail -f /var/log/apache2/error.log — auf GSSAPI-Fehler achten (gss_acquire_cred[_from]() failed to get server creds bedeutet, dass ein Problem mit der Keytab-Datei bzw. den Berechtigungen vorliegt oder der Principal fehlt).
  • Wenn curl --negotiate 401/403 zurückgibt, bedeutet dies häufig, dass der falsche Principal verwendet wird, kein Ticket vorhanden ist, der Host-Header nicht übereinstimmt oder ein Problem mit den Dateisystemberechtigungen vorliegt. Überprüfen Sie die Protokolle 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.