Table of Contents
Aktualisierung auf die neuste Cloud Navigation.
Als Folge der zunehmenden Projekte gibt es hier ein kleines How To mit den folgenden Punkten:
- Azure AD Seamless Single Sign-On (PTA / PHS)
- SAML Authentifizierung (Azure AD als IdP & NetScaler Gateway als SP)
- Citrix Federated Authentication Service (FAS)
- Microsoft Azure Multi-Factor-Authentication mit Conditional Access
Voraussetzungen
- Voll funktionsfähige Citrix Virtual Apps and Desktop Umgebung (Mindestens StoreFront & DDC Version 7.9)
- NetScaler (Citrix ADC) mit funktionsfähiger Basiskonfiguration & aktivierter Enterprise oder Platinum Lizenz (Minimum Version 12.1 Build 50+ für native Workspace App & für Browser Zugriff Minimum Version 11.1)
- Konfigurierter Unified Gateway vServer
- Interne und externe DNS Einträge für Unified Gateway vServer (z.B. citrix.deyda.net)
- Zertifikate für DNS Einträge (am einfachsten sind Wildcard-Zertifikate)
- Bestehender Azure Tenant mit Azure-AD Basiskonfiguration (Domain, AAD Sync) & aktivierter Azure AD Premium-Lizenz
- Installierte & Konfigurierte AD Connect Version (Minimum Version 1.1.644.0)
- Firewall Freigabe für *.msappproxy.net auf Port 443
- Domänen Administrator Zugangsdaten für die Domänen, die sich über Azure Connect mit Azure AD verbinden
- Installierte Authenticator App auf dem Test User Mobilgerät
Azure AD Seamless SSO (PTA / PHS)
Ausführlichere Hintergrundinformationen zu dem Thema sind hier zu finden.
Aktivierung Seamless SSO – AD Connect
Nun wird gezeigt, wie Pass-through Authentication oder Password Hash Synchronization aktiviert werden kann. Für die Verwendung von Seamless SSO ist nur ein Feature erforderlich.
Aktivierung Pass-through Authentication
Um die Pass-through authentication zu aktivieren, stellt eine Verbindung zu dem AD-Mitglied her, auf dem AD Connect installiert ist.
- Startet Azure AD Connect
- Klickt auf Configure im Welcome Screen
- Klickt nun auf Change user sign-in und bestätigt dies mit Next
- Gebt die Anmeldedaten des Global Administrator ein und bestätigt die Eingabe mit Next
- Möglicherweise wird wegen einer MFA Einrichtung eine weitere Anmeldemaske angezeigt
- Wählt Pass-through authentication und dann Enable single sign-on aus.
- Bestätigt dies mit Next
- Unter Single single-on klickt auf Enter credentials
- Gebt im folgenden Fenster die Anmeldedaten eines lokalen Domänen Administrators ein und klickt auf OK
- Klickt auf Configure um die beschriebenen Aktionen durchzuführen
- Bestätigt die erfolgreiche Ausführung im Fenster Configuration complete mit Exit
Activating Password Hash Synchronization
Um die Password Hash Synchronization zu aktivieren, stellt eine Verbindung zu dem AD-Mitglied her, auf dem AD Connect installiert ist.
- Startet Azure AD Connect
- Klickt auf Configure im Welcome Screen
- Klickt nun auf Change user sign-in und bestätigt dies mit Next
- Gebt die Anmeldedaten des Globalen Administrators ein und bestätigt die Eingabe mit Next
- Möglicherweise wird wegen einem eingerichteten MFA eine weitere Anmeldemaske angezeigt
- Wählt Password Hash Synchronization und dann Enable single sign-on aus
- Bestätigt dies mit Next
- Unter Single single-on klickt auf Enter credentials
- Gebt im folgenden Fenster die Anmeldedaten eines lokalen Domänen Administrators ein und klickt auf OK
- Klickt auf Configure um die beschriebenen Aktionen durchzuführen
- Bestätigt die erfolgreiche Ausführung im Fenster Configuration complete mit Exit
Lokale Active Directory
Im lokalen Active Directory ist nun ein neues Computerobjekt mit dem Namen AZUREADSSOACC zu finden. Dieses Objekt sollte vor dem Löschen geschützt werden.
Azure Portal
Im Azure Portal können nun die aktivierten Seamless SSO Methoden geprüft werden.
- Meldet euch mit Administrativen Credentials am Azure Portal an
- Im Azure Portal klickt auf Azure Active Directory
- Klickt dann auf Azure AD Connect
- Klickt im AAD Connect auf Connect Sync
- Nun klickt auf die eingerichtete Seamless SSO Methode (Seamless single sign-on oder Pass-through authentication), die über Azure AD Connect aktiviert wurde
Unter Seamless single sign-on können die mit Password Hash Synchronization aktivierten Domänen geprüft werden.
Bei der Pass-through authentication, wird ein Warnsymbol angezeigt, da der Agent nur auf einem Server gespeichert ist.
Laut Microsoft soll dies auf 3 interne Server verteilt werden.
Gruppenrichtlinien
Damit Seamless SSO auf den Endgeräten funktionieren kann, müssen noch einige Einstellungen über GPOs verteilt werden.
- Stellt eine Verbindung zu einem Computer, mit der installierten Group Policy Management Console, her.
- Fügt nun die folgenden Einstellungen zu einer bestehenden oder neuen GPO hinzu
- In der GPO, geht nach User / Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page
- Editiert die Site to Zone Assignment List mit den folgenden Werten
| Value Name | Value |
|---|---|
| login.microsoftonline.com | 3 |
| aadg.windows.net.nsatc.net | 1 |
| autologon.microsoftazuread-sso.com | 1 |
| secure.aadcdn.microsoftonline-p.com | 1 |
Hinweis:
Wenn Seamless SSO für einzelne Gruppen oder Benutzer deaktiviert werden soll, muss die GPO für diese Personen auf den Wert 4 gesetzt werden.
- Dann geht auf den GPO Pfad User / Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone
- Setzt die Einstellung Allow updates to status bar via script auf Enabled
Erneuerung des Kerberos Decryption Key
Microsoft empfiehlt, den Kerberos Decryption Key mindestens alle 30 Tage zu erneuern. Dadurch wird die Gefahr des Ausspionierens des Kerberos Decryption Key reduziert. Microsoft arbeitet an der Einführung einer automatisierten Funktion zur Erfüllung dieser Aufgabe.
Um den Kerberos Decryption Key des AZUREADSSOACC Computer Kontos zu erneuern, muss zunächst das Azure AD PowerShell-Modul aus der PowerShell Galerie heruntergeladen werden.
- Startet PowerShell als Administrator auf dem Computer, auf dem AD Connect installiert ist, und führt den folgenden Befehl aus:
|
1 |
Install-Module MSOnline |
- Navigiert zum Pfad C:\Program Files\Microsoft Azure Active Directory Connect und importiert das Modul AzureADSSO.psd1
- Führt den Befehl New-AzureADSSOAuthenticationContext aus
- Gebt im folgenden Fenster die Anmeldedaten eines Azure-Administrators ein.
- Führt dann Get-AzureADSSOStatus aus. Dadurch wird geprüft, welche Domänen im Seamless SSO Tenant gespeichert und aktiviert sind.
- Führt dann den Befehl $passwd = Get-Credential und gebt im folgenden Fenster die Anmeldedaten eines lokalen Domänen Administrators ein.
- Führt schließlich den folgenden Befehl aus, um die Aktualisierung des Decryption Key des AZUREADSSOACC Computer Kontos abzuschließen.
|
1 |
Update-AzureADSSOForest -OnPremCredentials $passwd |
Dies muss für alle Domänen geschehen, die für Seamless SSO konfiguriert sind.
SAML Authentifizierung (Azure AD als IdP & Citrix Gateway als SP)
Weitere Hintergrundinformationen zu diesem Thema sind hier zu finden.
Active Directory
Wenn nicht der gleiche UPN in Azure AD und im lokalen Active Directory verwendet wird, muss dieser noch angepasst werden.
- Öffnet dazu das Tool Active Directory Domains and Trusts
- Klickt im Tool mit der rechten Maustaste auf das oberste Element (Active Directory Domains and Trusts) und klickt auf Properties
- Gebt im folgenden Fenster unter Alternative UPN suffixes die gewünschte Domain (z.B. deyda.net) ein und bestätigt die Eingabe über Hinzufügen
- Überprüft, ob der Domainname korrekt eingegeben wurde und bestätigt dies mit OK
- Jetzt kann der UPN der benötigten Benutzer massenweise oder manuell bearbeitet werden, um der Azure-AD Domäne zu gleichen
Azure Active Directory
Um unseren zukünftigen Service Provider anzubinden, muss jetzt eine Enterprise application im Azure Active Directory erstellt werden.
- Um das Azure Active Directory zu konfigurieren, ruft Azure Portal auf
- Im Azure Navigation Panel, klickt auf Azure Active Directory
- Im Azure Active Directory Fenster, klickt auf Enterprise applications
- Nun klickt auf New application
- Und klickt oben auf Create your own application
- Im folgenden Fenster den Namen der Enterprise app eingeben und die Checkbox neben Integrate any other application you don’t find in the gallery (Non-gallery) auswählen
- Mit Create bestätigen
- Wartet auf die Erstellung der Anwendung. Informationen erhält man über das Element Notifications am oberen Rand
- Nach erfolgreicher Erstellung der Anwendung, wird man zur Overview Seite der Anwendung weitergeleitet
- Wenn dies nicht geschieht, einfach über Azure Active Directory > Enterprise applications > All applications die gerade erstellte neue Anwendung (z.B. CVAD) suchen und anklicken
- In der Enterprise application klickt auf Single sign-on oder auf 2. Set up single sign on
- Unter Select a single sign-on method klickt auf SAML
Das folgende Fenster konfiguriert die Kommunikation zwischen dem Identity Provider und dem Service Provider.
- Klickt auf das Stift Icon in der oberen Ecke vom Bereich 1, um die Basic SAML Configuration durchzuführen
- Gebt folgendes ein:
- Identifier (NetScaler Gateway Adresse, z.B. https://citrix.deyda.net)
- Reply URL (NetScaler Gateway Adresse mit /cgi/samlauth, z.B. https://citrix.deyda.net/cgi/samlauth)
- Relay State (NetScaler Gateway Adresse mit /CitrixAuthService/AuthService.asmx, z.B. https://citrix.deyda.net/CitrixAuthService/AuthService.asmx)
- Bestätigt die Eingabe mit Save
Hinweis !
Die Felder unter Identifier und Reply URL erscheinen erst nach einem klick auf die Add identifier / Add reply URL Links.
- Die Einstellungen im Bereich 2 Attributes & Claims können im bestehenden Standard bleiben
Hinweis !
Die Einstellungen in Attributes & Claims kann editiert werden, wenn nicht der Azure AD UPN an die lokale Umgebung übergeben werden soll, sondern ein alternatives Attribut genutzt werden soll, indem der lokale Anmeldenamen gespeichert wurde.
- Ladet unter SAML Signing Certificate (Bereich 3) das Certificate (Base64) für den Service Provider (NetScaler) herunter
Hinweis !
Der NetScaler kann auch per Metadata URL, in der Enterprise Application heisst diese App Federation Metadata Url, konfiguriert werden. Da ich persönlich nur Probleme damit hatte, empfehle ich die manuelle, hier beschrieben Methode.
Hinweis !
Das SAML Signing Certificate ist 3 Jahre gültig und muss daher rechtzeitig erneuert werden. Anleitung ist unter Erneuern des SAML Zertifikats zu finden.
- Kopiert aus Bereich 4 (Set up OnPrem CVAD) die angezeigten URLs (Login URL, Azure AD Identifier & Logout URL) in eine lokale Datei
Damit Benutzer die SAML-Authentifizierung für Citrix verwenden können, müssen diese der Anwendung zugeordnet werden.
- Klickt auf Users and groups
- Nun klickt auf Add user/group
- Wählt nun die Benutzer aus der Liste aus, denen der Zugriff gewährt werden soll (oder wählt alle Benutzer aus) und bestätigt dies mit Assign
- Ich habe nur einen Test Benutzer (Test User 01) dafür autorisiert
NetScaler
Schließlich muss der NetScaler (Citrix ADC) für die Kommunikation mit dem Identity Provider (Azure-AD) konfiguriert werden.
- Ruft die Admin Weboberfläche des NetScaler auf und navigiert zu Traffic Management > SSL > Certificates > Server Certificates
- Klickt dort auf Install, um das zuvor heruntergeladene Zertifikat der Unternehmensanwendung zu importieren
- Gebt das folgende ein und bestätigt dies mit Install
- Certificate-Key Pair Name (Eindeutiger Name für das SAML-Signaturzertifikat, z.B. SAML-Azure-AD)
- Certificate File Name (Heruntergeladenes Signatur-Zertifikat, z.B. Citrix FAS.cer)
- Das installierte Zertifikat ist nicht unter Server oder Client Certificates zu finden, sondern unter Unknown Certificates
- Navigiert dann nach Security > AAA – Application Traffic > Virtual Servers um die SAML Authentication Policy und den Authentication vServer zu erstellen
- Unter Authentication Virtual Servers, klickt auf Add um den neuen vServer zu erstellen
- Nun gebt folgendes ein:
- Name (Name des vServer, z.B. Azure-AD_auth_VS
- IP Address Type (Non Addressable)
- Klickt auf OK
- Im folgenden Wizard klickt auf No Server Certificate um ein Server Zertifikat anzubinden (nicht das IdP Zertifikat !)
- Klickt auf Click to select
- Wählt das Server Zertifikat aus (z.B. Wildcard Zertifikat) und klickt auf Select
- Klickt auf Bind
- Wenn das Zertifikat gebunden ist (1 Server Certificate) klickt Continue
- Unter dem Menü Eintrag Advanced Authentication Policies klickt auf No Authentication Policy
- Klickt auf Add unter Select Policy
- Gebt das folgende ein:
- Name (Name der Authentication Policy, z.B. saml_auth_pol)
- Action Type (SAML)
- Expression (HTTP.REQ.IS_VALID)
- Klickt auf Add neben Action
- Konfiguriert nun den Authentication SAML Server mit den folgenden Werten:
- Name (Name des SAML Authentication Server, z.B. saml_auth_server)
- IDP Certificate Name (Zertifikat von der Azure-AD Anwendung, z.B. SAML Auth)
- Redirect URL (Anmelde URL von der Azure AD Anwendung, z.B. https://login.microsoftonline.com/…/saml2)
- Single Logout URL (Anmelde URL aus der Azure-AD Anwendung, z.B. https://login.microsoftonline.com/…/saml2)
- Signing Certificate Name (Server Zertifikat des Citrix Gateway, z.B. Wildcard Zertifikat)
- Issuer Name (Bezeichner / Identifier aus der Azure Enterprise App, z.B. https://citrix.deyda.net)
- Reject Unsigned Assertion (Off)
Hinweis !
Wenn die Konfiguration automatisch geschehen soll, muss das Häkchen neben Import Metadata ausgewählt werden und in dem dann erscheinenden Fenster muss die vorher kopierte App Federation Metadata Url hinterlegt werden.
- Klickt auf More und editiert noch die folgenden Einstellungen:
- Signature Algorithm (RSA-SHA256)
- Digest Method (SHA256)
- Bestätigt die Eingaben mit Create
- Prüft die Eingaben und bestätigt diese mit Create
- Unter Policy Binding prüft die Eingaben und ändert die folgende Einstellung:
- Goto Expression (END)
- Bestätigt dies wiederum mit Bind
- Wenn die Authentication Policy angebunden ist klickt auf Continue und Done
Um die Konfiguration auf dem NetScaler abzuschließen, muss nur noch die neu erstellte SAML Authentication Policy an unseren Gateway Virtual Server gebunden werden.
- Um dies zu tun, navigiert nach NetScaler Gateway > Virtual Servers
- Wählt den in StoreFront für FAS konfigurierten Gateway vServer aus (z.B. https://citrix.deyda.net = UG_VPN_ug_10.0.0.8_443) und klickt auf Edit
- Unbind aller LDAP oder RADIUS authentication Policies vom vServer
- Klickt auf die ausgewählten Policies unter Basic Authentication (z.B. 1 LDAP Policy)
- Wählt die Policies aus und klickt auf Unbind
- Bestätigt das folgende Fenster mit Yes
- Prüft, dass weder unter Basic Authentication noch unter Advanced Authentication eine Policy gebunden ist
- Klickt auf der rechten Seite unter Advanced Settings auf Authentication Profile
- Klickt auf Add unter Authentication Profile
- Gebt einen Namen (z.B. saml_auth_profile) unter Create Authentication Profile ein und klickt auf Click to select unter Authentication Virtual Server
- Wählt den vorher erstellten Authentication Virtual Server (Azure-AD_auth_VS) aus und klickt auf Select
- Bestätigt die Eingaben mit einem klick auf Create
- Klickt auf OK und auf Done
- Navigiert nach NetScaler Gateway > Global Settings um dort die single sign-on domain zu entfernen
- Klickt auf Change Global Settings
- Löscht den eventuellen Eintrag unter Single Sign-on Domain
- Gegebenenfalls müssen die Richtlinien des Gateway vServer auch bezüglich Single Sign-on-Domain angepasst werden
Hinweis !
Wenn NetScaler 13.1 (getestet aktuell mit Build 12.51) verwendet wird und das Single Sign-on Domain Feld unter Global Settings gefüllt ist, funktioniert die Konfiguration aktuell nicht.
Unter NetScaler 13.1 wird in der Session Policy das Override Global nicht gespeichert, wenn das Feld leer ist. Dies wird aber so für die SAML Auth benötigt.
Also muss unter 13.1 die Globale Setting bereinigt werden und geprüft werden, das in den Session Policies des Gateway vServer kein Override Global unter Single Sign-on Domain hinterlegt wurde. Bitte vorher bei eventuell vorhandenen anderen Gateway vServern prüfen, das die per Global Setting für dieses Feld nicht benötigt wird und wenn, diese in die angebundenen Session Policies eintragen.
- Des weiteren muss die Richtlinien des Gateway vServer auch bezüglich Session Time-out angepasst werden
- Dieser Wert muss kleiner sein als der Timeout Wert des angebundenen Stores in StoreFront
CLI Befehle
Das Zertifikat muss zunächst über WinSCP auf die NetScaler Appliance hochgeladen werden. Es muss unter dem Pfad /nsconfig/ssl/ abgelegt werden.
|
1 2 3 4 5 6 7 8 9 |
add ssl certKey <idp-certificate-name> -cert <idp-certificate> add authentication vserver <auth-vserver-name> SSL bind ssl certkey <auth-vserver-name> <wildcard-certificate-name> add authentication samlAction <saml-auth-server-name> -samlIdPCertName <idp-certificate-name> -samlRedirectUrl <redirect-url-idp> -samlSigningCertName <wildcard-certificate-name> -logoutURL <logout-url-idp> -samlIssuerName <issuer-name-idp> -samlRejectUnsignedAssertion OFF -signatureAlg RSA-SHA256 -digestMethod SHA256 add authentication Policy <auth-policy-name> -rule HTTP.REQ.IS_VALID -action <saml-auth-server-name> bind authentication vserver <auth-vserver-name> -policy <auth-policy-name> -priority 100 -gotoPriorityExpression END unbind vpn vserver <gateway-name> -policy <ldap-policy-name> unset tm sessionparameter -ssoDomain unset vpn sessionAction <gateway-session-profile-name> -ntdomain |
Beispiel:
|
1 2 3 4 5 6 7 8 9 |
add ssl certKey SAML_Azure_AD -cert Citrix_FAS.cer add authentication vserver Azure-AD_auth_VS SSL bind ssl certkey Azure-AD_auth_VS Wildcard201904 add authentication samlAction saml_auth_server -samlIdPCertName SAML-Azure-AD -samlRedirectUrl https://login.microsoftonline.com/.../saml2 -samlSigningCertName Wildcard201904 -logoutURL https://login.microsoftonline.com/.../saml2 -samlIssuerName https://citrix.deyda.net -samlRejectUnsignedAssertion OFF -signatureAlg RSA-SHA256 -digestMethod SHA256 add authentication Policy saml_auth_pol -rule HTTP.REQ.IS_VALID -action saml_auth_server bind authentication vserver Azure-AD_auth_VS -policy saml_auth_pol -priority 100 -gotoPriorityExpression END unbind vpn vserver UG_VPN_SAML-UG -policy 10.0.0.4_LDAP_pol unset tm sessionparameter -ssoDomain unset vpn sessionAction AC_OS_10.0.0.8 -ntdomain |
Wenn die Authentication Policies nicht bekannt sind. Diese können wie folgt herausgefunden werden. Es werden ebenfalls die Session Policies angezeigt.
|
1 |
show vpn vserver <gateway-name> |
Beispiel:
|
1 |
show vpn vserver UG_VPN_SAML-UG |
Jetzt wo die Session Policies bekannt sind, können die Session Profiles angepasst werden.
|
1 |
show vpn sessionaction |
Citrix Federated Authentication Service (FAS)
Zertifizierungsstelle
Als Nächstes muss eine Microsoft PKI-Umgebung erstellt werden, wenn es diese in der Domäne noch nicht gibt. Macht dies auf dem Rechner, der als Zertifizierungsstelle dienen soll. In meinem Beispiel ist es der Domänen Controller selbst.
- Dazu geht in den Server Manager und klickt auf Add Roles and Features
- Klickt durch den Wizard bis zum Punkt Server Roles und wählt Active Directory Certificate Services aus
- Bestätigt die Auswahl mit Add Features
- Klickt dann in den Registerkarten Server Roles, Features und AD CS auf Next
- Unter Role Services wählt folgende Punkte aus:
- Certification Authority
- Certification Authority Web Enrollment
- Falls Pop-up Fenster mit zusätzlichen Features erscheinen, bestätigt diese ebenfalls mit Add Features
- Startet die Installation mit einem klick auf Install
- Klickt auf den Notifications Bereich im Server Manager
- Klickt dort auf Configure Active Directory Certificate Services
- In der folgenden Konfiguration können die Standardeinstellungen mit Next bestätigt werden
- Im folgenden Fenster Certification Authority auswählen und mit Next bestätigen
- Definiert eure Konfiguration und bestätigt die einzelnen Punkte mit Next
- Von mir genutzte Konfiguration:
- Setup Type (Enterprise CA)
- CA Type (Root CA)
- Private Key (Create a new private key)
- Cryptography for CA (RSA#Microsoft Software Key Storage Provider, 2048, SHA256)
- CA Name (Name of the CA, e.g. Deyda-CA)
- Validity Period (5 Years)
- Bestätigt die Einstellungen mit Configure
Nun muss dem Domänen Controller ein Zertifikat der lokalen CA ausgestellt werden.
- Öffnet dazu die MMC auf dem Domänen Controller
- Klickt auf File und dann auf Add / Remove Snap-in …
- Nun klickt auf Certificates und auf Add
- Wählt im folgenden Fenster Computer account und bestätigt dies mit Next
- Schließt das Fenster schließlich mit OK
- Geht per Rechts-Klick auf Personal und klickt dann auf All Tasks > Request New Certificate…
- Wählt im Fenster Certificate Enrollment die passende Active Directory-Enrollment Policy aus und klickt auf Next
- Wählt Domain Controller Authentication aus und bestätigt dies mit Enroll
Citrix Federated Authentication Service
Jetzt kann der FAS-Server installiert und konfiguriert werden. In meinem Beispiel installiere ich den FAS mit auf den StoreFront Server.
- Hängt dazu die ISO der verwendeten Citrix Virtual Apps and Desktops Version ein und startet autoselect.exe
- Startet dann die Installation, indem im folgenden Fenster Federated Authentication Service ausgewählt wird
- Klickt auf „I have read, understand, and … “ und bestätigt dies mit Next
- Bestätigt nun die folgenden Standardeinstellungen mit Next
- Und klickt wieder auf Next
- Startet die Installation mit Finish
- Möglicherweise muss der Server während oder nach der Installation neu gestartet werden
- Um die Grundkonfiguration des FAS über die GPO durchzuführen, kopiert die ADMX / ADML Dateien aus dem angegebenen Pfad des FAS Servers (C:\Program Files\Citrix\Federated Authentication Service\PolicyDefinitions)
- Fügt diese in den PolicyDefinitions Speicher der Active Directory ein
- Erstellt eine neue oder editiert eine bestehende GPO, welche den folgenden Systemen zugeordnet werden muss:
- FAS Server
- StoreFront Server
- VDA Worker
- In der GPO navigiert in den Pfad:
|
1 |
Computer Configuration \ Policies \ Administrative Templates \ Citrix Components \ Authentication |
- Unter Federated Authentication Service gebt den FQDN des FAS Server ein
- Aktualisiert die lokale GPOs auf dem FAs Server per gpupdate /force
- Überprüft die Registry das die folgenden Einträge erstellt sind:
|
1 |
HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Citrix \ Authentication \ UserCredentialService \ Addresses |
Oder / Und
|
1 |
HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Policies \ Citrix \ Authentication \ UserCredentialService \ Addresses |
- Startet nun über „run as administrator“ das Citrix Federated Authentication Service Tool
- Unter Connect to FAS Server sieht man die Liste der über GPO eingetragenen FAS Server
- Wählt den gewünschten Server aus und klickt auf OK
- Im folgenden Fenster wird die FAS konfiguriert.
- Klickt auf Deploy im ersten Bereich mit dem Namen Deploy certificate templates
- Klickt auf OK, so dass die Zertifikat Templates automatisch im Hintergrund in der CA hinterlegt werden
- Nach erfolgreicher Einrichtung erscheint ein grüner Haken neben dem ersten Punkt
- Klickt dann auf Publish im zweiten Bereich (Set up a certificate authority)
- Unter Certificate Authority wählt eure Microsoft CA für FAS aus (z.B. DC01.deyda.local\CA-DEYDA) und klickt auf OK
- Nach erfolgreichem Setup, erscheint auch neben dem zweiten Punkt ein grüner Haken
- Nun klickt auf Authorize neben dem Punkt Authorize this service
- Wählt wieder eure CA und klickt auf OK
- Neben dem dritten Punkt erscheint nun ein blinkender Kreis, weil die ausgelöste Zertifikats Anfrage für den FAS Server noch in der CA bestätigt werden muss
- Hierfür baut eine Verbindung zum CA Server auf und startet den Server Manager
- Im Server Manager klickt auf Tools > Certification Authority
- In der Certification Authority Konsole, klickt auf Pending Requests
- Dort klickt mit der rechten Maustaste auf die Anfrage des FAS Servers (z.B. DEYDA \ CTX01) und klickt dann auf All Tasks > Issue
- Danach erscheint das Zertifikat unter Issued Certificates
Das jetzt genehmigte Zertifikat läuft normalerweise alle 2 Jahren ab.
Es ist daher empfohlen, dieses Zertifikat in die Überwachung einzubeziehen, damit das Zertifikat rechtzeitig erneuert wird, bevor es abläuft.
Hier sind die PowerShell Befehle zum Abrufen des Ablaufdatums (Ersetzt CTX01.deyda.local mit dem FQDN des FAS Servers).
|
1 2 |
Add-PsSnapin Citrix.Authentication.FederatedAuthenticationService.V1 Get-FasAuthorizationCertificate -FullCertInfo -address CTX01.deyda.local |
- Nach der Genehmigung erscheint auch ein grüner Haken neben dem dritten Punkt
- Nun klickt auf Create im Bereich Create a Rule
- Klickt auf Next um die Default Rule zu erstellen
- Unter Template wählt Citrix_SmartcardLogon aus und klickt auf Next
- Im Certificate authority Bereich wählt eure FAS CA (z.B. DC01.deyda.local\CA-DEYDA) aus und klickt Next
- Nun wählt Allow in-session use wenn Double-Hop Szenarien auch unterstützt werden sollen
- Klickt auf Next
- Unter Access control klickt auf Manage StoreFront access permissions
- Im folgenden Fenster löscht die hinterlegte Gruppe der Domain Computers
- Fügt danach eure StoreFront Server hinzu und gebt diesen die Assert Identity (Allow) Berechtigung
- Bestätigt dies mit OK
- Klickt nun auf Next
- Unter Restrictions können die Benutzer und die Worker definiert werden, für die die Zertifikatsauthentifizierung über FAS erlaubt werden soll
- Klickt auf Manage user permissions
Hier können die Benutzer definiert werden, die sich über SAML bei Citrix anmelden können. Standardmäßig wird hier die Gruppe Domänen Benutzer gespeichert. Dies kann so bleiben.
- Klickt auf Manage VDA permissions
Unter Manage VDA permissions wird wiederum die Liste der Citrix Worker definiert, bei denen die SAML Authentifizierung funktionieren soll. Standardmäßig steht dies auf Domänen Computer, was auch so bleiben kann.
- Nachdem alles definiert wurde, klickt auf Next
- Im letzten Fenster klickt auf Create
- Jetzt haben alle Punkte einen grünen Haken
StoreFront
Jetzt werden die StoreFront Server konfiguriert, so dass diese mit dem FAS-Server kommunizieren können.
- Geht auf die Citrix StoreFront Konsole und notiert denn Store (z.B. Store) der mit dem FAS Server kommunizieren soll
- Startet eine Administrative PowerShell auf dem StoreFront Server
- Führt die folgenden Befehle im PowerShell (Ändert den Store Pfad in Zeile 2 mit eurem vorher notierten Store Namen) Fenster aus:
|
1 2 3 4 5 6 |
Get-Module "Citrix.StoreFront.*" -ListAvailable | Import-Module $StoreVirtualPath = "/Citrix/Store" $store = Get-STFStoreService -VirtualPath $StoreVirtualPath $auth = Get-STFAuthenticationService -StoreService $store Set-STFClaimsFactoryNames -AuthenticationService $auth -ClaimsFactoryName "FASClaimsFactory" Set-STFStoreLaunchOptions -StoreService $store -VdaLogonDataProvider "FASLogonDataProvider" |
- Wenn die Zuordnung wieder deaktiviert werden soll, z.B. fürs Troubleshooting, führt den folgenden Befehl in einem administrativen PowerShell (Passt die Zeile 2 an) Fenster aus:
|
1 2 3 4 5 6 |
Get-Module "Citrix.StoreFront.*" -ListAvailable | Import-Module $StoreVirtualPath = "/Citrix/Store" $store = Get-STFStoreService -VirtualPath $StoreVirtualPath $auth = Get-STFAuthenticationService -StoreService $store Set-STFClaimsFactoryNames -AuthenticationService $auth -ClaimsFactoryName "standardClaimsFactory" Set-STFStoreLaunchOptions -StoreService $store -VdaLogonDataProvider "" |
- Nun öffnet nochmals die Citrix StoreFront Konsole
- Klickt im rechten Menüband auf Manage Authentication Methods
- Aktiviert Pass-through from Citrix Gateway, wenn es noch deaktiviert ist
- Klickt dann auf das Zahnrad Symbol neben Pass-through from Citrix Gateway und klickt auf Configure Delegated Authentication
- Im folgenden Fenster, prüft das Fully delegate credential validation to Citrix Gateway aktiviert ist
- Klickt zweimal auf OK um die Fenster wieder zu schliessen
- Klickt nun auf Manage Citrix Gateways
- Fügt unter Manage Citrix Gateways ein neues Gateway hinzu oder bearbeitet ein vorhandenes, um eine Verbindung zum NetScaler herzustellen, das später als Service Provider verwendet wird
- In meinem Fall, wurde ein vorhandenes Gateway via Edit angepasst
- Hierfür konfiguriert folgendes unter Authentication Settings:
- Version (10.0 (Build69.4) or later)
- VServer IP address (IP Adresse der Gateway VIP, z.B. 10.0.0.8)
- Logon type (Domain)
- Callback URL (Adresse für den Callback des StoreFront, z.B. https://citrix.deyda.net)
- Bestätigt die Eingaben mit Finish
Wichtig !
Auch im internen DNS muss die Callback Adresse richtig aufgelöst werden.
- Im Hauptmenü der StoreFront Konsole klickt auf Configure Remote Access Settings
- Prüft das Allow users to access only resources delivered through StoreFront (No VPN tunnel) aktiviert ist
Delivery Controller
Der XML-Trust muss noch auf dem Delivery Controller aktiviert werden, falls dieser nicht bereits aktiviert ist.
- Um dies zu aktivieren, startet eine administrative PowerShell Konsole
- Führt den folgenden Befehl aus
|
1 2 |
asnp citrix.* Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true |
Microsoft Azure Multi-Factor-Authentication with Conditional Access
Ausführlichere Hintergrundinformationen zu diesem Thema findet man hier.
Conditional Access
- Zunächst baut eine Verbindung zum Azure Portal mit einem Administrativen Account auf
- Klickt dort auf Azure Active Directory > Security
- Klickt auf Conditional Access
- Klickt nun auf Named locations
- Erstellt einen neuen Standort auf Basis der IP mit einem klickt auf IP ranges location (Über Countries location können ganze Länder definiert werden, auf die man dann spezielle Berechtigungen setzten kann)
- Konfiguriert folgendes für die Worker
- Name (z.B. Azure Worker)
- Klickt auf das +
- Im folgenden Fenster die gewünschte IP Range eintragen
- Mark as trusted location (Checked)
- Klickt auf Create
- Klickt unter Policies auf New policy
- In dem neuen Fenster gebt einen Namen für Policy ein (z.B. External MFA)
- Klickt auf Users and groups
- Klickt unter Include auf All users
- Unter Exclude klickt auf Users and Groups
- Klickt auf Select excluded users
- Im folgenden Fenster wählt die Benutzer aus, die keine MFA Authentifizierung erhalten dürfen, wie z.B. der Break Glass User und die Azure AD Sync Accounts
- Bestätigt dies mit Done
- Klickt auf Target resources
- Klickt nun auf Select apps und wählt die vorher erstellte Unternehmensanwendung (z.B. Citrix FAS) aus
- Klickt auf Done
- Klickt auf Conditions > Locations
- Unter Configure wählt Yes aus
- Klickt unter Exclude auf Selected locations
- Wählt den vorher definierten Standort aus (z.B. Azure Worker)
- Speichert die Eingabe mit Done
- Unter Access controls klickt auf Grant
- Wählt Grant access und Require multi-factor authentication aus
- Bestätigt dies mit Select
- Klickt unter Enable policy auf On
- Speichert die Eingabe mit Create
Konvertierung der Benutzer von per-user MFA zu Conditional Access based MFA
Bevor das folgende Skript ausgeführt werden kann, muss eine Verbindung zum Azure AD hergestellt werden. Führt die folgenden Zeilen hierfür aus.
|
1 2 3 4 |
# Install and Connect to Azure AD Install-Module MSOnline $Msolcred = Get-credential Connect-MsolService -Credential $MsolCred |
Speichert den folgenden Code in eine PS1-Datei und führt ihn aus, um die MFA-Methode zu schwenken.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# Sets the MFA requirement state function Set-MfaState { [CmdletBinding()] param( [Parameter(ValueFromPipelineByPropertyName=$True)] $ObjectId, [Parameter(ValueFromPipelineByPropertyName=$True)] $UserPrincipalName, [ValidateSet("Disabled","Enabled","Enforced")] $State ) Process { Write-Verbose ("Setting MFA state for user '{0}' to '{1}'." -f $ObjectId, $State) $Requirements = @() if ($State -ne "Disabled") { $Requirement = [Microsoft.Online.Administration.StrongAuthenticationRequirement]::new() $Requirement.RelyingParty = "*" $Requirement.State = $State $Requirements += $Requirement } Set-MsolUser -ObjectId $ObjectId -UserPrincipalName $UserPrincipalName ` -StrongAuthenticationRequirements $Requirements } } # Disable MFA for all users Get-MsolUser -All | Set-MfaState -State Disabled |
Liste der konfigurierten MFA-Benutzer
|
1 2 |
# Identify registered users Get-MsolUser -All | where {$_.StrongAuthenticationMethods -ne $null} | Select-Object -Property UserPrincipalName | Sort-Object userprincipalname |
Liste der nicht konfigurierten MFA-Benutzer
|
1 2 |
# Identify non-registered users Get-MsolUser -All | where {$_.StrongAuthenticationMethods.Count -eq 0} | Select-Object -Property UserPrincipalName | Sort-Object userprincipalname |
Authentication App
Wir melden uns nun mit unserem Testbenutzer beim MFA Setup an, um die Authentication App auf dem mobilen Gerät zu konfigurieren.
Wenn der Testbenutzer noch keinen konfigurierten zweiten Faktor hat, erscheint die folgende Meldung.
- Die Konfiguration kann mit Weiter gestartet werden
- Wählt im nächsten Fenster den Typ des zweiten Faktors (z.B. Mobile App) aus
- Um die Konfiguration zu vereinfachen, konfiguriert Benachrichtigungen zur Überprüfung empfangen und klickt auf Weiter
- Im folgenden Fenster wird ein QR-Code angezeigt, mit dem die Authentication App konfiguriert werden kann
- Öffnet die Authenticator app auf dem Endgerät
- Klickt auf das + Symbol um einen neuen Account hinzuzufügen
- Wählt Geschäfts- oder Schulkonto im Konten Menü aus
- Im folgenden Fenster (Scan QR code) kann der angezeigte QR Code gescannt werden
- Nun ist der neue Account in der App vorhanden
- Im Browser kann die Konfiguration des MFA Dienstes mit Weiter und Fertig beendet werden
Ergebnis
Wenn wir nun den FQDN des Gateways (https://citrix.deyda.net) per Browser öffnen.
Werden wir direkt zu Azure-AD weitergeleitet und können uns dort authentifizieren (Mit zweiten Faktor).
Wir bekommen unsere Citrix-Ressourcen aufgelistet und können sie starten.
Troubleshooting
Lesson learned aus der Praxis.
Cannot start app / Cannot start desktop
Der Benutzer bekommt seine Ressourcen angezeigt, kann diese aber nicht starten und erhählt nur die Fehlermeldung:
Cannot start app…
Cannot start desktop…
Wenn diese Meldung erst erscheint, nachdem FAS implementiert worden ist, müssen die üblichen Verdächtigen (Maschinen nicht im Maintenance Mode, VDA ist nicht registriert, Maschinen sind heruntergefahren und so weiter), erst später geprüft werden.
Szenario 1
Prüfung des Event Logs auf dem StoreFront zeigt folgendes.
Es wird das Event 28 beim starten der Anwendung auf dem StoreFront Server erzeugt. Dies sagt aus:
Failed to launch the resource ‚ ‚ using the Citrix XML Service at address ‚??‘.
An unknown error occurred interacting with the Federated Autentication Service.
Citrix.Authentication.UserCredentialServices.FederatedAuthenticationServerFault,…Access Denied
Diese Fehlermeldung deutet auf eine Diskrepanz in der FAS Rule Konfiguration hin. Meistens wird ein anderer Rule Name verteilt, als der der im FAS genutzt wird.
Um dies zu prüfen, kontrolliert den eingestellten Rule Name in der GPO oder direkt auf dem StoreFront in der Registry.
Geht hierfür in den Registry Pfad und prüft den Inhalt von DefaultRole:
|
1 |
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Citrix\Authentication\UserCredentialService |
Vergleicht den Rule Namen mit dem, der in FAS unter User Rules hinterlegt ist.
In meinem Beispiel, gab es hier eine Diskrepanz (GPO war auf myRule konfiguriert und FAS auf default) und diese muss angeglichen werden, indem die GPO editiert wird und auf dem StoreFront ein gpupdate /force ausgeführt wird.
Szenario 2
Wenn auf dem StoreFront kein Event mit der ID 28 zu finden ist, wird das Event Log auf dem FAS Server geprüft.
![[S104] Server [] failed to assert UPN [] (UPN not allowed by role [default])](https://i0.wp.com/www.deyda.net/wp-content/uploads/2021/12/image-6.png)
Es wird das Event 104 beim starten der Anwendung auf dem FAS Server erzeugt.
[S104] Server [] failed to assert UPN [] (UPN not allowed by role [default])
Dies deutet auf eine Fehlkonfiguration in der angeziegten FAS Rule (hier default) hin. Der StoreFront Server (hier SF1) ist nicht autorisiert Anfragen an den FAS Server zu stellen. Es könnte aber auch der Benutzer nicht autorisiert sein in der FAS Rule.
Um dies zu prüfen, kontrolliert die Einstellungen in der FAS Konsole bezüglich Manage StoreFront access permissions und Manage user permissions.
Hier ist ersichtlich, das die StoreFront Server nicht hinterlegt sind.
Erweitert die Liste der hinterlegten Maschinen mit den benötigten StoreFront Server.
Prüft ebenfalls noch die Manage user permissions.
Falls hier der Benutzer oder eine seiner Gruppen aufgelistet ist und auf Deny eingestellt ist, sollte dies korrigiert werden.
The request is not supported
Der Benutzer bekommt seine Ressourcen angezeigt und erhählt nur die Fehlermeldung auf der Ressource:
The request is not supported
Da wir bis zum VDA kommen und dort die Meldung erscheint, prüft des Event Log auf dem Ziel VDA.
Szenario 1
Wenn im Event Log das Event 3 vorkommt mit dem folgenden Inhalt.
A Kerberos error message was received: on logon session
Error Code: 0x10 KDC_ERR_PADATA_TYPE_NOSUPP
Dies deutet darauf hin das den Domain Controllern das Domain Controller Authentication Certificate und / oder das Kerberos Authentication Certificate fehlt. In der Abbildung unten sieht man, wie es auszusehen hat.
Hierfür auf die Domain Controller aufschalten und prüfen, ob im Computer Kontext die oben genannten Zertifikate vorhanden sind. Wenn nicht diese einfach nachtragen, damit der Smart Card Logon funktioniert.
Szenario 2
Wenn im Event Log das Event 9 vorkommt.
The client has failed to validate the domain controller certificate for . The following error was returned from the certificate validation process: A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider.
Prüft die Registry auf dem betroffenen VDA unter:
|
1 |
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates |
Normalerweise sollten hier mehrere CAs hinterlegt sein.
Wenn dies der Fall ist, exportiert die internen CAs im DER format.
Importiert danach die einzelnen Dateien auf der VDA mit dem folgenden Befehl.
|
1 |
certutil -enterprise -addstore NTAuth <CA files> |
Danach überprüft über die Registry, das die CAs nun gelistet werden.
AADSTS50020: User account
Nach der Authentifizierung erhält der Benutzer die folgende Meldung.
AADSTS50020: User account
Wir kommen nicht bis zu der Citrix Farm und daher prüft das Azure AD unter Sign-in logs.
Wir finden dort den Error Code 50020, was zum angezeigten Error des Benutzers passt.
Invalid username or password or Inval….
Aus der Fehlermeldung ist ersichtlich das die eingetragenen Benutzerdaten nicht zur Active Directory passen.
Szenario 1
Prüfung des Userprincipalname (UPN) in der lokalen Active Directory.
Der lokale UPN (hier User01@deyda.local) passt nicht zu den eingegebenen und in Azure AD hinterlegten Daten (hier User01@deyda.net). Dies musst angepasst werden.
Szenario 2
Wenn der UPN zueinander passt, überprüft die Session Policies des Citrix Gateway vServer, der für die SAML Authentifizierung zuständig ist.
Die Single Sign-on Domain muss in den Session Policies leer sein, damit der richtige Benutzername übergeben werden kann.
The user name or password is incorrect
Der Benutzer bekommt die Fehlermeldung nach dem Start der Ressource auf dem VDA.
The user name or password is incorrect
Da wir bis zum VDA kommen und dort die Meldung erscheint, prüft des Event Log auf dem Ziel VDA. Dort finden wir wieder das Event ID 3 im System Log.
Das Event 3 sagt aus:
A Kerberos error message was received: on logon session
Error Code: 0x3e KDC_ERR_CLIENT_NOT_TRUSTED
Dies deutet darauf hin das die Certificate Revocation List abgelaufen oder nicht erreichbar ist.
Um dies zu prüfen startet das URL Retrieval Tool und checkt die CRLs aus der Active Directory.
Sorgt dafür das die CRLs aktuell sind und bereitgestellt werden (siehe Abbildung).
Temporär kann die CRL Abfrage auch deaktiviert werden, indem der folgende Registry Key auf dem VDA eingetragen wird.
Wichtig !!!!
Dies nach dem testen wieder entfernen.
|
1 2 3 4 |
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\Kerberos\Parameters Value Name: UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors Value Type: DWORD Value Data: 1 |
Cannot complete your request
Der Benutzer bekommt die Fehlermeldung nach dem dieser einige Zeit verbunden war.
Cannot complete your request
Dies deutet daraufhin, das der Timeout im StoreFront kürzer eingestellt ist als im NetScaler Gateway vServer.
Passt hierfür entweder den Timeout im StoreFront oder im NetScaler an, so dass der Wert im NetScaler kleiner als der im StoreFront ist (hier StoreFront 20 Minuten und Citrix Gateway 15 Minuten).
Die StoreFront Store Einstellungen sind im jeweiligen Store unter Manage Receiver for Web Sites erreichbar.
You cannot login using smart card
Der Benutzer bekommt die Fehlermeldung nach dem dieser versucht die Gateway Seite aufzurufen. Meist wenn der Benutzer vorher eine Authentifizierung gegen einen anderen Azure Dienst durchgeführt hat.
You cannot login using smart card
Zur Lösung muss die Datei script.js auf allen StoreFront Servern angepasst werden. Diese ist unter C:\inetpub\wwwroot\Citrix\<Store Name>Web\custom zu finden.
Die folgende Zeile an das Ende der Datei einfügen und speichern.
|
1 |
CTXS.allowReloginWithoutBrowserClose = true |
Danach muss noch der IIS neugestartet werden. Hierfür eine CMD starten und den folgenden Befehl ausführen:
|
1 |
iisreset |
Dies muss auf allen StoreFront Servern ausgeführt werden, auf dem der, in Citrix Gateway angebundene, Store hinterlegt ist.
Erneuern des SAML Zertifikats
Da mein erster Artikel zu diesem Thema, nun fast 3 Jahre her ist, bin ich auch an den Punkt gekommen, was mit dem SAML Zertifikat von der Azure AD Enterprise App passieren muss, wenn es abläuft. Dies muss neu in der Azure AD ausgestellt werden und dann in der NetScaler SAML Server Actions ausgetauscht werden.
Azure Active Directory
Um das Zertikat zu erneuern, muss dies unter Enterprise application im Azure Active Directory beantragt und heruntergeladen werden werden.
- Hierfür ruft das Azure Portal auf
- Im Azure Navigation Panel, klickt auf Azure Active Directory
- Im Azure Active Directory Fenster, klickt auf Enterprise applications > All applications
- Dort die vorher erstellte Anwendung (z.B. Citrix FAS) suchen und anklicken
- In der Enterprise application klickt auf Single sign-on oder auf 2. Set up single sign on
- Unter SAML Signing Certificate (Bereich 3) kann das Ablaufdatum des Zertifikats für den Service Provider (NetScaler) geprüft werden (hier 2.6.2022)
- Klickt auf Edit
- Im folgenden Fenster klickt auf New Certificate um ein neues Zertifikat zu erstellen
- Nun erscheint unter dem bestehenden Zertifikat ein neues mit dem Status n/a
- Klickt auf Save um das Zertifikat endgültig zu erstellen (Dann wird auch ein Zertifikat Thumbprint angezeigt)
- Nach dem bestätigen des neuen Zertifikats über Save, erscheint der Thumbprint und der Status wechselt auf Inactive
- Um das neue Zertifikat zu aktivieren, klickt auf die drei Punkte (…) in der Reihe des neuen inaktiven Zertifikats
- Im folgenden Drop Down Fenster klickt auf Make certificate active
- Es folgt eine Mitteilung das mit der Bestätigung dieser Meldung, das alte Zertifikat deaktiviert wird und keine SAML Authentifizierungen mehr mit diesem Zertifikat signiert werden können
Wichtig!
Das Zertifikat kann auch vor der Aktivierung heruntergeladen werden und im NetScaler eingespielt / aktiviert werden. Ich gehe in dieser Anleitung nur System für System durch.
- Das neue Zertifikat ist nun aktiv und das alte kann nicht mehr genutzt werden
- Nun kann das neue Zertifikat über Certificate (Base64) heruntergeladen werden
- Nachdem das Zertifikat heruntergeladen ist, wurde es, zur besseren Übersichtlichkeit, unbenannt in Citrix FAS New.
NetScaler
Schließlich muss auf dem NetScaler das neu heruntergeladene Zertifikat auch eingespielt werden.
- Ruft die Admin Weboberfläche des NetScaler auf und navigiert zu Traffic Management > SSL > Certificates > Server Certificates
- Klickt dort auf Install, um das neue Zertifikat zu importieren
- Gebt das folgende ein und bestätigt dies mit Install
- Certificate-Key Pair Name (Eindeutiger Name für das SAML-Signaturzertifikat, z.B. Citrix FAS NEW)
- Certificate File Name (Heruntergeladenes Signatur-Zertifikat, z.B. Citrix FAS – NEW.cer)
- Das installierte Zertifikat ist nicht unter Server oder Client Certificates zu finden, sondern unter Unknown Certificates.
- Navigiert dann nach Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Actions > SAML Actions um die bestehende SAML Server Action (hier saml_auth_server) zu bearbeiten
- Tauscht nun das Zertifikat unter IDP Certificate Name aus und wählt dort das neu heruntergeladene (hier Citrix FAS NEW) aus.
