Active Directory er fortsatt den autoritative brukerkatalogen i mange organisasjoner. Brukere, passord og gruppemedlemskap bor ofte der allerede, og i mange tilfeller har de gjort det i årevis.
Men moderne applikasjoner forventer ofte moderne føderasjonsprotokoller og sterkere autentiseringsalternativer.
Nye nettapplikasjoner, SaaS-plattformer og kundevendte portaler støtter ofte OpenID Connect eller SAML 2.0. De forventer moderne tokens, claims, føderasjonsmetadata, enkeltpåloggingsflyter og noen ganger økt autentisering med MFA.
Det skaper en felles utfordring: hvordan moderniserer du autentisering uten å erstatte Active Directory fra dag én?
Det er her FoxIDs Directory Connector for Active Directory blir nyttig. Den lar organisasjoner beholde Active Directory som kilden til brukere, passord og gruppemedlemskap, mens FoxIDs legger det moderne identitetslaget på toppen.
Brukere kan fortsatt logge på med sin eksisterende Active Directory-legitimasjon. Applikasjoner kan integreres med FoxIDs ved å bruke OpenID Connect eller SAML 2.0. Og FoxIDs kan legge til claims, roller, multifaktorautentisering og en merkevarepåloggingsopplevelse rundt den eksisterende katalogen.
Active Directory kan bli der den er
Mange organisasjoner er ikke ute etter en big-bang-migrering bort fra Active Directory. De trenger ganske enkelt å få deres eksisterende katalog til å fungere med moderne applikasjoner.
Med Directory Connector for Active Directory, kobles FoxIDs til en komponent installert inne i kundens Windows-miljø, nær domenekontrollerne. FoxIDs kaller koblingen over HTTPS, og koblingen validerer brukere, håndterer passordoperasjoner og returnerer utvalgte brukeregenskaper og claims fra Active Directory.
Den viktige delen er at Active Directory forblir autoritativ.
Det betyr at passord fortsatt kan valideres av AD. Eksisterende passordpolicyer kan fortsatt gjelde. Brukere kan fortsatt administreres i den kjente katalogen. Og gruppemedlemskap kan fortsatt kontrolleres av eksisterende IT-prosesser.
FoxIDs blir da det moderne identitetslaget foran AD.
I stedet for å koble hver applikasjon direkte til Active Directory eller LDAP, kobler applikasjoner til FoxIDs. FoxIDs håndterer føderasjonsprotokollen, tokenutstedelse, claims og autentiseringsflyt, mens AD forblir den underliggende katalogen.
Dette gir organisasjoner en praktisk migrasjonsvei. De kan starte med å holde brukere i Active Directory og senere flytte brukere til FoxIDs når det er fornuftig. Overgangen trenger ikke skje på en gang.
OIDC og SAML 2.0 for eksisterende AD-brukere
Hovedverdien er enkel: eksisterende Active Directory-brukere kan logge på moderne OpenID Connect og SAML 2.0-applikasjoner] gjennom FoxIDs.
For OpenID Connect applikasjoner fungerer FoxIDs som OpenID-leverandøren. Applikasjoner kan bruke oppdagelse, autentisering, utlogging og UserInfo-endepunktet. FoxIDs støtter også PKCE og forskjellige klientautentiseringsalternativer.
For SAML 2.0 applikasjoner kan FoxIDs utstede SAML-påstander og fungere som identitetsleverandør for applikasjoner som er avhengige av SAML-basert enterprise single sign-on.
Dette er nyttig når en organisasjon har en blanding av applikasjonstyper. En applikasjon kan bruke OpenID Connect. En annen kan fortsatt kreve SAML 2.0. En tredje kan senere trenge OAuth 2.0 tilgangstokener for APIer.
Brukerne kan fortsatt være de samme AD-brukerne.
Dette unngår en situasjon der organisasjonen må duplisere brukere, bygge tilpassede LDAP-integrasjoner eller migrere identiteter før den første moderne applikasjonen kan gå live.
I stedet kan FoxIDs bygge bro mellom den eksisterende katalogen og protokollene moderne applikasjoner forventer.
Bruk AD-grupper som moderne applikasjoner claims
Autentisering er bare en del av historien. Applikasjoner må også vite hvem brukeren er og hva de har tilgang til.
Active Directory inneholder ofte allerede denne informasjonen gjennom gruppemedlemskap. En bruker kan være medlem av en medarbeidergruppe, en administratorgruppe, en økonomigruppe eller en kundestøttegruppe.
Directory Connector kan returnere konfigurerte AD-attributter som claims og konfigurerte AD-gruppemedlemskap som claims. gruppeclaims returneres vanligvis som rolleclaims, og nestede grupper kan inkluderes.
Dette gjør det mulig å bruke eksisterende AD-gruppestrukturer i moderne applikasjoner.
For eksempel kan en AD-gruppe som Employees returneres som et rolleclaims med verdien Employees. Applikasjonen trenger ikke å forstå LDAP eller spørre Active Directory direkte. Den trenger bare å lese claimsene utstedt av FoxIDs.
Skjermbildet nedenfor viser en Active Directory-bruker som er medlem av Ansatte-gruppen. Dette er det eksisterende gruppemedlemskapet som allerede er administrert i Active Directory.
Når brukeren logger på gjennom FoxIDs, kan AD-gruppemedlemskapet inkluderes som et rolleclaims i det utstedte applikasjonstokenet. I dette eksemplet returneres Ansatte-gruppen som et rolleclaims.
Applikasjonen trenger ikke å spørre Active Directory direkte. Den trenger bare å lese claimsene utstedt av FoxIDs.
Det er en ren fordeling av ansvar.
Active Directory forblir stedet der medlemskap administreres. FoxIDs forvandler denne kataloginformasjonen til moderne identitetsclaims. Applikasjonen mottar resultatet i protokollen den allerede støtter.
Legg til MFA på toppen av Active Directory pålogging
En stor fordel med å bruke FoxIDs foran Active Directory er at påloggingen kan styrkes uten å erstatte katalogen.
FoxIDs støtter både enkel tofaktorautentisering og avansert multifaktorautentisering i påloggingsautentiseringsmetoden. Støttede innebygde faktorer inkluderer SMS-kode, e-postkode, autentiseringsappkode og gjenopprettingskode. FoxIDs kan også bruke andre autentiseringsmetoder, for eksempel OIDC eller SAML 2.0, som MFA-trinn.
MFA kan kreves på flere måter.
Det kan aktiveres for utvalgte brukere. Det kan kreves på innloggingsautentiseringsmetoden. Eller en applikasjon kan be om MFA ved behov. For OpenID Connect kan applikasjonen be om MFA med acr_values=urn:foxids:mfa. For SAML 2.0 kan MFA forespørres gjennom autentiseringskonteksten.
Dette er verdifullt fordi ikke alle applikasjoner trenger samme grad av sikkerhet hele tiden.
En vanlig intern applikasjon trenger kanskje bare brukernavn og passord. En sensitiv adminportal kan kreve MFA hver gang. En annen applikasjon kan bare be om MFA for spesifikke handlinger eller økter med høyere risiko.
FoxIDs kan støtte den typen step-up-modell mens den første faktoren fortsatt er validert mot Active Directory.
I praksis betyr dette at organisasjoner kan beholde AD som bruker- og passordkilde mens de legger til moderne sikkerhetskontroller rundt påloggingsopplevelsen.
En bedre migrasjonsvei
Å erstatte en identitetskatalog er sjelden bare en teknisk avgjørelse. Det påvirker brukere, applikasjoner, IT-drift, sikkerhetspolicyer og støtteprosesser.
Det er derfor en gradvis vei er viktig.
Med FoxIDs kan en organisasjon starte med å koble til Active Directory og la brukere logge på med sin eksisterende legitimasjon. FoxIDs kan føre en intern brukerpost med identifikatorer, egenskaper, claims, MFA-innstillinger og tilgangstilordninger, mens den eksterne katalogen forblir autoritativ for passordvalidering og passordendringer.
Senere, hvis organisasjonen ønsker å flytte brukere fullt ut til FoxIDs, har den en vei for å gjøre det.
Dette er spesielt nyttig for organisasjoner som ønsker å modernisere autentisering først og bestemme seg for brukermigrering senere. Det hjelper også når ulike brukergrupper beveger seg med ulik hastighet. Ansatte kan bli i AD. Eksterne brukere kan allerede bo i FoxIDs. Nye applikasjoner kan bruke OIDC. Eldre bedriftsapplikasjoner kan bruke SAML 2.0.
FoxIDs kan sitte i midten og få disse verdenene til å fungere sammen.
En merket påloggingsopplevelse
Moderne autentisering handler ikke bare om protokoller og sikkerhet. Brukeropplevelsen har også betydning.
Når brukere blir omdirigert til å logge på, skal påloggingssiden se kjent og pålitelig ut. FoxIDs støtter tilpasning av påloggingsopplevelsen, inkludert nettlesertittel, nettleserikon og CSS. Den samme påloggingsflyten kan også veilede brukere gjennom multifaktorautentisering når sterkere sikkerhet kreves.
Dette er nyttig for både interne og kundevendte scenarier.
En medarbeiderpålogging kan bruke organisasjonens navn og stil samtidig som den legger til MFA på toppen av det eksisterende Active Directory brukernavnet og passordet. En kundeportal kan bruke kundens merkevare. En partnervendt applikasjon kan ha en skreddersydd påloggingsopplevelse uten å endre den underliggende AD-integrasjonen.
Eksemplet nedenfor viser en merkevare MFA påloggingsskjerm for et fiktivt selskap, Northbridge Systems. Brukeren logger på med en eksisterende konto og blir deretter bedt om å fullføre SMS tofaktorautentisering i FoxIDs.
Den fullstendige CSS som brukes i dette eksemplet er inkludert på slutten av artikkelen.
Resultatet er et mer komplett identitetslag: moderne protokoller, AD-støttede brukere, claims, MFA og en merkevarepåloggingsflyt.
Komme i gang
Å komme i gang krever ikke at alle programmer eller brukere migreres.
Et typisk første trinn er å installere Directory Connector for Active Directory i Windows-miljøet der den kan nå domenekontrollerne. Derfra kan FoxIDs validere brukere gjennom kontakten og gi moderne OpenID Connect eller SAML 2.0 svar til applikasjoner.
Oppsettet blir da en inkrementell prosess. Start med én applikasjon, kartlegg AD-attributtene og gruppemedlemskapene som applikasjonen trenger, avgjør om MFA skal kreves, og eventuelt customise påloggingsopplevelsen.
Når den første applikasjonen fungerer, kan det samme mønsteret brukes på nytt for flere applikasjoner. Noen kan bruke OpenID Connect, andre kan bruke SAML 2.0, og sensitive applikasjoner kan kreve MFA ved behov.
For detaljerte konfigurasjonstrinn, se FoxIDs Directory Connector for Active Directory dokumentasjon.
Konklusjon
Active Directory er fortsatt sentral for mange organisasjoner, men moderne applikasjoner trenger moderne autentisering.
FoxIDs Directory Connector for Active Directory gjør det mulig å beholde eksisterende AD-brukere, passord og grupper samtidig som den aktiverer OpenID Connect, SAML 2.0, claims og MFA gjennom FoxIDs.
Det gir organisasjoner en praktisk måte å modernisere autentisering, forbedre sikkerheten og støtte nye applikasjoner uten å erstatte alt på en gang.
For mange organisasjoner er det den mest realistiske veien videre: behold det som allerede fungerer, legg det moderne identitetslaget på toppen, og migrér når virksomheten er klar.
Eksempel CSS for merkevarepåloggingsskjermen
Skjermbildet ovenfor bruker CSS nedenfor for å style FoxIDs påloggingssiden for det fiktive selskapet Northbridge Systems. Den endrer firmanavn, fargepalett, sidebakgrunn, påloggingskort, inndatafokusfarge, knapper, lenker og informasjonsmeldingen.
I FoxIDs kan denne CSS legges til på Login UI-fanen for påloggingsautentiseringsmetoden sammen med nettlesertittelen og nettleserikonet.
: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;
}
}