Active Directory SSO: how AD users get single sign-on

Active Directory does not provide single sign-on to web applications by itself. AD authenticates users to Windows domain resources with Kerberos, and applications can query it over LDAP, but SAML and OpenID Connect are not part of AD. "Active Directory SSO" is therefore always a bridge: something translates the AD identity into a protocol the application understands.

Short answer: there are three common bridges. Sync AD to Entra ID and let Entra ID do SSO. Keep AD and add AD FS for SAML. Or put an identity provider such as Casdoor in front of the applications, with AD as the user source. The right one depends on whether you are moving to the cloud, staying on-premises, or connecting a mix of old and new apps.

Why AD alone is not SSO for web apps

AD DS provides:

• Kerberos for domain logon and services that support Windows integrated authentication.
• LDAP for applications that bind with a username and password.
• Group Policy and DNS for managing Windows machines.

Kerberos-based integrated authentication works well for intranet applications and file shares, but SaaS products, mobile apps and most modern web applications expect SAML or OpenID Connect. LDAP integration is not single sign-on either: each application shows its own login form and receives the password.

Option 1: Sync AD to Entra ID

Microsoft's cloud identity service, Entra ID (formerly Azure AD), can receive users from on-premises AD through Entra Connect. The sync copies accounts and attributes; password hash sync or pass-through authentication lets users keep their AD password.

Applications then connect to Entra ID over SAML or OIDC. On domain-joined Windows machines on the corporate network, seamless SSO can sign users in to Entra ID without prompting for a password again.

This is the natural path if you use Microsoft 365 and want one identity for both Microsoft and third-party SaaS. It requires a hybrid identity design, and the cloud service becomes part of your login path.

Option 2: Add AD FS

Active Directory Federation Services (AD FS) is Microsoft's on-premises federation server. It issues SAML and WS-Federation tokens for applications, using AD as the account store. Many enterprises built their SSO on AD FS before cloud identity existed.

AD FS keeps authentication on-premises and works without a cloud dependency, which matters in regulated environments. The trade-offs are operational: servers, certificates, farm configuration and upgrades are yours to run. Some organizations keep AD FS for legacy applications while moving new applications to Entra ID.

Option 3: An identity provider in front of the apps

A third option keeps AD as the user store and puts an identity provider such as Casdoor or Keycloak between AD and the applications:

1. AD remains the source of employee accounts.
2. Casdoor syncs users and groups from AD over LDAP on a schedule.
3. Applications connect to Casdoor over OpenID Connect or SAML.
4. Casdoor adds MFA, passkeys, organizations and self-service login on top of AD.

This is common when applications cannot reach AD directly, when AD is old and should not be exposed, or when one login must cover both AD users and external customers. Casdoor also serves LDAP for applications that only speak LDAP, so legacy and modern apps share one user directory.

The limitation is that syncing copies attributes; AD remains the source of truth for accounts. Password changes still happen in AD, and Casdoor does not make AD's Group Policy apply to anything.

Choosing between the three

In practice, large organizations run more than one: AD FS for legacy applications, Entra ID for Microsoft 365, and a third-party identity provider for customer-facing products.

A migration checklist

1. Map applications to protocols. List which apps use Kerberos, LDAP, SAML or OIDC, and which have no SSO at all.
2. Pick the account source. Keep AD authoritative for employees and sync outward; do not create a second password store.
3. Pilot with one group. Move an IT team first and keep the old path available.
4. Plan MFA and recovery. SSO centralizes risk: one compromised account can reach every connected app.
5. Retire the bridge only after the apps move. AD FS, Entra Connect and Casdoor can run in parallel during the transition.

Casdoor is an open-source identity provider with an AD syncer, SAML and OIDC for applications, LDAP for legacy software, and MFA and organizations on top. Self-host it for free, or run a dedicated instance on Casdoor Cloud from $6.67/month billed yearly. Related reading: LDAP vs Active Directory, Active Directory alternatives and LDAP authentication.

FAQ

Does Active Directory support SAML? Not by itself. AD provides Kerberos and LDAP. SAML requires AD FS, Entra ID or a third-party identity provider that reads AD as its user store.

Is Azure AD the same as Active Directory? No. Azure AD, now called Microsoft Entra ID, is Microsoft's cloud identity service. Active Directory Domain Services is the on-premises directory and domain controller. Entra Connect links the two.

What is the difference between LDAP and SSO? LDAP is a directory query protocol: the application receives a username and password and checks it against the directory. SSO means the user signs in once at an identity provider, and applications receive a signed token instead of a password.

Can Casdoor replace AD FS? Casdoor can replace AD FS for applications that need SAML or OIDC, with AD or Entra ID as the user source. It does not replace AD's Kerberos, Group Policy or domain services.

Do users need a second password for the identity provider? No, if the identity provider syncs from AD and authentication stays in AD. If the identity provider stores its own credentials, plan how passwords will be created, reset and kept in sync.