Citrix Federated Authentication Service (SAML) 7.16

Last Modified: Dec 14, 2017 @ 11:20 am

Navigation

This article applies to Federated Authentication Services versions 7.16, 7.15.1000 (LTSR), 7.14, 7.13, 7.12, 7.11, and 7.9.

Changelog

Overview

Citrix Federated Authentication Service enables users to login to NetScaler Gateway and StoreFront using SAML authentication.

Citrix Federated Authentication Service uses Microsoft Certificate Authority to issue certificates on behalf of users. These certificates are used for the StoreFront and Virtual Delivery Agent logon process.

Requirements:

  • Microsoft Certificate Authority in Enterprise mode
  • XenApp/XenDesktop 7.9 or newer
  • StoreFront 3.6 or newer
  • NetScaler Gateway. Note: StoreFront 3.9 and newer also supports SAML authentication natively without NetScaler.
  • Receiver for Web only.
  • Receiver Self-Service for Windows 4.6 and newer supports SAML auth when connecting to StoreFront native SAML without NetScaler.

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.

Also see the Citrix Federated Authentication Service Scalability whitepaper.

Federated Authentication Service Versions

The most recent Federated Authentication Service Current Release is version 7.16. Current Releases are only supported for 6 months from release date and are expected to be upgraded every 3-6 months.

The most recent StoreFront Long Term Service Release (LTSR) is version 7.15.1000. LTSR versions are supported for 5 years from release date. Cumulative Updates are released periodically.

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.

Federated Authentication Service 7.16 is a Current Release, which is only supported for 6 months from release date. You are expected to upgrade it every 3-6 months. For longer term support, install Federated Authentication Service 7.15.1000 LTSR.

  1. On the Federated Authentication Service server, go to the XenDesktop 7.9 or newer ISO, and run AutoSelect.exe.
  2. In 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. In the Finish Installation page, click Finish.

FAS Group Policy

  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 this 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 Configuration

  1. From the Start Menu, run Citrix Federated Authentication Service as administrator. Make sure you run it elevated.
  2. The Federated Authentication Service FQDN should already be in the list (from group policy). Click OK.
  3. In Step 1: Deploy certificate templates, click Start.
  4. Click OK to add certificate templates to Active Directory. Sufficient permission is required.
  5. Note: the deployed Certificate Templates have Autoenroll enabled. You might want to disable that.

    1. On the Security tab, check every group assign to the template.
    2. Repeat for the other two templates.
  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.
  9. 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.
  10. Select the issuing Certificate Authority, and click OK.
  11. Step 3 is now yellow.
  12. Go to the Certificate Authority Console > Pending Requests. Find the pending request and Issue it.
  13. 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.
  14. 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.
  15. After authorization, switch to the User Rules tab.
  16. Use the Certificate Authority drop-down to select the issuing Certificate Authority.
  17. Use the Certificate Template drop-down to select the Citrix_SmartcardLogon template.
  18. Click Edit next to List of StoreFront servers that can use this rule.
  19. 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.
  20. On the bottom half, make sure Assert Identity is Allowed. Click OK.
  21. By default, all users and all VDAs are allowed. You can click the other two Edit boxes to change this.
  22. When done, click Apply.
  23. Click OK when Rule updated successfully.
  24. 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

  1. On the StoreFront 3.6 or newer server, run the following elevated PowerShell command:
    & "$Env:PROGRAMFILES\Citrix\Receiver StoreFront\Scripts\ImportModules.ps1"
  2. 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"
  3. If you have multiple StoreFront servers, Propagate Changes.
  4. On a XenDesktop 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 ""

NetScaler Gateway Config

SAML on NetScaler Gateway

Configure the SAML iDP:
Every iDP has unique instructions. Search Google for your iDP and NetScaler and you might find a iDP-specific guide.

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. NetScaler doesn’t have a SAML metadata service, but you can create a metadata file manually by following the instructions at Citrix CTX133919 How to Configure NetScaler SAML to Work with Microsoft AD FS 2.0 IDP.
  3. Otherwise, select the option to enter relying party data manually.
  4. For the Assertion Consumer Service URL (aka relying party service URL), enter the URL to your NetScaler Gateway with /cgi/samlauth appended to the end (e.g. https://gateway.corp.com/cgi/samlauth)
  5. Enter a Relying party trust identifier. You must specify the same identifier (Issuer Name) on the NetScaler as detailed soon.
  6. Configure the SAML iDP to send email address or User-Principal-name as Name ID. NetScaler 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.
  7. NetScaler will sign the authentication requests it sends to the iDP. On the NetScaler, you will soon configure the NetScaler signing certificate with private key that signs the requests. In your SAML iDP, import the same NetScaler signing certificate but without private key.
  8. Copy the SAML authentication URL (aka Token Issuance URL) from your SAML iDP. You’ll need to enter this same URL on your NetScaler later.
  9. Export the iDP Token-signing certificate from your SAML iDP. The iDP could be ADFS, Okta, Ping, etc.

Configure the NetScaler:

  1. Instructions for NetScaler 11.1 and NetScaler 12 are essentially the same.
    • NetScaler 11 is very similar, except the Certificates are in a different place in the menu tree.
  2. On NetScaler, import the iDP SAML token-signing certificate (without private key) under Traffic Management > SSL > Certificates > CA Certificates. NetScaler uses this certificate to verify the signature of the SAML assertion from the iDP.

  3. Move up two nodes to Server Certificates and Import or create a NetScaler SAML signing certificate with private key for signing of SAML authentication requests to the iDP. This can be the same certificate used on NetScaler Gateway. Or a more common practice is to create a self-signed certificate.

    1. You’ll also need to import this NetScaler SAML SP signing certificate (without private key) to your SAML iDP so it can verify the SAML authentication request signature from the NetScaler.
  4. Go to NetScaler Gateway > Policies > Authentication > SAML. The quickest way to get here is to enter SAML in the search box on top of the menu.
  5. On the right, switch to the Servers tab, and click Add.
  6. Enter the information for authenticating with your SAML iDP. This configuration will vary depending on your SAML iDP.
    1. For iDP Certificate Name, select the SAML iDP’s certificate that was exported from the SAML iDP and imported to NetScaler. NetScaler will use this iDP certificate to verify SAML assertions from the iDP.
    2. For Redirect URL, enter the URL to the SAML iDP’s authentication page. NetScaler 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 iDPs, get the URL from your iDP.
    3. For Signing Certificate Name, select the NetScaler certificate (with private key) that NetScaler 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.
    4. Enter an Issuer Name 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.
    5. Scroll down and click More.
    6. NetScaler defaults to SHA1. You might have to change the Signature Algorithm and Digest Method to SHA256.
    7. Review the other settings as needed by your iDP. Click Create when done.
  7. On the right, switch to the Policies tab, and click Add.

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

    1. On the Published Applications tab, make sure Single Sign-on Domain is not configured.
  10. Create a NetScaler Gateway Virtual Server if you haven’t already.
  11. Edit your Gateway Virtual Server. Go to the Basic Authentication section, and add a policy.
  12. Bind the SAML policy. This is the only authentication policy you need. You can remove all other authentication policies.

  13. Next step: configure StoreFront for SAML NetScaler Gateway.

StoreFront Config for SAML NetScaler Gateway

  1. In StoreFront 3.6 or newer, right-click the store, and click Manage Authentication Methods.
  2. Make sure Pass-through from NetScaler Gateway is selected.
  3. Click the 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 NetScaler 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 NetScaler

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

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

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), 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. Currently, the only supported configuration is ADFS with SAML to StoreFront without NetScaler.
  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.

207 thoughts on “Citrix Federated Authentication Service (SAML) 7.16”

  1. Hi Carl

    I want to integrate Netscaler SAML authentication with Azure AD, i have 3 customer each one of them has Azure AD.

    Can i create SAML authentication policy for each customer with SAML idp server ? pls note i have only one netscaler here.

    Each customer has his own citrix Farm at the backend.

    1. If users go to the iDP first, then you might be able to bind multiple SAML SP policies to the NetScaler Gateway.

      However, if the user goes to NetScaler Gateway first, then NetScaler might not know which iDP to redirect the user to.

        1. In Azure AD, create the NetScaler Gateway SP application. Users go to the Azure AD portal and there should be an icon for NetScaler gateway.

          1. Hi Carl

            Can you please send me citrix document which shows me how o create Netscaler SP in Azure AD .

            Thank you in advance

            Best Regards
            Basem

  2. I plan to use PingFederate services (with SAML Browsing) to authenticate my users during the netscaler access process. Is the FAS required in this case ? what will happen if i don’t install FAS ? the VDA logon won’t be SSO passtrough ? Will i get a prompt to reenter a username/pwd on the XA/XD workloads ?

    1. Without FAS, the VDA will prompt the user to enter username and password. This is the password for the shadow account, not the iDP account.

  3. Hi Carl, in Step 11 under ‘FAS Group Policy’ section, I think you need to add FAS, VDA and SF servers from Domain B to Windows Authentication Group in Domain A as per CTX220497….. not Domain B.

    Which brings the obvious question – how can step 11 be accomplished without a 2 way trust in place? If 2 way trust is needed, why bother eith FAS then?

    Kind regards
    Quazi

    1. Thanks for pointing that out. It should be updated now.

      I suspect the multiple domains in this case pertains to the shadow accounts being in a different domain than the Citrix machines.

  4. Hello Carl,

    I have the following environment:

    1) Domain A, where our office users reside. This domain only has the local user workstations which run Citrix Receiver with SSO configured. Domain A also has ADFS v4 (WIndows Server 2016) which is used as SAML IDP. We need to have users logging in to domain A to be able to SSO to our XenDesktop 7.15 LTSR VDAs which are deployed in domain B (see below).

    2) Domain B, where we have a XenDesktop 7.x delivery site, with 7.12 delivery controllers, 7.15 LTSR storefront servers and 7.15 LTSR VDA. We also have separate Citrix FAS server configured (latest version from VDA LTSR 7.15 binaries) and working with domain B PKI infrastructure (WIndows Server certificate services enterprise root CA). We have Netscaler VPX 10.5 configured with Netscaler Gateway, which is used as SAML SP.

    The issue is the following:
    ==========================
    When a user logs on to their local machine in domain A, they open a Web browser and point to the URL of Netscaler Gateway. They are automatically logged on to Netscaler Gateway via SAML and the the Storefront page is shown where the user can click on a published desktop. When the desktop is being launched, it gets all the way to the VDA machine, where the Windows Server LogonUI is shown but user does not get automatically logged on, screen stops at VDA logon. It seems that the necessary user certificates are not automatically populated, even though there are no errors in the FAS server. Even if we populate the user certificates via Powershell, the logon still stops on the VDA LogonUI screen.

    I have checked event logs on DDC, VDA, Storefront, FAS and PKI servers without any apparent sign. Any ideas on what else I could be checking?

  5. Hi Carl,

    Is there any way to integrate Netscaler with multiple Azure AD account, My scenario is using only one VIP with multiple saml policy for external Auth, group A has its own SAMl policy and their own Citrix ( Storefront, Delivery controoler, VDA ..) and group B has the same as group A, is there any way to tell the netscaler which saml to use for authentication if the user come from Group A, or Group B ?

    Thank you in advance.

    Kindest Regards
    Basem Shalabi

    1. Maybe if iDP initiated since I don’t think Citrix has an easy way to allow users to choose an iDP without using multiple FQDNs. Then maybe you would need Default Syntax Session Policies with expressions like http.REQ.USER.LOGIN_NAME.SET_TEXT_MODE(IGNORECASE).CONTAINS(“myupnsuffix.com”) to select the correct Session Policy for each iDP.

      1. Thank you Carl, i did not find that expression from the expression drop down list , Can i add this expression at the SAML policy level ?

        Thank you.

        1. Default Syntax for Session Policies requires NetScaler 12. The expression would only work after a login has been performed, not before.

          You could use HTTP.REQ.URL.HOSTNAME.EQ(“idp1.myurl.com”) to select a SAML Policy based on a unique FQDN. This implies that the certificate matches multiple FQDNs. And assumes Default Syntax Authentication Policies (nFactor) instead of Classic Expression.

  6. I’m having issues when accessing storefront from a IDP. I get “cannot complete request”. From the event log on Storefront I get two errors:

    Access is denied. Contact your system administrator.
    Citrix.DeliveryServices.Security.Claims.Specializations.Fas.MissingUpnException

    Followed by:

    A CitrixAGBasic Login request has failed.
    The remote server returned an error: (403) Forbidden.
    Url: https://127.0.0.1/Citrix/samlAuth/CitrixAGBasic/Authenticate

    I belive that the SSO from netscaler to storefront is the problem. I have checked my session policies multiple times. There is a CS(content switch) in front of the Netscaler vserver.

    1. One of your StoreFront servers should have an event indicating an issue with the Callback URL.

      Or, in StoreFront Console, go to Stores. in the middle, right-click your store. Click Manage Receiver for Web sites > Configure > Advanced. The third line is “loopback”. Change the drop-down from On to OnUsingHttp.

    2. In case anybody else is having the same issue:

      Mine was caused by me copying an existing session policy with SSO domain filled from before. I had to enable the field and clear it’s contents, then save. To have Netscaler SSO to Storefront.

  7. Hi Carl

    I made FAS working and was able to startup published desktop and apps (WS 2016, XA 7.15). But now it stopped and I get the message “wrong username or password” at the login (blue background of WS 2016, NOT a blue screen).

    I verified FAS and see the certs with the PS command.

    Any hint where I can look into?

    Thanks
    Udo

          1. So I found out that 2 of 3 VDA have this problem. When I connect to the first, everything is working fine all the time (publ app and desktop). VDA 2 and 3 showing this error every login.

            So I double-checked the FAS rule and the list of VDA includes all 3 VDA and rule is set to apply. I removed VDA 2 and 3 and re-added them but still no success.

          2. They are in the correct OU that gets the GPO that enables FAS? Check HKLM\Software\Policies\Citrix and somewhere under there is the FAS address.

          3. Argghhh – you made my day! The GPO was not linked to the correct OU. I worked with FAS earlier this year and only adjusted the server name but not the linked OU.

            Thanks a lot!
            Udo

          4. Didn’t hold that long… I can start published apps but with the desktop I’m getting the same error again.

            Any hint?

  8. Carl,

    I was wondering in you knew if it was possible to store the FAS RA private key on and HSM and still store the smart card logon keys on the FAS server? If so, could you point me in the right direction of configuring this? Based on my research, its seems you have an all or nothing option on where to store private keys (FAS, TPM, or HSM). Thanks in advance

  9. Thank you for all this information, it has been very usefull.
    Do you happen to know how i can set the ‘Fully delegate credential validation to NetScaler Gateway’ option with powershell?
    I ask because i have a storefront deployment with multiple iis sites so i can not use the console.

    1. I figured it out, maybe usefull for someone else:
      set-STFCitrixAGBasicOptions -AuthenticationService $auth -CredentialValidationMode Auto

  10. Thanks for the hard work Carl,
    Im having trouble wrapping my head around something. After I configure FAS and users are being logged into the VDA with certificates, when users access other service providers (within the VDA), such as office 365, or gmail, is SSO available? Is that where the Group policy setting “In-Session Certificates” comes in? We us Shibboleth as our idp.

    1. Password is not available. If you need password for SSON, then it won’t work. But Kerberos should work fine (e.g. ADFS with Integrated Windows Authentication).

        1. FAS is needed if you want to SSON to the VDA. Otherwise, the VDA will ask the user to login to the domain with username and password.

  11. Hi Carl,

    An update: I checked old logs and it looks like the SP-init SLO never worked properly. I don’t see any instance where the NetScaler has sent a SAML SLO to PingFederate. Other then specifying the “Single Logout URL” in the NetScaler config, is there something else we need to do to enable SLO from StoreFront?

    We tried to follow the aforementioned Citrix doc (https://support.citrix.com/article/CTX200392), but its unclear where to bind the TM action/policy. Can you provide some guidance and/or links to docs on how to do that with NeScaler 11.1 and StoreFront 3.9?

    Your help is much appreciated!

    Thanks,

    Jim

  12. Hi Carl,

    We are trying to configure SLO between NetScaler 11.1 and PingFederate. What wasn’t clear in Citrix documentation was what SLO endpoint to use on the NetScaler. I did find a Citrix support doc (https://support.citrix.com/article/CTX200392) that indicated a URL of: netscaler.com/cgi/tmlogout

    Is that the correct URL? That support doc discusses SP-init SLO…does the NetScaler support IdP-init SLO? In our testing the SP-init SLO seems to work fine, but when we send a SAML SLO assertion to that same endpoint we don’t get a response…and the user’s session isn’t terminated in StoreFront.

    Thanks,

    Jim.

  13. Hi Carl,

    I’m planning to upgrade XenApp with latest version 7.14.1, also would like to upgrade SAML with latest one, Is there any upgrade docs for SAML?

    Thanks,
    AJ

      1. Thanks for the quick reply Carl.

        Yes It’s FAS. Do I need to make any changes/upgrade on CA (Certificate Authority) server as well? Would you please help me upgrade sequence for XenApp 7.12 to 7.14.1?

        This is what I’m planning: VDA -> Delivery Controller -> StoreFront

        Thanks,
        AJ

  14. Karl, I also ran the Verify FAS procedure above and FAS is generating certs. Can I assume if I am getting “The UserID or Password is incorrect” message, then the generated cert is not correct? Thanks.

  15. Hi Carl

    Thank you for article. i have configured Citrix FAS for citrix authentication. netscaler has configured with Azure AD idp . When i am trying to start Application i am keep getting windows Login Prompt. all delivery agent servers able to communicate with FAS and domain controllers, but the is no problem in application start for different VDAs which is located in different network segment.

    Would you please advise

    Thank you.

  16. Karl, I get this message when I launch an app. I get a windows sign in screen with “The user name or password is incorrect”. I have looked for events on the S.F., FAS, and DC servers. Any ideas where to look? Thanks

  17. Is there a possibility to have two FAS servers ? build a loadbalanced FAS, just like any other component is HA in my Citrix,
    Thanks,

  18. Hi Carl

    Can you use a Standalone CA (i.e., not an Active Directory integrated CA) in using FAS, as long as you add the cert of your standalone CA to the Trusted Roots store on your VDAs/Storefront servers?

    Thanks

    1. The Enterprise CA is needed to issue certificates for each user and link them to Active Directory users.

      1. Hi Carl,

        I am totally new to ADFS and would like to learn and get a better understanding of how it can be used for enabling users from Domain A (client domain) to be able to launch a XenApp or XenDesktop session in Domain B (resouce domain) the two domans do not trust each other. Both domains are in the same organization all be it they live in two separate network subnets with a firewall. Can I acheive this using the steps you have shown?

        Thanks!

        1. Yes. If internal only, then StoreFront has native support for ADFS and FAS.

          Note: you must create accounts in Domain B for each of your users. The passwords don’t matter. The Domain B users are for authorization and identity mapping. What SAML does is avoid you having to synchronize passwords between the domains. And when you delete a user from Domain A, it can no longer be used to login to Domain B.

          1. Thanks Carl for your quick reply. I take it I will first need to configure ADFS services on both domains before I proceed with the Citrix configuration steps? If so would you be able to suggest any good blog/guides for configuring ADFS.

          2. So I need only need to configure ADFS in the resource domain. Or is it the client domain which is where the identity and passwords will be provided from? I can’t seem to get my head round this one 🙂

  19. Hi Carl,

    After logging in ADFS opens with an error page. In eventlog:

    Encountered error during federation passive request.

    Additional Data

    Protocol Name:

    Relying Party:

    Exception details:
    Microsoft.IdentityServer.RequestFailedException: MSIS7065: There are no registered protocol handlers on path /adfs/ls to process the incoming request.
    at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

    I can open /adfs/ls/idpinitiatedsignon.aspx and I see my relying parties. When selecting NetScaler Gateway I get Http/1.1 Service Unavailable

    Any idea what this could be?

    Thanks

  20. This is a great article Carl. Question after i do the SAML authentication I can see the desktop and published apps. When i launch the application i get the desktop logon screen before federated authentication i was able to launch the app. Can you point me in the right direction.

Leave a Reply