Citrix Cloud Okta SSO

Okta + Citrix Workspace | Okta

In this 2 parts article, I will provide step-by-step guidance on how to configure Citrix Cloud with Okta authentication and SSO for domain-joined computer connecting within the corporate network.

In this first part, we will configure:

  1. Cloud Connectors
  2. Okta
  3. Citrix Cloud Okta connection
  4. Citrix Workspace configuration
  5. Validate

Cloud Connectors

First thing that you will need to configure if you are new with Citrix Cloud will be to configure Cloud Connectors.

Here are the steps:

  • Deploy Windows Server(s).
  • Join the server(s) to your AD Domain.
  • Update the Windows Server(s) OS with all Windows patches.
  • Connect to https://us.cloud.com and authenticate.
  • Click on Menu and select Resource Locations.
  • Click on Cloud Connectors.
  • Click on Download.
  • Click on Run.
  • Click on Install.
  • Select Customer if multiple and click on Install.
  • Click on Close.
  • Click on Refresh.
  • Cloud Connector should be listed (an update may be required, if so server will be updated and rebooted).
  • After successful update and reboot, Cloud Connector should appear as Green.

Citrix Cloud Okta Configuration

Okta OIDC Web Application

To use Okta as an identity provider, you must first create an Okta OIDC web application with client credentials you can use with Citrix Cloud. After you create and configure the application, note the Client ID and Client Secret. You supply these values to Citrix Cloud when you connect your Okta organization.

Create an Okta OIDC web application.

  • From the Okta management console, under Applications, select Applications.
  • Click Add Application 
  • Click Create New App.
  • In Sign in method, select OpenID Connect and then click Create. The Platform default value (Web) is unchanged.
  • Enter an application name.
  • In Logout redirect URIs, enter your Workspace URL from Citrix Cloud.
  • Click Save.

Configure the Okta OIDC web application.

In this step, you configure your Okta OIDC web application with the settings required for Citrix Cloud. Citrix Cloud requires these settings to authenticate your subscribers through Okta when they sign in to their workspaces.

  • From the Okta application configuration page, in General Settings, click Edit.
  • In Allowed grant types, select the following options:
    • Authorization Code
    • Refresh Token
    • Implicit (Hybrid)
    • Allow ID Token with implicit grant type
    • Allow Access Token with implicit grant type
  • Click Save.
  • Allow user or group access to the application:
    • From the Assignments tab, select Assign and then select Assign to People or Assign to Groups.
  • Select the users or groups you want to have access to workspaces. To allow access for all users, select Assign to Groups and then select Everyone.
  • Click Done.
  • Add application attributes. These attributes are case-sensitive.
    • From the Okta console menu, select Directory > Profile Editor.
  • Locate the Okta user profile and select Profile. Under Attributes, select Add attribute.
  • Enter the following information:
    • Display Name: cip_sid
    • Variable Name: cip_sid
    • Description: AD User Security Identifier
    • Attribute Length: Greater than 1
    • Attribute Required: Yes
  • Click Save and Add Another.
  • Enter the following information:
    • Display Name: cip_upn
    • Variable Name: cip_upn
    • Description: AD User Principal Name
    • Attribute Length: Greater than 1
    • Attribute Required: Yes
  • Click Save and Add Another.
  • Enter the following information:
    • Display Name: cip_oid
    • Variable Name: cip_oid
    • Description: AD User GUID
    • Attribute Length: Greater than 1
    • Attribute Required: Yes
  • Click Save.
  • Edit attribute mappings for the application:
    • From the Okta console, select Directory > Directory Integrations.
  • On the Settings tab, select Edit Mappings.
  • Map the following attributes:
    • Select appuser.objectSid and map to the cip_sid attribute.
    • Select appuser.userName and map to the cip_upn attribute.
    • Select appuser.externalId and map to the cip_oid attribute.
  • Click Save Mappings.
  • Click Apply updates now.

Workspace URL

When creating the Okta application, you must supply your Workspace URL from Citrix Cloud. To locate the Workspace URL, select Workspace Configuration from the Citrix Cloud menu. The Workspace URL is shown on the Access tab.

IMPORTANT:

If you modify the workspace URL later on, you must update the Okta application configuration with the new URL. Otherwise, your subscribers might experience issues with logging off from their workspace.

Okta API token

Using Okta as an identity provider with Citrix Cloud requires an API token for your Okta organization. Create this token using a Read-Only Administrator account in your Okta organization. This token must be able to read the users and groups in your Okta organization.

To create the API token, see Create an Okta API token in this article. For more information about API tokens, see Create an API Token on the Okta website.

IMPORTANT:

When you create the API token, make a note of the token value (for example, copy the value temporarily to a plain text document). Okta displays this value only once, so you might create the token just before you perform the steps in Connect Citrix Cloud to your Okta organization.

Create an Okta API token

  • Sign in to the Okta console using a Read-Only Administrator account.
  • From the Okta console menu, select Security > API.
  • Select the Tokens tab.
  • Select Create Token.
  • Enter a name for the token and click Create Token.
  • Copy the token value. You supply this value when you connect your Okta organization to Citrix Cloud.

Sync accounts with the Okta AD agent

To use Okta as an identity provider, you must first integrate your on-premises AD with Okta. To do this, you install the Okta AD agent in your domain and add your AD to your Okta organization. For guidance for deploying the Okta AD agent, see Get started with Active Directory integration on the Okta web site. Afterward, you import your AD users and groups to Okta. When importing, include the SID, UPN, and OID values associated with your AD accounts.

Note:

If you are using Citrix Gateway service with Workspace, you don’t need to synchronize your AD accounts with your Okta organization.

To synchronize your AD users and groups with your Okta organization:

  1. Install and configure the Okta AD agent. For complete instructions, refer to the following articles on the Okta website:
  2. Add your AD users and groups to Okta by performing a manual import or an automated import. For more information about Okta import methods and instructions, refer to Manage Active Directory users and groups on the Okta website.

Connect Citrix Cloud to your Okta organization

  • From the Citrix Cloud menu, select Identity and Access Management.
  • Locate Okta and select Connect from the ellipsis menu.
  • In Okta URL, enter your Okta domain.
  • In Okta API Token, enter the API token for your Okta organization.
  • In Client ID and Client Secret, enter the credentials for your Okta application. To copy these values from the Okta console, select Applications and locate your Okta application. Under Client Credentials, use the Copy to Clipboard button for each value.
  • Click Test and Finish. Citrix Cloud verifies your Okta details and tests the connection.

Enable Okta authentication for workspaces

  • From the Citrix Cloud menu, select Workspace Configuration > Authentication.
  • Select Okta. When prompted, select I understand the impact on the subscriber experience.
  • Click Save.

Validation

  • Open a Web Browser and point to your Workspace URL.
  • You will be redirected to your Okta portal.
  • Provide Username and Password and click on Sign In.
  • Click on Send Push and validate on your Device.
  • Validate you have access to Workspace.

Now, we will configure:

  1. The Okta MFA Bypass
  2. The SSO for internal domain-joined computer authentication to Citrix Cloud

How to Okta MFA Bypass?

  • Connect to your Okta Portal.
  • Click on Security.
  • Click on Networks.
  • Click on Add Zone and select IP Zone.
  • Provide a name for your Zone and the Gateway IP to be used, then click on Save.
  • Click on Authentication.
  • Click Sign On Tab and on Add Rule.
  • Provide a Name for the Rule, select In zone and add your Zone. Uncheck Prompt for Factor and click on Create Rule.
  • Create another rule that will require MFA for User’s IP coming from Anywhere.

Validate Okta MFA Bypass

Here is a video showing the Okta MFA Bypass

SSO for Corporate Devices

In the following example, we will consider that we want Corporate devices, domain-joined computer accessing Citrix Cloud from a Corporate (HQ or Office network) to not prompt user for authentication.

We will use Okta IWA Web agent which is a lightweight Internet Information Services (IIS) web agent that enables Desktop Single Sign-on (DSSO) on the Okta service.

Okta IWA Web agent

What is Okta IWA Web Agent?

The Okta IWA Web agent is a lightweight Internet Information Services (IIS) web agent that enables Desktop Single Sign-on (DSSO) on the Okta service. DSSO allows users to be automatically authenticated by Okta and any apps accessed through Okta, whenever they sign into your Windows network. The Okta IWA Web agent uses Microsoft’s IWA and ASP.NET to authenticate users from specified gateway IPs. 

 

When you have only one forest it doesn’t matter to which IWA agent requests are routed. When you have multiple forests, you need to start taking network configuration into consideration. You need to ensure that user A on machine A only redirects to IWA agents that are in forest A, and user B on machine B only redirects to agents that are in forest B. The suggested way of doing that is redirecting the traffic from Okta to a global redirect URL, and then setting up your on-prem DNS to do the correct routing for that endpoint. You may also need to set up on-prem load balancing and the ability to detect which agents are online and offline into your load balancer.

Okta strongly recommends that you transition to using Secure Sockets Layer (SSL) with the on-premises agent. This is not only an important security provision, but it is also a hard requirement for application authentication (in particular, Windows 10 Universal Applications such as OneNote, Mail).

Okta IWA Web agent installation prerequisites

The following are the prerequisites for installing the Okta IWA Web agent:

  • You must have installed and configured the Okta AD Agent and Delegated Authentication must be enabled before you can configure IWA DSSO. See Manage your Active Directory integration.
  • Make sure that Port 80 (for http) and Port 443 (for https) are open for inbound traffic on the same server that hosts the Okta IWA Web agent.
  • Note: Okta strongly recommends that you enable SSL.
  • Windows Server 2008 R2, Windows Server 2012, Server 2016 or Windows Server 2019 and higher. Although the IWA Web Agent will also work with Windows Server 2008, for best results, Okta recommends Windows Server 2008 R2 and Windows Server 2012.

If you use Windows Server 2008 R2, keep in mind the following:

  • Microsoft requires Windows Server 2008 R2 users to have an extended support agreement. Also, Microsoft plans to EOL Windows Server 2008 R2 by 2020.
  • Additional security configuration is required if your IWA Web agent is installed on a server running Windows Server 2008 R2. For more information, see Enable the Transport Layer Security 1.2 protocol.
  • .NET 4.5.2 (minimum) up to  .NET 4.6.x  and ASP .NET 4.5.  If you have a lower version of .NET, upgrade to 4.5.2 or higher.
  • To improve the security of our integrations, we now only communicate using TLS 1.2 security protocol. Ensure you are running .NET framework 4.5.2 or later so the AD agent installs correctly. For Windows 2008 R2 TLS 1.2 is disabled by default and must be enabled through the registry. If you have Windows 2008 R2, ensure the following regkeys are set correctly:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] “Enabled”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] “DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] “Enabled”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] “DisabledByDefault”=dword:00000000

  • IIS 7.5 or higher must be installed on the server. If the required IIS version is not installed, the installer quits and you receive an error message.
  • AD Agent 3.0.4.x or higher. The Okta AD Agent does not have to be on the same server that hosts the OktaIWA Web agent. 
  • If your enterprise has more than one domain, see Configuring UPN Transformation.
  • The IWA agent doesn’t require any extra privileges beyond the default permissions the user inherits from the Domain Users group. However, note the following:
  • The installer configures some additional local permissions for the service account to allow it access the web-application files.
  • The IWA agent requires read and execute permissions for files in C:\inetpub\webroot\IWA.
  • If you want to use an existing account, then ensure:
    • the account is active and the password never expires
    • the account has permissions to read and execute for the C:\inetpub\wwwroot\IWA directory and its content

Install the Okta IWA Web agent

The Okta Administrative Account used during Okta IWA Agent installation must have Super admin permissions.

Note: When you install the Okta IWA agent the IP address of the client is added to the LegacyIPZone. For details, see Network Zones and IWA.

  • In the Admin Console, go to Settings > Downloads
  • In the SSO IWA Agents area, click Download Latest.
  • Browse to the location where you downloaded the installation file and double-click OktaSsoIwa-x.x.x.
  • Click Next.
  • In the Web Application Pool Identity dialog box, select Create or use the OktaService account, then click Next.
  • Optional. When prompted, specify a proxy server for your IWA Web agent.
  • On the Register Okta Desktop Single Sign-On screen, select an environment (ProductionPreview, or Custom), enter your Okta customer subdomain name, and then click Next.
  • On the Okta Sign In page, enter your Super admin username and password, and then click Sign In.
  • To grant permission to access the Okta API, click Allow Access.
  • When the message Installation completed appears, click Finish.
  • In the Admin Console, go to Security > Delegated Authentication and in the On-Prem Desktop SSO area, confirm the Okta IWA Web agent is connected.

Configure Windows browsers for SSO

Although IWA SSO may work if you choose not to configure your browser, Okta recommends that you review the relevant information for your browser type and then configure your browser as described if appropriate for your environment.

 The Microsoft Edge browser is not supported.

  • Add your Okta tenant URL and the URL of the server that hosts your Desktop SSO IWA Web agent to your trusted zone:

Note: The URL hostname.companyname.com is the fully qualified domain name of the server in question.  For example,  my-iis7-host.corp.acme.com. It is not sufficient for this URL to be listed as a Trusted Site in the Trusted Sites zone.

Most organizations set up a Group Policy to configure this setting in their users’ Internet options.

  • On your Windows Control Panel, select Network and Internet > Internet Options > Security > Local intranet > Sites > Advanced.
  • In the Add this website to the zone field, enter:

https://hostname.companyname.com or http://hostname.companyname.com

and

https://_subdomain_.okta.com or https://_subdomain_.okta-emea.com or https://_subdomain_.oktapreview.com as appropriate.

  • Click Add.
  • Click OK twice to close Internet Options.
  • Configure your browser:

Windows Internet Explorer

  • In Internet Explorer select Tools > Internet Options.
  • Click the Advanced tab, scroll down to the Security settings, and select Enable Integrated Windows Authentication.
  • Click OK.

Make sure that Internet Explorer can save session cookies (Internet Options > Privacy tab). If it cannot, neither SSO nor standard sign in can work.

 

Mozilla Firefox

The following configuration permits Firefox to properly pass the Kerberos ticket with IWA, but Firefox still warns the user about the transition from an HTTPS page to an HTTP page. To resolve this issue, deploy IWA in HTTPS mode.

  • In the Firefox address bar enter: about:config

In Firefox version 3.x and later, a warning message displays. Click the button to clear the message and proceed.

  • When the configuration page loads, enter the following in the Search field:

network.negotiate-auth.trusted-uris

  • In this field list the host name of the IWA server(s), separating multiple values with a comma  ‘,’  if two or more IWA instances are deployed.

Okta recommends that you enter the fully qualified domain name (FQDN) of your IWA host servers. If you do not, you will also need to toggle the following values to TRUE:

If you enter more than one host name, the order does not matter.

network.automatic-ntlm-auth.allow-non-fqdn

network.negotiate-auth.allow-non-fqdn

  • Right click the Value column for each of the above and toggle the value to True.
  • Click OK.

 

Google Chrome

IWA is automatically enabled on Chrome for Windows and the capability is allowlist-driven. If your browser is asked by a site to provide the Kerberos ticket, the browser only supplies the ticket to the site if the site is on a allowlist.

The allowlist is provided to the browser at startup using this command-line parameter:

–auth-server-whitelist=

For example:

–auth-server-whitelist=”*hostname.companyname.com”

This tells Chrome that any URL ending in hostname.companyname.comis in the permitted list.  Without the ‘*’ prefix, the URL has to match exactly.

The hostname.companyname.com value refers to the server hosting the OktaIWA Web agent.

If the ‘–auth-server-whitelist’ command-line parameter is not specified at startup, the permitted list includes the servers in the Local Machine or Local Intranet security zone. This behavior is consistent with Internet Explorer.

To start Chrome on Windows and supply this command-line parameter:

  • Right click your desktop Chrome icon or select Start > All Programs > Google Chrome and right click Google Chrome, and then select Properties.
  • In the Target field, move the cursor to the end of the existing value and add the text of your new command-line parameter.
  • Click OK.

Activate the Okta IWA Web agent

After you have configured all the settings appropriate to your environment and tested Desktop SSO, do the following:

  • In the Admin Console, go to Security > Delegated Authentication.
  • In the Agentless Desktop SSO area, click Edit and select On.
  • Click Save.
  • Click on Identity Provider routing policies.
  • Click on Add Routing Rules.
  • Provide a name, select In zone, select the required Zone and select OnPremDSSO. Click on Create.
  • Click on Activate.

Test the Okta IWA Web agent

After downloading and installing your Okta IWA Web agent, test it to make sure the IWA server is working from a client machine.

  • In the Admin Console, go to Security > Delegated Authentication.
  • Scroll down to On-Prem Desktop SSO and click Edit.
  • In the IWA Agents area, click Edit .
  • Select and copy the URL in the IWA redirect URL field.
  • Paste the IWA redirect URL in a browser that has been configured for SSO, and then add authenticated.aspx to the end of the URL. For example, if your IWA redirect URL is https://LAB-AD-01.lab.local/IWA/ enter https://LAB-AD-01.lab.local/IWA/authenticated.aspx in your browser.
  • Press Enter .

If you configured IWA correctly, three rows of results are returned. If the Okta Sign-In page displays instead of the success message, the test was unsuccessful.

Test Okta IWA Web agent Desktop Single Sign-on

After you have installed and configured your IWA Web agent and set up your browser, do the following:

  • In the Admin Console, go to Security > Delegated Authentication.
  • Scroll down to On-Prem Desktop SSO and click Edit.
  • Select Test and then click the test URL.

If you are authenticated successfully, continue to step 4. If you are not authenticated, check any browser configuration changes that you may have made in either Configuring Desktop SSO with IWA for Windows or Configuring Desktop SSO with IWA for Mac.

  • Click Save.

Validation

Here is a video showing the Okta MFA Bypass and SSO for a domain-joined computer accessing Citrix Cloud from a corporate Network.

 

I hope that that 2 articles will help you understand how to configure Okta MFA Bypass and SSO.

 

Feel free to share.

 

Thanks!