Nach Wazuh-Upgrade sind Agenten „verschwunden“: RBAC/LDAP-Sichtbarkeit vs. OpenSearch-Security-Zustand sauber trennen und reparieren

von

Einleitung

Wenn nach einem Wazuh-Upgrade plötzlich keine Agenten mehr im Dashboard erscheinen, obwohl Events weiterhin vom Agenten ankommen, ist das fast nie ein „Agent offline“-Problem. In der Praxis steckt dahinter häufig eine Kombination aus RBAC (Rollen-/Rechtemodell), LDAP/AD-Mappings und einem instabilen oder nicht initialisierten OpenSearch-Security-Plugin. Das Ergebnis: Der Manager verarbeitet Daten, aber der Dashboard-User darf (scheinbar) nichts sehen – oder die Rollenauflösung bricht im Backend weg.

Ausgangslage / Problemstellung

Nach einem Upgrade von Wazuh 4.13.1 auf 4.14.3 in einer All-in-one-Installation (Single Node / „Single cluster“) sind Agenten im Wazuh Dashboard für AD/LDAP-gemappten Administrator-Account nicht mehr sichtbar.
Wichtige Beobachtungen aus der Umgebung:

  • Logs/Ereignisse kommen weiterhin an (Manager verarbeitet SCA/Rootcheck etc.).
  • Mit dem lokalen Default-Admin im Dashboard sind die Agenten sichtbar → reines UI- oder Agentenproblem ist unwahrscheinlich.
  • Im Manager-Log tauchen Indexer-Fehler auf:
    • indexer-connector: ... 503 ... OpenSearch Security not initialized
  • Im Indexer-Clusterlog tauchen zusätzlich LDAP/Rollen-Auflösungsfehler auf, u. a.:
    • „Cannot retrieve roles … from ldap … No user … found“
  • Parallel Warnungen über abgebrochene Tasks wegen hoher Ressourcennutzung (Search backpressure / Heap).

Kurz: RBAC-Symptom (User sieht keine Agenten) + Indexer-Security-Zustand (Security-Plugin inkonsistent) + LDAP/AD-Rollenauflösung (BackendRoles werden nicht sauber aufgelöst).

Technische Analyse

1) Warum „Agenten kommen, aber sind nicht sichtbar“ möglich ist

In Wazuh sind „Agent sichtbar im Dashboard“ und „Events werden verarbeitet“ zwei getrennte Pfade:

  • Eingang & Verarbeitung: Agent → Manager (remoted/analysisd/modulesd) → Indexer (über indexer-connector)
  • Anzeige & Berechtigung: Dashboard-User → RBAC/Permissions (OpenSearch Security / Wazuh-App) → Query auf Indizes/Agenten-Metadaten

Wenn ein AD/LDAP-User keine Agenten sieht, der Default-Admin aber schon, ist das nahezu immer Role Mapping / Backend Role / Tenant / Index Permissions – oder die Rollenauflösung ist „leer“, weil das Security-Subsystem gerade kaputt ist.

2) „OpenSearch Security not initialized“ ist ein Game-Stopper für RBAC

Der Fehler 503 ... OpenSearch Security not initialized deutet darauf hin, dass der Security-Index bzw. der Security-Plugin-State (bei OpenSearch Security historisch z. B. .opendistro_security) nicht geladen oder inkonsistent ist. In diesem Zustand kann OpenSearch:

  • Rollen und Mappings nicht zuverlässig auflösen
  • Requests mit 503 beantworten
  • Aus Sicht des Dashboards wirkt es dann so, als hätte der User keine Rechte (Agentenliste leer), obwohl die LDAP-Mappings korrekt aussehen

Das erklärt auch die Beobachtung „Vor dem Update ging es“: Nicht zwingend das Mapping ist falsch, sondern nach dem Upgrade kann der Security-Plugin-State „aus dem Tritt“ geraten sein (z. B. Security-Index nicht initialisiert, Zertifikate/Hostnames, Cluster-Zustand, Security-Admin nicht gelaufen).

3) LDAP/AD-Mappings: korrekt auf Papier, aber wirkungslos in der Kette

Wazuh dokumentiert die LDAP-Integration so, dass AD/LDAP-Gruppen (CN/Backend Role) in der roles_mapping.yml auf z. B. all_access gemappt werden.
Wenn aber OpenSearch Security nicht sauber initialisiert ist, greift dieses Mapping nicht verlässlich – und zusätzlich können Fehlkonfigurationen in der Authc/Authz-Kette dazu führen, dass sogar interne Service- oder Admin-User „gegen LDAP aufgelöst“ werden (Fehlerbilder wie „No user admin found“).

4) Ressourcen-/Heap-Warnungen verstärken das Problem

Die Search-Backpressure-Warnungen zeigen, dass der Indexer Tasks wegen hoher Ressourcennutzung abbricht. Das kann Auth-/LDAP-Lookups und Security-Initialisierung zusätzlich destabilisieren. Es ist oft nicht die Primärursache, aber ein relevanter Verstärker: erst Stabilität herstellen, dann RBAC final prüfen.

Lösung / Best Practices

Die robuste Reihenfolge ist: Indexer-Security stabilisieren → Cluster Health prüfen → Security-Konfiguration re-pushen → Services sauber neu starten → LDAP/RBAC validieren.

Schritt 1: Faktencheck – sind Agenten am Manager wirklich da?

Auf dem Manager (Backend) prüfen:

/var/ossec/bin/agent_control -l

Wenn die Agenten hier gelistet sind, ist das Problem nicht „Agent weg“, sondern Anzeige/RBAC/Indexer.

Schritt 2: Indexer erreichbar und Cluster gesund?

Direkt am Indexer (All-in-one meist localhost) prüfen:

curl -k -u <WAZUH_INDEXER_USERNAME>:<WAZUH_INDEXER_PASSWORD> \
  https://<WAZUH_INDEXER_IP>:9200/_cluster/health?pretty

Wenn hier bereits 503 oder „Security not initialized“ kommt, zuerst Security reparieren.

Schritt 3: OpenSearch Security (Wazuh Indexer) re-initialisieren / Konfiguration neu anwenden

Wazuh nutzt ein Security-Admin-Skript (Wazuh-Paketname kann opensearch-securityadmin.sh sein), um Security-Konfiguration (Users/Roles/RoleMappings/etc.) in den Security-Index zu schreiben.

Beispiel (wie in der Praxis üblich):

/usr/share/wazuh-indexer/bin/opensearch-securityadmin.sh \
  -cd /etc/wazuh-indexer/opensearch-security/ \
  -icl -nhnv \
  -cacert /etc/wazuh-indexer/certs/root-ca.pem \
  -cert /etc/wazuh-indexer/certs/admin.pem \
  -key /etc/wazuh-indexer/certs/admin-key.pem

Wichtige Details dazu:

  • -nhnv deaktiviert Hostname-Verification (häufig nötig, wenn Zertifikats-SAN/Hostname nicht exakt passt).
  • Das Tool läuft standardmäßig nur zuverlässig, wenn der Cluster mindestens yellow ist; bei red braucht man je nach Situation Zusatzoptionen (z. B. „accept red cluster“).
  • Wenn Security nicht initialisiert ist, ist genau dieses „Pushen“ der Security-Konfiguration in den Security-Index der entscheidende Schritt.

Schritt 4: Services in sinnvoller Reihenfolge neu starten

Nach erfolgreicher Initialisierung/Anwendung:

systemctl restart wazuh-indexer
systemctl restart wazuh-manager
systemctl restart wazuh-dashboard

Danach erneut Cluster Health und Dashboard-Login testen.

Schritt 5: LDAP/AD-Role-Mappings verifizieren – aber erst nach stabiler Security

Wenn der Default-Admin alles sieht, der AD-User nicht: Mapping prüfen, basierend auf offizieller Wazuh-Doku.

Prüfpunkte (typische Fallen):

  1. Backend role stimmt exakt (Schreibweise/Format):
    • AD-Gruppenname (CN) muss genauso in roles_mapping.yml stehen, wie er als backend_roles vom LDAP-Backend geliefert wird.
  2. Richtige Rolle gemappt:
    • Für Vollzugriff ist all_access der übliche Zielpunkt (Indexer-Rolle).
  3. Authc/Authz-Kette (config.yml im Security-Plugin):
    • Interne System-User (z. B. Admin/Service-User) sollten nicht „zwangsläufig“ über LDAP aufgelöst werden.
    • Wenn Logs zeigen, dass interne User gegen LDAP geprüft werden („No user … found“), ist die Reihenfolge/Chain wahrscheinlich inkonsistent oder Security-State war währenddessen defekt.
  4. Cache-Effekte:
    • Nach Mapping-Änderungen immer Security-Konfig neu pushen (SecurityAdmin) und Services neu starten.

Schritt 6: Ressourcen stabilisieren (damit RBAC nicht fluktuiert)

Wenn Backpressure/Heap-Events gehäuft auftreten, sollte man die Indexer-Ressourcen und JVM-Heap prüfen/anpassen und unnötig schwere Queries/Visualisierungen identifizieren. Ziel: Indexer dauerhaft gelb/grün, keine dauernden Task-Cancels – sonst bekommt man „sporadische“ RBAC-/Login-/LDAP-Effekte.

Lessons Learned / Best Practices

  • Symptome sauber trennen: „Agent sendet Daten“ ist nicht gleich „User darf Agenten sehen“. RBAC ist ein eigener Pfad.
  • Bei RBAC-Problemen zuerst Indexer-Security-Zustand prüfen: 503 / „Security not initialized“ führt fast zwangsläufig zu „leeren“ Berechtigungen im Dashboard.
  • Security-Konfiguration nach Upgrades aktiv validieren: Cluster Health, Security-Index/Plugin, SecurityAdmin-Run als Upgrade-Postcheck.
  • LDAP-Integration nach Standard umsetzen und dokumentieren: Mapping (Backend Roles), Role-Mappings, Authc/Authz-Kette, Zertifikate.
  • Cluster muss stabil laufen: Backpressure/Heap-Probleme zuerst entschärfen, sonst werden Authz-Lookups und UI-Abfragen unzuverlässig.

Fazit

Wenn nach dem Upgrade Agenten „verschwinden“, aber der Default-Admin sie sieht, ist das in der Regel kein Agentenproblem, sondern RBAC/LDAP – häufig verschärft durch einen inkonsistenten OpenSearch-Security-Status. Der zuverlässigste Weg ist, zuerst den Indexer (Security-Plugin, Cluster Health, SecurityAdmin-Reinitialisierung) zu stabilisieren und anschließend die LDAP-Role-Mappings zu verifizieren. Damit wird aus einem scheinbaren Dashboard-Fehler wieder eine saubere, nachvollziehbare Rechtekette.

Quellen (Copy & Paste)

https://documentation.wazuh.com/current/user-manual/user-administration/ldap.html
https://docs.opensearch.org/latest/troubleshoot/security-admin/

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

https://wazuh.slack.com/archives/C0A933R8E/p1770992369992739