Introduction and Background

Citrix continues to invest resources into the Citrix Workspace + Gateway service platform in order to provide greater parity to customer-managed access tier architectures and security controls. The Device Posture service has been a key addition, which provides pre-authentication posture check capabilities that customers could only get via customer-managed NetScalers or the NetScaler-based Adaptive Authentication service that Citrix only makes available upon request and approval. Administrators of Endpoint Analysis (EPA) scans on NetScaler will be familiar with the workings of the Device Posture service, although it is not 100% feature parity.

I should also point out being the question has been asked more than once, that the Device Posture service or native EPA scans on NetScaler are not a replacement to the deviceTRUST platform Citrix acquired (and as of CVAD/DaaaS 2507 has largely integrated into Citrix client and server components into the installers), but rather compliments it Device Posture and EPA excels at scanning during pre-authentication or authentication to the platform while deviceTRUST excels at CONTINOUS scanning of the endpoint conditions.

When we combine Device Posture with Citrix SmartAccess / Access Control in Citrix DaaS, the fun begins and we can start crafting contextual access controls via Citrix policies. At the time of writing, Device Posture service + policies is not highlighted in the documentation, rather it focuses on Access Control filters to Delivery Groups (for the ability restrict enumeration of VDIs and apps in a given Delivery Group based on device compliance).

In this article, we will apply Citrix policies via SmartAccess filters to endpoints based on results of their Device Posture service scan. In our example we will apply watermarking policies to connections that match our BYOD policies while leaving managed devices without the effect of that policy.

In our scenario we have policies in Device Posture for managed, unmanaged, and a global default to deny access if no policy is matched, for optimal security. This does however, require that all endpoints that log in to Citrix Workspace be eligible to run an EPA scan due to the catch-all design. You do what works best for you, as we can filter policies and Delivery Groups on tag of COMPLIANT, NON-COMPLIANT, and in our example here, the exact Device Posture Check policy that matched.

While this is not an end-to-end guide on Device Posture service and SmartAccess filters, we hope there is sufficient information here to allow an administrator to extrapolate and develop policy configurations that match their needs.

Note: This guide is not a comprehensive walk-through on configuring Device Posture service. It is expected you already have this set up along with some policies.

Prerequisites

Citrix Workspace + Gateway service configured
Citrix DaaS environment configured and VDAs available
Citrix VDA (single or multi-session) 7.17 or higher (see limitations for watermarking)
Adaptive Access in Citrix Workspace enabled
Device Posture service configured and policies tested successfully
Supported client(s) for Device Posture service as per documentation

Lessons Learned

Policies with Access Control filters did not apply reliably when combining more than one condition. For example, a Device Posture service parameter and a Network Location parameter. In re-working the policy condition, we made the network condition redundant, simplifying it down to only the Device Posture service condition.
Linux did not display in the Device Posture console in Citrix Cloud initially. Evidently the documentation that references its availability was made available before it was rolled out to tenants by default. Working with engineering, we got this added on. While this is not relevant to the examples in this article, we wanted to share this info in case someone is keen on getting a Device Posture service configuration in place for IGEL or Linux.
In broader testing, some devices improperly had their watermark show their private IP and not their public IP. A case has been opened to investigate.

Step 1 – Identifying SmartAccess Filters

Context: Each user who matches a Device Posture service policy will have numerous tags passed through to the VDA for the session. In our case, we have two endpoints. Both are Macs, one is managed by the company, and one is unmanaged. This results in two distinct sets of tags we can review and filter on for our needs.

With each session connected (having successfully been scanned by Device Posture service and launched a session), we can hop into Citrix Monitor (Director) and examine the SmartAccess filters that have been tagged to the session from the Citrix Cloud access tier.

Focusing on the “Workspace” SmartAccess filters, we see a number of tags have come through.

Unmanaged (BYOD) Device

The matching Device Posture service policy that the device received was “UNMANAGED MACOS DEVICE CHECK”. The policy name will always come through capitalized, and it is important we match this when crafting the policy filter in DaaS later.

Managed Device

The matching Device Posture service policy that the device received was “MANAGED MACOS DEVICE CHECK”. The policy name will always come through capitalized, and it is important we match this when crafting the policy filter in DaaS later.

Step 2 – Crafting the Watermark Policy

We are creating a policy in our example that should only apply to users matching unmanaged Device Posture policies.

In addition to the text-based watermark labels that will render, we are applying the recommended policies to disable video codec and hardware encoding (it will default to ThinWire+ and not H.264 or H.265 video codecs) in order for the watermarking to reliably appear. This might in some use cases negatively impact session performance if dealing with a lot of dynamic media (watching videos or dealing with complex 3D graphics within the session), but this is not an issue for our example use case.

We are then configuring the Access Control filters for matching the policy to sessions. In our example, we have unmanaged Windows and Mac devices, so we will ensure both are added. From the SmartAccess filter analysis we performed above, the “Gateway farm name” will be “Workspace” and the access condition will be the name of the policy (all in caps). Alternatively, we could have designed our policy setup in Device Posture service to mark unmanaged devices as “NON-COMPLIANT” leaving managed devices as “COMPLIANT”, and crafting this policy to “Deny” vs. “Allow” and have one line that filtered on condition “COMPLIANT”. We did not test this, just an idea.

Step 3 – Testing Results

With the policy enabled and added in a higher order than baseline policies, we can get to testing by logging into Citrix Workspace service either via browser or Workspace app and launching a session.

Unmanaged (BYOD) Device

As per Citrix Monitor, we matched the BYOD/Unmanaged policy, and we see the watermark as expected.

User Experience:

Managed Device

As per Citrix Monitor, we did not match the BYOD/Unmanaged policy, and we do not see the watermark as expected.

User Experience:

Michael Shuster

Michael is Ferroque's founder and a noted Citrix authority, overseeing operations and service delivery while keeping a hand in the technical cookie jar. He is a passionate advocate for end-user infrastructure technology, with a rich history designing and engineering solutions on Citrix, NetScaler, VMware, and Microsoft tech stacks.