Yoffstr

Hi @Maxime Morin,

sorry the service is working fine, its more about telemetry that the service is working and can be start/stopped/restarted like we can with the PAM service in cloud.

Kind regards

Hi @Maxime Morin,

Broader availabilty. i like how devolutions have implemented the PAM service availability, so it would be nice to have it standardised with reporting service.

Kind regards

hi @Luc Fauvel,

A thought that came to mind, would it be best to have a dedicated PAM agent instead of having it bundled into the devolutions agent for cybersecurity reasons.

kind regards

hi @Luc Fauvel,

any update on this?

hi @Dominic Dansereau and @Luc Fauvel,

any update on this?

regards

Hi @Luc Fauvel,

Could you please also geet this working with devultions cloud, not just devolutions server.

kind regards

Hi @Luc Fauvel,

any uppdate on this?

Hi @Luc Fauvel,

any update on this?

Kind regards

Hi @Benoit Cortier,

Just seeing if there are any updates for this request?

Kind regards

Hi guys,

Just noticed in RDM when clicking on the Administer Gateways tab. when i click on the desired gateway and then click on the diagnostics tab, i get a cross on the agent installed information even though i have a agent installed on gateway.

We use devolutions cloud as well.

Hi @Luc Fauvel,

any update on this?

Kind regards

Hi @Benoit Cortier,

Just seeing if there are any updates for this request?

Kind regards

Hi @Luc Fauvel,

any update on this?

Kind regards

Hi @Luc Fauvel,

Correct, from a security perspective. If you have say 50 servers that you are doing the rotation on and all have remote powershell open to one or two servers with cloud services running. If the server with cloud services is compromiseed, then lateral movement between the other server will become quite easy.

Kind regards

hi guys,

instead of the current custom template for windows password rotation on local accounts. Instead of using powershell to do thee rotation, can we get it to work with the devolutions agent?

Hi guys,

Are we able to have a "test report" button implemented, so that when we test and see ehow the reports will come out and make adjustments accordingly, without having to wait for the report scheduleed time?

Hi @Luc Fauvel,

when you look into the implementation like PAM. are you also ablee to make it so that under applications we can see the reporting services conneecteed and can choose with one is activee/passive?

Kind regards

Hi @Luc Fauvel,

any update on this? as I also support this feature request.

kind regards

Hi @Luc Fauvel,

Please disregard my last post. I now understand that the encrpytion service is essentially for users to bypass the double 2FA prompt, if theey have thee devolutions account and SSO active at the same time.

Kind regards

Hi @Luc Fauvel,

like they say, nothing like a rewrite in order to progress....

Kind regards

sorry one thing i forgot to mention in the scope, is the traversal needs to be both ways.

For example: clients in internal network, connect to internal gateway, that connects to agent in DMZ, to connect to servers in DMZ. While also external clients, connect to the gateway in the dmz, gateway connects to agents in internal network, to connect to servers in internal network.

kind regards

Oops, I missed this message when I sent the previous one.

So I assumed that the Gateway in DMZ was accessible to clients in the internal network, but if that’s not the case, we could imagine exactly what you just said!

The caveat here compared to federations is that you, as an network administrator, will need to configure more components: "two Gateway farms in a single federation" vs "two Gateway farms and two Agent farms" + configure the selection policy (e.g.: can I reach DMZ Farm? Can I reach internal Farm?) for each relevant entries.

EDIT: Noting that you don’t need more machines since you can still have both a Gateway and an Agent per node. (Agent that you may already have installed for the updater module anyway.)

We’ll have to think about how to make this easy to configure.

Best regards,

Hi @Benoit Cortier,

As you said: "So I assumed that the Gateway in DMZ was accessible to clients in the internal network, but if that’s not the case, we could imagine exactly what you just said!"

No the client network cant access the DMZ gateways. Essentially following the zero trust model, we would want to poke as minimal holes in the internal network / dmz boundary to stop any risks or exposure, and hinder any lateral movment if something was to occur.

Hence why i suggested either a different port to be use from the standard/common ports for the communication between the two gateways or in this case gateway to agent tunnels.

kind regards

hi @Luc Fauvel,

I have difficulty following. If the PAM service can be done in high availability and the reporting service is being looked into being high availaibity capable. why cant the on premise encrpytion service be high available as well?

kind regards

As per the guidance of the devolutions team in thread: Cloud Services - Encryption and Reeporting Services - High Avilability

I am creating this thread, for the discussion around Cloud Services - reporting service - high availability feature request.

kind regards

As per the guidance of the devolutions team in thread: Cloud Services - Encryption and Reeporting Services - High Avilability

I am creating this thread, for the discussion around Cloud Services - Encryption service - high availability feature request.

kind regards

Hi @Yoffstr

I want to validate the actual requirements once more, because the proposed “super farm” is a specific implementation rather than necessarily the underlying need.

As I understand it, users should connect through the appropriate entry Gateway and then reach any authorized resource across the internal and DMZ networks, with automatic routing, minimal firewall exposure, high availability, auditing, and recording.

The architecture I proposed provides essentially the same outcome using existing building blocks: an internal Gateway for internal users, and a public Gateway using Agent Tunnel for internal destinations. Routing can still be based on subnet or hostname. The main difference is that the internal next hop is an Agent rather than another Gateway Farm, and the Agent connects outward to the already reachable public Gateway instead of requiring inter-farm network exposure.

Gateway federation is an interesting concept: effectively, a peer network of farms where selecting the federation provides access to anything it can route to. However, implementing it would require substantial work around trust, route exchange, loop prevention, authorization, auditing, recording, failover, and compatibility. It would solve valid scenarios, but many of them can already be addressed using simpler mechanisms. Unless we identify requirements that specifically require both Gateway Farms to participate in the session, it is unlikely to be implemented in the foreseeable future. Keeping the request open still makes sense, particularly if broader demand or additional use cases emerge.

The key question is: what capability would be lost if the internal next hop were an Agent instead of the internal Gateway Farm? Is Gateway federation itself a hard requirement, or would another architecture be acceptable if it satisfies the requirements?

If the simplified architecture works, a more realistic product improvement would be policy-based selection of the entry Gateway. Combined with Agent Tunnel destination routing, this could make the deployment transparent, avoid duplicated entries, and is something we could reasonably consider implementing sooner.

Thank you also for the internal-vs-external detection approach. LAN range plus a probe against an internal-only-resolvable FQDN. That's a sound way to disambiguate. A policy engine would need the client to evaluate network context and select the entry Gateway accordingly. That's a useful constraint to know early, and I think it fits well with policy-based selection too!

Looking forward to your reply.

Best regards,

Hi @Benoit Cortier,

Sorry i probably went abit overboard with my suggestions.

As per your post: "As I understand it, users should connect through the appropriate entry Gateway and then reach any authorized resource across the internal and DMZ networks, with automatic routing, minimal firewall exposure, high availability, auditing, and recording.

The architecture I proposed provides essentially the same outcome using existing building blocks: an internal Gateway for internal users, and a public Gateway using Agent Tunnel for internal destinations. Routing can still be based on subnet or hostname. The main difference is that the internal next hop is an Agent rather than another Gateway Farm, and the Agent connects outward to the already reachable public Gateway instead of requiring inter-farm network exposure."

Your are correct, this is the scope.

"The key question is: what capability would be lost if the internal next hop were an Agent instead of the internal Gateway Farm? Is Gateway federation itself a hard requirement, or would another architecture be acceptable if it satisfies the requirements?

If the simplified architecture works, a more realistic product improvement would be policy-based selection of the entry Gateway. Combined with Agent Tunnel destination routing, this could make the deployment transparent, avoid duplicated entries, and is something we could reasonably consider implementing sooner."

If you believe this simplified approach will work, happy to try it out.

The gateways by recommendation, is to have agents on them for auto updating, so i can guess they can be utilised for the tunnels. The only thing I am not sure is, for utilising the agent tunnels, could they be utilised in a active passive setup for high availiabilty?

"Thank you also for the internal-vs-external detection approach. LAN range plus a probe against an internal-only-resolvable FQDN. That's a sound way to disambiguate. A policy engine would need the client to evaluate network context and select the entry Gateway accordingly. That's a useful constraint to know early, and I think it fits well with policy-based selection too!"

All good, happy to help.

hi @Benoit Cortier,

sorry one thing i forgot to mention in the scope, is the traversal needs to be both ways.

For example: clients in internal network, connect to internal gateway, that connects to agent in DMZ, to connect to servers in DMZ. While also external clients, connect to the gateway in the dmz, gateway connects to agents in internal network, to connect to servers in internal network.

kind regards