We have had many customers shifting toward modern (usually SAML-based) authentication methods to secure access to their Citrix environments. This could include services such as Azure AD, Okta, Ping Federate, and others and often gives users a wider range of second/third/etc. factor options (text, call, PIN) than a traditional token.
This presents an inherent technical challenge, however, because now the Citrix Gateway and StoreFront server no longer have the user’s username and password — they have an SAML token. The SAML token cannot be passed directly back to the VDA for logon (Windows operating systems generally only accept username/password, Kerberos, or certificates as authentication methods). That means we are prompting the users for their credentials — and not providing an optimal user experience.
Federated Authentication Service
Enter the Federated Authentication Service (FAS), which integrates with StoreFront and the VDA to effectively swap that SAML token out for a user certificate. That certificate is inserted as part of the session-launch process to be used for authentication instead, thus achieving SSO to the VDA and avoiding additional authentication prompts being presented to the user.
While there is a good amount of information available in eDocs regarding how to install and set up FAS for the first time, I have had several customers struggle with how to troubleshoot this new component if issues do arise as this is a relatively new product (released with XenDesktop 7.9). This post is designed to walk you through a few common error scenarios to show where to begin and what certain combinations of events likely mean.
FAS Error Types
Generally, errors relating to FAS fall into two buckets:
- Launch errors — These mean the application or desktop fails to start from StoreFront.
- VDA SSO errors — These mean the session starts but Windows logon to the VDA fails.
Note that I have not included StoreFront authentication errors because FAS is not integrated with the StoreFront authentication processes, which is a common misconception. If you are seeing authentication failures to StoreFront, troubleshoot those separately. FAS only really comes into play during session launch. Therefore, without further ado, let’s dive in to the error types.
Launch Errors
The most common launch error you will see from StoreFront (regardless of whether FAS is in use) is the generic “Cannot start app” message that looks like the below:
Always, always, always start with the StoreFront Delivery Services event log if you see this error from StoreFront because it means that there is a brokering issue, which almost always shows up in the StoreFront event log. Some sample scenarios include:
|
If
|
And
|
Then
|
|
You see an error on StoreFront about “interacting with the Federated Authentication Service” (event ID 28) that ultimately includes “Access Denied” within the body of the error details.
|
There are no errors on the FAS servers
|
The issue is likely in the communication between StoreFront and FAS. This could be because the rule names applied to StoreFront and configured on the FAS servers do not match.
|
| You see an error on StoreFront about “interacting with the Federated Authentication Service” (event ID 28) | There are errors in the Application event log on the FAS servers about the StoreFront server or user UPN not allowed by the role | The issue is likely in the configuration of the user rules. Either the StoreFront server has not been added to the list of allowed servers or the user has not been added to the list of users (or a group in that list). |
VDA SSO Errors
If the application or desktop launches, but SSO fails, then everything should be working between StoreFront and FAS and we need to investigate other components in the process, including the VDA and Domain Controllers. Usually I start the investigation for these types of errors on the VDA itself. Some sample scenarios include:
|
If
|
And
|
Then
|
| Users see a spinning Windows login screen, but are never successfully authenticated | There are errors in the Application event log on the FAS servers about the VDA not having Relying Party permissions | The VDA needs to be added appropriate user rule in FAS. If the VDA was recently added to a machine security group that is specified in the rule, try rebooting the VDA to force it to read its updated list of group membership from AD. |
| Users are being prompted to enter credentials, but there are no errors in the VDA event log | There are no errors on the FAS servers | Validate that a GPO has not been applied that enables the RDS “always prompt for credentials upon connection” policy setting. Disable it if it is configured as it will prevent SSO |
| Users see an error from the VDA (from the Windows logon screen) that “The request is not supported” | (after enabling Kerberos logging on the VDA) you see an error in the System event log from “Security-Kerberos” that “KDC_ERR_PADATA_TYPE_NOSUPP” | The domain controller has not been configured to allow Smart Card authentication and either a “Domain Controller Authentication” or “Kerberos Authentication” certificate should be issued and bound to the Domain Controllers that are in the same AD Site as the VDAs. |
| Users see an error from the VDA (from the Windows logon screen) that “The user name or password is incorrect” | You see errors in the System event log from “Security-Kerberos” that “KDC_ERR_CLIENT_NOT_TRUSTED” and “revocation server was offline” | Validate that the CA has a valid and reachable CRL specified as this indicates that the revocation status of the certificate being used to log into the VDA cannot be validated. |
In Summary
The six different scenarios we’ve covered should give you some ideas for how to go about troubleshooting any issues that you might see with setting up your FAS deployment. Remember that the StoreFront Delivery Services event log, the Application log on the FAS servers, and the Security log on the VDA are your friends in these cases. Good luck out there!
Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.
Click here for more Tech Bytes and subscribe.
Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.
