OCS 2007 R2 Edge

Diese Seite beschränkt sich auf "kleine" Umgebungen mit einem Edge-Server für die Firma und deckt keine Load Balancer und andere Hochverfügbarkeitstechniken ab.
Die Seite gilt für den OCS 200 R2-Edge.

Achtung: OCS2007 R2 braucht zwingend zwei Netzwerkkarten. Eine normale Installation benötigt zudem drei offizielle Adressen, wenn Sie mit den Standard-Ports arbeiten wollen.

Testen Sie die Funktion von OCS Edge von Außen unter https://www.testocsconnectivity.com/

Achtung:
Diese Beschreibung gilt nicht für Lync, hier sind z.B.: Post 4443 für die Replikation der Konfigurationsdatenbank dazu gekommen.
Lync Edge - die sichere Außenverbindung
Siehe auch Reference Architecture 1: Port Summary for Single Consolidated Edge
http://technet.microsoft.com/en-us/library/gg425891.aspx
Chapter 06 Planning for External User Access.doc
"http://download.microsoft.com/download/1/A/5/1A5160CE-F5F7-4DFE-8EA0-6E2A3F89AD22/Chapter 06 Planning for External User Access.doc"

Diese Funktionseinheit vermittelt zwischen Teilnehmern im Internet und auf dem internen LAN. Dies bezieht sich auf drei Verbindungstypen:

Der Zugriff auf Communicator Web Access oder die Live Meeting Webseite hingegen muss nicht über den Edge laufen. Das sind ganz normale HTTPS-Pakete, die über eine Webveröffentlichungsregel bereit gestellt werden. Zugriff von Clients mit "VPN-Einwahl" können mit Einschränkungen als "interne Clients" betrachtet werden. Details hier finden Sie am Ende der Seite.

Firewall Ports und Kommunikationswege

Die Microsoft Dokumentation (http://technet.microsoft.com/en-us/library/dd441361(office.13).aspx) beschreibt sehr genau, welche Protokolle im Details eingesetzt werden. Damit sollte es auch dem Firewall Admin möglich sein, die entsprechenden Filter vor und nach dem Edge- Server zu konfigurieren.

Info: Dieses Bild ist noch nicht komplett !!. so fehlt z.B. der Adressbuchdownload /ABS

OCS Edge Firewall Ports

Diese Ports sind die StandardPorts und können fast alle nachträglich geändert werden. Für die internen Schnittstellen ist dies auch relativ problemlos. Auf den externen Schnittstellen ist jedoch zu prüfen. ob die Funktion in allen Fällen noch gegeben ist.

Ports für OCS 2007 RTM
Die Port 50000-59999 UDP/TCP Inbound sind nur für Kompatibilität mit Federation zu OCS2007RTM erforderlich. Da jeder OCS2007RTM Kunde aber kostenfrei auf 2007 R2 updaten kann (Arbeitszeit und 64bit Server erforderlich) dürfte es kaum noch solche Systeme geben.

Schematische Anzeige:
Beispiel: Der Edge muss natürlich sowohl interne als auch externe Namen auflösen können. Dazu wird man ihm aber sicher nicht externe und interne DNS-Server eintragen. In der Regel fragt der Edge besser einen internen DNS-Server der sowohl interne Namen kennt aber auch als Forwarder externe Adressenauflösen kann.

Ein ähnliches Bild stellt Microsoft auf http://technet.microsoft.com/en-us/library/dd441361(office.13).aspx bereit

Mit dem OCS 2007 R2 wurden die benötigten Ports weiterhin reduziert. Die komplette Freigabe der Port 50000-59999 für den externen Zugriff ist sogar nur für Federation mit anderen OCS-Servern erforderlich (http://technet.microsoft.com/en-us/library/dd441209(office.13).aspx). Sofern sie sicherstellen können, dass alle anderen Server mindestens R2 nutzen, können die due Öffnung auf "TCP" beschränken, so dass Firewalls die Verbindung besser überwachen können.

Edge Planning Tool for Office Communications Server 2007 R2
http://blogs.msdn.com/byrons/archive/2009/05/07/edge-planning-tool-for-office-communications-server-2007-r2.aspx
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ec4b960c-3fe2-41bd-abdf-ae89cfcb8c6c

Zertifikate und Dienstkonten

Wenn Sie sich aber das Diagramm genauer anschauen, dann finden Sie gleich mehrere eingehende Verbindung auf 443/TCP. Also müssen wir uns über HTTPS und Zertifikate unterhalten. Microsoft beschreibt die Anforderungen auf http://technet.microsoft.com/en-us/library/dd425344(office.13).aspx. Für den Edge-Server sind folgende Zertifikate erforderlich:

Die externen Zertifikate sollten natürlich "offizielle" Zertifikate sein, damit fremde und federierte Server die Gültigkeit und damit die Vertrauenswürdigkeit prüfen können. Natürlich können Sie auch "private" Zertifikate nutzen, solange sie nur dafür sorgen, dass alle Partner und externen Clients diesen Vertrauen. Meist ist ein offizielles Zertifikat aber günstiger als die manuelle Arbeit und der Supportaufwand. Wer "Sparen" will, kann alle drei Dienste mit einem Zertifikat betreiben, muss diese dann aber auf unterschiedliche Ports (ungleich 443) konfigurieren, womit nicht immer alle externen Zugriffe funktionieren.

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.

Externe Namen

Der Edge-Server steht in den meisten Fällen in einer separaten Zone und ist natürlich nicht Mitglied der Domäne. Damit gibt es gleich drei "Probleme, die gelöst werden müssen.

# Verweise auf den Access Edge aus dem Internet
_sipfederationtls._tcp.firma.tld  SRV 5061  edge.firma.tld
_sip._tls.firma.tld               SRV  443  edge.firma.tld
edge.firma.tld                      A  externe.ip.des.edge

# Weitere A-Records für DeviceUpdate, WebConferencing etc

OCS Federation TLS

# Verweise auf den Edge von innen
edgeintern.firma.tld    A  externe.ip.des.edge

Das hört sich alles aber komplizierter an, als es ist. zumindest wenn ihr DNS-Setup korrekt ist und Sie die richtigen Zertifikate auf die richtigen Ports gebunden haben.

Edge Konfiguration per Assistent

Wenn Sie die Edge-Rolle installieren, dann führt Sie ein Assistent sehr elegant durch die erste Konfiguration. Das sollte Sie aber nicht darüber hinweg täuschen, dass Edge nur funktioniert, wenn alle Komponenten korrekt zusammen greifen. Und das sind ganz schön viele (Zertifikate, IP-Adressen, Ports, Firewalls,..)

Internes Interface

Zuerst muss man für den Edge Server das interne Interface definieren, über welches der Edge mit den Frontend Server bzw. Standard Servern kommuniziert. Hier ist auch ein FQDN erforderlich, für welchen auch ein Zertifikat ausgestellt werden muss

Der nächste Schritt definiert die externen Schnittstellen und die Namen:

Die beste Praxis ist die Veröffentlichung von drei Namen mit drei IP-Adressen und den entsprechenden Zertifikaten.

Dass hier private Adressen auftauchen ist ein Zeichen, dass dieser Edge-Server hinter einer Firewall steht, die die ausgewählten Port per NAT nach intern weiter gibt.

Achten Sie hier genau die die FQDNs, die eingetragen sind. Diese werden z.B. im SIP-Handshake über 5061 an die Clients übermittelt. Der OCS-Zertifikatsassistent hat mit SAN-Zertifikaten hier die unschöne Eigenschaft, immer den primären Namen (CN) dort einzutragen. Das ist natürlich nicht passend, wenn sie ein SAN-Zertifikat nutzen und die OCS-Dienste mit einem SAN-Namen arbeiten.

Ein solcher Fehler wirkt sich derart aus, dass Desktopsharing, Voice und Federation etc. nicht funktionieren aber die erste Message per Federation schon bei ihnen ankommt. Die kommt nämlich schon mit dem SIP-INVITE, während folgende Meldungen wieder SIP-Messages sind.

Achtung
Dies ist eine Musterkonfiguration, die so nicht empfohlen ist. Sehr viele Firewalls lassen nur die Standardports 443 für HTTPS-Verbindungen zu, so dass die Funktion nicht sichergestellt ist, wenn Sie wie hier andere Ports verwenden.
Empfohlen ist daher der Einsatz von 443 und drei eigenen IP-Adressen und Namen. Für CWA Web Access brauchen Sie dann noch eine vierte Adresse mit Namen.

Einen EDGE-Server installiert man nicht nur, damit Mitarbeiter von extern auch Audio/Video nutzen können, sondern auch für die Verbindung mit anderen Diensten. Diese Funktion muss entsprechend aktiviert werden.

OCS Federation

In den folgenden Dialogen müssen noch Angaben zu Domänen, internen OCS-Servern etc. gemacht werden, ehe am Ende der Assistent eine Zusammenfassung anzeigt, die man sehr gut in eine Dokumentation übernehmen kann.

Edge hinter NAT

Seit OCS 2007 R2 ist es nun auch offiziell möglich, den Edge-Server hinter einer NAT-Firewall zu verbergen. Damit dies aber funktioniert, muss der Edge "wissen", dass er hinter NAT steht u. Und er muss wissen, welches die offizielle Adresse ist, auf die er Anfragen der Clients lenken soll. Das Wissen um NAT muss auf dem Edge Server per Checkbox aktiviert werden

Edge mit NAT

Die externe Adresse kann man dem Edge hier nicht hinterlegen. Der Edge nutzt dazu DNS, um den Namen auf eine externe Adresse aufzulösen. Da die meisten EDGE-Server zwar das externe Internet auflösen können aber vielleicht doch dazu interne DNS-Server nutzen, gibt es ein Problem bei Firmen mit "Split-DNS", d.h. bei denen die interne DNS-Zone mit der externen DNS-Zone identisch ist. Hier müssen Sie dann intern einen DNS-A-Record mit der offiziellen Adresse eintragen. Wohl dem, der intern nicht den gleichen Alias (z.B. avedge.netatwork.de) verwendet hat. Diesen intern aufgelösten Namen sendet der Edge dann über die SIP-Verbindung an den Client, damit der von extern dann die richtige "öffentliche Adresse" verwendet.

Edge Konfiguration auf dem Frontend Server

Dass Sie einen Edge-Server installiert haben, kann ihre restliche OCS-Struktur nicht alleine erkennen, da der Edge nicht im Active Directory ist. Sie müssen also den Edge Server der Infrastruktur bekannt geben. Dazu gibt es in den globalen Eigenschaften eine eigene Karteikarte

Edge im OCS definieren

Über diese Einstellungen wissen dann die OCS-Server, wie sie an die installierten Edge Server Pakete weiter geben können und dass diese Server auch eine Verbindung zur Farm aufbauen können.

Interne Benutzer von Außen

Der Edge Server wird nicht nur zur Verbindung mit Partnern und externen Personen genutzt, sondern dient natürlich auch den eigenen Mitarbeitern als Zugangspunkt für externe Zugriffe, z.B. von Unterwegs oder zu Hause ohne VPN. Wenn sich die Anwender hierbei nicht anmelden können, dann liegt dies meist an den Authentifizierungseinstellungen auf dem Frontend Server. Per Default ist hier nämlich nur "Kerberos" aktiviert, wozu der Client natürlich ein gültiges Ticket von einem KDC beziehen muss. Ein denkbar schwieriges Unterfangen aus dem Internet. In diesem Fall sollten Sie hier auf NTLM-Kerberos umstellen.

Die Sicherheit der Daten ist ja durch SSL und die NTLM-Verschlüsselung gewährleistet. Die Ursache können Sie übrigens mit dem SIP-Trace des OCS Logging tools sehr einfach ermitteln. Da sieht man auch, dass Der Edge keine Authentifizierung durchführt, sondern diese Anfragen einfach nach intern weiter gibt. Quasi eher ein SIP-Reverse Proxy ist. Aber auch hier zeigt sich wieder, wie wichtig ein Blick ins Eventlog ist, welches sogar die OCS-Management Console quasi direkt präsentiert:

Edge auf Windows 2008

Natürlich funktioniert der Edge Server auch auf Windows 2008 x64 Servern. Allerdings ist dort die Verwaltungskonsole etwas versteckt. man muss nämlich die alte "COMPMGMT.MSC"-Console starten. Hier findet man dann die Verwaltungskonsole für den Edge Server.

Fehlersuche

Die Kommunikation des Edge Servers mit anderen Knoten ist recht umfangreiche und damit gar nicht so einfach zu debuggen. Zwei Werkzeuge stehen bei mir da immer an erster Stelle:

Letztlich ist es manchmal aber auch einfach Glück und Spürsinn, einen Fehler zu finden. Das können abgelaufene Zertifikate sein, aber auch einfache Tippfehler im Servernamen, Zertifikatnamen o.ä.

Edge oder VPN

Der Betrieb eines EDGE-Servers ist natürlich mit Kosten verbunden, die man vielleicht sparen kann, wenn alle Clients als "intern" angesehen werden könnten. Dazu eignet sich natürlich auch ein VPN, zumindest wenn es korrekt konfiguriert ist. Sie dürfen nämlich nicht vergessen, dass der Communicator versucht direkt den Partner zu erreichen, und genau das bei vielen VPNs gar nicht der Fall. Nicht immer ist die IP-Adresse des VPN Clients voll "routbar".

Hinzu kommt natürlich noch, dass ein VPN in der Regel immer erst aufgebaut und Abgebaut werden muss und der Client die passende Software installiert haben muss. Gerade das ist auf mobilen Geräten (Communicator Mobile) oder IP-Telefonen wie einem SNOM oder Tanjay nicht möglich. Selbst wenn das VPN überhaupt erst aufgebaut werden kann und nicht schon durch den Hotspot-Betreiber unterbunden wird, dann werden die Pakete doch erneut umgepackt und eventuell in mehrere kleinere Pakete aufgeteilt, was sich direkt auf die Laufzeit und damit die Sprachqualität auswirkt.

Ein VPN kann also in der ersten Stufe sicher für den Betrieb abgesetzter Clients ein Anfang sein, aber mittelfristig werden sie bei externem Zugriff zum einen Edge-Server nicht wirklich herum kommen. Und erst mit einem Edge-Server haben Sie auch die Möglichkeit der Anbindung an andere Systeme über Federation und MSN PIC

Weitere Links

Keywords:OCS UC EDGE