Wie man AccessGateway (ICAProxy) und HTTP Reverse Proxy (Content Switching mit TM AAA) kombinieren kann

NetScaler wird bereits von vielen Kunden für den sicheren Zugang zu XenApp/XenDesktop Umgebungen eingesetzt. Auch bei der Entwicklung von neuen Citrix Produkten und Technologien wie beispielsweise CloudGateway mit StoreFront ist NetScaler ein wichtiger Bestandteil für eine mögliche Referenzarchitektur: beim Remote Zugriff steht NetScaler in der DMZ und sorgt für sicheren 2-Faktor Authentifizierung (Zertifikate oder OTP). Die Komponente bietet aber mehr als reine Funktionalitäten: neben Sicherheitsfeatures wie AAA (Authentifikation, Autorisation, Accounting), Reverse Proxy im Netzwerk, Zertifikats-Handling, SSL Offload gehören auch L4-L7 Load Balancing, ContentSwitching und Traffic Manager (TM AAA) zu den Kern-Funktionen der Appliance.

Viele Kunden wünschen sich, Ihre Infrastruktur und Komponenten zu konsolidieren und zu vereinfachen. NetScaler bietet den Vorteil, unterschiedliche Funktionen auch einer Appliance zu kombinieren Und hier ist der Vorteil – einfache Umsetzung durch Verwendung der identischen Module zur Authentifizierung – leider auch ein Nachteil: Ohne einen kleinen Kunstgriff, lässt sich der Traffic Manager und SSLVPN nicht miteinander verbinden

Aber erst einmal von vorne.

Einsatzbeispiel der Lösung

Wir gehen von einer Anforderung aus, die häufig in der Praxis zu finden ist:

Ein Kunde hat folgende Dienste für den RemoteZugriff

  • für ICA: XenApp und XenDesktop Umgebungen
  • für HTTPs: Microsoft SharePoint & Microsoft Outlook Web Access
    (das ist nur ein Beispiel; grundsätzlich ist nahezu jede Web-Anwendung hier möglich)

Beispiel 1: Konfiguration für den Zugriff auf XenApp/XenDesktop 

  1. Benutzer startet den Browser zum SSLVPN VServer (AG_IP:SSL) und gibt dabei die Adresse https://ag.demo.net ein
  2. Anmeldung am NetScaler und http-forward incl. SSO am Web Interface (WI) oder CloudGateway
  3. Erzeugen eines launch.ica Files in WI/ CloudGateway
  4. Start der ICA Session auf den gleichen SSLVPN VServer mit ICA Client (dabei spielt der Benutzer Client keine Rolle – egal ob Online Plugin, Receiver, WebClient, Java Client, HTML5 etc.)

Dazu ist die Verwendung von nur einer externen IP mit Port 443 notwendig

Beispiel 2: Konfiguration für den Zugriff via Browser auf Microsoft Outlook Web Access / Microsoft SharePoint mit vorgeschalteter Anmeldung an NetScaler

  • einen ContentSwitch VServer (parallel dazu) am NetScaler aufsetzen (CS_IP:SSL)
  • zur Authentisierung einen TrafficManager VServer (TM_IP:SSL) konfigurieren (im weiteren TM abgekürzt)
  • gleiche Authentisierung wie am Access Gateway, incl. SSO am Backend
  • Verwendung eines Wildcard Zertifikats ermöglich mehrere Services hinter den gleichen CS_IP eindeutig zu adressieren

Dazu ist die Verwendung von mindestens zwei IPs mit Port 443 notwendig: so können sich Benutzer gehen an  https://owa.demo.net oder https://sharepoint.demo.net anmelden (eine IP bei Verwendung von SNI oder Wildcard Zertifikaten)  und werden zur Anmeldung auf den TM VServer http://tm.demo.net weitergeletet.

Für die Benutzer sieht das wie folgt aus:

ICAProxy:  https://ag.demo.net zeigt auf die XA/XD Umgebung

ContentSwitch mit Authentisierung: https://owa.demo.net oder https://sharepoint.demo.net bringt mit vorgeschaltetem AAA auf OutlookWeb Access /SPS, wobei beide auf der gleichen auf CS_IP gehostet werden (zusätzlich sind noch beliebig andere Adressen möglich). Dabei findet die  Authentisierung über einen Redirect zu https://TM.demo.net auf der zusätzlichen TM_IP statt.

Somit sind aus Benutzersicht die beiden Dienste voneinander getrennt. Dabei entstehen folgende Nachteile:

  • Benutzer müssen sich mehrere URLs merken
  • Die unterschiedlichen Dienste laufen auf mehreren IPs (mindestens drei verschiedene IPs bei Verwendung von Access Gateway und Content Switching mit Anmeldung)
  • Wenn beide Dienste zusammen verwendet werden sollen, müssen sich Benutzer zwei Mal anmelden (und abmelden), da Access Gateway und TM unterschiedliche Authentisierungs-Cookies verwenden
  • Über Access Gateway können Benutzern basierend auf AD-Gruppen sowohl Anwendungen als auch URLs zugewiesen. Falls diese nun aber auf Content Switch „zeigen“, muss sich ein Benutzer erneut anmelden
  • WebInterface kann zur Änderung des AD Passworts oft nicht einfach verwendet werden

ContentSwitch als Einstiegspunkt zu ICA- und HTTP- Anwendungen

Aus oben beschriebenen Gründen, wäre es sinnvoll, einen ContentSwitch als einzigen Einstiegspunkt einsetzten zu können. Die unterschiedlichen Dienste können zwar auch direkt über unterschiedliche Namen angesprochen werden, aber im Normalfall will der Benutzer alle Sessions über https://portal.demo.net starten, sich dort anmelden und im einfachsten Fall das WebInterface als Landing Page für Anwendungen (XA) / Desktops (XD/XA) / URLs (PublishedContent) sehen.

Kleiner Exkurs zu URLs als Published Content:

Die Verteilung der URLs als Published- Content hat für XA Kunden natürlich den Vorteil, dass man bestehende Mechanismen zur Zuweisung von Anwendungen in der XenApp/XenDesktop Farm hier auch zur Verteilung der URLs verwenden kann. Über diese, im lokalen Browser aufgerufen URLs, werden die über NetScaler geschützten  Web-Anwendungen aufgerufen, incl. SSO, Web ApplikationFirewall und allen anderen umfangreichen Tools, die NetScaler  funktionsseitig bietet. Nicht zuletzt ist dieser Weg auch perfekt für den Übergang zu StoreFront und Receiver, weil dort der Published Content auch nach Anmeldung am Receiver zur Verfügung steht. D.h. auch für SmartPhones und Tablets mit Receiver ist keine umständliche Anmeldung an einem Portal notwendig.

Doch nun zu den Technischen Herausforderungen und den Lösungsansätzen.

Problem 1:  Hinter einen ContentSwitch kann als Service auf keinen SSLVPN VServer verwiesen werden

  1. Lösung 1: Verwendung eines Double Hop Deployments
    Der ContentSwitch mit TM AAA läuft auf dem ersten Hop und verweist auf den SSLVPN VServer auf dem zweiten HOP.
  2. Lösung 2: Umweg über einen TCP:* VServer
    Man konfiguriert eine Art Schleife indem man über einen TCP ANY VServer noch einmal durch die Traffic Engine des NetScaler läuft und damit einen Double Hop simuliert
    Abgekürzt heißt das:CS-VS_SSL–>LB-VS_HTTP–>LB-SRV_SSL –>LB-VS_TCP:* –> LB_SRV_TCP:* –> SSLVPN_VS
  3. Eine Form Based SSO ermöglicht die Weitergabe der Anmelden Information an den 2. Hop mit SSLVPN. Dies wird über eine TM SSO Action durchgeführt
    SSO Policy formSSOAction:
    TM_FormSSO-to_AG -actionURL “/cgi/login” -userField login -passwdField passwd -ssoSuccessRule “HTTP.RES.SET_COOKIE.EXISTS(\”NSC_CERT\”) && HTTP.RES.SET_COOKIE.EXISTS(\”NSC_AAAC\”)”

Problem 2: Der TM AAA verwirft die Authentisierungs-Cookies vom SSLVPN VServer

  1. Es ist als notwendig, diese Cookies vorher umzuschreiben (aus  NSC_AAAC wird also z.B.AG_AAAC bei der Response und aus AG_AAC wird wieder NSC_AAAC beim Request)Rewrite Policy
    RESPONSE: true / HTTP.REQ.HEADER(“Cookie”).REGEX_SELECT(re!PL_AAAC!) REPLACE “NSC_AAAC”
    REQUEST:  true / HTTP.RES.FULL_HEADER.REGEX_SELECT(re!NSC_AAAC!) REPLACE “PL_AAAC”

Diese Implementierung ergibt eine zusätzliche, elegante Möglichkeit zur  Konsolidierung:

Der  ContentSwitch wird den Anwendungsservern vorgeschaltet, unabhängig davon, ob diese über ICA oder HTTP angesprochen werden

Besonderen Dank möchte ich hier Benedikt.Henghuber@provectus.de aussprechen, der das initial aufgebaut und viele Details dafür getestet und validiert hat. Und auch an Dominik.Feser@citrix.com, der immer wieder mit Kompetenz und guten Ideen zur Seite gestanden ist.

Details zur Implementierung sind unter folgender URL auch nachzulesen: http://www.provectus.de/?p=502

Über Hinweise und neue Anwendungsfälle würde ich mich sehr freuen

Gruß

Peter