Citrix Netscaler VPX Express mit 5MBit/s

Die kostenlose VPX Express Edition des Citrix Netscalers ist jetzt nicht mehr auf 1MBit/s limitiert, sondern bietet den kompletten Funktionsumfang der Standard Edition – also auch den Betrieb im HA-Cluster – mit einer Durchsatzbegrenzung auf 5MBit/s. Für viele kleine Installationen im Perimeter (z.B. als Access Gateway und für das sichere Bereitstellen von externem Zugriff auf diverse Web Applikationen wie OWA und SharePoint) kann das schon ausreichend sein.

Weiterhin gibt es eine neue VPX Developer Edition für alle Kunden, die bezahlte VPX oder MPX Lizenzen besitzen. Die Developer Edition ist gedacht für Test- und Entwicklungsumgebungen und bietet den vollen Funktionsumfang der Platinum Edition (inklusive Web Application Firewall!) mit einem Durchsatzlimit von allerdings wieder 1MBit/s.

Quelle: Citrix Community Blogs

Citrix Receiver über Access Gateway Enterprise

Um über einen Access Gateway Enterprise (CAGEE) Virtual Server sowohl den Zugriff per Browser und Access Gateway Plug-In (Netzwerktunnel) als auch per Citrix Receiver vom iPhone, iPad, Android, Blackberry und so weiter zu ermöglichen, sind zwei Tricks nötig. Grund dafür ist, dass der Receiver die Anmeldedaten bei Verwendung von One Time Passwords (OTP) in der umgekehrten Reihenfolge sendet wie die Web-Schnittstelle: User, OTP, Password statt User, Password, OTP.

Voraussetzung: Zwei Web Interface Sites sind konfiguriert, eine für Access Gateway Zugriff (Authentifizierungspunkt: Access Gateway, Zugriffsmethode: Gateway direkt, auf dem/den WI-Servern wird FQDN des CAGEE auf interne/erreichbare VIP aufgelöst, STAs und Auth-Service URL sind konfiguriert) und eine Service Site (PNAgent).

Weiterhin gehe ich davon aus, dass die Anmeldung an Windows und interne Websites nur mit Benutzername + Passwort durchgeführt wird (für Single Sign On).

Dann sieht die Konfiguration des CAGEE VServers auf dem Netscaler aus wie folgt:

  • Zwei Authentication Server anlegen, LDAP (Active Directory) und Radius (Vasco, RSA oder andere OTP-Produkte)
  • Vier Athentication Policies anlegen, jeweils zwei für LDAP und Radius, die sich durch die Expression unterscheiden, anhand derer sie zur Anwendung kommen. Je eine Policy, die zu LDAP und Radius führt, verwendet als Expression „REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver“, das andere Pärchen „REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver“. (durch die spätere Priorisierung könnte man bei einem Pärchen die Expression auch weglassen, aber so ist es doppelt sicher)
  • Zwei Session Profiles anlegen. Eines für den normalen Web-Zugriff so konfigurieren, wie man das Verhalten im Browser haben möchte (mit/ohne Clientless Access, mit/ohne Client Choices usw., Single Sign On Credential Index „Primary“) und mit der CAG Site als „Web Interface Address“ – das ist das Browser-Profile. Das Receiver Profile bekommt folgende Einstellungen: Split Tunnel „On“, Clientless Access „Off“, Web Interface Address = URL der PNAgent Service Site.
  • Zwei Session Policies anlegen. Eine wiederum mit der Expression „REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver“, um entsprechend das Receiver-Profile auszuwählen, die andere die Negation.
  • CAGEE VServer anlegen, SSL Zertifikat binden.
  • Authentication Policies binden: Unter Primary wird mit niedrigerem Wert für die Priority die Policy gebunden, die den Receiver positiv bestimmt und die Radius-Authentifizierung erfordert, mit höherem Wert die den Receiver negativ (NOTCONTAINS) und dafür die LDAP-Authentifizierung bestimmt. Unter Secondary umgekehrt, d.h. oberste Prio ist Receiver auf LDAP und darunter NICHT Receiver auf Radius.
  • Session Policies binden: Oberste Priorität bekommt die Receiver-Policy, darunter die Browser-Policy.
  • STAs hinzufügen.

Das sollte es gewesen sein. Im Receiver auf Smartphone oder Tablet den Store konfigurieren zur Anmeldung an Access Gateway Enterprise und die entsprechenden Anmeldedaten eingeben (Speichern geht nicht, ist ja ein OTP beteiligt). Den Receiver für Windows besser mittels Merchandising Server parametrisieren und bereitstellen, dann lässt sich auch die Feldbeschriftung schöner setzen.

Citrix Access Gateway Enterprise Theme / Interface anpassen

Citrix hat für die Enterprise Edition 9.x ein weißes Theme zur Verfügung gestellt, das sich wie folgt installieren lässt:

  • Archiv von http://support.citrix.com/article/CTX123607 herunterladen, auf den Netscaler / das CAGEE kopieren, z.B. nach „/var“
  • Testweise entpacken: „tar -xvzf /var/AGEE_white_theme.gz -C  /netscaler/ns_gui/vpn/images/“
  • Wenn das Ergebnis zufriedenstellend ist, die obige Zeile eintragen in „/nsconfig/rc.netscaler“ (dann wird bei jedem Bootvorgang wieder das Theme ersetzt, sonst ist die Änderung nach einem Reboot verloren)

 Allgemein bzw. darüber hinaus lässt sich das Webinterface des CAGEE auch inhaltlich anpassen. Da die Informationen dazu über diverse Dokumente in der Citrix Knowledge Base verteilt sind, hier eine Übersicht:

  • Ein Verzeichnis für die angepassten Dateien anlegen, zum Beispiel „/var/custom“ – das ist nötig, damit Anpassungen einen Reboot überleben können, denn beim Booten werden die Original-Dateien immer wieder hergestellt
  • Unter „/netscaler/ns_gui/vpn/“ die Dateien index.html und login.js nach Wunsch anpassen
  • Die Lokalisierung in verschiedene Sprachen findet über Ressourcen unter „/netscaler/ns_gui/vpn/resources/“ statt – hier können alle Texte geändert werden
  • Alle angepassten Dateien in das oben erstellte Verzeichnis kopieren („/var/custom“)
  • In das Boot-Script „/nsconfig/rc.netscaler“ Copy-Aufrufe eintragen, die die angepassten Dateien an die entsprechenden Stellen unterhalb von „/netscaler/ns_gui/vpn/“ kopieren – das könnte bei passend angelegter Verzeichnisstruktur so aussehen: „cp -r /var/custom/* /netscaler/ns_gui/vpn/“
  • Beim Testen darauf achten, Browser und Proxy Caches zu leeren. 🙂

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.

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ß. 🙂