What happens when organisations try to extend web app single sign-on to on-prem applications without rethinking the underlying directory model?

Why SSO Reach Often Stops at the Browser Boundary

Web app single sign-on usually solves one access path, not the whole directory model. It works best when applications can trust a federated browser flow, but many on-prem systems still expect direct directory lookups, Kerberos tickets, LDAP binds, or platform-specific authentication. That means the organisation has unified the sign-in experience without necessarily unifying the underlying identity architecture.

The practical gap is that “SSO” can hide multiple authentication and authorization back ends. A user may authenticate once through an identity provider for SaaS and modern web apps, while legacy resources continue to depend on Active Directory, local groups, service-specific accounts, or protocol-specific trust. The user sees one front door, but operations still manage several doors behind it.

This is why SSO expansion often becomes an overlay, not a remodel. The directory remains the source of record for some systems, but not all enforcement points move with it. The result is partial coverage, duplicate policy logic, and a mixed estate where browser-based apps follow federation rules while on-prem dependencies continue to follow directory-native rules.

What Changes in the Directory Model When On-Prem Is Left Intact

When organisations do not rethink the underlying directory model, they keep the old assumptions alongside the new integration layer. Active Directory may still anchor workstation logon, Kerberos delegation, LDAP lookups, and legacy application access, even while web SSO uses federated identity assertions. That creates a layered identity fabric rather than a single coherent control plane.

One consequence is inconsistent lifecycle handling. Provisioning, group membership, role assignment, and deprovisioning may be automated for cloud apps, but on-prem entitlements often remain tied to inherited groups, application-local accounts, or manually maintained exceptions. The organisation may have modern login federation without modern entitlement governance.

Another consequence is that access paths diverge. Browser authentication can be centralised, but non-Windows systems, thick clients, middleware, file shares, administrative protocols, and service-to-service dependencies often remain outside that same model. For the reader’s practical purposes, the question is not whether SSO exists, but which assets actually accept it and which still require native directory trust.

Why the Mixed Model Creates Operational Drag

The biggest operational issue is not just inconvenience, it is control fragmentation. Teams must troubleshoot federation, directory replication, group policy, Kerberos behaviour, legacy protocol compatibility, and application-specific access rules at the same time. A change that looks small in the identity layer can ripple into legacy systems that were never designed to consume browser-centric SSO.

There is also a maintenance penalty. Modern SSO tends to improve user experience, but the organisation still has to maintain the old directory dependencies for applications that cannot be modernised quickly. That leaves IT with duplicated identity logic, more exception handling, and more places where access can drift out of policy.

For that reason, this kind of program often exposes the limits of partial modernization. If the directory model itself is not simplified, the SSO project becomes an additional layer to support rather than a replacement for the underlying access model. The better the federation layer works, the more visible the remaining legacy dependencies become.

Risk and Threat Considerations

The main security risk is false confidence. A company can believe it has standardized access because users sign in through a common web flow, while legacy protocols and on-prem services still expose separate authentication paths and long-lived directory dependencies. That creates uneven policy enforcement and a larger blast radius when accounts, groups, or trust relationships are mismanaged.

Failure mechanism: Federation covers the browser-facing applications, but on-prem systems continue to trust directory-native mechanisms such as LDAP, Kerberos, and legacy service accounts, so control gaps persist between the two models.

Impact: Attackers or careless administrators can exploit the weakest path, lateral movement becomes easier across mixed trust boundaries, and deprovisioning or privilege changes may not take effect uniformly.

Practitioner Guidance

What to verify: Map every material application and infrastructure dependency to the authentication mechanism it actually uses, then separate “SSO-enabled” from “directory-native” access paths. If an application still depends on Kerberos tickets, LDAP binds, or local accounts, treat it as outside the unified sign-on model even if users reach it through a portal.

Trade-off: Adding web SSO without directory redesign is often the fastest way to improve user experience, but it also preserves legacy complexity. That is acceptable when you are deliberately wrapping old systems, not when the program goal is architectural unification.

What good looks like: The identity model is explicit about which systems are federated, which remain directory-bound, and which require modernization or isolation. Access reviews, offboarding, and privilege changes should produce the same outcome across both layers, not just in the browser layer.

Practitioner takeaway: Treat web SSO as an integration pattern, not proof of directory convergence. If the back end still depends on mixed legacy trust models, the right next step is to inventory those dependencies and decide where to retire, isolate, or deliberately keep them.

Related resources from NHI Mgmt Group

• What happens when organisations extend Active Directory to AWS without visibility into sign in activity and access events?
• What happens when enterprise customers try to adopt SaaS applications without SAML or single sign-on support?
• What happens when organisations try to replace on-prem desktops with DaaS without planning for compliance and integrations?
• What happens when organisations try to secure critical web apps without a last mile control layer?