Citrix Federated Authentication Service (SAML) 2411

Last Modified: Dec 4, 2024 @ 2:28 am

1,097 Comments

Navigation

This article applies to Federated Authentication Service (FAS) versions 2411, 2402 LTSR CU1, 2203 LTSR CU5, 1912 LTSR CU9, and all other versions 7.9 and newer.

Change Log

Overview

Citrix Federated Authentication Service (FAS) enables users to log in to Citrix Gateway and Citrix StoreFront using SAML authentication.

With SAML, Citrix Gateway and StoreFront do not have access to the user’s password and thus cannot perform single sign-on to the VDA. FAS works around this limitation by using issuing certificates that can be used to logon to the VDA.

  • StoreFront asks Citrix Federated Authentication Service (FAS) to use a Microsoft Certificate Authority to issue Smart Card certificates on behalf of users.
  • The certificates are stored on the FAS server.
  • The VDA requests the user’s certificate from FAS so it can complete the VDA Windows logon process.

FAS can be used for any authentication scenario where the user’s password is not provided.

Requirements:

  • Microsoft Certification Authority (CA) in Enterprise mode.
    • When configuring FAS, you tell it what CA server to use.
    • You can build a new CA server just for FAS.
    • You can install CA on the FAS server.
  • Domain Controllers must have Domain Controller certificates. See CTX218941 FAS – Request not supported.
    • The certificates on the Domain Controllers must support smart card authentication. Certificates created using the Microsoft CA certificate template named Domain Controller Authentication supports smart cards. Manually created Domain Controller certificates might not work. See CTX270737 for the Domain Controller certificate requirements.

  • Citrix Virtual Apps and Desktops or XenApp/XenDesktop 7.9 or newer
  • StoreFront 3.6 or newer
  • Citrix Gateway.
    • StoreFront 3.9 and newer also support SAML authentication natively without Citrix ADC.
  • SAML in an nFactor (Authentication Virtual Server) configuration works in both browsers and Workspace app.
  • For multiple domains, see Deployment Guide: Multi-Domain FAS Architecture at Citrix Tech Zone.

Configuration overview:

  1. Build one or more FAS servers.
    • For security reasons, FAS should be its own server and not installed on a Delivery Controller.
  2. Upload Certificate Templates to Active Directory and configure a CA server to issue certificates using the new templates.
    • Enterprise Admin permissions are needed to upload the Certificate Templates.
    • One of the Certificate Templates is for Smart Card logon to Citrix VDA.
    • The other two Certificate Templates are to authorize FAS as a certificate registration authority.
    • The registration authority certificate does not renew automatically so be prepared to renew it manually every two years. See Renew registration authority certificates at Citrix Docs.
  3. Install the Citrix FAS group policy .admx template into PolicyDefinitions.
  4. Create a group policy object (GPO) and configure the GPO with the addresses of the FAS servers.
    • The GPO must apply to FAS servers, StoreFront servers, and every VDA. It does not need to apply to Delivery Controllers, but there’s no harm in applying it to the Delivery Controllers.
  5. Authorize FAS to request certificates from a Microsoft CA server.
  6. Configure FAS Rules to permit StoreFront servers to request FAS to generate certificates for users and permit VDA machines to retrieve the certificates from FAS.
  7. Configure StoreFront to use FAS for VDA single sign-on.

Links:

From Citrix CTX225721 Federated Authentication Service High Availability and Scalability: you can build multiple FAS servers. Enter all FAS server FQDNs in the Group Policy. StoreFront will then use a hashing algorithm on the username to select a FAS server.

  1. If you have less than 10K users, one FAS server with 4 vCPUs (2.5Ghz) should be sufficient.
  2. You will require a minimum of one FAS server (with 8 vCPUs) per 25,000 users if all users expect to be able to logon under cold start conditions (no keys or certificates cached) within 60-90 minutes.
  3. A single FAS server can handle greater than 50K users under warm start conditions (keys and certificates pre-cached)
  4. One reserve FAS server for every four FAS servers for “Day 1” cold start (Users get new keys/certificates) & disaster recovery scenarios
  5. Split the FAS Certificate Authority from Certificate Authority that performs other tasks for both security and scalability purposes.

Michael Shuster explains the Group Policy configuration for FAS in multiple datacenters at HowTo: Active-Active Multi-Datacenter Citrix FAS.

Also see the Citrix Federated Authentication Service Scalability whitepaper.

Federated Authentication Service Versions

The most recent Federated Authentication Service Current Release is version 2411.

For LTSR versions of Citrix Virtual Apps and Desktops (CVAD) and StoreFront, install the version of FAS that comes with the CVAD LTSR version.

Install/Upgrade Federated Authentication Service

The service should be installed on a secure, standalone server that does not have any other Citrix components installed. The FAS server stores user authentication keys, and thus security is paramount.

  1. On the Federated Authentication Service server, go to the Citrix Virtual Apps and Desktops, or XenDesktop 7.9, or newer ISO, and run AutoSelect.exe. Or you can download the standalone installer and run that.
  2. In the lower half of the window, click Federated Authentication Service.
  3. In the Licensing Agreement page, select I have read, understand, and accept the terms of the license agreement, and click Next.
  4. In the Core Components page, click Next.
  5. In the Firewall page, click Next.
  6. In the Summary page, click Install.
  7. The installer will probably ask for a restart.

    1. After the reboot, and after logging in again, you might see a Locate ‘Citrix Virtual Apps and Desktops 7’ installation media window. Don’t click anything yet.
    2. Go to the Citrix_Virtual_Apps_and_Desktops_7_2411.iso file and mount it.
    3. Go back to the Locate ‘Citrix Virtual Apps and Desktops 7’ installation media window.
    4. On the left, expand This PC, and click the DVD Drive.
    5. Click Select Folder.
  8. Click Finish.

FAS Group Policy

Configure a Group Policy that instructs StoreFront servers and VDAs on how to locate the FAS servers.

  1. On the Federated Authentication Service server, browse to C:\Program Files\Citrix\Federated Authentication Service\PolicyDefinitions. Copy the files and folder.
  2. Go to \\domain.com\SYSVOL\domain.com\Policies\PolicyDefinitions and paste the files and folder. If PolicyDefinitions doesn’t exist in SYSVOL, then copy them to C:\Windows\PolicyDefinitions instead.
  3. Edit a GPO that applies to all StoreFront servers, all Federated Authentication Service servers, and all VDAs.
  4. Navigate to Computer Configuration > Policies > Administrative Templates > Citrix Components > Authentication.
  5. Edit the setting Federated Authentication Service.
  6. Enable the setting and click Show.
  7. Enter the FQDN of the Federated Authentication Service server. You can add more than one Federated Authentication Service server.
  8. Click OK twice.
  9. On the Federated Authentication Service server, and VDAs, run gpupdate.
  10. On the FAS server, and on VDAs, look in the registry at HKLM\Software\Policies\Citrix\Authentication\UserCredentialService\Addresses. Make sure this key and value exists. The number one cause why FAS doesn’t work is because this key is missing from VDAs. The FAS Address GPO must apply to VDAs too.
  11. If the VDAs and Users are in different domains, see CTX220497 Users from one AD Domain not able to get FAS user certificates from another trusted domain: add the Citrix StoreFront Servers, FAS server and VDA servers to the Windows Authorization Access Group in the users’ domain. Also see Deployment Guide: Multi-Domain FAS Architecture at Citrix Tech Zone.
  13. By default, the VDAs will verify the certificates aren’t revoked by downloading the Certificate Revocation List. You can disable CRL checking by configuring HKEY_Local_Machine\System\CurrentControlSet\Control\LSA\Kerberos\Parameters\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors (DWORD) = 1 as detailed at CTX217150 Unable to login using the FAS Authentication – Getting Stuck on Please wait for local session manager.
  14. If your VDAs have third party credential providers (e.g., Duo), then it might interfere with FAS Single Sign-on.

FAS 1909+ Configuration

If you prefer to script the FAS configuration, then see Citrix Blog Post Automating the Citrix Federated Authentication Service with PowerShell.

FAS 1909 and newer have a different configuration GUI than FAS 1906 and older.

Here are 1909 and newer GUI configuration instructions:

  1. Log into the FAS server as an Enterprise Administrator that can upload certificate templates to Active Directory.
  2. On the FAS server, from the Start Menu, run Citrix Federated Authentication Service as administrator. Make sure you run it elevated.
  3. In the tab named Initial Setup, in the row named Deploy certificate templates, click Deploy.
  4. Click OK to deploy the templates to Active Directory.
  5. In the row named Set up a certificate authority, click Publish.
  6. Select an Enterprise Certificate Authority that will be issue the FAS certificates and click OK.
  7. In the row named Authorize this service, click Authorize.
  8. Select a CA that will issue this FAS server a Registration Authority certificate. Later, you will need to open the Certificate Authority console on the chosen server. Click OK.
  9. The row named Authorize this service has a new icon indicating it is waiting on the registration authority certificate to be approved.
  10. Open the Certification Authority console and point it to the CA server. In the Pending Requests node, find the certificate request for the FAS server and Issue it.
  11. Back in the FAS Administration Console, on the top right, click Refresh.
  12. The row named Authorize this service should now have a green check mark.
  13. In the row named Create a rule, click Create.
  14. In the Rule name page, leave it set to Create the default rule and click Next.
  15. In the Template page, click Next.
  16. In the Certificate authority page, select the CA that has the issuing templates configured and click Next. You can select more than one CA server.
  17. In the In-session use page, click Next.
  18. In the Access control page, click the link to Manage StoreFront access permissions.
  19. In the Permission for StoreFront Servers page, add your StoreFront servers and give them the permission Assert Identity. Click OK.
  20. Back in the Create Rule wizard, click Next.
  21. In the Restrictions page, you can optionally reduce the VDAs that are authorized to use FAS. Click Next.
  22. In the Summary page, click Create.
  23. The FAS Registration Authority certificate expires in two years. You’ll need to manually renew the FAS Registration Authority certificate before it expires. Put a notification on your calendar. For details, see Renew registration authority certificates at Citrix Docs.
    • In the row named Authorize this service, you can click the link for authorization certificate to see when it expires. Before expiration, use the Reauthorize button on the right of the same row.
  24. Jump ahead to Certificate Templates.

FAS 1906 and older Configuration

If you prefer to script the FAS configuration, then see Citrix Blog Post Automating the Citrix Federated Authentication Service with PowerShell.

Here are GUI configuration instructions for FAS 1906 and older:

  1. Log into the FAS server as a Domain Administrator or Enterprise Administrator that can upload certificate templates to Active Directory.
  2. On the FAS server, from the Start Menu, run Citrix Federated Authentication Service as administrator. Make sure you run it elevated.
  3. The Federated Authentication Service FQDN should already be in the list (from group policy). Click OK.
  4. In Step 1: Deploy certificate templates, click Start.
  5. Click OK to add certificate templates to Active Directory. Sufficient permission is required.
  6. In Step 2: Setup Certificate Authority, click Start.
  7. Select a Certificate Authority to issue the certificates, and click Ok.
  8. In Step 3: Authorize this Service, click Start.

    • Step 3 automatically submits an online request for the Registration Authority certificate to the CA and stores the non-exportable private key in the standard Microsoft Enhanced RSA and AES Cryptographic Provider.
    • Alternatively, you can submit the certificate request manually, and store the private key in TPM or HSM as detailed at Federated Authentication Service private key protection at Citrix Docs. When running New-FasAuthorizationCertificateRequest, the -UseTPM switch is optional.
  9. Select the issuing Certificate Authority, and click OK.

    • Authorize this Service only lets you select one Certificate Authority. If you want to load balance certificate requests against multiple Certificate Authorities, then see Set up multiple CA servers for use in FAS at Citrix Docs. 
      Set-FasCertificateDefinition -Name default_Definition -CertificateAuthorities @("ca1.corp.local\CA1.corp.local", "ca2.corp.local\ca2.corp.local")
  10. Step 3 is now yellow.
  11. On the Microsoft CA server, go to the Certification Authority Console > Pending Requests. Find the pending request, and Issue it.
  12. In a minute or two, Federated Authentication Service will recognize the issued certificate and Step 3 will turn green.
  13. After FAS authorization with the CA, in the FAS Configuration tool, switch to the User Rules tab.
  14. Use the Certificate Authority drop-down to select the issuing Certificate Authority.
  15. Use the Certificate Template drop-down to select the Citrix_SmartcardLogon template.
  16. Click Edit next to List of StoreFront servers that can use this rule.
  17. Remove Domain Computers from the top half, and instead add your StoreFront servers. You could add an Active Directory security group instead of individual StoreFront servers.
  18. On the bottom half, make sure Assert Identity is Allowed. Click OK.
  19. By default, all users and all VDAs are allowed. You can click the other two Edit boxes to change this.
  20. When done, click Apply.
  21. Click OK when you see Rule updated successfully.
  22. The FAS Registration Authority certificate expires in two years. You’ll need to manually renew the FAS Registration Authority certificate before it expires. Put a notification on your calendar. For details, see Renew registration authority certificates at Citrix Docs.
    • To see the expiration date of the authorization certificate, run the following PowerShell command after running add-pssnapin Citrix.Authentication.FederatedAuthenticationService.V1: 
      Get-FasAuthorizationCertificate -FullCertInfo -address myFASServer

Certificate Templates

The deployed FAS Certificate Templates from older versions of FAS have Autoenroll enabled. Newer versions of FAS (e.g., 2203) no longer have Autoenroll enabled.

  1. Open the Certificate Templates console. One option is to open the Certification Authority console, right-click Certificate Templates, and then click Manage.
  2. There should be three templates with names starting with Citrix_. Open the properties on each one.
  3. On the Security tab, highlight each group assigned to the template.
  4. On the bottom half, uncheck the box in the Autoenroll row but leave Enroll checked. Perform this step for every group assigned to this template. Then click OK.
  5. Repeat disabling autoenroll for the other two templates.

The Registration Authority certificate templates are permitted to all Domain Computers. You might want to change that.

  1. Open the Properties of one of the Citrix_RegistrationAuthority certificate templates.
  2. On the Security tab, remove Domain Computers.
  3. Add your FAS servers and enable the Enroll permission.
  4. Repeat for the other Registration Authority certificate.

To further restrict who can be issued certificates, go to your Certificate Authority’s Properties and use the Enrollment Agents tab to restrict enrollment agents.

StoreFront Configuration

Once FAS is enabled on a StoreFront store, it applies to all connections through that store, including password-based authentications. One option is to create a new store just for FAS users.

  1. Check the registry at at HKLM\Software\Policies\Citrix\Authentication\UserCredentialService\Addresses to confirm that the group policy with FAS addresses has been applied to the StoreFront servers.
  2. On the StoreFront 3.6 or newer server, run the following elevated PowerShell command: 
    & "$Env:PROGRAMFILES\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"
  3. Run the following commands. Adjust the store name as required. 
    $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"
  4. If you have multiple StoreFront servers, Propagate Changes.
  5. In Web Studio (CVAD 2212 and newer), go to Settings and Enable XML Trust.

    • Or on a Citrix Delivery Controller, run the following PowerShell command: 
      Set-BrokerSite -TrustRequestsSentToTheXmlServicePort $true

If you ever need to disable FAS on StoreFront, run the following commands. Adjust the store name as required.

$StoreVirtualPath = "/Citrix/Store"
$store = Get-STFStoreService -VirtualPath $StoreVirtualPath
$auth = Get-STFAuthenticationService -StoreService $store
Set-STFClaimsFactoryNames -AuthenticationService $auth -ClaimsFactoryName "standardClaimsFactory"
Set-STFStoreLaunchOptions -StoreService $store -VdaLogonDataProvider ""

SAML Configuration

SAML Flow

SAML flows like this:

  1. (Optional) User goes to the web application aka Service Provider (e.g. Citrix Gateway).
    • The Service Provider (SP) redirects the user’s browser to the Identity Provider’s (IdP) SAML Single Sign-on (SSO) URL and includes an authentication request in the Redirect. The IdP SSO URL might be different for each Service Provider.
    • The Authentication Request from the Service Provider includes a Service Provider Entity ID. The IdP matches the SP Entity ID with an entry in its database so it knows which SP is making the authentication request. The Entity ID must match on both the SP and the IdP.
    • If the Authentication Request is signed by the Service Provider’s certificate private key, then the IdP will verify the signature using the Service Provider’s certificate public key. In this scenario, the Service Provider’s certificate (without private key) must be loaded into the IdP.
  2. The user authenticates to the IdP, typically using Multi-factor Authentication.
    • If the user was redirected from the SP, then the IdP already knows which SP to authenticate with.
    • If the user went directly to the IdP, then the user typically needs to click an icon representing the web application (Service Provider).
  3. IdP generates a SAML Assertion containing the user’s userPrincipalName or email address.
    • Configure the IdP to include the user’s UPN or email address in the NameID field of the assertion. SAMAccountName won’t work with Citrix FAS.
    • The SAML Assertion also includes the Service Provider’s Entity ID. The ID in the Assertion must match the ID configured on the SP.
    • IdP signs the SAML Assertion using an IdP certificate private key.
    • IdP has a configuration for the SP that includes a SAML Assertion Consumer Service (ACS) URL. IdP redirects the user’s browser to the SP’s ACS URL and POST’s the SAML Assertion.
      • The ACS URL on Citrix Gateway ends in /cgi/samlauth
  4. SP uses the IdP certificate’s public key to verify the signature on the SAML Assertion.
    • The IdP’s certificate (without private key) is installed on the Citrix ADC so it can verify the Assertion’s signature.
  5. SP extracts the user’s userPrincipalName from the Assertion and uses the UPN for Single Sign-on to StoreFront and the rest of the Citrix components.
    • Note that the SP does not have access to the user’s password and thus that’s why we need Citrix FAS to generate certificates for each user.

Configure the SAML IdP

You typically start the configuration on the Identity Provider (IdP). Every IdP has unique instructions. Search Google for your IdP and Citrix ADC and you might find a IdP-specific guide. After IdP configuration, you download the IdP’s certificate and copy the IdP’s SSO URL so you can configure them on Citrix ADC.

Azure AD as SAML IdP

  1. In Azure Portal, go to Azure Active Directory.
  2. On the left, click Enterprise applications.
  3. In the new blade that appears, on the All applications page, on the right, click New application.
  4. In the All Categories view of the gallery, on the top right, click Non-gallery application.
  5. Give the application a descriptive name. Azure AD shows this name in the myapps portal. Click Add.
  6. After the application is created, on the left, in the Manage section, click Single sign-on.
  7. On the right, click the big button for SAML.
  8. In section 1 labelled Basic SAML Configuration, click the pencil icon.
  9. In the Identifier (Entity ID) field, enter an identifier in URI format. Usually it matches the FQDN of the Citrix Gateway and can be entered in https://gateway.corp.com format. You’ll later need to specify the exact same Identifier on the Citrix ADC.
  10. In the Reply URL (Assertion Consumer Service URL) field, enter a URL similar to https://mygateway.company.com/cgi/samlauth. The path must be /cgi/samlauth. The scheme should be https. And the FQDN is your Citrix Gateway’s FQDN.
  11. Click Save. Then you might have to click the x on the top right to make it go away.
  12. In section 2 labelled User Attributes & Claims, notice that it defaults to sending the userprincipalname. You can click the pencil to change the attribute used for the Name identifier value. Whatever value you send will need to match the userPrincipalNames of local Active Directory accounts (aka shadow accounts).


  13. In section 3 labelled SAML Signing Certificate, click the Download link in the Certificate (Base64) line.
  14. Citrix ADC 12.1 and newer support SAML metadata so feel free to copy the App Federation Metadata Url field.
  15. If you are running NetScaler 12.0 or older, then you will need to copy the Login URL field from section 4 labelled Set up gateway5.corp.com
  16. On the left, under Manage, click Users and groups.
  17. Use the normal process to assign Azure AD users and groups to this application. Click Assign.
  18. Jump to the section named Citrix ADC SAML Configuration.

ADFS as SAML IdP

The screenshots in this section use ADFS as an example IdP. Your IdP will be different.

  1. In your SAML IdP, create a Relying Party Trust (aka service provider trust) or new Application.
  2. Since we’re configuring the IdP before we configure Citrix ADC and thus don’t have access to the SP metadata, select the option to Enter data about the relying party manually.
  3. For the Assertion Consumer Service URL (aka relying party service URL), enter the URL to your Citrix Gateway with /cgi/samlauth appended to the end (e.g. https://gateway.corp.com/cgi/samlauth)
  4. Enter a Relying party trust identifier in URI format. You must specify the same identifier (Issuer Name) on the Citrix ADC as detailed in the next section.
  5. Configure the SAML IdP to send email address or User-Principal-name as Name ID. Citrix ADC receives the Name ID and sends it to StoreFront. StoreFront will look in Active Directory for an account with userPrincipalName that matches the Name ID.
  6. Citrix ADC will sign the authentication requests it sends to the IdP. On the Citrix ADC, you will soon configure the Citrix ADC SAML SP signing certificate with private key that signs the authentication requests that are sent to the IdP. In your SAML IdP, import the same Citrix ADC SAML SP signing certificate but without the private key.
  7. Copy the SAML authentication URL (aka Token Issuance URL) from your SAML IdP. You’ll need to enter this same URL on your Citrix ADC later.
  8. Export the IdP Token-signing certificate from your SAML IdP. The IdP could be ADFS, Okta, Ping, etc.

Citrix ADC SAML Configuration

SAML Server/Action

  1. Instructions for Citrix ADC 13.0, Citrix ADC 12.1, NetScaler 12.0, and NetScaler 11.1 are essentially the same.
    • Citrix ADC 12.1 and newer support SAML Metadata while older versions of NetScaler do not support SAML Metadata.
    • NetScaler 11 is very similar, except Certificates are in a different place in the NetScaler menu tree.
  2. Workspace app support – If you bind a SAML Authentication Policy directly to the Gateway Virtual Server (no nFactor/AAA), then Workspace app and Gateway VPN plug-in won’t work. To support SAML with Workspace app and Gateway VPN plug-in, configure nFactor (Authentication Virtual Server with Authentication Profile) instead of directly on the Gateway Virtual Server.
  3. IdP Signing Certificate – On Citrix ADC, if you are not importing IdP metadata, then manually import the IdP SAML token-signing certificate (without private key) under Traffic Management > SSL > Certificates > CA Certificates. Citrix ADC uses this certificate to verify the signature of the SAML assertion from the IdP.
    Note: when you later create the SAML Action on Citrix ADC, there’s a place to add a SAML certificate. Unfortunately, the SAML Action is trying to import the wrong type of certificate since it wants the private key, which you don’t have access to. If you import the certificate here under CA Certificates, then there’s no prompt for private key.


    • SAML IdP certificates are shown in the Unknown Certificates node.
  4. If you want ADC to sign the authentication requests it sends to the IdP, then do the following:
    1. Move up two nodes to Server Certificates and Import or create a SP SAML signing certificate with private key. This can be the same certificate used on Citrix Gateway. Or a more common practice is to create a self-signed certificate.

    2. You’ll also need to import this SAML SP signing certificate (without private key) to your SAML IdP so it can verify the SAML authentication request signature from the Citrix ADC.
  5. Go to Citrix Gateway > Policies > Authentication > SAML. The quickest way to get here is to enter SAML in the search box on top of the menu.
  6. On the right, switch to the tab labelled Servers, and click Add.
  7. In the Name field, give the SAML Action a name that indicates the IdP’s name.
  8. If your Citrix ADC is 12.1 or newer, then get the SAML Metadata URL (or file) from the IdP.

    1. In the SAML Server on Citrix ADC, in the SAML IDP Metadata URL field, paste in the URL. ADC should be able to extract the IdP’s certificate from the Metadata URL.
    2. In the Issuer Name field, enter the ID that the SAML IdP is expecting for the Relying Party.  This Issuer Name must match the name you configured on the IdP’s Relying Party (Service Provider) Trust. Azure AD calls this the Identifier or Entity ID.
    3. Near the bottom, configure a Relay State Rule to prevent session hijack. It should check the Relay State field to make sure it matches the URL that users using to reach the Gateway Virtual Server. Make sure you include the forward slash at the end of the URL. Sample expression below. Pattern set is also possible. See CTX316577 for details. To avoid relay state “does not match” error, make sure users enter the Gateway URL instead of using a bookmark. 💡 
      AAA.LOGIN.RELAYSTATE.EQ("https://gateway5.corp.com/")

    4. Scroll down and click More.
    5. You can optionally check Force Authentication to prevent users from doing SAML authentication using cached credentials. This prompts for MFA every time the user accesses Citrix Gateway.
    6. Scroll down and click Create.
    7. Edit the SAML Server again.
    8. If you uncheck the box next to Import Metadata, you can see the fields that it filled in for you. Unfortunately, other fields must be configured manually as detailed soon.
  9. Configure the SAML Server based on the data provided by your IdP. If you imported Metadata, then some of the fields might already be populated.
    1. For IDP Certificate Name, select the SAML IdP’s certificate that was exported from the SAML IdP and imported to Citrix ADC. Citrix ADC will use this IdP certificate to verify SAML assertions from the IdP.
      Note: the Add button here does not work correctly. Instead, if you need to import the SAML IDP certificate, then do it at the CA Certificates node as detailed earlier in this section.
    2. For Redirect URL, enter the URL to the SAML IdP’s authentication page. Citrix Gateway will redirect users to this URL. For ADFS, enter your ADFS URL appended with /adfs/ls (e.g. https://adfs.corp.com/adfs/ls). For other IdP’s, get the URL from your IdP.
    3. For User Field, enter the name of the SAML Claim from the IdP that contains the value that matches the userPrincipalName of your local Active Directory users (aka shadow accounts). This defaults to the NameID field, but you might have to use a different claim, like emailaddress.
    4. In the Issuer Name field, enter the ID that the SAML IdP is expecting for the Relying Party.  This Issuer Name must match the name you configured on the IdP’s Relying Party (Service Provider) Trust. Azure AD calls this the Identifier or Entity ID.
    5. Near the bottom, configure a Relay State Rule to prevent session hijack. It should check the Relay State field to make sure it matches the URL that users using to reach the Gateway Virtual Server. Make sure you include the forward slash at the end of the URL. Sample expression below. Pattern set is also possible. See CTX316577 for details. 💡
    6. Optionally, for Signing Certificate Name, select the SAML SP certificate (with private key) that Citrix ADC will use to sign authentication requests to the IdP. This same certificate (without private key) must be imported to the IdP, so the IdP can verify the authentication request signature. This field usually isn’t needed by most IdPs.
    7. Scroll down and click More.
    8. Citrix ADC defaults to SHA1. You might have to change the Signature Algorithm and Digest Method to SHA256.
    9. Review the other settings as needed by your IdP. Click Create when done.

SAML Policy – Advanced (nFactor) Method

Workspace app and Gateway Plugin (i.e. VPN plugin) require nFactor (Advanced Authentication Policies) to support SAML authentication.

Licensing – nFactor requires NetScaler ADC Advanced Edition or NetScaler ADC Premium Edition. The newest builds of NetScaler ADC 13 have added nFactor support for NetScaler ADC Standard Edition, but the configuration of an Authentication Virtual Server is not directly accessible from the main menu. If you only have Standard Edition, then do the following to get to the Authentication Virtual Server:

  1. Go to Citrix Gateway > Virtual Servers and edit one.
  2. On the right, add the Authentication Profile section.
  3. On the left, in the Authentication Profile section, click Add to create an Authentication Profile.
  4. In the Authentication Virtual Server row, click Add to create an Authentication Virtual Server.
  5. The rest of the nFactor configuration is similar to what’s detailed below.

If you prefer to configure the older Classic Method, which doesn’t work with Workspace app, then skip to the Classic Method.

Do the following to create an Advanced Authentication Policy, an Authentication Virtual Server, and bind it to the Gateway Virtual Server:

  1. In the left menu, expand Security, expand AAA – Application Traffic, expand Policies, expand Authentication, expand Advanced Policies, and then click Policy.
  2. On the right, click the button labelled Add.

    1. Change the drop-down for Action Type to SAML.
    2. Change the drop-down for Action to the SAML Action you created earlier.
    3. In the box labelled Expression, enter true.
    4. Give the policy a name and click Create.
  3. In the left menu, expand Security, expand AAA – Application Traffic and then click Virtual Servers.
  4. On the right, click the button labelled Add.

    1. Change the drop-down named IP Address Type to Non Addressable and then click OK.
  5. You can optionally bind a Server Certificate. If you don’t bind a certificate, then the AAA vServer will be down but it will still work. It doesn’t matter what certificate you choose. Click Continue when done.
  6. On the left, in the section named Advanced Authentication Policies, click the row that says No Authentication Policy.

    1. Click where it says Click to select.
    2. Click the small circle to the left of the SAML Policy that you created earlier. Then click the blue button labelled Select at the top of the screen.
    3. There’s no need to configure Select Next Factor unless you want to bind an LDAP Policy with Authentication Disabled so you can extract groups from Active Directory and use those groups for Gateway authorization. This configuration procedure is detailed in the next section.
    4. Click the blue button labelled Bind at the bottom of the window.
  7. Click Continue,
  8. At the bottom of the page, click Done to finish creating the AAA vServer.
  9. In the left menu, expand Citrix Gateway and click Virtual Servers.
  10. On the right, edit your existing Gateway Virtual Server.
  11. On the right side of the screen, in the Advanced Settings column, click Authentication Profile.
  12. On the left side of the screen, find the Authentication Profile section and then click the button labelled Add.
  13. Click where it says Click to Select and then select your AAA vServer.
  14. Give the Authentication Profile a name and then click the blue button named Create.
  15. Make sure you click the blue OK button before you click Done. If you don’t click OK then your changes won’t be saved.

Here are some sample CLI commands for this nFactor SAML configuration.

# SAML Actions
# ------------
add authentication samlAction "Azure AD" -samlIdPCertName AzureADSAML -samlSigningCertName WildcardCorpCom -samlRedirectUrl "https://login.microsoftonline.com/815e26a9-4a9b/saml2" -samlIssuerName gateway5.corp.com -Attribute1 emailaddress -logoutURL "https://login.microsoftonline.com/815e26a9/saml2" -logoutBinding REDIRECT -relaystateRule "aaa.LOGIN.RELAYSTATE.EQ(\"https://gateway5.corp.com/\")"

# SAML Authentication Policies
# ----------------------------
add authentication samlPolicy "Azure AD" ns_true "Azure AD"

# Advanced Authentication Policies
# --------------------------------
add authentication Policy "Azure AD Advanced" -rule true -action "Azure AD"

# Authentication Virtual Servers
# ------------------------------
add authentication vserver nFactor-AzureAD-SAML SSL 0.0.0.0
bind authentication vserver nFactor-AzureAD-SAML -policy "Azure AD Advanced" -priority 100 -gotoPriorityExpression NEXT

# Authentication Profiles
# -----------------------
add authentication authnProfile nFactor-AzureAD-SAML -authnVsName nFactor-AzureAD-SAML

# Citrix Gateway Virtual Servers
# ------------------------------
set vpn vserver gateway5.corp.com -authnProfile nFactor-AzureAD-SAML

SAML nFactor LDAP Group Extraction

If you use AAA Groups with Citrix Gateway, then be aware that SAML usually does not provide the user’s group membership. Instead, configure a LDAP Policy to get the user’s groups from Active Directory so the groups can be later used by Citrix Gateway.

If you don’t need LDAP Group Extraction, then skip ahead to the StoreFront section.

Do the following to configure LDAP Group Extraction.

  1. Create a new LDAP Action.
    1. Use the Search in Menu to find LDAP then pick any of the results.
    2. Check the box next to an existing LDAP policy and click Add to copy its configuration. Or create a new one.
    3. Change the name of the LDAP Action.
    4. On the top right, uncheck the box next to Authentication.
    5. Scroll down a bit and in the right side re-enter the Administrator Password. Copying an existing LDAP Action does not copy the Bind password.
    6. Scroll down to the Other Settings section.
    7. On the left, change Server Logon Name Attribute to –<< New >>–.
    8. Enter userPrincipalName. The UPN is extracted from the SAML Assertion.
    9. Scroll down and click Create.
  2. On the left, go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy and click Add to create a new Policy.

    1. Change Action Type to LDAP.
    2. Expression = true.
    3. Click Create.
  3. On the left, go to Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy Label. On the right, click Add.

    1. Give the Policy Label a name and click Continue. The Login Schema should be LSCHEMA_INT.
    2. Select your LDAP Group Extract policy and then on the bottom click Bind.
    3. Click Done to close the Policy Label.
  4. On the left, go to Security > AAA – Application Traffic > Virtual Servers. On the right, edit your SAML AAA vServer.

    1. Click where it says 1 Authentication Policy.
    2. Right-click the Authentication Policy and then click Edit Binding.
    3. In the Select Next Factor field, click where it says Click to select.
    4. Select your LDAP Group Extract Policy Label and then click Bind.
  5. Skip ahead to the StoreFront section.

Here are some sample CLI commands for this nFactor SAML LDAP Group Extract configuration.

# LDAP Actions
# ------------
add authentication ldapAction LDAP-GroupExtract -serverIP 10.2.2.11 -serverPort 636 -ldapBase "dc=corp,dc=local" -ldapBindDn ctxsvc@corp.local -ldapBindDnPassword ****** -ldapLoginName userPrincipalName -groupAttrName memberOf -subAttributeName cn -secType SSL -authentication DISABLED

# LDAP Policies
# -------------
add authentication ldapPolicy LDAP-Corp ns_true LDAP-Corp

# Authentication Policy Labels
# ----------------------------
add authentication policylabel LDAP-GroupExtract -loginSchema LSCHEMA_INT
bind authentication policylabel LDAP-GroupExtract -policyName LDAP-GroupExtract -priority 100 -gotoPriorityExpression NEXT

# Authentication Virtual Servers
# ------------------------------
bind authentication vserver nFactor-AzureAD-SAML -policy "Azure AD Advanced" -priority 100 -nextFactor LDAP-GroupExtract -gotoPriorityExpression NEXT

Configure StoreFront for SAML Citrix Gateway

  1. In StoreFront 3.6 or newer, in the StoreFront Console, go to Stores, right-click the store, and click Manage Authentication Methods.
  2. Make sure Pass-through from Citrix Gateway is selected.
  3. Click the bottom gear icon on the right, and click Configure Delegated Authentication.
  4. Check the box next to Fully delegate credential validation to Citrix Gateway and click OK twice.
  5. In StoreFront, add a Citrix Gateway object that matches the FQDN of the Citrix Gateway Virtual Server that has SAML enabled.
  6. On the Authentication Settings page, make sure you configure a Callback URL. It won’t work without it.
  7. Then assign (Configure Remote Access Settings) the Gateway to your Store.

  8. Next step: create Active Directory Shadow Accounts

Native SAML on StoreFront without Citrix ADC

StoreFront 3.9 and newer have native support for SAML Authentication without Citrix ADC. Notes:

  • SAML overrides Explicit and Pass-through authentication.
  • SAML in StoreFront without Citrix ADC seems to work in Workspace app and Receiver Self-Service for Windows.

For an example configuration using StoreFront PowerShell commands and SAML metadata, see CTX232042 Configure StoreFront with OKTA.

To configure native SAML in StoreFront 3.9 or newer:

  1. Export the signing certificate from your SAML IdP. The IdP could be ADFS, Okta, Ping Identity, etc.
  2. In StoreFront 3.9 or newer console, right-click a Store, and click Manage Authentication Methods.
  3. Check the box next to SAML Authentication. If you don’t see this option (because you upgraded from an older version), click the Advanced button on the bottom of the window, and install the authentication method.
  4. On the right, click the gear icon for SAML, and click Identity Provider.
  5. Change the SAML Binding to the method your IdP expects.
  6. Enter the IdP token issuance endpoint URL. For example, in ADFS, the path is /adfs/ls.
  7.  Click Import.
  8. Browse to the signing certificate exported from your IdP, and click Open.
  9. Then click OK to close the Identity Provider window.
  10. On the right, in the SAML Authentication row, click the gear icon, and then click Service Provider.
  11. Click the first Browse button.
  12. Give the Signing certificate a name, and save it somewhere.
  13. Click the second Browse button.
  14. Give the Encryption certificate a name, and save it somewhere.
  15. Copy the Service Provider Identifier. Or you can change it to your desired value. Then click OK.
  16. In your IdP (e.g. ADFS), create a Relying Party Trust.
  17. Import the Encryption certificate that you exported from StoreFront.
  18. Enable SAML 2.0.
  19. For the Assertion Consumer Service (ACS) path, enter something similar to https://storefront.corp.com/Citrix/StoreAuth/SamlForms/AssertionConsumerService. The hostname portion of the URL is equivalent to your StoreFront Base URL. /Citrix/StoreAuth matches your Store name with Auth on the end. The rest of the path must be /SamlForms/AssertionConsumerService. You can get this ACS value by looking in the SAML metadata at the bottom of https://<storefront host>/Citrix/StoreAuth/SamlForms/ServiceProvider/Metadata.

  20. For the Relying party trust identifier, enter the identifier you copied from the Service Provider window in StoreFront.
  21. Configure the Claim Rules to send the user’s email address or userPrincipalName as Name ID.
  22. Edit the Relying Party Trust. Import the Signing certificate that you exported from StoreFront.

  23. Create Active Directory Shadow Accounts. Federated users must be userPrincipalName mapped to local Active Directory accounts.
  24. If you point your browser to https://<storefront-host>/Citrix/<storename>Auth/SamlTest, it should perform a SAML Login, and then show you the assertion that was returned from the IdP. See Citrix CTX220639 How to configure SAML Authentication-Test Configuration.
  25. See Citrix CTX220682 Storefront SAML Troubleshooting Guide for event logs, SAML Metadata, Active Directory account mapping, Trust XML, etc.
  26. When you go to your Receiver for Web page, it should automatically redirect you to your IdP. After authentication, it should redirect you back to StoreFront and show you your icons.
  27. ADFS also works in Receiver 4.6 and newer, and Workspace app.
  28. When you logoff, it won’t let you log on again unless you close your browser and reopen it.

  29. To fix this problem, see CTP Sacha Thomet StoreFront – Allow relogin without browser close. Edit the file C:\inetpub\wwwroot\Citrix\StoreWeb\custom\script.js, and add the following line: 
    CTXS.allowReloginWithoutBrowserClose = true

  30. Now when you logoff, you’re given an option to log on again.

Active Directory Shadow Accounts

To login to Windows (Citrix VDA), every user must have an Active Directory account in a domain trusted by the VDA. For Federated Users, you typically need to create shadow accounts for each Federated user in your local Active Directory. These Shadow accounts need a userPrincipalName that matches the SAML attribute (usually email address) provided by the SAML IdP.

If the email address provided by the SAML IdP does not match the UPN suffix for your domain, then do the following:

  1. Open Active Directory Domains and Trust.
  2. Right-click the top left node (not a domain node), and click Properties.
  3. In the UPN Suffixes tab, add a UPN suffix that matches the email suffix provided by the SAML IdP.
  4. When creating a shadow account in your Active Directory, the new UPN suffix is available in the drop-down list. Note that the pre-Windows 2000 logon name can’t conflict with any other user in the domain.
  5. The password for these Shadow accounts can be any random complex password since the Federated users never need the Shadow account’s password.
  6. If the shadow account is already created, edit the account, and on the Account tab, use the drop-down to select the new UPN suffix.
  7. Create a shadow account for every federated user. There are third party Identity Management tools that can automate this. Or get an export from the IdP and use PowerShell scripting to create the acccounts.

Verify FAS

When FAS is enabled on StoreFront, every user that logs into StoreFront (local or remote) causes a user certificate to be created on the FAS server. You can see these user certificates by running the following PowerShell commands:

Add-PSSnapin Citrix.Authentication.FederatedAuthenticationService.V1
Get-FasUserCertificate -address fas01.corp.local

Citrix uses these certificates to logon to the VDA as the user. No password needed.

1,097 thoughts on “Citrix Federated Authentication Service (SAML) 2411”

  1. Hi Carl and thanks again for this tutorial,
    For troubleshooting purpose, is there a solution to test the FAS logon process strait from the storefront ? by using a test store with FAS authentication and a apps server …

    Reply

  2. Hi Carl,
    Happy New Year! A quick question: Can we enable FAS for multiple specific Stores on the StoreFront server? We would like to setup a SSO QA store and SSO Production store on our Storefront server.
    Thank you very much as always!
    Sunny

    Reply

    1. The PowerShell commands enable FAS for a specific store. You can run them for multiple stores. Is that what you’re asking?

      Reply

  3. Hi Carl,

    I have an issue when logging in with a Wyse3040, 9.1. We use SAML for Netscaler through Azure I receive a prompt for a token when I try and login.The login account does not have 2FA enabled so not sure why we get the token prompt.

    Logging in through a browser on a PC is fine, SAML auth works fine.

    Any pointers?
    Thankyou

    Reply

          1. Thanks. This is useful – the Wyse terminal is running in workspace mode so I will try disabling this initially. Will also review nFactor as workspace mode seems to be a slicker experience on the latest Wyse O/S.

            Will report back on the final fix.

          2. Hi Carl, I made some progress with the nFactor setup on the netscaler. Now when I logging on the Wyse terminal the Azure login pops and I can’t enter my login details.However, following the login I seem to get chucked back out to the login page. I receive the error failed to resolve host name. DNS is obviously ok as I am able to login initially. Looking at the packet capture I get the word ‘undefined’ appended to the end of the A record which is the reason for the resolution failure.
            Must be something in the SAML/nFactor config on the netscaler. Odd thing is SAML works fine when logging in with a web browser on a PC. And if I change the auth method to LDAP I can login fine on the Wyse terminal.
            I am running the latest Wyse firmware so will roll back to see how this goes. Also wondering if the failure is caused by the Netscaler re-direction to download receiver/workspace. This won’t be required on the Wyse terminal.
            Any other thoughts?
            Thanks

          3. I did get this working in the end, nFactor was required. There was also a bug in the Netscaler firmware. Once updated the issue was resolved (Upgrade your ADC to 13.0 64.x or greater build) I also needed to use the latest Wyse firmware 9.1 and use workspace mode.

            ‘In the trace I can see after the packet POST /nf/auth/webview/done HTTP/1.1, ADC Gateway responds with internal server error. But this is not observed when user logs in with Browser.

            Upgrade your ADC to 13.0 64.x or greater build, these builds have a fix to this issue.

            Thanks Carl!

  4. So we want to do a test to check if we can easily integrate our IDP via SAML to authenticate against a StoreFront store.
    Can we test this without installing FAS (suppose we don’t need to test launching apps or desktops). Should we be able to just authenticate against Storefront and see our available apps/desktops without FAS setup?

    Reply

      1. Ok, thanks for the prompt answer Carl, we’ll need to dig deeper and see if we can enable some extra logging. Getting the “There was a failure with a mapped account” error after authentication now in Storefront and “Citrix delivery services” eventlog shows “An authentication attempt was made for user: xxxx@xxxx with realm context that resulted in: Failed (Windows Error code: -1073741715)”.

        Reply

        1. I have found that native SAML support in StoreFront to have limited compatibility. Citrix ADC/Gateway has much greater compatibility.

          Reply

          1. Ok, so that implies preventing access to the storefront urls for end users (or workspace app) if we want to trigger MFA via our SAML auth.

          2. Put Citrix Gateway in front of StoreFront. In your StoreFront > Authentication > Manage Methods, only enable Gateway authentication.

          3. For what it’s worth, I have found what Carl said to be true regarding native SAML support in Storefront and it’s limited compatibility, when using any SAML IdP other than ADFS or Azure AD. With other Idp’s involved, I had to get Citrix support involved to make it work.

          4. And if I understand correctly in this scenario end users always should be using the gateway url for Receiver for Web and make sure that Internal Beacon points to sth unavailable for Workspace app to always make use of the gateway?

            “Put Citrix Gateway in front of StoreFront. In your StoreFront > Authentication > Manage Methods, only enable Gateway authentication.”

          6. Carl, Im having an issue getting to the storefront page with smart cards. Username and password works but when they authentication method is checked for smart cards, i get cannot login with smart card after i choose my cert. The account in active directory is configured correctly. Anything else i need to check?

        2. Did this get fixed? I’m running into an issue where i get cannot login with smart card and smart card is the only authentication method selected in storefront. Anything i need to enable in active directory or registry?

          Reply

          1. We did manage to perform a successful test run with SAML auth to Storefront (SAML 2.0 with Shibboleth Idp).

            So, initially we got these errors:
            “There was a failure with a mapped account” error after authentication in Storefront and “Citrix delivery services” eventlog shows “An authentication attempt was made for user: xxxx@xxxx with realm context that resulted in: Failed (Windows Error code: -1073741715)”.

            Performed some extra testing with the idp team and apparently we needed to add the StoreFront servers tot the Windows Authorizations Access Group.

            Next phase in our testing will be installing and integrating the FAS infrastr.

  5. Hey Carl, Is there anyway to configure delivery group membership via the SAML attributes? Or set it up in a way so that after authenticating with the IdP with SAML, have a desktop/application presented depending on the attributes sent in the claim attributes?

    Reply

    1. My current setup is domain1.local is IdP and domain2.local has SF. There are security groups configured in domain2.local which correlates to DG/VDA access. I am trying to find a way in which domain1.local to have information within the claim assertions to determine DG access. An example: after successful authentication via SAML, is it possible to have the attributes determine which DG/VDA will be presented in SF? I am trying to avoid the security group membership administration portion.
      Thanks Carl!

      Reply

      1. I’m not aware of anything in StoreFront that can use claims/attributes. But Citrix ADC can extract and use SAML attributes. Delivery Group visibility is based on local AD group membership. Maybe you can use ADC to extract a claim/attribute and use that to select a user ID (different user ID for different attribute values) in local AD that is a member of the Delivery Group. Or ADC might be able to configure SmartAccess (Session Policy expressions) based on SAML attributes. Or ADC might be able to send users with different SAML attributes to a different StoreFront server/store that hides applications.

        Reply

  7. Hi Carl Stalhood

    After authenticated FAS, black screen shows up in VM
    I tried everything , but I didn’t solve this problem , it’s like a hard to crack!

    Reply

  8. HI Carl,
    Thanks for your tutorial.
    I would like to understand exactly the additional “user oriented” features bring by FAS. Because with Keberos delegation we can allready have a SSO after an authentication with SAML / Netscaler. So what is exactly new in FAS ? is it a new way to do the same things ? is it more secure ? or I miss something ?
    Thanks in advance

    Reply

    1. FAS is only for Citrix Virtual Apps & Desktops. SAML usually does not provide the user’s password to ADC so ADC is not able to do Single Sign On to the CVAD VDAs. Kerberos (KCD) is one non-password option of SSON but CVAD 7.x and newer don’t support Kerberos. That leaves smart card certificates, which is what FAS does.

      Reply

  9. Still trying to clarify need. (No ADC and Non FAS)
    – ADFS as iDP for dom1.com. users login using upn user1@dom1.com
    – SF as SP
    – Shadow accounts in dom2.com. dom1.com added to Domain and Trusts. Shadow account for user1 set in
    dom2.com to use dom1.com so upn matches.

    Will SSO to SF work for users in dom1.com? Domains are in different forest. Not Domain trust. We are getting
    mixed messaging from Citrix. They want use to use FAS. Thx in advance

    Reply

    1. It should get you into StoreFront, yes. I assume you can access StoreFront and see the icons?

      But when you launch an icon, the VDA will prompt for credentials because it doesn’t know the user’s password because ADFS did not provide the password and ADFS probably doesn’t know the password for your shadow account anyways. FAS eliminates this VDA logon prompt.

      Reply

  10. Hi…I have configured FAS integrated with Azure. Getting below error while checking FAS configuration

    Get-FasAuthorizationCertificate : Error: System.ServiceModel.ServerTooBusyException: The HTTP service located at
    http://ServerName/CitrixUserCredentialService/Administration is unavailable. This could be
    because the service is too busy or because no endpoint was found listening at the specified address. Please ensurethat the address is correct and try accessing the service again later. —> System.Net.WebException: The remote server returned an error: (503) Server Unavailable.

    Also on Gateway getting “Cannot Complete Your Request” Not able to understand what’s the issue.

    Any lead will be very helpful. Thanks in Advance.

    Reply

    1. Look for an Identity Management tool that can sync accounts across directories. E.g. Microsoft Identity Manager.

      Or you can write scripts to get accounts from one directory and create accounts in another directory.

      Reply

    1. To eliminate the VDA logon prompt, yes. Unless you can configure ADFS to return the user’s password to StoreFront.

      Reply

      1. So if we us ADFS and shadow accounts, ADFS well send\use the passwords stored for those shadow accounts to storefornt.

        Reply

  13. @carls, Thanks for sharing wonderful document, i have setup SSO and its working fine but we had issue with user having more than 20 character upn name, user is getting Can’t complete request on the SF page. user’s who had less than 20 characters user name are fine and able to login successfully. raised a case with citrix as well but they are passing information here and there since so many days. Waiting for your valuable reply for this solution:

    Reply

  14. Carl

    we are trying to get native SAML working on Storefront 3.12 using PingID as the Idp. The request is directed successfully to Ping and then back to Storefront. When we check the SAML trace we see that we have a UPN atrribute in the right format as well as NameID in a UPN format. Is NameID the attribute used by Storefront from the Idp to complete the Storefront authentication ???

    we get the error message from Storefront – “There was a failure with the mapped account” and the following in the event log
    The security token failed validation.
    System.Security.Cryptography.CryptographicException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
    The signature verification failed.

    iDP ACS URL is /Citrix/SAMLAuth/SamlForms/AssertionConsumerService

    We already have Citrix Cloud authentication working successfully with SAML and Ping but have an internal 7.15 site that we want to authenticate with our internal storefront servers. We don’t have any Netscalers we can use for this

    Any help would be greatly appreciated

    Reply

    1. Maybe the wrong IdP certificate is uploaded to StoreFront?

      When I can’t get an IdP to work with StoreFront, I can almost always get it to work with Citrix Gateway.

      Reply

      1. yer if all else fails we might have to go down that path. Although we have Citrix Cloud configured to use SAML/Ping MFA so we could use site aggregation.

        Do you think storefront 1912 might fix the issue. i think we have the right Idp certificate but will double check.

        Is there any sort of information out there that says what Idp’d are supported or not. Could save some time if it is confirmed somehere that Ping does not work directly with Storefront

        thanks Mike

        Reply

          1. We are using F5 APM and ADFS as idp. Unable to SSO from F5 to StoreFront. After entering the site RUL, its passed on to ADFS page for authentication and then redirected to StoreFront logon page and it stops there. Functionally, its suppose to SSO to Storefront page where the apps are listed. Any Ideas ?

          2. StoreFront is configured with Callback URL? StoreFront is configured to fully delegate credentials to Gateway? F5 is configured to send user’s UPN to StoreFront?

      2. For what it’s worth, I faced an issue with SAML so, CVAD 7.15, and Storefront 3.12 CU4, where PingFederate was used as the SAML IdP. Eventually, I had to get a private fix from Citrix to resolve the issue. It is my understanding that this issue is resolved in CVAD 1912.

        Reply

        1. @Carl, Yes, the Callback URL on SF is the FQDN of the f5 virtual server. YEs, SF is configured to fully delegate credentials. We have an other instance of F5 and SF servers without SAML auth and it works fine. Looking at the session variables on F5 traffic, UPN seems to be in place. F5 uses a variable session.saml.last.nameIDValue and it seems to hold the username . Not sure where the miss is.

          Reply

  15. Hi Carl
    If I run web logon to Citrix storefront from ADFS server itself it works with all users, what I cannot do is make it work from end point devices (they are domain joined). What do I miss? Does certification authority requires some special config or web enrollment?

    Reply

      2. Carl one question. Citrix_SmartcardLogon certificate expiration has dates but no session only option. Can you change it so certificate is only issued for session duration?

        Reply

        1. The private key and certificate are stored on the FAS server for default 7 days. The certificate is distributed to the VDA by default only during the logon process but it can be configure to remain during the entire VDA session.

          Reply

          1. Last one, do you know why if I connect from domain joined laptop I’m always prompted for password? Windows authentication should push for passwordless connection. Intranet all configured but still same result. If I run it from adfs server all works with password, cannot figure out what is missing
            I appreciate your hard work answering all these questions.

          2. What exactly is prompting for password? StoreFront? Or the VDA?

            If the VDA, in Workspace app, run the SSON Configuration Checker.

  16. We have setup FAS and it is working when logging into storefront using a UPN. However when attempting to connect via a netscaler gateway we are getting a cannot complete your request in storefront. Looking at the error in storefront it is showing the wrong format for the username first.last@internaldomainname.local instead of first.last@externaldomainanme.org which we have the users UPN set for. If we change the NameID claim to SAMAccountName it fixes storefront but this prevents FAS from working. We have confirmed that the SAML claim and trace are passing the correct format for the UPN. Has anyone had this issue?

    NetScaler version 12.1 build 58.15
    Storefront Version 1912 CU1

    Reply

      2. Carl, we worked with Citrix support on the issue. The solution to our issue was to put the upn domain in the single sign on field on the netscaler policy instead of leaving it blank. Do you see this causing any negative affects?

        Reply

  17. Hello,
    Configure Storefront for SAML citrix gateway. Is this step relevant if we have other any ADC than Netscaler ?

    Reply

  18. Hello Carl,

    We recently enabled FAS in our Production environment following your guide, and it’s working perfectly. However, we want to adjust the logout experience for our users.

    Do you know if we could disable or remove the possibility of logging out from the Storefront, and have users redirected to another webpage when the session ultimately times out? I tried to play around with custom logout URLs, but I am met with a http 405 error, which I have to assume is limitations on the webpage I am redirecting to.

    The reason behind this is that we don’t want our users to use LDAP authentication at all, i.e we don’t want them to ever see the loginscreen to the netscaler.

    Reply

  19. Hi Carl!

    Regarding this:

    “If the VDAs and Users are in different domains, see CTX220497 Users from one AD Domain not able to get FAS user certificates from another trusted domain: add the Citrix StoreFront Servers, FAS server and VDA servers to the Windows Authorization Access Group in the users’ domain.”

    So basically if I have one-way non-transitive domain trust in place, where the domain from which users come from is trusted, but that domain does not trust the domain where our VDA’s and StoreFront Servers are, we cannot implement this?

    Reply

  20. Since migration to SAML iDP and FAS, some of our persistent desktop users who launch it externally will get logged out after 2-3 minutes, if they use another RADIUS enabled gateway it doesn’t happen. I have verified timeouts are same on each, and in each respective storefront. They actually see “logging out…”

    Reply

      1. Not a screen saver, but yeah an inactivity lock. Not that quickly, and this seems to happen middle of them working.

        Reply

  21. Hi Carl,

    We are using Citrix Gateway with Azure SAML and it’s working really great except for MFA.
    Within Azure Conditional Access we configured that we always want Azure MFA while logging in.
    The first time we visit the website we need to use MFA but the other times it isn’t asking for MFA anymore.

    It seems like we’re not getting the MFA because the user still stays logged in on the CItrix Gateway.
    Is there an option to log the user automatically with Azure SAML in but force MFA as second authentication?

    Hope you can help us.

    Kind regards,
    Jordy

    Reply

      1. Thanks for your reply, when we check the Force Authentication we need to manually enter the UPN and password. After entering those credentials MFA is working, is there also a way to automatically enter the credentials?

        Reply

  22. Thanks for the info. Quick question. Is it possible to allow users to change their PW on a gateway using SAML? I don’t see it being a possibility, but worth asking.

    Reply

  23. Our customer would like to log in to the Netscaler externally with local login information and then be forwarded to the StoreFront. Here the authentication to the AD should take place via LDAP. Is that possible? Maybe with FAS?

    Reply

      1. I have set up the authentication with a local policy for the ICA proxy on the ADC and use the AAAUser users for authentication. Now, after entering the local user data, I am forwarded to the StoreFront. Now I get the login page from the StoreFront. There I would have to log in with LDAP credentials. Is that even possible and can I then start published applications? I thought it wasn’t possible.

        Reply

  24. Hi Carl,

    Is it possible to implement FAS for just a subset of users or VDAs. We are using Citrix Cloud with Azure AD authentication and are able get SSO working thru Citrix workspace on Azure AD joined devices for our staff. However, it would be great if we could simplify sign in for our customers as they are not using the same setup (SSO enabled workspace and AAD joined devices). They do not use the same set of VDAs as our staff though.

    Thank you!

    Reply

    1. FAS is conducted between StoreFront and VDA. When you enable FAS on a StoreFront Store, FAS then generates certificates for all users that use that StoreFront Store. Front-end authentication (e.g. SAML) has nothing to do with FAS. FAS is used because SAML does not provide the user’s password.

      What other authentication do you want? You can configure ADC nFactor to ask for user’s email address and then choose an authentication method based on the email suffix.

      Reply

  25. Hi Carl, thanks for everything you’ve laid out in this article.

    Is it possible to turn SAML authentication on for only the external users coming through the NetScaler. I’d like to leave the internal VIP as Username/Password. Is a second store required for this to work?

    Thanks in advance.

    Reply

    1. If you do SAML on Gateway, then only Gateway users do SAML. Internal users usually connect directly to StoreFront (not through Gateway).

      Reply

  26. Hi Carl ,

    We have on – premise domain ( AD environment ) and our Citrx infra and Users are Part of this domain e.g ( Domain A )

    We also have AZURE AD (Doman B ) and this is no Sync configured between Domain A and Domain B

    We want to create Cloud Users in Domain B and Authenticate and Authorize them to on premise Citrix hosted on Domain A – Expectation is Cloud user should be able to authenticate and launch VDA and logon .

    So far we are able to create Service on Azure for access gateway and configured SAML – With cloud User created on Domain B we are atleast redirected to Azure and autheticate on access gateway , but we are stuck on Authorization part , how we can browse the directory of Domain B and assign desktop from Sutdio as there is no trust between Domain A and Domain B .

    can we create Shadown Accounts of cloud User on On-Premise AD ( DOmain A) , for authorization purpose ? or any alternate options for this Use case .

    Reply

    1. Yes, create Shadown Accounts of cloud User on On-Premise AD ( DOmain A) , for authorization purpose.

      Reply

    1. As long as your local AD has accounts with UPNs that match the Name ID coming from the SAML IdP.

      Reply

      1. My local AD does have accounts with UPN (added the correct suffix to match b2b account) that match the incoming name ID from the SAML IdP and I still could not get this to work. I can get them to authenticate and sign in to Citrix Cloud Workspace, but there is no virtual apps presented or available. Those virtual apps are based on AD group membership, so I thought by putting the internal shadow account in the group membership and then the map and UPN claim from the B2B Azure account, it would present the virtual app, but I never got this to work.

        Per Citrix support, this doesn’t work. I even shared this article, and their exact response is:

        “Hello Brett,

        After taking a look at the article provided I see that this configuration is only for Citrix Cloud and Citrix ADC; meaning you have to have a Netscaler on Premise to accomplish this.”

        I really thought setting up FAS and those shadow accounts internally was exactly what would allow our B2B partners to sign in and access our Citrix Cloud virtual Apps. But Citrix Support says no. Am I missing something or should this work without an on prem netscaler? They said an official SAML enterprise app in Azure AD is what I will need and that is slated on the road map for Q4 of this year.

        Thanks,

        Brett

        Reply

  28. Hi Carl,

    One more question.

    Do we still need to setup anything on ADC for SAML if we use StoreFront 3.9 native SAML setup as you described for non-trusted forest? We will add the forest UPN suffix and create the matching shadow accounts in the local VDA forest that match the foreign UPN.

    The non-trusted forest is outside our local area network and will access via the Internet.

    If this requires ADC configurations, we should complete ADC SAML setup and skip “Native StoreFront SAML setup” setups section, correct?

    Thank you very much,
    Sunny

    Reply

    1. It depends on the IdP. Not all of them work on native StoreFront. But it yours works, then you don’t need ADC.

      Reply

      2. Hi Carl,

        Hope you are staying safe and healthy. We realize different ACS URLs,

        sample URL

        https://sf.sp.com/Citrix/SSOAuth/SamlForms/AssertionConsumerService
        and
        https://adc.sp.com/cgi/samlauth

        for StoreFront only and ADC Gateway respectively while stepping through the setup with Idp.

        Our Storefront URL is not accessible outside the LAN. Do we need to make the Storefront ACS URL accessible from outside to setup SAML with Storefront without ADC? Or Do Storefront only SAML setup works with internal LAN accessible Idp only?

        Thank you very much again.

        Reply

        1. For user authentication, no. The user’s browser needs access to both the IdP and the SP, but there’s no need for IdP and SP to communicate with each other.

          For IdP setup, the IdP can import metadata directly from the SP. Or you can manually configure the IdP with your SP info. Or you can download the metadata XML file and import it to your IdP.

          Reply

          1. Thank you again, Carl.

            Does “user needs access to ….. SP” equal to users access publish apps via ADC gateway to Storefront? Users cannot access published apps via Storefront URL directly without going through ADC gateway. Users have access to IdP.

          2. Typically the users go to your Gateway, which then redirects to the IdP, which then redirects back to your Gateway.

      1. Hi Carl,

        We finally get through all the scheduling and completed the SAML setup with our ADC as SP and a client as IdP. The latest hurdle appear. A Windows login prompt pop up asking for credential when a user clicks on a published app after SAML process completed. This article, https://support.citrix.com/article/CTX220154, seems related, but outdated.

        Have you seen this problem and any suggestion how to resolve?

        Thank you very much as always.

        Sunny

        Reply

        1. Is FAS installed and enabled? If so, then you might have to check the VDA’s Event Viewer to determine why the domain controller is not accepting the user certificate.

          Reply

          1. Hi Carl!

            Thank you so much!

            Yes, FAS is installed and functional. I looked at event viewers on DC, FAS and SF/CDC without info and didn’t check the VDA event viewer. Found the error and a solution. All are working!

            Sharing them for other’s reference.
            Event on VDA: [S101] Identity Assertion Logon failed. Unrecognised Federated Authentication Service [id: 0]

            Added the missing FAS registry keys on the VDA/GPO solved the problem. It seems later CU for 7.15 LTSR is still affected by this case below.

            https://robertsteeghs.wordpress.com/2018/03/05/xenapp-vda-7-15-cu1-breaks-single-sign-on-with-citrix-fas/

            Again, thank you very much for your help! Stay safe and healthy!

            Sunny

  30. can I ask we are getting (under Mac users only) “You cannot login at this time” on SF window when accessing by gateway. The article CTX227673 is for SAML authentication. Why are we getting this if our authentication is RSA (on SF user name and password; domain pass-through and Pass-through from Citrix gateway ?
    Do I still need to apply CTX227673? Seems that if user close the browser completely they can login after that. https://www.netiq.com/documentation/advanced-authentication-62/server-administrator-guide/data/t455s7houfiy.html

    Reply

    1. That error usually only occurs when the user logs off. Are you saying that Mac users can login and only see the message after the webpage logs off?

      Reply

      1. seems to have two Mac users and Chromebooks users. With Chromebook user she got the error even after restarting chromebook. She is on receiver 14.9.200.21 (I just asked them to get her on WorkspaceApp) this started after I upgrade to 1912CU1. Bit strange as we dont use SAML.

        Reply

  31. Where are the FAS logs located? Also, is a STA still required with FAS or does FAS take its place? The install steps have been followed, my Domain Controller has a DC cert for smart card logon, I have enabled the FAS plugin on Storefront but I don’t see any information regarding FAS and if its working or not. I ran the FAS validate command to see what certs were issued but there is nothing. I am currently using smart card authentication at an F5 BIG-IP with SAML server side auth. I am sending the users UPN as the nameIDValue. Any guidance is appreciated. Thanks in advance.

    Reply

    1. See https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/secure/federated-authentication-service/fas-config-manage/fas-troubleshoot-logon.html

      STA authenticates the ICA session to Gateway ICA Proxy. FAS is not involved. FAS performs Single Sign-on the VDA and doesn’t care if your ICA connection goes through Gateway or not.

      If you’re able to do SSON to the VDA without entering any passwords in Gateway or StoreFront, then FAS is working.

      Reply

  32. Hi Carl, nice write up (as always).

    When using LDAP authentication (and Radius as second factor), we can configure group extraction which then allows authorization policies to be applied to AAA users and/or groups. How can this be done when using SAML iDP authentication?

    Reply

  33. I am still unsure about how to make the whole UPN claim portion work with Citrix Cloud and AAD. I am not using storefront, I have a direct Citrix Cloud setup with Azure AD as the id provider. I have my FAS servers all set up and passing validations and everything is configured per the instructions. What I want to accomplish is my customers log in with their own @customer.com domain credentials/their own office 365 ad accounts. I was assuming based on the instructions, to accomplish this, all I needed to do was: in my AD forests and trusts I just add the trust for customer domain name (customer.com), then on the user account in mydomain.com, I change their UPN suffix to @customer.com and that would work.

    I did that, but when trying to log in, I get the message: User account ‘user@customer.com’ from identity provider ‘customer.com’ does not exist in the tenant ‘MyDomain’ and cannot access the application ‘Citrix’ in that tenant. The account needs to be added as an external user in that tenant first.

    So I thought the way FAS worked was that upon logging in, it checked the AD, found that UPN claim for customer.com suffix account and mapped it to the internal mydomain.com account and signed them in. I think I missed something with how the actual authentication and federation to my Azure AD happens first though. I am thinking there is some portion of setting up an external identity, or B2B or SAML federation or something in Azure AD, but can’t find the best recommended way to go about this. Anyone have any experience or suggestions?

    Reply

    1. FAS is only for the final VDA login. StoreFront (or Citrix Cloud Workspace) asks FAS to generate a certificate for the UPN. Then VDA retrieves the certificate from FAS.

      I suspect your error is earlier in the process. Can the user see the list of icons? FAS doesn’t happen until the user clicks an icon.

      Reply

      1. No, the user cannot see the list of icons at that point, its still at the phase of authenticating and logging in with the azure credentials when they get that error that their domain name is not in our tenant. So I think you’re right, there’s something earlier on in the process I need to figure out to get that external identity to authenticate to my Azure AD first. I think I misunderstood or misinterpreted FAS’s role in that, I thought it was kind of the piece that helped broker that from Azure to Citrix Cloud for an external ID.

        Reply

        1. I got part of the problem solved. The users are now able to log into the citrix cloud workspace with their own external identity, but it shows no apps or desktops, which I believe means the UPN claim to the AD shadow account is still not working. I think what should be happening is Azure AD is passing their external identity in and making a UPN claim on an internal AD account which is in a group that has those apps and desktops provisioned in Citrix Cloud.

          I am assuming this needs to be tweaked in the Azure AD Enterprise Application, single sign on properties. My external ID users are their own Azure AD tenants, so supposedly you don’t need to do any configuration of ADFS, etc. How do I make these external ID logins also claim the internal AD account that is in a group membership that is set up to receive the correct Citrix Apps??? Any thoughts on what I am missing? Thanks for your continued help!

          Reply

  34. Anyone have a definitive answer as to exactly what level of Azure AD licensing is required for a ‘non-gallery application’? You definitely need at least P1 / EM+S for Conditional Access, but if you were to initially deploy without CA then do we know if the Azure AD Free and/or what you get included with Office 365 / Microsoft 365 Business is sufficient.

    https://azure.microsoft.com/en-gb/pricing/details/active-directory/ doesn’t really seem to give a specific answer on this.

    Thanks

    Reply

    1. I have an account without Premium and it seems to let me add “non-gallery”. Conditional Access tells me I need a P1 license. Licenses > Licensed Features shows you what you have access to, and Federated Authentication is one of them.

      Reply

  35. Carl, fantastic article, but I have one issue. In your Citrix ADC SAML Configuration you have this line:

    Workspace app support – If you bind a SAML Authentication Policy directly to the Gateway Virtual Server (no nFactor/AAA), then Workspace app and Gateway VPN plug-in won’t work.

    However when I go to nFactor document, the instructions are not clear as to how to configure nFactor for SAML. Should I still create the standard saml policy, and then attach it to an nfactor authentication. The direction is not clear on how to make saml work with nfactor. ADFS is my IDP, I have everything else configured, this is completely blocking me from finishing and would love some assistance.

    Thanks Carl, any advice would be great!

    Reply

    1. Create an Advanced Authentication Policy of type SAML with expression “true” or something like that. You can reuse your existing SAML Server.

      Create a non-addressable AAA vServer and bind the Advanced Authentication Policy to it.

      On your Gateway, add an Authentication Profile and select the AAA vServer. This overrides whatever authentication policies you have bound to your Gateway.

      Reply

  36. Hi Carl – excellent write up. I am still a bit confused as to if I need FAS in place in my use case or not. I have as Azure AD, connected to Citrix Cloud where I am hosting virtual desktops/apps. We are bringing on other customers who would like to authenticate with their own corporate ad credentials and not have a second username and password (ours) to remember. I was looking at the route of Citrix FAS to enable all of this, but then got to wondering if I can’t just set up the federation natively and directly in Azure AD, where their email address maps/claims a shadow acct on our Azure AD, which then maps to and authenticates them to the Citrix resources via AD groups. Citrix is then still using that AD account on our AD as it is today, the user at the new customer is signing in with their AD account/email, and we cut the need for FAS servers out of the picture. Am I wrong on that? Am I missing something? Feels like I am. Thanks in advance!

    Reply

    1. VDAs are joined to AD domain. Ultimately, the user must log into the AD domain.

      SAML does not provide the user’s password to StoreFront so it’s not possible for StoreFront to tell the VDA how to sign in the user. As an alternative, FAS can generate a certificate for each AD user and the VDA can use that certificate to sign in as the user. Without FAS, the VDA will prompt the user to enter AD credentials.

      Reply

      1. Ok, I think I see what you’re saying… For the sake of clarifying and making absolutely sure I understand, Here is what we have currently. Our Citrix Cloud Gateway points to my AD today, let’s say it’s XYZCLOUD.COM domain. We have our customers set up with domain accounts like JOEUSER@XYZCLOUD.COM and they go to Citrix workspace portal and log in with that credential and run their VDA’s, which are all also in that domain.

        Now, the customers want to instead sign in with their own JOEUSER@CUSTOMER.COM credentials. If I go on my domain controller, Active Directory Domains and Trusts, add @CUSTOMER.COM to the domains trust list, then in JOE USER’s XYZCLOUD.COM account, I change the user logon name to JOEUSER@CUSTOMER.COM, if JOE USER puts in his CUSTOMER.COM password, it won’t just pass through to the XYZCLOUD account\claim\upn? At that point of login, Citrix Workspace needs access to the customers AD Password, which it doesn’t have. Thus the need for FAS to facilitate certificate based authentication. Is that right? Is FAS the best way to solve this problem? I think it is based on your answer above. Also, do you have any idea when it will be out of technical preview for workspace and made GA? Thanks again!!

        Reply

        1. Hi Carl and Brett,
          We have a similar client request to allow SSO from an external AD (customer.com) with a different on premise AD (xyz.com) with StoreFront and ADC via the ADC web portal. Both AD do not communicate with each other currently and are separated over the Internet. I.e. j@customer.com wants to SSO to published apps via j@xyz.com. Do we also need setup ADFS and trusts between customer.com AD and xyz.com AD? Will setting Citrix FAS with corresponding ADC and Storefront settings suffice? Thank you very much.

          Reply

          1. Ultimately, you need accounts in a local AD that the VDAs trust. If users are from a different non-trusted forest, then add that forest UPN suffix to the VDA forest and create shadow accounts in your VDA forest with UPNs that match the foreign UPN.

  37. Hi Chris,

    Great post! i’m looking to follow this and stand up a POC in our environment. The VDA’s that will be using FAS for SSO are all Azure Hybrid AD joined. Do I still need FAS. For my POC deployment I am planning to put this is just asking as i can’t find anything about Azure AD hybrid joined VDA’s and FAS.

    Many thanks in advance for any guidance on this!!

    Reply

    1. FAS is only needed when Citrix StoreFront does not have access to the user’s password and if Citrix Workspace app Single Sign-on does not have access to the user’s password. SAML is the typical reason for deploying FAS.

      Reply

  38. Carl,

    This is obviously a great article and you are a great resource. We have recently decided we wanted to use AzureAD as our IDP for our external Citrix Gateway. We are getting the generic error most users are getting with the PublicKeyToken=Null.

    When doing a cat aaad.debug we can see the SAML assertion happening at the external netscaler gateway, but we get the “Cannot Complete Request” when storefront tries to retrieve the users apps.

    We previously used LDAP and when we revert to that all seems to work well. I have tried several things based on this article with no luck.

    One thing I know is that with LDAP you will get a list of AD groups the user is a member off when you look at the aaad.debug, but with SAML you just get a large bundle of an assertion.

    Storefront historically uses AD groups to decide on which apps a user gets, so I was thinking that was the problem, but I could be way off.

    Any ideas why the SAML assertion seems to be successful, but Storefront continues to give the same error? I would really like to get this to work and it seems we are so close.

    Thanks,

    Jon Toler

    Reply

  39. Hi Carl,

    If I were to setup a pair of ADCs in a DMZ with external and internal CVADs users under consideration:
    I’d use Azure AD as my IdP + SAML config + FAS etc.

    I think I understand how the external flows/auth work to get the users to their apps+desktops.

    My question is for the internal network users.
    What address should they be connecting to if we wanted either Username/password to still be required or SSO?

    What’s a “standard” practice for that kind of setup?

    Thanks for your help,
    Colin.

    Reply

    1. Internal users should go to the FQDN that resolves to the StoreFront load balancing VIP, not the Gateway VIP.

      Reply

      1. Thanks.

        So that means an internal user would present their UPN and Password only to gain access (as the MFA setup is on the Gateway VIP?

        Reply

  40. Hey Carl,

    As per one of your earlier replies:

    “Workspace app support – If you bind a SAML Authentication Policy directly to the Gateway Virtual Server (no nFactor/AAA), then Workspace app and Gateway VPN plug-in won’t work. To support SAML with Workspace app and Gateway VPN plug-in, configure nFactor (Authentication Virtual Server with Authentication Profile) instead of directly on the Gateway Virtual Server. Note: nFactor authentication is only available with ADC Advanced Edition and ADC Premium Edition.”

    So, does that mean you can bind a SAML policy to a Gateway VS (on Standard edition ADC) and then you access your Apps+Desktops using the standard Citrix storefront/website (i.e. don’t use the workspace app)?

    Thanks for any help,
    Colin

    Reply

  41. Thank you Carl. Can you still say something about how the whole thing must be built, if you want to operate multiple domains with it. Both in a forest and without a forest and only as a mutual trust?

    Reply

  42. I got pass that by changing the Global authorization policy. I guess the latest ADC 13 build change the default behavior to Deny instead of allow but I still having problem after that, getting 403 – Forbidden: Access denied. So I guess Netscaler didn’t pass the credential correctly to storefront or the SAML transformation is wrong? What log should I look at to figure out?

    Reply

    1. I guess I’m trying to answer my own question but I had it working now without the FAS component. The key was the Netscaler Callback URL has to be configured and accessible from Storefront and the routing and firewall configuration of the netscaler making it very difficult. The VIP is in the outside subnet and the storefront is part of the SNIP so getting the VIP to answer query from storefront requires a PBR configured. Now I want to ask you if it is possible to use KCD instead of FAS for SSO into the VDA?

      Reply

      1. Any Gateway VIP on the same appliance would be acceptable.

        KCD was supported in 6.5 but not in 7.x. FAS is the replacement.

        Reply

  43. I tried this instruction to integrate with Azure AD. I didn’t setup FAS yet and just try authenticate with storefront but after successfully sign in with AzureAD. I got “Error:Not a privileged User.” What could be wrong? You instruction also didn’t say configuring STA like the standard Gateway configuration. Is that needed?

    Reply

  44. I configure the access through NetScaler to a Virtual apps farm using ADFS.
    Could you help me, because when I configured the endpoint rule for logout in the ADFS console, I don`t know if this one is correct “https://adfsurl/adfs/ls/?wa=wsignout1.0”.
    Currently when I log off, I need to close the web browser. is that correct? or I need to change the logout fqdn?

    Thanks,

    Reply

    1. Same issue here with ADC and ADFS.
      If one reloads the page after the logout without closing the browser first you are immediately logged in again without any need for re-authentication through ADFS.
      No progress with Citrix support and many other people experience the same issue with different IDPs.

      @Carl: could you help us out?

      Reply

  45. Is there a way to set some sort of timeout the first time our users login they are redirected to Azure SAML and sign in then get into Storefront and can launch their desktops, However after their first authentication if they hit the Citrix Gateway address you are just sent right to Storefront without having to reauthenticate. We want a user to have to type in creds every time they go to our gateway. I have checked in storefront timeout is configured there as well as the default 30 minute timeout under client experience in the gateway policy itself.

    Reply

      1. unfortunately that’s not it if I run a show aaa sessions it does clear them out. here is a question, since I had this setup first using LDAP and only later changed to SAML do I need to change some sort of policy so the logout URL is redirected to the AzureAD SAML logout URL? like in the Citrix Gateway policy? I am thinking when you physically click logout it is smart enough to go to the logout URL set int he SAML policy but when it times out is the policy not sending it to the logout URL or something like that.

        Reply

      2. I figured out a work around in the SAML auth setting I used the checkbox to “Force Authentication” so basicaily everytime they hit the gateway (if they have timed out or not) it forces them to type in creds which work well for us

        Reply

  46. Hi Carl, thanks for this great guide, but I am stuck after SAML authentication at Azure AD. Storefront keeps logging event ID: 3 “A communication error occurred while attempting to contact the NetScaler Gateway authentication service at https://NetscalerVserver.domain.com/CitrixAuthService/AuthService.asmx. Check that the authentication service is running.”

    I can reach the NS vServer URL from the storefront, and the cert is good. If I try to browse to /CitrixAuthService/AuthService.asmx, I just get error “The resource cannot be found”.

    Is something on the netscaler supposed to catch this request and redirect to the Auth Service?

    Any help appreciated.

    Reply

    1. I wonder if SSL mismatch.

      What kind of certificate on the Gateway? Is it RSA (not ECC)? It is 2048-bit key?

      Have you changed the SSL Parameters or SSL Ciphers on the Gateway? Is Client Authentication (aka client certificate) turned off?

      Reply

      1. Thanks Carl. The cert is a GoDaddy Wildcard. I did not change any SSL Params or Ciphers on the new vServer Gateway that I built just for this. Where do I turn on/off Client Authentication?

        Reply

        1. I am running into the same issue that Chris discribed. I had it working the Azure AD as the IdP, but then I rolled back to LDAP since I was just testing. Now I cannot access the https://citrixgw.domain.com/CitrixAuthService/AuthService.asmx URL. I just get a 404 error. I rebooted both netscalers and it made no difference. I do not get any certificate errors. The certificate is 4096-bit and was installed over a year ago and is good until 2021, so I doubt that is the issue. I am not sure why it was working and then stopped working once I rolled my changes back. I may have to contact Citrix to work through this issue. I will post back if I find a resolution.

          Reply

          1. We ran into the same 404 error page on that URL. We resolved this error by ensuring the intermediate and root certificates to our ADC URL are installed on the server with both storefront and controller. We also ensure both servers are installed on ADC and link the intermediate cert to the root cert.

            Hope this can help.

  47. What licencing level do you need on the Netscaler and in Virtual Apps to be able to use FAS to complete Azure MFA authentication for external users?

    Reply

    1. For SAML on Gateway, I’m not aware of any licensing requirements. For nFactor (for Workspace support), you’ll need ADC Advanced Edition. The web-based SAML only seems to work in Workspace App if you configure nFactor.

      FAS is in all CVAD editions.

      Reply

      1. Thanks Carl. I have a few clients with the following in place :

        Azure AD Connect with Password Sync (No ADFS)
        Azure MFA setup for users with conditional access to not require MFA inside corporate network
        Citrix Gateway 13 On Prem. Only Proxies ICA traffic.Platform licence only.
        Virtual Apps & Desktop 7.15 and above

        What would you consider the best way to implement Azure MFA for these environments? Do we need to move up licence levels or is it achievable with what is there?

        Reply

  48. Hi Carl,

    Great write up and was exactly what I needed to help me understand the process.

    We are using an F5 as an IdP for StoreFront, version 1912, and have been very successful with it. We have run into one intermittent issue where the SAML IdP process appears to be completing as it should and providing the SAML Assertion back to StoreFront as the SP. Debugging the Assertion always shows the same info, as in a proper UPN for each user, but StoreFront is on occasion throwing back a “Mapped Account” error.

    Digging into trace files on StoreFront, I have found where the SAMLForms process is started and there is an entry about starting communications, but then there is a 60 second period of no activity and then the Mapped Account error. On a good login at the same point of the SAMLForms, I see the same starting communications entry with an immediate communications finished and an entry with a response from the FAS.

    Trying to work with Citrix Support is a no go since we are not using one of the “supported” methods, even though they claim they are SAML compliant and my Assertions from the IdP are proper.

    The StoreFront servers are on a different subnet than the FAS, bvut when this issue occurs, I am not seeing any traffic in my firewall fro from the StoreFront. Just trying to get a second opinion that this a a StoreFront to FAS communication issue and has nothing to do with the IdP once a proper assertion is handed off.

    Reply

    1. Why SAML to F5 instead of normal F5 iApp-to-StoreFront authentication? StoreFront can talk to F5 just like it does with NetScaler Gateway. Typically you configure the F5 iApp to talk to StoreFront. Then configure StoreFront with an F5 URL as the Gateway Callback.

      Also, if F5 is collecting the user’s password then FAS isn’t needed.

      Reply

      1. So the process flow is we hit a set of load balanced StoreFronts, 2 of them, for the initial connection through the F5. StoreFront then redirects to a F5 URL that handles the SAML auth, and then the client is then redirected back to the StoreFront using the same session with the SAML Assertion.

        Once the StoreFront receives the assertion, it is talking to the FAS for the client certificate creation and the authorization portion. It appears we are having the intermittent issue once the StoreFront tries to talk to the FAS for that certificate.

        Reply

        1. Understood. But rather than troubleshooting SAML and FAS, why not configure the F5 iApp to behave like a NetScaler Gateway?

          I’ve seen problems with configuring SAML directly on StoreFront so I typically advise putting a NetScaler in front of it and using normal NetScaler Gateway -> StoreFront SSO. Your F5 iApp can do the same.

          Reply

          1. Ahhh, I understand what you are saying now. We had F5 professional services set this up, and they partially used the iAPP, for us and this is the way they did it.

            We are now in a bit of a crunch for a go live on this new system, but once things settle down, I may try and talk them into getting me a dev setup I can test this out with.

            Thanks for taking the time to respond.

        2. Robert would be prepared to share some more detail on how you configured the F5 to handle the SAML and pass back to the storefront servers

          Reply

  49. Hi Carl – I have a client that implemented Windows Hello for Business using On Prem AD for their workstations logins which broke SSO thru Citrix Receiver/Workspace App to the VDAs. Would FAS help us in this situation?

    Reply

  50. Very nice post as usual !

    Could you tell me if FAS can use other attribute than UPN ? Example: email attribute ?

    I have to implemente the solution for a customer with existing account and the UPN is totally different from the email address. Email address are base on firstname.lastname@domain.com and UPN are base on a random number.

    I want to know if I can use the user account in order to avoid to create new user, new profile,…

    Thanks for your answer.

    Julien

    Reply

    1. StoreFront needs to match an incoming attribute with a specific AD Account. I think only UPN works. You might be able to configure your IdP to send the UPN to ADC in an attribute and then configure an ADC traffic policy to use the SAML attribute as the user name.

      Reply

      1. Thanks Carl for your answer. I have to address two types of connections:
        – remote users who will use Citrix ADC (I will try to use your advice
        – internal users who will use direct SAML on Storefront (I have to check if I can do some attributes mapping).

        Thanks again for your time

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *