Konferenz ID

Eine Lync Konferenz gewährt den Zugang über einen Rufnummer mit einer Konferenz-ID oder über eine Konferenz-URL. Beide Adressen enthalten eine scheinbar zufällige Nummer bzw. Buchstabenkombination. Diese Seite möchte dieser Konferenz-ID etwas näher beleuchten.

Meetings planen

Eine Konferenz wird immer dann erforderlich, wenn mehr als zwei Personen miteinander per Audio oder Video kommunizieren wollen oder zusätzliche Dienste wie Desktop-Sharing, Whiteboard, Powerpoint Präsentation oder umfragen benutzt werden. Sie können über verschiedene Wege eine Konferenz starten. Oft bleibt es sogar unbemerkt, dass im Hintergrund eine Konferenz gestartet wurde.

  • Sofortbesprechung/MeetNow im Lync Communicator
    Über das Menü können sofort eine Konferenz starten, die sie dann mit Material (z.B. Powerpoint) bestücken können und dann weitere Teilnehmer dazu einladen, z.B. indem Sie diese aus den Lync Kontakten addieren oder per DialOut aus der Konferenz anrufen:
  • Hochstufen einer P2P Verbindung
    Auch aus einem 1:1 Telefonat kann automatisch eine Konferenz werden, wenn Sie eine dritte Person addieren.
  • Ruf an mehrere Personen
    Sie können aber auch aus der Buddy-Liste im Communicator mehrere Personen markieren und dann über das Kontext-Menü eine Konferenz starten. Dann startet die Konferenz auch direkt.
  • Lync Web Schedule
    Auch mit einen Webbrowser können Sie seit Lync 2013 sehr einfach Konferenzen planen.
  • Lync Termin in Outlook
    In Outlook können Sie bei installiertem Lync-Client auch direkt einen Termin planen, der in ihrem Kalender eingetragen und an die Teilnehmer versendet wird. Hierbei können Sie schon im Termin einige Optionen des Meetings direkt einstellen.

In allen Fällen "spricht" der Communicator, Webbrowser oder das Lync AddIn in Lync mit dem Backend Server des Benutzers und legt eine Konferenz an. Und jede Konferenz hat immer eine Konferenzkennung (Numerisch) und eine Konferenz-ID (Buchstaben/Zahlen)

Die Konferenz auf dem Server

Technisch ist dies aber erst einmal nur ein Datenbankeintrag, mit dem eine Konferenz dem Benutzer zugewiesen wird. Eine MulticastUnit (MCU) wird damit noch nicht gestartet. Die Konferenz zeichnet zwei Dinge aus:

  • Zugangsnummer mit PIN
    Über diesen Zugang können sich Teilnehmer per Telefon einwählen.
  • Zugangs-URL
    Die Meeting-URL wird mit dem Username und einer Zeichenkette dem Anwender bereit gestellt. Wer diese URL kennt und diese anklickt, landet auf der Lync Webseite des Pools und wird abhängig vom Client dann mit dem Communicator oder LyncWebApp in das Meeting aufgenommen.

Erst wenn der erste Client auch diesen Dienst anfordert, startet der Lync Server die angeforderte MCU für diese Konferenzen. Es gibt drei MCUs

  • DataMCU
    Sorgt dafür, dass Instant Messages und andere Dateninhalte von einem Sender zu den anderen Konferenzteilnehmern geleitet werden
  • AudioMCU
    Überträgt die Empfangenen Audiodaten und sendet diese an die anderen Teilnehmer
  • VideoMCU
    Diese MCU ist für die Vermittlung der verschiedenen Videoströme der Teilnehmer

Weiter möchte ich auf die MCUs auf dieser Seite aber nicht eingehen.

Die Konferenz ID und die Konferenz Verzeichnisse

Interessant ist natürlich nun die Konferenz-ID und wie Lync diese IDs generiert und speichert. Schaut man sich die Meeting-URL an, dann kann man darauf schon den Benutzernamen erahnen.

Aber dieser ist nicht immer der "Userpart" einer SIP-Adresse, denn eine Lync Umgebung kann durchaus mehrere SIP-Domänen betreiben und ein Max.Mustermann@firma.tld und Max.Mustermann@firma2.tld haben sicher nicht den gleichen Meeting-Prefix. Auch die numerische Konferenz-ID, mit der sich jemand über die Zugangsnummern einwählen und mit der Konferenz verbinden kann, ist interessant.

Wenn eine Lync-Umgebung nicht nur aus einem Pool besteht, sondern mehrere Pools in unterschiedlichen Regionen vorhanden sind, dann hat zwar jeder Pool seine eigene "LyncWeb"-Adresse aber die zentralen "Meet" und "Dialin"-Adressen können von jedem Pool bedient werden, auch wenn die Konferenz nicht auf dem erreichten Pool laufen. Hier muss Lync also einen Kniff verwenden, um zu einer URL den richtigen "Home-Pool" zu finden, damit dort die Konferenz gestartet werden kann.

ähnlich gilt dies für die Telefoneinwahl. Die Konfiguration der Einwahl-Nummern ist per Default erst einmal "global", sie kann aber eingeschränkt werden. Aber Lync muss so oder so damit umgehen können, dass jemand über ein beliebiges Gateway auf einem Pool landet und dort nach der Ansage die Konferenz-ID eingibt. Damit stellt sich auch hier die Frage, wie Lync den Anruf samt Audiodaten dann zum Pool weiter vermittelt, der diese Konferenz hosten wird.

Die Information über die Konferenz-IDs und Konferenznummern werden nicht durch die gesamte Lync Umgebung repliziert. Welchem Benutzer welche Konferenznummern zugeordnet sind, ist nur in der lokalen Datenbank pro Pool und auf einem eventuell vorhandenen per Pairing verbundenen Pool vorhanden. Ohne nun genau auf den Algorithmus einzugehen ist in der Adresse auch die Nummer des Konferenzverzeichnisses hinterlegt. Es gibt pro Pool per Default auch immer nur genau ein Konferenzverzeichnis. Sie können sich diese mit Get-CSConferenceDirectory anzeigen lassen.

Stellen Sie sich vereinfacht mal vor, dass die Nummer einfach ein vielfaches der Anzahl der Konferenzverzeichnisse wäre und Sie dann die Nummer nach der Erkennung einfach durch die Zahl der Konferenzverzeichnisse teilen. Der "Rest"  (Modulo) wäre dann immer eine Zahl zwischen 0 und (Anzahl Konferenzverzeichnisse)-1. Ganz so einfach ist es natürlich nicht da nicht nur das Konferenzverzeichniss, sondern eben auch die entsprechende Konferenz in dem Konferenzverzeichniss bestimmt werden muss.

Nun können Sie sich aber auch vorstellen, dass die Länge der Konferenz ID auch von der "Größe" ihrer Umgebung abhängig ist. Je mehr Anwender in Lync aktiviert sind und je mehr Konferenzverzeichnisse vorhanden sind, desto größer muss der Pool der Nummern sein. Ergo wird die nummer länger. Indirekt können Sie also aus einer Einladung in eine Lync Konferenz erahnen, wie groß die dahinter stehende Infrastruktur sein dürfte. ähnliches gilt natürlich auch für den letzten Teil der Meeting-URLs.

Auf der anderen Seite bedeutet das natürlich auch, dass alle Meetings ungültig werden, wenn das dazugehörige Konferenzverzeichnis "unsauber" gelöscht wird. Achten Sie bei der Migration und Deinstallation von Pools also unbedingt darauf, dass die Konferenzverzeichnisse migriert werden.

Sicherheit bei Konferenzen

Nun könnten sie natürlich sagen, dass jemand mit einer Flatrate bei der Telefonie und einem Wählprogramm einfach mal versuchen könnte, in eine Konferenz einzusteigen die gerade läuft oder eine anstehende Konferenz starten und dann ihre Umgebung als kostenfreier Konferenzhost genutzt wird oder Daten abfließen. Dieses Risiko ist gar nicht mal unrealistisch aber ist keine Besonderheit von Lync, sondern betrifft jeden Dienst, der per DTMF und Nummern eine Authentifizierung erlaubt. Seit dem Wissen um die Möglichkeiten von Geheimdiensten ist es geradezu als sicher anzunehmen, dass beim Mitschnitt von Telefonaten auf jeden Fall auf DTMF "gelauscht" wird.

In Anbetracht, wie oft DTMF als PIN-Eingabe z.B. für Anrufbeantworter oder Exchange UM und auch bei Lync Telefonen genutzt wird, muss man sich wirklich überlegen, ob ein Telefon für solche Dienste ausreichend sicher ist. Auf jeden Fall sollte ihre ExchangeUM-PIN und auch Lync-Pin nichts mit ihrer EC-Karte, Kreditkarte oder Zahlenschluss an Türen zu tun haben.

Das Risiko bei Lync Konferenzen sehe ich aber eher bei der Einrichtung eines "Public Rooms". Jeder Benutzer, der das erste Mal ein Meeting in Outlook startet, bekommt eine Konferenz-PIN und Konferenz-ID, die "persistent" ist. Das ist quasi ihr persönlicher Besprechungsraum, den sie immer wieder starten können. Das Risiko dabei ist, dass sie vielleicht andere Personen über eine Termineinladung diese Zugangsdaten mitgeteilt haben und diese ein paar Tage später einfach mal "schauen", ob der Link immer noch funktioniert. Wenn Sie in der Zeit dann gerade ein Meeting abhalten, dann wäre der externe Teilnehmer auch wieder drin. In der Hektik eines Meetings könnte es auch passieren, dass Sie Personen in der Lobby irrtümlich zulassen, wenn Sie eine Lobby (ab Lync 2013) überhaupt aktiviert haben. Diese Lücke können Sie auf zwei Arten schließen.

  • Der Benutzer verzichtet auf "Public Rooms"
    öffnen Sie dazu ein Meeting und passen Sie die Meeting-Optionen an. Per Default ist der "unsichere" dedizierter Besprechungsort eingestellt

    Vergessen Sie danach die Einstellungen nicht zu speichern, damit sie nicht nur einmalig für dieses Meeting sondern als Default hinterlegt werden. Ab dem Moment bekommt jedes Meeting eine neue ID
  • Zentrale Steuerung
    Wenn Sie die Entscheidung nicht mit Anwender überlassen wollen, dann können Sie auch auf dem Server über die Lync Clientpolicies entsprechende Vorgaben einstellen. In dem Fall ist Es die MeetingConfiguration, welche Sie "global", pro Lync Topology Site oder pro Service zuweisen können. Über den Parameter "AssignedConferenceTypeByDefault $false" steuern sie, dass der Default nun private Meetings sind. Die Einstellung "-EnableAssignedConferenceType $false" blockiert die Möglichkeit, dass Anwender "publicMeetings" anlegen können. Die passende Zeile für einen "sichereren Meetingbetrieb" wäre also:

Set-CsMeetingConfiguration `
   -identity global `
   -AssignedConferenceTypeByDefault $false `
   -EnableAssignedConferenceType $false

Wenn nun bei jedem Meeting eine neue ID generiert wird, dann ist die Wahrscheinlichkeit gering, dass jemand die ID verrät. Selbst bei Net at Work mit einem Pool und <100 Benutzer ist die Konferenz ID schon 6-stellig. Da gibt es sicher andere einfacherer Wege an Informationen zu kommen.

Ein Anwender kann aber auch über die DialIn-URL die Adresse für den persönlichen Besprechungsraum anzeigen und natürlich ändern.

Die wenigsten Anwender werden aber diesen Zugang können und geschweige denn nutzen. Wer also "sicherer" sein will, sollte die persönlichen (Public) Konferenzen einfach serverseitig deaktivieren.

Alterung

Dennoch bleibt dann die Frage, wie lange denn Lync diese IDs vorhält. Sie werden ja in der Datenbank gespeichert und wenn Sie die obige Policy angewendet haben, ist sie nach dem Ende des Meetings nicht mehr erforderlich. Lync hat tatsächlich einen Aufräumprozess, der im Hintergrund solche Einträge aus der Datenbank entfernt. Allerdings passiert das nicht sofort, denn sonst könnten Sie selbst ja nicht mehr nach dem Ende eines Meetings noch einmal in den virtuellen Konferenzraum zurück und z.B. Inhalte zu exportieren. Folgende Alterungsintervalle sind per Default konfiguriert:

Meetingart Verfallszeit

Einmalbesprechung

14 Tage nach dem Ende des Meetings

Wiederkehrendes Meeting mit Endezeitpunkt

14 Tage nach dem Ende des letzten geplanten Meetings 

Wiederkehrendes Meeting ohne Endetermin

6 Monate nach der letzten Nutzung

Adhoc-Meeting (IM/Audio/Video)

8 Stunden

So lange kann ein anonymer Benutzer im Meeting bleiben, wenn kein authentifizierter Anwender mehr teilnimmt.

90 Minuten
änderbar über Set-CsUserServicesConfiguration -AnonymousUserGracePeriod

Maximale Dauer eines Meetings

1 Tag
änderbar über Set-CsUserServicesConfiguration -DeactivationGracePeriod

Maximale Anzahl der Meetings, die eine Person planen kann

1000 
änderbar über Set-CsUserServicesConfiguration -MaxScheduledMeetingsPerOrganizer

Nur einen Teil der Werte können Sie über die PowerShell anpassen. Die meisten anderen Werte sind entweder fest hinterlegt oder deren Anpassung nicht dokumentiert. Ich bin sicher, dass sich jeder Datei z.B. in einer "%appname%.config als XML-Wert auch anpassen lässt. Allerdings habe ich bislang keinen Grund daran gesehen, daran etwas zu ändern.

Update nach Migration

Normalerweise bleibt eine Meeting-ID statisch. Allerdings ist eine Meeting-ID mit dem Pool verbunden. Wenn Sie also Benutzer von einem Pool zu einem neuen Pool verschieben, dann ändert sich die Meeting-ID

Dieser Fall ist z.B. bei einer Migration von OnPremise in die Cloud oder bei einer Migration von Lync 2013 auf SkypefB zu einem neuen Pool weil auch ein Update des Betriebssystems erfolgen soll.

Der Anwender müsste dann seine geplanten Konferenzen noch einmal aktualisieren. Das macht Outlook alleine, wenn der Anwender das Meeting öffnet und aktualisiert. Nun kann man das natürlich nicht von Anwender erwarten. Daher gibt es ein Tool von Microsoft, welches dies automatisiert. Allerdings kann dies nur vom Anwender selbst gestartet werden und die SIP-Adresse und SMTP-Adresse muss übereinstimmen.

Meeting Update Tool for Skype for Business and Lync
https://support.office.com/en-us/article/Meeting-Update-Tool-for-Skype-for-Business-and-Lync-2b525fe6-ed0f-4331-b533-c31546fcf4d4

Der Anwender muss das Tool selbst starten, damit es mit dessen Berechtigungen sowohl auf dem Exchange Server nach den Meetings suchen kann und diese dann aktualisiert versendet. Alle Teilnehmer bekommen natürlich auch ein Meeting Update mit der neuen URL, damit diese daran teilnehmen können.

Interner Aufbau

Die Konferenz-ID ist je nach Größe der Umgebung (Anzahl der User, Anzahl der Pools) unterschiedlich lang. Schließlich muss sie ausreichend "eindeutig" und sollte leicht zu übermitteln sein. Microsoft hat das Format offen gelegt:

<housekeeping digit (1 digit)><conference directory (usually 1-2 digits)><conference number (variable number of digits><check digit (1 digit)> 

Die ID besteht also aus einer führenden Stelle gefolgt von der Nummer des Konferenzverzeichnisses, einer variablen Anzahl von Ziffern zur Identifikation der Konferenz und eine Prüfziffer.

Weitere Links