Citrix DaaS – Adaptive Authentication

Reading Time: 7 minutes

Overview

What is Citrix Adaptive Authentication? It’s part of Citrix Secure Private Access (SPA) and it’s building the authentication engine for SPA and for Cloud Workspace. Technically, Citrix is hosting an ADC HA-Pair on Azure – more precisely it’s two VPX AZURE AA (100) instances – and you are able to configure the hosted ADC with your favorite auth-mechanism.

If you’re not interested in technical background, but want to understand what Adaptive Authentication is, you can jump directly to Summary.

Typical as a Citrix Cloud Service, both ADC instances are based on a current 13.1 build, newer than you’re able to download.

You have to know about the restricted advanced license, which the service brings to:

Adaptive Authentication ADC restricted advanced License

First of all, configuring Adaptive Authentication is definitely easier if you’re having experiences and worked with ADC features before. It’s not possible to setup the service for productive usage without any practical ADC know-how.

The authentication flow is working with http 302 redirect to the hosted ADC, after the authentication is successful, the user get back to the Cloud Workspace URL.

Cloud Workspace Adaptive Auth Flow

Let’s reveal some insights about the technical configuration (and limits 🙂 ) and some cost perspectives.

Prerequisites

If you want to start with Adaptive Authentication, make sure the following requirements are present:

  • Active Subscription to DaaS Premium / DaaS Premium Plus or SPA Advanced.

  • A public domain which is owned by you or a customer and where you are able to create public DNS records.

  • During the setup wizard, Citrix Cloud is creating a public IP, where you have to create the DNS records for.

  • Citrix is recommending to access the HA instance-consoles using FQDN, so you have to create another two DNS records, for example adaptivemgmtprimary.customer.com and adaptivemgmtsecondary.customer.com where you have to bind certificates on each instance.

  • A public SSL certificate which matches your chosen adaptive auth redirect FQDN. Ensure the SAN attribute is contained, otherwise the certificate is not accepted.

  • Choose your connectivity type if you would like to connect OnPremises AD / RADIUS mechanisms. You can go by Citrix Cloud Connector (Only Windows based is supported, Connector appliance is not supported atm) or Azure VNet peering.

  • Copy your Citrix Cloud customer ID (CCID) and make sure to only paste it in case sensitive, it should always be in all lowercase.

Configuration

At the moment, the Adaptive Authentication user interface isn’t an own service catalog, means you have to access the interface directly by https://adaptive-authentication.cloud.com/ or navigate to Identity and Access Management > Authentication > Adaptive Authentication and choose Manage in the ellipsis menu.

I will not go through all provisioning and basic configuration steps, as this is well documented in Citrix Product documentation and you’re getting a step by step wizard during the provisioning process, where all the things are well explained.

Following, just a few notes during the setup.

Upload Certificate and set DNS Record

The adaptive auth mgmt consoles (= ADC NSIP) will only be accessible from a maximum of five public source IPv4 addresses, getting a higher security perspective.

MGMT IPv4 Source restriction

Now you are able to access the management consoles, as Citrix has created a HA-Pair of instances with two different public IPs. Citrix recommends accessing the adaptive auth management console using FQDN instead of IP (Also as using the IP address is not trusted and many browsers block the access with warnings).

Please use the Primary IP address / FQDN for any configuration changes. You also have to remember the following note:

MGMT Instance FQDN

Create two DNS records, for example adaptivemgmtprimary.customer.com and adaptivemgmtsecondary.customer.com pointing to the public IPv4 entries above and use these to access the ADC MGMT interfaces.

As we would like to have full control about HA-Failover (The instances in azure are provisioned in separate availability zones to safeguard against data loss), there is the option to edit the HA-mechanism to STAY PRIMARY – so only in a failover it will publish the secondary to primary and if the first is back online, it will auto-failover back to the initial primary node. This is a common used setting in typical OnPrem ADC deployments, too.

ADC HA Node State configuration

The first login will show you the well known welcome ADC wizard. DO NOT add any Subnet IP (SNIP) and just use “Do it later”.

It’s well recommended to set your timezone and make the use of public accessible NTP servers, so you don’t get any time differences with your OnPrem / Cloud hosted Workload.

Adaptive Auth first login Wizard

When ADM is used on the same Cloud tenant, the two adaptive auth ADC instances get automatically registered with your ADM, so you are able to get some more insights via ADM – but don’t configure firmware-update jobs with ADM, as this is part of Citrix Cloud.

ADM Auto-Registration

Further Manual Rework

Things I recommend to go through after the deployment process, BEFORE using Adaptive Authentication in a productive environment:

  • Upload your Intermediate and Root Certificate and link your SSL certificate, so you make sure to get a valid certificate chain when using different Client-OS to access to.

  • Bind your SSL certificate to all six internal services so you don’t get a certificate warning when accessing the MGMT FQDN and you get rid of the default selfsigned ns-server-certificate.

  • Double check NTP Servers (also if you configured it during the wizard) and make sure, the NTP hosts are configured as a preferred NTP server and enable the synchronization state , otherwise ADC will never request the time.

  • During deployment, a additional local User, called authadmin, is created for onboarding and accessing with ADM. It is recommended to change the default password of the user. After password change on ADC, go to ADM > Infrastructure > Instances > Citrix ADC, click Edit and select the Admin Profile prefixed with hosted-gateway, select Change Password and enter the newly changed password. Go to Citrix ADC > Select Action > Rediscover.

  • You / the customer is responsible for backups (as there are no auto-backups configured by default), it’s recommended to create backup jobs in ADM for configuration, certificates, keys, portal customization,…

  • Citrix is creating a SSL Cipher group called SECURE which only contains two ECDHE GCM TLS 1.2 cipher and is automatically bound to the created AAA vServer. It’s your decision to add further TLS 1.2 cipher OR also to make use of TLS 1.3.

  • When you connect to your primary instance via ssh, you will notice the following warning, as the RPC passwords are not changed during instance deployment. Change RPC passwords on both appliances for enhanced security.
RPC enhanced security
  • Schedule and configure Firmware upgrades. Do not upgrade the instances on your own, all upgrades are managed by Citrix Cloud.
Schedule instance upgrades

Last but not least, configure your desired nFactor authentication flows and bind all policies to the existing AAA vServer. Citrix is providing some authentication samples. When enabling Adaptive Authentication for Workspace, the redirect process during Authentication to Cloud Workspace will start. That’s because the OAuth IdP profile and policy are already created during instance-deployment. Enabling adaptive auth will bind the policy to the AAA vServer. You don’t have to create the policy by manual, as described here when using OnPrem ADC.

Summary

So after checking out Citrix Adaptive Authentication, what’s the biggest differences between the on Azure hosted ADC HA-Pair, which is managed by Citrix and configured by yourself / the customer AND bringing your own OnPrem / Azure hosted ADC, connecting as IdP via Citrix Gateway / AAA?

To be honest, let’s make a quick assembly.

Citrix Adaptive Authentication

  • No hypervisor resources for two ADC instances are required
  • No public IP Address is required
  • No Firewall / DMZ changes are required, as routing is going through Azure / Citrix Cloud Connector
  • No Patchmanagement is required
  • Restricted advanced license

BYO ADC as IdP

  • Citrix ADC PushOTP is usable as a MFA solution. In Adaptive Authentication instance, the Push Service configuration is missing, because the instance is limited to advanced features and PushOTP is a premium feature.
  • License flexibility – you can choose the license bandwidth and edition – pooled, perpetual or service provider capacity.
  • Technical / feature flexibility – you can use your ADC as DaaS-IdP AND do a lot of additional stuff providing apps / services with eg content switching.

Personally, pricing should make the decision. If there are DaaS Premium / Premium Plus / SPA Advanced licenses already available, go for Adaptive Authentication. Otherwise, calculate BYO ADC investigation and go for your suitable possibility.

To be fair, the idea of hosting managed ADC’s which the customer don’t have to maintain is great, but there is enough potential upward. At the moment there is a highly expertise with ADC nFactor required. Additionally, who knows if the auth-flow is working without problems after an auto update last weekend? 🙂

The future goal should bring wizards, included in Adaptive Authentication Cloud Console, where you’re able to create your preferred nFactor flow with some easy templates and API scripts should create the necessary configuration on the ADC automatically in background. That would be a big advantage over BYO ADC. Let’s see which enhancements Citrix Cloud Development will release in the near future.

Hints

  • Both methods (Adaptive Auth and BYO ADC) are supported to use as IdP for Secure Private Access (SPA) when publishing Web, TCP and SaaS applications, also when using EPA check for device scans, as the ADC provides the smart access tags to Citrix Analytics (CAS).
  • Remember the need of FAS when doing SAML. Adaptive Authentication isn’t a new, magical architecture. Eg when connecting to Azure AD, make sure to setup and configure FAS for SSO to your VDA.

One comment

Leave a Reply

Your email address will not be published.