Making use of Azure B2B in a Citrix deployment – Citrix DaaS

Posted on by Geir Dybbugt

Post contents

Why do you want this?

In this post, that is a follow up to the previous post for on-prem, I will walk your through leveraging Entra ID and the b2b feature within, together with your Citrix DaaS deployment.

This gives you the possibility to give external users access via their own credentials.

It also opens up the usage of all of Entra ID´s authenication methods for your users, passwordless, FIDO etc.
Using Entra ID where you can, is a great and powerful way to help you leverage some of the best security mechanisms to protect your users identity, and access to your data, so why would you not leverage it where you can?

So let´s get started.

Prerequisites // Components.:

  • Microsoft Entra ID (Azure AD) – with P1 level.
  • Azure Subscription
  • On-Prem ADDS with Shadow accounts
  • Citrix Federated Authentication Service (FAS)
  • Server with Enterprise CA role
  • Citrix DaaS

Component: Microsoft Entra ID

Think of Entra ID as your user catalog, controlling and securing access to the service your are providing to the users accessing it. We are trusting Entra ID to do the user verification for us, to be our source of truth.

Our goal here is to provide users access to a Citrix DaaS environment, that you manage and control. Since we are controlling the Entra ID that handles the authentication, this means we can control, via our Conditional Access rules, the requirements for MFA etc to reach our resources, regardless of what they have configured on their own end. 

We also want the users to be able access the environment with their own existing credentials. To make this possible, we will make use of  the b2b feature within Entra ID. This means you do not need to handle the credentials used by the users to access the service, and focus only on the parts that your are responsible for.


This means we will use Microsoft Entra ID as the IdP (Identity provider) for the Citrix Environment, create an SAML based “Enterprise Application” in Microsoft Entra ID, add the external users as guests in Entra ID, and give users access via this Enterprise application we will create.

Preferably you will create a group (dynamic or static) in Entra ID, to add to the Enterprise application, making the admin overhead simpler. *

Depending on the scale or context of the deployment, you can opt to create a seperate Entra ID for this “service” or use your existing Entra ID.
In this case I am setting this up to deliver a service to people outside of the organization, and prefer to not get alot of external /guest users in “My // Internal Organizations” Entra ID. This keeps this environment isolated and managed as its own “service”, and limits clutter. **
 

*To be able to assign groups to the enterprise application you need P1 License level on Entra ID. This is also a requirement to add a “non-gallery” enterprise application.

** You choose what  fits your intended setup

Component: Azure Subscription – To use against Microsoft Entra External ID.

A while back Microsoft changed the licensing model for external collaboration with Entra ID (Azure AD). Previously you had to license the environment with 1 P1 license pr 5 guest accounts//b2b user.
This is now changed to a MAU model (Monthly Active Users), you can read more about that in Microsoft learn site here.

This means you have to add a Azure subscription to the Entra ID environment, to handle the billing for the MAU users, should your MAU count exeed the included free usage. *

*The first 50 000 MAUs per month are free for both Premium P1 and Premium P2 features.

More details on pricing here.

Component: On-Prem AD with Shadow accounts

In this post, we are basing this on a Classic Citrix environment (On-Prem CVAD).
This means we have a Active Directory Domain Services involved (ADDS).

This AD is will contain your users/groups/computers as normal.
To provide access to our external (b2b) users, we will leverage shadow accounts.
These are normal AD user objects in your ADDS. These users will have their UPN and E-Mail attribute set to the same as the external users actual information. So if your external user has E-Mail address of user@somedomain.com, you will add somedomain.com as a upn suffix in the ADDS environment and set the users E-mail and UPN to match this on the shadow account.

For password you can set something random and secure, as the user does not need this password on their end to access the environment – the authenticate with their own existing credentials that you do not manage. *

*Exception here is if the user needs access to applications when inside the environment that does not use integrated authentication – meaning they will need the acutal AD user password to access the app after loging in to the Citrix environment.

Component: Citrix Federated Authentication Service (FAS)

We want the users to get access with proper SSO from when they enter the service.
Because we are using Entra ID as IdP, SAML authentication, and shadow accounts on the inside, we need to implement Citrix FAS to handle the SSO into the session host.

Citrix FAS issues a virtual smart card for the users shadow account, that smartcard is used to logon to the session host.

To use FAS with Citrix DaaS, you need to connect your FAS server to Citrix Cloud, and enable FAS in Citrix Cloud.

Setting it up – updated version

Setup Entra ID for Citrix DaaS

Previously to get b2b accounts to work with Citrix DaaS we needed to use a NetScaler between Citrix DaaS and Entra ID. This came from Citrix DaaS expecting that the SID of the Shadow account in ADDS to match the b2b account in Entra ID. To work around this we needed to use Citrix Gateway as a authentication method in Citrix DaaS, and configure the authentication so that the user got redirected to a authentication page on the NetScaler, doing group extraction (no auth), before redirecting to Citrix DaaS. We did this so that the SID of the Shadow account was collected before doing the authentication against our Entra ID. Not ideal, but it works.

But previously this year Citrix changed their requirements in the SAML 2.0 authentication method,

Previously the cip_sid AND cip_upn claims where both required, but as we can see now, this is changed so that we only need one – sid of no upn, and upn if no sid – this means we no longer need the NetScaler to work around this, and can use the SAML 2.0 option alone – one less component to manage, reducing cost, complexity and also reducing your attack surface.

So lets start the Entra ID part of the setup.

Enable MAU billing model for guest accounts

First, to enable the MAU model, you need to make a quick change in your Entra ID, and link external identities to an Azure Subscription. This is to handle billing for authentications above the already included 50.000 pr month.

To do this, go to the external identities section in Entra ID – Entra ID>External identities>Linked Subscriptions.

1: Select Linked Subscriptions in the left navigation panel
2: Check the tenant you want to link
3: Click Link subscription
4: Select the subscription to use
5: Select the Resource group to use
6: Click Apply

Setup the Enterprise app

In the Entra ID you choose to use for the setup we need to configure an Enterprise Application to use for SSO via SAML against Citrix DaaS – we will use the SAML 2.0 SSO app from the app gallery as a starting point.

When you create the app and configure the SSO settings, remember to take a note of the Entity ID and urls provided in the app. Also download the Base64 certificate – you will need this when you configure Citrix DaaS.

Create the Enterprise App

1: Go to the enteprise applications blade in your azure portal
2: Click new application to create a new enterprise app

1: On the browse Microsoft Entra Gallery page, search for “citrix cloud saml sso”
2: Select the Citrix Cloud SAML SSO app from the results
3: Input a name for your enterprise application
4: Click create to create the initial application, and wait for the process to complete

Configure SSO settings

1: Once the application is created, click the Single Sign-on selection in the left bar
2: In the Single sign-on settings, select SAML

Basic SAML Configuration

1: In the Basic SAML Configuration part click edit
2: Input the details for Identifier, Reply URL and Sign on URL (Logout url is optional) to the following:

Identifier (Entity ID)

Reply URL (Assertion Consumer Service URL)

For Sign on URL

This will be your Citrix DaaS Workspace url, i.e “mytenant.cloud.com”
You can see what you have configurede for this in Citrix Cloud, under your Workspace configuration on the Access part.

For Logout URL.:

1: Review your input information in the fields
2: Click save to complete the Basic SAML configuration.

Next is to edit the Attributes & Claims section.

Attributes & Claims

This is where we see the before mentioned defaults from Citrix, like the cip_sid and cip_oid mentioned before.

Edit the claims as follows:

1: Click Edit in the claims section
2: The cip_oid must be set manually, click on the line to edit the claim
3: Click the source attribute line, and search for “user.objectid”, and select it from the result list.
4: Click save to finish editing the cip_oid claim
5: Next click the three dots on the right for the cip_sid claim and select delete
6: Confirm the claim deletion.
(As mentioned previously, since we are going to use b2b users in Entra ID, we can choose to only have UPN in the claim.)
7: Review your claims, and click the “X” to finish editing the claims.

Next we need to fetch the certificate for use in Citrix Cloud from the SAML Certificates section

SAML Certificate

1: Click edit on the Token signing certificate section
2: Click the three dots on the certificate line
3: Download the PEM certificate
4: Close the  Certificate details.

Next, take a note of the URLs in the last section (4) – as we need them when setting up the authentication for Citrix Cloud.

Info needed for Citrix DaaS

User assignment for Enterprise app

Before we exit the Entra ID section of the setup, configure your Entra ID users/groups access to the Enterprise application,.

Limit app to a subset of users/groups

If you want  to limit the SSO app to a specific set of users or groups:
(I would reccomend using a group – i.e a dynamic group targeting guest user objects)

1: Click the “Users and Groups” option in the left bar
2: Click “Add user/group”
3: Click Users in the Add Assignments page
4: Select your users or groups to give access to the SSO app
5: Click select, and then the Assign button to complete assignment.

Do not require assignment

1: Click on the Properties option in the left navigation bar on the Enterprise Application
2: Set Assignment required to No
3: Click Save

Next we will setup the Citrix DaaS service to use SAML 2.0 for authetication against Entra ID.

Setup  SAML 2.0 in Citrix DaaS

To enable SAML 2.0 in your Citrix DaaS tenant do the following.

Login to you Citrix Cloud tenant, click the “hamburger menu” in the top left, and select Identity and access management.

Scroll down to SAML 2.0, click the three dots, and choose connect

You will be promptet to input a URL to use for administrative login via SAML, input the url of your choosing and click save and continue

In the next page, input the details from your Enterprise App and upload the certificate

Entity ID: Entity ID Url from enterprise app in Entra ID
Sign Authentication Requests: Yes
SSO Service URL: Sign on Url from enterprise app in Entra ID
Binding Mechanism: HTTP Post
SAML Response: Sign either response or assertion
X.509 Certificate: Upload your PEM certificate from the Entra ID enterprise app
Authentication Context: Unspecified Exact
Logout URL:  Logout Url from enterprise app in Entra ID 

Scroll down and review the attributes:

In the field for Security Identifier, delete the text in the field.
(this will make the text show in gray)
As we can see from the notes in the bottom, only one of the attributes (SID or UPN) are required.

Click Test and Finish to complete the SAML 2.0 configuration.

Enable Subscriber access

Back on the Identity and access management, you should now have status connected for SAML 2.0, and the next we need to do, is enable subscriber access via the newly created SAML 2.0 authentication, to do this:

Click the three dots on the right for SAML 2.0, and choose manage subscriber access.

This will redirect you to the Workspace authentication page, here you select SAML 2.0 as the authentication method.

(You will get a message about subscriber impact for the change – it may take some time to roll out, but it is normally rather fast).

Setup FAS

The last thing we need, is to make sure FAS is up and running, so the users get SSO in to the VDA

For FAS you configure this like normal, and set it up with rules to fit your requirement in terms of limiting user groups / VDA server FAS servers if you do not want to use the default “everything” configuration.

I will not put the full guide on seting the FAS parts up here, as others already have detailed steps published already.
Official Citrix documentation can be found here for Citrix FAS.

The difference for Citrix Cloud vs on-prem, are that you do not need to configure storefront in the FAS console, and you need to connect Citrix FAS to Citrix Cloud.
This has good instructions in the Official Citrix docs.

Once that is in place, you can click the button to “Enable FAS” in the Workspace configuration>authenication page in Citrix Cloud.

With that your users should be able to login to Citrix DaaS with b2b users (and normal users) as normal via your Entra ID.
To do this you will need to create shadow accounts in your ADDS and create the b2b objects in your Entra ID. How you choose to create the users on-prem and in Entra ID is up to you, but I will include an example here on how this could be done.

Provisioning/managing users/tenants

When it comes to creating the users you want to give access there are multiple ways of doing this.

You could create the users first in Entra ID, and then sync the b2b users down to your on-prem AADS.

One way of doing that is with the “B2B to AD” sync script located here.
The script can run as a task on intervals to get new users etc.

However this will sync all users to one OU in AADS by default, so you will need to customize that should you want to seperate different users to different OU’s. If you have alot of different “tenants” this may not be ideal.

The other way is to do it in the opposite direction, meaning we create the shadow accounts in AADS first, and use the shadow accounts to provision the b2b accounts in Entra ID.
This is my preferred way, as it means I can create my structure in AADS, and provision the users to Entra ID after it is setup. Since you are giving access to the service you manage, you probably have full insight into who is going to be given access as well.

My way of doing this, is to create a collection of “onboarding” scripts, and put a GUI on top of that.
This way I have a simple “application” that helpdesk etc can use to do what is required to create a new “tenant” add/delete a user, create unique service users provision the b2b users, and also to create documentation on what is onboarded.  Since the process of onboarding is scripted, this means I can define my OU structure, groups pr tenant etc as a part of the onboarding process, meaning all users get created the same way, minimizing human errors. (if something is configured wrong, you have the same thing wrong across the board).

How does this look on my end?

In my environment I created a collection of scripts for each of the functions I want to be able to do in a simplified way, or i.e  orthers can do it without needing to know all the gritty details.

The script collection is put together and baked into a simple GUI based “app”. This way the scary powershell code and terminal window do not need to scara away others from using the functionality.

To create a simple GUI for a s script you can cut down the effort by leveraging stuff like poshgui, to create the code for the gui for you based on your  layout.

Poshgui gives you a quick way to create the layout in a simple  WYSIWYG  editor, and serves you back the code for the GUI (Winframe).

You then put your code together to make it usable.

For the one I made, i wanted the following functionality in the GUI.:

  • Enter info for a new “tenant”
  • Import the users for the new tenant
    • Script handles OU creation, GPO links, passwords, service accounts, security groups and members, as well as nesting against central groups used to publish resources on the Citrix side. This way all “tenants” get set up their own way, with their own prefixed groups in accordance to naming conventions etc. And I can publish the citrix apps against a central group for all “tenants” using the same app/resource. This means I can control everything based on the groups and rrarely need to go into Citrix WEM, Studio etc to manage user access.
  • Add new user(s) to exisiting tenant
  • Delete user(s) for exisiting tenant
  • Create dedicated SQL instansce for a tenant
  • Provisiong the tenants shadow users to Entra ID b2b
  • Create initial documentation at point of onboarding

This ended up looking like this with options for the functions to initiate.

To provision the Entra ID b2b users I use the option for provisioning in the gui, and the terminal window gives me the option to choose what tenant to provision users for

After selecting the tenant nr and hitting enter.

The script takes the info of the shadow accounts, connects to Entra ID using service principal/Certificate, and does the b2b invitation. You can in that process set the b2b creation to send a invite message on email to the users once they are provisioned . I opt to not do this,

The scripts shows in the terminal status for b2b generation as it moves throught the tenant.

Once it is finished, the menu is active again and I proceed with next action or exit if that was all i needed to do.

At this point the users can access the environment with their own credentials.

Connect to Entra ID via certificate auth and script

To make the process of provisioning users via script you can set up authentication to your Entra ID via Certificate. This way you can connect via  a service principal and certificate on your “management workstation” unattended – meaning the usage of a b2b provisioning script via self-made GUI or automated scheduled task can be achieved for less hassle in user management.

——

To connect with certificate you create a app registration in Entra ID

Give your app registration a name and create the registration

Go to the Overview page of the registration and take a note of:

Application (client) ID

Directory (tenant) ID

Object ID

Head down to API permissionsand give the registration the needed permission to add b2b users and add them to a group. Also grant admin consent for the registration

Create a certificate on the endpoint where you are going to connect from

Install-Module Microsoft.Graph -Scope AllUsers

$Cert = New-SelfSignedCertificate -DnsName seritmoreb2b.onmicrosoft.com -CertStoreLocation “Cert:\LocalMachine\My” -FriendlyName “b2bscriptMicrosoftGraphSDK” -Subject “Azure b2b onboarding – Cert for Microsoft Graph SDK”

Get-ChildItem “Cert:\CurrentUser\My\$($Cert.thumbprint)”

Note down the Thumbprint

Import the certifcate for use on the app registration

From the device you created the certificate on, export the certificate

Import the certificate on the App registration in Entra ID

You should then be able to conncet to Entra ID via powershell with the following command

Result

The result of this setup for your users is a seamless logon experience to access the apps/desktop you provide. Sinvc we are leveraging Entra ID, B2B and SAML to access the solution, your users will get a real SSO experience to access their apps, all with their own already exisiting credentials, that they manage on their own.

Since we are using b2b functionality to provide access, it doesn’t really matter where the external users have their identity. If they already are a M365 user, they will be able to use that identity, same for google and other providers.

Since we are enforcing conditional access rules on our end, we have the control to require MFA regardless what the users have on their end.

During the first logon the users will be prompted to setup MFA on their account as normal.

Should you want to give users access via features like cross-tenant sync, you could do that also, but keep in mind that you will need to make steps to ensure that  the users synced into your b2b tenant are created on the on-prem side, in your ADDS.

Resources

Connect SAML as an identity provider to Citrix Cloud

Tutorial: Microsoft Entra single sign-on (SSO) integration with Citrix Cloud SAML SSO | Microsoft Learn

Citrix FAS – SID Lookup Mismatch with Citrix DaaS (julianjakob.com)

Leave a Reply

%d bloggers like this:
Explore Yubico