Here’s an example of a usecase where Citrix FAS comes into play.
If you are not familiar with Citrix FAS and the use of it you may find this useful to get some insight to the usecases.
-The customer is renewing the server park as a whole – in this case, this means swapping out the old AD forest and starting from scratch.
-They run some applications via Office 365 and SaaS, and have some mobile workers using an app from their phone/tablet.
-They may want to leverage Microsoft 365 for security features, MFA, Conditional Access and Windows Hello to mention some.
-They have some users with the need to access an application (CAD) that talk to a traditional SMB share – and is running locally from the computers.
-This SMB share also need to be accessible from the Citrix VDA’s for the new deployment.
Going through this, how can we fulfill this with SSO across for the users, minimize the number of dedicated servers for the customer, maintain security, support for SSO /Windows Hello and Citrix XenApp? –
This is where Citrix FAS comes in play for this case.
First of some prereqs to be aware of:
-For Azure AD – you need AD premium (P1 is fine) – you need this to be able to create a “non-gallery” enterprise app in Azure. Arguably – all users accessing that app should be assigned AD Premium licenses.
(Although you actually only need 1 license – to be able to create the application, and it will work, but this is not allowed license wise – this is based on trust from Microsoft that you will license correctly – so please do that)
Side note: if you have O365 Business Premium, E3 or similar, and don’t need all the M365 E3 features, the best way to get MFA, Conditional Access and AD Premium is to go for the EM-S E3 licenses.
(EDIT: M365 Business should now also be valid for both Office Shared computer activation and conditional access)
-For Azure SSO – you need to setup AD sync from the customer domain to Azure – In this setup we leverage Password Hash sync.
– Because there exist users with the need to access a local SMB share from their local computers – they need “traditional AD join” to connect to the share without prompts.
But that kills the idea of modern workspace, SSO to SaaS and FAS – so how to get both the up to date SSO with Azure and the local resources?
Hybrid AD Join – we want the connection to Azure from the computers to leverage windows hello and sso with FAS and cloud apps.
Be aware that for Hybrid ad with sync of identity data this is done on the forest level – so if you are using child domains, shared domains etc it will not work – dedicated Forest for the domain is the way to go.
-I will not cover the setup for Citrix FAS here, it fairly straight forward, and well documented in Citrix docs found here: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/secure/federated-authentication-service.html
Or you can take a look at Carl’s step by step guide here if it’s the first time, it will give you some extra things to be aware of: https://www.carlstalhood.com/citrix-federated-authentication-service-saml/
The actual setup based on criteria
Based on the above we end up with the following (all resources are hosted in partner datacenter):
Servers dedicated for the customer: AD with AD sync (password hash), File server for the CAD share, Citrix VDA worker to access hosted applications/desktop.
Servers hosted by partner: Partner AD with shadow accounts for the needed users, Citrix infrastructure (Citrix FAS, VDA’s, Storefront servers, DDC’s, PVS, WEM, etc. ), owned and maintained by the partner.
Access.: Citrix Gateway running on an VPX in the partner datacenter – SAML policy on the GW to authenticate with the customers Azure AD.
Trust: One-way incoming trust between Customer forest and partner hosted forest (Customer forest trusts partner forest users) – this due to the requirement to access the Customer SMB share from the Partner hosted VDA’s.
PS: the shadow accounts need to be added to the file share in the customer SMB share, so they can access the share from the customers local ad users as well as the shadow accounts.
Azure AD: Enterprise application is created with the SAML settings defined, the users are added to the application in Azure AD, either directly or via security groups in Azure AD.
It will look something like this:
Pardon for the “amazing” hand drawing 🙂
-The user connects to the ADC GW that has a SAML policy bound to it – the GW redirects the user to the SAML IDP (Azure in this case) to request a SAML token. (The user uses their normal Azure/Office365 credentials)
-Azure IDP issues a token to the user and redirects back to the ADC GW.
-ADC GW takes the info from the SAML token to lookup the user in the partner hosted AD. (via the NameID in the token – this gets matched to UPN in partner AD on the Shadow accounts)
-After user lookup Storefront is contacted by the ADC.
-Storefront contacts the FAS service to request a certificate for a single session to the user.
-The session gets brokered by the DDC.
-When the session gets initiated on the VDA – the VDA ask the FAS service for access to the previously created certificate for the user – and then uses this to logon the user to the VDA with the Shadow account.
(The user never know anything other then their normal credentials)
The user experience:
The user machines will be Hybrid joined to AzureAD, this gives the users real SSO to apps inside 365 etc.
Machines get Windows hello activated, so the users can leverage Biometrics, PIN etc, to login to the computer, eliminating the need to use the actual password.
The machines get Citrix Workspace App installed, and pointed to the SAML activated Storefront store, since FAS is involved, SSO to Workspace app works since authentication is SAML based against Azure AD.
(If not using the FAS service, and the users login to the computer with Windows Hello, the SSON service, responsible for SSO to Workspace app does not start as there are no NTLM credentials to pass)
The users start the application/desktop from workspace app as normal.
In the backend, FAS together with Storefront and ADC takes care of the authentication, and mapping to the shadow account in the partner hosted Citrix environment and VDA.
When the user authenticates, a request is sent to azure ad to verify the user claim, a token gets sent back with the UPN of the user, this gets looked-up in the partner AD for a user matching the UPN from Azure.
FAS in this case, when a matching user is found, issues a virtual smart-card that gets passed to the VDA to seamlessly login to the VDA with the shadow account.
-The customer can minimize their dedicated footprint, and cost related to this, as more is handled by services managed by the partner.
-The customer can reap the benefits from modern authentication, MFA, Windows Hello, Azure AD joined, Conditional Access etc.
-The customer can bring their own identity (from Azure AD) to access services hosted at the partner – no need to handle multiple password/usernames as they don’t need to care about what the username/password is for the actual user that accesses the Citrix environment.
-The customers, due to Azure AD join, have full SSO to 365 services as well as the Citrix services.
-The customer can take advantage of services like Windows Autopilot, Intune etc to manage their endpoints and software deployments, minimizing the need for the traditional LAN only access situations.
-The customer can choose to access the Citrix environment via web browser with, Citrix Receiver or via Microsoft’s myapps portal, all with real SSO.
-The customer can, if they want, invite B2B users to their Azure AD, and give these users access to resources in the Citrix environment – leveraging the B2B users identity. The customer don’t need to handle the B2B users identities, as this done with shadow accounts as well.
-The partner can more easily manage the deployment, as less infrastructure is dedicated for this specific customer.
Consultant manager & SME @ iteam, localized in Kristiansund, Norway.
Focused on EUC, security, mobility, virtualization, management and a modern workplace. Highly specialized around RDS/Citrix/EUC/Mobility.