VPN, bastions, servers: how a European data center applies MFA for every client

A provider that hosts other companies’ infrastructure does not have one set of users to protect. It has dozens, each belonging to a different organization, and each expecting that its identities, its policies and its administrators stay strictly separate from everyone else’s. Adding multi-factor authentication in that context is not the same problem as rolling out MFA inside a single company. The platform has to behave like many independent authentication services at once, while running as one system that a small team can operate.

This is the situation a European data center came to us with. It protects sensitive information and runs critical operations on behalf of its clients, hosting their systems and, in many cases, their directories. It wanted to offer its clients strong authentication and single sign-on, run as a managed identity and access service rather than a bolted-on second factor, and it was moving away from an existing RSA deployment. The functional scope was broad from the start: several VPNs, Windows login both online and offline, and MFA across a wide set of client environments, including the bastions used to reach client systems. The user population ran to several thousand across all clients.

Two parts of this deployment are worth looking at closely, because they generalize well beyond this one provider. The first is how the licensing and tenancy model maps onto a provider’s own commercial offer. The second is how access control, not the second factor alone, fits a layered access architecture built around bastions. We deployed OpenOTP, the RCDevs authentication server, managed through WebADM, the central IAM console that runs and pilots all the services of the suite, from directory federation and single sign-on to access policies and delegated administration, with multi-factor authentication as one layer among them. Data centers and managed service providers fall squarely within the scope of NIS2, which is part of why the question of who can authenticate to what, and how it is recorded, carries weight here.

Why multi-tenancy is the hard part of IAM for a service provider

The difficulty is not the second factor itself. Push notifications, OTP or FIDO2 are well understood. The hard part is isolation at scale. A provider’s client base is rarely uniform: a handful of very small clients with a few users each sit alongside larger clients that run their own directory and expect their own administrators to manage their own people. A product that assumes one organization, one directory and one administrative boundary does not fit that shape. It forces the provider to either stand up a separate installation per client, which multiplies operational cost, or to flatten everyone into one space, which breaks isolation.

What this provider needed was a platform that could hold both arrangements at once: a shared space for the small clients and fully separate spaces for the larger ones, under one console and one operational team.

Licensing that mirrors the provider’s own client model

OpenOTP is offered in a Service Provider edition built for exactly this. Instead of licensing a fixed product to one organization, the provider works from a multi-tenant platform and a pooled user allowance that it allocates across its clients as it sees fit. A client that grows takes a larger share, a client that shrinks frees it up again, and the provider does not renegotiate a separate contract for each movement. The components are selected a la carte, so each client gets only what it uses, and the whole stack can be presented under the provider’s own brand.

Operationally this stays compact. WebADM runs the tenants from one console, the suite is designed to host hundreds of individual client tenants on an active/active cluster, and the same team manages all of them. The licensing model, in other words, follows the provider’s commercial model rather than the reverse: the provider sells authentication the way it already sells hosting, and the platform is sized against the whole population rather than against a rigid per-client count.

Hosting each client’s own directory side by side

The tenancy model rests on how directories are attached. For the smaller clients, the provider runs a single shared tenant backed by one mutualized Active Directory that holds all of them together. For the larger clients, each gets a dedicated tenant connected to its own Active Directory. In this deployment that meant a shared directory for the smaller clients alongside a series of dedicated, per-client directories on the same platform.

OpenOTP connects to each of these directories natively. Active Directory stays the source of truth for each client: at login, OpenOTP validates the user’s password against that client’s own directory, then applies the second factor, push notification, OTP or FIDO2, according to the policies defined for that tenant. WebADM presents each directory as its own isolated tenant, so the shared directory and the dedicated ones coexist without the provider having to run separate installations. The same approach extends beyond Active Directory: OpenOTP works with other LDAP directories and integrates with Entra ID, Okta, Google and further identity providers, so a provider whose clients are not all on Active Directory is not blocked.

Letting each client run its own user administration, without crossing tenant boundaries

A provider does not want to be the help desk for every one of its clients’ users. The Help Desk application lets the provider delegate day-to-day user administration to each client, so a client’s own administrators reset tokens, enroll users and handle first-line support within their own tenant.

This delegation is available for the dedicated tenants, and deliberately not for the shared one. A client sitting in the mutualized tenant shares that directory with other clients, so granting it administrative access would let it see users that do not belong to it. The isolation that makes the shared tenant economical for small clients is the same property that prevents safe delegation inside it. Larger clients on dedicated tenants have no such overlap, so they get their own delegated administration. The distinction is not a limitation bolted on afterwards. It follows directly from where each client’s identities live.

How MFA and access policies fit a layered bastion architecture

Many providers put MFA on the VPN and treat remote access as solved. In a hosting environment that is only the outer gate. The systems that matter, a client’s servers and the privileged accounts on them, sit several layers deeper, and each layer is a place where an attacker who already holds one credential tries to move further. The design exists to make one stolen credential insufficient on its own, and an identity check governed by the tenant’s access policy is placed at every layer so that credential theft does not turn into lateral movement. The access path has three control points, and that check belongs at all three.

A VPN guards the network edge, not the privilege boundary

The VPN connection opens access to a defined segment of the infrastructure rather than to everything at once. It proves that a known person reached a known segment. It says nothing about whether that person should be opening a privileged session on a server inside. MFA on the VPN is necessary and not sufficient: it protects the edge, while the privilege boundary is still ahead of it.

A bastion is the choke point for privileged access, so it authenticates in its own right

From the authorized segment, the client reaches a bastion, a jump host that sits one level deeper and from which, and only from which, the target systems are reached. The bastion topology follows the tenant model: each larger client has its own dedicated bastion, while the small clients that share a tenant also share a bastion and a common pool of resources. Either way, the bastion is the point every privileged session funnels through, which is why it is never exposed directly to the internet (a directly reachable bastion is probed and attacked continuously) and why the login to the bastion itself is checked again instead of trusting the VPN that preceded it. What is enforced here is not only a second factor but the tenant’s access policy: WebADM evaluates the bastion login against that client’s own rules through the same policy engine that governs the rest of the platform, so one client’s bastion access never inherits another client’s policy. The second factor is one input the policy weighs, alongside who the user is and what they are allowed to reach.

The server login is the last gate, and it has to hold when the path is degraded

At the end of the path are the Windows and Linux servers themselves. The Windows login carries MFA online and offline through the OpenOTP credential provider, which matters in a data center: a privileged server has to stay reachable for its administrators even when the link to the authentication server is briefly unavailable, and offline-capable login keeps the second factor in place rather than dropping it at the worst moment. A credential stolen at one layer does not carry an attacker through the next, because each login that OpenOTP protects asks again.

OpenOTP plugs into each of these points over the protocols they already speak rather than asking the provider to re-plumb its network, which is what lets the same policy engine reach the VPN, the bastion and the server without running three separate projects.

The diagram shows the generic reference model, in which each client’s services are published to the internet. This deployment is more restrictive: nothing is exposed online except the endpoints needed for push notifications, which reach the RCDevs cloud push service. The proxy tier shown as an HAProxy and WAProxy cluster is played by F5 equipment that also handles front-line firewalling, and the SQL and LDAP storage shown as separate clusters runs directly on the two WebADM nodes rather than on dedicated storage tiers. Each client reaches its own tenant through its own dedicated VPN and its own URL, never across a shared public surface.

Scaling the same model across several data centers

Nothing in this design is tied to a single site. A provider that operates several data centers places a WebADM node in each one: either a full cluster per data center, or one node of a global cluster per site. The platform spans them without changing how tenants, directories or policies are defined. Adding a data center means adding a node, not rebuilding the authentication service. A provider can grow from one site to several, or take on a new region, and the same multi-tenant model carries over unchanged.

For a provider in this position, the useful point is that the authentication service does not have to be assembled from one installation per client, and it does not have to trade away isolation to stay manageable. A multi-tenant platform can hold a shared tenant for small clients and dedicated tenants for large ones, attach each client’s own directory, delegate administration where isolation allows it, enforce MFA across VPNs, bastions and server logins, and extend across as many data centers as the provider runs.

Further reading

• OpenOTP for Service Providers (MSSP edition): https://www.rcdevs.com/mssp-partners/
• License features and editions: https://www.rcdevs.com/license-features/
• OpenOTP compared with cloud IAM and MFA solutions: https://www.rcdevs.com/compare_cloud_iam_and_mfa_solutions/
• WebADM, the core IAM console: https://www.rcdevs.com/products/webadm/
• MFA on VPN and SSL VPN: https://www.rcdevs.com/solutions/vpn/