Choosing the correct Identity Provider (IdP) for Citrix Cloud

Updated 22-09-2021!

Choosing the correct Identity Provider (IdP) for your new Citrix Cloud environment is one of the most discussed items and one of the first points when starting a new deployment. Most organizations already have an Identity Provider (IdP) and would like to give users the easiest way to migrate to their new deployments. Sadly it’s not always possible to keep it that simple.

I explain the pros and cons as much as possible and what I learned during my latest projects. I don’t have any experience with Okta or SAML, so I can’t give all the details about those issues. If anyone has additional information about the integration with Okta or SAML, please let me know, and I update the article. I look at Citrix Virtual Apps and Desktops services and Gateway Services integration for SSO to SaaS apps or Enterprise web apps.

My projects are starting with a migration of their traditional on-premises Citrix Virtual Apps and Desktops (CVAD) deployment and would like to move to a cloud setup. The reason for this varies per customer. At the start of a new project, we talk about customer requirements. The topics covered most are authentication, security, and application compatibility. When using Citrix Cloud, it is essential to make it clear which IdP to choose at the start of the project because we get more and more authentication options than on-premises when implementing a CVAD environment.

Scenario’s and requirements

Below I describe some scenario’s

  1. Double hop
    There are many customers that use published apps that start from another VM within their published desktop (called a double hop), and there are numerous reasons:
    1. The app is for archive only;
    2. The app doesn’t support the same OS as the desktop;
    3. The app conflicts with other apps;
    4. The app can only be used by some users, and licenses don’t allow us to install it on the same image as the desktop.

      In the case of a double hop scenario, you need an on-premises StoreFront, which means you still need to manage the StoreFront server and keeping it up to date. To configure a double hop with an on-premises storefront take a look here.
  2. Federated Authentication Service (FAS)
    When choosing AAD, Okta, or SAML for your CVAD requires a FAS server (or two for redundancy). FAS uses certificates to sign in to the VDA’s. To use FAS requires a Microsoft Certificate Authority. To make this secure, you have to install it with an offline root CA and an online issuing CA.
  3. SSO to Saas or enterprise web apps limitations
    When choosing AAD, Okta, or SAML with Citrix Gateway services, you could not use all SSO solutions to your SaaS apps. Basic and form-based SSO will not work. This is because when you authenticate, your credentials (username and password) aren’t cached in a hash on the gateway services. Only the authentication token is sent to the Gateway, and thus basic, and form-based SSO can’t get the credentials.   https://docs.citrix.com/en-us/citrix-gateway-service/support-web-apps.html
  4. Second public domain needed for Azure federation
    When choosing AAD, the primary domain is used for authentication to Citrix Cloud. You can’t use the same domain for federation to Azure for SaaS apps. This mostly isn’t a problem because most companies have multiple public domains, but you need to think of it. See: https://docs.citrix.com/en-us/citrix-gateway-service/saas-apps-templates/citrix-gateway-o365-saas.html#authentication-methods-supported-for-office365
  5. Password change not supported within Citrix Cloud
    When choosing AAD, Okta, or SAML, you can’t use the default option to let users change their password, and you need to configure this on the chosen IdP. This won’t stop your project, but you need to keep this in mind.
  6. Existing MFA provider
    When you need to support an existing MFA provider (RSA, Gemalto, etc.), you can get this to work with an on-premises setup only or with Okta.
  7. No support for authentication to Office 365
    When you need to authenticate your Office 365 applications from the Citrix Gateway services, this isn’t supported for Okta and SAML.
    https://docs.citrix.com/en-us/citrix-gateway-service/saas-apps-templates/citrix-gateway-o365-saas.html#authentication-methods-supported-for-office365

Identity Providers

Looking at the available IdP’s, Citrix Cloud currently support the following:

  1. Active Directory
  2. Active Directory + token
  3. Azure Active Directory (AAD)
  4. Citrix Gateway (on-premises)
  5. Okta
  6. SAML 2.0

I explain all the IdP’s one by one and give some pros and cons I experienced during my last projects.

On-premises AD with or without token

I combine options 1 & 2 because the main functionality is the same. The only difference is a token code that gives some extra security.

Using your on-premises AD (with a token) is the easiest setup. You only need to add two cloud connectors, and you’re good to go. You can use all the services without any additional requirements. In the case of Citrix Gateway SSO, this enables you to also use form-based authentication with on-premises SaaS apps.

Pros:

  1. Easy setup
  2. No additional requirements
  3. Free MFA
  4. SSO with form-based authentication
  5. Allows password Changes

Cons:

  1. When using this token, users need to replace their current MFA or need another MFA solution.

Azure Active Directory (AAD)

As more and more companies are using Azure AD, as needed when using Microsoft 365, Microsoft keeps adding features to the suite. One of those features is Azure MFA, where you can use conditional access (with the appropriate license). With conditional access, it’s possible to give users the option to only sign in with username and password from trusted locations (think about HQ and branch offices).

Pros:

  1. You can use your existing Azure MFA for Citrix
  2. You don’t need additional MFA products
  3. Conditional access
  4. Users can sign in with there same username and password as AD

Cons:

  1. FAS server required
  2. Double hop only with on-premises StoreFront
  3. SSO to SaaS or enterprise web apps limitations
  4. Second public domain needed for Azure federation
  5. Password change not supported with Citrix Cloud
  6. Can’t use existing MFA solution

Citrix Gateway (on-premises)

When you have a Citrix Gateway (f.k.a. NetScaler Gateway), you could use that to manage the authentication to your on-premises domain. Using the Gateway gives you more flexibility to the way users are going to sign in.  When looking at MFA, the on-premises Gateway gives you the possibility to use your current MFA solution, like Gemalto, RSA, or Azure MFA. The downside is that you will need to maintain an on-premises gateway. And because that is your point of entry to your environment, you need to keep it very secure.

Pros:

  1. More flexibility in authentication providers with or without MFA
    When using MFA, make sure the LDAP password is the default password (https://docs.citrix.com/en-us/citrix-cloud/citrix-cloud-management/identity-access-management/connect-ad-gateway.html#troubleshooting)
  2. Keep using load balancing
    When using an on-premises gateway, you could leverage all the functionality of the appliance. This gives you the option to use it for load balancing features

Cons:

  1. More costs and management you need to manage, update, and buy support for the appliance. Which will cost you more than using the Gateway Services  managed and updated by Citrix
  2. Password change not supported with Citrix Cloud
  3. Double hop only with on-premises StoreFront

Okta

Pros:

  1. Use existing MFA solutions (if supported)
    https://help.okta.com/en/prod/Content/Topics/Security/mfa/about-mfa.htm
  2. Use Okta as your IdP for multiple scenarios

Cons:

  1. No support for authentication to Office 365
  2. FAS server required
  3. Double hop only with on-premises StoreFront
  4. SSO to SaaS or enterprise web apps limitations
  5. Password change not supported with Citrix Cloud

Security Assertion Markup Language (SAML)

SAML is currently in technical preview. SAML 2.0 is now generally available. All pros and cons are based on information that Citrix provides in its documentation. Take a look at the Citrix blog for more info.

 Pros:

  1. Use the same SAML setup for more partner/app integrations

Cons:

  1. No support for authentication to Office 365
  2. FAS server required
  3. Double hop only with on-premises StoreFront
  4. SSO to SaaS or enterprise web apps limitations
  5. Password change not supported with Citrix Cloud

Looking at all these pros and cons could make it hard to choose the right Identity provider. I hope this article is a good starting point and makes a choice easier so you won’t have the same issues I had during my latest projects.
Would you please let me know if you have some pros and cons I have forgotten to mention or need some additional information?

NetScaler: Using groups membership to Authenticate

When using the NetScaler Gateway 10.x and you need to allow remote users access based on their group membership, you can use the Active Directory groups. To configure this create an Active Directory group and set the following settings on the LDAP server within the NetScaler go to: NetScaler Gateway > Policies> Authentication/Authorization> Authentication> LDAP and then Servers tab and then edit/create the LDAP server:

Connection Settings:

  • IP address: your Domain Controller
  • Port: 389
  • Base DN: dc=subdomain,dc=domain,dc=nl
  • Administrator Bind: Administrator account

Other Settings:

  • Server Logon Attribute: sAMAccountName/UserPrincipalName
  • Search Filter: memberOf=CN=XenDesktop Remote ,OU=Groups,OU=Resources, DC=subdomain,dc=domain, DC=nl
  • Group Attribute: memberOf
  • Sub Attribute Name: CN
  • Security Type: PLAINTEXT

Nested Group Extraction:

  • Maximum Nesting Level: 2
  • Group Name Identifier: sAMAccountName/UserPrincipalName
  • Group Search Attribute: memberOf
  • Group Search Sub-Attribute: CN
  • Group Search Filter: <BLANK>

Groups

I Hope this helps you.