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.

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.

On the Federated Authentication Service server, and VDAs, run gpupdate.

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.

Log into the FAS server as a Domain Administrator or Enterprise Administrator that can upload certificate templates to Active Directory.

On the FAS server, from the Start Menu, run Citrix Federated Authentication Service as administrator. Make sure you run it elevated.

In the tab named Initial Setup, in the row named Deploy certificate templates, click Deploy.

Click OK to deploy the templates to Active Directory.

In the row named Set up a certificate authority, click Publish.

Select an Enterprise Certificate Authority that will be issue the FAS certificates and click OK.

In the row named Authorize this service, click Authorize.

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.

The row named Authorize this service has a new icon indicating it is waiting on the registration authority certificate to be approved.

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.

Back in the FAS Administration Console, on the top right, click Refresh.

The row named Authorize this service should now have a green check mark.

In the row named Create a rule, click Create.

In the Rule name page, leave it set to Create the default rule and click Next.

In the Template page, click Next.

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.

In the In-session use page, click Next.

In the Access control page, click the link to Manage StoreFront access permissions.

In the Permission for StoreFront Servers page, add your StoreFront servers and give them the permission Assert Identity. Click OK.

Back in the Create Rule wizard, click Next.

In the Restrictions page, you can optionally reduce the VDAs that are authorized to use FAS. Click Next.

In the Summary page, click Create.

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.

Select a Certificate Authority to issue the certificates, and click Ok.

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.

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.

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.

After FAS authorization with the CA, in the FAS Configuration tool, switch to the User Rules tab.

Use the Certificate Authority drop-down to select the issuing Certificate Authority.

Use the Certificate Template drop-down to select the Citrix_SmartcardLogon template.

Click Edit next to List of StoreFront servers that can use this rule.

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.

On the bottom half, make sure Assert Identity is Allowed. Click OK.

By default, all users and all VDAs are allowed. You can click the other two Edit boxes to change this.

When done, click Apply.

Click OK when you see Rule updated successfully.

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:

SAML Configuration

SAML Flow

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.

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

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

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.

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.

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.

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.

Click Save. Then you might have to click the x on the top right to make it go away.

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

ADFS as SAML IdP

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

In your SAML IdP, create a Relying Party Trust (aka service provider trust) or new Application.

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.

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)

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.

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.

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.

Note: when you later create the SAML Action on Citrix ADC, there’s a place to add a SAML certificate. Unfortunately, the SAML Action is trying to import the wrong type of certificate since it wants the private key, which you don’t have access to. If you import the certificate here under CA Certificates, then there’s no prompt for private key.

SAML IdP certificates are shown in the Unknown Certificates node.

If you want ADC to sign the authentication requests it sends to the IdP, then do the following:

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.

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.

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.

On the right, switch to the tab labelled Servers, and click Add.

In the Name field, give the SAML Action a name that indicates the IdP’s name.

If your Citrix ADC is 12.1 or newer, then get the SAML Metadata URL (or file) from the IdP.

In the SAML Server on Citrix ADC, in the SAML IDP Metadata URL field, paste in the URL.

Scroll down and click Create.

Edit the SAML Server again.

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.

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.

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.

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.

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.

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.

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.

Scroll down and click More.

Citrix ADC defaults to SHA1. You might have to change the Signature Algorithm and Digest Method to SHA256.

Review the other settings as needed by your IdP. Click Create when done.

On the right, switch to the tab labelled Policies, and click Add.

Give the policy a name, select the SAML Server, and enter ns_true for the expression. Click Create.

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.

On the right, click the gear icon for SAML, and click Identity Provider.

Change the SAML Binding to the method your IdP expects.

Enter the IdP token issuance endpoint URL. For example, in ADFS, the path is /adfs/ls.

Click Import.

Browse to the signing certificate exported from your IdP, and click Open.

Then click OK to close the Identity Provider window.

On the right, in the SAML Authentication row, click the gear icon, and then click Service Provider.

Click the first Browse button.

Give the Signing certificate a name, and save it somewhere.

Click the second Browse button.

Give the Encryption certificate a name, and save it somewhere.

Copy the Service Provider Identifier. Or you can change it to your desired value. Then click OK.

In your IdP (e.g. ADFS), create a Relying Party Trust.

Import the Encryption certificate that you exported from StoreFront.

Enable SAML 2.0.

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.

For the Relying party trust identifier, enter the identifier you copied from the Service Provider window in StoreFront.

Configure the Claim Rules to send the user’s email address or userPrincipalName as Name ID.

Edit the Relying Party Trust. Import the Signing certificate that you exported from StoreFront.

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:

Open Active Directory Domains and Trust.

Right-click the top left node (not a domain node), and click Properties.

In the UPN Suffixes tab, add a UPN suffix that matches the email suffix provided by the SAML IdP.

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.

The password for these Shadow accounts can be any random complex password since the Federated users never need the Shadow account’s password.

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.

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:

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

Comment navigation

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?

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.

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!

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.

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.

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.

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!

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.

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

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.

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.

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.

“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)?

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?

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?

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?

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?

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.

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.

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

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?

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.

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.

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.

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.

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.

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.

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?

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,…

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.

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