Active Directory är fortfarande den auktoritativa användarkatalogen i många organisationer. Användare, lösenord och gruppmedlemskap bor ofta redan där, och i många fall har de gjort det i flera år.
Men moderna applikationer förväntar sig ofta moderna federationsprotokoll och starkare autentiseringsalternativ.
Nya webbapplikationer, SaaS-plattformar och kundvända portaler stöder ofta OpenID Connect eller SAML 2.0. De förväntar sig moderna tokens, claims, federationsmetadata, enkel inloggningsflöden och ibland ökad autentisering med MFA.
Det skapar en gemensam utmaning: hur moderniserar du autentisering utan att ersätta Active Directory från dag ett?
Det är här som FoxIDs Directory Connector for Active Directory blir användbar. Det låter organisationer behålla Active Directory som källan till användare, lösenord och gruppmedlemskap, medan FoxIDs lägger till det moderna identitetslagret ovanpå.
Användare kan fortfarande logga in med sina befintliga Active Directory-uppgifter. Applikationer kan integreras med FoxIDs med OpenID Connect eller SAML 2.0. Och FoxIDs kan lägga till claims, roller, multifaktorautentisering och en varumärkesinloggningsupplevelse runt den befintliga katalogen.
Active Directory kan stanna där den är
Många organisationer letar inte efter en big-bang-migrering bort från Active Directory. De behöver helt enkelt få sin befintliga katalog att fungera med moderna applikationer.
Med Directory Connector for Active Directory, ansluter FoxIDs till en komponent installerad i kundens Windows-miljö, nära domänkontrollanterna. FoxIDs anropar anslutningen över HTTPS, och anslutningen validerar användare, hanterar lösenordsoperationer och returnerar valda användaregenskaper och claims från Active Directory.
Den viktiga delen är att Active Directory förblir auktoritativ.
Det betyder att lösenord fortfarande kan valideras av AD. Befintliga lösenordspolicyer kan fortfarande gälla. Användare kan fortfarande hanteras i den välbekanta katalogen. Och gruppmedlemskap kan fortfarande styras av befintliga IT-processer.
FoxIDs blir då det moderna identitetslagret framför AD.
Istället för att ansluta varje applikation direkt till Active Directory eller LDAP, ansluter applikationer till FoxIDs. FoxIDs hanterar federationsprotokollet, utfärdande av token, claims och autentiseringsflöde, medan AD förblir den underliggande katalogen.
Detta ger organisationer en praktisk migrationsväg. De kan börja med att behålla användare i Active Directory och senare flytta användare till FoxIDs när det är vettigt. Övergången behöver inte ske på en gång.
OIDC och SAML 2.0 för befintliga AD-användare
Huvudvärdet är enkelt: befintliga Active Directory-användare kan logga in på moderna OpenID Connect och SAML 2.0-applikationer genom FoxIDs.
För OpenID Connect applikationer fungerar FoxIDs som OpenID-leverantör. Applikationer kan använda upptäckt, autentisering, utloggning och UserInfo-slutpunkten. FoxIDs stöder också PKCE och olika klientautentiseringsalternativ.
För SAML 2.0 applikationer kan FoxIDs utfärda SAML-påståenden och fungera som identitetsleverantör för applikationer som förlitar sig på SAML-baserad enkel inloggning för företag.
Detta är användbart när en organisation har en blandning av applikationstyper. En applikation kan använda OpenID Connect. En annan kan fortfarande kräva SAML 2.0. En tredje kan senare behöva OAuth 2.0 åtkomsttokens för API:er.
Användarna kan fortfarande vara samma AD-användare.
Detta undviker en situation där organisationen måste duplicera användare, bygga anpassade LDAP-integrationer eller migrera identiteter innan den första moderna applikationen kan gå live.
Istället kan FoxIDs överbrygga gapet mellan den befintliga katalogen och de protokoll som moderna applikationer förväntar sig.
Använd AD-grupper som moderna applikationer claims
Autentisering är bara en del av historien. Applikationer måste också veta vem användaren är och vad de får åtkomst till.
Active Directory innehåller ofta redan den informationen genom gruppmedlemskap. En användare kan vara medlem i en anställd-grupp, en administratörsgrupp, en ekonomigrupp eller en kundsupportgrupp.
Directory Connector kan returnera konfigurerade AD-attribut som claims och konfigurerade AD-gruppmedlemskap som claims. gruppclaims returneras vanligtvis som rollclaims och kapslade grupper kan inkluderas.
Detta gör det möjligt att använda befintliga AD-gruppstrukturer i moderna applikationer.
Till exempel kan en AD-grupp som Anställda returneras som ett rollclaims med värdet Anställda. Applikationen behöver inte förstå LDAP eller fråga Active Directory direkt. Den behöver bara läsa claimsen från FoxIDs.
Skärmdumpen nedan visar en Active Directory-användare som är medlem i gruppen Anställda. Detta är det befintliga gruppmedlemskapet som redan hanteras i Active Directory.
När användaren loggar in via FoxIDs kan AD-gruppmedlemskapet inkluderas som ett rollclaims i den utfärdade applikationstoken. I det här exemplet returneras gruppen Anställda som ett rollclaims.
Applikationen behöver inte fråga Active Directory direkt. Den behöver bara läsa claimsen från FoxIDs.
Det är en ren ansvarsfördelning.
Active Directory förblir platsen där medlemskap hanteras. FoxIDs förvandlar den kataloginformationen till moderna identitetsclaims. Applikationen tar emot resultatet i det protokoll som det redan stöder.
Lägg till MFA ovanpå Active Directory inloggning
En stor fördel med att använda FoxIDs framför Active Directory är att inloggningen kan stärkas utan att ersätta katalogen.
FoxIDs stöder både enkel tvåfaktorsautentisering och avancerad multifaktorautentisering i inloggningsautentiseringsmetoden. Inbyggda faktorer som stöds inkluderar SMS-kod, e-postkod, autentiseringsappkod och återställningskod. FoxIDs kan också använda andra autentiseringsmetoder, såsom OIDC eller SAML 2.0, som MFA-steg.
MFA kan krävas på flera sätt.
Det kan aktiveras för utvalda användare. Det kan krävas på inloggningsautentiseringsmetoden. Eller en applikation kan begära MFA vid behov. För OpenID Connect kan applikationen begära MFA med acr_values=urn:foxids:mfa. För SAML 2.0 kan MFA begäras via autentiseringskontexten.
Detta är värdefullt eftersom inte alla applikationer behöver samma nivå av säkerhet hela tiden.
En normal intern applikation behöver kanske bara användarnamn och lösenord. En känslig administratörsportal kan kräva MFA varje gång. En annan applikation kan endast begära MFA för specifika åtgärder eller sessioner med högre risk.
FoxIDs kan stödja den typen av step-up-modell medan den första faktorn fortfarande är validerad mot Active Directory.
I praktiken innebär detta att organisationer kan behålla AD som användar- och lösenordskälla samtidigt som de lägger till moderna säkerhetskontroller kring inloggningsupplevelsen.
En bättre migrationsväg
Att ersätta en identitetskatalog är sällan bara ett tekniskt beslut. Det påverkar användare, applikationer, IT-drift, säkerhetspolicyer och supportprocesser.
Det är därför en gradvis väg är viktig.
Med FoxIDs kan en organisation börja med att ansluta Active Directory och låta användare logga in med sina befintliga referenser. FoxIDs kan hålla en intern användarpost med identifierare, egenskaper, claims, MFA-inställningar och åtkomsttilldelningar, medan den externa katalogen förblir auktoritativ för lösenordsvalidering och lösenordsändringar.
Om organisationen senare vill flytta användare helt till FoxIDs, har den en väg att göra det.
Detta är särskilt användbart för organisationer som vill modernisera autentisering först och besluta om användarmigrering senare. Det hjälper också när olika användargrupper rör sig i olika hastigheter. Anställda får stanna i AD. Externa användare kanske redan bor i FoxIDs. Nya applikationer kan använda OIDC. Äldre företagsprogram kan använda SAML 2.0.
FoxIDs kan sitta i mitten och få dessa världar att fungera tillsammans.
En märkt inloggningsupplevelse
Modern autentisering handlar inte bara om protokoll och säkerhet. Användarupplevelsen spelar också roll.
När användare omdirigeras för att logga in bör inloggningssidan se bekant och pålitlig ut. FoxIDs stöder anpassning av inloggningsupplevelsen, inklusive webbläsartitel, webbläsarikon och CSS. Samma inloggningsflöde kan också guida användare genom multifaktorautentisering när starkare säkerhet krävs.
Detta är användbart för både interna och kundinriktade scenarier.
En anställds inloggning kan använda organisationens namn och stil samtidigt som den lägger till MFA ovanpå det befintliga användarnamnet och lösenordet för Active Directory. En kundportal kan använda kundens varumärke. En partnerinriktad applikation kan ha en skräddarsydd inloggningsupplevelse utan att ändra den underliggande AD-integrationen.
Exemplet nedan visar en MFA-inloggningsskärm för ett fiktivt företag, Northbridge Systems. Användaren loggar in med ett befintligt konto och uppmanas sedan att slutföra SMS tvåfaktorsautentisering i FoxIDs.
Den fullständiga CSS som används för detta exempel finns i slutet av artikeln.
Resultatet är ett mer komplett identitetslager: moderna protokoll, AD-stödda användare, claims, MFA och ett varumärkesmärkt inloggningsflöde.
Komma igång
Att komma igång kräver inte att varje applikation eller användare migreras.
Ett typiskt första steg är att installera Directory Connector for Active Directory i Windows-miljön där den kan nå domänkontrollanterna. Därifrån kan FoxIDs validera användare genom kontakten och ge moderna OpenID Connect eller SAML 2.0 svar till applikationer.
Installationen blir sedan en stegvis process. Börja med en applikation, kartlägg AD-attributen och gruppmedlemskap som applikationen behöver, bestäm om MFA ska krävas, och valfritt customise inloggningsupplevelsen.
När den första applikationen fungerar kan samma mönster återanvändas för ytterligare applikationer. Vissa kan använda OpenID Connect, andra kan använda SAML 2.0 och känsliga applikationer kan kräva MFA vid behov.
För detaljerade konfigurationssteg, se FoxIDs Directory Connector for Active Directory-dokumentationen.
Slutsats
Active Directory är fortfarande central för många organisationer, men moderna applikationer behöver modern autentisering.
FoxIDs Directory Connector for Active Directory gör det möjligt att behålla befintliga AD-användare, lösenord och grupper samtidigt som OpenID Connect, SAML 2.0, claims och MFA genom FoxIDs aktiveras.
Det ger organisationer ett praktiskt sätt att modernisera autentisering, förbättra säkerheten och stödja nya applikationer utan att ersätta allt på en gång.
För många organisationer är det den mest realistiska vägen framåt: behåll det som redan fungerar, lägg till det moderna identitetslagret överst och migrera när verksamheten är redo.
Exempel CSS för inloggningsskärmen för märket
Skärmdumpen ovan använder CSS nedan för att styla FoxIDs inloggningssidan för det fiktiva företaget Northbridge Systems. Det ändrar företagsnamn, färgpalett, sidbakgrund, inloggningskort, inmatningsfokusfärg, knappar, länkar och informationsmeddelandet.
I FoxIDs kan denna CSS läggas till på Login UI-fliken för inloggningsautentiseringsmetoden tillsammans med webbläsarens titel och webbläsarikon.
: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;
}
}