PoC Guide - Citrix Zero Trust Architecture Configuration Guide

Overview

As enterprises migrate towards a mature zero-trust architecture, it is crucial to understand the core concepts and how to configure an environment to satisfy the tenets of a zero-trust architecture. This article delves into a comprehensive zero-trust scenario and how to configure Citrix adaptive authentication, adaptive access, and Citrix DaaS policies to build the following architecture.

Use Case

The following diagram shows the architecture for the adaptive authentication, adaptive access, and DaaS policy configurations.

In this scenario, there are two user groups: employee and contractor. The employees and contractors access the same workspace URL in this example.

Employees

Walking through the nFactor flow from left to right, employee users select “Employee” from the organization drop-down list, which directs them to one of three outcomes:

1. Green - access to the employees-only app and a VDI with relaxed security controls.
2. Orange - access to the employees only app with strict security controls without access to a VDI.
3. Red - access denied.

All employees are subject to a device certificate endpoint analysis (EPA) scan and authentication via Azure Active Directory (Azure AD) SAML.

1. If an employee fails the device certificate EPA scan, they are prompted for a second EPA scan to check for Antivirus Software (AV) on the device.
2. If the employee’s device contains the specified device certificate or has antivirus software running, they are prompted to authenticate with their Azure AD credentials.
3. If the employee fails to have either the device certificate or antivirus running, they are denied access.

Contractors

When contractor users select “Contractor” from the organization drop-down list, two outcomes can occur:

1. Purple - access to a contractors-only app and a VDI with strict security controls applied to both.
2. Red - access denied.

All contractors are subject to a device certificate endpoint analysis (EPA) scan and authentication via the on-premises Active Directory (AD). If a contractor fails the device certificate EPA scan, they are denied access.

Prerequisites

The following prerequisites were completed before the Adaptive Authentication configurations:

• Access to a Citrix Cloud tenant with Citrix DaaS and Secure Private Access Advanced enabled and Cloud Connector installed in your resource location.
• Provision Adaptive Authentication by following Step 1 in the Provision Adaptive Authentication guide.
• Published Desktop in Citrix DaaS with a Machine Catalog and Delivery Group.
• The Access Policy is edited later for adaptive access (see Step 1: Provision Adaptive Authentication).
• Published external (Outside my corporate network) Employees Only and Contractors Only apps from Secure Private Access.
  • The Access Policies are edited later for adaptive access.
  • Follow the Adaptive Access to SaaS and Private Web Apps POC guide.
• Microsoft Azure AD Sync with existing Azure tenant and Active Directory.
• Configure Device Certificate auto-enrollment via GPO on a domain controller.
  • Follow the Configure Group Policy to Autoenroll and Deploy Certificates guide.
• Download and install the EPA plug-in from the Workspace URL in Citrix Cloud > Workspace Configuration.

Configurations

The following sections detail the configuration of the previous scenario. The configuration guide is broken down into the following sections:

• Adaptive Authentication configuration
• Adaptive access configuration
• DaaS policy configuration

Adaptive Authentication Configuration

The following configurations are done on the Adaptive Authentication instance. To access Adaptive Authentication:

1. Log in to Citrix Cloud and select the appropriate Customer.

   

   

2. From the main admin console home page, select the menu in the top left and navigate to My Services > Secure Private Access.

   

3. Hover over the menu icons on the far, select Identity and Access Management, and click Manage.

   

4. Copy the Primary IP, paste and go into the web browser, and authenticate.

   

LDAP

For use case scenario two, LDAP policies are needed. First, create the standard LDAP policy for the contractor flow and then a NO_AUTH LDAP policy that will come after the Azure SAML policy for the employee flow.

1. Start on the main adaptive auth configuration page, type LDAP into the top left search bar, and select Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Actions > LDAP.

   

2. For the standard LDAP, click Add, give it a Name, and enter the details for your LDAP server as shown, then click OK.

   

   

3. For the NO_AUTH LDAP, click Add, give it a Name, enter the details for your LDAP server as shown, and click OK.

   

4. The finished LDAP actions look similar to the following.

   

SAML

For the use case scenario, a single SAML auth policy needs to be created for the employee flow. In this configuration guide, Azure AD is used as the SAML IdP. In this section, the Azure Enterprise App is configured first followed by configuring the SAML auth action in adaptive auth.

Azure Enterprise App

1. In the Azure portal, select Azure Active Directory, Enterprise Applications, then New Application.

   

2. In the search bar, enter Citrix, select the Citrix ADC SAML Connector for Azure AD, give it a name, and click Create.

   

3. Once created, select Single Sign On from the left menu and click Edit for the Basic SAML Configuration.

   

4. Enter the following details for the Basic SAML Configuration:

   • Entity ID: FQDN of my adaptive auth instance
   • Reply URL: FQDN of my adaptive auth instance appended with “/cgi/samlauth”
   • Sign-on URL: FQDN of my adaptive auth instance appended with “/cgi/samlauth”

   

5. Lastly, download the Certificate (Base64) from pane 3 and copy the Login URL from pane 4.

   

Adaptive Auth SAML configuration

1. Start on the main adaptive auth configuration page, type SAML into the top left search bar, select Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Actions > SAML.

   

2. Click Add and fill in the details for the SAML action as shown and click OK:

   • Name
   • Redirect URL (login URL that was copied from the Azure AD enterprise app configuration)
   • Single Logout URL (login URL that was copied from the Azure AD enterprise app configuration)
   • IdP Certificate Name (Base64 certificate from the Azure-AD enterprise app)
   • Signing Certificate Name (adaptive auth certificate that was uploaded to the service during the provisioning process)
   • Issuer Name (FQDN of the adaptive auth instance, specified during the provisioning process)
   • Reject Unsigned Assertion (Off)

   

   

The finished SAML action looks similar to the one following.

EPA

For the use case scenario, there are three EPA policies to complete:

1. Employee device certificate check.
2. Employee antivirus check.
3. Contractor device certificate check.

Employee Device Certificate

1. Start on the main adaptive auth configuration page, type EPA into the top left search bar, and select Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Actions > EPA.

   

2. Click Add, give the EPA action a name, and enter the details:

   • Default Group: Place the name of the AAA group users into if they pass the check (make sure to use all CAPS)

   Note:

   This group is used later to match with the Smart Access tag.

   • Expression: click EPA Editor to the top right of the “Expression” text box, select the appropriate drop-down lists as shown, and click Done.

   

3. The finished action looks similar to the following:

   

Employee Antivirus

1. From the main EPA action page, click Add, give the EPA action a name, and enter the details:

   • Default Group: Place the name of the AAA group users into if they pass the check (make sure to use all CAPS).

     Note:

     This group is used later to match with the Smart Access tag.

   • Expression: click EPA Editor to the top right of the “Expression” text box, select the appropriate drop-down lists as shown, and click Done.

   

2. The finished action looks similar to the following.

   

Contractor Device Certificate

1. From the main EPA action page, click Add, give the EPA action a name, and enter the details:

   • Default Group: Place the name of the AAA group users into if they pass the check (make sure to use all CAPS).

     Note:

     This group is used later to match with the Smart Access tag.

   • Expression: click EPA Editor to the top right of the “Expression” text box, select the appropriate drop-down lists as shown, and click Done.

   

2. The finished action looks similar to the following.

   

The finished EPA actions looks similar to the following:

Smart Access

For the use case scenario there are three Smart Access policies to complete:

1. Employee with device certificate
2. Employee without device certificate but a device with proper antivirus software installed
3. Contractor device certificate.

Employee Device Certificate

1. Start on the main adaptive auth configuration page, type smart into the top left search bar and select Security > AAA - Application Traffic > Policies > Authentication > Advanced Policies > Smart Access.

   

2. Click Add, give it a Name and enter the details as follows.

   • Action: select Add, enter a tag name

     Note:

     This is the tag that is passed to Citrix Cloud Workspace to be later used with adaptive access policies for SPA and policies for DaaS.

   • Click OK

   

   • Expression: To check to see if the user is a part of the AAA group that passed the Employee Device Certificate EPA check enter the following expression AAA.USER.IS_MEMBER_OF(“<AAA_group_specified_in_employee_device_certificate_epa_action>”.

3. The finished Smart Access policy looks similar to the following:

   

Employee antivirus

1. From the main Smart Access policy page, click Add. Give it a Name and enter the details as follows.

   • Action: select Add, enter a tag name.

   Note:

   This is the tag that is passed to Citrix Cloud Workspace to be later used with adaptive access policies for SPA and policies for DaaS.

   • Click OK.

   

   • Expression: To check to see if the user is a part of the AAA group that passed the Employee Device Certificate EPA check enter the following expression "AAA.USER.IS_MEMBER_OF(“<AAA_group_specified_in_employee_anti-virus_epa_action>”)

2. The finished Smart Access policy looks similar to the following:

   

Contractor Device Certificate

1. From the main Smart Access policy page, click Add, give it a “Name,” enter the following details, and click OK.

   • Action: select Add, enter a tag name.

   Note:

   This name is the tag that is passed to Citrix Cloud Workspace to be later used with adaptive access policies for SPA and policies for DaaS.

   • Click OK.

     

   • Expression: To see if the user is a part of the AAA group that passed the Employee Device Certificate EPA check, enter the following expression “AAA.USER.IS_MEMBER_OF(“<AAA_group_specified_in_contractor_device_certificate_epa_action>”)

2. The finished Smart Access policy looks similar to the following:

   

The finished Smart Access policies look similar to the following:

nFactor Flow

For the use case, one nFactor flow is required.

1. Start on the main adaptive auth configuration page, type nfactor into the top left search bar, select Security > AAA - Application Traffic > nFactor Visualizer > Flows, and click Add on the next page.

   

2. Click The + to add the first factor.

   

3. In the new Add Factor Pane select Create Factor and give it a name.

   Note:

   This is the name of the entire flow.

4. Click Create.

   

5. Click Add Schema.

   

6. Click Add to add a new schema on the next pane.

   

7. Give the schema a Name and click the “pencil” icon to edit the schema.

   

8. Select the Login Schema folder, scroll down, select DomainDropdown.xml, and click Edit.

   

9. Give the schema a name and fill out the fields as shown:

   

10. By default, this schema provides three options in the drop-down list. To modify the schema to eliminate the third drop-down list option, hover over the newly created schema and click the download icon that appears. Open the downloaded XML file in a text editor.

    

11. In the downloaded XML file, delete the highlighted text shown to remove the third drop-down list option.

    

12. Close out of the schema edit pane, click edit on the newly created schema, upload the new schema XML file, click OK, and then OK once more. You can now edit the updated schema by clicking the pencil icon if needed.

    

    

13. Now, create the authentication policy associated with the domain drop-down list schema. In this case, a NO_AUTH policy is needed. Click Add Policy.

    

14. Click Add, give the policy a Name, select “NO_AUTHN” from the Action Type drop-down list, and enter “true” into the expression text box. Click Create. Click Add.

    

    

    

15. The next factor is the decision block for “Employee” or “Contractor.” Click the green “+” to add the next factor. Select the “Create Decision Block” radio button, give it a Name, and click Create.

    

    

16. Click “Add Policy,” click Add to create an authentication policy, and give it a Name. This policy determines if the user has selected the “Employee” option from the drop-down list. The expression used to check for this is:

    HTTP.REQ.BODY(500).AFTER_STR("domain=").CONTAINS("Employee")

17. Click OK.

    

    

    

18. Click Add.

    

19. Repeat this process for the Contractor selection. Click the blue “+” below the Employee check policy, click Add to create an authentication policy, and give it a Name. This policy is for determining if the user has selected the “Contractor” option from the drop-down list. The expression used to check for this is:

    HTTP.REQ.BODY(500).AFTER_STR("domain=").CONTAINS("Contractor")

    

    

    

20. Click Add.

    

21. The next steps focus on the configurations for the “Employee” use case. The next factor is going to be the device certificate check EPA scan. Click the green “+” on the employee check policy to add the next factor.

    

22. Give the factor a Name and click Create.

    

23. Select Add Policy for the “Employee Device Certificate Factor” and click Add to create an authentication policy, give it a Name, and set the Action Type to “EPA.” Attach the employee device certificate, check the EPA action created earlier, set the Expression to “true,” and click Create.

    

    

    

24. Click Add.

    

25. Continuing with the “Employee” use case (the configurations for the “Contractor” use case are covered later). Next is the configuration for the factor after the employee passes the previous device certificate EPA check. Click the green “+” on the employee device certificate check policy to add the next factor.

    

26. Give the factor a Name and click Create.

    

27. Select Add Policy for the “Employee Azure AD SAML Factor” and click Add to create an authentication policy, give it a Name, and set the Action Type to “SAML.” Attach the employee Azure AD SAML action created earlier, set the Expression to “true,” and click Create.

    

    

    

28. Click Add.

    

29. After the SAML policy, the next step is to attach the NO_AUTHN policy to retrieve the necessary attributes for proper authentication to Workspace. Click the green “+” on the employee Azure AD SAML policy to add the next factor.

    

30. Give the factor a Name and click Create.

    

31. Select Add Policy for the “Employee No-Auth LDAP Factor” and click Add to create an authentication policy, give it a Name, and set the Action Type to “LDAP.” Attach the employee NO_AUTH LDAP action created earlier. Set the Expression to “true” and click Create.

    

    

    

32. Click Add.

    

33. To configure the second employee use case where the employee fails the device certificate check, click the red “+” on the “Employee Device Certificate Check” factor.

    

34. Give the factor a Name and click Create.

    

35. Select Add Policy for the “Employee AV Check Factor” and click Add to create an authentication policy, give it a Name, and set the Action Type to “EPA.” Attach the Employee AV Check action created earlier, set the Expression to “true” and click Create.

    

    

    

36. Click Add.

    

37. If the employee passes the antivirus check, they get passed through to the Azure AD SAML + NO_AUTHN LDAP. To configure this, click the green “+” for the “Employee AV Check” factor.

    

38. In the Next Factor to Connect pane, click the radio button for “Connect to existing factor", select the “Employee Azure AD Factor”, and click Create.

    

39. This completes the Green, Orange, and Red Employee use case configurations. The configuration up to this point looks similar to the following:

    

40. Moving on to configurations for the “Contractor” use case, the first factor to configure is a device certificate EPA check. To start, click the green “+” on the contractor check policy to add the next factor.

    

41. Give the factor a Name and click Create.

    

42. Select Add Policy for the “Contractor Device Certificate Factor” and click Add to create an authentication policy, give it a Name, and set the Action Type to “EPA.” Attach the contractor device certificate action created earlier. Set the Expression to “true” and click Create.

    

    

    

43. Click Add.

    

44. If the contractor passes the device certificate check, they are permitted to log in. Next, configure the LDAP authentication for the contractor by clicking the green “+” for the “Contractor Device Certificate Check Factor”.

    

45. Give the factor a Name and click Create.

    

46. Select Add Policy for the “Contractor LDAP Factor” and click Add to create an authentication policy. Give the policy a Name and set the Action Type to “LDAP”. Attach the contractor LDAP action created earlier, set the Expression to “true” and click Create.

    

    

    

47. Click Add.

    

48. A login schema is required for this LDAP factor to show the user name and password fields to the end user. To configure this, click Add Schema for the “Contractor LDAP Factor”.

    

49. On the choose Login Schema pane, click Add.

    

50. Give the schema a Name and click the pencil icon.

    

51. Click the “Login Schema” folder and scroll down to and select “SingleAuth.xml”. Then click the Select button.

    

    

52. Click Create.

    

53. Click OK.

    

This completes the configurations for the nFactor flow. The final result looks similar to the following image:

AAA Virtual Server

To apply these configurations to the authentication flow, apply the following configurations on the AAA virtual server:

1.  upload and bind the CA certificate
2.  bind the nFactor flow
3.  bind the Smart Access policies.

There's a subsection for each.

1. First, navigate to the AAA virtual server. Start on the main adaptive auth configuration page, type “AAA” into the top left search bar, and select Security > AAA - Application Traffic > Virtual Servers.

   

2. Click the "auth_vs" virtual server to edit.

   

CA Certificate

1. On the main edit page of the AAA virtual server, select the pencil icon in the top right.

   

2. Click More.

   

3. Scroll down to the “CA for Device Certificate” setting pane and click Add.

   

4. Select the CA certificate that was added earlier, click the “+,” and then OK.

   

   

5. Click No Device Certificate.

   

6. Click the “>” and select the same CA certificate, click Select, and then Bind.

   

   

   

7. The AAA virtual server looks similar to the following image:

   

nFactor Flow

The next step is to bind the nFactor flow created earlier to the AAA virtual server.

1. On the main edit page for the auth_vs AAA virtual server, click Continue until you see “No nFactor Flow”. Click “No nFactor Flow”.

   

2. Click the “>” to select the nFactor flow created earlier, click Select, and then Bind.

   

3. Select the nFactor flow created earlier and click Select.

   

4. Click Bind.

   

5. The AAA vServer looks similar to the following:

   

Smart Access Policies

The final necessary configuration on the AAA virtual server is binding the three smart access policies created earlier.

1. On the main edit page for the auth_vs AAA virtual server, click Continue until you see “No Smart Access Policy”. Click “No Smart Access Policy”.

   

2. Click Add.

   

3. Select the first “smart access policy” by clicking the radio button and then click Select.

   

4. Click Bind.

   

5. Repeat steps 2 through 4 for the other two smart access policies. The finished smart access policy bind looks similar to the following. Click Close.

   

The AAA virtual server configurations are now complete. On the main AAA virtual server configuration page, click Continue or scroll to the bottom and click Done.

Adaptive Access Policies

The following configurations are done in the Secure Private Access service in the Citrix Cloud administration console. For the scenario, there are three adaptive access policies that need to be created:

1. Green - access to employee app with relaxed security controls
2. Orange - access to employee app with strict security controls
3. Purple - access to contractor app with strict security controls.

There's a subsection for each.

The following configurations are done on the Adaptive Authentication instance. To access Adaptive Authentication:

1. Log in to citrix.cloud.com and select the appropriate “customer”.

   

   

2. From the main admin console home page select the menu in the top left and navigate to My Services > Secure Private Access.

   

3. Hover over the left-hand navigation icons to show the labels, then select Access Policies.

   

Green - Access to employee app with relaxed security controls

1. The first policy to create is for the employee app with relaxed security controls. To get started, from the main policy configuration page, click Create Policy.

   

2. Fill out the policy creator with the following details, and then click + Add condition:

   • Applications: <employee app name>
   • User/user groups: <employee user(s)>

Note:

AD security groups can be used instead of individual user names.

1. Continue to fill out the policy creator with the following details:

   • Select condition: Device posture check > “matches all of”
   • Enter custom tags: CERT
   • Then do the following - select action: Allow access
   • Policy name: enter a name
   • Enable check box “Enable policy on save”

2. The policy looks similar to the following, then click Save.

   

Orange - Access to employee app with strict security controls

1. The second policy to create is for the employee app with strict security controls. To start, click Create Policy from the main policy configuration page.

   

2. Fill out the policy creator with the following details, and then click + Add condition:

   • Applications: <employee app name>
   • User/user groups: <employee user(s)>

   

3. Continue to fill out the policy creator with the following details:

   • Select condition: Device posture check > “matches all of”
   • Enter custom tags: NOCERT
   • Then do the following - select action: Allow access with restrictions
   • Restrictions: select the restrictions to be enabled
   • Policy name: enter a name
   • Enable check box “Enable policy on save”

4. The policy looks similar to the following, then click Save.

   

   

Purple - access to contractor app with strict security controls

1. The third policy to create is for the contractor app with strict security controls. To start, click Create Policy from the main policy configuration page.

   

2. Fill out the policy creator with the following details, and then click + Add condition:

   • Applications: <employee app name>
   • User/user groups: <employee user(s)>

   

3. Continue to fill out the policy creator with the following details:

   • Select condition: Device posture check > “matches all of”
   • Enter custom tags: CONTRACTOR
   • Then do the following - select action: Allow access with restrictions
   • Restrictions: select the restrictions to be enabled
   • Policy name: enter a name
   • Enable check box “Enable policy on save”

4. The policy looks similar to the following, then click Save.

   

   

The adaptive access policies configurations are now complete. The main configuration page for adaptive access looks similar to the following image:

DaaS Policies

The following configurations are done in the DaaS service in the Citrix Cloud administration console. For the scenario, two DaaS policies need to be created:

1. Allow VDI for “green” employees and “purple” contractors
2. Purple contractor VDI with strict security controls.

There's a subsection for each.

The following configurations are done on the Citrix DaaS service. To access the Citrix DaaS service:

1. Log in to citrix.cloud.com and select the appropriate “customer”

   

   

2. From the main admin console home page select the menu in the top left and navigate to My Services > DaaS.

   

Allow VDI for green employees and purple contractors

1. To configure VDI access for “green” employees and “purple” contractors' use cases the access policy must be edited for the delivery group. Select “Delivery Group” from the left menu. Highlight the delivery group for the VDI and click Edit.

   

   

2. On the delivery group edit pane click “Access Policy” from the left menu. Select all three check boxes and Click Add.

   

3. The first filter to add is to allow access for the employee. In the “Add Filter” pane, add the following details:

   • Site or farm name: workspace
   • Filter: <employee device certificate smart access tag>

Note:

For this example, “CERT” is used. This matches the smart access tag configured previously in the Adaptive Authentication console.

1. Click OK.

   

2. The second filter to add is to allow access for the contractor. Back on the main “access policy” page click Add.

   

3. In the “Add Filter” pane, add the following details:

   • Site or farm name: workspace
   • Filter: <contractor device certificate smart access tag>

Note

For this example, “CONTRACTOR” is used. This matches the configured smart access tag in the Adaptive Authentication console.

1. Click OK.

   

2. Click Save.

   

Contractor VDI with strict security controls

1. To configure contractor VDI with strict security controls, the DaaS studio policies must be edited. To start the configurations, from the DaaS manage home page click “Policies” from the left menu.

   

2. Click Create Policy.

   

3. The strict security policy to enforce is setting a session watermark for the Contractor VDI. The right search bar type in “watermark.” Click Select for “Enable session watermark”.

   

4. Enable the setting and click Save.

   

5. Click Next.

   

6. In the “Assign Policy To” box, click Assign for the “Access control” setting.

   

7. In the “Access control elements” box, enter the “contractor device certificate smart access tag” in the Access condition field. Click Save.

   

8. Click Next.

   

9. Make sure that the policy is enabled on the summary page, give it a name, and click Finish.

   

Summary

This guide walked you through the configurations for the adaptive authentication and adaptive access scenario described in the Use Case section. Use the Workspace URL found in the Workspace Configuration section of citrix.cloud.com to test and validate the configuration.