Kopano-Meet - Anmeldung nicht möglich

Apps & App Center
,
1

In einer ucs@school Umgebungen habe ich einen Member Server (ucs4.4-4) aufgesetzt und

• Open-Id-Conncetor und Kopano-Meet App installiert,
• den Server per dyndns-Adresse von außen erreichbar gemacht,
• diese dyndns-Adresse für den Open-id-Conncetor genutzt, entsprechend Kopano-Meet config angepasst,
• Let´s Encrypt installiert und SSL-Zertifikat für die dyndns-Adresse erstellt,
• zuletzt das Zertifikat in den apache2/ssl und saml/apache2/ssl Einstellungen gesetzt

Wenn ich nun Kopano-Meet aus dem Univention-Portal öffne erhalte ich den Anmelde-Button, der nach betätigen versucht den oidc zu erreichen und wieder zurück auf /meet springt. Eine Anmeldung ist nicht möglich.

In der Konsole Web-Entwickler Tools erhalte ich folgendes:
grafik

@fbartels Eine Idee wieso?

Tani

2

Hallo @tani,

ich habe unter https://wiki.z-hub.io/display/K4U/Debugging+Kopano+on+Univention#DebuggingKopanoonUnivention-Containerisedapps eine Reihe von Kommandos versammelt um Probleme bei der Inbetriebnahme von Meet zu debuggen.

Das ist bereits das erste Zeichen das etwas nicht stimmt. Normalerweise sollte man direkt den Anmeldebildschirm sehen. Diesen Button sieht man nur wenn der erste Anmeldeversuch fehlgeschlagen ist.

3

Hallo @fbartels,

  1. System ist erfolgreich der Domäne beigetretten:
    root@video:~# univention-check-join-status
    Joined successfully

  2. FQDN_MEET und FQDN_SSO ist auf die dynds-Adresse des Server:
    root@video:~# ucr dump | grep kopano/docker | grep -v PASSWORD
    kopano/docker/FQDN_MEET: video-lindlar$dyndns$tv
    kopano/docker/FQDN_SSO: video-lindlar$dyndns%tv
    …

  3. Variable oidc/konnected(issuer_identifier ist auf dynds-Adresse der Servers gesetzt:
    root@video:~# ucr search --brief oidc/konnectd/issuer_identifier
    oidc/konnectd/issuer_identifier: https§//video-lindlar$dyndns$tv

  4. https§//video-lindlar$dyndns$tv/.well-known/openid-configuration ist abrufbar:
    root@video:~# curl $(ucr get oidc/konnectd/issuer_identifier)/.well-known/openid-configuration
    {
    “issuer”: “https§//video-lindlar$dyndns$tv”,
    “authorization_endpoint”: “https§//video-lindlar$dyndns$tv/signin/v1/identifier//authorize",
    “token_endpoint”: “https§//video-lindlar$dyndns$tv/konnect/v1/token”,
    “userinfo_endpoint”: “https§//video-lindlar$dyndns$tv/konnect/v1/userinfo”,
    “end_session_endpoint”: "https§//video-lindlar$dyndns$tv/signin/v1/identifier/    /endsession”,
    “check_session_iframe”: “https§//video-lindlar$dyndns$tv/konnect/v1/session/check-session.html”,
    “jwks_uri”: “https§//video-lindlar$dyndns$tv/konnect/v1/jwks.json”,
    “scopes_supported”: [
    “openid”,
    “offline_access”,
    …

  5. wie auch https§//video-lindlar$dyndns$tv/signin/v1/welcome/
    root@video:~# curl $(ucr get oidc/konnectd/issuer_identifier)/signin/v1/welcome

  • als auch FQDN_SSO/signin/v1/welcome
    curl https§//$(ucr get kopano/docker/FQDN_SSO)/signin/v1/welcome
  • im yaml-File sind als Clients sowohl interene Clienthostname (Domäne des UCS) als der über außen erreichbare:
    clients:
    • id: kpop-https§//video-lindlar$dyndns$tv/meet/
      name: Kopano Meet
      application_type: web
      trusted: true
      redirect_uris:
      • https§//video-lindlar$dyndns$tv/meet/
        trusted_scopes:
      • konnect/guestok
      • kopano/kwm
        jwks:
        keys:
        • kty: EC
          use: sig
          crv: P-256
          d: G-udY_euOfCZ-stsdypyC7Jv1QNLXXXXXXX
          kid: meet-kwmserver
          x: 1r6Pz-GcLp9OKqNcnPkXXXXXXX
          y: QzFx4GBBdl7smKgsct4uXXXXXXXXX
          request_object_signing_alg: ES256
    • id: kpop-https§//video$schulen$lindar$de/meet/
      name: Kopano Meet
      application_type: web
      trusted: true
      redirect_uris:
      • https§//video$schulen$lindar$de/meet/
        trusted_scopes:
      • konnect/guestok
      • kopano/kwm
        jwks:
        keys:
        • kty: EC
          use: sig
          crv: P-256
          d: G-udY_euOfCZ-stsdXXXXXXXX
          kid: meet-kwmserver
          x: 1r6Pz-GcLp9OKqNcnXXXXXXXX
          y: QzFx4GBBdl7smKgsct4uXXXXXXXXX
          request_object_signing_alg: ES256
          authorities:
    • name: ucs-konnect
      default: true
      iss: https§//video-lindlar$dyndns$tv
      client_id: kopano-meet
      authority_type: oidc
      response_type: id_token
      scopes:
      • openid
      • profile
      • email
        trusted: true
        end_session_enabled: true
    1. Logfiles:
      Hier jedoch wird angezeigt, dass der /.well-known/openid-configuration nicht aufgerufen werden kann -> timeout:

    kopano_kwmserver | 2020/05/31 12:37:18 Waiting for https://video-lindlar.dyndns.tv/meetid/.well-known/openid-configuration: Get https://video-lindlar.dyndns.tv/meetid/.well-known/openid-configuration: dial tcp 62.246.114.65:443: i/o timeout.

    …

    kopano_konnect | time=“2020-05-31T12:51:55Z” level=error msg=“error while oidc provider update: oidc provider error: failed to fetch discover document: failed to fetch JSON: Get “https§//video-lindlar$dyndns$tv/.well-known/openid-configuration”: context deadline exceeded” id=ucs-konnect type=oidc

    Da ich max zwei Links posten kann habe ich
    : mit §
    und
    . mit $
    erstetzt.
    Hoffe ist noch leserlich geblieben.

    4

    Hi @tani,

    als generellen Tipp würde ich empfehlen Code Blöcke als solche zu formatieren (Markdown Syntax oder der Button mit “Preformatted text” im Editor). Dann sollte sich Discourse hoffentlich auch nicht über Links beschweren.

    Grundsätzlich sieht das aber alles ok aus. Selbst wenn kwmserver nicht läuft, dann sollte der Login grundsätzlich aber klappen. Aber wenn Konnect nicht den “äußeren Provider” (die OpenID App von Univention) auflösen kann dann lässt sich das gesehene Verhalten durchaus damit erklären, Ich sehe beim Aufruf der Domain hier z.B. auch keine Weiterleitung an den “äußeren Provider”.

    Das sollte sich vermutlich mit einem einfachen Restart des Containers beheben lassen.

    In einer neueren Version habe ich etwas Skripting verbaut um Konnect beim Start fehlschlagen zu lassen, wenn der äußere Provider nicht richtig konfiguriert ist.

    5

    Hallo @fbartels,

    ein Neustart vom welchem Container?
    Ein Neustart von Kopano-Meet hilft nicht:
    root@video:/var/lib/univention-appcenter/apps/kopano-meet/compose# docker-compose restart

    Restarting kopano_konnect … done
    Restarting kopano_meet … done
    Restarting kopano_kapi … done
    Restarting kopano_web … done
    Restarting kopano_kwmserver … done
    Restarting kopano_ssl … done
    Restarting kopano_grapi … done

    Zudem sehe ich auch dass kopano_kapi und kopano_kwmserver unhealthy sind:
    root@video:/var/lib/univention-appcenter/apps/kopano-meet/compose# docker-compose ps
    Name Command State Ports

    kopano_grapi /usr/bin/dumb-init – /kop … Up (healthy)
    kopano_kapi /usr/bin/dumb-init – /kop … Up (unhealthy)
    kopano_konnect wrapper.sh Up (healthy) 6777/tcp, 8777/tcp
    kopano_kwmserver docker-entrypoint.sh wrapp … Up (unhealthy) 6778/tcp, 8778/tcp
    kopano_meet /kopano/start-service.sh Up (healthy)
    kopano_ssl /start.sh Exit 0
    kopano_web docker-entrypoint.sh wrapp … Up (healthy) 0.0.0.0:2015->2015/tcp, 443/tcp, 80/tcp

    6

    kopano_konnect

    Den Health Status kann man auf folgende Weise abfragen (nur halt kopano_konnect durch den gewünschten Container ersetzen):

    docker inspect --format='{{json .State.Health}}' kopano_konnect | jq .

    Das Startup Logging von Konnect würde mich noch interessieren. Denke aber es ist das Beste wenn du dich einmal mit unserem Support in Verbindung setzt, damit sich jemand dein System genauer ansehen kann.