Outlook Anywhere via Citrix Netscaler (SSL-Offload)

Outlook Anywhere, vormals bekannt als „RPC-over-http(s)“, ermöglicht den externen Zugriff mit „richtigem“ Outlook auf Exchange ohne die Notwendigkeit eines VPN-Tunnels. Dazu wird ein SSL-Proxy von extern zugänglich bereitgestellt, der nach innen dann mit dem Exchange Client Access Server (CAS) spricht.

Aus Netzwerksicht:

Outlook <–HTTPS (tcp/443)–[Firewall]–> Netscaler <–RPC*–[Firewall]–> CAS

Da das Problem mit den dynamischen Ports bei RPC damit noch nicht erschlagen wäre, sind die RPC-Verbindungen zwischen Netscaler und CAS auf eine überschaubare Anzahl von Ports (3) festgelegt. Standardmäßig sind das tcp/6001, tcp/6002 und tcp/6004, die also auf der inneren Firewall geöffnet werden müssen zwischen Proxy und CAS.

Die Verbindungspfeile sind oben bewusst so gezeichnet, dass die Verbindungen beim Netscaler terminieren und von dort neu ausgehen. Der Citrix Netscaler arbeitet mit einer Full-Proxy-Architektur, d.h. er terminiert alle Verbindungen auf der einen Seite und initiiert eigene Verbindungen auf der anderen Seite. Erst diese Arbeitsweise als „Simultan-Dolmetscher“ macht viele Funktionalitäten möglich:

  • TCP-Optimierungen, die die Server entlasten und Verbindungen beschleunigen (Multiplexen von vielen Client-Verbindungen auf wenige Verbindungen zu den Backends, Maximieren von Framegröße uvm.)
  • Caching und Kompression (transparent)
  • Schutz vor Angriffen inklusive: Protokoll-Anomalien kommen nie bei den Backends an, da diese nur saubere Verbindungen vom Netscaler zu sehen bekommen.
  • Web Application Firewall (WAF, in Platinum Edition enthalten) hat Einblick in vollständigen Layer7-Verkehr und kann auf Anomalien in HTML, JavaScript/Formularen, XML uvm. prüfen.
  • Der Dolmetscher kann beim Übersetzen beliebig optimieren und verändern – gilt beim Netscaler in beide Richtungen, d.h. sowohl Request als auch Response!
  • Zurück zu Outlook Anywhere. Die Funktion muss auf dem CAS zunächst aktiviert werden, entweder per PowerShell oder in der Exchange Verwaltungskonsole (Server – Clientzugriff – Outlook Anywhere aktivieren):

    enable-OutlookAnywhere -Server:<ServerName> -ExternalHostName:<ExternalHostName> -ClientAuthenticationMethod:Basic -SSLOffloading:$true

    Erforderliche Informationen beim Aktivieren:

    Servername – der interne FQDN des CAS (sollte vom Netscaler aufgelöst werden können)
    Externer Servername – der FQDN, der durch Outlook von außen angesprochen wird, unter dem also der Netscaler erreicht wird und auf den das SSL-Zertifikat ausgestellt ist
    „SSL-Verschiebung“ – krude Übersetzung für SSL-Offload, wenn aktiviert, akzeptiert Exchange unverschlüsselte Verbindungen vom Proxy

    Dann wird auf dem Netscaler ein SSL-Offloading (Content Switching) VServer angelegt – am einfachsten macht man sich das mit dem passenden AppExpert Template für Outlook Web Access, das direkt einige Parameter wie Caching, Compression, sowie einen Encoding-Filter konfiguriert. Erforderlich ist hier natürlich ein valides SSL-Zertifikat, das an den VServer gebunden wird, sowie die individuellen IP-Adressen für VServer und Backends (CAS Server). Um die Sicherheit noch weiter zu erhöhen, können noch die über diesen VServer erreichbaren Pfade eingeschränkt werden.

    Dazu unter AppExpert – Pattern Sets ein neues Set anlegen und (maximal) mit den folgenden Pfaden bestücken: /owa, /public, /ecp, /autodiscover, /microsoft-server-activesync, /rpc, /unifiedmessaging, /ews. Mit diesem vollständigen Set sind später alle OWA/OMA-Funktionen über diesen VServer möglich.

    Netscaler Pattern Set OWA Paths

    Das Pattern Set nun verbindlich machen, indem eine Rewrite-Policy gebunden wird: AppExpert – Applications – OWA – RedirectToHTTPS – Insert Policy – New Policy.

    Die Policy überprüft, ob der Pfad im Request mit einem der durch das Pattern Set (Name des Sets ist Parameter der Expression) definierten zulässigen Pfade übereinstimmt. Falls nicht, trifft die Expression zu und die Policy führt die angegebene Action aus. Diese wiederum ändert dann den Pfad im Request, hier zum Beispiel auf „/owa“, so dass der Request auf die Outlook Web App zugreift:

    Wird nun der VServer über ein Destination NAT oder das Freigeben des HTTPS-Zugriffs auf die externe Adresse des VServers zugänglich gemacht, kann schon die Konnektivität geprüft werden. Dazu gibt es einerseits ein CMDlet, um vom Exchange Server selbst aus zu testen:

    Test-OutlookConnectivity -Protocol:Http -GetDefaultsFromAutoDiscover:$true -verbose

    Und andererseits eine praktische Website von Microsoft, mit der man tatsächlich auch ActiveSync, OWA, OA und SMTP von extern testen kann (mit einem Wegwerf-Postfach am besten): https://www.testexchangeconnectivity.com Hier ist unter Umständen die Aussage irreführend, OA würde nicht funktionieren, weil die anonyme Authentifizierung für die Site im IIS aktiviert ist. Falls OWA mit Formular-Authentifizierung und OA in der selben Site betrieben werden sollen, ist dies erforderlich, was den Test stört (nicht unterstützt), die Funktion aber nicht verhindert.

    Dann muss nur noch Outlook konfiguriert werden: Kontoeinstellungen – Exchange-Konto – ändern – weitere Einstellungen – Verbindung – Verbindung mit Microsoft Exchange über HTTP herstellen (check) – Exchange-Proxyeinstellungen – diese URL verwenden: externer Servername wie bei der Aktivierung angegeben – Authentifizierung: passend zur aktivierten Authentifizierungsmethode (Basic = Standardauthentifizierung).

    Bei der Standardauthentifizierung werden Benutzername und Passwort beim Verbinden per IE-Dialog abgefragt – und dann ist Outlook „Verbunden mit Microsoft Exchange“. Viel Spaß. 🙂

    Über die XenServer HA-Mechanismen

    Dieser Artikel entstand als Beitrag in den internationalen Community-Foren von Citrix und ist daher englisch verfasst. Es gibt immer wieder Fragen und Diskussionen zu den Effekten, die bei aktiviertem HA Feature in einem XenServer Pool auftreten – daher möchte ich die Hintergründe und Funktionsweisen hier erläutern, denn so wird das Verhalten nachvollziehbar und auch weitgehend vorhersagbar (unerlässlich für eine sinnvolle Planung).

    The case is described (very short version) as a pool of multiple XenServer hosts that loose network connectivity due to failover of a HP Flex-10 fabric or other reasons and then sending all hosts into a reboot loop.

    This behaviour is more or less by design, I think (don’t take this as an official statement, I must not speak for the vendor or their specialists!).

    A XenServer pool is able to act and react without a management server, because all pool members decide on their own, what their state and the state of the pool is. They do so by checking network heartbeat AND storage heartbeat for the availability of all other hosts. If both heartbeats fail, a host will analyze in what manner they have failed: Is nobody else reachable via neither of the heartbeats? Then I am all alone and the problem is most probably located in or at my very self –> fencing strikes! And it strikes by triggering a low (hypervisor) level hard reboot.

    Imagine a different (more probable) situation: a pool with 5 servers. Due to split connectivity, three servers are on one „side“ and two on the other side. They can each reach the pool members on their side via at least one heartbeat, but not the other portion. In this case (where „some“ heartbeats are still good, others are bad) the smaller group will fence and reboot. The larger group will elect a new master and restart the VMs that were running on the now fenced servers. If the two groups would be equal in member size, the current pool master will make the difference, i.e. the group containing the master is the larger group.

    This is a very intelligent concept and probably the only way to make this work automatically, but it has the downside of one case: Everybody uses all heartbeats. Everybody is alone. Everybody fences. Nobody is master.

    Keen thesis: This case should be avoided by a good architecture/design on the fabric part. 😉

    Because of todays „converged infrastructures“, the two heartbeats may not be that different anymore, because you don’t have storage and networking on two different fabrics in all cases, yes, this weakens the otherwise very strong concept of two heartbeats (storage heartbeat is actually a „quorum“ for deciding, who is there and who is not).

    Über Speichervirtualisierung

    Virtualisierung ist in aller Munde. Alles und jeder wird virtualisiert – nur das mit der Cloud ist noch schlimmer (Cloud-Salat). So ist der Begriff der Virtualisierung im Storage-Bereich auch schon länger angekommen, lässt aber ebenfalls schon länger keine Rückschlüsse darauf zu, was eigentlich gemeint ist.

    Eine Variante von Speicher-„Virtualisierung“ hat HP schon lange im Programm (schon bevor es zum Buzzword wurde, behaupte ich mal): EVA. Enterprise Virtual Array. Da wird innerhalb der Speichermaschine virtualisiert. Bei den klassischen Arrays, seien es EMC² AX, CX oder HP MSA oder NetApp FAS oder oder… sieht der Admin Controller und Platten, baut RAID-Sets (Aggregates bei NetApp) mit einem RAID-Level aus von ihm bestimmten Platten zusammen, legt Volumes an und stellt sie als LUNs zur Verfügung. Dazu muss er wissen, was auf den Volumes laufen wird, um die RAID-Level richtig zu wählen und die Anzahl der Platten passend zu bestimmten für die geforderte Performance und Verfügbarkeit – was dann für die Zukunft auch statisch so ist und bleibt. Bei einer EVA sieht der Admin die einzelnen Platten nur zur Information über den Hardware Status und um Speicher Pools zu definieren. Innerhalb eines Pools gibt der Admin Eigenschaften bzw. Anforderungen wie das Redundanz-Niveau vor. Dann legt er Volumes innerhalb der Speicher Pools an, für die er wiederum das Redundanz-Niveau und die gewünschte Größe definiert. Wie die EVA dann intern tatsächlich die Daten über die Platten verteilt, weiß der Admin nicht. Das ist dynamisch und abhängig davon, wie viele Volumes mit welchen Anforderungen es gibt. So ändert sich auch mit der Zeit die Menge des verfügbaren Speichers in einem Pool, denn die EVA balanciert und striped die Volumes dynamisch über den gesamten Pool. Das ermöglicht prinzipiell, dass sie die Verteilung auf Spindeln aus Performance- oder Platz-Sicht optimiert. Angeblich tut sie das auch – unmittelbar nachvollziehbar ist das im Detail aber nicht, ist halt virtualisiert.

    SAN-Virtualisierung im Sinne von DataCore und anderen sieht hingegen so aus, dass man einen Windows Server braucht, auf dem die DataCore Software installiert wird. Was immer an Storage dem Server zur Verfügung steht – sei es Direct Attached (DAS) oder unterschiedliche SAN-Arrays im Backend, erst mal muss es der Windows Server erreichen können – kann dann als Basis für die Funktionalität verwendet werden. D.h. es wird das tatsächliche Backend virtualisiert/abstrahiert und nach vorne einheitlich per iSCSI präsentiert (das kann mit kleinerem Feature-Set auch mit einem Windows Storage Server erreicht werden).

    SANmelody ist dabei auf ein HA-Pärchen limitiert, SANsymphony unterstützt N+1 Redundanz. Loadbalancing findet nur zu den Backends statt (wobei auch erst SANsymphony Multipathing-Arrays unterstützt), d.h. die Anwendungsserver (iSCSI Initiators) sprechen immer mit einem Target (DataCore Server). Andere Vertreter dieser Gattung sind OpenFiler, aber auch – in anderem Maßstab – HP SVSP.

    Dann taucht in dem Zusammenhang auch noch ein HP Produkt auf, das allerdings weniger selbst virtualisiert als dass es wirklich optimal als Storage für Virtualisierungsumgebungen geeignet ist: HP P4000 (the artist formerly known as „Lefthand“). Was dort virtualisiert wird, ist eigentlich nur die Anzahl der Knoten; es wird ein Cluster gebildet aus N Knoten, der von allen iSCSI Initiators über eine Cluster-IP angesprochen wird und die tatsächlichen Verbindungen dann auf die beteiligten Knoten verteilt. Es entsteht ein „hyperredundanter“ Speicher-Cluster, der immer gleichzeitig Platz und Performance skaliert, sehr performant und praktisch immer Feature-complete ist (einmal kaufen, nichts nachlizensieren). Die Redundanz bis hoch zur Knoten-Ebene (Ausfall eines kompletten Speicherknotens) ist transparent für die iSCSI Clients, ein aufwändiges, fehleranfälliges und möglicherweise sogar manuelles Failover zwischen Sites ist nicht nötig.

    Allerdings können P4000 Speicherknoten auch virtuell sein – als Virtual SAN Appliance (VSA) für VMware ESX(i), die wiederum das komplette Feature-Set zur Verfügung stellt. Betrachtet man nun also den ESX-Host als Vergleich zum o.g. Windows Server, der als Basis für z.B. DataCore SANsymphony dient, dann kann man mit einer P4000 VSA alle dem Host zur Verfügung stehenden Storage Backends nutzen und einheitlich, mit dem gesamten P4000 Funktionsumfang, präsentieren, mithin also virtualisieren. In diesem Konstrukt sind allerdings schon so viele Ebenen beteiligt, durch die ein Datenblock zum Lesen oder Schreiben wandern muss, dass das Szenario seine Grenzen haben sollte.

    Bevor ich jetzt noch in Diskussionen oder Vergleiche einsteige (das hebe ich mir für einen anderen Beitrag auf), sage ich nur noch: Welches Schweinderl hätten’s denn gern? Nur weil ein Produkt oder Angebot das Label „Virtualisierung“ trägt, sagt das alleine noch nichts über seine tatsächliche Beschaffenheit oder Funktionsweise aus. Nicht von den Verkäufern einlullen lassen, immer hinterfragen und auf kompetente Beratung bestehen (und darin investieren), um herauszufinden, was für meine konkreten Anforderungen die passende Lösung ist!

    Datensicherung ist kein Notfallplan

    In den meisten größeren Unternehmen ist man sich des Unterschieds zwischen Datensicherung und Disaster Recovery bewusst, doch im Mittelstand fehlt diese Einsicht oft.

    Die Datensicherung ist dazu da, Daten zu sichern und im Bedarfsfall wiederherstellen zu können. Daten, nicht ganze Systeme, sondern Nutzdaten. Also Dateien, Datenbanken etc., die versehentlich oder aus welchen Gründen auch immer gelöscht, überschrieben oder beschädigt wurden.

    Ein Notfallkonzept betrachtet Großschadensfälle vom Hardware-Ausfall (System-Platten statt oder zusätzlich zu den Nutzdaten-Platten, zentrale Komponenten, die zum Ausführen von Betriebssystem und/oder Anwendungen/Diensten erforderlich sind, …) bis zur Nicht-Verfügbarkeit von Infrastruktur-Elementen wie Stromversorgung, Netzwerk, Anbindung reichen.

    Das Notfallkonzept ist sehr individuell und vielfältig, denn es muss nicht nur verschiedene Szenarien betrachten, sondern auch unterschiedlichen Anforderungen an die Verfügbarkeit gerecht werden. So ergeben sich für die Auslegung einer zentralen Infrastruktur Verfügbarkeitsklassen, die Systemen/Diensten zugeordnet werden, und darauf basierend unterschiedliche Auslegungen der Infrastrukturelemente, die diese Systeme bereitstellen, sowie verschiedene Maßnahmenkataloge für den je nach Szenario notwendigen Wiederanlauf.

    Abhängig von den umgesetzten Redundanz-Niveaus (Rahmen-Infrastruktur wie Strom, Kühlung etc., Netzwerk passiv und aktiv, Storage, Virtualisierung, Verfügbarkeitscluster) gibt es nur noch bestimmte Szenarien, die überhaupt dazu führen, dass eine Unterbrechung (Disaster) eintritt und ein Disaster Recovery erforderlich wird. Fällt beispielsweise ein ganzer Standort aus, aber sämtliche Daten und Systeme sind dank Speicher- und Server-Virtualisierung auch in einem weiteren Standort vorhanden und ausführbar, so liegt aus Infrastruktur-Sicht kein Disaster vor (Definitionssache, aber zumindest kann, entsprechende Kapazitäten vorausgesetzt, alles weiter ausgeführt und bereitgestellt werden). Dieses Niveau lässt sich etwa mit einem Storage Cluster aus HP MSA P4000 (ehemals „Lefthand“) und entsprechend aufgebauter Virtualisierungsinfrastruktur (Citrix, VMware, Microsoft) erreichen.

    Man reduziert so die Wahrscheinlichkeit, aber irgendwie kann es doch immer noch passieren, dass mal ein System komplett wiederhergestellt werden muss. Sei es aufgrund von Kompromittierung durch einen Angreifer (neu installieren oder auf einen definitiv sauberen Stand zurück gehen) oder durch beschädigte Daten im Systembereich. Dafür muss es entsprechende Mechanismen geben, die etwa auf Imaging-Verfahren oder einer Software-Verteilung inkl. Betriebssystem-Installation basieren könnten. Die Möglichkeiten klassischer Backup Software sind hier meist eingeschränkt, erlauben bei entsprechend sauberer Umsetzung aber zumindest die Wiederherstellung auf absolut identischer Hardware. Oft ist das aber gar nicht mehr das Problem, da die „Hardware“ sowieso eine Virtuelle Maschine ist. Aber es reicht nicht aus, einfach „alles“ mit der Datensicherung zu sichern.

    Datensicherung ist kein Notfallplan. Wer eine Datensicherung einkauft und umsetzt, hat davon kein Notfallkonzept für Komplettausfälle von Systemen.