Consuming the deviceTRUST context
deviceTRUST is designed to allow the context to be consumed by your existing management solution such as:
- Traditional logon script.
- Microsoft Group Policy (GPO) scripts.
- Microsoft Group Policy Preferences (GPP).
- User Environment Management (UEM) products (Ivanti User Workspace Management, RES ONE Workspace, VMware User Environment Manager, Citrix Workspace Environment Management (WEM) etc.).
For easy consumption of this deviceTRUST context, all properties are made available within the users’ session as registry values under HKCU and / or user specific environment variables.
Step 1: Ensure your management solution can access the deviceTRUST information
To consume the context provided by deviceTRUST within an existing management solution, deviceTRUST must be configured to persist the context information to the Windows Registry before the management solution processes the user logon. Within the deviceTRUST configuration under COMPUTER CONFIGURATION\ADMINISTRATIVE TEMPLATES\DEVICETRUST\SHELL ACCESS, the METHOD USED TO BLOCK LOGON WHILST PROPERTIES ARE READ FROM THE CONNECTED DEVICE defines this behavior and must be set to BLOCKING:
- The default behavior of deviceTRUST ensures that your management solutions can access the latest context information at Logon and Reconnect. There is no need to change this setting to support your management solutions.
Step 2: Configure persistence of context information within the users’ session
Within the deviceTRUST configuration under COMPUTER CONFIGURATION\ADMINISTRATIVE TEMPLATES\DEVICETRUST you can define the persistence of those context information for the users’ registry, environment variables and through the deviceTRUST Command Processor. Those settings are:
- Persist properties to the users’ registry.
- Persist properties to user environment variables.
- Allow deviceTRUST triggers to get properties of the user and Define who can get properties of the user.
The context information deviceTRUST delivers into the users’ session will be persisted as registry values or environment variables when these settings are set to DEFAULT or ENABLED.
- At least one of these settings must be enabled for existing management solutions to consume the context.
- You can disable both settings at the same time, but your existing management solution will not have access to the context within the users’ session. In this scenario, only actions triggered by the deviceTRUST triggers have access to the context information as environment variables.
- Choose between the persistence of registry values and environment variables based on the best practice of your management solution.
Step 3: Check if a deviceTRUST Client is installed on the remote device (EUC)
Depending on your configuration for ‘Untrusted Devices’, you should check first if client-based context information’s are available within the users’ virtual session. This can be achieved by checking the value of the HOST_DEVICETRUST_CONNECTED property:
|HOST_DEVICETRUST_CONNECTED||false||There is no deviceTRUST Client installed on the remote device and therefore only the HOST_* properties are available within the users’ virtual session.|
|true||There is a deviceTRUST Client installed on the remote device and therefore the HOST_* and DEVICE_* properties are available within the users’ virtual session.|
Step 4: Using deviceTRUST Triggers with your management solution
Depending on the management solution you are using, deviceTRUST triggers can bring additional value to your management solution. For example, traditional logon scripts (triggered by NETLOGON share or from within a Microsoft Group Policy) can consume the deviceTRUST context information. However, they are unable to react to a reconnection, or to a change to one of the existing properties.
With deviceTRUST triggers, you can now also execute scripts or executables when a user reconnects to an existing session, or when the value of the properties changes. In this scenario, you can leave your logon script within the NETLOGON share or Microsoft Group Policy but call it again if a user reconnects or a property change occurs. This will enhance your ability to act with your scripts on logon, reconnect and on a property change which you can’t do with your traditional logon script.
If a more advanced User Environment Management solution is used, the built-in triggers of that solution also enable you to act on a Reconnect event. deviceTRUST ensures that the context information delivered into the users’ virtual session can be consumed by those UEM solutions on Logon and Reconnect. In this scenario, the deviceTRUST Property Change trigger can be used to trigger the UEM solutions to act on mid-session property changes of the remote device and user.
- It is also possible to use any deviceTRUST trigger in conjunction with the management solution you are using. There is no technical limitation why you shouldn’t use the deviceTRUST triggers together with the triggers your management solution offers.
- deviceTRUST RECONNECT triggers are only applicable to End-User Computing (EUC) installations.
Step 5: Notify your management solution during session runtime
Some management solutions are able to track a start of a process and can apply their own policies at that time to the users’ session. To be able to notify any capable management solution about a context change during the runtime of the users’ session, deviceTRUST has introduced a new application called DTNOTIFY.EXE which will be installed as part of the deviceTRUST Host.
DTNOTIFY.EXE is installed within the deviceTRUST Host folder under %PROGRAMFILES%\DEVICETRUST\HOST\BIN and can be triggered through the deviceTRUST triggers to notify your management solution about a context change. An argument can be supplied on the command line to differentiate between context changes.
With the following command you could very easily notify e.g. Ivanti User Environment Manager about a security context change to trigger Ivanti User Environment Manager to re-apply their policy set during session runtime.
The following screen shows the Ivanti User Environment Manager management interface, which demonstrate how the PROCESS STARTED condition was defined to catch security context changes provided by deviceTRUST:
Out-of-the-box most of the available deviceTRUST properties are enabled and create a PROPERTY CHANGE event every time a DYNAMIC or DYNAMIC (REAL-TIME) property changes. Please consult the Property Matrix for detailed information about DYNAMIC or DYNAMIC (REAL-TIME) properties. It is recommended to consider the following steps to make your deviceTRUST configuration effective:
- Enable only properties you require within your environment. Please consult deviceTRUST Property Filters.
- Tweak property queries for display, network, printer and certificates, to target the information you need. Please consult deviceTRUST Property Queries.
- Depending on your requirements, potentially disable Property Change trigger for specific dynamic properties. Please consult deviceTRUST Property Filters.
- Depending on the company’s privacy requirements, potentially blacklist specific properties for Windows Event Log. Please consult deviceTRUST Property Filters.