LyncWeb Services

Für Exchange Administratoren ist es nicht wirklich neu, wenn Server verschiedene Funktionen per HTTP bzw. HTTPS bereit stellen. Autodiscover ist sicher der erste solche Service, mit denen Exchange 2007/2010 Einsteiger konfrontiert werden. Und Outlok2007/2010 nutzen mit Exchange 2007/2010 auch noch Exchange Web Services, OAB-Downloads etc., die alle per HTTPS veröffentlicht werden wollen.

Auch Lync nutzt dieses Verfahren, um verschiedene Dienste für interne und externe Clients bereit zu stellen. Anders als Outlook, welches über "autodiscover.maildomain.de" den ersten Zugang findet, um dann per XML-Antwort die weiteren URLs zu erhalten, nutzt der Lync Communicator hierzu natürlich SIP. Über eine bestehende SIP-Verbindung bekommt der Client die URL für die Lync Webservices.

Topology Builder

Den Namen der einen Lync-Webservice-URL müssen Sie im Topologie Builder konfigurieren. Es gibt je StandardServer bzw. je Pool eine eigene URL, die hinter "External Web Services" konfiguriert werden kann. In dem Beispiel hier ist "lyncweb.domain.de" als Adresse gewählt.

Sie sehen hier auch, dass Lync zwischen den internen und externen Webservices unterscheidet und da diese auf dem gleichen Server laufen, unterschiedliche Ports dafür verwendet. kommt ein Client von Intern, dann nimmt er sich den Poolnamen oder Namen des Standard Servers um auf die Dienste zuzugreifen.

Kommt der Client aus dem Internet, dann nimmt er den konfigurierten externen Namen. Hier spricht der Client aber auch Port 443 an, d.h. wer einen externen Zugriff benötigt, sollte eine passende Firewall haben, die Zugriff von extern auf den Port 443 nach intern auf 4443 (oder einen anderen konfigurierten Port) umleitet. Idealerweise ist dies ein HTTP-Reverse Proxy, wie er schon für die Veröffentlichung von OWA oft zum Einsatz kommt. Der Server, auf dem der Client "auftrifft", muss natürlich ein gültiges Zertifikat für diesen Namen vorweisen können.

Wer einen Enterprise Pool betreibt, muss sich auch über die Lastverteilung der Zugriffe auf die Frontendserver des Pools Gedanken machen. Hier ist ein Loadbalancer erforderlich.

IIS Konfiguration

Ausgehend von den Einstellungen in der Topologie richtet das Lync Setup auf dem jeweiligen Server die virtuellen Verzeichnisse im IIS ein. Die Standardwebseite wird dabei nicht entfernt aber einfach gestoppt. Zusätzlich gibt es die beiden Webseiten

  • Lync Server Internal Web Site
    Diese nimmt Verbindungen auf Port 80/443 von internen Clients an und sollte so nicht aus dem Internet erreichbar sein.
  • Lync Server External Web Site
    Diese eigene IIS-Webseite ist für die Veröffentlichung in das Internet vorgesehen. Allerdings lauscht diese erst mal nur auf Port 8080 und 4443. Sie müssen also bei der Veröffentlichung von Extern die Ports über einen ReverseProxy oder NAT umdrehen. Auch wenn die Separierung in eine Webseite einen besseren Schutz bietet, so sollten Sie dennoch besser einen ReverseProxy zur Publizierung einsetzen. Wenn sie sogar einen Lync-Pool betreiben, dann müssen Sie sowieso eine Verteilung der Zugriffe vornehmen.

Genau genommen hätte Microsoft die Funktion der beiden Webseiten auch einfach in einer Webseite verschmelzen können und dem Administrator einfach ins Pflichtenheft schreiben, dass er die Dienste "sicher" veröffentlichen muss. Nun kenne wir alle die Begeisterung, Dokumentationen zu lesen. So zwingt Microsoft sicher den ein oder anderen Admin zum Nachdenken, wie er die Dienste veröffentlichen kann.

Es ist übrigens durchaus möglich, die Ports im Topology Builder zu ändern. genau könnten Sie den Server mit zwei Netzwerkkarten versehen und die Webseite auf die IP-Adresse binden, von denen eine Karte "nach außen" verweist. Trotzdem sollten Sie sich natürlich über die Absicherung ihres Servers Gedanken machen und die Sparsamkeit nicht übertreiben.

Schauen wir uns die virtuellen Verzeichnisse mal genauer an, dann sehen Sie im linken baumdiagramm aufgeklappt die Struktur der "External Website und rechts die Details der "Internal Website".

Durch diese Gegenüberstellung können Sie auch schnell erkennen, welche virtuellen Verzeichnisse nur intern vorhanden sind. So fehlt extern natürlich das "CSCP-Verzeichnis" und "Location Information". Auch die "OCSPowerShell" ist nur von intern zu erreichen.

Die Web Dienste im Einzelnen

Auch wenn in den hier mit aufgezeigten TMG-Traces als User "anonymous" steht, so bedeutet dies nicht, dass die URLs auch für jeden erreichbar sind. Lync nutzt intern die Authentifizierung mit Zertifikaten, die aber vom TMG nicht gesehen wird.

Virtuelles Verzeichnis seit Lync
Version		 Web Funktion

ABS

2010RTM

extern
intern

Über diese URL wird das Adressbuch bereit gestellt, welches sich dann die Clients herunterladen. Auch Photos werden so bereit gestellt.

CertProv

2010RTM

extern
intern

Dieser Webservice stellt nach einer Anmeldung die Zertifikate für den Client bereit. In der Folge kann sich der Client dann direkt mit dem "Zertifikat" anmelden.

CollabContent

2010RTM

extern
intern

 

cscp

2010RTM

intern

Das Communication Server Control Panel stellt die bekannte Administrationsoberfläche basierend auf Silverlight bereit und sollte nicht ohne Not von "extern" erreichbar sein.

DataColabWeb

2010RTM

Extern
Intern

WebService für Data Collaboration, z.B. Um Powerpoint bei Lync 2013 hoch zu laden.

Dialin

2010RTM

extern
intern

Für den Betrieb der SimpleURL ist "dialin" erforderlich. Sie sehen, dass dies keine eigene Webseite ist. Bei der Veröffentlichung sollten Sie also darauf achten, dass der gleiche Listener im Zertifikatnamen auch die Hostnamen der SimpleURLs enthält.
Über diese URL können anonyme Anwender die Einwahlrufnummern in Erfahrung bringen. Über einen Link können sich Anwender auch anmelden und ihre Telefon-PIN ändern.

Fonts

2010RTM

extern
intern

 

GroupExpansion

2010RTM

extern
intern

Dieser Webservice löst die Gruppenmitgliedschaften auf. Immer wenn Sie also eine Gruppe addresieren  oder in der Karteikarte sich die Mitglieder einer Gruppe oder Mitgliedschaften eines Benutzers anzeigen lassen, greift der Lync Communicator hierauf zu.

HybridConfig
(Lync 2013)

2013

extern
intern

 

LMStaticData

2010RTM

extern
intern

LiveMeeting Static Data ?

LocationInformation

2010RTM

intern

Über diesen Webservice kann ein Client, sofern er intern ist, seinen Standort ermitteln und dann im SIP-Paket auch weiter melden. Diese Funktion ist in den USA für die E-911 Nutzung erforderlich. Aber auch sonst kann diese Information z.B.: den "Ort" im Communicator automatisch aktualisieren.

lwa

2013RTM

 

Lync 2013 WebApp

mcx

2010 CU4

Extern
Intern

Das Verzeichnis MCX wird von den mobilen Clients genutzt, die per HTTPS so ihre Daten abrufen.

meet

2010RTM

extern
intern

Für den Betrieb der SimpleURL ist "meet" erforderlich. Sie sehen, dass dies keine eigene Webseite ist. Bei der Veröffentlichung sollten Sie also darauf achten, dass der gleiche Listener im Zertifikatnamen auch die Hostnamen der SimpleURLs enthält.

MeetingContent

2010RTM

extern
intern

 

MeetingFiles

2010RTM

extern
intern

 

PassiveAuth

2013RTM

 

 

PersistentChat

2013RTM

 

 

OCSPowerShell

2010RTM

intern

Hier zeigt sich noch der Name "OCS", der Vorgänge von Lync. Über den Weg können Sie Lync "remote" verwalten. Dieses Verzeichnis sollte normal nicht extern erreichbar sein.

Reach

2010RTM

extern
intern

 

RequesthanderExt

2010RTM

extern
intern

 

RgsClients

2010RTM

extern
intern

Webservice um den Status der Responsegroup zu erkennen.

RgsConfig

2010RTM

intern

Hier hinter verbirgt sich die Webseite, mit der Sie die Response Groups verwalten können. Zwar hat Lync einige Einstellungen in die GUI gebracht, aber die Workflows sind weiterhin eine Webseite

Scheduler

2013RTM

Extern
Intern

Web Scheduler

UCWA

2013RTM

Extern
Intern

Unified Communication Web API

Webtickets

2010RTM

extern
intern

Auch die Webdienste nutzen nur kurzfristig eine Anmeldung mit Benutzername und Kennwort bzw. Zertifikat. Dieser Webservice stellt für die Anwender kurzfristige "Tickets" aus, die in nachfolgenden Anfragen im HTTP-Header mit übertragen werden und damit eine weitere immer wiederholte Anmeldung vermeiden. Quasi "Sessionkeys".

EWS

Exchange

Extern
Intern

Die Bereitstellung von Exchange Webservices ist keine originäre Lync Aufgabe sondern Exchange. Aber der Lync Client nutzt natürlich EWS und wenn Sie einen Trace auf den Client machen, dann sehen Sie auch solche Anfragen

Hier nicht

Port 80 ?

Nun könnten Sie ja sagen, dass alles per SSL abgesichert wird und damit der Port 80 oder 8080 gar nicht erforderlich wäre. Dem ist aber nicht so, wie ein schneller Blick in die IISLogs einer aktiven Lync-Installation zeigt:

POST /CertProv/CertProvisioningService.svc/anon - 80 - 10.1.1.3 OCPhone/4.0.7576.0+(Microsoft+Lync+2010+Phone+Edition)
GET /RequestHandler/Files/UCPhone/AASTRA/6725ip/A/ENU/4.0.7577.250/CPE/CPE.cat - 80 - 10.1.1.3 Microsoft+UCPhone+Device+(lcs_se_w14_main:824457)
GET /lyncweb - 80 - 10.1.1.2 Mozilla/4.0+(compatible;+MSIE+7.0) 
OPTIONS /Ansagen/03_Warteschleife_mono.wma - 80 - 10.1.1.2 Microsoft-WebDAV-MiniRedir/6.1.7601 200 0 0 5
GET /cscp - 80 - 10.1.1.2 Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+WOW64;+Trident/5.0) 403 4 5 215

Mal abgesehen von der Anfrage nach "Ansagen", was ein Zugriff eines Clients auf eine in den Gruppenrichtlinien hinterlegten WMA-Datei sind sind die beiden ersten Request ein wichtiger Aspekt. Die Lync Phones laden über HTTP bei der ersten Verbindung die Liste der Stammzertifikate herunter. Das ist insbesondere dann wichtig, wenn Sie eine interne Zertifizierungsstelle betreiben und die internen Zertifikate entsprechend "privat" sind.

Und dann sieht man hier auch noch, dass ein Aastra-Telefon auch ohne HTTPS eine Anfrage nach der Firmware-Version stellt.

Eine Änderung dieser Konfiguration ist immer nur temporär, da ein "Publish Topology" mit einem "Enable-CSComputer" die aus Sicht von Lync richtigen Einstellungen wieder einträgt. Vergessen Sie es also, diesen IIS zu "verbessern" oder andere Aufgaben bereit stellen zu lassen.

Es ist schon komisch. Früher gab es auch schon PCs im Umfeld von Telefonanlagen, primär für Call Control, Adressbücher etc. Und ich habe viele Umgebungen gesehen, wo diese "TK-Systeme" nicht gesichert waren, d.h. kein Virenscanner, keine Updates und nicht mal die Standardkennworte wurden geändert. Und diese Systeme standen natürlich im LAN.
Nun kommt Lync und es gibt nicht wenige Administratoren, die nun auch die Server "härten" wollen und sich daran stören, dass da ein IIS auf den Standardport hört.
Ein IIS ist ein Webserver und Webdienste werden von Clients genutzt. Sicherheit erreicht man nicht durch die Verwendung von "nicht Standard Ports" sondern durch sichere Kennworte, passende Firewalls und Intrusion Detection Systemen. Windows 2008 ist von Hause aus deutlich besser abgesichert als alte Windows Server und schon der Ansatz zwei eigene virtuelle Webseiten aufzubauen um allen Diensten den Wind aus den Segeln zu nehmen, die sich ungefragt in die "Default Web Site" installieren, sollte ihnen schon zeigen, dass Lync einen hohen Anspruch an die Lösung hat.

SSL und Offloading

Da der Einsatz von NLB auf Lync Frontend Servern nicht sinnvoll möglich ist und Microsoft für die Veröffentlichung der Webdienste eines Enterprise Pools sowieso LoadBalancer vorschreibt, müssen Sie diese Dienste über gesonderte Hardware "veröffentlichen".

Die Webdienste nutzen aber SSL und einige Loadbalancer bieten eine SSL-Acceleration oder SSL-Offloading an. Dies kann genutzt werden. Allerdings ist auf dem Lync Webdiensten eine Umleitung von Zugriffen auf Port 80 nach 443 eingerichtet. Das bedeutet aber auch, dass ein Loadbalancer nicht wirklich mit SSL-Offloading arbeiten kann. Er kann natürlich die SSL-Verbindung aufbrechen, um z.B. Anhand von Cookies die Sessions zu erkennen aber er muss auch zum Backend (also Lync Server) wieder mit SSL weiter arbeiten, da ein umsetzen der Zugriffe von Extern Port 443 auf intern 80 einen "Redirect" auslösen würde.

Versuchen Sie nicht diese SSL-Umleitung im IIS außer Kraft zu setzen. Zum einen würde der LyncPBA dies anmeckern. Spätestens bei der nächten Änderung der Topologie würden diese Einstellungen aber wieder zurück gestellt.

Kerberos

Wer nur einen einzelnen Standard Server mit einer überschaubaren Anzahl an Anwendern betreibt, muss sich um die Anmeldung per Kerberos keine größeren Gedanken machen. Der Zugriff auf die Webseite erfolgt intern normalerweise über den Poolnamen, der zum Servernamen identisch ist und so können die Clients auch den SPN finden.

Wer aber einen Frontendpool mit einem Poolnamen betreibt, muss wissen dass sich hier die Clients erst mal nur mit NTLM anmelden können, was auf anderer Seite wieder Probleme mit sich bringt (Ressourcenbedarf auf DCs zur Überprüfung der Anmeldedaten). Daher kann es für größere Installationen durchaus relevant sein, die Anmeldung per Kerberos auf den Webservices zu aktivieren. Dies gilt um so mehr, wenn eine Firewall eine Preauthentication macht und sie mit Constraint Delegation arbeiten können.

Die Konfiguration ist wie bei Exchange und anderen Webdiensten vergleichbar. Die Anwendungen auf den verschiedenen Servern müssen mit einem Dienstkonto laufen, zu welchem der passende SPN im Active Directory hinterlegt wird

Internet und Reverse Proxy

Die externen Lync Webdienste sind auf dem Lync Server über 8080/4443 erreichbar. Das ist natürlich nicht der Port, unter dem externe Clients den Dienst erwarten. Daher ist eine Umsetzung von 80/443 auf 8080/4443 erforderlich. In sehr kleinen Umgebungen wird das vielleicht ein NAT-Router machen. Die meisten Firmen veröffentlichen aber ihre Webservices und Webseiten in so einem Fall über einen Reverse Proxy.

Die Lync Web Dienste müssen immer dann aus dem Internet erreichbar sein, wenn Clients oder Meeting-Teilnehmer aus dem Internet ohne VPN mit ihrer Umgebung kommunizieren müssen. Das ist fast immer der Fall, da Meetings mit Browsern oder mobile Clients heute zum Standard gehören. Da jeder Anwender aber immer mit "seinem HomeServer" kommuniziert, muss natürlich auch jeder Lync Pool, Standard-Server und Director-Server mit einem eigenen externen DNS-Namen versehen und im Internet veröffentlicht werden.

We recommend that you configure your HTTP reverse proxy to publish all Web Services in all pools. Publishing https:// ExternalFQDN/* publishes all IIS virtual directories für a pool. You need one publishing rule für each Standard Edition server, Front End pool, or Director or Director pool in your organization. In addition, you need to publish the simple URLs. If the organization has a Director or Director pool, the HTTP reverse proxy listens für HTTP/HTTPS requests to the simple URLs and proxies them to the external Web Services virtual directory on the Director or Director pool. If you have not deployed a Director, you need to designate one pool to handle requests to the simple URLs. (If this is not the User’s home pool, it will redirect them onward to the Web Services on the User’s home pool). The simple URLs can be handled by a dedicated web publishing rule, or you can add it to the public names of the web publishing rule für the Director. You also need to publish the external Autodiscover Service URL.
Quelle: Setting up reverse proxy servers für Lync Server 2013 https://technet.microsoft.com/en-us/library/gg398069.aspx

Leider hat Microsoft sich dagegen entschieden, den TMG2010 weiter zu betreiben, so dass andere ReverseProxy-Systeme hier zum Einsatz kommen. Hierbei sind einige Dinge zu beachten, von denen es eigentlich keine Abstufung nach Wichtigkeit gibt

  • Timeout
    Der Einsatz von mobilen Clients macht es erforderlich, dass TCP-Sessions nicht nach vielleicht 120 Sekunden schon abgebrochen werden, sondern deutlich länger bestehen bleiben. Wenn ein Proxy oder eine Firewall die Verbindung vorschnell kappt, können Clients mit Fehlern reagieren, z.B. dass der mobile Lync Client neu gestartet werden muss
  • Authentifizierung
    der Zugang zu Lync Web erfolgt entweder anonym (z.B. DialIn/Meet) oder durch eine Software. Damit fallen formularbasierte Anmeldungen oder Multi-Faktor Anmeldungen mit Einmaltokens raus. Der Zugang darf keine "Preauthentication" erwarten sondern muss die Authentication Header durchreichen
  • Offloading und Verteilung
    Wenn als Backend mehrere Lync Server die Dienste bereitstellen, dann wird oft der Reverse Proxy auch zum Verteilen der Anfragen genutzt. In dem Falle muss der Reverse Proxy die SSL-Verbindung aufbrechen um anhand der Anmeldedaten , Cookies o.ä. den Client eindeutig zu identifizieren und das Paket zum gleichen Backend weiterleiten zu können

Die entsprechende Konfiguration ist je nach Reverse Proxy individuell. Viele Firmen nutzen interessanterweise Apache als Reverse Proxy. Hier ein Ausschnitt einer Konfiguration:

ProxyRequests Off
<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>

ProxyReceiveBufferSize 4096
ProxyPass / https://lync.domain.com:4443/ retry=1 acquire=3000 timeout=600 keepalive=On
ProxyPassReverse / https://lync.domain.com:4443/
ProxyPreserveHost On

Hier ist zu sehen, dass die Anfragen auf den Port 4443 intern weiter gegeben werden und der Timeout 600 Sekunden beträgt.

Reverse Proxy und Deep Inspection (Sophos)

Gerade die "Intelligenz" von solchen Reverse Proxy Systemen kann auch zu sehr schwer zu findenden Effekten kommen. Bei Net at Work hatten wir den Fall, dass genau eine Person von einem Windows 8 Phone nicht den Lync Mobile Client nutzen konnte. Interessanterweise konnten anderen Personen problemlos arbeiten. Selbst auf einem anderen Telefon konnte der Anwender wieder arbeiten, so dass wir zuerst das Telefon im Verdacht hatten. Der Fehler äußerte sich wie folgt.

Mit dem CLSLogging erscheint ein

UCWA,Helper.ValidateEtagPrecondition:helper.cs(1386)) Failing operation because precondition was not met.
   currentEtag: 1123784134, expectedEtag: 1123784134-gzip

Auf dem Smartphone kam folgender Fehler

Als wir dann aber auf der Firewall etwas ausführlicher die Logs inspiziert haben, konnten wie sehen, dass die Firewall die Requests als SQL-Injection-Angriff gewertet hat

Allerdings wurden ganz verschiedene Muster getriggert. Erst also wir dann auf diesem Service die SQL-Prüfungen entfernt haben, war auch die Problem bei dem Client gelöst.

Fehlersuche

Es handelt sich ganz einfach um einen IIS. Insofern ist die erste Anlaufstelle natürlich das IISLog, welches jeden Request  beinhaltet. Hier sehen Sie meist die Clients, ihre Anfragen und auch den Benutzer, zumindest sofern er sich erfolgreich anmelden konnte.

Sie können aber auch mit einem Browser den ein oder anderen Test einfach durchführen. Dabei gibt es drei Stellen zum Testen

  • Intern gegen die interne Webseite
    Das muss problemlos funktionieren, damit interne Clients arbeiten
  • Intern gegen die Externe Webseite
    Diese Anfragen werden so normal nicht benötigt. Sie sind aber ein test um die Erreichbarkeit der "external Websites" zu überprüfen und hier Probleme zu erkennen.
    Hinweis: Einige URLs machen einen Redirekt auf den Hostnamen der ExternalURL. Der Trace zeigt aber schon, dass eine Verbindung möglich war
  • Extern gegen die Externe Webseite
    Dies ist dann von extern auf jede Lync Installation, zu der man die ExternalURLs kennt, möglich. Sie hilft bei der Fehlersuche beim ReverseProxy und Firewall

Folgende URLs nutze ich gerne, wobei diese natürlich abhängig von ihrem Namenskonzept für die SimpleURL zu sehen sind.

Host URL Ergebnis Status

https://<lyncweb>
http://<lyncweb>

/dialin

Hier sollte der Lync Server ohne Anmeldung die Konferenznummern anzeigen. Beim Zugriff

 

https://<lyncweb>
http://<lyncweb>

/Dialin/Conference.aspx

Beim Zugriff von extern leitet Lync auf eine andere Seite um
https://<lyncweb>/Dialin/Conference.aspx

 

https://<lyncweb>
http://<lyncweb>

webticket/webticketservice.svc/mex

Liefert die Webservice-Definition für den WebTicketTest

 

Bei Lync 2013 sind auch die Office Web Components für Zugriffe relevant

Weitere Links