Lync mit vielen SIP-Domains

Interessant in diesem Zusammenhang ist auch die Seite Namenswahl
Sie beschreibt die Grundlagen zum "Namen" von Diensten wie Exchange, Active Directory etc.

Auf der Seite Lync Zertifikate habe ich beschrieben, wozu alles Zertifikate benötigt werden. Lync sichert aber nicht nur die interne Kommunikation und Authentifizierung per Zertifikate ab, sondern auch gegenüber Clients und anderen Diensten zeigt Lync seine Zertifikate vor, um die Daten per SSL zu verschlüsseln. Die Clients und anderen Server greifen auf Lync Dienste über einen Namen zu, der per DNS auf den Service verweist und der natürlich auch im Zertifikat enthalten sein muss. Diese Seite beschreibt die Besonderheiten, die beim Einsatz von mehreren SIP-Domains zu berücksichtigen sind. Denn verschiedene Dienste erwarten per Default einen Host aus einer Domäne, die auch zur SIP-Domäne gehört.

Es ist problemlos möglich, mehrere SIP-Domänen auf einer Infrastruktur zu betreiben. Aber je nach Größe und Anforderungen bedeutet dies, dass Zertifikate mehrere Namen enthalten müssen (Siehe SAN-Zertifikate) und diese kosten Geld und eine Änderung ist auch aufwändig. Je mehr SIP-Domänen daher eine Firma betreibt, desto wichtiger wird die richtige Wahl der Zertifikate, der CA aber auch der Konzeption.

Wer mehrere SIP-Domains betreibt, muss für folgende Fragen eine Lösung liefern:

Lync Client (_sip._tls.)

Ein Lync Client in der Betriebsart "Autokonfiguration" nutzt die SIP-Adresse, um den Lync Server zu ermitteln. Der Name des Servers muss dazu in der gleichen DNS-Domäne sein, wie die SIP-Domain und das Zertifikat muss den Namen auch enthalten. Hier ist der erste Konfliktpunkt, den Hoster oder Betreiber lösen müssen.

Siehe dazu Lync Hosting:Edge und Clients

Open Federation (_sipfederationtls._tcp.)

Der zweite Punkt, an der DNS-Hostname und damit der Zertifikatnamen mit der SIP-Domain übereinstimmen müssen ist die Open Federation von Firmen miteinander. Bei der Open Federation muss der Administrator keine weiteren Einträge in Lync vornehmen, außer die globale Einstellung, dass Open Federation eben erlaubt ist und der Anwender Federation nutzen darf.

Folgender DNS-Eintrag funktioniert problemlos, da Zielhost und SIP-Domain in der gleichen DNS-Domäne sind.

_sipfederationstls._tcp.netatwork.de SRV 5061 0 0  sip.netatwork.de

Folgender Eintrag funktioniert aber nicht, da der Zielhost in einer andere Domäne ist

_sipfederationstls._tcp.msxfaq.de SRV 5061 0 0  sip.netatwork.de

Folgender Eintrag funktioniert aber wieder.

_sipfederationstls._tcp.msxfaq.de SRV 5061 0 0 sipfed.online.lync.com

Der geht aber nur, weil bei den meisten Lync Installationen "sipfed.online.lync.com" als "Hoster" hinterlegt ist.

Wenn der Anwender dann in seinem Client eine SIP-Adresse in einem anderen unternehmen eingibt, dann wird der Lync Server diese Anfrage über den Edge-Server leiten, der dann per DNS den Edge-Server im Ziel auflöst und per SIP erreichen will. Das ist der Namensauflösung für Mailadressen mit dem MX-Record vergleichbar. Allerdings kommen bei Lync wieder DNS-Service Records (SRV) zum Einsatz und die Verbindung wird zwingend per TLS gesichert.

Siehe dazu Lync Hosting:Edge und Federation

Lync Client Autodiscover (lyncdiscover.)

Lync 2013 Clients (Mobile als auch Windows) nutzen das "lyncdiscover"-Verfahren, um die richtige Konfiguration zu ermitteln. Das Lync-Team ha damit eine Alternative geschaffen, die der Exchange Autodiscover-Funktion nicht ganz unähnlich ist. Mobile Geräte mit Lync Client (Siehe auch Lync 2010 Mobile) fragen nicht per DNS nach SRV-Records um die Lync Edge-Server zu finden, sondern nutzen zuerst einen HTTP/HTTPS-basierten Dienst. Sie fragen nämlich folgende URLs parallel ab:

https://lyncdiscover.<sipdomainhttps://lyncdiscoverinternal.<sipdomain>
http://lyncdiscoverinternal.<sipdomain>

Sie sehen, dass der Client sowohl HTTP als auch HTTPS versucht. Eine Firma mit einer SIP-Domäne kann diesen Zugriff einfach auf den gleichen Host lenken, auf dem auch die Lync Webdienste (Siehe LyncWeb) laufen und dort in das Zertifikat auch den Namen "Lyncdiscover" addieren. Ein umleiten geht nicht.

Mobile device clients do not support multiple Secure Sockets Layer (SSL) certificates from different domains. Therefore, CNAME redirection to different domains is not supported over HTTPS. für example, a DNS CNAME record für lyncdiscover.contoso.com that redirects to an address of director.contoso.net is not supported over HTTPS. In such a topology, a mobile device client needs to use HTTP für the first request, so that the CNAME redirection is resolved over HTTP. Subsequent requests then use HTTPS
Quelle: http://technet.microsoft.com/en-us/library/hh690030(v=ocs.14).aspx

If you have many SIP domains, updating public certificates on the reverse proxy can become very expensive. If this is the case, you can choose to implement automatic discovery so that the initial Autodiscover Service request uses HTTP on port 80, instead of using HTTPS on port 443. However, this is not the recommended approach
Quelle: Defining your mobility requirements für Lync Server 2013 http://technet.microsoft.com/en-us/library/hh690039.aspx

If you use manual settings instead of automatic discovery, mobile Users need to manually enter the following URLs in their mobile devices:
https://<ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root für external access
https://<IntPoolFQDN>/AutoDiscover/ autodiscoverservice.svc/Root für internal access
Quelle: Defining your mobility requirements für Lync Server 2013 http://technet.microsoft.com/en-us/library/hh690039.aspx

Für Firmen mit mehreren SIP-Domänen oder gar Provider ist es aber viel interessanter, darauf zu verzichten und stattdessen per HTTP die Information zum Webservice bereit zu stellen. Diese Daten liefert Lync ohne Authentifizierung, so dass eine SSL-Verbindung beim Erstkontakt gar nicht erforderlich ist. Allerdings erfolgt dann der zweite Zugriff auf die Lync Webdienste per HTTPS. auf die enthaltene URL. Und hier kommt dann noch wieder ein Zwischenschritt, wenn diese DNS-Domäne nicht mit der SIP-Domäne übereinstimmt. Der Clients wird darüber informiert, dass eine "Umleitung" ansteht, die der Client bestätigen muss.

Die Umleitung ist unschön aber aus Sicherheitsgründen verständlich. Denn sowohl DNS-Abfragen als auch die JSON-Antworten mit der LyncWeb-URL sind Klartext und nicht gegen Veränderungen geschützt. Da darf der Client schon mal nachfragen, ehe er die Anmeldedaten an diesen neuen Server in einer anderen Domäne sendet. Nebenbei "erspart" sich ein Hoster damit, auch noch den "Lyncdiscover.<sipdomain>"-Namen pro SIP-Domain in ein Zertifikat zu addieren.

Certificate Requirements
....
When you publish the initial Autodiscover Service request on port 80, you do not need to change certificates für the reverse proxy, because the request uses HTTP rather than HTTPS. This approach is supported, but we do not recommend it.
Quelle: "Technical Requirements für Mobility " http://technet.microsoft.com/en-us/library/hh690030(v=ocs.15).aspx s

Dass Microsoft dies nicht empfiehlt ist wohl dieser Umleitung geschuldet, die ich auch auf Lync Client Discover beschrieben habe.

Es ist sogar nicht einmal schädlich, wenn sich hinter der URL ein Zertifikat befindet. Zumindest bei Microsoft Online ist dies der Fall. Ein PING wird aufgelöst:

Ein HTTP-Zugriff liefert aber folgendes unpassende Zertifikat:

Ich kann nun nicht mit 100% Sicherheit sagen, ob dieses Zertifikat im Lync Mobile Client vielleicht als "Providerzertifikat" enthalten ist. Ich würde daher Lyncdiscover einfach über eine IP-Adresse zum Lync Web Service senden, die kein HTTPS anbietet.

Lösungsweg Beschreibung

Lyncdiscover ohne HTTPS

Für jede Domäne wird im DNS ein "lyncdiscover"-Eintrag addiert, der über eine Webveröffentlichung auf den Lync WebService verweist. Der Client versucht es auch ohne HTTPS und bekommt dann die Information ,wo der Lync Mobility-Service per HTTPS erreichbar ist. Die Domäne diese Hostnamens muss dann aber nicht mehr mit der SIP-Domäne übereinstimmen.

SimpleURLs (meet.)

Der letzte Aspekt ist eher eine kosmetische Komponente, die aber aufgrund der "Sichtbarkeit" nicht unterschätzt werden darf. Wenn Sie Lync einsetzen und z.B. Meetings organisieren, dann finden Sie in den Einladungen, die Sie im Kalender haben oder per Mail versenden in der Regel zwei URLs

In diese Beispiel nutzen beide den Hostnamen "meet.netatwork.de", aber das muss nicht so sein.

  • Konferenz-URL
    Für jede SIP-Domäne muss eine eigene eindeutige URL für die MeetingJoin-Links angegeben werden. Über diese URLs kann ein Anwender dann einem Meeting mit dem Lync Client oder dem Attendee-Client beitreten.
  • DialIn-URL
    Diese URL ist global für die Lync Umgebung und kann nicht pro Domäne angepasst werden. Über diese URL können Konferenzteilnehmer z.B.: die Einwahlnummern abfragen. Sie können sich aber auch anmelden um z.B. ihre Lync-PIN zu ändern.

Für die Wahl der Namen haben Sie eigentlich drei Optionen, die ich auf SimpleURL vorgestellt habe. Wichtiger als die Technik ist hier aber die Abstimmung mit dem Kunden, ob er zwingend seine SIP-Domäne auch als eigenständige URL in den Einladungen sehen will. Konfiguriert wird dies in der Lync Topologie:

Die URL für den Administrativen Zugriff ist eigentlich nur intern relevant. Kaum jemand wird das Lync Control Panel aus dem Internet erreichbar machen wollen. Zwar beherrscht auch Lync eine Delegierung von Berechtigungen per RBAC aber ist noch nicht so weit wie Exchange 2010. Wobei die meisten Firmen, die ich hierzu kenne sowieso ein eigenes Metadirectory, Identity-Management oder Provisioning einsetzen.

Lync Webservices

Neben den sichtbaren Links und Adressen nutzt der Lync Client natürlich noch andere Dienste per SSL. Hier ist z.B. der Lync Web Service zu nennen (Siehe LyncWeb). Dessen URL ist aber für den Anwender eigentlich nicht sichtbar und unabhängig vom SIP-Domainnamen. Sie können für diesen Zugang sogar ein Wildcard-Zertifikat verwenden.

Aber in einer anderen Hinsicht sind viele SIP-Domains natürlich etwas störend. Lync legt für jede SIP-Domain verschiedene REWRITE-Regeln an, die zwar schnell abgearbeitet werden, aber wer mit IIS Failed Request Tracing arbeitet, wird an die Default Größe des Logfiles von 512kByte stoßen. Wer in so einer Umgebung etwaige Fehler bei den Lync Webservices analysieren will, muss diese Grenze eventuell anheben.

Das geht mit der folgenden Kommandozeile:

cd /d "%windir%\system32\inetsrv"
appcmd set config /section:sites -siteDefaults.traceFailedRequestsLogging.maxLogFileSizeKB:1024

Vergessen Sie aber nicht die Einstellung wieder zurück zu stellen und generell die IIS Failed Request Tracing-Konfiguration nach dem Debugging wieder zu deaktivieren.

Weitere Links