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:
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)
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 StartbildschirmErstellen 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 erzeugtDazu kommen noch NAT Gateways und Elastic IPs
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.
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 type
Deployment type
Standalone entitlements
Citrix App Delivery and Security Service – Citrix Managed
Trial entitlements
Citrix App Delivery and Security Service – Citrix Managed
Pooled SaaS Bundle entitlements
Citrix App Delivery and Security Service – Citrix Managed
Entitlements
Edition type
Entitled to
Advanced
300 TB bandwidth + 25 million DNS queries
Advanced
1200 TB bandwidth + 100 million DNS queries
Advanced
4800 TB bandwidth + 500 million DNS queries
Advanced
2000 TB bandwidth + 2 billion DNS queries
Premium
300 TB bandwidth + 25 million DNS queries
Premium
1200 TB bandwidth + 100 million DNS queries.
Premium
4800 TB bandwidth + 500 million DNS queries
Premium
2000 TB bandwidth + 2 billion DNS queries
Entitlements / Pakete
Es wird voraussichtlich auch zusätzliche DNS Pakete geben.
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.
Nachdem wir uns in Teil 1 und Teil 2 der Serie „VerSAMLung“ mit Webapplikationen beschäftigt haben, betrachten wir in Teil 3 die Anbindung von Citrix Virtual Apps and Desktops (CVAD) mit Azure Active Directory Anmeldung. Da auch hier kein Kennwort vorliegt, welches für ein Single Sign on genutzt werden könnte und der Storefrontserver kein KCD unterstützt, kommt eine weitere Citrix Komponente „Citrix Federated Authentication Service“ (FAS), welche eine virtuelle Smartcard Anmeldung am Citrix Desktop ermöglicht zum Einsatz.
Dies ermöglicht dem User ein einmaliges Anmelden an seinem Azure AD integriertem Notebook und danach ohne weitere Passworteingabe direkt auf Citrix CVAD zuzugreifen.
Editieren der Default Rule auf dem Citrix FASStorefront Server BerechtigungenVDA Berechtigungen (in dieser kleinen Testumgebung haben wir keine spezielle Ausnahme gemacht)Benutzer Berechtigungen (Auch hier dürfen alle Benutzer die Regel nutzen)
FAS integration für den Storefront Store aktivieren (Per Powershell auf dem Storefrontserver ausführen, dabei Storenamen anpassen):
Als nächstes muss nun überprüft werden ob die entsprechenden Authentication Methods aktiviert sind. Hierbei ist darauf zu achten, dass unter „Pass-through from Citrix Gateway“ der Haken unter „Configure Delegated Authentication“ gesetzt ist:
Authentication MethodsDas Setzen des Hakens veranlasst den Storefront komplett dem Gateway zu vertrauen für die Anmeldedaten. Hierfür ist dann allerdings ein sog. Callback erforderlich, den wir im nächsten Schritt konfigurieren.Es sollte später geprüft werden, ob die Callback URL eingetragen und auch von den Storefrontservern erreichbar ist. Wichtig: das Gateway/ Callback -RL Zertifikat muss dabei vom Storefront als Vertrauenswürdig betrachtet werden, sonst funktioniert der Callback nicht.
Einrichtung Gateway Virtual Server auf dem ADC
Als nächstes muss man das Citrix Gateway konfigurieren. Wenn noch kein Gateway existiert kann mit dem Wizard eins mit Standard Settings erstellt werden:
Erstellen des Citrix Gateway via Wizard
Name, VIP, FQDN und Port festlegen
Zertifikat anbinden
zu Testzwecken haben wir ein selbst signiertes Zertifikat genommen (welches wir auch auf dem Storefront als vertrauenswürdig hinzugefügt haben)
Als Primäre Authentication haben wir Radius genommen (entfernen wir später wieder), andernfalls läuft der Wizard nicht weiter. Dann wählen wir das Portaltheme aus.
Die Anbindung von CVAD erfolgt im Abschnitt „Applications“. Auf Add Applications klicken um die Applikationen hinzuzufügen.
in unserem Fall wählen wir XenApp & XenDesktop (der neue Name scheint im Wizard noch nicht angekommen) und wählen als Integrationspunkt den Storefront aus.
Storefront URL und STA Adresse hinzufügen
Mit Done wird der Wizard geschlossen und das Gateway ist gebaut.
Einrichtung Enterprise Application im Microsoft Azure Portal
Auch hier benötigen wir wieder eine Enterprise Applikation in Azure AD wie in Teil 1 schon beschrieben.
Gateway/ SAML SP Konfiguration auf dem ADC
Nun entfernen wir die Dummy Radius Policy, die wir mit dem Wizard erstellt haben.Statt der Radius Policy legen wir jetzt einen AAA Virtual Server an, an den wir die SAML Policies binden und den wir später selber in Netscaler N-Factor Manier per Authentication Profile an das Gateway binden.
add authentication vserver aaamwdemo SSL 0.0.0.0
Zertifikat an den AAA Virtual Server binden (tritt hier nicht äußerlich in Erscheinung, muss aber vorhanden sein).
Die „Redirect“ und die „Single Logout Url“ sind bei unserem Beispiel (Microsoft Azure AD) gleich und können den Settings der Enterprise Application im Azure entnommen werden („Reply URL“ und „Single Sign On Url“).
Dort laden wir uns ebenfalls das „SAML Signing“ als „Certificate (Base64)“ herunter und fügen es auf dem ADC als „IDP Certificate“ über den Knopf „Add“ hinzu (siehe nächster Screenshot).
Das EA Feld „Identifier“ im Azure und das Feld „Issuer“ auf dem ADC müssen den gleichen Text String enthalten, wir haben die URL/den FQDN des SAML-SP verwendet.
Nach Citrix Best Practices muss zur Absicherung eine Relaystate Regel konfiguriert werden (vergl. Citrix Application Delivery Controller and Citrix Gateway – SAML Configuration Reference Guide): https://support.citrix.com/article/CTX316577
bind authentication vserver aaamwdemo -policy pol_AzureSSOHapp-Citrix-ADC-CVAD -priority 100 -gotoPriorityExpression NEXT
Im nächsten Schritt legen wir ein Authentication Profile an, welches die AAA Settings zusammenfasst und die Bindung an das Gateway ermöglicht.Im Profil wird der AAA Virtual Server verknüpft.Die Domain kann leer gelassen werden oder wenn der Cookie von verschiedenen Virtual Servern genutzt werden soll, die übergeordnete Domain angegeben werden.
Über den Punkt „Authentication Profile“ wird das Profil an den Gateway Virtual Server gebunden. Hinweis: Das Objekt sollte danach nicht mehr mit dem Wizard bearbeitet werden.
Dem aufmerksamen Betrachter sind vielleicht die SSL Settings des Gateways aufgefallen. Diese sind so vom Wizard erzeugt worden und nur für eine Testumgebung einzusetzen. Für den produktiven Einsatz wären diese anzupassen (z.B. SSL abschalten, Perfect Forward Secrecy implementieren, aktuelles Cipherset erstellen).
Test der fertigen Konfiguration
Wenn man sich nun von einem nicht Azure AD integrierten Gerät anmelden würde, erschiene je nach Azure Conditional Access Konfiguration ggf. einfach die Azure Anmeldeseite und/oder die Tokenabfrage auf dem Mobiltelefon und danach die Storefront oder RFWEBUI Oberfläche, von der aus man die Applikationen starten kann.
Wenn sich der User an einem Azure AD integrierten Gerät anmeldet, ist er danach direkt am Azure AD angemeldet. Greift er dann auf den ADC zu , wird er dort über die Vertrauensbeziehung zwischen ADC als SAML SP und Azure AD als SAML IDP direkt angemeldet und kann die Applikationen starten.
Wie im Folgenden Video zu sehen ist nur die Anmeldung am Notebook/ Desktop erforderlich, alles weitere erfolgt über Single Sign On:
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 NetScaler 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 SPNKerberos 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:
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
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 – 1Log Erfolg – 2 Log Erfolg – 3Log Erfolg – 4Log Erfolg – 5Log Erfolg – 6Log Erfolg – 7
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 NetScaler 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)
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.
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…).
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
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
add authentication vserver aaademo SSL 0.0.0.0
Ein SSL Zertifikat muss gebunden werden, auch wenn der AAA Vserver nicht direkt angesprochen wird.
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).
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.
Das Thema ist aktuell in aller Munde. Die IT scheint sich auch mit nichts anderem zu beschäftigen, als Home Office. Ressourcen sind überlastet, die eigene Infrastruktur im Rechenzentrum bietet nicht genügend Freiraum, alle Arbeitsplätze von heute auf morgen virtuell abzubilden. Muss sie auch nicht!
Das ist die Stunde für eine Technologie, die Citrix schon lange im Portfolio, aber bisher immer ein Schattendasein geführt hat. Citrix Remote-PC.
In diesem Video wird anschaulich erklärt, was diese Technologie leisten kann.
Citrix Remote PC
Machen Sie ihre PC Arbeitsplätze Home Office-Ready und ermöglichen Sie damit ihren Mitarbeiter*innen, sicher über das Web von zu Hause aus mit ihren gewohnten Desktops zu verbinden. Wenn schon Citrix im Einsatz ist, kann eine Einbindung sehr einfach in die bestehende Infrastruktur erfolgen. Für Newbies kann ein schneller Einstieg über Cloud-Dienste von Citrix eine Option sein.
Für die Techies gibt es auch noch mal eine wunderbare Übersicht, wie das funktioniert.
Sprechen Sie uns an, wir unterstützen Sie gerne bei der Einführung, Beratung und Support.
Wir haben schon lange in etlichen internen Runden darauf gedrängt, und auch die ersten positiven Signale (natürlich streng vertraulich) bereits im Sommer zurückbekommen. Und jetzt ist es endlich offiziell: Citrix lockert die SSL-VPN Lizenzierung auf. Bisher konnten wir trotz der Investition in Citrix NetScaler Standard oder Enterprise Lizenzen nur 5 Concurrent User SSL-VPN nutzen. Weitere User mussten separat per NetScaler Gateway Universal Licenselizenziert werden oder aus XenApp / XenDesktop Platinum übernommen werden. Einzig die NetScaler Platinum Lizenz hat 100 CCU SSL-VPN mitgebracht.
Wie schon angekündigt gibt es einige Neuigkeiten rund um die neue NetScaler 11.1 Firmware. Für das neue NetScaler Management and Analytics System (MAS) habe ich mir ein paar Tage in unserem DemoCenter und unserer Lab-Umgebung gegönnt.
Wie schon angekündigt gibt es einige Neuigkeiten rund um die neue NetScaler 11.1 Firmware. Für das neue NetScaler Management and Analytics System (MAS) habe ich mir ein paar Tage in unserem DemoCenter und unserer LAB Umgebung gegönnt.
Doch zuerst wollen wir noch einen Blick auf die bisher verfügbaren Werkzeuge rund um den NetScaler Betrieb werfen.
Citrix hat im Dezember XenMobile 10.3 angekündigt. Wir haben es getestet und es gibt einige grundlegenden Veränderungen. Sowohl das gesamte Webinterface und die Aufteilung der einzelnen Themenreiter wurde überarbeitet als auch einige Troubleshooting-Möglichkeiten, die bislang nur sinnvoll über die CLI möglich waren, sind nun ins Webinterface integriert worden.
Es wurde zudem die Top-Bar überarbeitet, in der sich nun die Kategorien „Analyze“, „Manage“ und „Configure“ – in der deutschen Version diesmal auch übersetzt mit „Analysieren“, „Verwalten“ und „Konfigurieren“ – sowie die Settings für den Server selbst über ein Zahnrad-Icon befinden. Neben den Server-Settings ist ein Schraubenschlüssel-Icon zu sehen, welches zu den Support-/Troubleshooting-Funktionen und -Links führt.
Desweiteren sind im Support-Menü nun Links zu den Citrix-Docs, dem APNS-Signing-Tool etc. dazugekommen.
Es wurden einige Reporting-Funktionen mit *.csv-Export hinzugefügt, sodass die XenMobile-Datensätze für Reports auch als kommaseparierte Rohdaten bereitgestellt werden können.
Auch die Benutzerverwaltung wurde nun in den Top-Bar-Reiter „Verwalten“ integriert.
ShareFile hat einen eigenen Unterpunkt in der Nav-Bar bekommen, hat allerdings keine weiteren Konfigurationsparameter spendiert bekommen.
Unter „Einstellungen“ >> „Mobilfunkanbieter“ ist es nun möglich, ActiveSync-Geräte-/Vorgänge abzufragen.
Der durch iOS 9.2 aufgetretene Fehler bezüglich des APNS & nicht funktionierender Push-Notifications ist in XenMobile 10.3 noch durch einen Workaround umgangen, wurde mittlerweile allerdings auch durch das iOS-Update 9.2.1 durch Apple behoben.
Alles in allem wird XenMobile auf Administrationsseite dadurch deutlich benutzerfreundlicher und bietet mehr Möglichkeiten hinsichtlich der Dateiauswertung. Durch den CSV-Export können so relativ schnell Inventurlisten etc. erstellt werden, ohne händisch alle Parameter pflegen zu müssen.
