FAS Archive – Deyda Consulting Blog

Finding in the Wild | StoreFront + Entra ID Is Becoming Seriously Interesting

During a current Citrix project, I came across a development that will be particularly interesting for future StoreFront architectures. StoreFront can now configure Microsoft Entra ID directly through the management console. This becomes especially interesting in hybrid environments:

During a current Citrix project, I came across a development that will be particularly interesting for future StoreFront architectures.

StoreFront can now configure Microsoft Entra ID directly through the management console.

This becomes especially interesting in hybrid environments:

→ Hybrid users can receive resources from Citrix DaaS and on-premises CVAD through StoreFront.

→ From CVAD 2603, StoreFront supports Entra ID SSO to published resources, provided the VDAs are appropriately hybrid Entra ID joined.

→ Even more interesting: Entra SSO and FAS can be used in parallel within the same store.

StoreFront uses each delivery group’s logon type to decide which authentication method to use for resource launch.

For example, this enables gradual modernization of an environment without immediately removing FAS from the design.

What I take from this for new designs

In future, I would create an authentication matrix during the design phase:

Delivery group → VDA join state → authentication method → SSO method

For example:

• Conventional AD VDAs → FAS
• Hybrid Entra ID joined VDAs → Entra SSO
• DaaS workloads → according to the identity design

In larger hybrid environments in particular, this prevents considerable confusion later.

For me, this is another step towards making StoreFront more interesting in modern Entra ID/DaaS architectures, rather than viewing it solely as a component of conventional on-premises CVAD environments.

Finding in the Wild | Citrix FAS + Entra ID – Sign-In Works, but No PRT?

A small Finding in the Wild from a current Citrix FAS project. The starting point: * Hybrid Entra joined VDA * FAS logon works * Certificate is issued correctly * CRL is reachable internally * But no Primary

A small Finding in the Wild from a current Citrix FAS project.

The starting point:

* Hybrid Entra joined VDA
* FAS logon works
* Certificate is issued correctly
* CRL is reachable internally
* But no Primary Refresh Token (PRT)

What was particularly interesting: I had previously implemented comparable configurations in older FAS environments without explicitly enabling Certificate-Based Authentication (CBA) in Entra.

The crucial difference may lie in the PRT acquisition flow being used.

Entra CBA changes certificate validation

If native Microsoft Entra Certificate-Based Authentication is used to issue the PRT, CBA must be enabled under

Entra ID → Authentication methods → Certificate-based authentication

for the relevant users.

Then there is a second important point:

A CRL that is reachable only internally is not sufficient.

If Entra validates the certificate, Microsoft must also be able to access the Certificate Revocation List.

The internal CA does not have to be exposed to the internet. Publishing the signed .crl file through a publicly reachable HTTP endpoint is sufficient.

This turns:

FAS → Windows logon works → no PRT

into an investigation across the entire chain:

FAS → certificate → Entra CBA → CA trust → CRL → PRT

My learning: do not automatically assume that older and newer FAS environments acquire the PRT through the same authentication path.

Sometimes the issue is not with Citrix, but between your own PKI and Microsoft Entra ID.

Finding in the Wild | Citrix Entra SSO – When the Microsoft Security Baseline Blocks Sign-In

A Citrix environment with Microsoft Entra ID, correctly configured SSO and registered VDAs. Users authenticate successfully to Citrix Workspace. However, launching the desktop prompts for Windows credentials again, or SSO fails. The symptoms: ✅ Entra ID authentication succeeds

A Citrix environment with Microsoft Entra ID, correctly configured SSO and registered VDAs.

Users authenticate successfully to Citrix Workspace. However, launching the desktop prompts for Windows credentials again, or SSO fails.

The symptoms:

✅ Entra ID authentication succeeds
✅ The VDA is registered and reachable
✅ Citrix resources are displayed
❌ Single sign-on within the session does not work

The initial suspects are Entra ID, Conditional Access, Kerberos or the Citrix configuration.

But the actual cause may lie in a Microsoft Security Baseline.

🔍 Root cause

Citrix Entra SSO requires the following Windows security setting:

Allow Custom SSPs and APs to be loaded into LSASS

The Microsoft Intune Security Baseline for Windows sets this setting to Disabled by default.

This prevents Windows from loading additional Security Support Providers and Authentication Packages into LSASS.

As a result, the authentication integration required for Citrix SSO can be blocked.

🛠️ My troubleshooting approach

First, I check the effective policy on the affected VDA:

Computer Configuration → System → Local Security Authority

The critical setting is:

Allow Custom SSPs and APs to be loaded into LSASS

Next, I check whether Intune, a Security Baseline or a conventional GPO controls this setting.

The solution:

Specifically set the setting to Enabled on the affected Citrix session hosts.

Important: do not disable the entire Security Baseline!

I would use a dedicated policy or an agreed exception for the Citrix VDAs.

Then verify policy application, restart the VDA and retest SSO.

⚠️ Security note

This change permits additional SSP/AP components to load into LSASS, deliberately expanding the allowed authentication integration.

The exception therefore belongs only on systems that actually require this functionality.

💡 My takeaway

Not every Citrix SSO issue is a Citrix problem.

Sometimes a correctly deployed Security Baseline prevents exactly the functionality required by the intended authentication architecture.

Security hardening and functionality must be considered together, especially with Citrix, Entra ID and Windows.

SAML Authentication between Citrix & Microsoft with Azure MFA

Update to the latest cloud navigation.

As a result of increasing projects, here is a little how-to with the summary of my previous articles. The main points are:

Azure AD Seamless Single Sign-On (PTA / PHS)
SAML Authentication (Azure AD as IdP & Citrix Gateway as SP)
Citrix Federated Authentication Service (FAS)
Microsoft Azure Multi-Factor-Authentication with Conditional Access

Requirements

Fully working Citrix Virtual Apps and Desktop Environment (StoreFront & DDC Minimum Version 7.9)
NetScaler with successful base configuration & activated Enterprise or Platinum license (Minimum Version 12.1 Build 50+ for native workspace app, for browser Minimum Version 11.1)
Configured Unified Gateway vServer
Internal and external DNS entries for Unified Gateway vServer (e.g. citrix.deyda.net)
Certificates for DNS entries (wildcard certificates are the easiest)
Existing Azure Tenant with Azure-AD base configuration (Domain, AAD Sync) & activated Azure AD Premium license
AD Connect version installed and configured (Minimum Version 1.1.644.0)
Firewall release for *.msappproxy.net on port 443
Domain administrator credentials for the domains that connected to Azure AD via AD Connect
Installed Authenticator App on Test User Mobile Phone

Citrix Virtual Apps and Desktops & WEM 2003 is released

The new current releases of Citrix Virtual Apps and Desktops, Workspace Environament Management & Citrix Provisioning are now available. They contains many new features compared to the last LTSR.