Active Directory is still the authoritative user directory in many organisations. Users, passwords and group memberships often already live there, and in many cases they have done so for years.
But modern applications often expect modern federation protocols and stronger authentication options.
New web applications, SaaS platforms and customer-facing portals often support OpenID Connect or SAML 2.0. They expect modern tokens, claims, federation metadata, single sign-on flows and sometimes step-up authentication with MFA.
That creates a common challenge: how do you modernise authentication without replacing Active Directory from day one?
This is where the FoxIDs Directory Connector for Active Directory becomes useful. It lets organisations keep Active Directory as the source of users, passwords and group memberships, while FoxIDs adds the modern identity layer on top.
Users can still sign in with their existing Active Directory credentials. Applications can integrate with FoxIDs using OpenID Connect or SAML 2.0. And FoxIDs can add claims, roles, multi-factor authentication and a branded login experience around the existing directory.
Active Directory can stay where it is
Many organisations are not looking for a big-bang migration away from Active Directory. They simply need to make their existing directory work with modern applications.
With the Directory Connector for Active Directory, FoxIDs connects to a component installed inside the customer’s Windows environment, close to the domain controllers. FoxIDs calls the connector over HTTPS, and the connector validates users, handles password operations and returns selected user properties and claims from Active Directory.
The important part is that Active Directory remains authoritative.
That means passwords can still be validated by AD. Existing password policies can still apply. Users can still be managed in the familiar directory. And group membership can still be controlled by the existing IT processes.
FoxIDs then becomes the modern identity layer in front of AD.
Instead of connecting every application directly to Active Directory or LDAP, applications connect to FoxIDs. FoxIDs handles the federation protocol, token issuing, claims and authentication flow, while AD remains the underlying directory.
This gives organisations a practical migration path. They can start by keeping users in Active Directory and later move users to FoxIDs when it makes sense. The transition does not have to happen all at once.
OIDC and SAML 2.0 for existing AD users
The main value is simple: existing Active Directory users can sign in to modern OpenID Connect and SAML 2.0 applications through FoxIDs.
For OpenID Connect applications, FoxIDs acts as the OpenID Provider. Applications can use discovery, authentication, logout and the UserInfo endpoint. FoxIDs also supports PKCE and different client authentication options.
For SAML 2.0 applications, FoxIDs can issue SAML assertions and act as the identity provider for applications that rely on SAML-based enterprise single sign-on.
This is useful when an organisation has a mix of application types. One application may use OpenID Connect. Another may still require SAML 2.0. A third may later need OAuth 2.0 access tokens for APIs.
The users can still be the same AD users.
This avoids a situation where the organisation must duplicate users, build custom LDAP integrations or migrate identities before the first modern application can go live.
Instead, FoxIDs can bridge the gap between the existing directory and the protocols modern applications expect.
Use AD groups as modern application claims
Authentication is only part of the story. Applications also need to know who the user is and what they are allowed to access.
Active Directory often already contains that information through group memberships. A user may be a member of an Employees group, an Administrators group, a Finance group or a Customer Support group.
The Directory Connector can return configured AD attributes as claims and configured AD group memberships as claims. Group claims are commonly returned as role claims, and nested groups can be included.
This makes it possible to use existing AD group structures in modern applications.
For example, an AD group such as Employees can be returned as a role claim with the value Employees. The application does not need to understand LDAP or query Active Directory directly. It only needs to read the claims issued by FoxIDs.
The screenshot below shows an Active Directory user who is a member of the Employees group. This is the existing group membership already managed in Active Directory.
When the user signs in through FoxIDs, the AD group membership can be included as a role claim in the issued application token. In this example, the Employees group is returned as a role claim.
The application does not need to query Active Directory directly. It only needs to read the claims issued by FoxIDs.
That is a clean separation of responsibilities.
Active Directory remains the place where membership is managed. FoxIDs transforms that directory information into modern identity claims. The application receives the result in the protocol it already supports.
Add MFA on top of Active Directory login
A major benefit of using FoxIDs in front of Active Directory is that login can be strengthened without replacing the directory.
FoxIDs supports both simple two-factor authentication and advanced multi-factor authentication in the login authentication method. Supported built-in factors include SMS code, email code, authenticator app code and recovery code. FoxIDs can also use other authentication methods, such as OIDC or SAML 2.0, as MFA steps.
MFA can be required in several ways.
It can be enabled for selected users. It can be required on the login authentication method. Or an application can request MFA when needed. For OpenID Connect, the application can request MFA with acr_values=urn:foxids:mfa. For SAML 2.0, MFA can be requested through the authentication context.
This is valuable because not all applications need the same level of assurance all the time.
A normal internal application may only need username and password. A sensitive admin portal may require MFA every time. Another application may only request MFA for specific actions or higher-risk sessions.
FoxIDs can support that kind of step-up model while the first factor is still validated against Active Directory.
In practice, this means organisations can keep AD as the user and password source while adding modern security controls around the login experience.
A better migration path
Replacing an identity directory is rarely just a technical decision. It affects users, applications, IT operations, security policies and support processes.
That is why a gradual path matters.
With FoxIDs, an organisation can start by connecting Active Directory and letting users sign in with their existing credentials. FoxIDs can keep an internal user record with identifiers, properties, claims, MFA settings and access assignments, while the external directory remains authoritative for password validation and password changes.
Later, if the organisation wants to move users fully into FoxIDs, it has a path to do so.
This is especially useful for organisations that want to modernise authentication first and decide on user migration later. It also helps when different user groups move at different speeds. Employees may stay in AD. External users may already live in FoxIDs. New applications may use OIDC. Legacy enterprise applications may use SAML 2.0.
FoxIDs can sit in the middle and make those worlds work together.
A branded login experience
Modern authentication is not only about protocols and security. The user experience also matters.
When users are redirected to sign in, the login page should look familiar and trustworthy. FoxIDs supports customisation of the login experience, including browser title, browser icon and CSS. The same login flow can also guide users through multi-factor authentication when stronger security is required.
This is useful for both internal and customer-facing scenarios.
An employee login can use the organisation’s name and style while still adding MFA on top of the existing Active Directory username and password. A customer portal can use the customer’s brand. A partner-facing application can have a tailored login experience without changing the underlying AD integration.
The example below shows a branded MFA login screen for a fictional company, Northbridge Systems. The user signs in with an existing account and is then asked to complete SMS two-factor authentication in FoxIDs.
The full CSS used for this example is included at the end of the article.
The result is a more complete identity layer: modern protocols, AD-backed users, claims, MFA and a branded sign-in flow.
Getting started
Getting started does not require every application or user to be migrated.
A typical first step is to install the Directory Connector for Active Directory in the Windows environment where it can reach the domain controllers. From there, FoxIDs can validate users through the connector and issue modern OpenID Connect or SAML 2.0 responses to applications.
The setup then becomes an incremental process. Start with one application, map the AD attributes and group memberships that the application needs, decide whether MFA should be required, and optionally customise the login experience.
Once the first application is working, the same pattern can be reused for additional applications. Some may use OpenID Connect, others may use SAML 2.0, and sensitive applications can require MFA when needed.
For the detailed configuration steps, see the FoxIDs Directory Connector for Active Directory documentation.
Conclusion
Active Directory is still central to many organisations, but modern applications need modern authentication.
The FoxIDs Directory Connector for Active Directory makes it possible to keep existing AD users, passwords and groups while enabling OpenID Connect, SAML 2.0, claims and MFA through FoxIDs.
It gives organisations a practical way to modernise authentication, improve security and support new applications without replacing everything at once.
For many organisations, that is the most realistic path forward: keep what already works, add the modern identity layer on top, and migrate when the business is ready.
Example CSS for the branded login screen
The screenshot above uses the CSS below to style the FoxIDs login page for the fictional company Northbridge Systems. It changes the company name, colour palette, page background, login card, input focus colour, buttons, links and the information message.
In FoxIDs, this CSS can be added on the Login UI tab of the login authentication method together with the browser title and browser icon.
:root {
--brand-primary: #16324f;
--brand-primary-dark: #0f2439;
--brand-accent: #1f8a8a;
--brand-accent-dark: #176d6d;
--brand-accent-soft: #e9f6f6;
--brand-bg: #f4f8fb;
--brand-surface: rgba(255, 255, 255, 0.97);
--brand-border: #dbe5ec;
--brand-text: #14202b;
--brand-muted: #5f6f7f;
}
/* Page background */
body {
background:
radial-gradient(circle at top right, rgba(31, 138, 138, 0.12), transparent 28rem),
radial-gradient(circle at bottom left, rgba(22, 50, 79, 0.10), transparent 26rem),
linear-gradient(135deg, #ffffff 0%, var(--brand-bg) 100%);
color: var(--brand-text);
}
/* Page spacing */
.container.body-content {
padding-top: 3.5rem;
padding-bottom: 3.5rem;
}
/* Main content card */
.page-content {
background: var(--brand-surface);
border: 1px solid var(--brand-border);
border-radius: 1.25rem;
box-shadow: 0 1.25rem 3rem rgba(15, 36, 57, 0.10);
padding: 2.25rem 2.5rem;
}
/* Brand block */
.brand-content {
margin-bottom: 2rem;
}
/* Hide default text and replace with fictive company name */
.brand-content-text {
visibility: hidden;
height: auto;
}
.brand-content-text::before {
content: "Northbridge Systems";
visibility: visible;
display: block;
color: var(--brand-primary);
font-size: 2.9rem;
font-weight: 600;
line-height: 1.05;
letter-spacing: -0.03em;
}
.brand-content-text::after {
content: "Secure Login";
visibility: visible;
display: block;
color: var(--brand-accent);
font-size: 1.15rem;
font-weight: 500;
margin-top: 0.35rem;
letter-spacing: 0.01em;
}
/* Hide the default icon if you want a clean text-led brand */
.brand-content-icon {
display: none;
}
/* Main headings, e.g. SMS two-factor */
h1, .h1 {
color: var(--brand-primary);
font-weight: 300;
letter-spacing: -0.03em;
margin-bottom: 1.5rem;
}
/* General supporting text */
.info-message,
.info-message-filter,
.help-block,
.text-muted,
small {
color: var(--brand-muted) !important;
}
/* Labels */
label,
.label-control {
color: var(--brand-primary) !important;
font-weight: 500;
}
/* Inputs */
.form-control,
.input-control {
border: 1px solid #cfd9e2;
border-radius: 0.5rem;
color: var(--brand-text);
min-height: 2.8rem;
background-color: #ffffff;
}
.form-control:focus,
.input-control:focus,
.input:focus {
border-color: var(--brand-accent);
box-shadow: 0 0 0 0.2rem rgba(31, 138, 138, 0.18);
outline: none !important;
}
/* Primary button */
.btn-primary,
.btn-primary:hover,
.btn-primary:focus,
.btn-primary:active,
.btn-primary:not(:disabled):not(.disabled).active,
.btn-primary:not(:disabled):not(.disabled):active,
.show > .btn-primary.dropdown-toggle {
color: #ffffff;
background-color: var(--brand-primary);
border-color: var(--brand-primary);
border-radius: 0.5rem;
font-weight: 500;
padding-left: 1.15rem;
padding-right: 1.15rem;
}
.btn-primary:hover,
.btn-primary:active,
.btn-primary:not(:disabled):not(.disabled):active {
background-color: var(--brand-primary-dark);
border-color: var(--brand-primary-dark);
}
.btn-primary:focus,
.btn-primary:not(:disabled):not(.disabled).active:focus,
.btn-primary:not(:disabled):not(.disabled):active:focus,
.show > .btn-primary.dropdown-toggle:focus {
box-shadow: 0 0 0 0.2rem rgba(22, 50, 79, 0.22);
}
/* Disabled button */
.btn-primary.disabled,
.btn-primary:disabled {
color: #ffffff;
background-color: #8ea3b7;
border-color: #8ea3b7;
}
/* Links */
a,
a:hover,
.btn-link,
.btn-link:hover,
.btn-link:focus,
.btn-link:not(:disabled):not(.disabled):active,
.btn-link:not(:disabled):not(.disabled).active,
.show > .btn-link.dropdown-toggle {
color: var(--brand-accent-dark);
text-decoration: none;
}
a:hover,
.btn-link:hover {
text-decoration: underline;
}
/* Checkbox */
.form-check-label {
color: var(--brand-text) !important;
font-weight: 400;
}
/* Optional info panel before or inside login box */
div.page-content::before {
content: "Sign in with your company account. Multi-factor authentication may be required for added security.";
display: block;
background: var(--brand-accent-soft);
color: var(--brand-primary);
border: 1px solid #cfe7e7;
border-radius: 0.75rem;
padding: 0.9rem 1rem;
margin-bottom: 1.5rem;
font-size: 0.96rem;
line-height: 1.45;
}
/* Footer */
.footer,
footer {
color: var(--brand-muted);
font-size: 0.85rem;
}
/* Mobile */
@media (max-width: 767.98px) {
.container.body-content {
padding-top: 1.5rem;
padding-bottom: 1.5rem;
}
.page-content {
border-radius: 0.9rem;
padding: 1.5rem;
box-shadow: 0 0.75rem 2rem rgba(15, 36, 57, 0.08);
}
.brand-content-text::before {
font-size: 2.2rem;
}
.brand-content-text::after {
font-size: 1rem;
}
}