SAML loop after a conditional access change, and an expiring FAS certificate

Start with the identity side, because the timeline points there. The loop began when a conditional access policy began requiring compliant devices. A personal or unmanaged device cannot satisfy that grant control, so Entra denies the sign-in or re-prompts, the Gateway re-initiates the SAML request, and the user circles. The client cannot fix that by retrying, which is why "Cannot complete your request" appears after a few passes.

Evidence to pull:

• Entra sign-in logs for the Citrix enterprise application during the failure window: the conditional access result and the failure reason (device not compliant, device not registered) will name the cause immediately.
• Gateway authentication and AAA logs for the same transaction, to confirm the loop is repeated SAML requests rather than a failed assertion.
• StoreFront logs for the "Cannot complete your request" events, to see whether the assertion arrived and was rejected, or never arrived.

Separate Citrix from identity fault: test with an account excluded from the conditional access policy. If that account succeeds end to end, the Citrix chain - Gateway, SAML trust, callback URL, STA - is intact and the fault is the policy; do not touch the Citrix configuration. If the excluded account also fails, then examine the Citrix-side items: ACS URL and entity ID matching between Gateway and Entra, clock skew, the callback URL certificate and reachability from the DMZ, and whether the store is configured for the same authentication method the Gateway is asserting.

Resolution direction: the fix belongs in conditional access design - a grant that unmanaged devices can meet (MFA plus an app protection or session policy), a separate app for BYOD, or an exclusion for the Citrix enterprise app with compensating controls. Document the SAML trust dependencies so the next policy change is reviewed against them.

Blast radius first, because it justifies treating 18 days as urgent. FAS is what turns a Gateway or StoreFront authentication into a certificate the VDA can use for single sign-on inside the session. If the FAS chain becomes invalid, users still authenticate to the Gateway but the VDA cannot log them on silently: sessions fail with credential errors or prompt unexpectedly, across every delivery group using FAS. It is a full-service outage that appears as a Citrix problem, not a certificate problem, which slows diagnosis.

Renewal plan:

1. Inventory what actually expires - the FAS server certificate, the ticket-signing certificate and the authorization certificate are distinct objects, and the CA template and its validity period determine how each one is renewed. Do not assume renewing one renews all.
2. Snapshot and export the FAS configuration and the current certificates before touching anything, and confirm you have a tested way back.
3. Renew or reissue through the FAS console against the issuing CA, then re-run the FAS configuration steps so StoreFront knows about the new certificate material.
4. Verify the VDA side: the trust chain for the FAS server and the CA must be present on every VDA via GPO, including the intermediate. A renewed certificate with a new chain is the most common reason a renewal "works for some users".
5. Pilot with a small delivery group or a test account, then roll out. Confirm single sign-on works for a Gateway user, a StoreFront internal user and a smart card user separately - they take different paths into the VDA.
6. Add monitoring that warns at 60 and 30 days for every certificate in the path: Gateway, StoreFront, STA, FAS, VDAs.

Documentation: record the renewal date, the owner and the dependent certificates in the change system, so this does not arrive as an 18-day warning again.

Coexistence design. The Gateway must route the two populations down different factor paths inside one nFactor flow rather than exposing two different entry points.

• Smart card users: certificate authentication at the Gateway, followed by the smart card path into StoreFront. Their single sign-on comes from the smart card itself, so confirm that FAS is not in the path for these users - a store configured to use FAS for everyone will attempt certificate-based SSO and can conflict with the smart card credential. Validate CRL and OCSP reachability from the Gateway and the VDAs, because an unreachable revocation check makes smart card logons fail intermittently and look like a policy problem.
• SAML users: policy-based factor selection by client subnet or by an identifying attribute, landing on the SAML factor. Keep the smart card policy evaluated first so internal users are not accidentally pushed into Entra.
• Shared store: one store can serve both, but the store's authentication service settings must permit both methods, and the Gateway session policy must point each flow at the same store consistently. Test all four combinations: internal smart card, internal password, external SAML, external SAML on a non-compliant device.

Wrong Outlook profile in the shared hosted desktop pool is not an authentication design question and should be investigated as a profile or image integrity issue:

• Profile path and container path variables - a literal or mis-scoped variable (%username% resolving incorrectly) can point two users at one container.
• FSLogix or Profile Management logs for both users, showing the container that was actually attached.
• Image generalisation: a master image that was not properly prepared and cloned can carry duplicate local account identities and produce exactly this symptom across a pool.
• Session reuse: confirm whether the report was two users seeing the same session rather than two profiles, which points at the connection path rather than storage. Treat it as a potential data-exposure incident until the cause is established, and preserve the container and event logs before any cleanup.