deviceTRUST 19.2 is now available and includes the new macOS Client and an updated iOS Client. See the release notes for more information.

Getting Started

deviceTRUST requires some essential configuration steps to be performed to enable deviceTRUST functionality for your virtual sessions or for your endpoints.

Scenario: End-User Computing (EUC)

We will guide you step-by-step through all essential deviceTRUST installation and configuration steps to enable deviceTRUST with a Security State use case within your End-User Computing environment:

End-User Computing
End-User Computing

We will perform the following steps:

  1. Step 1: Download the deviceTRUST setup binaries from the deviceTRUST Portal
  2. Step 2: Install the deviceTRUST Host on a Microsoft Server 2016 RDSH / Citrix XenApp server
  3. Step 3: Install the deviceTRUST Console
  4. Step 4: Enable deviceTRUST by applying your personalized license
  5. Step 5: Install the deviceTRUST Client on a Microsoft Windows endpoint
  6. Step 6: Activate the deviceTRUST Client on an IGEL UD Pocket endpoint
  7. Step 7: Apply some deviceTRUST default configurations
  8. Step 7.1: Configure a blacklist of users that are not controlled by deviceTRUST
  9. Step 7.2: Configure a blacklist of users denied access from an untrusted device
  10. Step 8: Check that both HOST_* and DEVICE_* context properties are available from a trusted device
  11. Step 8.1: Check that access is denied from an untrusted device
  12. Step 9: Enable the Security State use case
  13. Step 10: Test the Security State use case from a Microsoft Windows endpoint
  14. Step 11: Update the Security State context to require a specific IGEL UMS server for IGEL endpoints
  15. Step 12: Test the Security State use case with an IGEL endpoint

Step 1: Download the deviceTRUST setup binaries from the deviceTRUST Portal

Within your evaluation kit, your license certificate or your Not-for-Resale (NFR) kit you will find your personalized link to register yourself with the deviceTRUST portal to get access to your license, documents, binaries etc. The relevant document provides a step-by-step guide for the portal registration process. Follow the steps in the section Downloading the Software to get the latest version.

Step 2: Install the deviceTRUST Host on a Microsoft Server 2016 RDSH / Citrix XenApp server

Start the installation of the deviceTRUST Host onto your Microsoft Server 2016 RDSH / Citrix XenApp server. Follow the steps in the section Installing the Host to complete the installation.

Step 3: Install the deviceTRUST Console

To configure the deviceTRUST Host using the Local Policy Editor, the deviceTRUST Console must be installed on the same machine as the deviceTRUST Host. Alternatively, configuration can be deployed using a Group Policy Object (GPO) by installing the deviceTRUST Console on the same machine as your Group Policy management tools. Follow the steps in the section Installing the Console to complete the installation.

The deviceTRUST Console includes a node within the Group Policy management tools at COMPUTER CONFIGURATION\POLICIES\DEVICETRUST CONSOLE (or COMPUTER CONFIGURATION\DEVICETRUST CONSOLE when using the Local Policy Editor) which can be used to model the context of a user, and then act on changes to that context by triggering custom actions within your environment.

The deviceTRUST Console
The deviceTRUST Console

Additionally, the deviceTRUST Console installs Administrative Templates onto the local machine. When editing a GPO, these can be found at COMPUTER CONFIGURATION\POLICIES\ADMINISTRATIVE TEMPLATES\DEVICETRUST (or COMPUTER CONFIGURATION\ADMINISTRATIVE TEMPLATES\DEVICETRUST when using the Local Policy Editor).

Note:
  • If your domain is not configured to load ADMX files from the local computer, you will need to copy the contents of `dtpolicydefinitions-x.x.x.x.zip` to the appropriate location.
The Administrative Templates installed by the deviceTRUST Console
The Administrative Templates installed by the deviceTRUST Console

Step 4: Enable deviceTRUST by applying your personalized license

Your personal product license can be found by signing into the deviceTRUST Portal and navigating to LICENSING.

To add the license into the deviceTRUST configuration on the Microsoft Server 2016 RDSH / Citrix XenApp server, navigate to the DEVICETRUST administrative template. Open the setting ENABLE DEVICETRUST, select ENABLE and copy your deviceTRUST license into the LICENSE field.

Enabling deviceTRUST
Enabling deviceTRUST

deviceTRUST is now enabled and will work for all users connecting to that Microsoft Server 2016 RDSH / Citrix XenApp server with deviceTRUST Host installed. To check if you have added a valid deviceTRUST license, open the Windows Event Log and navigate to APPLICATION AND SERVICE LOGS\DEVICETRUST\ADMIN and check for the existence of event ID 11 which states that your deviceTRUST license is valid.

Valid deviceTRUST license
Valid deviceTRUST license
Note:
  • When deploying configuration using a Group Policy Object, a call to `gpupdate` will be necessary to apply the new policy.
  • Existing user sessions will not get the updated policy until their next logon.

Step 5: Install the deviceTRUST Client on a Microsoft Windows endpoint

Install a deviceTRUST Client on a Microsoft Windows endpoint by following the steps in the section Installing the Client on Microsoft Windows endpoints to complete the installation.

Step 6: Activate the deviceTRUST Client on an IGEL UD Pocket endpoint

Activate the deviceTRUST Client within the IGEL OS by following the steps in the section Installing the Client to complete the configuration.

Step 7: Apply some deviceTRUST default configurations

For simplicity we will apply some basic deviceTRUST configurations to some user accounts and not groups.

Step 7.1: Configure a blacklist of users that are not controlled by deviceTRUST

To exclude for example the administrative accounts from deviceTRUST functionality, we need to blacklist those accounts from within the deviceTRUST configuration.

Within the Local Policy Editor or your chosen Group Policy management tool, navigate to the DEVICETRUST administrative template. ENABLE the BLACKLIST OF USERS NOT CONTROLLED BY DEVICETRUST.

Enable Blacklist Users policy
Enable Blacklist Users policy

User and security group names can be supplied in the format DOMAIN\USERNAME or DOMAIN\SECURITYGROUPNAME, where DOMAIN is either the SAM compatible domain, or the DNS domain name.

Blacklist Users
Blacklist Users

deviceTRUST will now control all users signing into the Microsoft Server 2016 RDSH / Citrix XenApp server, but will exclude the domain administrator DOMAIN\ADMINISTRATOR.

Note:
  • When deploying configuration using a Group Policy Object, a call to `gpupdate` will be necessary to apply the new policy.
  • Existing user sessions will not get the updated policy until their next logon.

Step 7.2: Configure a blacklist of users denied access from an untrusted device

Out of the box deviceTRUST allows any remote connection from any endpoint with or without a deviceTRUST Client installed. We will prevent access for a specific user if the endpoint they are using has no deviceTRUST Client installed or enabled.

deviceTRUST definition:

  • A TRUSTED DEVICE is an endpoint with an active deviceTRUST Client.
  • An UNTRUSTED DEVICE is an endpoint without an active deviceTRUST Client.

Within the Local Policy Editor or your chosen Group Policy management tool, navigate to the DEVICETRUST\SHELL ACCESS administrative template. ENABLE the BLACKLIST OF USERS DENIED ACCESS FROM AN UNTRUSTED DEVICE.

Enable Blacklist Device Policy
Enable Blacklist Device Policy

User and security group names can be supplied in the format DOMAIN\USERNAME or DOMAIN\SECURITYGROUPNAME, where DOMAIN is either the SAM compatible domain, or the DNS domain name.

Blacklist Device
Blacklist Device

deviceTRUST will allow access to all users signing into the Microsoft Server 2016 RDSH / Citrix XenApp server with trusted or untrusted device. The user DOMAIN\USER1 can now only access the virtual session from a trusted device.

Note:
  • When deploying configuration using a Group Policy Object, a call to `gpupdate` will be necessary to apply the new policy.
  • Existing user sessions will not get the updated policy until their next logon.

Step 8: Check that both HOST_* and DEVICE_* context properties are available from a trusted device

If you have successfully performed all steps before, you can now sign into the virtual session from either the Microsoft Windows endpoint or from the IGEL endpoint. Within the virtual session open REGEDIT and check under HKEY_CURRENT_USER\SOFTWARE\DEVICETRUST\PROPERTIES that HOST_* and DEVICE_* properties are visible.

Step 8.1: Check that access is denied from an untrusted device

From an untrusted device, use the same user account configured under STEP 7.2: CONFIGURE A BLACKLIST OF USERS DENIED ACCESS FROM AN UNTRUSTED DEVICE to access the Microsoft Server 2016 RDSH / Citrix XenApp server. Because the endpoint does not have an active deviceTRUST Client, the access will be denied with the following default message:

Untrusted Device
Untrusted Device
Note:
  • The default message including a language specific translation can be configured within the policy. Within the Local Policy Editor or your chosen Group Policy management tool, navigate to the `DEVICETRUST\SHELL ACCESS` administrative template. Customize the `USER MESSAGE DISPLAYED WHEN UNTRUSTED DEVICE IS DISALLOWED` and if required, the language dependent message `TRANSLATION OF USER MESSAGE DISPLAYED WHEN AN UNTRUSTED DEVICE IS DISALLOWED` to meet your requirements.

Step 9: Enable the Security State use case

We will use the deviceTRUST Console to create a configuration which controls access to the shell depending upon the security state of the endpoint. The deviceTRUST Console includes a set of templates which can be used to quickly implement a use case. Launch the deviceTRUST Console and click on the SHARING button either on the homepage, or in the top right of the navigation bar.

The Sharing button within the deviceTRUST Console
The Sharing button within the deviceTRUST Console

Scroll down and select the SECURITY STATE template by clicking on it, then choose IMPORT FROM TEMPLATE.

Importing the Security State template
Importing the Security State template

Both the SECURITY STATE context, and the SECURITY STATE CONDITIONAL ACCESS action will be highlighted. Click IMPORT FROM TEMPLATE to import and then select OK to dismiss the summary message.

Importing the Security State context and actions
Importing the Security State context and actions

Click on CONTEXT within the navigation bar, and then SECURITY STATE to view the imported context.

The Security State context
The Security State context

The context is set to the value of the left-most path where all conditions successfully evaluate. If no path is found, then the default value is used. For the SECURITY STATE context, a Windows device is PROTECTED if ANTISPYWARE, ANTIVIRUS and FIREWALL are all ACTIVE. If any of these security products are not active, then the SECURITY STATE is set to UNPROTECTED.

Click on ACTIONS within the navigation bar, and then SECURITY STATE CONDITIONAL ACCESS to view the imported action.

The Security State Conditional Access action
The Security State Conditional Access action

Actions execute a sequence of tasks when a trigger occurs, such as LOGON, RECONNECT, CONTEXT CHANGE etc, and optionally filtered by the value of a context. For the SECURITY STATE CONDITIONAL ACCESS action, whenever the SECURITY STATE context becomes UNPROTECTED, access to the shell will be denied. Similarly, whenever the SECURITY STATE context becomes PROTECTED, access to the shell will be allowed.

Click on the save icon which will be highlighted within the navigation bar.

Note:
  • When deploying configuration using a Group Policy Object, a call to `gpupdate` will be necessary to apply the new policy.
  • Existing user sessions will not get the updated policy until their next logon.

Step 10: Test the Security State use case from a Microsoft Windows endpoint

From a Microsoft Windows endpoint with the deviceTRUST Client installed, remotely connect to your Microsoft Server 2016 RDSH / Citrix XenApp server. Try toggling the enabled state of the Windows Firewall to see how deviceTRUST can simply and dynamically control access to the shell.

Testing the Security State use case
Testing the Security State use case

Step 11: Update the Security State context to require a specific IGEL UMS server for IGEL endpoints

Click on CONTEXT within the navigation bar, and then SECURITY STATE to view our context. Beneath the DEVICE - IGEL UMS SERVER AVAILABLE condition, click on the + button to add a new condition.

Adding a condition from the IGEL category of properties
Adding a condition from the IGEL category of properties

Click on IGEL.

Selecting the UMS Server from the IGEL category of properties
Selecting the UMS Server from the IGEL category of properties

Click on UMS SERVER.

Enter the UMS Server
Enter the UMS Server

Enter the name and port of your IGEL UMS Server.

Click OK, then click on the save icon which will be highlighted within the navigation bar

Note:
  • When deploying configuration using a Group Policy Object, a call to `gpupdate` will be necessary to apply the new policy.
  • Existing user sessions will not get the updated policy until their next logon.

Step 12: Test the Security State use case with an IGEL endpoint

Test drive this Security State use case with an IGEL endpoint. Only IGEL devices which use the specified UMS Server will be able to access the shell.