SimpleURL und WebServices

Änderungen an den URLs für SimpleURL und Webservices erfordern ein "Enable-CSComputer" auf allen betroffenen Frontend und Direktoren, damit die Daten in die IIS Metabase übernommen werden und passende Zertifikate angefordert werden können.

Als Anwender von Lync können Sie sehr einfach per Mail oder Kurzmitteilung ein Meeting aufbauen. Das gibt bei OCS mit Livemeeting auch schon, aber die URLs waren alles andere als "Lesbar" oder gar per Telefon zu übertragen. Hier ein Beispiel von OCS/Livemeeting:

Diese "URL" ist natürlich in keinster Weise "brauchbar" lesbar. In Lync sieht dies schon mal ganz anders aus, wie eine Einladung mit Lync z.B. zeigt:

Hier ist die URL nun viel einfacher "lesbar" und notfalls auch über Telefon oder andere Weg sicher zu übermitteln. Aber damit das funktioniert, muss der Lync-Administrator einige Einrichtungen vornehmen.

Achtung:
Wenn ein Anwender umbenannt wird (z.B. Heirat), dann werden die alten Meeting-URLs ungültig, d.h. der Anwender muss alle noch ausstehenden Meetings neu einladen.

Was braucht man dazu ?

Natürlich müssen Sie die Namen der URLs in der Lync Konfiguration hinterlegen. Aber für die Funktion ist es noch wichtiger, dass der Client über den Zugriff auf diese URL auch auf den Lync Webserver (also die Webseite auf dem Standard Server oder den Frontend-Pool) kommt. Dort läuft die entsprechende Anwendung, die dann passend zur kurzen freundlichen URL die eigentliche Sitzungsdaten an den Client ausliefern. für interne Zugriffe reicht ein passender DNS-Eintrag und das Zertifikat auf dem IIS. für externe Zugriffe muss natürlich der Webservice auch veröffentlicht werden.

Wenn Sie die URLs schon alle richtig im Topologybuilder eintragen, dann fordert der Zertifikatsassistent bei der Installation des Frontend Servers schon gleich die richtigen Namen an.

Betrachtungen zur "Sicherheit" müssen Sie nun natürlich selbst anstellen, aber ich würde den Lync-Server nicht einfach per Port 443 und NAT im Internet erreichbar machen. Ich ziehe da schon einen Reverse-Proxy mit SSL-Zertifikat vor, da es sich durchweg um HTTPS-Verkehr handelt, der durch so eine Applikation Firewall gerne inspiziert werden sollte.

SimpleURL Konfiguration in Lync

Microsoft hat für den Zugriff auf die "SimpleURLs" drei Modelle vorgesehen, von denen die eines auswählen und umsetzen sollten. Welches Modell das "passende" ist, hängt stark von ihren persönlichen Vorlieben und der Anzahl an unterstützten SIP-Domains ab. Daher sind unterschiedliche Schreibeweisen für die DIALIN, die MEET und die Webservice-Adresse möglich.

Beachten Sie, dass der Hostname der WebService Adresse des Pools nicht mit dem Hostnamen der SimpleURLs übereinstimmen darf. Sie benötigen also immer mindestens zwei oder sogar drei Namen, die mit einem Zertifikat abgesichert werden. Dank SAN-Zertifikate kann dies aber über eine IP-Adresse abgewickelt werden.

Modell URLs Beschreibung

1

https://meet.lyncme.de
https://dialin.lyncme.de
https://lyncweb.lyncme.de

Default nach Installation
Der Topologybuilder schlägt drei Hostnamen vor. Die ist ein Weg für mittlere Firmen oder wenn ihnen die Namen so gefallen. Viele Firmen werden aber lieber auf einen Namen(= ein kotenpflichtiger Eintrag im Zertifikat) sparen wollen.

2

https://join.lyncme.de/meet
https://join.lyncme.de/dialin
https://lyncweb.lyncme.de

Das ist mein Favorit, der zufällig auch von Microsoft selbst verwendet wird

Sie sparen sich damit schon mal einen Hostnamen im Zertifikat. Sparfüchse mit einem guten Reverse Proxy nutzen sogar bestehende Zertifikate und Webveröffentlichungen, da "/meet" und "/dialin" ja nur zwei virtuelle Verzeichnisse sind, die z.B. mit OWA nicht in Konflikt stehen. Die URL ist aber ein bisschen länger.

3

https://join.provider.de/domain/meet
https://join.provider.de/domain/dialin
https://lyncweb.provider.de

Dieses Modell ist wohl eher interessant für Provider und Hoster, die eine ganze Menge von SIP-Domains verwalten und möglichst über einen zentralen Zugang bereit stellen wollen.

So können viele weitere SIP-Domains voneinander getrennt und doch mit dem gleichen Zertifikat betrieben werden

Die Wahl der Hostnamen ist natürlich ihnen überlassen, wobei die Hostnamen für den Webservice und die SimpleURLs nicht gleich sein dürfen, obwohl sie doch auf den gleichen Webserver verweisen. Ein klassischer Fall für eine Veröffentlichung mit einem SAN-Zertifikat.

Die Einstellungen der "SimpleURL" sind für die komplette Lync global im Topology Builder vorzunehmen.

Webservice Konfiguration in Lync

Der Eintrag des externen Hostnamens der Webservices findet sich hingegen auf den Eigenschaften des Pools bzw. Standard Servers.

Hier ist auch gut zu sehen, dass Lync sehr wohl zwischen internen und externen Zugriffen unterscheidet und dazu einfach zwei unterschiedliche Ports verwendet. Interne Clients verbinden sich einfach auf 80/443 und landen auf dem internen Webservice. Externe Client können diese Webseite aber nicht erreichen, sondern müssen über eine Veröffentlichung auf die externe Seite kommen.

Die Webservices stellen z.B.: den Zugriff auf folgende Dienste bereit

  • Download von Konferenz-Inhalten
  • Auflösen von Gruppenmitgliedschaften (Group Expansion)
  • Download des Lync Adressbuchs
  • Zugriff auf den Lync Web App Client.
  • Zugriff auf die Webseite mit den Rufnummern zur Einwahl (dialin)
  • Zugriff auf die LIS Datenbank
  • Zugriff auf DeviceUpdate-Seite für Geräte
  • Download von Zertifikaten, z.B. für Endgeräte, Telefone etc

Wer auf dem Lync-Frontend/Standard-Server einmal im IIS-Manager schaut, erkennt die verschiedenen virtuellen Verzeichnisse, die hier von extern erreichbar sein sollen:

Sie sehen gut das ABS-Verzeichnis für Adressbücher, "GroupExpansion" für die Auflösung von Verteilergruppen und andere. Bei einem Blick auf die "Lync Server Internal Web Site" werden sie feststellen, dass es dort auch noch das Verzeichnis CSCP  (Communication Server Control Panel) gibt.

Aus dem Internet erreichbar machen ..

Um die Beschreibung einfach zu halten, nutzen ich das Namensmodell, bei dem nur zwei DNS-Namen erforderlich sind, d.h. die Dialin und Meet-URL mit einem Namen arbeiten.

Damit all das funktioniert, müssen die Daten natürlich "veröffentlicht" werden. Und wer in der Microsoft Welt zuhause ist, wird hier natürlich zuerst an den ISA/TMG-Server denken. der dazu auch perfekt geeignet ist. Kniffliger wird es, wenn Sie mehrere Frontend Server betreiben, da dann das DNS-Loadbalancing nicht greifen kann. Ein DNS-Eintrag auf "join.lyncme.de", der auf zwei Frontend-Server verweist, verhindert keine Fehler beim Ausfall eines Frontend. Hier sind also intern zusätzliche Load-Balancer gefragt. Wenn sie mehrere Reverse-Proxy-Server betreiben, muss auch hier der Zugriff von Extern mit Hilfsmitteln verteilt werden. Sicher kann man dazu auch das bordeigene NLB nutzen. Sie sollten aber die Einschränkungen dazu können. (Siehe auch NLB)

Letztlich wird dann aber die Kette durchlaufen:

DNSName IP-Adresse Listener Publshung Ziel

ucweb.firma.tld

1.2.3.4

80/443

pool.firma.intern

8080/4443

join.firma.de

1.2.3.4

443

pool.firma.intern

4443

Beachten Sie folgende Aussage beim Einsatz von mehreren Pools oder einem Director.

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

Abhängig vom Namenskonzept gibt es weitere Einträge vorzunehmen. Folgende kleine Stichwortliste kann ihnen dabei helfen:

Tätigkeit Beschreibung Erledigt

offizielle IP-Adresse holen

Die Veröffentlichung im Internet erfordert eine offizielle IP-Adresse.

 

Zertifikat beantragen
CN = ucweb.lyncme.de
SAN = join.lyncme.de

Dieser Prozess dauert in der Regel ein wenig, so dass dieser am besten schon früh angestoßen wird.

 

Externe DNS-Einträge
join.lyncme.de A x.x.x.x
ucweb.lyncme.de  A x.x.x.x

In der DNS-Zone im Internet müssen Sie die gewählten Namen eintragen lassen. Auch dies dauert meist ein paar Stunden, bis die Einträge dann auch überall erreichbar sind

 

Interne DNS-Einträge
join.lyncme.de A 10.1.1.1
ucweb.lyncme.de  A 10.1.1.1

Damit auch intern die URLs funktionieren, müssen Sie sicherstellen, dass auch interne Client diese Adressen erreichen können. Wer mit "SplitDNS" arbeitet, hat es hier natürlich einfach.

 

Firewallfreischaltung
Internet -> ReverseProxy:  80/443 allow
ReverseProxy -> FEPool 8080/4443 allow

Wir gehen davon aus, dass die Webdienste nicht per NAT erreichbar gemacht werden, sondern zwischen Internet und internem Pool ein Reverse Proxy steht, welcher durch Firewalls nach Aussen und innen abgeschottet wird. Dann sind in der Firewall die entsprechenden Ports zu öffnen.

 

Reverse Proxy
Zertifikat einspielen
InternetIP:80/443 Pfad:/*  -> 8080/4443

Auf dem Reverse Proxy ist nun das erhaltene Zertifikat einzuspielen und über eine Webveröffentlichung mit einem Listener (ISA/TMG) oder einen virtual Host (Apache) oder andere Wege einzurichten

ProxyPass / https://pool.firma.intern
ProxyPassReverse / https://pool.firma.intern

Die Veröffentlichung ohne http ist optional

 

Test
https://join.lyncme.de/dialin

Ein einfacher Test ist der Zugriff mit einem Browser auf die Dialin-Webseite, die dann die Einwahl-Nummern anzeigen sollte.

 

Wenn sie nun alles richtig gemacht habe und keine Tippfehler und Zahlendreher enthalten sind, dann sollte nun dieser Teil der Veröffentlichung erledigt sein.

Wie machen es andere ?

Die URLs sind eigentlich nicht geheim, da jeder externe Teilnehmer an einem Meeting diese sowieso bekommt. Und für einen Angreifer ist es ein einfaches, die IP-Bereiche eines Unternehmens nach offenen Ports auf 443 ab zu scannen und das Zertifikat auszulesen. Sicherheit durch "Heimlichtuerei" ist kein guter Ratgeber. Der Zugriff auf die SimpleURLs (Speziell /DIALIN) ist Prinzip bedingt ohne Authentifizierung möglich, so dass Sie sehr problemlos schauen können, wie andere Firmen das so machen. Am Beispiel von Microsoft ist das schön zu sehen, dass Sie das zweite Namensmodell nutzen und anscheinend eine ganze Farm an Webservices ebenfalls im Internet veröffentlicht haben.

Man könnte fast zu dem Rückschluss kommen, dass Microsoft intern neun Frontendserver in einem Pool betreibt.

Weitere Links