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 Paketeinrichtung die Eingabeaufforderungen, 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 einen leicht lesbaren Hostnamen zu (optional, für lokale Tests).

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

sudo vi /etc/hosts

Beispiel für eine Zeile, 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

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 Hostname→Realm-Zuordnung funktioniert. Abweichungen hier verursachen Fehler vom Typ Server not found in Kerberos database.

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

sudo krb5_newrealm

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

sudo kadmin.local

Innerhalb von 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 belassen Sie sie lokal, wenn es dieselbe Maschine 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
# verify
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 mod_auth_gssapi-Versionen 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

Innerhalb von 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    # or: sudo netstat -tnlp | grep :80

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

In der Ticketliste sollte krbtgt/[email protected] angezeigt werden. Führen Sie kinit als derselbe OS-Benutzer aus, der das Ticket benötigt (z. B. zabbix für Web-Prüfungen 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 die 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-Authentifizierung im Zabbix-Frontend (ui/conf/zabbix.conf.php):

$ALLOW_HTTP_AUTH = true;

Gehen Sie in der Web-UI zu Benutzer > Authentifizierung und wechseln Sie zur Registerkarte HTTP settings. Aktivieren Sie das Kontrollkästchen Enable HTTP authentication und klicken Sie im Pop-up auf Ok. Wählen Sie im Dropdown Default login form die Option "HTTP login form". Entscheiden Sie, ob Case-sensitive login zu Ihrer Verzeichnisrichtlinie passt. Klicken Sie zum Abschluss auf die Schaltfläche Update.

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

Innerhalb von about:config:

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

Beim Aufruf von http://dc01.example.com sollten Sie nun direkt ohne Formular bei Zabbix angemeldet werden.

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

#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. Prüfungen zur Systempflege:

  • klist -k /etc/apache2/http.keytab — prüfen Sie, ob der Service-Principal in der keytab vorhanden ist.
  • sudo tail -f /var/log/apache2/error.log — beobachten Sie auf GSSAPI-Fehler (gss_acquire_cred[_from]() failed to get server creds bedeutet keytab/Berechtigungen oder fehlender Principal).
  • Wenn curl --negotiate 401/403 zurückgibt, bedeutet das oft einen falschen Principal, kein Ticket, einen Host-Header-Konflikt 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.