As Citrix environments continue to evolve alongside Microsoft identity services, many organizations are rethinking how authentication is handled across their digital workspace. With the introduction of Microsoft Entra ID–based single sign-on (SSO) for Citrix DaaS without requiring Federated Authentication Service (FAS), there is now a supported path to align Citrix more closely with modern, cloud-first identity models. This blog walks through the practical realities of implementing that capability, based on hands-on experience, including where configurations span Entra ID, Active Directory, and Citrix components, and what needs to be in place to ensure the design works reliably in production.
Environment Readiness
Before Citrix SSO with Microsoft Entra ID can be enabled, the environment must already meet several functional prerequisites across Citrix DaaS, Microsoft Entra ID, and the VDA identity model. This feature is supported for Citrix DaaS and requires session hosts to be Microsoft Entra joined or Microsoft Entra hybrid joined. From a VDA perspective, supported launches require Windows VDAs running version 2507 or later on supported Windows operating systems. The Microsoft Entra tenant must also be configured to allow Microsoft Entra authentication for Windows so the required authentication tokens can be issued, and hybrid joined environments introduce additional dependencies on synchronized identities, on-premises Active Directory, and Microsoft Entra Kerberos. In practice, this means implementation readiness should be validated across Citrix, Microsoft Entra ID, and Active Directory before configuration begins, rather than treating the feature as a simple Citrix-side setting.
The details about requirements, supported access methods, identity providers and considerations are provided in the Microsoft Entra single sign-on | Citrix DaaS™ Citrix article.
Microsoft Entra
Configure Microsoft Entra Enterprise Applications
The very first step is to register the Citrix Resource and Citrix Client application within Microsoft Entra. To do so, the following links are provided for the respective regions:
Citrix Cloud US, EU, APS
- Resource app: https://login.microsoftonline.com/common/adminconsent?client_id=3a510bb1-e334-4298-831e-3eac97f8b26c
- Client app: https://login.microsoftonline.com/common/adminconsent?client_id=85651ebe-9a8e-49e4-aaf2-9274d9b6499f
Citrix Cloud Japan
- Resource app: https://login.microsoftonline.com/common/adminconsent?client_id=0027603f-364b-40f2-98be-8ca4bb79bf8b
- Client app: https://login.microsoftonline.com/common/adminconsent?client_id=0fa97bc0-059c-4c10-8c54-845a1fd5a916
As our Citrix Cloud is in the US, we have used the appropriate links. Clicking the link will prompt to authenticate and present the prompts to enable required security permissions for these applications. Knowing that the majority of enterprise clients will have a separate Azure team, I recommend presenting the requirements to them to ensure this can be enabled for your Microsoft Entra.
Once completed, there will be two new enterprise applications called Citrix-Workspace (Client app) and Citrix-Workspace-Resource (Resource app).
To verify the proper permissions are applied, locate these applications in Entra, select permissions and ensure that the following permissions are applied under the Admin Consent.
Citrix-Workspace-Resource (Resource app)
| API Name | Claim Value | Permission | Type | Granted Through | Granted By |
|---|---|---|---|---|---|
| Microsoft.Graph | User.Read | Sign in and read user profile | Delegated | Admin consent | An administrator |
Citrix-Workspace (Client app)
| API Name | Claim Value | Permission | Type | Granted Through | Granted By |
|---|---|---|---|---|---|
| Citrix-Workspace Resouce | User_impersonation | Citrix Entra ID SSO | Delegated | Admin consent | An administrator |
| Microsoft.Graph | User.Read | Sign in and read user profile | Delegated | Admin consent | An administrator |
Remote Desktop Security
To enable single sign-on (SSO) to a Microsoft Entra-joined or Microsoft Entra hybrid-joined device, the Remote Desktop Protocol (RDP) needs to be enabled for the Remote Desktop Security object of the service principal; in this case, Citrix-Workspace-Resource enterprise application. For clarification, the RemoteDesktopSecurityConfiguration represents the configuration object of the service principal, while isRemoteDesktopProtocolEnabled is the property of the object and determines if Microsoft Entra RDS authentication protocol for RDP is enabled.
As mentioned earlier, we used PowerShell and here is the script we used to enable RDP.
# Import the Authentication and Application Microsoft Graph modules and connect to Microsoft Graph with the Application.Read.All and Application-RemoteDesktopConfig.ReadWrite.All scopes:
Import-Module Microsoft.Graph.Authentication
Import-Module Microsoft.Graph.Applications
Import-Module Microsoft.Graph.Beta.Applications
Connect-MgGraph -Scopes "Application.Read.All","Application-RemoteDesktopConfig.ReadWrite.All"
# Get the object ID for the service principals associated with the app registrations:
$CtxResourceSpId = (Get-MgServicePrincipal -Filter "AppId eq '3a510bb1-e334-4298-831e-3eac97f8b26c'").Id
$CtxClientSpId = (Get-MgServicePrincipal -Filter "AppId eq '85651ebe-9a8e-49e4-aaf2-9274d9b6499f'").Id
# Set the property isRemoteDesktopProtocolEnabled to true:
If ((Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $CtxResourceSpId) -ne $true) {
Update-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $CtxResourceSpId -IsRemoteDesktopProtocolEnabled
}
# Confirm the property isRemoteDesktopProtocolEnabled is set to true:
Get-MgServicePrincipalRemoteDesktopSecurityConfiguration -ServicePrincipalId $CtxResourceSpId
Approved Client App
The approvedClientApp object in Entra SSO for Citrix is the configuration that allows a specific client application (like Citrix Workspace) to request authentication tokens for the Citrix resource application, enabling the OAuth/OIDC-based SSO flow.
The PowerShell script we used is as follows:
# Create an approvedClientApp object:
$acp = New-Object -TypeName Microsoft.Graph.Beta.PowerShell.Models.MicrosoftGraphApprovedClientApp
$acp.Id = $CtxClientSpId
# Add the client app to the approvedClientApp object:
New-MgBetaServicePrincipalRemoteDesktopSecurityConfigurationApprovedClientApp -ServicePrincipalId $CtxResourceSpId -BodyParameter $acp
The User Consent Dialog
The user consent dialog is essentially a cosmetic change, as users are prompted to allow connection to Microsoft Entra-joined or Microsoft Hybrid Entra-joined machines during the single sign-on. To hide the user consent dialog prompt, create a group that will contain Microsoft Entra-joined or Microsoft Hybrid Entra-joined machines and then authorize the group in the resource application (Citrix-Workspace-Resource).
The PowerShell script that was used to hide consent dialog for a group is as follows:
# Get the object ID (OID) of the group that contains the session hosts for which you want to hide the Remote Desktop connection prompt.
# This should be a group we will publish resources to.
# Create a targetDeviceGroup object:
$tdg = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphTargetDeviceGroup
$tdg.Id = "<groupOID>"
# Add the client app to the approvedClientApp object:
New-MgServicePrincipalRemoteDesktopSecurityConfigurationTargetDeviceGroup -ServicePrincipalId $CtxResourceSpId -BodyParameter $tdg
This concludes the requirements for Microsoft Entra configuration. As mentioned earlier, consult your Entra administrators to ensure these steps are allowed within your tenant. The one thing I would highlight here is that we experienced some issues using PowerShell ISE to run these commands as a script; however, once I changed to just PowerShell, we did not have any issues with the commands.
On-Premises Active Directory
Kerberos Server Object
For Microsoft Entra Hybrid-joined machines, creation of the Microsoft Entra Kerberos server object within the Active Directory is required. This object will be used by Microsoft Entra to generate Kerberos ticket-granting tickets (TGTs) for the Active Directory domain. Kerberos TGTs allow users to sign in to Windows with modern credentials and then access traditional Active Directory-based resources. Kerberos Service Tickets and authorization continue to be controlled by on-premises Active Directory domain controllers (DCs).
The following link provides details regarding the configuration of the Kerberos Server object, Passwordless security key sign-in to on-premises resources – Microsoft Entra ID | Microsoft Learn. For our implementation, we have used a script to prompt for all credentials using modern authentication.
Citrix VDA
Session Lock Behavior
This section is only relevant if using Microsoft Entra hybrid-joined machines. When Windows is locked, the default behavior is to show the Windows lock screen, and at this time, only the username and password, and smart card authentication methods are supported.
For passwordless implementation, wherein users do not know their passwords, Citrix recommends disconnecting the session instead of showing the lock screen. This can be accomplished by creating scheduled tasks to execute cmd.exe /c tsdiscon in the event the session is locked. Citrix documentation provides a script to create a scheduled task; however, the task scheduler GUI can accomplish this as well.
Citrix Workspace Configuration
Enable Microsoft Entra ID Authentication
As mentioned above, the very first step for enabling Citrix Entra SSO is to configure Microsoft Entra as an Identity Provider (IdP). Verify that within the Identity and Access Management section of the Citrix Cloud console, Microsoft Entra is configured. Once that is complete, ensure Microsoft Entra is selected within Workspace authentication. If using Conditional Access, the authentication method within the Conditional Access policy is set to Azure AD (this is the default value; it is possible to create multiple Microsoft Entra ID providers, and each one has a unique name).
Create a Service Principal to Enable Microsoft Entra SSO with Workspace
This step is required if using the native Citrix Workspace client to access the Workspace. If you are using browser-only access, the Citrix browser extension is needed for integration of Citrix Entra SSO. This feature should work for HTML5 client version 2511, but I would recommend against using the HTML5 client.
The Citrix Cloud Service Principal is needed in Citrix–Microsoft Entra SSO integrations because it provides a secure, non-interactive identity that allows Entra and Citrix Cloud to communicate programmatically. In other words, it lets Citrix Cloud trust and interact with Entra during the authentication flow and configuration processes.
In Citrix Cloud, navigate to Identity and Access Management> API Access > Service principals. Select “Create service principal” and follow the steps. In our environment, a service principal has been configured as follows:
- Service principal name: Citrix-SSO
- Access: Full
- Secret expiration date: 12 months
NOTE: Please save your secret as it will be shown only upon creation of the service principal. If not saved at that time, you will not be able to recover it at a later date, and instead, you will need to create another service principal.
Enable Azure AD SSO on Workspace
Once the service principal is created, it is used to enable Azure AD SSO on the Workspace, which requires downloading the Citrix Workspace PowerShell module. The following script shows how to enable Azure AD SSO for Workspace.
Import-Module -Name “<extractedPath>\Citrix.Workspace.StoreConfigs.psm1”
Set-StoreConfigurations -StoreUrl "https://<yourPrimaryStore>.cloud.com" -ClientId "<clientId>" -ClientSecret "<clientSecret>" -AzureAdSsoEnabled $True
With this, the Workspace configuration is complete, and the last step is to configure the delivery group to which the Citrix VDAs belong.
Delivery Group Configuration
The last step in the process is to configure the logon type of the delivery group to which the VDAs belong. Configuring the logon type on the delivery group is required because it determines how the Virtual Delivery Agent (VDA) expects the user to authenticate to the Windows session after the user has already authenticated to Citrix Workspace via Entra.
Even though Entra performs the first authentication, the actual Windows VDI session also needs a valid Windows logon mechanism. The delivery group logon type informs Citrix how the second authentication step (on the VDI) happens.
The following scripts need to be executed on the delivery group based on the machine identity.
Microsoft Entra joined machines:
asnp citrix*
Get-XDAuthentication
Get-BrokerDesktopGroup -Name <dgName> | Set-BrokerDesktopGroup -MachineLogOnType "AzureAd"
Microsoft Entra Hybrid joined machines:
asnp citrix*
Get-XDAuthentication
Get-BrokerDesktopGroup -Name <dgName> | Set-BrokerDesktopGroup -MachineLogOnType "HybridAzureAd"
Final Thoughts
Citrix SSO with Microsoft Entra ID is a meaningful advancement, but it still comes with important design considerations. Although it removes the need for Citrix Federated Authentication Service (FAS) in supported scenarios, it is not supported with on-premises access tier (i.e., NetScaler and Citrix StoreFront. This remains a limiting factor for many larger enterprise environments that continue to rely on an on-premises Citrix access tier built around NetScaler and StoreFront.
The implementation also depends on several Microsoft Entra ID configuration elements, including enterprise applications, supporting objects, and delegated permissions. As a result, successful deployment typically requires early engagement with the Entra team and other relevant stakeholders to ensure prerequisites, ownership, and security expectations are clearly understood.
Even with these limitations, this feature is a strong step in the right direction. It supports a more modern and potentially passwordless authentication experience for Citrix DaaS, while reducing dependency on additional infrastructure in supported designs. For organizations aligning Citrix with a broader cloud-first identity strategy, this is a capability that architects and engineers should become familiar with.
Ferroque Systems has deep experience designing and implementing Citrix solutions across a wide range of enterprise environments. If your organization is exploring how Microsoft Entra ID authentication can fit into your Citrix architecture, we would welcome the opportunity to help assess, design, and implement the right approach.