MFA, SSO and Contractors in a Hybrid Identity Estate
Litware, a health insurer, serves 1,800 employees and 400 contractors from Citrix DaaS. Identity is on-premises AD with two domain controllers in Azure, synchronised to Entra ID with password hash sync; no device management covers the VDAs. Today users authenticate to Citrix Workspace with their AD credentials and then authenticate again inside the VDA session. Security wants MFA on all remote access, single sign-on after the Workspace logon, and no MFA prompt when the user is on the corporate LAN. Contractors exist only as Entra B2B guest accounts with no on-premises AD identity. VDAs are domain joined and FSLogix profiles sit on Azure Files using AD DS authentication. A pilot that switched VDA machines to Entra ID join failed because profiles would not mount.
1. Design the authentication chain for employees: which components enforce MFA, how SSO into the Windows session is achieved, and how the corporate LAN exemption is expressed.
Read the worked answer
Chain design
- Citrix Workspace is configured for SAML or OIDC against Entra ID. Workspace becomes an enterprise application, which is what makes it a target for Conditional Access.
- MFA is enforced in Entra ID by a Conditional Access policy scoped to that enterprise application, not inside Citrix and not again inside the VDA. One policy, one prompt, one audit trail.
- The LAN exemption is a named location containing the corporate egress IPs, referenced as an exclusion in the same policy. Do not build a separate weaker policy; two policies drift and produce the 'why did it ask me twice' ticket.
- Single sign-on into the Windows session is delivered by Citrix FAS, not by passing the password through. FAS issues a short-lived certificate to the VDA, which is presented to the domain controller and mapped to the AD account. This keeps the VDA domain joined, which the FSLogix design requires.
Prerequisites people forget
- FAS needs a subordinate or enterprise CA, a certificate template, and rules covering the user accounts in scope. Cross-domain or forest-trust scenarios need extra rules; verify before rollout.
- The Workspace identity (Entra UPN) and the AD account must resolve to the same person. Mismatched UPN suffixes produce a silent fallback to a second credential prompt.
- Keep a break-glass path: a delivery group with direct AD authentication that is not exposed to the internet, documented and tested, in case FAS or Entra is unavailable.
Order of work: FAS first and validated on a pilot group, then Conditional Access in report-only mode, then enforcement.
2. How do the 400 B2B contractors get a session and a profile, given they have no on-premises AD account? Evaluate the options and recommend one.
Read the worked answer
The constraint: Entra B2B guest sign-in gets a person through Workspace, but the VDA still needs a Windows identity to log on, load a profile and be governed by policy. FAS also signs certificates for AD accounts; it cannot invent one for a guest.
Option A - shadow AD accounts. Provision an AD account per contractor, mapped to the guest UPN, with lifecycle driven from the HR or vendor system. Works with the existing FAS, FSLogix and GPO estate unchanged. Cost is identity governance: stale accounts are a real risk, so the joiner/mover/leaver process must be automated and audited, not maintained by spreadsheet.
Option B - publish only web and SaaS apps through Citrix Secure Private Access for contractors, keeping Windows sessions for employees. Smaller attack surface, no shadow accounts, but only viable if the contractors' actual workload is browser-based.
Option C - a separate contractor estate in a dedicated subscription and delivery group, accepting the duplicate management overhead.
Recommendation: if the contractors use full desktop applications, take Option A with automated provisioning and a hard expiry date on each account; if their work is web-only, Option B is materially better and should be chosen even though it requires an application assessment.
Regardless of choice: give contractors their own delivery group, their own Conditional Access policy with a stricter session lifetime, and no access to employee profile shares. Mixing them into the employee pool is the decision that turns an identity problem into an incident.
3. The Entra ID join pilot broke FSLogix profile mounting. Explain why, and state what would have to change for a cloud-joined VDA to work.
Read the worked answer
Why it broke. Azure Files with AD DS authentication requires a Kerberos ticket from an on-premises or Azure-hosted AD domain controller. A machine that is Entra joined but not hybrid joined has no domain membership to obtain that ticket, so the SMB session to the share fails and FSLogix reports that it cannot attach the container. The VDA boots, the user logs in, and then the profile attach fails - exactly the black-screen-plus-error signature.
What must change
- Use Microsoft Entra Kerberos for Azure Files rather than AD DS authentication. That requires hybrid identities, meaning the user accounts are still synchronised from AD, and a specific directory and feature configuration on the storage account. Cloud-only accounts are not covered; check the current support matrix before committing, because the contractor population in this estate is cloud-only.
- Verify that Citrix DaaS and the MCS provisioning path in your release support cloud-joined machines for the catalog type you use, and that your image tooling does not assume domain join at first boot.
- Re-examine everything else that silently depended on domain membership: GPO-delivered policy, drive mappings, certificate auto-enrolment, licensing, and the FAS model. FAS with certificate-based SSO expects domain-joined VDAs; losing that reverses the SSO design in the previous question.
Judgement: this estate has AD DS-authenticated profiles, FAS-based SSO and GPO-managed session hosts. The cloud-join pilot was solving a problem the estate does not have. The pragmatic answer is to keep hybrid Entra join, document the dependency, and revisit only if the organisation moves profiles to a service that does not require Kerberos.