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: Configure persistence of context information within the users’ session
Within the deviceTRUST Console’s settings, you can define the persistence of contextual information for the Windows Event Log, Windows Registry, environment variables and through the deviceTRUST Command Processor.
All of these settings are enabled by default, however we recommend disabling persistence that you do not require.
Step 2: 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 3: Using deviceTRUST actions with your management solution
Depending on the management solution you are using, deviceTRUST actions 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 actions, 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 context 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 Context 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 a deviceTRUST action in conjunction with the management solution you are using. There is no technical limitation why you shouldn’t use the deviceTRUST actions together with the triggers your management solution offers.
- deviceTRUST RECONNECT triggers are only applicable to End-User Computing (EUC) installations.
Step 4: 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 actions 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: