PoC Guide: Adaptive Authentication with Citrix DaaS

Overview

Citrix Cloud customers can use Citrix Workspace to provide Adaptive Authentication to Citrix DaaS. Adaptive Authentication is a Citrix Cloud service that enables advanced authentication for customers and users logging in to Citrix Workspace. This POC Guide aims to show how Adaptive Authentication can provide access to Citrix DaaS to a client or third party without creating and managing local AD accounts and allowing multiple IdPs.

Conceptual Architecture

Here is an overview of the deployment created for this POC Guide.

• Main Provider with Citrix Cloud components (including PKI and FAS) and two domains to mimic customers.

• Shadow accounts created in lab.local with email matching customer email for first-factor validation (group extraction).

• Citrix DaaS is configured for the lab.local Active Directory domain with the following details:

  • Domain Controllers:
    • LAB-AD-01
    • LAB-AD-02
  • Cloud Connectors:
    • LAB-CC-01
    • LAB-CC-02
  • Microsoft Certificate Server:
    • LAB-PKI-01
  • Citrix FAS Servers:
    • LAB-FAS-01
    • LAB-FAS-02
  • Citrix Virtual Delivery Agents (VDA):
    • DAAS-MCS-S-02.lab.local
    • DAAS-MCS-S-03.lab.local
    • DAAS-MCS-S-04.lab.local -Published resources:
    • Windows 10 MCS Desktop for lab\user1, lab\shadow001, and lab\shadow002.

Configure Adaptive Authentication service

The following high-level steps are involved in configuring the Adaptive Authentication service.

1. Provision Adaptive Authentication
2. Configure Adaptive Authentication policies
3. Enable Adaptive Authentication for Workspace

Prerequisites

• Reserve an FQDN for your Adaptive Authentication instance. For example, aauth.arnaud.biz, assuming arnaud.biz is your company domain. This FQDN is the Adaptive Authentication service FQDN in this document and is used when provisioning the instance. Map the FQDN with the IdP virtual server public IP address. This IP address is obtained after provisioning in the Upload Certificate step.
• Procure a certificate for aauth.arnaud.biz. Certificates must contain the SAN attribute, or the certificates are not accepted.
• Choose your connectivity type for the on-premises AD/RADIUS connectivity. The following two options are available. Use the connector connectivity type if you do not want data center reachability.
• Citrix Cloud Connector - For details, see Citrix Cloud Connector.
• Azure VNet peering - For details, see Set up connectivity to on-premises authentication servers using Azure VNet peering.
• Configure the network time protocol (NTP) server to avoid time skews. For details, see How to synchronize system clock with servers on the network.

Points to note

1. Citrix recommends not to run clear config for any Adaptive Authentication instance or modify any configuration with the prefix AA (for example, AAuthAutoConfig), including certificates. This disrupts Adaptive Authentication management, and user access is impacted. The only way to recover is through reprovisioning.
2. Do not add SNIP or any additional routes on the Adaptive Authentication instance.
3. The nFactor configuration required for the Citrix Workspace or the Citrix Secure Private Access service is the only configuration customers must create directly on the instances. Currently, no checks or warnings in the Citrix ADC prevent admins from making these changes.
4. Do not upgrade the Adaptive Authentication instances to random RTM builds. Citrix Cloud manages all upgrades.
5. Only a Windows-based cloud connector is supported. The connector appliance is not supported in this release.
6. If you are an existing Citrix Cloud customer and have already configured Azure AD (or other authentication methods) to switch to Adaptive Authentication (for example, device posture check), you must configure Adaptive Authentication as your authentication method and configure the authentication policies in the Adaptive Authentication instance. For details, see Connect Citrix Cloud to Azure AD.
7. For RADIUS server deployment, add all connector private IP addresses as the RADIUS clients in the RADIUS server.
8. In the current release, the external ADM agent is not allowed, so Citrix Analytics (CAS) is not supported.
9. Citrix Application Delivery Management service collects the backup for your Adaptive Authentication instance. To extract the backup from ADM, onboard the ADM service. For details, see Config backup and restore. Citrix does not take the backups explicitly from the Adaptive Authentication service. Customers must take the backup of their configurations from the Application Delivery Management service if necessary.

How to configure the Adaptive Authentication service

The following steps assume you use Citrix DaaS with Citrix Cloud Connectors and Active Directory on-premises.

Access the Adaptive Authentication user interface

You can access the Adaptive Authentication user interface by one of the following methods.

1. Manually type the URL https://adaptive-authentication.cloud.com.
2. Log in using your credentials and select a customer.
3. After you successfully authenticate, you are redirected to the Adaptive Authentication user interface.

OR

1. Navigate to Citrix Cloud > Identity and Access Management.
2. In the Authentication tab, click the ellipsis menu in Adaptive Authenticationand select Manage. The Adaptive Authentication user interface appears.

Step 1: Provision Adaptive Authentication

Perform the following steps:

1. On the Adaptive Authentication UI, click Provision.

   

2. Click Next.

   

3. Select the preferred connection for Adaptive Authentication.

   • Citrix Cloud Connector: You must set up a connector in your on-premises network for this connection type. Citrix recommends deploying at least two Citrix Cloud Connectors in your environment to set up the connection to the Citrix Gateway hosted on Azure. You must allow your Citrix Cloud Connector to access the domain/URL reserved for the Adaptive Authentication instance. For example, allow https://aauth.xyz.com/*.

   For details on Citrix Cloud Connector, see Citrix Cloud Connector.

   • Azure VNet peering: You must set up the connectivity between the servers using Azure's VNet peering.
   • Ensure that you have an Azure subscription account to set up the connectivity.
   • The customer VNet being peered must already have an Azure VPN gateway provisioned. For details, see Azure VPN Gateway.

     

   To add a Citrix Cloud Connector as your preferred connection: Perform the following steps.

   • Select the Citrix Cloud Connector option, and select the end user agreement checkbox.

   • Click Provision.

     

Note:

Provisioning might take up to 30 minutes to complete.

1. Set up credentials to access the instances you have enabled for Adaptive Authentication. You need management console access to create policies for authentication, conditional access, and so on
   • Enter the user name and password in the Console access screen, and click Next.

     

2. Add the Adaptive Authentication service FQDN and upload the certificate-key pair. You must enter the Adaptive Authentication service FQDN of your choice for the publicly accessible authentication server. This FQDN must be publicly resolvable.

   • in the Upload Certificate screen, enter the FQDN reserved for Adaptive Authentication.
   • Select the certificate type.
   • Upload the certificate and the key.

   

Note:

A DNS entry needs to be created for the configuration to apply.

![Adaptive Authentication](/en-us/tech-zone/learn/media/poc-guides_adaptive-authentication-citrix-daas_aa7.png)

1. Upload the certificate and the key. The Adaptive Authentication instance is connected to the Identity and Access Management service. The Adaptive Authentication method status is displayed as Connected.

2. Set up IP addresses to access the Adaptive Authentication management console.

   • In the Allowed IP addresses screen, enter a public IP address as the management IP address for each instance. To restrict access to the management IP address, you can add multiple IP addresses allowed to access the management console.
   • To add multiple IP addresses, click Add, enter the IP address, and click Done. This step must be done for every IP address. If you do not click the Done button, the IP addresses are not added to the database but are only added to the user interface.

     

   • If you use the connector connectivity type, specify a set of resource locations (connectors) to reach the AD or RADIUS servers. You can skip this step if you use the VNet peering connectivity type.
   • Admins can choose the connectors through which back-end AD and RADIUS servers must be reached. To enable this feature, you can set up a mapping between their back-end AD/RADIUS server subnets such that if the authentication traffic falls under a specific subnet, then that traffic is directed to the specific resource location. However, If a resource location is not mapped to a subnet, then admins can specify to use the wildcard resource location for those subnets.
   • Previously, Adaptive Authentication traffic for on-premises AD/RADIUS was directed to any available resource location using the round-robin method. This setup caused issues for customers with multiple resource locations.

3. On the Adaptive Authentication UI, click Manage Connectivity, enter the subnet details, select the respective resource location, click Add, and click Save Changes.

   

Step 2: Configure Adaptive Authentication policies

After the provisioning, you can access the Adaptive Authentication management IP address directly. You access the Adaptive Authentication management console using the FQDN or your primary IP address.

• Access the Adaptive Authentication management console:
  • To access the Adaptive Authentication management console using the FQDN, see Configure SSL for ADC Admin UI access.

To access the Adaptive Authentication using your primary address, do the following:

1. Copy the primary IP address from the Configure Authentication policies section in the GUI and access the IP address in your browser.

2. Log in using the credentials that you have entered while provisioning.

   

3. Click Continue.

   

4. Navigate to Configuration> Security > AAA - Application Traffic > Virtual Servers.

   

5. Add the authentication policies. For various use cases, see Sample authentication configurations. The configuration part of this article is provided below in the next section.

Step 3: Enable Adaptive Authentication for Workspace

After provisioning is complete, you can enable authentication for Workspace by clicking Enable in the Enable Adaptive Authentication for Workspace section.

1. Click Enable to enable Adaptive Authentication for Workspace.

   

2. Check the Box and click Confirm.

   

Configure input-based group extraction

Consider an organization with the following three departments (groups), Employee, Partner, and Vendor. The Citrix ADC appliance can extract the user's group based on the user's email ID or the AD user name in the first-factor login form. Based on the group a user belongs to, Citrix ADC presents an authentication method (LDAP, SAML, OAuth, and so on), as shown in the following table as an example.

The following diagram shows a high-level interaction between a user and the Citrix ADC appliance for the previously mentioned use case.

1. The user logs in to Citrix Workspace and gets redirected to a virtual authentication server.

2. Citrix ADC presents a login form to enter their email ID (or user name).

   

3. The user enters the Email ID (or user name).

4. Citrix ADC presents a login form based on the group extracted using the provided email ID (or user name).

Configure email ID (or user name) input using CLI

Prerequisite

• A load-balancing virtual server configured with authentication enabled.

• LDAP Load Balancing virtual server with IP address: 10.0.0.1 created:

  add server LAB-AD-01 192.168.2.1

  add server LAB-AD-02 192.168.2.2

  add serviceGroup LDAP_SG TCP -maxClient 0 -maxReq 0 -cip DISABLED -usip NO -useproxyport YES -cltTimeout 9000 -svrTimeout 9000 -CKA NO -TCPB NO -CMP NO

  add lb vserver LDAP_VS TCP 10.0.0.1 389 -persistenceType NONE -cltTimeout 9000

  bind lb vserver LDAP_VS LDAP_SG

  bind serviceGroup LDAP_SG LAB-AD-02 389

  bind serviceGroup LDAP_SG LAB-AD-01 389

Configure authentication virtual server for email-based group extraction

Note:

You can modify **OnlyUsername.xml schema to create a customized login schema (emailOnlyLSchema).

Create login schema policy using email login schema created in the previous step and bind to the virtual authentication server

add authentication loginSchema emailOnlyLSchema -authenticationSchema "/nsconfig/loginschema/LoginSchema/EmailOnlyLSchema.xml"

add authentication loginSchemaPolicy lschema_only_email_pol -rule true -action emailOnlyLSchema

bind authentication vserver auth_vs -policy lschema_only_email_pol -priority 100 -gotoPriorityExpression END

Create an LDAP authentication policy for group extraction

Note:

ldapLoginName is "mail" for email ID-based login, whereas -ldapLoginName is "samAccountName" for username-based login.

add authentication ldapAction aaa_local_grp_extraction -serverIP 10.0.0.1 -ldapBase "dc=lab,dc=local" -ldapBindDn svc_ldap@lab.local -ldapBindDnPassword ****** -ldapLoginName mail -groupAttrName memberOf -subAttributeName CN -secType TLS -authentication DISABLED

add authentication Policy aaa_local_grp_extraction_pol -rule true -action aaa_local_grp_extraction

Extracted group-based policy configuration

Create the next factor for Employee, Partner, and Vendor Groups using policy labels

add authentication loginSchema lschema_noschema -authenticationSchema noschema

add authentication policylabel plabel_noauth_Employee_Partner_Vendor -loginSchema lschema_noschema

add authentication Policy noauth_Employee_pol -rule "AAA.USER.IS_MEMBER_OF(\"Employee\")" -action NO_AUTHN

add authentication Policy noauth_Partner_pol -rule AAA.USER.IS_MEMBER_OF(\"Partner\")" -action NO_AUTHN

add authentication Policy noauth_Vendor_pol -rule "AAA.USER.IS_MEMBER_OF(\"Vendor\")" -action NO_AUTHN

Create a single Auth policy factor (LDAP is used as an example for this configuration)

add authentication loginSchema lschema_singleauth_Employee -authenticationSchema "/nsconfig/loginschema/LoginSchema/ PrefilUserFromExpr.xml"

add authentication policylabel plabel_singleauth_Employee -loginSchema lschema_singleauth_Employee

add authentication ldapAction aaa_local_pwd_act -serverIP 192.168.2.1 -ldapBase "dc=lab,dc=local" -ldapBindDn svc_ldap@lab.local -ldapBindDnPassword ****** -ldapLoginName samAccountName -groupAttrName memberOf -subAttributeName CN -secType TLS -ssoNameAttribute userPrincipalName -passwdChange ENABLED -nestedGroupExtraction ON -maxNestingLevel 7 -groupNameIdentifier sAMAccountName -groupSearchAttribute memberOf -groupSearchSubAttribute CN -defaultAuthenticationGroup ldapDefaultAuthGroup -Attribute1 userPrincipalName -Attribute2 mail

add authentication Policy aaa_local_pwd_pol -rule true -action aaa_local_pwd_act

bind authentication policylabel plabel_singleauth_Employee -policyName aaa_local_pwd_pol -priority 100 -gotoPriorityExpression NEXT

Create SAML Policy for redirecting to Okta SAML IdP

add authentication policylabel plabel_saml_Partner -loginSchema lschema_noschema

add authentication samlAction "SAML OKTA" -samlIdPCertName Okta -samlSigningCertName MTRCConsulti-certkey -samlRedirectUrl "https://dev-52531691.okta.com/app/citrixnetscalergateway_saml/exk9a4qvlqFEP4bHI5d7/sso/saml" -samlUserField userprincipalname -samlIssuerName https://aauth.arnaud.biz

add authentication Policy SAML-OKTA -rule true -action "SAML OKTA"

bind authentication policylabel plabel_saml_Partner -policyName SAML-OKTA -priority 100 -gotoPriorityExpression NEXT

Create SAML Policy for redirecting to Azure SAML IdP

add authentication policylabel plabel_saml_Vendor -loginSchema lschema_noschema

add authentication samlAction saml_sp_act -samlIdPCertName "Citrix ADC SAML" -samlRedirectUrl "https://login.microsoftonline.com/a5edf84a-78ce-4ceb-92d0-2c835a217494/saml2" -samlUserField userprincipalname -samlIssuerName " https://aauth.arnaud.biz"

add authentication Policy saml_sp_pol -rule true -action saml_sp_act

bind authentication policylabel plabel_saml_Vendor -policyName saml_sp_pol -priority 100 -gotoPriorityExpression NEXT

Bind all three policy factors to plabel_noauth_Employee_Partner_Vendor

bind authentication policylabel plabel_noauth_Employee_Partner_Vendor -policyName noauth_Employee_pol -priority 100 -gotoPriorityExpression NEXT -nextFactor plabel_singleauth_Employee

bind authentication policylabel plabel_noauth_Employee_Partner_Vendor -policyName noauth_Partner_pol -priority 110 -gotoPriorityExpression NEXT -nextFactor plabel_saml_Partner

bind authentication policylabel plabel_noauth_Employee_Partner_Vendor -policyName noauth_Vendor_pol -priority 120 -gotoPriorityExpression NEXT -nextFactor plabel_saml_Vendor

Bind group-based policy label as nextFactor for group extraction authentication policy

bind authentication vserver auth_vs -policy aaa_local_grp_extraction_pol -priority 100 -nextFactor plabel_noauth_Employee_Partner_Vendor -gotoPriorityExpression NEXT

Configure email ID (or user name) input using the nFactor Visualizer

1. Navigate to Security > AAA-Application Traffic > nFactor Visualizer > nFactor Flow and click Add.

2. Click + to add the nFactor flow.

3. Add a factor for group extraction with LDAP group extraction policy using EmailOnlyLoginSchema. The name that you enter is the name of the nFactor flow. Click Create.

   

4. Click Add Schema on the nFactor block. To create a customized login schema (emailOnlyLSchema), you can edit the built-in OnlyUsername.xml schema.

   

5. Click Add Policy.

6. Select Policy aaa_local_grp_extraction_pol and click Add.

   

7. Click the green + sign on the emailbasedGroupExtraction block to create decision blocks for the subsequent factors.

   

8. On the Next Factor to Connect screen, select Create decision block, enter a name for the decision block, and click Create.

   

9. Click Add Policy

   

10. Select Policy and click Add.

    

11. The following diagram shows the nFactor flow after creating all the decision blocks.

    

12. Once all the decision blocks are created, bind all the group-based decision blocks to the respective authentication factors. For example, an Employee group can have a username and password authentication factor.

    

13. Choose login schema from the Authentication Login Schema drop-down menu and click Add.

    

14. Choose the authentication policy and click Add.

    

15. Once all group-based decision blocks are configured with authentication policies as factors, the nFactor flow looks like the following diagram.

    

16. Click Bind to Authentication Server and click Create.

    

17. Select the virtual authentication server and click nFactor Flow.

    

18. Choose the nFactor flow under the Select nfactor Flow field and click Add.

    

19. Bind this flow to the authentication, authorization, and auditing virtual server.

    

Note:

Azure AD does not expect the Subject ID field in the SAML request. For Citrix ADC to not send the Subject ID field, type the following command on the Citrix ADC CLI. nsapimgr_wr.sh -ys call="ns_saml_dont_send_subject" This command only applies to nFactor authentication workflows.

Summary

This guide walked you through using Adaptive Authentication to provide access to Citrix DaaS to a client or third party without creating and managing local AD accounts and allowing multiple IdPs.