ADFS was a stopgap and is now production
The bridge between your directory and your modern applications became load-bearing without ever being designed for it. It is the fragile part of the estate and everyone knows it.
Identity & access · Straventa Accounts
An Active Directory alternative for the applications AD was never built for
Active Directory does the Windows domain well: Group Policy, machine join, file-share permissions, Kerberos on the LAN. What it does not do is speak the protocol your web and mobile applications want, which is why there is an ADFS box in the middle of your estate that everyone is slightly afraid of. Straventa Accounts is the application sign-on layer — self-hosted, OpenID Connect, inside your own infrastructure.
Why teams move
What actually pushes organisations off On-prem AD / LDAP
Twelve applications, twelve user tables
The apps AD could not cover grew their own logins. Offboarding takes a week and nobody can answer what a leaver still has access to in one query.
Licensing, hardware, and administrators
Server and CAL licensing, the hardware under it, and the people who keep it running are all real costs that never appear as one line labelled 'identity'.
Forests and trusts are heavy to change
Reorganise the group, acquire a subsidiary, or restructure a division, and the directory is the slowest thing in the room.
What does not carry over
This is a coexistence story, not a replacement. Straventa Accounts does not do Active Directory's Windows domain duties — no Group Policy, no machine join, no file-share ACLs, no Kerberos on the LAN — and it does not ship live LDAP sync today. What it replaces is the ADFS bridge and the twelve separate application user tables. The common shape is Accounts in front of every web and mobile application while AD keeps the Windows estate, and AD shrinks over time as applications move off it. We map which of your systems fall on which side during the architecture review, before you sign anything.
Straventa vs On-prem AD / LDAP
Straventa Accounts compared with On-prem AD / LDAP
Written for the person who has to defend the choice in a board pack. Competitor rows describe each vendor's publicly documented model at time of writing.
| Criterion | Straventa Accounts | On-prem AD / LDAP |
|---|---|---|
| Deployment model | Self-hosted on your Kubernetes or Docker, or Straventa-managed at accounts.straventa.com. Your choice, same product. | Self-hosted only. |
| Where identity data lives | Your infrastructure, in Indonesia. Nothing leaves your environment on the self-hosted deployment. | Your infrastructure. |
| Pricing model | Per deployment, annual. Not per seat — headcount growth does not change the invoice. | Server and CAL licensing plus hardware plus administrators. |
| Who operates it | You, or Straventa under contract. Start managed and take it in-house later without re-platforming. | Your infrastructure team. |
| Who answers at 03:00 | A named Straventa engineering contact, on terms set in your contract, in your timezone. | Your own on-call. |
| Protocols | OpenID Connect / OAuth 2.0 — PKCE, discovery, JWKS. SAML and SCIM are not shipped today; see the FAQ. | Kerberos / LDAP — needs ADFS or a bridge for modern apps. |
| Multi-tenant / group structure | Native tenant hierarchy with descendant-scoped permissions — built for holdings with subsidiaries. | Forests and trusts; heavy to change. |
| Ships integrated with your payments and ops stack | Yes — Payops and the Ops platform already authenticate against it and resolve permissions through it on day one. | An integration project. |
| Exit cost | Standard OIDC. Your apps point at an issuer URL — repoint them and leave. | High. |
Competitor rows describe each vendor’s publicly documented model at time of writing; confirm current terms with the vendor before making a decision.
Migration
Moving off On-prem AD / LDAP, without a flag day
Both systems run in parallel until the last application is across. There is no single evening on which everything has to work.
Step 1 Split the estate in two
Windows domain duties on one side, application sign-on on the other. Only the second side moves, and being explicit about the line is what makes the rest predictable.
Step 2 Deploy Accounts inside your infrastructure
AD stays exactly as it is. Accounts stands up beside it as the issuer for applications, with identity data in your own environment.
Step 3 Retire the ADFS dependency
Applications that were reaching AD through the bridge point at the Accounts issuer over standard OpenID Connect instead. The fragile hop comes out of the path.
Step 4 Consolidate the orphan user tables
The applications that grew their own logins move onto the same issuer, so offboarding becomes one action and access review becomes one query.
Straight answers
Questions we get from On-prem AD / LDAP teams
- Do we have to decommission Active Directory?
- No, and most organisations should not try to in the first phase. AD keeps Group Policy, machine join, file shares, and Kerberos. Accounts takes application sign-on. AD shrinks over time as applications move off it, but that is an outcome rather than a prerequisite, and there is no point in the plan where both have to be replaced at once.
- Can users keep the same password?
- Not automatically — there is no live LDAP sync today, so users set a credential against Accounts as part of the cutover. We sequence that with the first application move so it happens once rather than per application, and user import itself is scripted against the Accounts API.
- What about applications that only speak LDAP or SAML?
- They stay pointed at what already works, or they sit behind a bridge. Accounts speaks OpenID Connect and OAuth 2.0 only. During the architecture review we list every application that falls into this category and are explicit about which ones the project does not help — that list is usually shorter than people expect, but it is never empty.
Comparing something else?
Take the bridge out of the critical path.
Bring your application inventory and we will map which systems move onto a modern issuer, which stay with AD, and what the ADFS dependency is actually costing you.