Table of Contents
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.
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.
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#EXTfirstname.lastname@example.org which is not supported)
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.