Citrix Federated Authentication Service (SAML) 2003

Last Modified: May 7, 2020 @ 2:47 pm

Navigation

This article applies to Federated Authentication Service (FAS) versions 2003, 1912 LTSR CU1, 1909, 7.15.5000 (LTSR), 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
  • NetScaler Gateway or Citrix Gateway.
    • StoreFront 3.9 and newer also support SAML authentication natively without Citrix ADC.
  • SAML is web-based authentication and thus requires a browser.
    • SAML authentication might work in the newest builds of Workspace app and Citrix ADC 12.1 (and newer) if you configure nFactor. However, nFactor (Authentication Virtual Server aka AAA) requires ADC Advanced Edition or ADC Premium Edition.

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.
    • 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. For details, 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 2003.

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.
  2. In Citrix Virtual Apps and Desktops, or XenDesktop 7.13 and newer, in the lower half of the window, click Federated Authentication Service.
  3. Or in XenDesktop 7.9 through 7.12, on the bottom right, click Federated Authentication Service.
  4. In the Licensing Agreement page, select I have read, understand, and accept the terms of the license agreement, and click Next.
  5. In the Core Components page, click Next.
  6. In the Firewall page, click Next.
  7. In the Summary page, click Install.
  8. The installer might require a restart. Let it restart, and login again.

    1. After logging in, if you see a Locate ‘Citrix Virtual Apps and Desktops 7’ installation media window, don’t click anything in the window.
    2. Go to the Citrix_Virtual_Apps_and_Desktops_7_2003.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.
    6. Installation will resume.
  9. In the Finish Installation page, 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.
  12. 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.

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 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. 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.
    • If it doesn’t turn green, then there might be a private hotfix. See David Lloyd at Citrix Discussions.
    • Another user at XenDesktop 7.9 FAS at Citrix Discussions had to bump up the Validity Period of the Citrix_RegistrationAuthority_ManualAuthorization template to 2 days before it would authorize.
  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 have Autoenroll enabled. You might want to disable that.

  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. On a Citrix Delivery Controller, run the following commands:
    asnp citrix.*
    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 NetScaler 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

  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. Note: nFactor authentication is only available with ADC Advanced Edition and ADC Premium Edition.
  3. On Citrix ADC, 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.


  4. SAML IdP certificates are shown in the Unknown Certificates node.
  5. 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.
  6. 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.
  7. On the right, switch to the tab labelled Servers, and click Add.
  8. In the Name field, give the SAML Action a name that indicates the IdP’s name.
  9. 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.
    2. Scroll down and click Create.
    3. Edit the SAML Server again.
    4. 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.
  10. 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. 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.
    5. 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.
    6. Scroll down and click More.
    7. Citrix ADC defaults to SHA1. You might have to change the Signature Algorithm and Digest Method to SHA256.
    8. Review the other settings as needed by your IdP. Click Create when done.
  11. On the right, switch to the tab labelled Policies, and click Add.

    1. Give the policy a name, select the SAML Server, and enter ns_true for the expression. Click Create.
  12. Create Citrix Gateway Session Polices if you haven’t already.
  13. Edit your Session Policy/Profile.

    1. On the tab labelled Published Applications, make sure Single Sign-on Domain is not configured. Repeat this for your other Session Policies/Profiles.
  14. Create a Citrix Gateway Virtual Server if you haven’t already.
  15. Edit your Citrix Gateway Virtual Server.
  16. Scroll down to the Basic Authentication section, and add a policy by clicking the plus icon.
  17. Change the type to SAML and click Continue.
  18. Select your SAML policy and bind it. This is the only authentication policy you need. You can remove all other authentication policies.
  19. Next step: configure StoreFront for SAML Citrix Gateway.

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 NetScaler 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 NetScaler Gateway, and click OK twice.
  5. In StoreFront, add a NetScaler 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.

510 thoughts on “Citrix Federated Authentication Service (SAML) 2003”

  1. 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?

    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.

      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.

        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!

  2. 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

    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.

  3. 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!

    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.

  4. 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!

    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.

      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!!

  5. 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!!

    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.

  6. 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

  7. 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.

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

      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?

  8. 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

  9. 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?

  10. 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?

    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?

      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.

  11. 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?

  12. 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,

  13. 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.

      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.

      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

  14. 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.

    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?

      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?

        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.

  15. 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?

    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.

      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?

  16. 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.

    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.

      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.

        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.

          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.

  17. 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?

  18. 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

    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.

      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

Leave a Reply to Peter Cancel reply