Citrix DaaS – Microsoft Entra ID B2B User Identity Logonmethods

Reading Time: 5 minutes

Overview

Recently my namesake Julian wrote a great Post about choosing the correct Machine Identity in a Virtual Desktop Infrastructure – which is very important.

This post will cover the other Hand – choosing the correct User Identity Logonmethod for your Citrix DaaS Tenant – on a basis of Microsoft Entra ID and with a focus on B2B Guestaccounts.

There is also a useful Post from Mark Dear where he also explores the different Resource types / Join Methods. That’s the best way to start into that topic.

Identity Provider

First of all it’s important to understand how the authentication flow works. Doing SAML to Entra ID doesn’t mean the authentication takes place on the Entra ID Tenant. It’s beeing processed from Entra ID, but per default it gets authenticated against an AD User Identity, not Entra ID.

OIDC uses the opposite, Entra ID.

That means there are different behaviour when we are talking about group resource enumeration for published Apps and Desktops in DaaS and also when you’re using Entra ID Guestaccounts (B2B).

Testing the Scenarios

Delivery Group MachineLogOnType

We will start digging into an option which only appears when creating a new Delivery Group:

Sounds not bad, isn’t it? But what does that mean technically?

You aren’t able to see that setting after the creation in DaaS Webstudio, so if you would like to check if it’s enabled or not (or you want to switch between ON or OFF) use PowerShell. Install the Citrix DaaS SDK and connect:

Option enabled = MachineLogOnType is LocalMappedAccount:

Option disabled = MachineLogOnType is ActiveDirectory:

Okay, now we know the settings and how to switch, but what’s the impact for the Logon / SSO process to the VDA?

If the Option is enabled (=LocalMappedAccount) the matching OnPrem-AD Shadow User gets ignored, instead there is a local User created on the VDA which is used for SSO. My OnPrem-AD is HDXLAB and as you can see, the Logondomain is the Hostname of my VDA:

That’s one easy way to prevent supporting / editing / creating lots of Shadow User vor every B2B Guestaccount, but keep in mind, per default, there will be processed no GPO or profile settings. After the next reboot of the VDA, everything is reset (Except persistent VDI/VDA). There are options to use local policies to capture these local Users and create filters for different policy enforcements.

If the Option is disabled (=ActiveDirectory) there is the need of a matching OnPrem-AD Shadow User. And now there are different behaviour (OIDC vs SAML) when there’s the customers need of B2B Guestaccounts in Entra ID. Let’s check that.

Switch Identity to Entra ID

As I already wrote here, (at the moment) only with SAML 2.0 you can ignore the SID-Check. Now there’s the option to switch the Identity from AD to Entra ID (AAD).

The process is also described here, you can’t use the gallery app Citrix Cloud SAML SSO, you have to create your own. The main difference are the claims. cip_directory points to “azuread” which tells DaaS to use Entra ID as the Identity:

Another claim cip_fed_upn points to user.userprincipalname:

The main difference is the enumeration of group memberships, which is important for App / Desktop brokering.

If you would like to use that method, there is the requirement to have connected OIDC in DaaS (eg you can use it for admin control-plane auth) but SAML 2.0 has to be set as Workspace Authentication. So both is used. Why? SAML 2.0 Entra ID uses the OIDC connection to Citrix Cloud to look up the user attributes it needs.

Sadly, the logon with a B2B Guestaccount to DaaS will fail:

At this time, I’m not 100% sure of the failure reason, the SAML Trace looks fine with all needed Attributes:

I think the restriction is on the Citrix Cloud-side and on how that logon type gets processed. Sure, a B2B flow is way more complicated. B2B actually imports a copy of User X without the SID from X into Entra ID tenant Y from Entra ID tenant X. We disabled the SID-Check but in that flow there has to be anything (not yet explored) which is causing the failure.

Decision-Table

I played through all possible scenarios and tested the resource enumerations and the logon process. Here are my results. Keep in mind, focus (and testing) is on B2B Guestaccounts.

Optimally, you’re able to choose the correct authentication method during the design phase of your DaaS Tenant. The following Table should allow an easier way to make the correct decision. In all possibilities FAS is in use, because the VDA Machine Type for that scenario is OnPrem-AD joined or a maximum of Entra hybrid joined.

If you’re using Entra joined machines, there are other solutions.

Citrix Workspace configured Identity	Delivery Group MachineLogOnType	User Identity	Group resource enumeration	B2B Guestaccounts	OnPrem CVAD Site resource enumeration
OIDC	LocalMappedAccount	Entra ID (AD not supported)	Cloud, Synced	SSO to VDA with local User	No
OIDC	ActiveDirectory	Entra ID	Cloud, Synced	Not working, SID-Check fails	No
SAML 2.0	LocalMappedAccount	AD	OnPrem-AD	SSO to VDA with local User	Yes
SAML 2.0	ActiveDirectory	AD	OnPrem-AD	SSO to VDA with OnPrem-AD Shadow User*	Yes
SAML 2.0	LocalMapped Account	Entra ID	Cloud, Synced	Not working, DaaS Logonerror	No
SAML 2.0	ActiveDirectory	Entra ID	Cloud, Synced	Not working, DaaS Logonerror	No

*The UPN of the OnPrem-AD Shadow User has to be identical to the B2B Guestaccounts E-Mail Address (NOT the UPN, because the UPN of a Guestaccount is displayname_upnsuffix#EXT#@domain.onmicrosoft.com which is not supported)

ADFS

At the moment, be aware that if your Domain is federated to Microsoft’s ADFS, the SAML flow to DaaS will fail. I tried that at a customer and never got that to work. It’s an untested Design by Citrix at the moment, so it’s not yet verified and “not supported” – for reference you can use CCPHELP-8559.

Summary

As both methods are having their limitations, you have to choose between the authentication protocols for your needs.

Special thanks to Mark Dear for taking the time discussion about the different scenarios.