Citrix ADC Gateway/Storefront Seite lädt nach Chrome oder Edge Update auf Version 100 nicht

Mit dem Update von Chromium auf die Version 100.0.4896.60 gibt es einen Fehler beim Laden der Gateway/Storefont Seiten in Verbindung mit dem Portal Theme „RfWebUI“. Dabei hängen die User in einer Ladeschleife fest. Seit Microsoft am 31.März die neue Edge Version (mit entsprechender Chromium Engine) veröffentlicht hat, tritt das Problem nochmals deutlicher zu Tage.

Laut unseren ersten Beobachtungen trat das Problem nur mit RfWebUi und einem Browser/ einer Engine Version über 99 im User-Agent Header-String auf.

User-Agent Header neuer Microsoft Edge

Nach der Manipulation des Strings im Browserdebugger (mit der gleichen Chromium 100 Engine) funktionierte der Zugriff sofort wieder.

Manipulierter User-Agent Header

Citrix hat das Problem laut einem kürzlich veröffentlichtem KB-Artikel inzwischen eingegrenzt auf fehlerhafte Expressions in Verbindung mit einem Custom RfWebUI Theme. Im Artikel ist ein permanenter Fix beschrieben:

https://support.citrix.com/article/CTX399433

Tech Preview: Citrix App Delivery and Security Service mit AWS

Citrix hat bereits im September angekündigt einen App Delivery Service zu implementieren, auf dem Field Kickoff wurde der Service gleich an prominenter Stelle (in der Keynote) mehrmals erwähnt, es ist also vielleicht an der Zeit sich den Service einmal anzusehen. Seit dem Field Kickoff besteht die Möglichkeit sich über den Citrix Cloud Service Zugang (cloud.com) für ein Tech Preview freischalten zu lassen. Momentan kann der Service nur Amazon Web Services (AWS) Datenströme verarbeiten, somit wird derzeit zwingend ein AWS Konto zur Verknüpfung benötigt, später soll der Service aber auch MS Azure Datenströme bereitstellen können.

Neue Kachel im Citrix Cloud Service (bereits freigeschalteter Preview läuft hier noch 52 Tage)

Citrix hängt die Latte für den App Delivery and Security Service (ADS) ganz schön hoch, er soll Intent-based sein, Always Learning, Always Adapting und Always Protecting (vergl. Introducing intent-based Citrix App Delivery and Security Service | Citrix Blogs).

Die „Intent based“ Konfiguration stellt eine Art Wizard dar, der die Konfiguration stark vereinfacht ermöglicht. Des weiteren soll der Service kontinuierlich den Netzwerkstatus des Internets monitoren und lernen und so eine End-to-End Experience Map erstellen können. Über die Netzwerkmessungen wird erstmals ein „internet-state aware GSLB“ implementiert schreibt Citrix (vergl. Whitepaper Citrix App Delivery and Security Service, A paradigm shift for IT modernization, Seite 9). Der Service soll weiter fehlerhafte Applikationsserver aus dem Load Balancing entfernen können und durch den Rollout weiterer ADC Ressourcen im Hintergrund in die breite Skalieren können. In der Intent based Konfiguration lassen sich an vielen Stellen wenig Details konfigurieren bzw. es sind nicht alle ADC Funktionen direkt nutzbar, andere wiederum werden im Hintergrund automatisch konfiguriert wie z.B. die SSL Settings, welche vom Service optimiert werden. Die WAF kann momentan manuell eingeschaltet und konfiguriert werden.

Nach der Freischaltung des Services wird dieser mit AWS verknüpft und ermöglicht dann eine Konfiguration, welche auf Knopfdruck in das AWS und die ADS Elemente ausgerollt (deployed) wird. Es wird im Startbildschirm nach Application oder Multi-Site Application unterschieden, welches die Unterscheidung zwischen Loadbalancer/ Content Switching Geschäft und DNS basiertem GSLB (bzw. etwas vergleichbarem) darstellt.

Startbildschirm des Services

Als ich mit meinen Tests begann, lies der Menüpunkt „Deliver an Application“ (welcher die Intent based Konfiguration startet) noch zu auf einen Classic Modus umzuschalten, welcher alternativ ADC-like zu bedienen war. Allerdings mussten die Objekte hier ohne Erklärung manuell erzeugt werden und über die Eintragung in Freitextfelder verknüpft werden. Diese noch nicht ganz fertige Funktion wurde im Laufe meiner Tests ausgeblendet. Auch gab es am Anfang die Möglichkeit eine ADC Konfiguration zu laden, dort einzelne Virtual Server auszuwählen, zu extrahieren und übernehmen zu können. Diese Funktion war aber nur in der Lage einfache Konfigurationen übernehmen zu können, bei komplexeren Konfigurationen gab es Fehler beim Parsing. Die im Folgenden zu sehenden Screenshots stammen daher von der Intent based „Modern“ Konfigurationsmöglichkeit.

Erstellen Cloud Access Profile

Zuerst muss die Anbindung der Citrix Cloud Services an die AWS-Plattform erfolgen, dies geschieht über ein Cloud Acsess Profile. Dafür muss ein Skript im AWS ausgeführt werden, welches einen Cloud Formation Stack erzeugt und auch die entsprechenden Berechtigungen im AWS setzt.

Screenshot von der Validation bzw. Update des Stacks / JSON Vorlage

Der obige Screenshot ist von der Validation eines Cloud Formation Stacks, bei der Erstausführung ist ganz unten noch ein Feld eingeblendet, in das der durch AWS zurückgegebene RoleARN eingetragen werden muss. In diesem Dialog muss der obige JSON Code kopiert werden oder die Datei über den Link „Download“ heruntergeladen werden.

Cloud Formation Startbildschirm
Erstellen des Stacks über eine Vorlagendatei (die zuvor gespeicherte JSON Datei)
Übersicht der Stacks

Der gerade erstellte Stack muss geöffnet werden um den RoleARN anzuzeigen, welcher in den Citrix Dialog eingefügt werden muss.

Job Ausgabe / RoleARN

Der oben genannte RoleARN aus der Job Ausgabe wird kopiert und in die Citrix Console eingefügt. Danach kann das Cloud Environment erzeugt werden.

Erzeugen Cloud Environment

Ein Cloud Environment ist ein Bereich in den der Citrix Service Deployed werden kann. In ihm sind die Region, Availability Zones und die zu benutzende Virtual Private Cloud definiert.

Cloud Environment erzeugen/ updaten

Danach kann das Deployment des Environments erfolgen. Mit dem „View More Details“ Schalter in der Mitte wird die Ausgabe detaillierter und lässt erahnen, was Citrix mit der Role im AWS erzeugt.

Erzeugte Objekte im AWS / Citrix geht „Xlarge“ einkaufen

Es werden pro Availability Zone zwei m5.xlarge Instances erzeugt
Dazu kommen noch NAT Gateways und Elastic IPs

Achtung: In unserer Testumgebung haben die von Citrix erzeugten Objekte mindestens 6$ pro Tag gekostet (realistisch für 24 Stunden eher 16$) und im ausgeschalteten Zustand noch etwa 3$, da die NAT Gateways pro Stunde abgerechnet werden (vergl. Logisch isolierte virtuelle private Cloud – Amazon VPC Preise – Amazon Web Services)!

AWS Cost Explorer

Einrichten einer Testapplikation (LAMP)

Als Backend für die Testapplikation wurde eine Linux Maschine mit LAMP Stack ausgerollt als t3.micro Instanz (diese sind im kostenlosen Kontingent enthalten; vergl. Limits des kostenlosen Kontingents für AWS – AWS-Fakturierung (amazon.com)).

Testlamp Application 1
Testlamp Application 2
Testlamp Application 3
Testlamp Application 4

Die Möglichkeiten in der Intent based Konfiguration liegen weit hinter dem was der darunterliegende ADC kann.

Testlamp Application 5 / Beispiel Responder

Auch beim Responder kann derzeit nur ein Subset genutzt werden von dem, was der ADC eigentlich ermöglicht. Mangels der Möglichkeit mit einer Webseite zu antworten, haben wir im Test einen Error zurückgegeben.

Testlamp Application 6 / Leere WAF Konfiguration

Testlamp Application 7 / Laufende Applikation
Ansicht der Analytics

Unterstützte Features

FeatureCitrix App Delivery and Security service AdvancedCitrix App Delivery and Security service premium
SSL/Load balancing/content switchingYesYes
Content rulesYesYes
AuthenticationYesYes
GSLBYesYes
Caching and compressionYesYes
AnalyticsYesYes
Lifecycle managementYesYes
ITM based GSLBYesYes
Security (WAF, BOT management)NoYes
ICA ProxyNoNo
Gateway SSL VPNNoNo
Tabelle der derzeit unterstützten Features lt. Hersteller
Usage/ Abrechnung

Abrechnung / Entitlements

Der obige Screen zeigt die Möglichkeit die Trafficnutzung nach Art der genutzten Bandbreite (Premium Bandbreite = Premium Features wie z.B. WAF) anzeigen zu können. Im SaaS Model wird Bandbreite von zuvor abgeschlossenen Entitlements genutzt werden.

Entitlement typeDeployment type
Standalone entitlementsCitrix App Delivery and Security Service – Citrix Managed
Trial entitlementsCitrix App Delivery and Security Service – Citrix Managed
Pooled SaaS Bundle entitlementsCitrix App Delivery and Security Service – Citrix Managed
Entitlements

Edition typeEntitled to
Advanced300 TB bandwidth + 25 million DNS queries
Advanced1200 TB bandwidth + 100 million DNS queries
Advanced4800 TB bandwidth + 500 million DNS queries
Advanced2000 TB bandwidth + 2 billion DNS queries
Premium300 TB bandwidth + 25 million DNS queries
Premium1200 TB bandwidth + 100 million DNS queries.
Premium4800 TB bandwidth + 500 million DNS queries
Premium2000 TB bandwidth + 2 billion DNS queries
Entitlements / Pakete

Es wird voraussichtlich auch zusätzliche DNS Pakete geben.

Quelle und mehr Informationen: Entitlements | Citrix App Delivery and Security service

Fazit

Der Service bietet einen interessanten Ansatz, da die darunterliegende Infrastruktur von Citrix betrieben und somit auch geupdatet wird. Momentan ist das Feature Set noch recht klein, wenn dieses aber für die Intent Based Konfiguration erweitert wird und die weiteren Möglichkeiten wie die Classic Konfiguration oder der Import von „ns.conf“ Kommandos wieder dazukommen (aktuell nicht oder zumindest nicht mehr in meinem Tech Preview), könnte sich eine interessante Alternative zum Aufbau kompletter Instanzen im AWS oder Azure ergeben.

Zu den Möglichkeiten des Einsatzes eines Citrix ADC in einer Cloud Umgebung sprechen sie uns gerne an, wir zeigen ihnen die unterschiedlichen technischen Möglichkeiten der Realisierung und erklären ihnen die Unterschiede in der kaufmännischen Abbildung mit dem neuen Citrix ADS Service, ihren vorhanden Lizenzen, den Subscriptions wie Pooled Licensing oder auch unserem eigenen sehr flexiblem ADCaaS Produkt.

Links ADS Service:

Introducing intent-based Citrix App Delivery and Security Service | Citrix Blogs

App Delivery and Security Service – Citrix Germany

Citrix App Delivery and Security Service, A paradigm shift for IT modernization

Entitlements | Citrix App Delivery and Security service

Links zu AWS:

Limits des kostenlosen Kontingents für AWS – AWS-Fakturierung (amazon.com)

Logisch isolierte virtuelle private Cloud – Amazon VPC Preise – Amazon Web Services

Teil 2: VerSAMLung – SSO mit SAML oder KCD für interne Webservices

(von Stefan Kuscher und Benjamin Rodewald)

Im ersten Teil unserer Serie „verSAMLung“ haben wir den Citrix Application Delivery Controller (ADC) als SP an die MS Azure MFA Authentifizierung (als IdP) angebunden und so die bequeme und transparente Nutzung von Applikationen auf dem Citrix ADC möglich gemacht, welche mit einer Pre-Authentifizierung geschützt sind.

Bisher muss man sich nach der Anmeldung am Azure (welche der ADC nutzt) noch immer an der eigentlichen Applikation anmelden, aber auch dafür gibt es eine Lösung. Der ADC bietet die Möglichkeit Anmeldedaten zu extrahieren und die diese auch für den Single Sign On im Backend zu benutzen. Im einfachsten Fall, könnte die dem ADC bekannte Username/ Kennwort Kombination z.B. für eine 401 Header Based Authentication genutzt werden, hierfür wäre lediglich eine Traffic Policy, welche Web Single Sign On anschaltet, notwendig.

In Verbindung z.B. mit SAML oder Certificate based Authentication ist das Vorgehen ein klein wenig komplizierter, da auf dem ADC keine Anmeldedaten vorliegen (was dem Sicherheitsniveau natürlich sehr zuträglich ist). Hier muss ein Verfahren genutzt werden, welches alleine mit den im SAML Token vorhandenen oder im Zertifikat vorhandenen Informationen auskommt. Neben der Möglichkeit hier im Backend ebenfalls SAML für den SSO zu benutzen, gibt es die Möglichkeit Kerberos Constrained Delegation (KCD) zu nutzen. Da sämtliche Applikationen aus dem Windows Umfeld damit sehr einfach angebunden werden können, bietet sich diese Möglichkeit oft an um eine Applikationen zu verSAMLen (SAML fähig zu machen).

DNS und NTP auf dem ADC

Wie auch in den späteren Logs erkennbar sein wird, benötigt der Netscaler für die Nutzung von Kerberos eine funktionierende DNS Auflösung der Windows Active Direcory Domain und eine per NTP korrekt synchronisierte Uhrzeit. Für die Domain/ den DC kann theoretisch auf dem Netscaler auch manuell ein Ressource Record hinzugefügt werden. Zur Zeitsynchronisation sind idealerweise mindestens zwei NTP Server einzutragen und die Synchronisation einzuschalten.

Konfiguration AD Account / Delegation

Bei der Constrained Delegation wird ein Servcie Benutzer für den ADC angelegt, dem dann die Delegierung (Zugriff im Auftrag eines anderen Benutzers) erlaubt wird:

Nachdem der Benutzer angelegt wurde, muss der HOST SPN gesetzt werden, damit die Regsiterkarte „Delegation“ erscheint:

setspn -S HOST/[Name d. Deleg.-konto].[FQDN] [NetBIOS-Domainname]\[Name d. Deleg.-konto]

Setzen des Host SPN
Kerberos Delegierungskonto 1/2

Auf der Registerkarte „Delegation“ des Accounts wird dann die eigentliche Delegierung konfiguriert, der Service SPN „http/demoweb.mwdemo.local@MWDEMO.LOCAL“ für einen internen Microsoft IIS Webserver.

Kerberos Delegierungskonto 2/2

Konfiguration KCD auf dem ADC

Für den Account wird dann auf dem ADC ein KCD Objekt erstellt, welches in einer Traffic Policy eingebunden wird:

ADC / KCD-Account
add aaa kcdAccount wiakcd_appdelegation -realmStr MWDEMO.LOCAL -delegatedUser appdelegation -kcdPassword b616477dhgkjifdghuidf4757747593458930580f -encrypted -encryptmethod ENCMTHD_3 -kek -suffix 2021_yy_yy_yy8 -userRealm MWDEMO.LOCAL -serviceSPN "http/demoweb.mwdemo.local@MWDEMO.LOCAL"

Steuerung SSO mittels Traffic Policy und Profile

Mittels einer Traffic Policy und einem Traffic Profile, welches auf dem Load Balancing Vserver gebunden wird, wird gesteuert an welchen Stellen die KCD SSO Settings angewendet werden sollen:

Traffic Profile (unten ist der KCD Account ausgewählt)
add tm trafficAction prof_traf_wia_demoweb_kcd -SSO ON -persistentCookie OFF -InitiateLogout OFF -kcdAccount wiakcd_appdelegation

Traffic Policy über die das o.g. Profile angebunden wird
add tm trafficPolicy pol_traf_wia_demoweb_kcd true prof_traf_wia_demoweb_kcd

Debugging

Ein Debugging ist mittels cat /tmp/nkrb.debug möglich.

Bei unserem ersten Versuch in der Demo Umgebung gab es wegen den unterschiedlichen Realms in Verbindung mit dem Azure AD noch Probleme:

Log Fehler

Wir haben daraufhin in den KCD Settings das Feld „User Realm“ ergänzt, dies verhindert, dass wie oben eine Cross Realm Authentifizeirung zwischen Azure AD und AD Domäne versucht wird. Somit wird die Anfrage „Username@michaelwesseldemo.onmicrosoft.com“ zu der passenden Anfrage „Username@mwdemo.local“ umgewandelt. Dieser „Workaround“ betrifft unserer Testumgebung aufgrund der fehlenden routingfähigen Domäne.

Hier die Logs des Erfolgsfalls:

Log Erfolg – 1
Log Erfolg – 2
Log Erfolg – 3
Log Erfolg – 4
Log Erfolg – 5
Log Erfolg – 6
Log Erfolg – 7

Teil 1: VerSAMLung – Microsoft Azure SSO am Citrix ADC mit SAML

(von Stefan Kuscher und Benjamin Rodewald)

Im Nachfolgenden erläutern wir die Vorteile, wenn Citrix ADC und Azure Active Directory verSAMLt sind und wie wir dies umgesetzt haben.

Folgende Vorteile ergeben sich:

  • Benutzer muss lediglich beim Anmelden am Arbeitsgerät ein Passwort eingeben (SSO) und ist somit automatisch beim Citrix ADC bekannt und bestenfalls alles was mit diesem verknüpft ist. Von dort aus kann z.B. der Zugriff auf Applikationen wie Citrix Xenapp/XenDesktop oder auch Web-Applikationen erfolgen. (Ohne zusätzliche Anmeldung)
  • Azure AD als der Zugangspunkt für Benutzer.
  • Benutzersteuerung/Berechtigungsverwaltung zentral in Azure AD.
  • Conditional Access\Begrenzter Zugriff + MFA (Azure AD P1 Lizenz)

Voraussetzungen

Ablauf

Abbildung Ablauf SAML

Das SAML Protokoll wurde geschaffen um über eine Teilung in Identity Provider (IdP) und Service Provider (SP) die Authentication für Zugriffe zu ermöglichen. Dabei kann sofern eine Applikation z.B. aus der Cloud bezogen wird, trotzdem gegen einem IdP, der unter Kontrolle des eigenen Unternehmens steht authentifiziert werden (in unserem Falle ist dieser in der Cloud als MS Azure AD ausgeprägt). Der SAML SP (AAA auf dem ADC) vertraut diesem IdP und lässt den Request beim Vorhandensein der Authentifizierungsinformationen passieren. Sind die Informationen nicht vorhanden, würde der Citrix ADC auf die Anmeldeseite des SAML IdP weiterleiten.

In unserem speziellen Fall meldet das Gerät bereits beim MS Windows Logon den Benutzer in der Cloud beim Azure AD an. Der Benutzer besitzt daher zum Zeitpunkt seines ersten Zugriffs schon die entsprechenden Anmeldeinformationen und der ADC (bzw. die AAA / SP Komponente) lässt den Benutzer mit SSO passieren.

Deployment einer Enterprise Applikation in Azure (IDP)

Um eine Kommunikation mit dem Citrix ADC via SAML herzustellen benötigt man auf der Azure Active Directory Seite eine Enterprise Applikation. Diese wird im Azure Active Directory -> Enterprise Applications -> New Application
bereitgestellt und wird benötigt um sich mit dem SP per SAML auszutauschen.

Auswählen einer Vorlage im Browse Azure AD Gallery für das Citrix SAML Add On
Microsoft bietet bereits diverse Vorlagen für Enterprise Applikationen an. In unserem Fall benötigen wir die Vorlage „Cirix ADC SAML Connector for Azure AD“.

In der Enterprise Applikation müssen die benötigten Informationen wie Identifier, Reply URL und Sign On URL des Citrix ADC hinterlegt werden.

1.) Enterprise Applikation -> Name der APP -> Single Sign-on
Identifier: https://FQDN
Reply URL: http(s)://FQDN der WebApplication/cgi/samlauth
Sign On URL: https://FQDN/CitrixAuthService/AuthService.asmx


Ebenfalls finden sich dort die Informationen die der Citrix ADC im späteren Verlauf benötigt z.B. die Login URL von Azure Active Directory oder die Metadaten URL.

2.) Mittels Metadaten URL kann der Austausch der Informationen zwischen AAD und ADC automatisch erfolgen. Voraussetzung hierfür ist dass die Version des CItrix ADC den Austausch via Metadaten bereits unterstützt.

3.) Falls ein Austausch via Metadaten nicht in Frage kommt ,können die Informationen auch manuell dem Citrix ADC übergeben werden (Login URL, Zertifikat…).

Screenshot aus dem Citrix ADC SAML Connector

Berechtigungskontrolle für die Enterprise Applikation

Im Anschluss müssen die Benutzer noch die Berechtigungen erhalten, um die Enterprise Applikation nutzen zu können. In unserem Fall stellen wir die Applikation für alle Benutzer zur Verfügung. Wir deaktivieren somit die Zuweisung für einzelne Benutzer komplett:

Assignment required = No

Screenshot Zuweisung einzelner Gruppen und Nutzer
Falls eine Zuweisung an einzelne Benutzer erwünscht ist, einfach „Assignment required“ auf „Yes“ umstellen (Standardeinstellung) und die Zuweisung für Benutzer unter „Users and Groups“ durchführen.

Konfiguration des AAA Servers / SAML SPs auf dem ADC

Um eine Applikation auf dem Netscaler mit einer Preauthentication zu schützen, kommt die AAA Funktion zum Einsatz. Hierfür wird ein AAA Virtual Server Objekt angelegt, welches in der SAML Welt gleichzeitig den SAML Service Provider (SP) darstellt, der in unserem Fall dem Microsoft Azure Identity Provider (IdP) vertraut. Um für eine Web Applikation die Anmeldung am AAA bzw. dem SAML IdP zu erzwingen, wird der AAA Vserver auf dem enstprechenden Load Balancer oder Content Switch Objekt über die „Authentication“ Registerkarte verknüpft.

Anlage des AAA Virtual Servers

Screenshot  Anlage des AAA im Authentication Virtual Servers
add authentication vserver aaademo SSL 0.0.0.0

Ein SSL Zertifikat muss gebunden werden, auch wenn der AAA Vserver nicht direkt angesprochen wird.

bind ssl vserver aaademo -certkeyName AAA_test
bind ssl vserver aaademo -eccCurveName P_256
bind ssl vserver aaademo -eccCurveName P_384
bind ssl vserver aaademo -eccCurveName P_224
bind ssl vserver aaademo -eccCurveName P_521

Screenshot SSL Virtual Server Server Certificate Binding

SAML SP Server

Falls der Import der Metadaten nicht funktioniert, können die Daten auch aus dem XML extrahiert werden und manuell hinterlegt werden. Das IdP Zertifikat lässt sich auf der Azure Enterprise Appliacation im Azure Portal exportieren (Base64 bietet sich an).

Screenshot mögliche Konfiguration aus dem Configure Authentication SAML Server
SAML Action 1/3
SAML Action 2/3

Nach Citrix Best Practices muss zur Absicherung eine Relaystate Regel konfiguriert werden (vergl. Citrix Application Delivery Controller and Citrix Gateway – SAML Configuration Reference Guide):

SAML Action 3/3 – Relaystate Regel
add authentication samlAction AzureSSOHapp-SAMLServer -samlIdPCertName ADC-SAML-Connector -samlRedirectUrl "https://login.microsoftonline.com/883dfdf-154e-4fdf33-b857-1dfdf8d/saml2" -samlIssuerName "https://vipdemo.michael-wessel.de" -relaystateRule "AAA.LOGIN.RELAYSTATE.EQ(\"https://vipdemo.michael-wessel.de/\")" -logoutURL "https://login.microsoftonline.com/8dda6db-dde-4e33-dddd7-173179eb1e8d/saml2"

SAML SP Policy

Screenshot Configure Authentication Policy
add authentication Policy pol_AzureSSOHapp -rule true -action AzureSSOHapp-SAMLServer

Die erstellte SAML SP Policy muss dann an den AAA Virtual Server / SAML SP gebunden werden und der AAA Virtual Server auf der Registerkarte „Authentication“ des Load Balancers oder Content Switches verknüpft werden. Auf ADCs mit einer aktuellen Firmware haben sich zudem die Defaults für die Athorization geändert, so dass eine pasende Authorization Policy anzulegen ist.

Ausblick

Mit dem Vorliegen der Anmeldeinformationen kann auf dem Netscaler auch eine detaillierte Berechtigung auf bestimmte URLs anhand von z.B. Gruppenmitgliedschaften über Authorization Policies erfolgen.

Außerdem ist es möglich authentifizierte Benutzer z.B. per SAML oder KCD an Servern hinter der Pre-Authentication automatisch anzumelden.

Im MS Azure sind umfangreiche Möglichkeiten der Multi Faktor Authentifizierung und des Conditional Access möglich.

Mehr zu diesen und anderen Möglichkeiten werden sie in den weiteren Artikeln unserer Serie „verSAMLt“ lesen.

Citrix ADC/ Netscaler Full-VPN mit Client Choices

Neben der Nutzung des ADC als Load Balancer und Content Switch oder Gateway für Virtual Apps and Desktops, bietet die Lösung auch die Möglichkeit echtes SSL VPN zu implementieren.

Falls ein bestehender Gateway Virtual Server konfiguriert ist, kann dieser mit wenigen Schritten oft um ein wahlweises SSL VPN erweitert werden.

Voraussetzungen

  • Netscaler Gateway Virtual Server muss im Smart Access Modus sein („IcaOnly = false“)
  • Es müssen ausreichend Universal Licenses vorhanden sein, für alle Verbindungen zu diesem Gateway Virtual Server

Einbau in ein bestehendes Gateway

Am einfachsten lässt sich das Full-VPN in ein bestehendes Gateway implementieren, wenn man über eine Gruppenmitgliedschaft einem teil der Benutzer die selektive Auswahl des Full VPN als Alternative zum Virtual Apps and Desktops anbiete. Hierzu gibt es idealerweise in der LDAP Policy des Gateways eine funktionierende Group Extraction. Der ADC wird dann beim Login eines Benutzers versuchen LDAP Gruppenmitgliedschaften auf ADC Gruppenmitgliedschaften (hier: CitrixFullVPN) zu übersetzen.

add aaa group CitrixFullVPN

An diese Gruppe können wir nun den gewünschten Client IP-Bereich für das VPN binden und eine entsprechende Policy, welche die Benutzerauswahl („-Client Choices ON“) einblendet und die VPN Funktion zusätzlich konfiguriert:

add vpn sessionAction AC_VPN -splitDns REMOTE -splitTunnel OFF -transparentInterception ON -defaultAuthorizationAction ALLOW -SSO ON -ssoCredential PRIMARY -icaProxy OFF -wihome "https://store.mycompany.de/Citrix/StoreWeb" -ClientChoices ON -ntDomain mycompany -clientlessVpnMode OFF -iconWithReceiver OFF
add vpn sessionPolicy PL_VPN-classic ns_true AC_VPN
bind aaa group CitrixFullVPN -intranetIP 192.168.1.0 255.255.255.0
bind aaa group CitrixFullVPN -policy PL_VPN-classic -priority 100

Bei der Konfiguration kann über die Parameter „-splitTunnel“ und „-splitDns“ angegeben werden, ob der komplette Traffic in den Tunnel geleitet werden soll oder nur ein Teil des Traffics. Eine ähnliche Konfiguration ist für DNS möglich. Im obigen Beispiel, wird der komplette Traffic nach dem VPN Verbindungsaufbau in den Tunnel geleitet und DNS Remote, also über den Netscaler abgewickelt.

Routing

Es ist theoretisch möglich die Full VPN Funktionalität ohne einen zusätzlichen Adressbereich zu nutzen, der Netscaler lässt dann alle Clients per Übersetzungstabelle über die SNIP kommunizieren. In der Praxis hat sich gezeigt, das einige Backendsysteme damit nicht klarkommen und der Traffic außerdem in einer Firewall selektiver behandelt werden kann, wenn ein zusätzlicher Adressbereich genutzt wird. Zu diesem Adressbereich wiederum wird dann über die bestehende SNIP des Netscalers geroutet. Es ist also auf einer zentralen Firewall oder einem Gateway eine Route analog dem folgenden Beispiel zu konfigurieren:

route add 192.168.1.0 255.255.255.0 <NetscalerSNIP>

Benutzeransicht

Login
„Client Choices“ Abfrage
Netscaler Gateway Plugin

Weitere Möglichkeiten

Das Netscaler Gateway Plugin beherrscht neben den klassischen primären und sekundären Faktoren auch die Anzeige der Netscaler NFactor Faktoren/ eines Flows im Plugin und kann somit auch damit kombiniert werden.

Die Verbindungen innerhalb des VPNs können mittels Authorization Policies pro Benutzer oder Gruppe eingeschränkt werden.

Citrix Dokumentation:

Full VPN setup on Citrix Gateway

PreLogin VPN über NetScaler

Always On before logon Funktion des Netscaler Gateway

Inzwischen dürfte sich rumgesprochen haben, das über die Netscaler Gateway Funktion des Netscalers nicht nur ein Zugriff auf ein XenDesktop realisiert werden kann, sondern auch Web-Applikationen und ein vollwertiges SSL VPN integriert werden können. 

Weitaus weniger bekannt ist, dass mit der Version 11.1 der Netscaler Firmware zur SSL VPN Funktion eine Always On Funktion bzw. jetzt zusätzlich noch eine „Always on service“ Funktion hinzugekommen ist. 

Bisher konnten sich Benutzer an einem Notebook anmelden um dann eine Netscaler Gateway Verbindung aufzubauen und dann gesteuert über ein Session Profile ein Full VPN aufbauen.  

Die bisherige Funktion konnte prinzipbedingt einige Situationen nicht abdecken: 

  • Benutzer startet das Notebook außerhalb des Unternehmensnetzes und benötigt Support bei der VPN/ Gateway Anmeldung. 
  • Ein Benutzer wechselt mit einem eingeschalteten Gerät aus dem VPN (z.B. Internet Cafe/ Homeoffice etc.) in das Unternehmensnetz oder will mit einem Gerät transparent weiterarbeiten welches vorher im Unternehmensnetz war. 
  • Das Unternehmen möchte den Netzwerkzugriff bei abgebautem VPN kontrollieren. 
  • Neue Benutzer ohne Cached Credentials müssen sich am mobilen Gerät anmelden. 
  • Das Notebook soll bereits vor dem Windows Logon im Netz sein um es mit Policies oder Softwareverteilung zu versorgen. 

Wie funktioniert der Always on Service bzw. die neue Funktion „Always on before logon“? 

Die Always On Funktion verbindet ein mobiles Endgerät mit einem VPN Endpunkt, mit dem es zuvor manuell verbunden wurde. 

Abhängig davon ob sich das mobile Endgerät im Unternehmensnetz oder „on the road“ befindet, wird die VPN Verbindung automatisch auf und abgebaut. 

Die Funktion „always on before logon“ wird über den „Always on service“ realisiert (Ablauf im Modus „Always on sErvcie with a user persona“): 

  • Nach dem Einschalten des Geräts wird eine Verbindung, der „Machine level tunnel“ zum Netscaler Gateway mit einem Device Zertifikat aufgebaut 
Alwayson with user personal flow

(Bild von Citrix) 

  • Der  Benutzer meldet sich mit seinem AD Benutzer an das Gerät an 
  • Nach der Anmeldung wird der Benutzer ggf. nach seinem zweiten Faktor befragt und nach erfolgreicher Verifizierung der „Machine Level tunnel“ durch einen „User level Tunnel ersetzt“ 
  • Wenn der Benuter sich abmeldet wird der „User Level Tunnel“ wieder durch den „Machine level tunnel“ ersetzt 

Ob und welcher Tunnel aufgebaut ist, lässt sich bei einem gesperrten Gerät über die Sign-In Options sehen (service mode= Machne level tunnel): 

Windows credential manager screen

(Bild von Citrix) 

Wie funktioniert die normale „Always on“ Funktion ? 

Sollte keine primäre Netzwerkverbindung vorhanden sein, wartet der Always on Service im Hintergrund auf den Verbindungsaufbau. 

Nach der neuen „always on before logon“ Funktionalität greift die bereits länger vorhandene „always on“ Funktion. 

Durch ein Always On Profile auf dem Netscaler kann kontrolliert werden, ob die VPN Verbindung aufgebaut bleiben soll, wenn das Gerät sich im Unternehmensnetzwerk („Location based VPN“) befindet oder was passieren soll wenn kein VPN Tunnel aufgebaut werden kann („Network Access on VPN Failure)“. Über das Setting „Full Access“ kann normaler Netzwerkzugriff und logon an jedem anderen Netscakler Gateway als Backup freigeschaltet werden. 

Citrix ADC vpx 
Configuration X 
@ https:// 
10.20.lO.lOO 
/menu/n 
Citrix ADC vpx (3000) 
Reporting 
HA Status 
Primary 
Documentation 
Ill \ 
Partition v 
default 
Downloads 
nsroot 
Dashboard 
Configuration 
O Configure AlwaysON Profile 
Name 
aonprof_mwde 
Location Based VPN* 
Remote 
Client Control* 
ALLOW 
Network Access On VPN Failure* 
Full Access 
OK 
Close

(Bild von br/ MWDE) 

Systemanforderungen 

AlwaysOn service Windows version Citrix ADC and Windows VPN plug-in version 
Always on service without a user persona Windows 7 and later No recommendation on specific Citrix ADC version. VPN plug-in must be version 13.0.36.xx and later or 12.1.53.xx and later. 
Always on service with a user persona Windows 8 and later Citrix ADC and VPN plug-in must be version 13.0.41.xx and later. 
   

Aus https://docs.citrix.com/en-us/citrix-gateway/13/vpn-user-config/alwayson-service-for-windows.html  

„The expression is_aoservice is valid from Citrix Gateway version 13.0 build 41.20 and later.“ 

Aus https://docs.citrix.com/en-us/citrix-gateway/13/vpn-user-config/alwayson-service-for-windows/alwayson-before-logon-with-a-user-persona.html 

Welche Schritte sind zur Konfiguration von „Always on service with a user persona“ notwendig? 

  1. Für ein bestehendes Netscaler Gateway  muss ein Authentication Profile mit einem neuen AAA Authenticationserver 
    erzeugt werden (sofern noch kein Netscaler N-Factor im Einsatz ist) 
  2. Es muss eine EPA Policy hinzugefügt werden welche auf „is_aoservice“ prüft und die Action „sys.client_expr(“device-cert_0_0”)“ triggert (Binden mit Prio 100).  
  3. Es muss eine EPA Policy hinzugefügt werden welche auf „is_aoservice.not“ prüft den Actiontyp „No_AUTHN“ hat (Binden mit Prio 110)  
    als „Next Factor“ wird eine LDAP Authentication Policy hinterlegt. 

Weiterführende Links: 

Grundlegende Always On Funktion: 

https://docs.citrix.com/en-us/citrix-gateway/13/vpn-user-config/alwayson.html

Neue Always On Servcie / before Logon Funktion: 

https://docs.citrix.com/en-us/citrix-gateway/13/vpn-user-config/alwayson-service-for-windows.html

Konfiguration der „before Logon Funktion“: 

https://docs.citrix.com/en-us/citrix-gateway/13/vpn-user-config/alwayson-service-for-windows/alwayson-before-logon-with-a-user-persona.html

EPA mit Device Zertifikation: 

https://docs.citrix.com/en-us/citrix-gateway/13/device-certificate-in-nfactor-as-an-epa-component.html

Kriegsschauplatz Internet

Ein reißerischer Betreff, durchaus, aber wer regelmäßig einschlägige Branchennews konsumiert, der wird sicher festgestellt haben, dass die Zahl der „Online-Einbrüche“ und „Datendiebstähle“, oder zumindest die Berichterstattung darüber, seit einigen Monaten erheblich gestiegen ist. Vielleicht ist dies nur ein subjektiver Eindruck, aber selbst in den non-IT Medien waren Namen bekannter Opfer zu lesen, wie dem FBI, dem BKA, sämtlichen Sparten der Sony Gruppe und weiteren.

Gestohlen wurden u.a. geheime und vertrauliche Dokumente, Konto- und Adressdaten samt Passwörtern und was sonst nicht niet- und nagelfest war und als halbwegs interessant galt.

Neuerdings trifft es scheinbar auch vermehrt die weniger großen Unternehmen und Organisationen. Von der Handelskette Rewe war z.B. zu hören. Von den allgegenwärtigen DDoS-Attacken, die getreu ihrem Namen lediglich Dienste und Online-Angebote zeitweise zum Erliegen bringen, ganz zu schweigen.

Eine Web Application Firewall (kurz: WAF) ist eine gute Möglichkeit Erste Hilfe leisten zu können oder proaktiv Einbrüchen vorzubeugen. Sie arbeitet auf Applikationsebene (Layer 7) und kann somit Anfragen und Antworten auswerten und verändern. Eine Filterung ist sowohl mit Positiv- als auch mit Negativlisten möglich und es gibt verschiedene weitere Möglichkeiten bekannte Angriffe zu verhindern.

Die Lösung kann so z.B. auch eine Prüfung auf gültige Kreditkartennummern durchführen, um gezielt eine Übertragung dieser Daten nach außen zu verhindern. SQL Injections und CrossSiteScripting Angriffe können direkt in den Paketen durch harmlosen Code ersetzt werden. Die Manipulation von Formularen wird durch das Einfügen eines versteckten Feldes wirksam verhindert und bekannte Angriffsmuster können durch vom Hersteller gelieferte Signaturdateien erkannt werden.

Im einfachsten Fall werden beispielsweise nur Zugriffe über gelernte Positivlisten (vorher durchgeführte gutartige Requests) durchgelassen – eine sehr elegante Möglichkeit Web Applikationen sicherer zu machen. So haben wir zum Beispiel mit dem Citrix Netscaler ein starkes Werkzeug zur Hand, mit dem wir Web Applikationen absichern (und beschleunigen) können und der in der Platinum Edition auch noch eine vollständige Web Application Firewall mit hybridem (positiv und negativ kombinierbar) Sicherheitsmodell enthält.

Eine WAF filtert wirkungsvoll, an vorderster Front – prinzipiell sollte ein IT-System aber auch ohne so einen Filter sicher sein (Programmierung und Konfiguration). Aber wie immer gibt es keinen 100%-igen Schutz – und wenn es nur durch Insider-Wissen oder Social Engineering erlangte Zugriffswege sind, die „ganz normal“ die Systeme nutzen. Daher ist es für uns alle wichtig zu überlegen, wem wir welche Daten geben und wo wir sie lagern/bereitstellen.

Autoren: Thiemo Noack, Benjamin Rodewald