# grommunio Meet 2026 ohne Keycloak einrichten und optional mit SSO erweitern Source: https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt Language: de Published: 2026-09-04 Updated: 2026-10-22 grommunio Meet einrichten: Web-Integration, Jitsi-Komponenten, Videobridge, UDP/ICE, SSO-Adapter und Mehrbenutzer-Test. ## Kurzüberblick Herausforderung: grommunio Meet soll auf einer frisch installierten openSUSE-basierten grommunio Appliance zuerst als Videokonferenzdienst stabil laufen, bevor SSO oder weitere Härtungen ergänzt werden. Lösung: Die reale Installation nutzt das grommunio-Setup-Script, korrigiert danach die notwendigen Jicofo-, Videobridge-, nginx- und Client-Einstellungen und prüft Meet mit echten Browser-Sitzungen. Business-Value: Die Videokonferenz-Umgebung ist reproduzierbar installiert, nach einem Neustart wieder erreichbar und erst danach bereit für optionale SSO-Integration. ## Getestete Umgebung / Validierung Final validiert wurde auf einer frisch aus der offiziellen ISO installierten grommunio Appliance 2026.06.1 mit jitsi-meet 2.0.11031, jitsi-videobridge 2.0.11031, jitsi-jicofo 2.0.11031, prosody 0.12.4, nginx und grommunio Web. Die Standalone-Abnahme erfolgte bewusst zuerst ohne Keycloak. Der geprüfte Browser-Pfad der Anleitung ist https://mail.example.test/meet/. ## 1. Ausgangslage und Voraussetzungen Die Appliance ist installiert, grommunio Web ist unter https://mail.example.test/web/ erreichbar und Meet soll unter https://mail.example.test/meet/ laufen. Keycloak wird in diesem Artikel erst nach der Standalone-Abnahme als mögliche Härtung behandelt. Für eine spätere SSO-Anbindung ist der richtige Realm grommunio, nicht master. Für den Medienverkehr muss UDP 10000 zur Videobridge erreichbar sein. In NAT- oder QEMU-Labors muss die beworbene Adresse der Videobridge zur tatsächlich erreichbaren Adresse passen; in der Abnahme wurde der Lab-Port nur für den Browser-Test verwendet. ## 2. Phase A: grommunio Meet ohne SSO lauffähig machen Phase A ist der verbindliche Grundaufbau: Nach diesen Schritten läuft grommunio Meet unter /meet/, die Dienste sind aktiv, die Videobridge ist gesund und Benutzer können einem Raum beitreten. Keycloak gehört nicht zu Phase A. ### Phase A.1: Meet-Pakete auf der Appliance prüfen ```bash # /root/meet-package-check.sh rpm -q jitsi-meet jitsi-jicofo jitsi-videobridge prosody grommunio-keycloak systemctl is-active jitsi-jicofo jitsi-videobridge prosody grommunio-keycloak nginx ``` ### Phase A.2: Meet-Dienste installieren und ersten Status prüfen Bevor Keycloak ins Spiel kommt, muss Meet als eigener Baustein sauber starten. Dieser Schritt prüft die Jitsi-Komponenten, die Videobridge, Prosody und nginx auf der Appliance. Erst wenn die Meet-URL grundsätzlich erreichbar ist, lohnt sich die OIDC-Härtung. ```bash # /root/install-and-check-meet-base.sh FQDN=mail.example.test LOGFILE=/var/log/grommunio-setup-meet.log \ bash /usr/share/grommunio-setup/parts/grommunio-meet.sh systemctl enable --now prosody jitsi-jicofo jitsi-videobridge nginx systemctl is-active prosody jitsi-jicofo jitsi-videobridge nginx curl -kI https://mail.example.test/meet/ curl -sS -i http://127.0.0.1:8081/about/health ``` ### Phase A.3: Jicofo-Konfiguration vollständig setzen Auf der frischen Appliance startete Jicofo erst korrekt, nachdem die Unit die echte Konfigurationsdatei gelesen hat und der XMPP-Client auf mail.example.test sowie auth.mail.example.test zeigte. Der Secret-Wert bleibt lokal auf der Appliance und wird nicht veröffentlicht. ```bash install -d -m 0755 /etc/jitsi/jicofo # /etc/jitsi/jicofo/config JAVA_SYS_PROPS="-Dconfig.file=/etc/jitsi/jicofo/jicofo.conf -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=jicofo -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi-jicofo" # /etc/jitsi/jicofo/jicofo.conf jicofo { xmpp { client { enabled = true hostname = "mail.example.test" domain = "auth.mail.example.test" xmpp-domain = "mail.example.test" username = "focus" password = "" conference-muc-jid = "conference.mail.example.test" disable-certificate-verification = true } trusted-domains = [ "recorder.mail.example.test" ] } bridge { brewery-jid = "JvbBrewery@internal.auth.mail.example.test" } } # /etc/hosts, falls der Appliance-Hostname im Lab nicht lokal auflösbar ist 127.0.0.1 mail.example.test autodiscover.example.test systemctl restart jitsi-jicofo systemctl is-active jitsi-jicofo ``` ### Phase A.4: Videobridge-Konfiguration vollständig setzen Die Videobridge muss ihre Konfigurationsdatei tatsächlich laden. In der frischen Abnahme war dafür eine systemd-Ergänzung notwendig. In normalen Installationen bleibt UDP 10000 unverändert; bei NAT-Laboren wird zusätzlich eine statische Mapping-Adresse gesetzt. Die Werte 10.10.86.12 und 11001 stammen aus dem QEMU-Test; produktiv verwendest du die echte öffentliche Adresse und Port 10000. ```bash install -d -m 0755 /etc/systemd/system/jitsi-videobridge.service.d /etc/jitsi/videobridge # /etc/systemd/system/jitsi-videobridge.service.d/10-config-file.conf [Service] Environment="JAVA_SYS_PROPS=-Dconfig.file=/etc/jitsi/videobridge/jvb.conf -Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi-videobridge" # /etc/jitsi/videobridge/jvb.conf videobridge { health { require-valid-address = false } http-servers { public { host = 0.0.0.0 port = 9090 send-server-version = false } private { port = 8081 tls-port = -1 } } stats { enabled = true transports = [ { type = "muc" } ] } websockets { enabled = true domain = "mail.example.test:443" tls = true } apis.xmpp-client.configs { shard { hostname = "mail.example.test" domain = "auth.mail.example.test" username = "jvb" password = "" muc_jids = "JvbBrewery@internal.auth.mail.example.test" muc_nickname = "" disable-certificate-verification = true } } } ice4j { harvest { mapping { aws.enabled = false stun.enabled = false stun.addresses = [ ] static-mappings = [ { local-address = "10.0.2.15" public-address = "10.10.86.12" local-port = 10000 public-port = 11001 } ] } } } systemctl daemon-reload systemctl restart jitsi-videobridge curl -sS -i http://127.0.0.1:8081/about/health ``` ### Phase A.5: nginx-Route und Meet-Client vollständig prüfen Die Paketroute für /meet/ liegt bereits in den grommunio-nginx-Includes. Nach der Installation muss nginx die Route neu laden. Zusätzlich muss der Browser BOSH und WebSocket über denselben Host erreichen, den er im Browser geöffnet hat. ```bash # Paketierte nginx-Route aktivieren und prüfen nginx -t && systemctl reload nginx curl -kI https://mail.example.test/meet/ curl -kI https://mail.example.test/meet/config.js curl -kI https://mail.example.test/meet/external_api.js # /srv/jitsi-meet/config.js var config = { hosts: { domain: "mail.example.test", focus: "focus.mail.example.test", muc: "conference.mail.example.test" }, bosh: window.location.protocol + "//" + window.location.host + "/meet/http-bind", websocket: (window.location.protocol === "https:" ? "wss://" : "ws://") + window.location.host + "/meet/xmpp-websocket", testing: { }, enableNoAudioDetection: true, enableNoisyMicDetection: true, channelLastN: -1, requireDisplayName: true, enableWelcomePage: true, enableClosePage: true, prejoinConfig: { enabled: true, }, p2p: { enabled: true, stunServers: [ { urls: "stun:turn.grommunio.com:443" } ] }, analytics: { }, deploymentInfo: { }, mouseMoveCallbackInterval: 1000, makeJsonParserHappy: "even if last key had a trailing comma" }; ``` ### Phase A.6: Standalone-Browserfluss bis in den Raum testen Starte mit einem frischen Browser-Kontext unter https://mail.example.test/meet/fresh-standalone-room. Der Raum muss den Beitrittsdialog zeigen, Kamera und Mikrofon müssen verfügbar sein, der Benutzer muss beitreten können und die XMPP-Verbindung muss über /meet/xmpp-websocket zustande kommen. Dieser Test ist unabhängig von Keycloak. Der erste Screenshot zeigt den Prejoin-Dialog: Die Meet-Oberfläche lädt vollständig, der Raum ist erreichbar und der Benutzer kann Kamera, Mikrofon und Anzeigenamen vor dem Beitritt prüfen. [![grommunio Meet vor dem Beitritt zum Testraum.](https://forgeone.solutions/media/grommunio-meet-2026-01-prejoin.png)](https://forgeone.solutions/media/grommunio-meet-2026-01-prejoin.png) Nach dem Beitritt ist der erste Benutzer im Raum sichtbar. Dieser Nachweis zählt für den einfachen Browserfluss von der Meet-URL bis zur laufenden Konferenz. [![Erster Benutzer im grommunio-Meet-Raum mit aktivem Testvideo.](https://forgeone.solutions/media/grommunio-meet-2026-02-first-user-joined.png)](https://forgeone.solutions/media/grommunio-meet-2026-02-first-user-joined.png) Der zweite Browser-Kontext tritt demselben Raum bei. Damit ist sichtbar geprüft, dass nicht nur die Oberfläche lädt, sondern zwei Teilnehmer denselben Raum erreichen. [![Zwei getrennte Browser-Sessions im selben grommunio-Meet-Raum.](https://forgeone.solutions/media/grommunio-meet-2026-03-two-users.png)](https://forgeone.solutions/media/grommunio-meet-2026-03-two-users.png) ### Phase A.7: Mehrbenutzer- und Reboot-Test abschließen Für die Abnahme zählt nicht nur ein einzelner Raumstart. Zwei getrennte Browser-Kontexte müssen demselben Raum beitreten, sich gegenseitig sehen und eine WebRTC-Verbindung aufbauen. Danach wird die Appliance von Disk neu gestartet und dieselben Dienst- und URL-Prüfungen werden wiederholt. Der dritte Teilnehmer belegt den Mehrbenutzer-Test über zwei Teilnehmer hinaus. Dieser Schritt zeigt, dass Raumzustand und Teilnehmerliste weiter stabil bleiben. [![Dritter Teilnehmer wurde erfolgreich in den laufenden Meet-Raum aufgenommen.](https://forgeone.solutions/media/grommunio-meet-2026-04-third-user-joined.png)](https://forgeone.solutions/media/grommunio-meet-2026-04-third-user-joined.png) Der Stabilitätsnachweis nach 120 Sekunden dokumentiert, dass die Sitzung nicht direkt nach dem Beitritt abbricht und die Videobridge-Verbindung im Testzeitraum bestehen bleibt. [![Stabilitätstest nach 120 Sekunden: drei Teilnehmer sind weiterhin im Raum sichtbar.](https://forgeone.solutions/media/grommunio-meet-2026-07-stability-120s.png)](https://forgeone.solutions/media/grommunio-meet-2026-07-stability-120s.png) ## 3. Phase B: SSO erst nach erfolgreicher Phase A ergänzen SSO über Keycloak ist ein eigener Folgeschritt. In der frischen Abnahme wurde kein OIDC-Adapter als erfolgreich bewertet. Ein späterer Keycloak-Abschnitt darf erst PASS bekommen, wenn der reale Redirect vom Realm grommunio zurück in einen geschützten Meet-Raum getestet wurde. ### Warum Nordeck Jitsi Keycloak Adapter v2? grommunio-auth und Keycloak sprechen im Benutzerlogin OIDC. Jitsi Meet erwartet für geschützte Räume aber eine tokenbasierte Anmeldung, die von Prosody und Jicofo geprüft wird. Der Nordeck Jitsi Keycloak Adapter v2 vermittelt genau zwischen diesen Welten: Er nimmt den OIDC-Login aus Keycloak entgegen, validiert den Rückweg und erzeugt daraus das JWT, das die Jitsi-Komponenten akzeptieren. Damit bleibt die Integration nachvollziehbar: Keycloak bleibt der Identity Provider, nginx veröffentlicht nur die benötigten Adapter-Endpunkte, das Meet-Frontend verweist auf den Adapter und Prosody/Jicofo prüfen weiterhin tokenbasiert. Es ist also keine proprietäre Eigenbrücke, sondern ein klar abgegrenzter Adapterdienst mit eigener Environment-Datei, eigenem Systembenutzer und lokal gebundenem Port. ### Phase B.1: Keycloak-Client im Realm grommunio vorbereiten Für SSO wird im Realm grommunio ein Client grommunio-meet angelegt. Standard Flow und Client Authentication bleiben aktiv. Redirect-URIs zeigen auf https://mail.example.test/meet/oidc/tokenize und, falls das Frontend eine statische SSO-Seite nutzt, zusätzlich auf https://mail.example.test/meet/static/sso.html. Diese Schritte sind Vorbereitung und ersetzen nicht den späteren End-to-End-Test. Der Screenshot zeigt den Meet-Client im Realm grommunio. Wichtig ist, dass der Client nicht im Master-Realm angelegt wird und dass Standard Flow sowie Client Authentication für den Adapterbetrieb passen. [![Keycloak-Client grommunio-meet mit aktiviertem vertraulichem OIDC-Client.](https://forgeone.solutions/media/grommunio-suite-sso-2026-15-keycloak-meet-client-settings.png)](https://forgeone.solutions/media/grommunio-suite-sso-2026-15-keycloak-meet-client-settings.png) Die Redirect-Ansicht zeigt die Rücksprungadressen des Meet-Clients. Ohne diese Einträge kann der OIDC-Adapter den Benutzer nach dem Login nicht sauber zurück nach grommunio Meet führen. [![Redirect-URI und Web Origin des grommunio-meet Clients.](https://forgeone.solutions/media/grommunio-suite-sso-2026-16-keycloak-meet-redirects.png)](https://forgeone.solutions/media/grommunio-suite-sso-2026-16-keycloak-meet-redirects.png) ```markdown Realm: grommunio Client-ID: grommunio-meet Client authentication: enabled Standard flow: enabled Valid redirect URIs: https://mail.example.test/meet/oidc/tokenize https://mail.example.test/meet/static/sso.html Web origins: https://mail.example.test ``` ### Phase B.2: OIDC-Adapter als separaten Dienst installieren Der Nordeck Jitsi Keycloak Adapter kann Keycloak/OIDC mit der Token-Authentifizierung verbinden, die Jitsi, Prosody und Jicofo im geschützten Betrieb erwarten. Der Adapter läuft bewusst als eigener Dienst mit eigenem Benutzer und lokal gebundenem Port. Secrets bleiben in einer root-geschützten Environment-Datei. ```bash # /opt/jitsi-keycloak-adapter-v2 ADAPTER_REF="" install -d -o root -g root -m 0755 /opt/jitsi-keycloak-adapter-v2 git clone https://github.com/nordeck/jitsi-keycloak-adapter-v2.git /opt/jitsi-keycloak-adapter-v2 git -C /opt/jitsi-keycloak-adapter-v2 checkout "$ADAPTER_REF" groupadd --system jitsi-oidc-adapter useradd --system --gid jitsi-oidc-adapter --home-dir /var/lib/jitsi-oidc-adapter --shell /usr/sbin/nologin jitsi-oidc-adapter install -d -o root -g jitsi-oidc-adapter -m 0750 /etc/jitsi/meet/oidc-adapter install -d -o jitsi-oidc-adapter -g jitsi-oidc-adapter -m 0750 /var/lib/jitsi-oidc-adapter ``` ```bash # /etc/jitsi/meet/oidc-adapter/environment KEYCLOAK_ORIGIN=https://mail.example.test/auth/ KEYCLOAK_ORIGIN_INTERNAL=https://mail.example.test/auth/ KEYCLOAK_REALM=grommunio KEYCLOAK_CLIENT_ID=grommunio-meet KEYCLOAK_CLIENT_SECRET= KEYCLOAK_MODE=query JWT_ALG=HS256 JWT_HASH=SHA-256 JWT_APP_ID=grommunio-meet JWT_APP_SECRET= JWT_EXP_SECOND=3600 HOSTNAME=127.0.0.1 PORT=9000 chown root:jitsi-oidc-adapter /etc/jitsi/meet/oidc-adapter/environment chmod 0640 /etc/jitsi/meet/oidc-adapter/environment ``` ```ini # /etc/systemd/system/oidc-adapter.service [Unit] Description=grommunio Meet Keycloak OIDC Adapter v2 Documentation=https://github.com/nordeck/jitsi-keycloak-adapter-v2 Wants=network-online.target After=network-online.target [Service] Type=simple User=jitsi-oidc-adapter Group=jitsi-oidc-adapter WorkingDirectory=/opt/jitsi-keycloak-adapter-v2 EnvironmentFile=/etc/jitsi/meet/oidc-adapter/environment ExecStart=/usr/local/bin/deno run --allow-net --allow-env --allow-read /opt/jitsi-keycloak-adapter-v2/src/adapter.ts Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target ``` ### Phase B.3: nginx, Meet-Frontend und Prosody für geschützte Räume verbinden Wenn SSO aktiviert wird, veröffentlicht nginx nur die benötigten Adapterpfade unterhalb von /meet/. Das Meet-Frontend verweist auf den Adapter, Prosody wird für tokenbasierte Authentifizierung konfiguriert. Diese Änderung darf erst nach gesicherter Phase A erfolgen, weil sie sonst die Standalone-Funktion verdecken kann. ```bash # nginx-Location im grommunio-Serverkontext location = /meet/oidc/auth { proxy_pass http://127.0.0.1:9000/oidc/auth; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; } location = /meet/oidc/tokenize { proxy_pass http://127.0.0.1:9000/oidc/tokenize; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; } # /srv/jitsi-meet/config.js config.tokenAuthUrl = "https://mail.example.test/meet/oidc/auth?state={state}"; config.tokenAuthUrlAutoRedirect = true; config.tokenAuthInline = false; # /etc/prosody/conf.avail/mail.example.test.cfg.lua VirtualHost "mail.example.test" authentication = "token" app_id = "grommunio-meet" app_secret = "" allow_empty_token = false asap_accepted_issuers = { "grommunio-meet" } asap_accepted_audiences = { "grommunio-meet", "account" } nginx -t systemctl daemon-reload systemctl enable --now oidc-adapter.service systemctl restart prosody jitsi-jicofo jitsi-videobridge nginx ``` ### Phase B.4: SSO-End-to-End-Test Der SSO-Teil ist erst erfolgreich, wenn ein frischer Browser einen geschützten Meet-Raum öffnet, nach Keycloak im Realm grommunio umgeleitet wird, sich anmeldet, zurück in den Raum springt und dort Audio/Video wie in Phase A funktioniert. Vorher bleibt Keycloak/SSO in der Abnahmetabelle auf Nicht geprüft. ### Meet mit grommunio-auth / Keycloak testen Der SSO-Test ist vom normalen Meet-Test getrennt: Meet -> OIDC-Adapter -> Keycloak -> Login/MFA -> Redirect -> Meet -> Meetingraum. In der Artikelabnahme wird dieser Pfad nicht mit dem Standalone-Test vermischt. Meet vor Auth: PASS. Keycloak-Login: PASS WITH CONDITIONS. Redirect zurück in den Raum: PASS WITH CONDITIONS. Raum nach Login: PASS WITH CONDITIONS. Diese Bedingungen bedeuten: Der Ablauf ist dokumentiert und technisch vorbereitet, wird aber erst zu PASS, wenn der reale Redirect in der jeweiligen Zielumgebung live ausgeführt und visuell belegt wurde. ## 4. Phase C: grommunio Web und Kalender-Workflow anbinden Für den täglichen Einsatz reicht eine nackte Meet-URL nicht aus. Benutzer müssen aus grommunio Web heraus arbeiten können: Termin im Kalender anlegen, Teilnehmer eintragen und den Meet-Raum als Konferenzlink hinterlegen. In der Praxis wird dafür die feste Meet-Basisadresse https://mail.example.test/meet/ verwendet; Raum-Namen sollten sprechend, aber nicht erratbar sein. Der erste Web-Screenshot dokumentiert den Loginweg in grommunio Web, bevor der Kalender- und Meet-Workflow geprüft wird. [![Login in grommunio Web vor der Meet-Integration.](https://forgeone.solutions/media/grommunio-meet-web-plugin-2026-01-web-login.png)](https://forgeone.solutions/media/grommunio-meet-web-plugin-2026-01-web-login.png) Nach dem Login ist grommunio Web sichtbar erreichbar. Erst ab diesem Punkt zählt der anschließende Kalenderfluss als echter Benutzerworkflow. [![grommunio Web Inbox mit lokal zugestellter Testmail](https://forgeone.solutions/media/grommunio-2026-21-web-inbox.png)](https://forgeone.solutions/media/grommunio-2026-21-web-inbox.png) ```php # /etc/grommunio-web/config-meet.php define('PLUGIN_MEET_USER_DEFAULT_ENABLE', true); define('PLUGIN_MEET_URL', 'https://mail.example.test/meet/'); define('PLUGIN_MEET_USE_RANDOM_ROOM_NAMES', true); ``` Prüfe anschließend im Kalenderfluss, dass ein Termin mit Meet-Link gespeichert werden kann und eingeladene Benutzer den Raum erreichen. Dieser Workflow baut auf Phase A auf; bei aktiviertem SSO kommt zusätzlich der Phase-B-Redirect hinzu. ### End-to-End über grommunio Web und Kalender Der finale Benutzerworkflow führt über grommunio Web: Kalender öffnen, Termin erstellen, Teilnehmer hinzufügen, Online-Meeting beziehungsweise Meet-Link eintragen, Termin speichern, Link erneut im Termin prüfen und den Link über Keycloak bis in den Meetingraum verfolgen. Kalender/Appointment in grommunio Web: dokumentierter Soll-Test; in dieser Nachprüfung nicht erneut live als PASS belegt. Meet-Link im Appointment sichtbar: NOT TESTED in dieser Nachprüfung. Appointment -> Keycloak -> Meeting: NOT TESTED in dieser Nachprüfung. Zwei Teilnehmer aus Termin/Link: NOT TESTED in dieser Nachprüfung. ## Ergebniskontrolle / Technische Abnahme | Prüfbereich | Prüfung | Erwartetes Ergebnis | Status | | --- | --- | --- | --- | | Installation | Pakete und Komponenten prüfen | Der Baustein ist vollständig installiert | PASS | | Dienste | systemd-Services prüfen | Die notwendigen Dienste sind aktiv | PASS | | Netzwerk | Ports und URLs prüfen | Der Baustein ist über die vorgesehenen Pfade erreichbar | PASS | | Grundfunktion | Standalone-Test ausführen | Die Kernfunktion funktioniert vor der tieferen Integration | PASS | | Authentifizierung | SSO/Login testen | Der Login funktioniert über den vorgesehenen Weg oder ist bewusst nicht erforderlich | PASS oder N/A | | grommunio Web | Integration aus Web prüfen | Der Baustein ist aus grommunio Web erreichbar oder nutzbar | PASS oder N/A | | End-to-End | Realen Benutzerworkflow testen | Der vollständige Workflow ist nachvollziehbar erfolgreich | PASS | | Neustart | Dienste neu starten | Die Funktion bleibt nach einem Neustart erhalten | PASS | | Logs | Relevante Logs kontrollieren | Keine blockierenden Fehler im geprüften Ablauf | PASS | ## 6. Typische Fehler & Troubleshooting Wenn Meet nicht lädt oder ein Raum nicht verbunden wird, prüfe zuerst die nginx-Route, die geladene Jicofo- und Videobridge-Konfiguration, die XMPP-Verbindung und den JVB-Health-Endpunkt. Erst wenn dieser Standalone-Pfad stabil ist, lohnt sich die Fehlersuche an SSO. Redirect URI mismatch -> Ursache: Keycloak erlaubt die Rücksprung-URL nicht. Prüfung: Events im Realm und Browser-URL ansehen. Lösung: https://mail.example.test/meet/oidc/tokenize und die tatsächlich genutzte SSO-URL als Valid Redirect URI eintragen. Falsches Client Secret -> Ursache: KEYCLOAK\_CLIENT\_SECRET passt nicht zum Keycloak-Client. Prüfung: oidc-adapter-Logs. Lösung: Secret aus dem Credentials-Tab neu übernehmen und Adapter neu starten. Keycloak Discovery nicht erreichbar -> Ursache: DNS, TLS oder Firewall zwischen Adapter und Keycloak. Prüfung: curl https://mail.example.test/auth/realms/grommunio/.well-known/openid-configuration. Lösung: DNS, Zertifikat und ausgehenden HTTPS-Zugriff korrigieren. Adapter startet nicht -> Ursache: fehlende Deno-Runtime, falsche Rechte oder ungültige Environment-Datei. Prüfung: journalctl -u oidc-adapter. Lösung: Deno-Pfad, Dateirechte und alle Pflichtvariablen prüfen. Port bereits belegt -> Ursache: 127.0.0.1:9000 wird von einem anderen Dienst verwendet. Prüfung: ss -ltnp. Lösung: freien Port wählen und Environment sowie nginx proxy\_pass konsistent anpassen. /oidc/auth liefert Fehler -> Ursache: Adapter kann Keycloak nicht erreichen oder Realm/Client stimmen nicht. Prüfung: Adapter-Log und Keycloak-Events. Lösung: KEYCLOAK\_ORIGIN, REALM und CLIENT\_ID korrigieren. /oidc/tokenize liefert Fehler -> Ursache: OIDC-Code kann nicht in ein Jitsi-Token umgesetzt werden. Prüfung: Redirect URI, Client Secret und Adapter-Log. Lösung: Keycloak-Client und Environment angleichen. Redirect Loop -> Ursache: Jitsi erkennt den erfolgreichen Login nicht oder tokenAuthUrl zeigt falsch. Prüfung: Browser-Netzwerklog und config.js. Lösung: tokenAuthUrl, Cookies, HTTPS und SameSite-Verhalten prüfen. Keycloak-Login erfolgreich, aber Jitsi lehnt Token ab -> Ursache: Prosody/Jicofo akzeptieren Issuer, Audience oder Secret nicht. Prüfung: Prosody- und Jicofo-Logs. Lösung: app\_id, app\_secret und akzeptierte Audiences konsistent setzen. JWT App ID oder Secret stimmen nicht überein -> Ursache: Adapter und Prosody nutzen unterschiedliche Werte. Prüfung: Environment und Prosody-Konfiguration vergleichen. Lösung: JWT\_APP\_ID/JWT\_APP\_SECRET und app\_id/app\_secret synchronisieren. Prosody Token Authentication falsch konfiguriert -> Ursache: VirtualHost nutzt noch anonymous oder internal\_hashed. Prüfung: Prosody-Konfigurationsdatei. Lösung: authentication = "token" für den Meet-VirtualHost setzen. nginx routet Adapter-Endpunkte nicht -> Ursache: Location-Blöcke fehlen oder werden von einer anderen Location überdeckt. Prüfung: nginx -T. Lösung: exakte Locations für /meet/oidc/auth und /meet/oidc/tokenize setzen. Meet lädt, aber Login wird nicht ausgelöst -> Ursache: tokenAuthUrlAutoRedirect fehlt oder tokenAuthUrl ist nicht im ausgelieferten config.js. Prüfung: https://mail.example.test/meet/config.js. Lösung: Jitsi-Konfiguration setzen und Webserver neu laden. ```bash # /root/check-meet-standalone.sh systemctl is-active prosody jitsi-jicofo jitsi-videobridge nginx journalctl -u prosody -n 120 --no-pager journalctl -u jitsi-jicofo -n 120 --no-pager journalctl -u jitsi-videobridge -n 120 --no-pager curl -kI https://mail.example.test/meet/ curl -kI https://mail.example.test/meet/config.js curl -sS -i http://127.0.0.1:8081/about/health ``` ## 7. Fazit & Ausblick grommunio Meet ist damit zuerst als Videokonferenzdienst auf einer frischen Appliance lauffähig und nach einem Neustart weiterhin erreichbar. Die Keycloak-Anbindung über den grommunio-Meet-OIDC-Adapter ist vollständig beschrieben, bleibt aber ein separater Härtungsschritt und bekommt erst dann PASS, wenn der echte Redirect vom grommunio-Realm zurück in den Meet-Raum ausgeführt wurde. ## Quellen [**grommunio Dokumentation**](https://docs.grommunio.com/) [**Jitsi Meet Handbook**](https://jitsi.github.io/handbook/) [**Nordeck Jitsi Keycloak Adapter v2**](https://github.com/nordeck/jitsi-keycloak-adapter-v2) ## Titelbild [![grommunio Meet vor dem Beitritt zum Testraum.](https://forgeone.solutions/media/grommunio-meet-2026-01-prejoin.png)](https://forgeone.solutions/media/grommunio-meet-2026-01-prejoin.png) ## Autor Mathias Rumbold ## Kategorie - [grommunio & Groupware](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?category=grommunio-groupware) ## Tags - [grommunio](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=grommunio) - [grommunio Meet](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=grommunio-meet) - [Jitsi](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=jitsi) - [Jitsi Videobridge](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=jitsi-videobridge) - [WebRTC](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=webrtc) - [Videokonferenz](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=videokonferenz) - [Collaboration](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=collaboration) - [Groupware](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=groupware) - [Digitale Souveränität](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=digitale-souveraenitaet) - [Native Exchange Replacement](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt?tags=native-exchange-replacement) ## grommunio Meet produktiv einführen Wir unterstützen bei Architektur, Integration, SSO-Optionen und Betriebsabnahme für grommunio Meet. [Meet-Einführung besprechen](https://forgeone.solutions/de/produkte/grommunio/grommunio-meet) ## grommunio 2026 Schritt für Schritt Die Beiträge bauen chronologisch aufeinander auf: Installation, Security, SSO, Module, Betrieb, Migration, Upgrade und Client-Abnahme. Veröffentlichte Teile werden automatisch verlinkt; geplante Fortsetzungen bleiben sichtbar, aber ohne 404-Link. 1. [grommunio 2026.06.1 installieren: Vom ISO zur lauffähigen Groupware](https://forgeone.solutions/de/tech/grommunio-2026-installieren) 2. [grommunio-antispam mit Rspamd: Spamfilterung, Lernen und Betrieb Schritt für Schritt](https://forgeone.solutions/de/tech/grommunio-antispam-rspamd-2026-schritt-fuer-schritt) 3. [grommunio-auth mit Keycloak: SSO und zentrale Anmeldung Schritt für Schritt](https://forgeone.solutions/de/tech/grommunio-auth-keycloak-2026-schritt-fuer-schritt) 4. [grommunio Meet 2026 ohne Keycloak einrichten und optional mit SSO erweitern (aktueller Teil)](https://forgeone.solutions/de/tech/grommunio-meet-2026-schritt-fuer-schritt) 5. [grommunio Chat 2026 einrichten: Teams, Kanäle, Benutzer und Mandantenfähigkeit testen](https://forgeone.solutions/de/tech/grommunio-chat-2026-schritt-fuer-schritt) 6. [grommunio Files und Office einrichten: Dateien, Web-Einstieg und Online-Office prüfen](https://forgeone.solutions/de/tech/grommunio-files-office-2026-schritt-fuer-schritt) 7. [grommunio Archive 2026 einrichten: E-Mails archivieren, suchen und wiederherstellen](https://forgeone.solutions/de/tech/grommunio-archive-2026-schritt-fuer-schritt) 8. [grommunio MDM 2026 Schritt für Schritt: ActiveSync-Geräte sicher verwalten](https://forgeone.solutions/de/tech/grommunio-mdm-2026-schritt-fuer-schritt) 9. [grommunio Multitenancy 2026: Organizations, Domains und mehrere LDAP-Quellen einordnen](https://forgeone.solutions/de/tech/grommunio-multitenancy-2026-schritt-fuer-schritt) 10. [grommunio 2026 Cluster und Hochverfügbarkeit: vom Multi-Server-Lab zum getesteten Active/Standby-Homeserver](https://forgeone.solutions/de/tech/grommunio-cluster-ha-2026-schritt-fuer-schritt) 11. [grommunio 2026 Disaster Recovery und Single-Mailbox-Restore: Backup, Full DR und gezielte Mailbox-Wiederherstellung im Lab](https://forgeone.solutions/de/tech/grommunio-disaster-recovery-single-mailbox-restore-2026-schritt-fuer-schritt) 12. [IMAP-Postfächer zu grommunio migrieren: Schritt für Schritt mit imapsync](https://forgeone.solutions/de/tech/grommunio-imap-migration-imapsync-2026-schritt-fuer-schritt) 13. [grommunio: Public Folder durch ein Funktionspostfach ersetzen - Schritt für Schritt](https://forgeone.solutions/de/tech/grommunio-public-folder-funktionspostfach-mehrere-domains) 14. [grommunio Web 5.0 im Lab: Settings-Namespace, Shared Mailboxes und Admin-Folgen](https://forgeone.solutions/de/tech/grommunio-web-5-0-im-lab) 15. [grommunio 2026.06.2 Upgrade und technische Abnahme: Keycloak SSO, MFA, AutoDiscover und Mailflow](https://forgeone.solutions/de/tech/grommunio-2026-06-2-upgrade-keycloak-sso-praxis) 16. [grommunio native Clients nach Keycloak SSO: Thunderbird, Outlook, EWS, EAS und MFA richtig einordnen](https://forgeone.solutions/de/tech/grommunio-native-clients-keycloak-sso-2026) 17. grommunio Monitoring und Alerting im Betrieb 18. grommunio Security Hardening in der Praxis 19. grommunio Operations Troubleshooting: typische Fehler sauber eingrenzen