How to enable a seamless SSO experience using Citrix Workspace, Okta and FAS.

In my many years at Citrix, one sentence has always stuck with me throughout these years and I do truly believe in it!

If the user experience is not as good as you had previously or better, then adoption will fail, user experience is king!”

I am sure we are all familiar with similar sayings, and whilst I obviously agree with this, I also appreciate that security is equally as important and should not be overlooked.

We also need to appreciate that whilst we as vendors would love our customers to use all our technology stack, the reality is that’s not always the case, for many reasons this means that the customer then has the challenge of whether or not they can get these technologies to work seamlessly together.

In this blog, I am going to take you through something that I have heard a lot from customers, its one specific use case but an example of how two technology vendors can come together to give an experience that’s expected by users.

The Problem

For many of our existing customers when using the likes of Storefront, they have been able to get a seamless SSO experience from Windows Domain Joined devices, going back as far as the likes of PN Agent, to more recently, Receiver.

As we look to help our customers transition to Workspace, this experience is essential to a lot of our customers. Going back to that experience statement at the very beginning, if you were to try this today with Workspace you would not get this experience and that is the purpose of this blog, to show you how we can help address these user challenges as they look at transitioning to the cloud.

The Solution

From a domain joined device, launch Workspace via a browser or the native Workspace application and get pass through (SSO) into Workspace, removing the need to for any additional user authentication.

Citrix Workspace with passthrough using a browser

Citrix Workspace app with passthrough (Windows Domain Joined)

Citrix Workspace app with passthrough (Mac Domain Joined)

By the end of this blog, you should have a good understanding of how with Citrix Workspace + Okta you can deliver an experience that will make your users want to use the Workspace.

Whilst this blog is specific to Okta; the theory is that this can be done with other Enterprise Identities such as AAD, perhaps another blog?

What will you need?

• Citrix Cloud
  • Cloud Connectors
  • Citrix Workspace
  • Federated Authentication Service (optional but recommended)
• Citrix Virtual Apps & Desktop Service
  • AD Domain joined VDA or physical AD joined devices (Windows or Mac)
• Okta Tenant
  • Okta IWA Agent (Integrated Windows Authentication)
  • Okta Verify (This is downloaded from the Appstore) (optional but recommended)
• Active Directory

This is not a step by step guide; I will reference any blogs or documentation I used to get this working during my setup!

The order I have listed these in, is not the order in how we will do things.

Citrix Cloud

Existing Citrix Cloud customer

If you already have a Citrix Cloud tenant up and running and have a Resource Location with cloud connectors deployed within that Resource Location, then you are all set to move to the next step!

New to Citrix Cloud

If you do not have a Citrix Cloud tenant, then you can sign up for a trial

https://docs.citrix.com/en-us/citrix-cloud/overview/citrix-cloud-service-trials.html

You will need to define a Resource Location and have the connectors configured and healthy.

It is recommended to have at least two cloud connectors deployed in production environments, but it is not essential for Proof of Concepts and testing.

You can find documentation on how to install Citrix Cloud connectors here, installation is straightforward.

https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-resource-locations/citrix-cloud-connector/installation.html

Okta

You can sign up for an Okta trial here.

Once you have signed up, you will need to deploy the Okta AD Agent, you can download this within the Okta Admin portal.

From the menu at the top, choose Directory, Directory Integrations

Click on the Add Directory option and select Add Active Directory

You will now be prompted with a simple workflow, which covers off the Agent Architecture and Installation Requirements

Click on the Set Up Active DIrectory

Click on the Download Agent

Once downloaded, you can install this onto a Windows server as per the guidance in the above image covering the Installation Requirements

Documentation can be found here on how to install, again its very straight forward to install and setup.

https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-prerequisites.htm

Once installed you should see something similar to above

Okta gives you the ability to decide what you want to sync. In my lab, I have very few accounts so chose to sync all users, the trial is limited to 100 active users.

Once this is configured and working you should be able to login with user credentials whose users account have synched from AD to Okta.

I would recommend enabling one of the many MFA options available within Okta, for this blog, I used Okta Verify. However, you can choose one of the many MFA options available.

Okta – Integrated Windows Authentication (IWA)

Next lets setup IWA, this is another agent, you can run this on the same machine that runs the OKTA AD Agent.

Click on Security and then Delegated Authentication

Scroll down to the On-Prem Desktop SSO part on the page that loads

Click on Download Agent

Click the link to download the agent, this link is very helpful in setup and troubleshooting

https://help.okta.com/en/prod/Content/Topics/Directory/Configuring_Desktop_SSO.htm

Make sure that you have setup the Routing Rules for IWA, I had missed this out, so for a while mine did not work, the link above is a very good article on troubleshooting.

If all is setup correctly you should see the agent calling back into OKTA, you can see this in the agent status.

Now that you have the Okta IWA Agent installed and the status is enabled, you should be able to login from a Windows Domain joined device

Launch the Okta customer portal, you should notice that it jumps past the login and directs you to the IWA login page and passes the user credentials through.

You should see something similar to the above, if not then review the document on troubleshooting.

Now that all the Okta configuration is complete, we can move on to the Citrix piece, we should not need to go back in to the Okta Admin portal now, unless you want to setup MFA, which I will cover off later in this article.

If you want to go a step further than I have you could look at the agentless option with Okta, whcih means no need for the IWA Agent

https://help.okta.com/en/prod/Content/Topics/Directory/Configuring_Agentless_SSO.htm

Citrix Cloud – Okta as an IDP

Next we need to login to the Citrix Cloud admin portal and enable OKTA as the IDP, I used Dan Feller’s video to do this from Citrix Tech Zone.

https://docs.citrix.com/en-us/tech-zone/learn/tech-insights/okta.html

Some of the screen shots in this documentation are from a version before Oktane 2020, so they have changed slightly, at least that was my experience when I used this documentation.

Once you have this working, you can now login from the same domain joined devices, this time use the Workspace URL for your Citrix Cloud customer.

You can do this from either the Workspace app or browser, both should give the pass-through experience as per the videos shown earlier in the blog.

Federated Authentication Service

Now that we have pass through auth working, we need to ensure that as we launch workloads, we get SSO to our HDX workloads.

FAS is optional here, however if you are using HDX workloads and want your users to have a seamless SSO experience then this is recommended when using an IDP such as OKTA, without this the user will be prompted for the AD username and password.

I used Jason Samuels blog to get this setup, you can find that here

Whilst it does refer to AAD, the setup is very similar, this blog was very helpful and the troubleshooting at the end helped me with some issues I had due to a failed domain controller in my lab.

Enabling MFA in Okta

So now we have a very slick user experience where a user can just login to their domain joined device and get SSO to all resources within Workspace, as I said at the beginning, Security is also equally as important here.

What I will take you through here is having context of when we should challenge for a second factor, in my lab I used OKTA Verify, I really like this as it uses Push which really helps with the user experience, especially to the users who probably using similar when using the likes of Xbox and Facebook.

Here is a very detailed document from Okta although it’s very straight forwards to get setup.

Get started, once you are logged into the Okta portal as an admin, navigate to

Click, Security and then Multifactor

To give a nicer experience I enabled Push Notifications and Require Touchid for Okta Verify, this is also used for Faceid, so it will enable for both Touch and Face.

Now that you have this enabled, we need to set the Factor Enrollment

Set Okta Verify as Required. Push is optional, but I do feel it gives a nicer experience to the end user.

Update the policy, now we just need to add a couple of policies for when we will bypass MFA and when we will challenge for MFA.

Back at the menu options select Security and then Networks

Click on Add Zone, IP Zone

From my brief experience with Okta, two networks appear by default:

• BlockedIpZone
• LegacyIpZone

Home is a Zone I have setup myself and is used to define that when I login, this IP is detected then we can then take an action on that.

You can enter your Gateway IPs manually, or there is the Add your current IP address option, once this is added you can click on Save

Now we just need to add two basic Policies

I created two rules and used my network called Home I left the rest as default, but you can play around with this to tailor for your own lab.

MFA Bypass – this essentially will not prompt for MFA if you are in a specific Zone.

MFA Required – prompts all users for MFA unless they are in the zone(s) in the bypass rule.

With this now in place you should now be set to test your environment.

Summary

So to summarise, hopefully you can see what kind of experience you can achieve when using Citrix & Okta together to help drive the kind of experience we all want.

Whilst the blog is specific to passthrough, I did go into some extra details around Citrix FAS to show that full end to end experience and additionally Okta with MFA to also address security concerns, additonally showing the contextual aspects from Okta and how they can work just as well when using Citrix Workspace.

I hope you have found this helpful, please feel free to leave any comments, all feedback is welcome!

Advertisement