Multi-Hop with deviceTRUST

deviceTRUST supports different Multi-Hop scenarios. Read how they work and how they can be implemented.

Imagine you have clients, be they from inside your organization or outside, which access a server or workstation inside your network. To reach this target, they must pass through one or multiple hops, for example in a multiple DMZ structure. You could now either want information from the initial client or even from any hop in between to be available in the target or another hop.

There are three different approaches regarding such scenarios. These are explained here.

All three approaches can be used as mixed scenarios, of course.

1. Managed Hops

The "Managed Hops" scenario brings information from a client machine to a target machine, passing over one or multiple hops. On the target, Context will be evaluated and actions will be executed.

In this scenario, all hops as well as the target require a licensed deviceTRUST Agent to be installed and configured.

 

The following configuration elements are required:

This is how the implementation looks from an architectural view.

Please feel free to use the configurations in our GitHub repository for reference and as a base for your implementation. The configurations are described in GitHub. 

2. Unmanaged Hops

The "Unmanaged Hops" scenario brings information from a client machine directly to a target machine, passing over one or multiple hops. On the target, Context will be evaluated and actions will be executed.

In this scenario, only the target requires a licensed deviceTRUST Agent to be installed and configured. The hops use a special function of the deviceTRUST Client Extension (available from Version 21.1.314) to forward the properties.

If the deviceTRUST Client Extension discovers an upstream connection (e.g. Client to Hop1) and does not recognize a deviceTRUST Agent, but a deviceTRUST Client Extension on Hop1, it will attempt to communicate further. This will happen on every hop until a deviceTRUST Agent is found. Then, a secure channel will be established between the deviceTRUST Agent and the deviceTRUST Client Extension on the user's device. The secure channel is then used to fetch properties from the user's device.

 

The following configuration elements are required:

This is how the implementation looks from an architectural view.

 

Please feel free to use the configurations in our GitHub repository for reference and as a base for your implementation. The configurations are described in GitHub. 

3. Managed Hops with Properties

This scenario collects additional properties from the intermediate hops. deviceTRUST can gather data from any hop in a multi-hop scenario and use the information on any subsequent hop and the target.

You might, for example, want to know that a user only hopped over machines that are joined to your domain and thus controlled and secured by your organization, when accessing the target session. Or you could make sure the user took a pre-defined path, hopping through your DMZ structure. These scenarios would require evaluating information not only on the user's device but also on the hops along the chain.

 

The following configuration elements are required:

This is how the implementation looks from an architectural view.

Please feel free to use the configurations in our GitHub repository for reference and as a base for your implementation. The configurations are described in GitHub.