Write a comment

Kürzlich hat mir einer meiner Kunden eine Aufgabe zur Lösung gegeben: "Können wir uns gegen das Netscaler Gateway nur mit Benutzernamen und Security Token authentifizieren, von einem nicht Domänenmitglied und dann Zugriff auf eine volle Citrix ICA Sitzung bekommen?"

Genau hier kommt der Citrix Federated Authentication Service zur Rettung!

Der Kunde möchte, dass Angestellte kennwortfrei arbeiten und der Grund warum in der Firma nur SmartCards mit allen Domänenmitgliedern verwendet werden. Die Firmengeräte haben kein Problem damit, von extern Zugriff auf das interne Netzwerk zu bekommen. Was ist aber mit privaten Geräten? Für diesen Fall bekommen Benutzer einen Security Token und weiter nichts. In der Vergangenheit mussten Benutzer mindestens einmal das Kennwort am WebInterface eingeben und dann speichern.

Das ist meiner Meinung nach ein gutes Beispiel, und ich glaube, dass andere Citrix Kunden die gleichen oder ähnlichen Anforderungen haben. Bevor ich auf die Anwendungsfälle zurückkomme, sollten wir erst einen Blick auf die Funktionsweise des Citrix Federated Authentication Service werfen.

 

Citrix Federated Authentication Service

Zum besseren Verständnis halte ich es einfach mit den Erklärungen. FAS ist ein Windows Dienst, der Smart Card Class Zertifikate (vSmartCards) im Namen des Active Directory Benutzers erstellen kann. Um das zu können muss der Dienst bei der eigenen internen privaten Zertifikatsstelle (CA) autorisiert werden. Der Federated Authentication Service interagiert primär mit Citrix StoreFront, wobei andere Komponenten wie Netscaler, DDC und VDA auch beteiligt sind, jedoch nicht die Wichtigkeit haben. Die erstellte vSmartCard wird dann zum Ziel VDA Server gesendet, wie früher das NFuse Ticket. Da FAS alle privaten Schlüssel der erstellten Benutzer vSmartCards hält, muss das System abgesichert werden, mit eingeschränktem Zugriff auch für Administratoren.

 

FAS Setup

FAS ist Bestandteil des XenApp/XenDesktop Media seit der Version 7.9. Das Deployment von FAS ist einfach, besonders mit vollen administrativen Rechten auf die private CA. Citrix rät, keinen Server zu verwenden auf den anderen Citrix Komponenten installiert sind, noch einen Server auf dem bereits Port 80 verwendet wird z.B. IIS. Einfach das Setup starten, was einen Windows Dienst und eine Konsole installiert. Die FAS Konsole unbedingt ausführen als Administrator (runas) ausführen, ansonsten wird die weitere Konfiguration fehlschlagen. Es müssen drei Aufgaben erledigt werden, um das Setup abzuschließen:

  1. Upload (Import) Zertifikatvorlagen in die private CA
  2. Hinzufügen der Vorlagen in die CA und
  3. Autorisation des FAS Server zur Erstellung der Zertifikate und dies muss auf dem CA Server genehmigt werden.

1 und 2 geht über remote PoSh und sollte kein Problem sein.

Sind alle Aufgaben "Grün", dann muss eine Microsoft Gruppenrichtlinie gesetzt werden die den FQDN und Sitzungseinstellungen des FAS Server definieren. Die Richtlinie muss dann auf VDA, DDC und den FAS Server selbst zugewiesen werden. Mit der Konfiguration geht es nicht weiter, solange die Richtlinie noch nicht gegriffen hat. Sollte das System die Richtlinie nicht haben, dann ist Folgendes im Event-Log zu finden: No User Credential Service configured. Apply the "Citrix User Credential Service Group" Policy Object

 

Benutzer Regeln / ACL

Hauptsächlich muss die Security Access Control List (ACL) gesetzt werden. Als Standard sind alle Computer für StoreFront und VDA's verboten. Es müssen alle beteiligten Computer mit "erlaubt" hinzugefügt werden und alles, was verboten ist, muss entfernt werden. Das ist alles.

 

FAS Konfiguration

Dies ist der knifflige Teil, da aktuell nicht alles dokumentiert ist und schon gar nicht für alle möglichen Szenarien. Das Grundkonzept und die Architektur für einige Fälle sind in den Citrix eDocs zu finden (https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-14/secure/federated-authentication-service/fas-architectures.html), wie Nutzung von ADFS für eine B2B Lösung usw. aber keine exakten Details wie diese zu Konfigurieren sind, weder für Netscaler noch StoreFront. Es gibt nur eines, das sicher ist: Die Benutzer müssen sich mit dem User Principal Name (UPN) anmelden, ansonsten kann FAS keine vSmartCards erstellen.

 

StoreFront FAS Plug-In

Momentan kann FAS nicht in der StoreFront Konsole aktiviert werden und muss über PoSh gemacht werden. Ich empfehle hier einen eigenen Store wie "FAS" zu erstellen. In den PoSh Befehlen wird dann der Pfad Citrix/FASAuth verwendet. Dies modifiziert die web.conf Datei in dem Ordner und wird auch in einem StoreFront Cluster repliziert. So lauten die PoSh Befehle mit einem Store der "FAS" benannt wurde:

& “$Env:PROGRAMFILES\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1”

$siteId = 1
$storeVirtualPath = “/Citrix/FAS”
$authenticationVirtualPath = “/Citrix/FASAuth”

# Use FAS
Set-DSClaimFactoryName –siteId $siteId –virtualPath $authenticationVirtualPath –factoryName “FASClaimsFactory”
Set-DSVdaLogonDataProviderName –SiteId $siteId –VirtualPath $storeVirtualPath –VdaLogonDataProviderName “FASLogonDataProvider”

 

FAS Anwendungsfälle

Es sind sehr unterschiedliche Szenarien möglich, die sehr komplex werden können, aber alle Fälle sind letztlich für den Zugriff auf eine vollständige Citrix ICA/HDX Sitzung. Das bringt mich zurück an den Anfang des Artikels, aber nicht unbedingt zum ersten Anwendungsfall.

Was ich als ersten Einsatz für FAS sehe, ist das einfache Domänen Pass-Through mit StoreFront. Wird Domänen Pass-Through im StoreFront aktiviert, dann ist dies nur für Receiver für Web (RfW) aber nicht für den Ziel VDA Server. Damit das dann auch geht, muss der lokale Receiver mit Administratorrechten installiert werden, damit SSO registriert werden kann. Dann muss SSO noch per GPO konfiguriert werden und geht am Ende doch nicht, weil weitere "Credential Providers", die geladen wurden, die Funktion verhindern. Alles in allem nicht unbedingt einfach und fehlerfrei.

Mit FAS einfach den SSO Teil von Receiver vergessen! Keine admin Installation, keine Receiver Konfiguration für SSO! Nicht vergessen, dies erfordert einen Client in der Domäne und RfW muss in der Intranet Zone des Internet Explorers sein.

Zurück zu dem "Nur Token" Anwendungsfall, ein gutes Beispiel für FAS. Nehmen wir an, alle Beschäftigten im Unternehmen verwenden SmartCards und kennen ihr Active Directory Kennwort nicht. Wenn Mitarbeiter von zu Hause arbeiten und dabei kein Gerät des Unternehmens verwenden, wie können diese sich authentifizieren ohne Kennwort? Token Authentifizierung mit UPN als Benutzername ist alles, was mit FAS notwendig ist. Dies gibt Mitarbeitern ein kennwortfreies und doch sicheres Arbeiten innerhalb- wie außerhalb des Unternehmens.

 

FAS Verbesserungen

FAS wird und sollte durch Citrix weiterentwickelt werden und dabei meine nicht nur FAS, sondern wichtiger die Integration mit StoreFront und Netscaler. StoreFront braucht bessere Frontend Fehlermeldungen (immer nur Anforderung kann nicht abgeschlossen werden hilft nicht), FAS als Authentifizierungsoption in der Konsole. Netscaler sollte in den Profilen für Session FAS Optionen für SSO haben. FAS selbst solle ein "Facelift" der Konsole bekommen und bessere Fehlermeldungen, Tracing und Log Funktionalität.

abgesehen davon arbeitet FAS sehr stabil und ist einfach zu konfigurieren. Identity Management wird immer wichtiger, und FAS ist eine Brücke, um Benutzern Zugang zu einer HDX Sitzung zu ermöglichen.

 

Mein Dank geht an Andrew Innes (FAS) und sein Team sowie an Simon Frost (StoreFront)  

Gib hier deinen Kommentar ein...
oder als Gast kommentieren
Lade Kommentar... Der Kommentar wird aktualisiert nach 00:00.

Schreibe den ersten Kommentar.