Supported topology for concurrent Azure + on-prem DVLS nodes sharing one database (PAM/AD access)

Hi kseay1,

Thank you for reaching to our forum, short version: two nodes on one database is supported, but I do not think it is what you want. Devolutions Server can reach your domain controllers through a Devolutions Gateway installed on-premises, so the Azure node you already have can do the AD work and you need no second node.

1. Yes, supported - both a high-availability load-balancing topology and a manual failover one:

https://docs.devolutions.net/server/overview/topologies/#high-availability-load-balancing-topology
https://docs.devolutions.net/server/knowledge-base/how-to-articles/deploy-in-a-high-availability-or-load-balancing-environment/

That second article is written for Windows and IIS; the mechanics apply to containers, but we have no container-specific one yet.

My reason is what runs where. PAM work a user triggers a password reset from the interface, say runs in the web application on whichever node served the request. Everything on a timer belongs to the Scheduler: heartbeat, scheduled rotation, and the whole checkout lifecycle - activation, expiry, and the check-in that removes the temporary group from Active Directory. Only one scheduler is active per deployment, the others standing by:

https://docs.devolutions.net/server/knowledge-base/knowledge-base-articles/scheduler-service-general-information/#scheduler-service-in-a-high-availability-environment

Which one wins is decided automatically, with no way to prefer a node or a location. That is the problem with the second node: users on it could request a checkout and reset a password there, but activation, expiry and the check-in still run wherever the active scheduler is so if that is the Azure node with no route to your domain, the temporary group is never deleted and the elevation never lapses.

You could force the scheduler on-prem by leaving the Azure node without one, at the cost of the standby though I have not confirmed that behaves as a per-node control on the App Service image, so do not build on it yet. The Gateway avoids the question entirely: every node then has a route to AD, whichever holds the scheduler.

The better route is a Devolutions Gateway. Install it on-premises next to your DCs, tick Use Devolutions Gateway in the domain configuration, and the server tunnels LDAP or LDAPS to the domain controller through it instead of reaching the DC directly. Selecting a preferred domain controller becomes mandatory once the option is on. The PAM side is written up step by step, and the same option sits in the authentication domain's advanced settings:

https://docs.devolutions.net/pam/knowledge-base/how-to-articles/configure-pam-domain-account-provider-through-devolutions-gateway/
https://docs.devolutions.net/server/web-interface/administration/configuration/server-settings/general/authentication/domain/#advanced-settings

Configure one thing separately: Kerberos only travels the tunnel if the Gateway entry also carries a KDC server URL and a Kerberos realm its own section, not part of the box you tick
(https://docs.devolutions.net/gateway/knowledge-base/how-to-articles/use-the-devolutions-gateway-kdc-proxy/).Without it the LDAP tunnel works but Kerberos has no route.

This is what the standard, separate-host Gateway install exists for - our guidance calls it the choice for networks "that Devolutions Server cannot access"
https://docs.devolutions.net/gateway/getting-started/devolutions-server/devolutions-gateway-configuration-with-devolutions-server/.
Its click-through starts from the Devolutions Server Console, which a container does not have; the MSI or silent PowerShell install on the same page is your route. Note the direction too: your Azure node reaches the Gateway outbound, not your domain controllers, so one published HTTPS endpoint replaces the whole network-integration exercise.
It covers interactive AD logins too, on the default configuration: the domain's user validity strategy decides how a login is checked, and the shipped default your dropdown shows it as Default (Ldap) uses the same LDAP path the Gateway carries. ValidateCredentials and CreateUserPrincipal talk to the domain directly and would bypass it, so tell me if you have picked either. Each node binds to AD itself and never delegates, and on a login it does so with that user's own credentials.

If you would rather not run a Gateway, the alternative is giving the Azure node its own reach to the DCs but that is not an extension of your SQL VPN. An App Service for Linux Containers reaches on-premises only through regional virtual network integration, which carries its own prerequisites around region, routing and DNS; Microsoft's App Service virtual-network-integration overview lists them. Worth pricing against a Gateway.

2. Identical, and you supply it yourself there is no key distribution mechanism. Container nodes need the same DVLS_ENCRYPTION_CONFIG_B64 value you saved at first-time setup
(https://docs.devolutions.net/server/knowledge-base/how-to-articles/devolutions-server-docker-deployment/devolutions-server-deployment-to-azure-app-service-using-a-container/#initialize-devolutions-server-and-retrieve-encryption-configuration).
If a node is a Windows/IIS install instead, do not copy encryption.config between machines on Windows it is DPAPI-protected to that machine; export the keys from the console on one node and import them on the other. Be careful here: the configuration holds several separate keys - data, passwords, tokens, attachments, login - so a partial mismatch does not fail loudly. The vault looks healthy while domain authentication or PAM secrets fail; we have chased that symptom before.

3. Yes, that is the intended mechanism, and with two nodes you must apply it on both. The OpenID client registration the redirect and post-logout URLs the server accepts is built from AccessUri plus AdditionalAccessUris and written to the shared database every time a node starts, so the node that started most recently sets that list for the whole database. If each lists only its own hostname, logins through the other break after a restart. Give both the same complete list.

4. Three things to plan for.

Affinity is recommended and is entirely the load balancer's job; in your design each population has its own front end, so it is satisfied by construction. Enable X-Forwarded-For if you use IP allowlisting or conditional access, or every request looks like Front Door.
Caching is the one that will bite you. Each node caches settings and domain configuration for about five minutes, so change a domain service account password on one node and the other keeps the old value until its cache expires - and during that window AD sync, user lookups and domain authentication fail on it. Restarting that node clears it. This is a known open issue on our side, not a misconfiguration at yours.
Concurrent writes from scheduled work are not a concern, for the single-active-scheduler reason above; expect a few minutes during a failover where none runs. On interactive concurrent writes I have no constraint to report and no test of my own - the load-balancing topology is documented for that shape, and I would rather say I have not verified it than imply I have.

5. No extra licence is needed. Licences live in the shared database and are assigned per user, so nodes draw on one entitlement and nothing counts instances.

Happy to go further on any of these. One thing worth checking whichever way you go: what your System dashboard (https://docs.devolutions.net/server/web-interface/system/system-dashboard/) shows for schedulers. If nothing is listed as Up, checkouts are not activating or expiring and check-ins are not completing today, Gateway or no Gateway.

Best regards,
Michel