Azure AD SAML Authentifizierung an Citrix Virtual Apps & Desktops onPremise

Last Updated on 14. Oktober 2021 by Sebastian

Danke an Julian Jakob (@jakob_davidson) und sein Hinweis das die hier vorgestellte Lösung leider nur mit dem Browser funktioniert. Mit der Citrix Workspace App funktioniert diese Variante nicht. Ich werde in den nächsten Tagen mein ADC auf 13.1 aktualisieren und mich dann mit AAA auf dem ADC beschäftigen. Danach gibt es dann eine erweiterung dieses Posts. Vorab habe ich ein Workaround ans Ende des Posts gepackt damit die Anmeldung auch via Workspace/Receiver App funktioniert.

In einem meiner letzten Projekte hatte ich Berührung mit Microsoft 365 und im speziellen mit Azure Conditional Access. Dabei ist mir in den Sinn gekommen die Microsoft Authentifizierung für meine onPremise Citrix Virtual Apps und Desktops Farm zu verwenden. Vor wenigen Tagen habe ich erst von meiner selbst gebastelten Google Authenticator Lösung gewechselt auf eine komfortablere Lösung von PrivacyIDEA. Den Anstoss für diese Lösung gab mir Julian Mooren mit seinem Blogpost.

Auch wenn diese Lösunge schnell implementiert war würde eine SAML Authentifzierung via Azure AD einige Vorteile mit sich bringen und deswegen war schnell klar das dies die nächste Aufgabe wird. Für die Implementierung der Lösung habe ich auf einige bestehenden Anleitungen im Internet zurückgegriffen. Leider war aber keine der Anleitungen 100% Kompatibel zu meinem Setup bzw. die eingesetzten Features waren nicht mit meinen zur Verfügung stehenden Lizenzen kompatibel. Für die Implementierung musste ich Cloud sowie OnPremise Elemente anpassen.

Als Komponenten OnPremise habe ich ein Citrix ADC Standard VPX 200 Version 12.1 eingesetzt sowie eine Citrix 1912 CU3 CVAD Umgebung. Im Bereich Azure habe ich eine Azure AD Premium P1 Lizenz (Ob diese benötigt wird für eine Enterprise Applikation anzulegen glaube ich nicht, aber das Conditional Access und damit verbunden auch MFA ist nur mit einem Premium P1 Plan möglich)

Ich Beginne am besten mit den Einstellungen im Azure Active Directory. Ich gehe jetzt einfach mal davon aus ihr bereits einen bestehenden Azure AD Connect im Einsatz habt und ihre User entsprechend von OnPremise in die Cloud Sync’nd. Sollte dem nicht der Fall sein müsst ihr diesen Schritt noch vorher tun. Ansonsten klappt das Single SignOn(SSO) nicht.

1. Als erstes legen wir uns im Azure Active Directory eine neue Enterprise Applikation an. Hierzu klicken wir auf den Punkt „New Application“.
   
   Im nächsten Menüpunkt suchen wir nicht nach einer Applikation sondern wählen oben aus „Create your own Application“
   Hier vergeben wir einen Namen für unsere Enterprise App. Auf Basis des Names sucht Microsoft evtl. vorhandene Applikationen. Wir ignorieren in diesem Fall die Vorschläge. Prüfen ob der Punkt „Integrate any other application you don’t find in the gallery“ ausgewählt und klicken auf Create.
   
   Nachdem nun die Applikation für euch erstellt wurde habt ihr die Möglichkeit als nächsten Schritt User hinzuzufügen oder das SSO zu konfigurieren. Natürlich konfigurieren wir als erstes das SSO. Hierzu klicken wir auf den Punk „Single sign-on“ und anschließend auf den Punkt SAML.
   Nun müssen wir die Identifier sowie die Reply URL festlegen. Hierzu klicken wir im ersten Abschnitt auf „Edit“
   Hier legen wir die Entity ID sowie die Reply URL fest. Diese entspricht eurer onPremise Netscaler URL. Bei der Reply URL fügt ihr noch „/cgi/samlauth“ hinzu. Die Einstellungen unter Punkt 2 können so bleiben. Hier muss nichts angepasst werden.
   In Punkt 3 ladet ihr das Base64 Zertifikat runter damit ihr es später auf dem ADC importieren könnt. Es dient zur Verifizierung zwischen AzureAD und Citrix ADC.
   Als nächstes sichern wir uns die Daten unter Punkt 4 in eine Textdatei damit wir sie auf unseren ADC später eingeben können.
   Jetzt wird es Zeit einen Benutzer oder eine Gruppe zu unserer App hinzuzufügen. Der Benutzer darf kein nativer Azure AD User sein sondern muss von einem onPremise Active Directory stammen.
   Damit wären wir in der Cloud soweit fertig. Weitere Anpassungen im Detail bzgl. Azure Conditional Access können im Nachgang dann noch angepasst werden.
2. Citrix ADC. Nun kommen wir zur ersten OnPremise Komponente bei diesem Aufbau. Wir loggen uns auf dem Citrix ADC Management Interface ein.
   
   Nun navigieren wir auf den Punk Traffic Management -> SSL -> Certificates -> Server Certificates und klicken dort auf Install
   
   Hier wählt ihr nun das von euch aus Azure runtergeladene Zertifikat und ladet es hoch.
   
   Das Zertifikat wird anschließend unter „Unknown Certificates“ zu finden sein. Kann aber trotzdem verwendet werden.
   Nun öffnet ihr den Menüpunkt Citrix Gateway – > Policies -> Authentication -> SAML. Dort legen wir unter Servers einen neuen Server an.
   Nun benötigt ihr die im Azure AD Portal notierten URLs. Dabei entspricht die Login URL der Redirect URL und die Logout URL der Single Logout URL. Bei mir waren beide URLs identisch. Allerdings habe ich auch schon Setups gesehen in denen dies unterschiedlich waren. Bei IDP Certificate Name wählt ihr euer eben hochgeladenes Zertifikat. Bei Signing Certificate Name benötigt ihr euer Citrix Gateway Zertifikat und bei Issuer Name gebt ihr noch die URL an über die euer Citrix Gateway erreichbar ist. Natürlich könnt ihr mit einem entsprechenden Zertifikat und weiteren Anpassungen auch ein weiteres Citrix Gateway bereitstellen das nur für SAML Authentifizierung zuständig ist. Abschliessend klickt ihr auf Create und erstellt damit den Server.Nun erstellen wir noch eine einfache SAML Policy die wir für unsere Authentifizierung im Gateway verwenden können. Dazu klicken wir unter Policies auf Add, wählen unseren eben erstellen Server aus und geben als Expression „ns_true“ ein.
   Danach wechseln wir in die Konfiguration unseres Citrix Gateways unter Citrix Gateway – Virtual Server und wählen dort unser Citrix Gateway aus. Unter Authentification entfernen wir zuerst bestehende Primary und Secondary Authentifications und fügen anschließend eine neue Methode über das Plus zeichen hinzu.
   
   Anschließend binden wir die Policy an den vServer und mit einem close speichern wir die Konfiguration für die Laufzeit des Netscalers. Wollt ihr die Konfiguration persistent machen müsst ihr noch das Diskettensymbol rechts oben in der Ecke betätigen.
   
3. Nun machen wir weiter mit dem FAS Server ( OnPremise ). Vielleicht sollte ich erst etwas zur grundsätzlichen Funktion des FAS Server erzählen. Ein FAS Server stellt ein Authentifizierungsprovider für den Storefront dar. Hierzu arbeitet der FAS Server eng mit der Windows Certificate Authority zusammen in dem er für User Zertifikate erstellt die für virtuelle Smartcards verwendet werden können. Mit diesen Zertifikaten wird auf der VDA Seite dann das Single Sign On realisiert. Durch die Verwendung von FAS ist es dem Storefront möglich viele Authentifizierungsmethoden zu verwenden. Die bekannteste dabei ist SAML.Für mich war es die erste installation eines FAS Servers.Ich bin dabei nach der Anleitung von  Carl Stahlhood ( Filling gaps in EUC vendor documentation ) vorgegangen. Diese ist ziemlich ausführlich und weist auch auf einige Stolpersteine hin. Wichtig hier zu erwähnen wäre auch das erstellen einer GPO nachdem installieren des FAS. Diese GPO teilt den VDAs, sowie auch dem Storefront mit welchen FAS Server verwendet werden soll. Legt ihr keine GPO an bzw. verlinkt eine erstellte GPO nicht wird euer SSO fehlschlagen. Ein weiteres Problem auf das ich gestoßen bin war beim erstellen der Regel. Hier gibt es ein Dialog wo man seine Storefronts den Zugriff erlauben muss diese eben erstellte Regel auch lesen und verarbeiten zu dürfen. Hier steht in der Standardkonfiguration „Authenticated Users“ drin aber auf Deny. Da ein Computerobjekt natürlich auch ein Authenticated User ist war der Verbot in dem Moment höherwertig und die Storefronts konnten die Regel nicht anwenden.
   
   Ansonsten verlief die Installation und die Einrichtung der Zertifikate ziemlich Problemlos. Problematisch kann es evtl. aber noch beim Deployment der Zertifikatsvorlagen werden oder auch beim Autorisieren des Dienstes. Beides benötigt entsprechende rechte auf dem Zertifikats Server die evntl. bei einem entsprechenden Active Directory mit Rechtekonzept nicht gegeben sind.
4. Kommen wir zu unserem finalen Test. Hierzu öffnen wir unsere Citrix Gateway URL und wenn wir alles richtig gemacht haben sollte anstatt dem Citrix Gateway Login ein Microsoft Login erscheinen.
   Hier meldet ihr euch nun mit eurer Email Adresse und Passwort entsprechend euren AD Daten an. Solltet ihr noch MFA aktiviert haben bzw. Conditional Access dann wird nach der Passworteingabe natürlich dies auch noch abgefragt.
   
   Habt ihr diese Hürde überstanden, sollte euch der Storefront begrüssen mit der Auswahl eurer zur Verfügung stehenden Apps und Desktops.
   
   Bei einem sauberen Single Sign On Prozess solltet ihr nun beim starten eines Desktops oder einer Anwendung keine erneute Passwort abfrage erhalten. Damit wäre auch die Funktion des FAS entsprechend geprüft. Alternativ könnt ihr auch noch prüfen ob für den User auch ein SmartCard Zertifikat ausgestellt wurde auf der CA.
   
5. Leider funktioniert in der Variante die Anmeldung via Workspace App nicht mehr. Da die App nicht mit dem SAML redirect klar kommt. Hierzu wird AAA auf dem ADC benötigt. Als Workaround hierfür passe ich die SAML Policy an das diese nur auf Browserebene funktioniert und füge eine klassische LDAP Authentifizierung für die Workspace App hinzu.Zunächst editieren wir unter Citrix Gateway – > Policies -> Authentication -> SAML unsere Policy in dem wir Sie anklicken und öffnen. Wir entfernen das ns_true und ersetzen es durch REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver und speichern diese Konfiguration mit OKNun wechseln wir auf den Vserver des CItrix Gateway und fügen über das + Symbol die LDAP Policy die wir vorher noch entfernt haben wieder hinzu. Solltet ihr in der LDAP Policy nicht unterscheiden beim User-Agent müsst ihr diese auch noch anpassen. Hier ein Beispiel wie meine LDAP Policy aussieht. Wichtig ist auch das die Priority nidriger ist wie die der SAML Policy.
   
   Nachdem ihr dies Angepasst habt. Sollt es dann zwei Primäre Authentifizierungsmethoden geben.
   Durch die weiche in den Policys ist es nun möglich das via Browserder SAML-aufruf Richtung AzureAD läuft während die Workspace App die klassische LDAP Authentifizierung verwendet.

   Das wars fürs erste. Ich hoffe du konntest meiner Anleitung etwas folgen. Wenn du Probleme hast oder etwas nicht verstehst. Zögere nicht und kontaktiere mich. Ansonsten wünsche ich euch noch viel Spass beim nachbauen.