ADFS-federatie met Entra ID-gids

By Mirko Peters · 2026-04-30 · Updated 2026-09-13

Leer hoe AD FS-federatie, SSO, vertrouwensrelaties en beveiliging werken, bekijk vervolgens de migratie van AD FS naar Microsoft Entra ID en de meest voorkomende problemen bij het oplossen van storingen.

Automatically translated with AI from the original post. Read the English original

Federatie met Active Directory Federation Services (AD FS) speelt een centrale rol in de manier waarop moderne organisaties digitale identiteit en single sign-on (SSO) beheren. Naarmate bedrijven groeien en hun behoeften veranderen, vooral met de opkomst van cloudapplicaties en samenwerkingsplatforms, wordt begrip van AD FS steeds belangrijker. Deze gids legt uit wat AD FS doet, hoe het past in het bredere Microsoft-ecosysteem en waarom de overstap naar geavanceerde oplossingen zoals Entra ID en Azure AD het authenticatielandschap in het bedrijfsleven ingrijpend verandert.

Van basisconcepten zoals gefedereerde identiteit tot gedetailleerde migratiestrategieën en beveiligingsbest practices: je krijgt een uitgebreid overzicht van hoe AD FS werkt, plus wat je moet weten als je overstapt naar moderne cloudidentiteit. Of je nu een bestaande opzet aan het oplossen bent of een nieuwe aanpak aan het ontwerpen bent, deze gids helpt je weloverwogen beslissingen te nemen en je authenticatie sterk te houden.

Fundamentele begrippen van Active Directory Federation Services

Active Directory Federation Services (AD FS) staat centraal in de manier waarop veel organisaties verschillende authenticatiesystemen met elkaar verbinden, zeker als je te maken hebt met een allegaartje aan on-premises resources en cloudservices. Het kernidee is eenvoudig: gefedereerde identiteit laat gebruikers applicaties buiten hun eigen omgeving benaderen met hun vertrouwde inloggegevens. Het draait om het slechten van digitale muren tussen organisaties en services, zodat toegang veiliger en soepeler verloopt voor iedereen die erbij betrokken is.

Stel je voor dat je partners, leveranciers of remote teams hebt die aan je systemen moeten werken, maar je wilt niet een hoop extra gebruikersnamen en wachtwoorden uitdelen. AD FS bouwt ‘vertrouwde bruggen’, zodat die gebruikers kunnen inloggen alsof ze gewoon thuis zijn. Het is Microsoft’s antwoord op de oude vraag: hoe deel je resources zonder beveiliging op te geven? Daarbij maakt het gebruik van een flink arsenaal aan technische standaarden zoals SAML en OAuth.

Ben je net begonnen met identiteitsfederatie, of beheer je al jarenlang vertrouwensrelaties tussen domeinen, dan legt dit volgende deel de basis. We kijken naar wat AD FS precies doet, waarom het nog steeds relevant is en hoe het zich heeft ontwikkeld naast de realiteit van cloud en hybride bedrijfsomgevingen. De details komen in de volgende delen, maar onthoud voor nu dat AD FS je startpunt is voor veilige authenticatie over grenzen heen in omgevingen waar veel Microsoft wordt gebruikt.

Wat is Active Directory-federatie en hoe werkt het?

Active Directory Federation Services (AD FS) is een door Microsoft ontwikkelde tool die veilige, naadloze authenticatie mogelijk maakt over organisatie- en domeingrenzen heen. In de kern implementeert AD FS ‘gefedereerde identiteit’. Dat betekent dat je gebruikers toegang kunnen geven tot systemen, apps of services die niet door jouw domein worden beheerd, en dat ze daarvoor gewoon hun normale inloggegevens gebruiken. Niemand hoeft dus een tiental wachtwoorden te onthouden of met meerdere logins te jongleren om zijn werk te kunnen doen.

Hoe werkt dat precies? AD FS gebruikt industriestandaarden zoals SAML (Security Assertion Markup Language) en OAuth om vertrouwensrelaties op te zetten, vaak ‘gefedereerde vertrouwensrelaties’ genoemd, tussen jouw organisatie (de identity provider) en externe applicaties of partners (de relying parties). De truc zit in claimsgebaseerde authenticatie: nadat de gebruiker is geverifieerd, geeft AD FS een ‘beveiligingstoken’ uit met claims, in feite gegevens over de identiteit en rechten van de gebruiker. De doelapplicatie controleert het token en laat de gebruiker binnen als alles klopt.

Vroeger hielp AD FS grote organisaties bij het aanbieden van single sign-on (SSO) voor zowel on-premises applicaties als cloudresources zoals Office 365. Nog voordat cloud-native directories zoals Entra ID mainstream werden, was AD FS de brug die authenticatie soepel liet verlopen, zelfs over bedrijfsgrenzen heen. Vandaag de dag is het een fundamenteel onderdeel van hybride opzetten, ook al kiezen veel organisaties nu voor cloudgebaseerde identiteitsoplossingen voor meer flexibiliteit en beveiliging.

Kerncomponenten van de AD FS-architectuur

• Federation Server: De belangrijkste AD FS-engine die gebruikers authenticeert, claimsgebaseerde tokens uitgeeft en de vertrouwensrelaties met relying parties beheert.
• Web Application Proxy (WAP): Fungeert als gateway en biedt beveiligde proxytoegang voor externe gebruikers. Daarnaast beschermt het de federatieservers tegen directe blootstelling aan internet.
• Claims Provider: Levert gebruikersidentiteitsgegevens, vaak afkomstig uit Active Directory, die worden gebruikt voor het genereren van tokens en het uitgeven van claims.
• Relying Party Trust: Vertegenwoordigt de externe applicaties of systemen die AD FS-tokens gebruiken en valideren. Hier wordt vastgelegd hoe claims worden getransformeerd en welke gebruikers zijn geautoriseerd.
• Domain Controller: Authenticeert gebruikers in Active Directory en bevestigt de inloggegevens voordat een token wordt uitgegeven.

ADFS-authenticatiestromen en federatieve vertrouwensrelaties uitgelegd

Als het gaat om single sign-on en veilige toegang, blinkt AD FS uit doordat authenticatie voor eindgebruikers eenvoudig aanvoelt, ook als de achterkant allesbehalve simpel is. De kern hiervan zit in hoe AD FS authenticatiestromen en federatieve vertrouwensrelaties afhandelt. Het draait om het veilig en efficiënt verplaatsen van inloggegevens, tokens en claims, van het moment dat een gebruiker probeert in te loggen tot het moment dat hij of zij de doelapplicatie of -bron bereikt.

Hier komen de details van protocollen zoals SAML, WS-Federation en OAuth goed tot hun recht. Het proces verloopt snel: gebruikersgegevens worden gevalideerd, claims worden uitgegeven, attributen worden getransformeerd en de juiste tokens worden naar de juiste systemen gestuurd. Federatieve vertrouwensrelaties zorgen er ondertussen voor dat organisaties aan beide kanten van de handdruk erop kunnen vertrouwen wie er binnenkomt.

Hierna brengen we stap voor stap de typische AD FS-authenticatiereis in kaart. Daarna duiken we in hoe een federatieve vertrouwensrelatie wordt ingesteld, zodat twee volledig gescheiden organisaties veilige toegang over bedrijfsgrenzen heen mogelijk kunnen maken zonder daar wakker van te liggen. Deze concepten helpen IT-professionals en securityteams bij alles, van het bouwen van een veilige federatie tot het later oplossen van hardnekkige toegangs- of claimproblemen.

ADFS-authenticatiestromen begrijpen

1. Gebruiker opent applicatie: De gebruiker probeert een gefedereerde applicatie te openen. Is het een externe aanvraag, dan komt die eerst bij de Web Application Proxy terecht. Interne aanvragen gaan rechtstreeks naar AD FS.
2. Authenticatieverzoek verstuurd: De relying party van de applicatie stuurt de browser van de gebruiker door naar de AD FS-server met een authenticatieverzoek, inclusief de bron waartoe de gebruiker toegang wil.
3. Validatie van inloggegevens: AD FS vraagt de gebruiker om in te loggen (met Windows-inloggegevens, formulieren, MFA of certificaat) en controleert die gegevens bij de domain controller van Active Directory.
4. Claims aanmaken: Na een succesvolle validatie maakt AD FS een claims-gebaseerd token aan. Dit token bevat attributen over de gebruiker, zoals gebruikersnaam, groepslidmaatschap of e-mailadres, op basis van vooraf ingestelde regels.
5. Token uitgegeven: Het claimtoken wordt door AD FS veilig ondertekend en teruggestuurd naar de browser van de gebruiker.
6. Applicatie valideert token: De browser geeft het token door aan de doelapplicatie, die de echtheid controleert met behulp van het publieke deel van het certificaat van AD FS.
7. Toegang verleend: Als het token, de claims en de regels allemaal kloppen, laat de applicatie de gebruiker binnen, zonder om nog een wachtwoord te vragen.

Deze stapsgewijze flow werkt voor standaard SSO, of gebruikers nu intern zijn of via een gefedereerde partner binnenkomen. Dezelfde logica geldt voor OAuth (populair bij SaaS-applicaties). Daardoor kan AD FS een breed scala aan authenticatiescenario's en protocollen afhandelen.

Federatieve vertrouwensrelaties tussen organisaties opzetten

Een federatieve vertrouwensrelatie instellen in AD FS betekent dat twee organisaties een relatie aangaan waarin ze elkaars authenticatietokens accepteren. Technisch gezien houdt dit in dat beide kanten zo worden geconfigureerd dat ze de ander herkennen als vertrouwde claims provider of relying party. SSL-certificaten worden uitgewisseld om de communicatie te beveiligen, en er worden aangepaste vertrouwensbeleidsregels ingesteld om te bepalen welke claims worden geaccepteerd en hoe gebruikersidentiteiten worden gekoppeld.

Een correcte vertrouwensinstelling vormt de basis voor veilige, naadloze SSO voor zakelijke partners, leveranciers of dochterondernemingen. Zo ontstaat samenwerking zonder dat het beveiligingsniveau van de organisatie daalt.

Beveiligingsoverwegingen en best practices voor AD FS-implementatie

Zodra het over federatie en SSO gaat, krijgt beveiliging meteen de hoogste prioriteit. Eén datalek of een verkeerd ingestelde vertrouwensrelatie kan namelijk snel grote gevolgen hebben. Met AD FS draait het om het beschermen van de hele tokenuitgifteketen, zorgen dat alleen de juiste mensen zich kunnen aanmelden en aanvallers weghouden van je meest waardevolle resources.

Het dreigingslandschap omvat van credential phishing en tokendiefstal tot denial-of-service-aanvallen en brute force-pogingen. Je hebt sterke verdedigingslinies nodig op elk niveau: van strikte authenticatiebeleidsregels tot versleutelde tokenstromen en van regelmatig patchen tot monitoring in realtime. Dit soort gelaagde beveiliging houdt niet alleen hackers buiten de deur, maar helpt organisaties ook om te voldoen aan eisen op het gebied van audit en governance.

In de volgende secties bespreken we concrete verdedigingsmaatregelen voor AD FS, belichten we de meest voorkomende aanvalsvectoren en de bijbehorende mitigatiestrategieën, en vatten we beproefde best practices samen voor veilige configuratie, doorlopende audits en integratie met bredere beveiligings- en governanceprogramma's. Wil je praktische strategieën voor risicoreductie, inclusief lessen uit Microsoft Entra ID- en Azure-omgevingen, lees dan verder. En wil je weten hoe identiteit, voorwaardelijke toegang en governance in de cloud samenwerken? Bekijk dan deze aflevering over identiteitsbeveiligingsstrategie voor meer diepgaande inzichten.

Tokenuitgifte en authenticatie beveiligen in AD FS

• Handhaaf sterke wachtwoord- en credentialbeleidsregels: Stel complexe wachtwoorden en strikte verlooptermijnen in om het risico op zwakke credentials te verkleinen.
• Schakel multifactorauthenticatie (MFA) in: Voeg een tweede verificatiestap toe (zoals een code op je telefoon of een hardwaretoken) om ongeautoriseerde aanmeldingen te blokkeren, ook als een wachtwoord is gecompromitteerd.
• Gebruik beveiligde, versleutelde tokenkanalen: Vereis SSL/TLS voor alle tokenuitwisselingen en zorg dat tokens zijn ondertekend en versleuteld om manipulatie of afluisteren te voorkomen.
• Beperk de levensduur van tokens: Gebruik kortlevende tokens om het aanvalsvenster te beperken als een token wordt gestolen of opnieuw wordt afgespeeld.

Voor aanvullende context over het voorkomen van aanvallen die zelfs MFA omzeilen, zoals misbruik van OAuth-toestemming, kun je kijken naar deze essentiële maatregelen voor het beveiligen van Entra ID.

Belangrijkste beveiligingsoverwegingen en het beperken van dreigingen

• Credential phishing: Leer gebruikers phishing herkennen en vereis MFA om het inlogmoment te beschermen.
• Replay en tokendiefstal: Gebruik korte tokenlevensduren en continue tokenvalidatie om schade door onderschepte tokens te beperken.
• Denial-of-service (DoS)-aanvallen: Zet AD FS- en proxyservers op in hoogbeschikbare configuraties en beperk de blootstelling aan onbetrouwde netwerken.
• Patchbeheer: Werk alle AD FS- en afhankelijke systemen regelmatig bij om kwetsbaarheden te dichten voordat aanvallers ze misbruiken.
• Auditen en monitoren: Implementeer robuuste logging en monitoring om verdachte activiteit vroegtijdig te signaleren. Voor een bredere zero trust-aanpak, bekijk deze podcastaflevering over Zero Trust.

Best practices voor de implementatie en monitoring van AD FS

• Redundantie en loadbalancing: Zet meerdere federatie- en proxyservers in om single points of failure te voorkomen en grote aantallen gebruikers aan te kunnen.
• Doorlopende monitoring: Gebruik auditlogs, gebeurtenismonitoring en realtime waarschuwingen om verdachte patronen snel te signaleren.
• Regelmatige beveiligingsaudits: Controleer configuraties en vertrouwensrelaties op afwijkingen of hiaten, en blijf op de hoogte van wijzigingen in best practices.
• Integratie met cloudbeveiligingsplatforms: Koppel AD FS-logs en -gebeurtenissen aan SIEM-tools zoals Microsoft Sentinel of Microsoft Purview Audit voor een geïntegreerde risicodetectie en compliancerapportage.
• Levenscyclusbeheer: Werk tokens, certificaten en beleidsinstellingen regelmatig bij om "identiteitsschuld" en technisch risico te minimaliseren.

Beperkingen van AD FS en probleemoplossing in moderne organisaties

Hoewel AD FS in de afgelopen jaren veel organisaties heeft geholpen om systemen en gebruikers met elkaar te verbinden, brengt de technologie al met al een aantal moderne hoofdpijndossiers met zich mee. Als je AD FS-infrastructuur beheert, ken je het riedeltje: er zijn onderhoudskosten, complexe vertrouwensconfiguraties en updates die opduiken op de momenten dat je ze het minst verwacht. Voeg daar snel groeiende cloudomgevingen aan toe en plotseling voelen de oude werkwijzen behoorlijk wankel aan.

De beperkingen zijn niet alleen technisch van aard, ze kunnen ook uitmonden in bedrijfsrisico’s. Denk aan de betrouwbaarheid van authenticatie, hoe eenvoudig je kunt opschalen en hoe snel je kunt inspelen op de volgende SaaS-eis die binnenkomt. Dit zijn de knelpunten die steeds meer teams ertoe aanzetten om naar cloudgebaseerde identiteiten zoals Entra ID te kijken. Maar voordat je een grote stap zet, is het essentieel om te weten waar je op moet letten en wat je moet doen als er in je AD FS-landschap iets misgaat.

Hierna duiken we in de belangrijkste beperkingen die AD FS voor hedendaagse ondernemingen tegenhouden, en lopen we praktische stappen voor probleemoplossing door voor de issues die het vaakst bij je helpdesk terechtkomen. Als je deze basics beheerst, koop je cruciale tijd en krijg je meer vertrouwen, of je nu de boel draaiende houdt of je voorbereidt op een migratie.

Belangrijkste beperkingen van AD FS voor authenticatie in de onderneming

• Hoge onderhoudslast: AD FS-implementaties vragen om voortdurend patchen, monitoring en onderhoud van hardware, wat de operationele kosten opdrijft.
• Beperkte cloudintegratie: Verouderde AD FS kan niet tippen aan de diepe, native integraties met SaaS of cloudnatieve beveiliging die je vindt in Entra ID of Azure AD.
• Complexe configuratie: Het opzetten van scenario’s met meerdere forests of meerdere domeinen levert meer bewegende delen op en meer kansen op verkeerde configuratie.
• Uitdagingen qua schaalbaarheid: Groeiende gebruikersaantallen of wereldwijde toegangsbehoeften vragen vaak om extra servers en geavanceerde netwerkopzetten.

Veelvoorkomende AD FS-problemen oplossen

1. Authenticatiefouten: Controleer de machtigingen van het serviceaccount, de connectiviteit met domeincontrollers en mislukte aanmeldpogingen in de AD FS-gebeurtenislogboeken (Event ID 364 wijst op problemen met tokenuitgifte).
2. Fouten bij tokenuitgifte: Bekijk de claimregels en de certificaatconfiguraties. Niet-overeenkomende of verlopen certificaten zorgen vaak voor storingen.
3. Verkeerd geconfigureerde relying parties: Controleer de eindpunten, vertrouwensrelaties en claimtransformaties voor de juiste koppeling tussen systemen.
4. Accountvergrendelingen of wachtwoordproblemen: Zorg dat wachtwoordsynchronisatie en accountbeleid consistent zijn over forests en domeinen heen.
5. Controleer de AD FS-logs: Gebruik de relevante event-ID’s (zoals 100 voor geslaagde tokenuitgifte of de 300-reeks voor configuratieproblemen) om de hoofdoorzaken snel te achterhalen.

Migreren van AD FS naar Entra ID en de toekomst van federatie

Voor organisaties die met één been in het verouderde AD FS staan en met het andere de cloud in stappen, wordt het pad vooruit steeds duidelijker. Cloudgebaseerde identiteitsoplossingen zoals Azure AD en Entra ID bieden robuuste, flexibele en veiligere authenticatie voor moderne workloads, ook voor die oude, lastige apps die tot nu toe uitsluitend op AD FS vertrouwden. De sector beweegt er met reden naartoe: minder hardwarelast, eenvoudiger vertrouwensmodellen en beveiliging die is opgebouwd om zich ontwikkelende dreigingen en compliance-eisen het hoofd te bieden.

Overstappen van AD FS is echter geen kwestie van één knop omzetten. Migreren naar Entra ID (de nieuwe merkparaplu voor Microsoft-identiteitsdiensten) betekent dat je vertrouwensrelaties, applicatie-integraties en de manier waarop beleid zoals voorwaardelijke toegang en governance in de nieuwe situatie werkt, opnieuw moet bekijken. Doe je dat goed, dan krijg je meer gebruikerstevredenheid en sterkere, consistentere controles over cloud- en on-premises systemen heen.

Hieronder vind je een directe vergelijking van AD FS met cloudidentiteit, plus beproefde strategieën voor een gefaseerde overgang die gebruikers niet ontwricht en geen nieuwe beveiligingslekken opent. Als je een idee wilt krijgen van de risico- en governance-uitdagingen die bij voorwaardelijke toegang in Entra ID komen kijken, is deze diepgaande analyse van identity security loops ook een goed startpunt.

AD FS versus cloudgebaseerde identiteit met Azure AD en Entra ID

• Beperkingen van AD FS: on-premises hardwarevereisten, patchen, complex beheer van vertrouwensrelaties en claimregels, beperkte native integratie met cloud/SaaS, en een trage reactie op nieuwe beveiligingsdreigingen.
• Voordelen van Azure AD en Entra ID: Native integratie met Microsoft 365, eenvoudiger instellen, ingebouwde voorwaardelijke toegang, snelle onboarding van SaaS-applicaties, consistent afdwingen van beleid en verbeterde identiteitsbescherming voor cloudworkloads.
• Strategische drijfveren voor migratie: Lagere onderhoudskosten, gestroomlijnd beheer, schaalbare toegang en op beleid gebaseerde beveiligingsmodellen die meegroeien met het bedrijf.

Meer over hoe opgehoopte uitzonderingen en machtigingen ‘identiteitsschuld’ creëren en hoe goed governance in Entra ID de beveiliging van cloudidentiteiten verandert, lees je in deze podcast over identiteit als controlevlak.

Migratiestrategieën voor een naadloze overgang van AD FS naar Entra ID

• Inventarisatie: Breng alle relying party trusts, claimregels en geïntegreerde applicaties die aan AD FS gekoppeld zijn in kaart; breng de afhankelijkheden in beeld en bepaal welke workloads klaar zijn voor migratie.
• Planning: Ontwerp een gefaseerd migratieplan, richt Entra ID in en valideer de cloudconnectors voor hybride coëxistentie als dat nodig is.
• Coëxistentie: Laat AD FS naast Entra ID draaien, verplaats applicaties stap voor stap naar authenticatie via Azure AD en houd de gebruikerservaring en toegangslogboeken in de gaten.
• Overschakeling: Migreer gebruikers en de laatste workloads naar Entra ID, verwijder de oude trusts en aangepaste regels en haal de on-premises AD FS-infrastructuur uit de running zodra de validatie is afgerond.
• Afstelling na migratie: Controleer voorwaardelijke toegangsbeleid, gebruikersprovisioning en rapportage in Entra ID om de cirkel rond te maken en je identiteitspraktijken toekomstbestendig te maken.

Luister ook naar deze afleveringen

Ben je aan het onderzoeken hoe ADFS-federatie met Entra ID werkt? Dan geven deze afleveringen praktische context over architectuur, beveiliging, governance en implementatie:

• Microsoft AI Agent Harness – Simply Explained — Begrijp orkestratie, guardrails, evaluatie en betrouwbare AI-workflows.
• Microsoft Defender XDR – Simply Explained — Verbind identiteits- en AI-beslissingen met security-monitoring en respons.
• Microsoft Teams Governance – The Illusion of Control — Leer hoe governance, eigenaarschap en beleid operationeel risico verlagen.
• Azure Virtual Network – Simply Explained — Begrijp de architectuurcontext achter cloudconnectiviteit.