If you run an on-premise Active Directory, a couple of hundred internal applications, and a security team that will not let any new tool write into AD or turn the directory into an application database, most modern identity platforms will gently explain that this is not how they work. We had that conversation recently with a European group of several thousand users running its identity stack on premises. Here is how the constraint actually gets solved, and why it is far less exotic than vendors make it sound.

The requirement everyone tries to talk you out of

The group already had an access-management product. It did one-time passwords and nothing else, it was unstable, and the team could not operate it without outside help. They wanted out, and they had a clear list: single sign-on across a large application estate over SAML and OIDC, a second factor by both TOTP and push, conditional access, usage reporting with export to their SIEM, one portal for users, and the ability to bring external contractors in through the same identity provider rather than through a separate side door.

So far, ordinary. Then came the part that decides which vendors are still in the room.

The new layer was not allowed to write into their Active Directory or store its own operational data there. AD had to remain authoritative and read-only to the RCDevs layer. Users and groups could be synchronized from AD into OpenLDAP, and passwords could be validated against AD, but the production directory itself was not to become the storage backend for MFA, SSO, policies, or configuration.

This is not a quirky preference, and a good team should not have to defend it. Every additional place where authentication data is handled has to be explicit, controlled, and justified. Keeping AD authoritative and out of the write path is a deliberate control decision. The trouble is that many cloud-first identity products are a poor fit for that constraint. Their normal operating model is to synchronize your on-premise directory into a vendor cloud tenant and run SSO, MFA, policy, enrolment state, reporting, and sometimes lifecycle management from there. Some can leave AD authoritative and avoid writing back to it, but the vendor cloud still becomes the operational identity control plane. For a customer that wants AD read-only and wants MFA/SSO operational data to remain on-premises, that does not honour the architecture they are trying to enforce. The customer was evaluating one of those in parallel, which is partly why the requirement was on the table at all.

Keep AD authoritative, and keep it out of the write path

The way through is to separate two questions that vendors like to merge: where the identity is authoritative, and what the MFA and SSO layer needs to operate.

AD remains authoritative for users and groups. The relevant accounts and group memberships are synchronized into RCDevs OpenLDAP, where the identity layer can use them without turning AD into an application database. In practice, AD stays the upstream source of truth, while OpenLDAP becomes the operational directory for the MFA and SSO layer.

At sign-in, the domain password is checked by binding against the corresponding account in AD. If AD validates the password, the last validated password is stored on the replicated OpenLDAP user object. That is an intentional resilience measure: it allows the authentication layer to continue operating if AD later becomes unavailable.

This makes the boundary clear. Password validation still comes from AD when AD is available, and the last validated password is held in the on-premise OpenLDAP layer for continuity.

Everything else the MFA and SSO layer needs to know, including token secrets, enrolment state, user policies, group policies, client policies, IdP configuration, and RCDevs configuration data, also lives in OpenLDAP. AD stays out of the write path: still the authoritative identity source, but with the authentication and SSO layer sitting beside it rather than inside it.

That is the whole idea, and it is a supported way to run the suite, not a workaround we improvised. A strong identity layer does not have to own your directory to protect it.

One identity provider in front of the estate

With the data question settled, the rest is integration work. We stood up the identity provider speaking both SAML and OIDC, in front of the application estate, so a user authenticates once and reaches the applications they are entitled to. The VDI and remote-access gateways were wired in as SAML service providers. The second factor was delivered through TOTP and push, using the free OpenOTP Token app, so there was no per-user hardware to buy.

External contractors were also represented in AD, so they authenticate through that same identity provider, with the same MFA, instead of through a parallel mechanism nobody audits. RCDevs initially proposed storing external contractor accounts in OpenLDAP rather than in Active Directory, in order to keep only internal accounts in the AD. However, the customer preferred to provision and manage contractor accounts directly from Active Directory, which was both understandable and fully supported.

Conditional access policies keep routine sign-ins frictionless while unusual ones get challenged. And because the whole thing runs on premises, the audit trail and the SIEM export stay inside their own environment. For a European group that wants its authentication data to remain under its own roof, that is the reason to do it this way.

There was also an autonomy problem to fix, since the team had been unable to run their previous tool unaided. Self-service token enrolment and delegated help-desk roles mean day-to-day MFA operations no longer route through a vendor. They can support users and operate the identity layer themselves, while AD password management stays outside the scope of the deployment.

A single sign-on portal for 200+ internal applications

One requirement did not fit any product sheet at the time. With more than two hundred web applications in the estate, the group wanted users to land on a single page after signing in, see the applications available to them, and open any of them in one click. Less a login screen than an internal application directory, with entitlements that vary widely from one team to the next.

That requirement became the basis for what is now the Application Shortcuts Portal in RCDevs Identity Provider 1.6.15. The portal presents application shortcuts to the authenticated user according to their entitlements. Each shortcut is an icon that redirects the user to the application’s login URL. The application then redirects the user to the IdP through SAML or OpenID Connect. Since the user already has an authenticated session on the portal, the IdP completes the SSO flow and sends the user back to the application as authenticated.

Visibility and access follow directory group membership, so who sees and opens what is governed exactly the way the group already governs everything else.

This is the kind of thing that separates an adaptable platform from a closed one. The requirement was reasonable and sat close to what the IdP already did, so extending it was the right answer, not “that is not supported.”

Setting up self-service password reset against a read-only AD

Early on during the POC, the main complexity revolved around synchronization behavior, group mapping, and operational resilience when directory availability changed. Since the synchronization mechanism relies on Active Directory as the authoritative source, users are automatically maintained in OpenLDAP based on their presence and status in AD. Questions such as which AD groups were authoritative, which employee and contractor accounts needed to be synchronized, and how the platform should behave when AD became unavailable are the kinds of operational considerations that typically only emerge in a real production environment rather than in a demo tenant.

Operationally, account lifecycle management was ultimately handled through the native synchronization mechanism itself. No custom scripting was required, as the synchronization process runs automatically every hour and keeps OpenLDAP aligned with the state of the Active Directory.

If you are carrying the same constraint

The questions to put to any identity vendor are short, and the answers sort the on-premise-friendly tools from the ones that need to become your new system of record:

• Where does my user data physically live once your product is in place?
• Can my Active Directory remain authoritative and read-only while users and groups are synchronized into a local directory?
• Do you write into AD or store product configuration in AD?
• How do you validate passwords, do you cache anything, and where exactly is that data held?
• Is this solution fully on-premise? 

We are happy to be asked all five.