Many organisations run their whole identity layer from a single site. Active Directory sits on-premise, a federation layer in front of it authenticates dozens of downstream applications, and remote access rides on the same chain. It works, until the site does not. A power, network or hardware failure in that one location does not only take Active Directory offline. It takes down every service that depends on it for sign-in.

The usual answer is to push authentication out to a cloud identity provider, most often Microsoft Entra ID, so that users can still log in when the on-premise site is unreachable. That does solve availability. It also moves the user directory and the authentication decision out of the organisation’s own perimeter and into infrastructure governed by another jurisdiction. Before accepting that as the only path, it is worth examining how on-premise identity can be made resilient without depending on a hyperscaler.

This is the question a large European public-sector operator is currently working through with us, and it is a common one for any essential entity that cannot afford a single point of failure on identity.

Why a single-site Active Directory puts every connected service at risk

The operator runs Active Directory on a single site. In front of it, an on-premise federation layer (Active Directory Federation Services, in this case) authenticates a large number of services, including remote access. Identities are created and managed centrally, which is sound. The weakness is geographic: everything that authenticates against that directory lives or dies with one location.

This is the part that is easy to underestimate. The concern is not a corrupted database or a failed service that a local cluster could absorb. It is the loss of the site itself. When the building, its network or its power goes, both halves of a same-site high-availability pair go with it. An active-active cluster of two nodes protects against a server failure. It does nothing for the failure of the site that hosts both nodes.

So the real exposure is not Active Directory in isolation. It is the chain behind it. A single outage at one location can leave users unable to authenticate to remote access, to internal SSO and to every federated application at once. For an organisation whose services have to keep running, that concentration is the problem to solve.

Does moving authentication to Entra ID actually solve resilience, and what does it cost?

Moving authentication to Entra ID is a reasonable instinct. If sign-in happens in the cloud, it no longer depends on the on-premise site being reachable. In the model the operator was considering, users would still be created in Active Directory and synchronised to Entra ID, with authentication handled in the cloud. Availability improves, because the cloud identity provider is not affected by the loss of a local site.

What this also does is change where identity lives and who controls it. The user directory is replicated into a service operated by a US-headquartered provider, and the authentication decision moves there too. The data residency options offered by the major providers can keep the storage in Europe, but, as we discuss further below, residency and jurisdiction are not the same thing.

There is a second cost that is easy to miss. Once authentication depends on a cloud identity provider, the organisation has traded one dependency for another. The single on-premise site is no longer the single point of failure, but the cloud tenant and the connectivity to it now are. For an essential service, that is a trade worth making consciously rather than by default.

Adding geographic redundancy to on-premise identity without a hyperscaler

There is another way to remove the single point of failure, and it does not require moving authentication off-premise. The on-premise identity layer can be extended with a second node in a separate location, including a sovereign or European cloud, so that the loss of the primary site does not take authentication down with it.

This is how WebADM, our LDAP administration and IAM console, is designed to run. It supports an active-active cluster whose nodes can sit in different sites or data centres, with the directory, the SQL store and the session state replicated between them. One node on-premise and one node in a sovereign cloud give the organisation geographic redundancy of the same kind a hyperscaler offers, while keeping the infrastructure under its own control. There is a practical constraint worth naming early: a cluster spread across locations needs controlled latency between nodes, which has to be checked when the second site is a cloud region.

The federation layer can be made redundant in the same way. Where the operator’s downstream services currently depend on an on-premise ADFS service, OpenOTP, our authentication server, can act as the identity provider through its Federation Services (SAML, OIDC and OAuth), and can add multi-factor authentication to remote access over the RADIUS Bridge, the component that brings MFA to VPNs and network equipment. Because these run on the same clustered nodes, the federation and VPN entry points stop being a single point of failure too. The aim is not to replace the directory but to make the whole authentication chain survive the loss of any one site.

How authentication survives a site or Active Directory outage

For the alternative to be credible, one question has to be answered precisely: if the on-premise site or Active Directory becomes unreachable, how does authentication keep working?

For this architecture to be resilient, the important point is how OpenOTP and WebADM are deployed with Active Directory.

In the proposed design, Active Directory remains the authoritative identity source. WebADM and OpenOTP can be configured to read users and groups from Active Directory without modifying the AD schema or changing AD objects, provided the LDAP service account is granted read-only permissions and no AD write-back features are enabled. The operational directory used by the RCDevs platform can be hosted in the suite’s own OpenLDAP directory and replicated across WebADM nodes.

During normal operation, user credentials are validated against Active Directory. Once a user has successfully authenticated, OpenOTP can maintain local offline validation data according to policy, allowing authentication to continue during a temporary loss of connectivity to Active Directory or to the primary site. This mechanism should not be described as copying the Active Directory password into OpenLDAP; the exact storage and validation method depends on the configured OpenOTP policy.

When Active Directory becomes reachable again, online validation against AD resumes. Combined with WebADM and OpenOTP nodes deployed across two separate locations, this design allows the authentication chain to survive the loss of one site while keeping the authoritative directory under the organisation’s control.

Keeping identity data under European jurisdiction: NIS2 and the CLOUD Act

For a public-sector operator, two regulatory considerations sit underneath this architecture.

The first is NIS2. An operator of this kind generally falls within scope as an essential entity, with obligations around risk management, access control, cryptography and multi-factor authentication. NIS2 does not prescribe a specific product, nor does it forbid any particular provider. What it requires is that the risk be addressed, and strong authentication on access to critical services is one of the measures that addresses the risk NIS2 targets. Extending MFA across remote access, federated applications and administrative accounts speaks directly to that.

The second is jurisdiction, and this is where data residency and legal reach diverge. The operator itself is not subject to the US CLOUD Act. But a cloud provider that is US-based, or controlled by a US parent, remains subject to it regardless of where the data is physically stored, which means a user directory replicated into such a service can fall within the reach of US legal process even when it is held in a European region. The major providers offer safeguards and EU data boundary options, and direct access to European data centres is not the everyday event some headlines suggest. The argument does not rest on how often a request is made. It rests on the structural fact that the data sits under a foreign legal regime, which is precisely what a sovereignty requirement is meant to exclude.

Keeping the directory and the authentication decision on-premise, extended into a sovereign cloud rather than a hyperscaler tenant, lets the operator meet the resilience requirement and keep identity data under European jurisdiction at the same time. That is the trade the move to Entra ID does not offer.

Resilience and sovereignty are often framed as a choice: keep control and live with a single point of failure, or gain redundancy by moving identity to a hyperscaler. When neither can be given up, the question is whether the on-premise foundation can be consolidated instead of replaced. For this kind of constraint, it can be.

Further reading: a feature and tier comparison of OpenOTP and Microsoft Entra ID.