Lync Hosting: Edge und Clients

Beim klassischen Hosting gibt es ja keine "internen Clients". Alle Anwender melden sich immer von extern über einen Edge-Server beim Hosting System an. Aber auch bei einer internen Anmeldung finden die Clients den Server über DNS-Einträge.

Suchen, Finden und prüfen

Ein Lync Clients weiß Anfangs nur die SIP-Adresse und eventuell das Kennwort eines Anwenders. Wenn man nicht statisch einen Lync-Server hinterlegt hat, dann startet der Client eine DNS-Suche. (Siehe auch UC und DNS).

Er sucht also nach SRV-Records mit den folgenden Namen:

_sipinternaltls._tcp.netatwork.de
_sipinternal._tcp.netatwork.de
_sip._tls.netatwork.de
_sip._tcp.netatwork.de
_sip._udp.netatwork.de

Sobald eine Abfrage erfolgreich ist, kennt der Client auch den Zielserver und den Port. Diese SRV-Records müssen natürlich auf einen Hostnamen verweisen und der Lync Client erwartet, dass die Domäne des Hostnamens auch in der SIP-Domäne ist, also etwas so:

_sipinternaltls._tcp.netatwork.de  SRV 10 10 5060 lync01.netatwork.de

Der Client prüft natürlich bei einem Aufbau per TLS, ob das Zertifikat vertrauenswürdig ist und der Zielname auch im Zertifikat enthalten ist. Und da ist er sehr pingelig. Folgendes funktioniert nicht:

_sipinternaltls._tcp.<sipdomain1>  SRV 10 10 5060 lync01.<ad-domain>

_sipinternaltls._tcp.<sipdomain2>  SRV 10 10 5060 lync01.<sipdomain2>
              lync01.<sipdomain2> CNAME lync01.<ad-domain>

Wenn der Name nicht im Zertifikat enthalten ist, dann "warnt" der Client den Anwender, dass er bei einem "falschen" Server ist.

Wird keine Änderung vorgenommen, dann ist diese Lösung natürlich unschön, wenn mehrere Domains verwendet werden. Schließlich müssen sie für jede SIP-Domain nicht nur den SRV-Record sondern auch einen A-Record in der DNS-Domäne anlegen. Was aber viel schlimmer ist, ist der erforderliche Eintrag im Zertifikat.

Lösungen für die Client Warnung

Es gibt mehrere Ansätze auch ohne weitere Namen im SAN-Zertifikat den Client "verbinden" zu lassen.

Lösungsweg Beschreibung

Manuelle Konfiguration

Wird der Name des Lync Servers einfach fest vorgegeben, dann kommt auch keine Zertifikatswarnung. für Windows Computer, die zudem noch Mitglieder einer Domäne sind, ist das sehr einfach per Gruppenrichtlinie machbar. Der Weg ist natürlich verbaut für andere Client.

Mobile Client benötigen diesen Eintrag aber nicht (Stichwort Lyncdiscover) und Telefone für Lync können zumindest im internen LAN per DHCP provisioniert werden. für den externen Einsatz geht es aber nicht. Hier funktionieren dann aber die Serien, die per USB mit dem PC verbunden werden (CX600, 6725ip etc.) und vom PC aus konfiguriert werden.

TrustModelData per GPO

Damit ersparen Sie sich z.B. die ganzen SAN-Einträge im Namen aber die Clients bekommen natürlich eine Rückfrage, dass der Zugriff auf einen anderen Server "umgeleitet" wurde. Der Anwender muss dann zustimmen.

Sie können dies nur verhindern, indem Sie den Provider lokal als "Trusted" addieren. Office 365 ist natürlich per Default schon vorhanden oder wird über den Office Signin Assistent eingetragen.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Policies\Microsoft\Office\15.0\Lync]
"TrustModelData"="netatwork.de"

[HKEY_CURRENT_User\Software\Microsoft\Communicator]
"TrustModelData"="lync.com, outlook.com, lync.glbdns.microsoft.com, microsoftonline.com"

Firmencomputer können per Gruppenrichtlinien entsprechend "vorbetankt" werden.

  • 2833618 "Lync cannot verify that the server is trusted für your sign-in address" message when a User tries to sign in to Lync 2013
  • 2531068 "Lync cannot verify that the server is trusted für your sign-in address" message when you sign in to Lync 2010 by authenticating to Lync Online
  • MSXFAQ.DE:Gruppenrichtlinien

Es könnte als ein Weg sein, ein vergleichbares Programmpaket an die Kunden abzugeben, welches erforderliche Mindestvoraussetzungen der Software prüft und so schon einen Teil von Telefonanrufen reduziert und die erforderlichen Konfigurationseinstellungen durchführt.

TrustModelData per Setup

Natürlich können Sie auch die Werte ganz klassisch per SETUP setzen. Ein Provider könnte z.B. den Lync Installer entsprechend anpassen. Hosting Provider haben ja z.B. den Zugriff auf eine Standalone Version des Lync Client und können ein eigenes Setup bauen.

Alternativ könnte ein Provider auch gleich einen "Login Assistenten" schreiben, der vielleicht noch ganz andere Einträge vornimmt, z.B. auch für Exchange Autodiscover, SharePoint, ein Icon in der Taskleiste zur Fehlersuche etc. Microsoft hat sowas ja auch.

Microsoft Online Services-Anmelde-Assistent für IT-Experten RTW
http://www.microsoft.com/de-de/download/details.aspx?id=28177

Hier noch ein paar Links zum Thema:

Wie macht es Microsoft mit Office 365 und Federation ?

Vor dem gleichen Problem steht natürlich auch das Office 365 Hosting von Microsoft. Wer allerdings schon einmal in die Lync Konfiguration geschaut hat, wird ein paar Einträge interessant finden: (Stand Mai 2014, Lync 2013) 

Windows Registry Editor Version 5.00

[HKEY_CURRENT_User\Software\Microsoft\Communicator]
"TrustModelData"="lync.com, outlook.com, lync.glbdns.microsoft.com, microsoftonline.com"

Microsoft definiert in Lync per Default einige Einträge, die z.B. einen Edge-Server mit den Namen ".lync.com" als Vertrauenswürdig erscheinen lassen. Wenn ich dann meine Office 365 Umgebung per DNS abfrage, dann sehe ich da

_sip._tls.carius.onmicrosoft.com        SRV service location:
          priority       = 100
          weight         = 1
          port           = 443
          svr hostname   = sipdir.online.lync.com

_sipfederationtls._tcp.carius.onmicrosoft.com   SRV service location:
          priority       = 10
          weight         = 1
          port           = 5061
          svr hostname   = sipfed.online.lync.com

Wenn mein Client also "lync.com" vertraut, dann kann Office 365 als Provider sehr einfach mit seinem vorhandenen Zertifikat arbeiten.

Was machen dann andere ?

An der technischen Problematik lässt sich leider nicht ändern. Die Ausgangsvoraussetzungen sind für alle Hoster gleich, wenn man mal von Office 365 absieht, die sich schon "vorgeladen" haben. Sie können also nur

  • Den Benutzer bitten die Warnung zu bestätigen
    möglich aber eigentlich nicht "ratsam"
  • Im Zertifikat die Kunden-Domain addieren
    Das ist aber teuer, die Einträge im SAN-Feld sind beschränkt und der Beantragungsprozess nicht einfach. Wenn das Feld voll ist, müsste man weiter Edge-Server installieren.
  • Den Registry-Key auf dem Client setzen lassen
    z.B. durch die Verteilung eines Softwarepakets, welches vielleicht noch andere Einstellung optimiert. Das geht aber nur unter Windows aber nicht bei Tablets, Smartphones etc.

Und genau so sehe ich es, wenn ich mit Wissen einer SIP-Domain eines Hosting-Kunden mir das Zertifikat des Edge-Servers beim Provider anschaue. Eigentlich ein Trauerspiel.

Lösung durch SNI ?

Dabei gibt es auch für diese Problemstellung eventuell eine Lösung. Über die Funktion SNI-Zertifikate kann ein Client dem Server schon beim SSL-Handshake mitteilen, welchen Namen der Client anspricht. Diese Funktion unterstützt auch der Lync Client. NetMon zeigt das: 

Allerdings unterstützt aktuell der Lync Edge Server noch nicht diese Erweiterung. Er kann also noch nicht aus einem Pool von Client Zertifikaten dann ein passendes Zertifikat auswählen und zur weiteren verschlüsselten Verbindung mit dem Client nutzen.

Ich habe es noch nicht ausprobiert, aber vielleicht kann auch ein TLS-Proxy diese Lücke füllen, welcher die Verbindungen des Clients annimmt und dann weiter reicht.

Ich kann leider noch nicht sagen, ob diese Ansatz eine dauerhafte, stabile und realistische Alternative ist. Ich hoffe schon, dass Microsoft für den Betrieb mit vielen SIP-Domains oder für Provider eine Lösung schaffen wird.

Weitere Links