Active Directory er stadig det autoritative brugerkatalog i mange organisationer. Brugere, adgangskoder og gruppemedlemskaber findes ofte allerede dér og har i mange tilfælde gjort det i årevis.
Moderne applikationer forventer imidlertid ofte moderne føderationsprotokoller og stærkere autentifikationsmuligheder.
Nye webapplikationer, SaaS-platforme og kundeportaler understøtter ofte OpenID Connect eller SAML 2.0. De forventer moderne tokens, claims, føderationsmetadata, single sign-on flows og nogle gange step-up autentifikation med MFA.
Det skaber en velkendt udfordring: Hvordan moderniserer man autentifikationen uden at erstatte Active Directory fra første dag?
Her er FoxIDs Directory Connector for Active Directory nyttig. Organisationen kan beholde Active Directory som kilde til brugere, adgangskoder og gruppemedlemskaber, mens FoxIDs tilføjer et moderne identitetslag ovenpå.
Brugerne kan fortsat logge ind med deres eksisterende Active Directory legitimationsoplysninger. Applikationer kan integrere med FoxIDs via OpenID Connect eller SAML 2.0. FoxIDs kan samtidig tilføje claims, roller, multi-factor authentication og en brandtilpasset loginoplevelse omkring det eksisterende katalog.
Active Directory kan blive, hvor det er
Mange organisationer ønsker ikke en big-bang migration væk fra Active Directory. De har blot brug for, at deres eksisterende katalog fungerer sammen med moderne applikationer.
Med Directory Connector for Active Directory forbinder FoxIDs til en komponent, der installeres i kundens Windows-miljø tæt på domænecontrollerne. FoxIDs kalder connectoren via HTTPS, og connectoren validerer brugere, håndterer adgangskodeoperationer og returnerer udvalgte brugeregenskaber og claims fra Active Directory.
Det vigtige er, at Active Directory forbliver autoritativt.
Det betyder, at adgangskoder fortsat kan valideres af AD. Eksisterende adgangskodepolitikker kan fortsat gælde, brugerne kan administreres i det velkendte katalog, og gruppemedlemskaber kan styres gennem de eksisterende IT-processer.
FoxIDs bliver dermed det moderne identitetslag foran AD.
I stedet for at forbinde hver applikation direkte til Active Directory eller LDAP forbindes applikationerne med FoxIDs. FoxIDs håndterer føderationsprotokollen, udstedelse af tokens, claims og autentifikationsflowet, mens AD fortsat er det underliggende katalog.
Det giver organisationen et praktisk migrationsforløb. Brugerne kan i første omgang blive i Active Directory og senere flyttes til FoxIDs, når det giver mening. Overgangen behøver ikke ske på én gang.
OIDC og SAML 2.0 til eksisterende AD-brugere
Den centrale værdi er enkel: Eksisterende Active Directory brugere kan logge ind i moderne OpenID Connect og SAML 2.0 applikationer gennem FoxIDs.
For OpenID Connect applikationer fungerer FoxIDs som OpenID Provider. Applikationerne kan bruge discovery, autentifikation, logout og UserInfo endpointet. FoxIDs understøtter også PKCE og forskellige muligheder for klientautentifikation.
For SAML 2.0 applikationer kan FoxIDs udstede SAML assertions og fungere som identitetsudbyder for applikationer, der er afhængige af SAML-baseret enterprise single sign-on.
Det er nyttigt, når en organisation har flere typer applikationer. Én applikation bruger måske OpenID Connect, en anden kræver fortsat SAML 2.0, og en tredje får senere brug for OAuth 2.0 access tokens til API'er.
Brugerne kan fortsat være de samme AD-brugere.
Dermed undgår organisationen at skulle duplikere brugere, bygge særlige LDAP-integrationer eller migrere identiteter, før den første moderne applikation kan gå i produktion.
FoxIDs kan i stedet bygge bro mellem det eksisterende katalog og de protokoller, som moderne applikationer forventer.
Brug AD-grupper som moderne applikationsclaims
Autentifikation er kun en del af løsningen. Applikationer skal også vide, hvem brugeren er, og hvad brugeren har adgang til.
Active Directory indeholder ofte allerede disse oplysninger gennem gruppemedlemskaber. En bruger kan eksempelvis være medlem af grupperne Employees, Administrators, Finance eller Customer Support.
Directory Connector kan returnere konfigurerede AD-attributter som claims og konfigurerede AD-gruppemedlemskaber som claims. Gruppeclaims returneres ofte som rolleclaims, og indlejrede grupper kan medtages.
Det gør det muligt at bruge eksisterende AD-gruppestrukturer i moderne applikationer.
En AD-gruppe som Employees kan eksempelvis returneres som et rolleclaim med værdien Employees. Applikationen behøver ikke forstå LDAP eller forespørge Active Directory direkte. Den skal blot læse de claims, som FoxIDs udsteder.
Skærmbilledet nedenfor viser en Active Directory bruger, der er medlem af gruppen Employees. Det er det eksisterende gruppemedlemskab, som allerede administreres i Active Directory.
Når brugeren logger ind gennem FoxIDs, kan AD-gruppemedlemskabet medtages som et rolleclaim i det udstedte applikationstoken. I dette eksempel returneres gruppen Employees som et rolleclaim.
Applikationen behøver ikke forespørge Active Directory direkte. Den skal blot læse de claims, som FoxIDs udsteder.
Det giver en klar ansvarsfordeling.
Active Directory er fortsat stedet, hvor medlemskaber administreres. FoxIDs omsætter katalogoplysningerne til moderne identitetsclaims. Applikationen modtager resultatet gennem den protokol, den allerede understøtter.
Tilføj MFA oven på Active Directory login
En væsentlig fordel ved at bruge FoxIDs foran Active Directory er, at login kan styrkes uden at erstatte kataloget.
FoxIDs understøtter både enkel to-faktor-autentifikation og avanceret multi-factor authentication i loginmetoden. De indbyggede faktorer omfatter SMS-kode, e-mailkode, kode fra authenticator-app og gendannelseskode. FoxIDs kan også bruge andre autentificeringsmetoder, eksempelvis OIDC eller SAML 2.0, som MFA-trin.
MFA kan kræves på flere måder.
Det kan aktiveres for udvalgte brugere eller kræves på loginmetoden. En applikation kan også anmode om MFA efter behov. Med OpenID Connect kan applikationen anmode om MFA med acr_values=urn:foxids:mfa. Med SAML 2.0 kan MFA anmodes gennem authentication context.
Det er værdifuldt, fordi ikke alle applikationer kræver samme sikkerhedsniveau hele tiden.
En almindelig intern applikation har måske kun brug for brugernavn og adgangskode. En følsom administrationsportal kan kræve MFA hver gang, mens en anden applikation kun anmoder om MFA ved bestemte handlinger eller sessioner med højere risiko.
FoxIDs kan understøtte denne type step-up model, samtidig med at den første faktor fortsat valideres mod Active Directory.
I praksis kan organisationen beholde AD som kilde til brugere og adgangskoder og samtidig tilføje moderne sikkerhedskontroller omkring loginoplevelsen.
Et bedre migrationsforløb
Udskiftning af et identitetskatalog er sjældent kun en teknisk beslutning. Det påvirker brugere, applikationer, IT-drift, sikkerhedspolitikker og supportprocesser.
Derfor er et gradvist forløb vigtigt.
Med FoxIDs kan en organisation begynde med at forbinde Active Directory og lade brugerne logge ind med deres eksisterende legitimationsoplysninger. FoxIDs kan vedligeholde en intern brugerpost med identifikatorer, egenskaber, claims, MFA-indstillinger og adgangstildelinger, mens det eksterne katalog forbliver autoritativt for validering og ændring af adgangskoder.
Hvis organisationen senere vil flytte brugerne helt til FoxIDs, findes der et forløb til det.
Det er især nyttigt for organisationer, der først vil modernisere autentifikationen og senere træffe beslutning om brugermigrering. Det hjælper også, når forskellige brugergrupper flyttes i forskelligt tempo. Medarbejdere kan blive i AD, eksterne brugere kan allerede findes i FoxIDs, nye applikationer kan bruge OIDC, og ældre virksomhedsapplikationer kan bruge SAML 2.0.
FoxIDs kan placeres imellem systemerne og få dem til at fungere sammen.
En brandtilpasset loginoplevelse
Moderne autentifikation handler ikke kun om protokoller og sikkerhed. Brugeroplevelsen er også vigtig.
Når brugerne omdirigeres til login, skal siden se genkendelig og troværdig ud. FoxIDs understøtter tilpasning af loginoplevelsen, inklusive browsertitel, browserikon og CSS. Det samme loginflow kan også føre brugerne gennem multi-factor authentication, når der kræves stærkere sikkerhed.
Det er nyttigt i både interne og kundevendte scenarier.
Et medarbejderlogin kan bruge organisationens navn og stil og samtidig tilføje MFA oven på det eksisterende Active Directory brugernavn og den eksisterende adgangskode. En kundeportal kan bruge kundens brand, og en partnerapplikation kan få en tilpasset loginoplevelse uden at ændre den underliggende AD-integration.
Eksemplet nedenfor viser en brandtilpasset MFA loginskærm for den fiktive virksomhed Northbridge Systems. Brugeren logger ind med en eksisterende konto og bliver derefter bedt om at gennemføre SMS to-faktor-autentifikation i FoxIDs.
Den fulde CSS til eksemplet findes sidst i artiklen.
Resultatet er et mere komplet identitetslag med moderne protokoller, AD-baserede brugere, claims, MFA og et brandtilpasset loginflow.
Kom godt i gang
Det kræver ikke, at alle applikationer eller brugere migreres, før man kan komme i gang.
Et typisk første skridt er at installere Directory Connector for Active Directory i det Windows-miljø, hvor den kan nå domænecontrollerne. Derefter kan FoxIDs validere brugere gennem connectoren og udstede moderne OpenID Connect eller SAML 2.0 svar til applikationerne.
Opsætningen bliver derefter en trinvis proces. Begynd med én applikation, map de AD-attributter og gruppemedlemskaber, som applikationen har brug for, beslut om MFA skal kræves, og tilpas eventuelt loginoplevelsen.
Når den første applikation fungerer, kan samme mønster genbruges til flere applikationer. Nogle bruger måske OpenID Connect, andre SAML 2.0, og følsomme applikationer kan kræve MFA efter behov.
De detaljerede konfigurationstrin findes i dokumentationen til FoxIDs Directory Connector for Active Directory.
Konklusion
Active Directory er stadig centralt i mange organisationer, men moderne applikationer kræver moderne autentifikation.
FoxIDs Directory Connector for Active Directory gør det muligt at beholde eksisterende AD-brugere, adgangskoder og grupper og samtidig aktivere OpenID Connect, SAML 2.0, claims og MFA gennem FoxIDs.
Det giver organisationer en praktisk måde at modernisere autentifikationen, forbedre sikkerheden og understøtte nye applikationer uden at udskifte alt på én gang.
For mange organisationer er det det mest realistiske forløb: Bevar det, der allerede fungerer, tilføj det moderne identitetslag ovenpå, og migrér, når organisationen er klar.
Eksempel på CSS til den brandtilpassede loginskærm
Skærmbilledet ovenfor bruger nedenstående CSS til at tilpasse FoxIDs login siden for den fiktive virksomhed Northbridge Systems. Den ændrer virksomhedsnavn, farvepalette, sidebaggrund, loginkort, fokusfarve i inputfelter, knapper, links og informationsmeddelelsen.
I FoxIDs kan CSS'en tilføjes på fanen Login UI på loginmetoden sammen med browsertitel og browserikon.
: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;
}
}