Kopano Meet ist der Zeit in UCS leider nicht so ohne weiters funktionsfähig, da der Hersteller die Version nicht aktualisiert hat. Dies hat eine Inkompatibilität mit der aktuellen Version von OpenID zur Folge.
Lösbar ist das ganze mit einem Downgrade. Für das muss zuerst Kopano Meet deinstalliert werden, und danach OpenID in einer alten Version installiert werden. univention-app install openid-connect-provider=1.0-konnect-0.23.3
im Prinzip funktioniert es ja. Wenn ihr wollt, schaut mal bitte bei einem Kunden von mir: https://ucs-sso.cloud-seniorenstift.de/ Dort ist noch die alte OpenID App installiert.
Wenn man Kopano aufruft und die Sicherheitswarnung im Browser bestätigt, kann man sich anmelden und Kopano nutzen. Aber das ist natürlich nicht schön.
Wenn man jetzt ein Let`s Encrypt Zertifikat für ucs-sso.cloud-seniorenstift… installiert, geht es nicht mehr über https://ucs-sso.cloud-seniorenstift.de//meet/r/call hinaus. Keine Anmeldung, nichts. Nur noch das Kopano Logo
Sorry, ich muss mich korrigieren. Die Aussage muss so aussehen: Die betreffende Stelle habe ich fett markiert.
Wo kann ich das Log finden?
Danke
Hallo zusammen,
im Prinzip funktioniert es ja. Wenn ihr wollt, schaut mal bitte bei einem Kunden von mir:
https://ucs-shb.cloud-seniorenstift.de/ Dort ist noch die alte OpenID App installiert.
Wenn man Kopano aufruft und die Sicherheitswarnung im Browser bestätigt, kann man sich anmelden und Kopano nutzen. Aber das ist natürlich nicht schön.
Wenn man jetzt ein Let`s Encrypt Zertifikat für ucs-sso.cloud-seniorenstift… installiert, geht es nicht mehr über https://ucs-sso.cloud-seniorenstift.de//meet/r/call hinaus. Keine Anmeldung, nichts. Nur noch das Kopano Logo
Eine aktualisierte Version sitzt nun schon seit einigen Wochen im Test Appcenter und wartet auf die Freigabe durch Univention. Aber eine inkompatibilität zur OpenID Provider App ist mir derzeit nicht bekannt, die neue Version stellt die Möglichkeit her Meet innerhalb des Intranet Plugins in der WebApp einzubinden.
Hallo Leute, wie ist denn hier der Status? Funktioniert der neue OpenID Connector 2.2-konnect-0.33.11 bereits mit Kopano Meet? Hab hier noch 1.0-konnect-0.23.3 am laufen.
Nachteil: Von außen funktioniert Meet nun nicht mehr. Kommt nur das schöne große Meetlogo und nach ein paar Sekunden kommt die Timeoutmeldung.
ucr get kopano/docker/FQDN_MEET
darkdevil.osit.cc
ucr get kopano/docker/FQDN_SSO
darkdevil.osit.cc
ucr get oidc/konnectd/issuer_identifier
https://darkdevil.osit.cc
Nun sehe ich aber im Webbrowser das von außen nun trotz korrekten SSO Einstellungen auf ucs-sso.osit.cc umgeschaltet wird. Diese Adresse zeigt auf eine interne IP, somit bleibt der ganze Vorgang stehen.
Habe nun den öffentlichen DNS geändert. Hat leider nichts gebracht. Hier noch die gesamten Meet Variablen. @fbartels magst du das bitte mit deiner Config vergleichen, da gibt es sicher wo nen gravierenden Unterschied. Vielen Dank.
ucr dump | grep -i meet
appcenter/apps/kopano-meet/container: bae3f926bae058f4dd33c205eb95069asdfs334358d2448a3949ff11ec6c
appcenter/apps/kopano-meet/hostdn: cn=kopan-46393153,cn=memberserver,cn=computers,dc=osit,dc=cc
appcenter/apps/kopano-meet/image: docker.software-univention.de/kopano-meet-kopano_grapi:2.3.1_0
appcenter/apps/kopano-meet/ports/2015: 2015
appcenter/apps/kopano-meet/status: installed
appcenter/apps/kopano-meet/ucs: 4.4
appcenter/apps/kopano-meet/version: 2.3.1_0
kopano-meet/autostart: yes
kopano/docker/FQDN_MEET: darkdevil.osit.cc
kopano/docker/MEET_GUEST_ALLOW: yes
kopano/docker/MEET_GUEST_REGEXP: ^group/public/.*
ucs/web/overview/entries/service/kopano-meet/description/de: Die sichere Open Source Videokonferenzlösung für den professionellen Einsatz
ucs/web/overview/entries/service/kopano-meet/description: The secure and open source videoconferencing solution for professionals
ucs/web/overview/entries/service/kopano-meet/icon: /univention/js/dijit/themes/umc/icons/scalable/apps-kopano-meet_20201221164302.svg
ucs/web/overview/entries/service/kopano-meet/label/de: Kopano Meet
ucs/web/overview/entries/service/kopano-meet/label: Kopano Meet
ucs/web/overview/entries/service/kopano-meet/link: /meet
ucs/web/overview/entries/service/kopano-meet/port_http: 80
ucs/web/overview/entries/service/kopano-meet/port_https: 443
When I visit that domain and open Meet, it tries to redirect to https://ucs-sso.osit.cc, which is not trusted (lets encrypt certificate, but the domain is not part of it) and then gives a 404 because simplesamphp cannot be found. It first goes to https://darkdevil.osit.cc/signin/v1/identifier (which would be the openid provider app), but then for the actual saml sign in into the openid provider app some configuration seems to be off.
bin nun auf folgendes dahinter gekommen. Da nun alles auf SAML passiert hilft natürlich der SSO nicht wenn dieser auf darkdevil.osit.cc zeigt, das ist ein Slaveserver. Nun hab ich zum den Test einen Domänenserver per public freigegeben und mit öffentlichem DNS auf ucs-sso.osit.cc auf diese public IP, und schon hat es funktioniert.
Nun stellen sich für mich hier ein paar Fragen:
Dem Zertifikat wird nicht vertraut sofern man keine bekannte Umgebung verwendet, kann ja garnicht, da bei ucs-sso das Domänenzertifikat von UCS verwendet wird. Kann das überhaupt mit einem Let’s Encrypt verknüpfen? Proxy?
Zum Zweiten müsste man eine Apacheconfig schaffen, die den Zugang maximal auf ucs-sso.osit.cc beschränkt, ansonsten wäre das UCS Portal und andere Dinge die auf Port 80/443 abrufbar sind frei für Hackerangriffe.
Was hat sich der Hersteller hierbei genau gedacht, ich konnte hierfür noch keine Anleitung finden wie man dies nach best practice konfiguriert
Ich hab das Portforwarding auf SSO natürlich für’s erste wieder abgeschaltet.
Ich bin nicht sicher, ob ich die Bedenken richtig nachvollziehen kann.
Ja, aber ist das nicht das “Problem” mit allen Applikationen die in Richtung Internet geöffnet sind? Der Vorteil an einem zentralen Auth Endpunkt (wie ucs-sso) ist aber dass man so für eine vielzahl von Diensten nur eine einzelne Remote Access Lösung braucht.
Im Falle von Meet müsste ucs-sso auch nur für diejenigen Nutzer erreichbar sein, die sich mit einem Nutzerkonto anmelden sollen (per VPN z.B.). Gäste brauchen keinen Zugriff darauf.
ja, das mit Sicherheit könnten wir über einen Proxy lösen. Im Endeffekt bin ich voll bei dir. Für Auth. nehmen wir die VPN. Öffentliche Meetings funktionieren wie du schon richtig sagtest, auch so. Hatte heute Nachmittag ein. Alles wunderbar.