Danke an Julian Jakob (@jakob_davidson) für den Hinweis, dass die hier vorgestellte Lösung leider nur mit dem Browser funktioniert — mit der Citrix Workspace App nicht. Ich werde in den nächsten Tagen meinen ADC auf 13.1 aktualisieren und mich dann mit AAA auf dem ADC beschäftigen; danach folgt eine Erweiterung dieses Beitrags. Vorab habe ich einen Workaround ans Ende gestellt, damit die Anmeldung auch via Workspace- bzw. Receiver-App funktioniert.

In einem meiner letzten Projekte hatte ich Berührung mit Microsoft 365 und im Speziellen mit Azure Conditional Access. Dabei kam mir die Idee, die Microsoft-Authentifizierung auch für meine OnPremise-Farm mit Citrix Virtual Apps and Desktops zu verwenden. Erst vor wenigen Tagen war ich von meiner selbst gebastelten Google-Authenticator-Lösung auf die komfortablere von privacyIDEA gewechselt; den Anstoss dazu gab mir Julian Mooren mit seinem Blogpost.

Auch wenn diese Lösung schnell implementiert war, bringt eine SAML-Authentifizierung via Azure AD einige Vorteile mit sich — deswegen war schnell klar, dass das die nächste Aufgabe wird. Für die Umsetzung habe ich auf einige bestehende Anleitungen im Internet zurückgegriffen. Leider war keine davon hundertprozentig mit meinem Setup kompatibel, oder die eingesetzten Features passten nicht zu meinen Lizenzen. Anpassen musste ich sowohl Cloud- als auch OnPremise-Elemente.

Als OnPremise-Komponenten habe ich einen Citrix ADC Standard VPX 200 in Version 12.1 sowie eine CVAD-Umgebung 1912 CU3 eingesetzt. Auf Azure-Seite nutze ich eine Azure AD Premium P1-Lizenz. (Dass die zum Anlegen einer Enterprise Application nötig ist, glaube ich nicht — aber Conditional Access und damit auch MFA gibt es nur mit einem Premium-P1-Plan.)

Ich beginne am besten mit den Einstellungen im Azure Active Directory. Ich gehe davon aus, dass ihr bereits Azure AD Connect im Einsatz habt und eure Benutzer von OnPremise in die Cloud synchronisiert werden. Ist das nicht der Fall, müsst ihr diesen Schritt vorher nachholen — sonst klappt das Single Sign-on (SSO) nicht.

  1. Als Erstes legen wir im Azure Active Directory eine neue Enterprise Application an. Hierzu klicken wir auf den Punkt „New Application“.

    Im nächsten Menüpunkt suchen wir nicht nach einer Applikation, sondern wählen oben „Create your own Application“.
    Hier vergeben wir einen Namen für unsere Enterprise App. Auf Basis des Namens sucht Microsoft nach vorhandenen Applikationen — diese Vorschläge ignorieren wir. Wir prüfen, ob der Punkt „Integrate any other application you don’t find in the gallery“ ausgewählt ist, und klicken auf Create.

    Nachdem die Applikation erstellt wurde, könnt ihr als nächsten Schritt Benutzer hinzufügen oder das SSO konfigurieren. Wir konfigurieren natürlich zuerst das SSO: Hierzu klicken wir auf „Single sign-on“ und anschließend auf SAML.
    Nun müssen wir den 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. Letztere entspricht der URL eures OnPremise-NetScalers; ihr hängt lediglich „/cgi/samlauth“ an. Die Einstellungen unter Punkt 2 können so bleiben, hier muss nichts angepasst werden.
    In Punkt 3 ladet ihr das Base64-Zertifikat herunter, damit ihr es später auf dem ADC importieren könnt. Es dient der Verifizierung zwischen Azure AD und Citrix ADC.
    Als Nächstes sichern wir die Daten unter Punkt 4 in eine Textdatei, damit wir sie später auf unserem ADC eingeben können.
    Jetzt wird es Zeit, einen Benutzer oder eine Gruppe zu unserer App hinzuzufügen. Der Benutzer darf kein nativer Azure-AD-Benutzer sein, sondern muss aus einem OnPremise-Active-Directory stammen.
    Damit wären wir in der Cloud fertig. Die Details zu Azure Conditional Access lassen sich im Nachgang noch anpassen.
  2. Citrix ADC. Nun kommen wir zur ersten OnPremise-Komponente dieses Aufbaus. Wir melden uns am Management-Interface des Citrix ADC an.

    Nun navigieren wir zu Traffic Management → SSL → Certificates → Server Certificates und klicken dort auf Install.

    Hier wählt ihr das aus Azure heruntergeladene Zertifikat aus und ladet es hoch.

    Das Zertifikat findet sich anschließend unter „Unknown Certificates“ — es kann 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: Die Login URL entspricht der Redirect URL, die Logout URL der Single Logout URL. Bei mir waren beide identisch, ich habe aber auch schon Setups gesehen, in denen sie sich unterschieden. Bei IDP Certificate Name wählt ihr das eben hochgeladene Zertifikat, bei Signing Certificate Name euer Citrix-Gateway-Zertifikat, und bei Issuer Name gebt ihr die URL an, über die euer Citrix Gateway erreichbar ist. Mit einem passenden Zertifikat und weiteren Anpassungen könnt ihr natürlich auch ein zweites Citrix Gateway bereitstellen, das ausschließlich für die SAML-Authentifizierung zuständig ist. Abschließend klickt ihr auf Create und erstellt damit den Server.Nun erstellen wir noch eine einfache SAML-Policy, die wir für die Authentifizierung im Gateway verwenden. Dazu klicken wir unter Policies auf Add, wählen den eben erstellten Server aus und geben als Expression „ns_true“ ein.
    Danach wechseln wir unter Citrix Gateway → Virtual Servers in die Konfiguration unseres Gateways. Unter Authentication entfernen wir zunächst die bestehenden Primär- und Sekundärmethoden und fügen anschließend über das Plus-Zeichen eine neue hinzu.

    Anschließend binden wir die Policy an den vServer; mit Close wird die Konfiguration für die Laufzeit des NetScalers übernommen. Dauerhaft speichern müsst ihr sie über das Diskettensymbol rechts oben in der Ecke.
  3. FAS-Server (OnPremise). Vielleicht sollte ich zuerst etwas zur grundsätzlichen Funktion erzählen: Ein FAS-Server ist ein Authentifizierungsprovider für den StoreFront. Dazu arbeitet er eng mit der Windows Certificate Authority zusammen, indem er für Benutzer Zertifikate erstellt, die als virtuelle Smartcards verwendet werden können. Mit diesen Zertifikaten wird auf VDA-Seite das Single Sign-on realisiert. Durch FAS kann der StoreFront viele Authentifizierungsmethoden nutzen — die bekannteste 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. Sie ist ziemlich ausführlich und weist auf einige Stolpersteine hin. Wichtig zu erwähnen ist das Erstellen einer GPO nach der Installation des FAS: Diese GPO teilt den VDAs und dem StoreFront mit, welcher FAS-Server verwendet werden soll. Legt ihr keine GPO an oder verlinkt sie nicht, wird euer SSO fehlschlagen. Auf ein weiteres Problem bin ich beim Erstellen der Regel gestoßen. Dort gibt es einen Dialog, in dem man den StoreFronts erlauben muss, die eben erstellte Regel zu lesen und zu verarbeiten. In der Standardkonfiguration steht hier „Authenticated Users“ — allerdings auf Deny. Da ein Computerobjekt natürlich auch ein Authenticated User ist, war das Verbot in dem Moment höherwertig und die StoreFronts konnten die Regel nicht anwenden.

    Ansonsten verliefen Installation und Einrichtung der Zertifikate ziemlich problemlos. Problematisch kann es noch beim Deployment der Zertifikatsvorlagen oder beim Autorisieren des Dienstes werden: Beides benötigt entsprechende Rechte auf dem Zertifikatsserver, die in einem Active Directory mit striktem Rechtekonzept nicht immer gegeben sind.
</div>
  1. Finaler Test. Wir öffnen unsere Citrix-Gateway-URL — wenn wir alles richtig gemacht haben, erscheint anstelle des Citrix-Gateway-Logins ein Microsoft-Login.
    Hier meldet ihr euch mit eurer E-Mail-Adresse und dem Passwort aus dem AD an. Habt ihr MFA bzw. Conditional Access aktiviert, wird das nach der Passworteingabe ebenfalls abgefragt.

    Habt ihr diese Hürde überstanden, begrüßt euch der StoreFront mit der Auswahl eurer Apps und Desktops.

    Bei einem sauberen Single-Sign-on-Prozess solltet ihr beim Starten eines Desktops oder einer Anwendung keine erneute Passwortabfrage erhalten — damit ist auch die Funktion des FAS geprüft. Alternativ könnt ihr auf der CA nachsehen, ob für den Benutzer ein Smartcard-Zertifikat ausgestellt wurde.
  2. Workaround für die Workspace App. In dieser Variante funktioniert die Anmeldung via Workspace App leider nicht mehr, weil die App mit dem SAML-Redirect nicht klarkommt — dafür wäre AAA auf dem ADC nötig. Als Workaround passe ich die SAML-Policy so an, dass sie nur im Browser greift, und füge für die Workspace App eine klassische LDAP-Authentifizierung hinzu. Zunächst öffnen wir unter Citrix Gateway → Policies → Authentication → SAML unsere Policy. Wir entfernen das ns_true, ersetzen es durch REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver und speichern mit OK.Nun wechseln wir auf den vServer des Citrix Gateways und fügen über das Plus-Symbol die vorher entfernte LDAP-Policy wieder hinzu. Unterscheidet ihr in der LDAP-Policy nicht nach User-Agent, müsst ihr sie ebenfalls anpassen — hier ein Beispiel, wie meine aussieht. Wichtig: Die Priority muss niedriger sein als die der SAML-Policy.

    Danach gibt es zwei primäre Authentifizierungsmethoden.
    Durch diese Weiche in den Policies läuft der SAML-Aufruf im Browser Richtung Azure AD, während die Workspace App die klassische LDAP-Authentifizierung verwendet.

    Das war’s fürs Erste. Ich hoffe, du konntest meiner Anleitung folgen. Wenn du Probleme hast oder etwas unklar ist, zögere nicht und kontaktiere mich. Ansonsten viel Spaß beim Nachbauen.