Lync Edge - die sichere Außenverbindung
So verbinden Sie ihre Skype for Business mit einem Edge Server mit anderen Firmen, Office 365 Online und erlauben externe Teilnehmer.
Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/
Achtung
Ein Lync Edge darf nicht gegen einen OCS2007 R2 Backend Server mit
Benutzern betrieben werden. Dies ist nicht unterstützt. Einige
Einstellungen für Benutzer greifen z. B. nicht, d.h. Benutzer ohne
"Remote Access"-Recht können dann dennoch von unterwegs arbeiten etc.
Der Edge darf erst dann installiert werden, wenn KEIN OCS 2007R2
installiert ist. Während der Migration muss daher ein OCS Edge weiter
betrieben werden.
Achtung
Die Ports und Beschreibungen sind noch nicht auf
Lync 2013 angepasst. So fehlt z.B. noch der XMPP
Port.
Achtung: Microsoft Teams nutzt die Port 3478-3481. Ihr Edge muss ausgehend auch diese Ports erreichen können.
Die Edge-Rolle zwischen OCS und Lync hat sich ein wenig verändert. Zum einen hat die Möglichkeit eines DNS-Round-Robin als Verfügbarkeitsoption den Bedarf an LoadBalancer reduziert und zudem wurden einige Protokolle verändert. Auf der anderen Seite gibt es neue Zugänge wie z.B. SimpleURL und auch bekannte Funktionen wie Adresslistdownload, Gruppenauflösung etc. benötigen neben dem Edge noch einen Reverse Proxy. Das muss nicht immer ein ISA/TMG-Server sein. Was letztlich bereit zu stellen ist, ist ein Reverse Proxy für HTTPS mit der gewünschten Schutzfunktion.
Sehr schöne Übersicht der
Ports und IP-Adressen
Edge Server scenarios in Skype für Business
Server 2015
https://technet.microsoft.com/en-us/library/mt346416.aspx
Skype for Business Protocol Workloads
Poster
https://www.microsoft.com/en-us/download/details.aspx?id=46448
Visio-Diagramm für Lync 2013
Kommunikationsports
http://www.lync-solutions.com/Documents/Lync_2013_protocol_poster_v6_7.pdf
Microsoft Lync Server 2010 Protocol Workloads
Poster
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ad8ff3fb-014e-4fd7-8003-436d896ab0c6
Für Windows Phone 7 gibt
es eine Lync Protocol App zur Anzeige der Ports
Lync Protocol&Ports | zune://navigate/?phoneappid=209f1437-ab9d-40f3-860f-3194b3b269fb
Lync Topology
Es erklärt sich von selbst, das Sie den "Edge-Server" natürlich in der Lync Topologie eintragen müssen. Dazu zählen die interne und die drei offiziellen Namen und Ports, die NAT-Einstellung und natürlich der "Next Hop"-
Den "Next Hop" auf dem Edge können Sie aber eigentlich nicht vergessen, da der Parameter verpflichtend ist. Allzu oft wird aber auch vergessen, die Zuordnung des Edge am Standard Server bzw. Enterprise Pool vorzunehmen.
An diesem Server muss der Client nämlich auch verwiesen werden, damit er bzw. der RTP-Datenstrom, den Weg nach draußen kennt.
Vergessen Sie dabei nicht, dass Sie auf der Site auch die Federation Route entsprechend eintragen.
Windows Basis Installation
Klar ist, dass der Lync Edge auf einem Windows 2008/20008R2-Server installiert werden muss. Er kann sogar Mitglied der Domäne sein, wenn Sie ihn per Gruppenrichtlinien verwalten wollen. Oft steht der Edge-Server aber auch in einem eigenen Subnetz und dann macht man sich es einfacher, wenn er einfach als Standalone-Server vor sich hin arbeiten. Allerdings sind die entsprechenden Ports zu öffnen, was in der Folge beschrieben wird. Aber Ports alleine sind es nicht.
- IP-Leitwege
Per Default werden alle IP-Pakete in das Internet geroutet. Das ist für Federation und external Access natürlich auch erforderlich. Dennoch muss der Edge natürlich auch alle "internen" Netzwerke erreichen können. Wenn dies nicht über das "Default Gateway" möglich ist, dann müssen Sie statische Routen addieren. (z.B. NETSH oder ROUTE ADD
Route ADD ist unter Windows 2008 und höher nicht mehr empfohlen. Nutzen Sie stattdessen netsh (IP Routing commands http://technet.microsoft.com/en-us/library/cc783403(WS.10).aspx)
REM: Hier Beispiele für die "privaten" Netzwerke. x.x.x.x ist der interne Router und "LAN" der Kartenname netsh interface ipv4 add route 10.0.0.0/8 Interface=LAN nexthop=x.x.x.x store=persistent netsh interface ipv4 add route 172.16.0.0/12 Interface=LAN nexthop=x.x.x.x store=persistent netsh interface ipv4 add route 192.168.0.0/16 Interface=LAN nexthop=x.x.x.x store=persistent
- DNS-Auflösung
Weiterhin muss der Server natürlich die Federation-Partner auflösen können. Ehe Sie nun aber als DNS-Server einen externen Server eintragen, dann sollten Sie beachten, dass der Edge auch den "Next Hop" und alle anderen internen Lync-Server auflösen und erreichen muss. Auch wenn der Edge zwei Netzwerkkarten hat, sollten Sie nicht auf der externen Karte einen externen DNS-Server eintragen und intern den internen DNS-Server. Der TCP-Stack addiert einfach diese Einträge und entsprechend landen einige externe Anfragen intern und interne auch Extern. Beides geht nicht.
Speziell wenn der Edge auch noch Mitglied der Domäne ist, sollte er immer einen DNS-Server fragen, welcher auch AD-Informationen bereit stellen kann. Dieser muss dann eben per Forwarder auch die externe Auflösung erlauben.
Hinweis:
Der Edge fragt auch die DNS-Records _sipfederationtls._tcp.<eigenedomain.tld>
ab. Gerade beim Einsatz mit "Split-DNS", wenn der
Edge noch die internen Server fragt, muss der
Eintrag also auch intern vorgenommen werden.
Wenn Sie dann noch intern "sip.<eigenedomain.tld>"
verwenden, dann hilft nur einen HOSTS-Datei auf
dem Edge, damit der Edge die externe offizielle
Adresse in Erfahrung bringen kann.
Microsoft rät davon ab, dass der Edge Server den internen DNS-Server fragt. Systeme in einer DMZ sollten nie nach intern fragen, sondern nach Extern. Die wenigen Server, die intern über Namen erreichbar sein müssen, können über HOSTS-Einträge gepflegt werden.
- DNS-Registrierung
In dem Zuge sollten Sie auch noch mal einen Blick auf die Einstellungen der Netzwerkkarten tätigen. Die interne Netzwerkkarte mit der einen internen IP-Adresse kann sich gerne am internen DNS-Server registrieren und eintragen.
Die externe Netzwerkkarte
dürfen sich nicht registrieren.
Die drei externen Adressen des Edge sind in der
Regel von intern nicht zu erreichen und erwarten
auch keine Daten "von innen". Wenn ein interner
Frontend mit dem Edge über dessen externe
Adresse sprechen möchte, dann wir er dort keine
Antwort bekommen.
- Zertifikate und CRL
Da die Kommunikation zwischen internen Lync-Servern und Edge per TLS gesichert und verschlüsselt wird, muss dieser auf der internen Netzwerkkarte ein Zertifikat haben. Wird das von einer internen CA ausgestellt, dann sollten Sie bei einem Standalone Server nicht vergessen, dass die Stamm-CA als vertrauenswürdige "Root" addiert werden. Weiterhin sollten Sie sicherstellen, dass der Edge-Server per HTTP die entsprechenden CRL der CAs erreichen kann.
Hinweis:
Der Access Edge sendet bei einer SIP-Verbindung
zu einem
Federation Partner sein Zertifikat mit. Die
andere Seite nimmt die Verbindung nur an, wenn
Sie dem Aussteller des Zertifikats vertraut.
Leider ist die Liste der Stammzertifikate in
Windows 2008 deutlich reduziert und das
dynamische Nachladen dem Server nur möglich,
wenn er die Microsoft Server per HTTP erreichen
kann.
Siehe auch
Rolle der CA
Certificate Support and the Update Root
Certificates Component
http://technet.microsoft.com/en-us/library/bb457160.aspx
http://technet.microsoft.com/en-us/library/cc733922(WS.10).aspx
Weiterhin können zu viele Stammzertifikate einen
Bufferüberlauf verursachen
Siehe 2464556 TLS client authentication fails
between Unified Communications peers with a
logged Schannel warning
Update your firewall now with
this new CRL endpoint
http://blogs.technet.com/b/lync/archive/2014/04/16/update-your-firewall-now-with-this-new-crl-endpoint.aspx
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "SendTrustedIssuerList"=dword:0
- NTP
Zertifikate sind nur in einer bestimmten Zeitspanne Gültig. Daher muss auch der Edge-Server eine korrekte Zeit haben - Windows Features installieren
Add-WindowsFeature ` RSAT-ADDS, ` NET-Framework-Core, ` NET-Framework-45-Core, ` NET-Framework-45-ASPNET, ` Web-Net-Ext45, ` NET-WCF-HTTP-Activation45, ` Windows-Identity-Foundation, ` Telnet-Client ` -Source D:\sources\sxs
Wenn all das gewährleistet ist, dann kommt natürlich noch die Einrichtung der Firewall bezüglich der Verbindungen. Am besten laden Sie sich das folgende Visio-Sheet herunter und drucken es aus.
Microsoft Lync Server 2010 Protocol Workloads
Poster
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ad8ff3fb-014e-4fd7-8003-436d896ab0c6
Installation
In den seltensten Fällen ist ein Edge Server Mitglied der Domäne. So kann der Installer natürlich nicht per LDAP im AD den CMS-Server finden und sich die Daten direkt holen. In diesem Fall müssen Sie die Konfiguration auf einem Server in der Topologie in eine ZIP-Datei exportieren:
export-csconfiguration -filename c:\to_edge.zip
Diese Datei übertragen Sie dann auf den Lync Edge Server und starten das Setup. Hier werden Sie dann gefragt, wo die Datei zu Installation liegt. Nach der Installation selbst erfolgt der weitere Abgleich dann wieder per HTTPS auf 4443, d.h. der interne Lync CMS-Master sendet die Update auf den EdgeServer per HTTPS auf dessen WebService auf Port 4443.
- Install Edge Servers
Lync 2013 http://technet.microsoft.com/en-us/library/gg398230.aspx
Lync 2010 http://technet.microsoft.com/en-us/library/gg398230(v=ocs.14).aspx - Installing the Lync Edge
Server
http://blogs.technet.com/b/ilvancri/archive/2011/02/03/installing-the-lync-edge-server.aspx - Skype for Business 2015 Edge
Server Deployment
http://blog.schertz.name/2016/03/skype-for-business-2015-edge-server-deployment/ - Bereitstellen von Edgeserver
in Skype for Business Server
2015
https://technet.microsoft.com/de-de/library/dn933903.aspx
Externe Kommunikationen
Der Edge-Server ist in den meisten Fällen nicht viel mehr als ein "intelligenter Proxy", der auf Applikationsebene die Protokolle kennt, die zwischen intern und extern übertragen werden. Der Edge bedient dabei drei Zugänge, die jeder für sich eine eigene IP-Adresse benötigen. Es sind auch Konfigurationen möglich, bei denen die drei Dienste auf einer IP-Adresse mit unterschiedlichen Ports laufen, aber dies schränkt oft die Kompatibilität mit anderen Servern ein.
Rolle | Ports | Beschreibung |
---|---|---|
Access |
5061/TLS |
SIP-Verkehr wie Status, Einladungen und die ersten Message einer Kurzmitteilungen |
WebConf |
443/TLS |
Der Name "WebConf" ist irreführend, da es eigentlich nicht viel mit "Web" zu tun hat. Intern heißt der Dienst "RTCDATAPROXY", was viel besser die Funktion beschreibt. Es ist ein Application Proxy für RTC-Daten |
AV Edge |
443/TLS |
Als "Audio/Video"-Edge ist der Dienst mit einer breiten Portrange dafür zuständig, Audio und Video-Nutzdaten zwischen den Internet und Intern zu übertragen. Das bedeutet z.B. dass alle internen LYNC-Clients, die mit externen Lync Clients oder Federation-Partnern A/V machen, mit diesem Edge sprechen, sofern es keine 3+ Konferenz über die MCU auf dem Frontend ist. Office 365 hat die Ports noch enger gefasst: Lync Online Media Port Changes Offer
Better Bandwidth Management |
AV Edge |
3478-3481/UDP |
Wenn Sie per Federation mit Microsoft Teams telefonieren wollen, dann muss ihr Edge Server ausgehend auch diese Ports beim Microsoft Teams Transportrelay erreichen können.
|
In Lync 2013 scheinen die High-Ports komplett zu
entfallen, wenn auch die Gegenseite Lync 2013 hat.
Quelle: Port Summary - Single Consolidated Edge with Private IP
Addresses using NAT (http://technet.microsoft.com/en-us/library/gg425891.aspx)
- Lync Online Media Port
Changes Offer Better Bandwidth
Management
http://blogs.technet.com/b/nexthop/archive/2013/07/03/lync-online-media-port-changes-offer-better-bandwidth-management.aspx
Nicht vergessen werden darf eine vierte Kommunikation, welcher per HTTPS mit dem Frontendpool am Edge-Server vorbei erfolgt und typischerweise über einen Reverse Proxy bereit gestellt wird.
Rolle | Ports | Beschreibung |
---|---|---|
Reverse |
443/HTTPS |
Diese Rolle läuft NICHT auf dem Edge sondern ist ein eigenes System und stellt den Zugriff der externen Clients auf Webservices bereit. Und die bieten ein sehr umfangreiches Leistungsspektrum.
Ein Blick auf den internen IIS zeigt all diese virtuellen Verzeichnisse Es ist also absolut erforderlich, diese Komponente bereit zustellen, wenn Sie nur eine der Funktionen nutzen. Zugriffe werden nach intern auf den Frontend Server (nicht auf einen ebenfalls vorhandenen Directory weiter gegeben. Hochverfügbarkeit ist nicht per DNS sondern nur mit Load Balancern möglich |
HTTPS SimpleURL |
443/HTTPS |
Parallel dazu gibt es natürlich noch die "SimpleURLs" für die Einladung zu Meetings und Anzeige von Einwahlnummern, die zwar vom gleichen Webserver bereit gestellt werden, aber durch einen eigenen Namen und URLs oft getrennt zu betrachten sind. |
HTTP |
80/HTTP |
Adresse zum Download der Meeting Addins für anonyme Teilnehmer. |
Nicht alle Dienst, die auf Port 443 arbeiten müssen darüber zwingend "HTTPS" sprechen.
Interne Kommunikationen
Gerne wird vergessen, dass der Edge natürlich auch intern Verbindungen aufbauen. Und damit ist nicht nur die Verbindung zum "Next Hop", also dem Standard Server oder Frontend Pool gemeint, sondern auch alle Clients. Wenn nämlich z.B. per Federation zwei Partner von ja intern und extern miteinander Audio/Video machen, dann geht das NICHT über den Frontendpool, sondern der Interne Client spricht direkt mit dem Edge.
Die Lync Edge Rolle ist die "Application Firewall" für die Lync Kommunikation. Auch wenn Sie den Server noch mal durch eine
Portfilter-Firewall geschützt in andere Netzwerke stellen, so kann keine
Firewall sinnvoll die Datenströme inspizieren, da alles per TLS
verschlüsselt ist. Viel mehr kann z.B.: die Checkpoint SmartScreen die
Funktion behindern und stören.
Aus meiner Sicht ist es relativ unkritisch, das interne Netzwerk des
Edge-Servers auch in das interne LAN zu stellen, da nicht nur die
internen Lync-Server sondern auch alle Clients immer dann eine
Verbindung zum Edge-Server aufbauen, wenn Sie mit externen Partnern
kommunizieren. Insofern ist das Firewall-Regelwerk nach innen sehr breit
zu fassen.
ähnlich der Diskussion, ob ein ISA/TMG Domainmitglied sein sollte oder
nicht, bin ich eher ein Fürsprecher, den Edge-Server als Domainmitglied
über Gruppenrichtlinien und zentrale Verwaltung zu betreiben statt einen
losgelösten Standalone-Server zu nutzen.
In Umgebungen, in denen der Edge aber nun in einer DMZ steht und eine Firewall den Edge auch gegen interne Zugriffe absichert, müssen die erforderlichen Ports dann freigeschaltet werden. Zudem muss die interne IP-Adresse des Edge Servers auch von allen Netzwerken intern erreichbar sein. Dies bedeutet:
- IP Routing
Beachten Sie, dass der Edge nicht nur mit den Lync Servern kommuniziert, sondern auch mit allen Clients - Namensauflösung
Auch wenn der Edge per Default die meisten Namen nach extern auflösen wird, muss er doch die internen Lync-Server auflösen können
zudem sind natürlich einige Ports zu öffnen. Das können Sie gut sehen, wenn Sie auf einem PC mit NetMon 3 o.ä. einfach mal die Verbindungen mitschneiden
Bitte nicht verwirren lassen. Die Kommunikation wird immer vom Client auf den Edge-Server aufgebaut.
Source | Ziel:Port | Protokoll | Beschreibung |
---|---|---|---|
Edge |
NetHop:5061/TCP |
SIP/TLS |
Der Standardport für die Kommunikation |
Lync CMS |
Edge:4443/TCP |
Lync Replication |
Über diesen Port sendet der interne CMS-Server KonfigurationsÄnderungen an den Edge-Server, der diese in seine lokale SQL-Datenbank überträgt. |
Client und Frontend |
Edge: 443/TCP |
STUN |
Alle Clients, die mit externen
Personen z.B. telefonieren,
Desktop-Sharing etc. machen, sprechen
direkt mit dem Edge-Server. |
Frontend |
Edge:5062/TCP |
SIP/MTLS |
A/V Authentication Service |
Frontend |
Edge:8057/TCP |
PSOM |
|
Adminclient |
Edge:50001/TCP |
CLS |
Lync 2013 CommonLogSystem zur Fehlersuche von dem Client, auf dem CLSController.exe gestartet wird. |
Reverse Proxy |
Frontend-Pool:4443/TCP |
HTTPS |
Zugriff auf die "externe Webseite" auf dem FE-Pool |
Port-Diagramm
Kurz gefasst, sind es z.B. folgende Kommunikationskanäle:
Wenn Sie sich mal die AVEdge-Anforderungen nach extern anschauen, dann sehen Sie einen Pfeil mit "ANY", der mit einem Stern gekennzeichnet ist. Eigentlich soll der AVEDGE dies nicht benötigen, aber ich habe schon erlebt, dass externe Clients einen Port <50000 geöffnet haben, auf den dann der AVEDGE gehen sollte. In der Microsoft Dokumentation steht dazu auch nur:
Regarding the 50,000-59,999
port range, the best practice für Lync Server
2010 is to open it outbound, to "Any" für RDP/TCP für the A/V Edge external interface if
corporate policy allows.
Determining External A/V Firewall and Port
Requirements (http://technet.microsoft.com/en-us/library/gg425882.aspx)
Die Öffnung der Port 50.000-59.999 ist kein Sicherheitsproblem, da die Ports vom Edge immer nur kurz für bekannte Verbindungen geöffnet werden. Wenn diese Ports aber geschlossen sind, dann werden die Pakete zwischen den Edge Servern über 3478/443 getunnelt, was mehr Latenzzeit und mehr Last auf dem Edge bedeutet.
Achtung: Bei Federation mit Microsoft Teams kommen auch die TURN-Ports 3479, 3480 und 3481 zum Einsatz. Daher der gesonderte blaue Pfeil mit dem Teams Icon. Siehe auch Vorbereiten des Netzwerks Ihres Unternehmens für Microsoft Teams (https://docs.microsoft.com/de-de/microsoftteams/prepare-network)
Insofern habe ich mir angewöhnt, dass der AVEDGE nach außen nicht weiter beschränkt ist.
Edge und weitere Firewall
Windows 2008 und 2008R2 bringen ja schon eine ganz gut einstellbare lokale Firewall mit sich, die man aber natürlich auch einschalten sollte. Lync als Windows 2008-Anwendung trägt bei der Installation eine ganze Menge von Regeln ein, die in einer eigenen Gruppen zusammengefasst sind. Hier ein Überblick.
Die ersten 5 Regeln erlauben eingehende Daten auf die entsprechenden Dienste. Etwas irritierend ist natürlich, dass die Ports auf "Any" stehen. Aber hier vertraue ich mal darauf, dass die Microsoft Entwickler schon dafür gesorgt haben, dass ein anderes als das hinterlegte Programm davon eben nicht profitieren kann.
Etwas gefährlich ist aber die Regel "CS System", welche als Programm zwar "System" hat, aber ansonsten alles erlaubt. Nachgeforscht habe ich hier deswegen, da ich auch mal einen Edge Server direkt am Internet betrieben habe und von außen per RDP mich hätte anmelden können. Diese Art Remote-Zugang möchte ich natürlich nicht haben. Und das passiert so.
- Die Regel erlaubt eingehende Verbindungen auf "System", wenn der entsprechende Prozess auch Daten annimmt.
- RDP ist per Default
ausgeschaltet
Aber viele Administratoren schalten es natürlich ein um ihre Server zu verwalten - Durch das Einschalten von
RDP wird auch eine
Firewall-Regel angelegt, die
eingehende Verbindungen auf 3389
ermöglicht.
Allerdings weißt Microsoft darauf beim Aktivieren hin und sie können die Regel natürlich anpassen. - Sie passen die RDP-Regel z.B. an, damit nur interne Clients auf die interne IP-Adresse zugreifen können
- Sie testen und extern und sind erstaunt, dass der Edge dennoch von extern erreichbar ist !!!
Die "CS System" Regel erlaubt dies. Erst eine ""Blockiere RDP von Extern"-Regel würde den Zugriff auch dann unterbinden. Das ist zumindest eine Abhilfe.
Bitte schützen Sie ihren Edge auch von extern durch eine Firewall. Das entspricht dann auch eher dem 4-Augen-Prinzip. Ein einfacher Portfilter mittels Zugriffslisten auf dem Router reicht ja schon aus.
Es ist sehr einfach per DNS-Abfrage auf "sip.<ihre domain> die IP-Adresse des Edge zu erhalten und dann per RDP sie einfach zu ärgern.
Edge Pool
Für eine höhere Verfügbarkeit können mehrere Edge Servers als Pool verschaltet werden. Empfohlen ist dabei die Verteilung der Zugriffe über DNS-RoundRobin. Alternativ kann die Verteilung durch Loadbalancer erfolgen, die dann aber intern ebenfalls per LB verteilt werden müssen. Ein Loadbalancer ist immer dann erforderlich, wenn z.B. OCS-Clients bedient werden, die kein DNS-RoundRobin erlauben. Zudem sind einige Dinge zu beachten:
- AV-Edge Zertifikat
Das Zertifikat auf dem AV-Edge muss auf allen Servern des Pools identisch sein. Die Publickey/Private-Key Daten werden ausschließlich dazu genutzt die MRAS-Tokens zu erzeugen. Da ein Client aber ein MRAS-Token von einem Edge bekommt aber bei der Nutzung von STUN/TURN bei einem anderen Edge des Pools landet, muss dieser das gleiche Zertifikat nutzen. Ansonsten kann es die Credentials nicht verifizieren. - LB Afffinity
Seit Lync 2013 ist "DNS RoundRobin" das empfohlene Verfahren. Sollten Sie aber dennoch einen Hardware Loadbalancer für Edge einsetzen, dann achten Sie darauf, dass Verbindungen von einem anderen System anhand der Source-IP auch immer beim gleichen Edge ankommen..
- Hairpinning und NAT
Denken Sie an den Sonderfall, dass zwei Endpunkte beide je einen anderen Edge-Server in ihrer Umgebung nutzen können. Wenn hier dann per ICE eine "TURN-Verbindung" ausgehandelt wird uns sie die Edge-Server hinter NAT verbergen, dann muss der eine Edge-Server die öffentliche IP-Adressen des anderen Edge-Servers erreichen können und umgekehrt. Ansonsten funktioniert Audio/Video etc. nicht. Dieser Fehler ist sehr schwer zu finden.
Microsoft Dokumente und Referenz-Implementierungen
- Port Summary - Scaled Consolidated Edge with
Hardware Load Balancers
http://technet.microsoft.com/en-us/library/gg398739.aspx - Microsoft Lync Server 2010 Protocol Workloads-Poster
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ad8ff3fb-014e-4fd7-8003-436d896ab0c6 - Edge Server Reference Architecture diagrams
http://go.microsoft.com/fwlink/?LinkId=213322 - Reference Architecture
http://technet.microsoft.com/en-us/library/gg412898.aspx - Primary – Reference Architecture 1: Single
consolidated Edge using network address translation
(NAT)
Reference Architecture 1: Single Consolidated Edge. - Primary – Reference Architecture 2: Scaled
consolidated Edge using NAT and Domain Name System (DNS)
load balancing
Reference Architecture 2: Scaled Consolidated Edge (DNS Load Balanced). - Alternate – Reference Architecture 3: Scaled
consolidated Edge using public IP and hardware load
balancing
Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced). - Lync Server 2010 Edge Server Reference Architecture
Diagrams Available für Download
http://blogs.technet.com/b/nexthop/archive/2011/03/14/lync-server-2010-edge-server-reference-architecture-diagrams-available-for-download.aspx - Planning für External User Access
http://go.microsoft.com/fwlink/?LinkId=205565
Word.doc format http://go.microsoft.com/fwlink/?LinkId=205484 - Vorbereiten des Netzwerks Ihres Unternehmens für
Microsoft Teams
https://docs.microsoft.com/de-de/microsoftteams/prepare-network
Wildcard auf Edge Server
OCS 2007 R2 unterstützt offiziell keine "Wildcard-Zertifikate". Erst mit Lync wird die möglich sein, aber auch nur, wenn alle Gegenstellen ebenfalls Lync verwenden.
Wildcard Zertifikate erscheinen vielen Administrator als ultimative Lösung. Schließlich muss man sich nicht auf Namen festlegen und kann über Hostheader selbst bei Verwendung von SSL mehrere Webseiten und Namen unter einer IP-Adresse betreiben. Auch wenn diese Zertifikate mehr kosten, so sind sie doch sehr flexibel einzusetzen.
Auf der anderen Seite nutzen immer mehr Protokolle die Möglichkeit, dass sich die Gegenstellen gegenseitig identifizieren. Dazu ist es aber normal der Fall, dass der angesprochene Servername auch im Zertifikat enthalten ist. Wenn ein Client einen Server unter seinem Namen anspricht und dann aber ein Zertifikat "*.firma.tld" bekommt, kann darüber schon noch hinweg sehen. Anders sieht es aber aus, wenn der Client sich selbst am Server ebenfalls mit einem Zertifikat ausweisen muss. Er kann hier nur sein "*.firma.tld"-Zertifikat vorweisen. für die Gegenseite ist es dann erst mal schwer daraus den Partner zu ermitteln. Erst wenn der SSL-Handshake aufgebaut ist, können im Nutzdatenstrom dann weitere Informationen ausgetauscht werden. OCS 2007R2 hat diese Intelligenz noch nicht, so das hier noch nicht mit SAN-Zertifikaten gearbeitet werden kann.
Aber selbst mit Lync sind Wildcard-Zertifikate zwar möglich, aber mit Einschränkungen verbunden:
- Wildcard auf Frontend/Pool
Dies ist supportet, aber da LCS und OCS dies nicht unterstützen, sollten Sie dies erst planen, wenn wirklich alle Lync einsetzen. Das Zertifikat auf dem FE ist aber sowieso in fast allen Fällen ein internes Zertifikat, so dass auch mehrere Namen kein echtes Problem sind und keine Kosten entstehen. - Wildcard auf dem Edge
Normalweise benötigt der AccessEdge und der DataEdge ein offizielles Zertifikat. Wildcards sind seit Lync 2010 möglich aber unterliegen einer wichtigen Einschränkung: Nicht alle Gegenstellen reicht das aus, insbesondere da sich damit die Server untereinander auch authentifizieren. OCS-Gegenstellen haben damit z.B. das Problem dass ein Rechner namens "sip.netatwork.de" ankommt, sich aber mit "*.netatwork.de" ausweist. Insofern funktionieren Wildcard-Zertifikate auf dem Edge nur, wenn die Gegenstellen Lync betreiben - Edge auf dem internen Edge
Es ist möglich aber aus meiner Sicht macht es nicht wirklich Sinn. Hier können Sie einfach ein internes Zertifikat verwenden. - Phone Client
Ein echtes "Problem" gibt es aber mit den Telefonen (Aastra, Polycom), die keine Wildcard-Zertifikate unterstützen. Relevant sind hierbei die Namen, die per DNS Autokonfiguration mitgegeben werden. Diese Namen müssen im SAN-Zertifikat enthalten sein.
Auch wenn also ein Wildcard-Zertifikat auf der einen Seite viel Arbeit sparen kann, so bleibt es ein kniffliges Thema in einigen Randbereichen und erfordert einige Tests.
- Wildcard Certificate Support
http://technet.microsoft.com/en-us/library/hh202161.aspx
Private Zertifikate auf Edge Server
Erst mal ist ein Zertifikat auch nur ein Zertifikat und genau genommen hindert Sie niemand daran auch auf den externen Adressen erst mal private Zertifikate zu nutzen. Schließlich können Sie dies ja auch als "Closed Federation" ansetzen und ihre Partner auffordern, ihren privaten Zertifikaten oder der ausstellenden privaten CA zu vertrauen. Das funktioniert sogar zwischen zwei Partnern einer Partnerschaft. Und ihre eigenen Client können, sofern Sie der RootCA als Domainmitglied vertrauen, auch von extern arbeiten. Allerdings sollten Sie zwei Dinge beachten.
- Vertrauen und CRL
Welchen Eindruck macht es für einen Partner, wenn Sie ihn auffordern eine ihm völlig unbekannte RootCA zu vertrauen. Hinzu kommt, dass Sie ihre CA dann "richtig" betreiben müssen und dazu gehört auch die Bereitstellung eines CRL im Internet - Federation-Clients im Internet
Übersehen wird auch gerne, dass ein Anwender einer Partnerfirma nicht immer hinter dem Edge-Server versteckt sind. Wenn Sie dann aber unterwegs mit ihnen kommunizieren, dann bekommen Sie direkt das Zertifikat. Dann fällt auf, wenn auch die Clients des Kunden nicht ihrem privaten Zertifikat vertrauen.
Und ob dies es dann wert ist, das Geld für offizielle Zertifikate zu sparen, sei mal dahin gestellt. Nur auf dem AVEDGE können Sie ein privates Zertifikat verwenden.
DoS auf Benutzerkonten
Eine normale Funktion des Edge-Servers ist die Anmeldung von Anwendern von Extern. Wer aber die Konfiguration der Client über DNS-Einträge automatisch macht, zeigt damit auch möglichen Angreifern, wie Sie per SIP mit Anmeldung sogar Konten sperren können. Aber selbst eine manuelle Konfiguration ist kein Schutz. Es "kostet" einen Angreifer zu wenig, die IP-Subnetze eines möglichen Ziels in Erfahrung zu bringen und Port 5061 oder 443 zu "proben".
Das Lync Team hat sich dieser Problematik schon mal für den Edge-Server angenommen, welcher als Einfallstor denkbar ist.
- Protecting the Edge Server
Against DoS and Password Brute-Force
Attacks in Lync Server 2010
http://technet.microsoft.com/en-us/hh180551 - Protecting the Edge Server
Against DoS and Password Brute
Force Attacks in Office
Communications Server
http://technet.microsoft.com/en-us/ff706687
Aus meiner Sicht greift dies aber zu kurz, da auch Lync andere Dienste wie Autodiscover, EWS nutzt und auch die Lync Webservices per HTTPS mit Authentifizierung angesprochen werden. Eigentlich wäre es an der Zeit, dass die Domaincontroller, welche letztlich die fehlerhaften Anmeldungen protokollieren und das Konto sperren, dies etwas feiner Abstufen und erst mal Fehlversuche von den Clients bzw. Servern blocken und bei wiederholten Fehlversuchen das Konto dann doch sperren. Siehe auch DoS mit Account Lockout
ICE, STUN und TURN
Die quasi wichtigste Funktion des Edge-Servers ist die sichere Verbindung für Audio und Video. Nun ist es aber gerade im Internet üblich, dass Clients sich hinter einen NAT-Router verbergen. NAT schützt in gewisser Weise den Client, da eingehende Pakete nur als Antwort auf eine ausgehende Verbindung möglich sind. Damit wird es aber eigentlich unmöglich, dass ein Client hinter einem NAT-Router angesprochen wird. Ein "Anruf" würde daher ins Leere laufen, weil der Audiokanal zum Endgerät nicht aufgebaut werden kann.
Wer SIP etwas kennt weiß, dass jeder Client sich bei einem SIP-Registrar anmelden und damit eine ausgehende Verbindung aufgebaut wird, auf die der SIP-Registrar antworten kann. Über diesen Weg wird auch in einem "Session Description Packet" (SDP) ausgetauscht, wie die Partner miteinander kommunizieren können. Dazu müssen die Partner aber erst mal ermitteln, wie sie erreichbar sind. Und mit Lync gibt es da eigentlich drei mögliche Verbindungen
- Die eigene direkte
IP-Adresse
Der Lync Client nimmt alle ihm bekannten lokalen IP-Adressen und öffnet dort Ports für eingehende Verbindungen. Diese Kandidaten sind ideal und kommen z.B. bei einer internen Kommunikation zum Einsatz - Externe Adresse des Routers
Der Lync Client baut ausgehend Verbindung zu einem STUN-Server auf. Diese "sieht" nun die externe IP-Adresse:Port, die der NAT-Router verwendet. STUN sendet diese Informationen an den Client zurück. Der Klient kann nun auch diese meist offizielle Adresse und Port als "Kandidat" aufführen. In vielen Fällen leitet ein Router nämlich Pakete an diese Adresse:Port-Kombination an den internen Client weiter. - TURN-Tunneladresse
Mit dem Edge kann der Client aber auch einen Tunnel auf den AVEDGE über Port 3478/UDP aufbauen. Der Edge ist ja extern erreichbar. Der Edge reserviert nun von seiner Portrange 50000-59999 Ports und bietet diese dem Client an, der nun die "AVEDGE externer IP:Port" als weitere Kandidaten aufnimmt.
Dies machen beide Clients und diese Kandidaten werden als SDP im SIP-Paket ausgetauscht. Dann versuchen die Clients miteinander sich irgendwie Pakete zu senden und sich zu erreichen. Das ganze ist natürlich mit Tokens abgesichert und individualisiert, so dass der Client "merkt", über welchen Weg Daten der Gegenstelle abkommen. Die beste mögliche Verbindung wird dann per SDP ausgetauscht und genutzt. Das ganze passiert übrigens schon gleich nach dem INVITE und ist als "Early Media" oft schon abgeschlossen, ehe ein Anwender den Ruf annimmt.
- Silence
- MediaBypass
- SIP im Detail
- MRAS Edge
- Interactive Connectivity
Establishment (ICE)
http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment - Traversal using Relay NAT
(TURN)
http://en.wikipedia.org/wiki/Traversal_Using_Relay_NAT - Session Traversal utilities für NAT (STUN)
http://en.wikipedia.org/wiki/Session_Traversal_Utilities_for_NAT - Troubleshoot STUN with TURN
in Office Communications Server
2007 R2
http://blogs.technet.com/b/drrez/archive/2010/12/06/troubleshoot-stun-with-turn-in-office-communications-server-2007-r2.aspx - RFC 5389 - Session Traversal utilities für NAT (STUN) at http://www.packetizer.com/rfc/rfc5389.
- Interactive Connectivity
Establishment (ICE): A Protocol für Network Address Translator
(NAT) Traversal für Offer/Answer
Protocols
http://tools.ietf.org/html/draft-ietf-mmusic-ice-19 - Vorbereiten des Netzwerks Ihres Unternehmens für Microsoft
Teams
https://docs.microsoft.com/de-de/microsoftteams/prepare-network - Traversal using Relays
around NAT (TURN): Relay
Extensions to Session Traversal utilities für NAT (STUN)
http://tools.ietf.org/html/draft-ietf-behave-turn-09 - Interactive Connectivity
Establishment Protocols (media)
http://go.microsoft.com/fwlink/?LinkId=207414 - [MS-TURN]: Traversal using
Relay NAT (TURN) Extensions
http://go.microsoft.com/fwlink/?LinkId=207419 - Microsoft Lync Server 2010:
Lync Edge Server Security
http://technet.microsoft.com/en-us/magazine/hh272676.aspx
DNS-Auswertungen
Über dass Skype for Business Monitoring können Sie eigentlich sehr gut ermitteln, welche Clients mit welchen anderen Domänen wie intensiv kommunizieren. Allerdings brauchen Sie dazu natürlich die CDR/QoE-Rolle mit einem SQ-Server. Gerade kleinere Umgebungen sparen sich diese Komponente. Dennoch können Sie auch per DNS-Abfragen auf dem Edge-Server zumindest erste Rückschlüsse auf die Nutzung ziehen. Hier ein paar Beispiele:
# Listet alle bestehenden Verbindungen zu anderen Server. Leider ohne Get-NetTCPConnection -RemotePort 5061
Leider enthalten wir hier so keine Information über die Datenmengen. Das ist dann eher wieder eine Aufagbe für NetFlow,SFlow und Co
Auch die DNS-Auflösung und der DNS-Cache kann eine interessante Quelle sein
# listet alle DNS-Einträge aus dem Cache Get-DnsClientCache -RecordType "SRV" -RecordName "_sipfederationtls._tcp.*" # Nun mit aufbereitung nach Domainname Get-DnsClientCache -RecordType "SRV" -RecordName "_sipfederationtls._tcp.*" | select {$_.name.substring(23)},{$_.data}
Wenn Sie z.B. diesen Befehl also z.B. alle 10 Minuten ausführen und die Ergebnisse zusammenführen, dann können Sie grob ermitteln, wann und wie aktiv eine Domain über die Zeit ist.
Weitere Links
Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/
- SimpleURL
- ISA-Server und SSL
- TMG und UAG
- LoadBalancer
- Wildcard Zertifikate
- SAN-Zertifikate
- Deploying an Edge Server with Lync
http://ocsguy.com/2010/11/21/deploying-an-edge-server-with-lync/ - Wildcard Certificates in Lync Server
http://blog.schertz.name/2011/02/wildcard-certificates-in-lync-server/ - Lync Phone Edition Incompatible with Wildcard
Certificates
http://blog.schertz.name/2011/02/lync-phone-edition-incompatible-wildcard-certificates/ - Skype for Business 2015 Edge Server Deployment
http://blog.schertz.name/2016/03/skype-for-business-2015-edge-server-deployment/ - Topologies für External User Access
http://technet.microsoft.com/en-us/library/gg425727.aspx - Microsoft Lync Server 2010 Protocol Workloads Poster
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ad8ff3fb-014e-4fd7-8003-436d896ab0c6 - Ports and Protocols für Internal Servers
http://technet.microsoft.com/en-us/library/gg398833.aspx - Determining External A/V Firewall and Port
Requirements
http://technet.microsoft.com/en-us/library/gg425882.aspx - Lync Server 2010 Port Ranges
and Audio/Media Negotiation
http://www.shudnow.net/2010/12/06/lync-server-2010-port-ranges-and-audiomedia-negotiation/ - Communication ports used by Office 365 table
http://blog.hametbenoit.info/Lists/Posts/Post.aspx?ID=249 - Configuring Lync für External Access
http://ucken.blogspot.com/2011/07/configuring-lync-for-external-access.html - Lync Reverse Proxy Host Header Forwarding
http://waveformation.com/2011/02/21/lync-host-header-forwarding/ - Lync External Web Services without Reverse Proxy
http://ucken.blogspot.com/2011/01/lync-external-web-services-without.html - Certificate Support and the Update Root Certificates
Component
http://technet.microsoft.com/en-us/library/bb457160.asp
http://technet.microsoft.com/en-us/library/cc733922(WS.10).aspx - Vorbereiten des Netzwerks Ihres Unternehmens für
Microsoft Teams
https://docs.microsoft.com/de-de/microsoftteams/prepare-network - 2464556 TLS client authentication fails between Unified Communications peers with a logged Schannel warning
- The (hopefully) definitive guide to load balancing
Lync Edge Servers with a Hardware Load Balancer
http://devcentral.f5.com/weblogs/rkorock/archive/2011/07/14/1096289.aspx - Publishing Lync with Forefront TMG
Part 1 - Covers the initial configuration of Forefront TMG
Part 2 - Publishing Lync Web Services with Forefront TMG
Part 3 - Creating the protocols needed für publishing Lync Edge server
Part 4 - Publishing Lync Edge server with Forefront TMG
Part 5 - Installing Lync Front End and Lync Edge - ms-client-diagnostics: 25; reason=”A federated call
failed to establish due to a media connectivity failure
where both endpoints are internal
https://ucsorted.com/tag/a-federated-call-failed-to-establish-due-to-media-connectivity-failure-when-both-endpoints-are-internal-icewarn0x40003a0/