Citrix DaaS – Adaptive Authentication

Reading Time: 8 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:

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.

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.

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.

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:

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.

Citrix is doing Firmware Updates to your HA-Pair, so make sure that you don’t use the “STAY PRIMARY” HA-mechanism, otherwise the Auto-Updates will fail.

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.

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.

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.

• Schedule and configure Firmware upgrades. Do not upgrade the instances on your own, all upgrades are managed by Citrix Cloud.

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.

OnPrem AD or RADIUS connectivity

With Adaptive Authentication you are able to use OnPrem authentication capabilities like LDAP (Active Directory) or RADIUS. Let’s take a deeper insight on how the connection flow is working.

During the deployment process of Adaptive Authentication, you chose Windows based Cloud Connector, that’s the way on how ADC on Azure is able to establish connections to OnPrem LDAP / RADIUS. That’s called a mapping between OnPrem backend server subnets and is preconfigured with an Advanced Expression. If your LDAP / RADIUS server IP address is a public IP address, you have to extend the existing expression with your subnet.

For LDAP, create Servers based on IP-Address and configure LDAPS LoadBalancing (recommended). If you would like to use FQDN instead of IP, DNS tunneling is not supported, so static A-Records must be added on the ADC appliance.

When doing LDAP connection test, you can validate the traffic in ns.log with the following simple commands, as the log is prefixed with [NS_AAUTH_TUNNEL]

shell
cd /var/log
cat ns.log | grep -I "tunnel"

A successful connection looks something like this:

The Cloud Connector will forward the request (SRC 192.168.0.7 is the NSIP of my primary ADC instance) to one of your Domain Controllers (in my case 10.56.130.10:636) and route back via Internet to the Adaptive Authentication FQDN (AAA vServer). Make sure that all Cloud Connectors can resolve and access the public FQDN with https.

For RADIUS, create Servers based on IP-Address and configure RADIUS LoadBalancing (recommended if there is more than one RADIUS host). If you would like to use FQDN instead of IP, DNS tunneling is not supported, so static A-Records must be added on the ADC appliance. Add all Cloud Connector IP addresses as RADIUS clients in your RADIUS provider / server, that’s necessary because these IP addresses are the source for all RADIUS requests. I’ve tested this in my Lab with an OnPrem Windows NPS Server:

Be aware that RADIUS authentication is impacted for a few minutes if the Connector serving the RADIUS request goes down. User must reauthenticate in this case.

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.