None of us likes starting over. So if we don’t have to, why would we?
Unfortunately, with technology, many of us are forced to to follow a single path. That single path often requires us to start over. But this is one of the interesting things about Citrix Workspace and the user’s primary identity… Don’t start over – Simply integrate.
Okta integrates with Citrix Workspace to provide intuitive Single Sign-On (SSO) and Adaptive Multi-Factor Authentication (MFA), enabling a unified and secure workspace for each employee With apps, files, and other resources accessed in one convenient location, employees stay engaged and productive throughout the workday. Credential from Azure ADDS is used to logon at Citrix Cloud Workspace URL Solution Correct the SID in user's attribute at OKTA console, to match with the one which is used during Workspace URL logon.
With an overall understanding on primary/secondary identities within Citrix Workspace, we can better understand how Citrix Workspace integrates with Okta as an identity provider for a user’s primary identity. If our organization has standardized on Okta for identity, why would we want to move away from it to utilize a digital workspace?
Citrix Workspace simply brokers identity to your preferred identity provider, then leverages the user’s identity to generate of list of authorized resources to access.
Citrix Workspace accesses an OpenID Connect application created within Okta. The application authenticates the user with Okta, receiving two tokens in response:
- Access Token: Provides proof that the user can access the Okta resource
- Identity Token: Provides claims (info) about the authenticated user.
One of the interesting things about how this works is that the tokens sent back to Citrix Workspace are not impacted by any Okta MFA configurations. Okta authentication is a separate process from Citrix Workspace. If Okta configuration is based on password, SMS, TOTP (software/physical), Push, YubiKey or Windows Hello, then the result back to Citrix Workspace are the two tokens validating the user’s identity and authorizations. Your Okta admin can change the authentication policies without impacting Citrix Workspace.
Several months ago I posted on Twitter how you can use on-premises or cloud IaaS hosted Citrix Gateway/NetScaler Gateway, Workspace app/Receiver, and Okta as your identity provider (IdP) with SAML 2.0 authentication for full single sign-on. In the past the Receiver client did not have the capability to pop up a web view and embrace. To configure Okta in Citrix Cloud, see the Citrix Cloud article Connect Okta as an identity provider to Citrix Cloud. If Endpoint Management is Workspace enabled, this article also contains the steps for configuring Okta as the authentication method for Citrix Workspace. Configure Citrix identity as the IdP type for Endpoint Management.
This is extremely important because chances are the person responsible for Okta in your organization will most likely not be the same person responsible for Workspace.
Citrix Workspace Download
Once Citrix Workspace receives the claims contained within the identity token, the resource feed micro-service is able to generate a list of authorized resources. The claims are important because different resource feed types have different requirements on the claims returned by Okta.
- SaaS and Web apps: Uses the native Okta identity claims
- Windows-based apps: For Citrix Virtual Apps and Desktops (VDI), the Okta ID must be linked to an Active Directory account. The identity token returned by Okta must include the user’s Active Directory SID, UPN and GUID.
This is for authorization. When user’s launch one of these resources, we must authenticate to the resource, which is often categorized as Single Sign-On.
- SaaS applications: Utilize SAML-based authentication
- Windows apps/desktops: Utilize the Federated Authentication Service, which is able to use the Active Directory-based claims within the Okta identity token to provide single sign-on to Citrix Virtual Apps and Desktops (a topic for a future blog)
Take a look at the setup and user experience
Daniel (Follow on Twitter @djfeller)
In this post I wanted to discuss the use of Citrix Enlighted Data Transport with Citrix Gateway Service. This is a feature that has been available with Citrix ADC for quite some time but it is a new feature for Gateway Service. I wanted to take you through step by step on how to configure EDT and Adaptive Transport with Gateway Service, as well as discuss any system requirements that are needed to get you up and running.
Citrix Workspace Okta
What is Adaptive Transport
Adaptive transport is a proprietary transport protocol that functions well on highly latent networks, which TCP alone finds challenging. This protocol is adaptive and can switch to TCP or UDP based on network conditions in order to ensure the best user experience for users using HDX.
Enlighted Data Transport System requirements
- VDA 1912 or later
- Rendezvous protocol must be enabled and working ( We cover this next)
- Ports UDP 443 and TCP must be open outbound from VDA to the Internet
- Adaptive Transport must be enabled
- EDT is supported with all supported OS’s. Citrix do recommend the use of Windows 10 and Windows 2019 when running EDT with Citrix Gateway Service
- Latest Workspace App Version ( 1908 or above for Parallel connections)
Configuring Rendezvous Protocol
When you are configuring Rendezvous protocol for use with Citrix CVAD Service the following is required.
- VDA 1912 or later
- Enable the Rendezvous protocol in the Citrix policies in Studio
- The Cloud Connectors must obtain the VDA’s FQDN when brokering a session. This can be achieved by using the the following commands in Powershell:
- asnp citrix*
- Get- XDAuthentication
Set the DNS Resolution to True
Set-Brokersite -DNSResolutionEnabled $True
To check that the DNS Settings are configured correctly – Type Get-Brokersite
The DNS Resolution should now be set to True.
Citrix Policy Requirements
Now that the DNS settings are complete, we need to ensure the Citrix Policies are also set for Rendezvous protocol. (The Rendezvous protocol allows HDX sessions to bypass the Citrix Cloud Connector and connect directly and securely to the Citrix Gateway service.)
Please see more detail here: https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-service/hdx/rendezvous-protocol.html
To set the Citrix policy, Open Citrix Studio and create a new policy for Rendezvous protocol.
Click enable , and also enable Adaptive transport.
Lets also set up Session Reliability setting, as our final policy requirement. Enabling Session Reliability will allow users to automatically reconnect to Citrix sessions after a disruption.
Now that Rendezvous protocol is setup, lets move on to complete the setup to allow for the use of EDT.
Open Microsoft Group Policy Manager, and create a policy that will allow for you to set the Cipher Suite for the VDA workloads. Choose Computer configuration, Network, SSL Configuration, SSL Cipher Suite Order.
Lets now check if the settings are working as expected
Within the HDX session, launch a desktop and open powershell
Citrix Workspace Okta Log
The transport protocols used are displayed as below when successfully using EDT
Netscaler Okta Mfa
It is also possible to check via Director