Inleiding

Welkom bij het negende deel van onze serie over Identiteits- en Toegangsbeveiliging. In de vorige blogs behandelden we onder meer Defender for Identity en Entra ID Protection. Dit keer richten we onze aandacht op een facet dat nog steeds een van de meest voorkomende pijnpunten in cybersecurity is: het wachtwoord. Hoewel veel organisaties inmiddels inzetten op Multi-Factor Authentication (MFA) en zelfs passwordless methoden, blijft het wachtwoord vaak een onmisbaar element binnen hybride en on-premises omgevingen.

We leven in 2025, en toch zien we nog steeds dat slechte wachtwoorden, hergebruik van inloggegevens en simpele dictionary-aanvallen tot grote datalekken kunnen leiden. Waar het ooit volstond om te vragen om “minimaal 8 tekens en een cijfer”, maakt Microsoft nu gebruik van smart password policies en password protection-mechanismen. Met banned passwords, real-time check van nieuwe wachtwoordaanvragen en Azure AD/Entra ID-integratie, kun je jouw aanvalsoppervlak aanzienlijk verkleinen.

In deze blog gaan we in op:

1. Het principe van “banned passwords” en hoe dit gebruikers dwingt om veilige(re) wachtwoorden te kiezen.
2. De integratie met Azure AD/Entra ID en de meerwaarde voor hybride omgevingen.
3. Praktische tips voor het optimaliseren van wachtwoordbeleid, inclusief best practices en PowerShell-voorbeelden, zodat ook techneuten direct aan de slag kunnen.

We hebben opnieuw als doel om een semi-technische, maar diepgaande blog te schrijven, zonder al te veel jargon maar mét voldoende detail. Laten we beginnen!

1. Banned passwords: wat is het en waarom is het belangrijk?

1.1 De zwakte van traditionele wachtwoordpolicies

Traditioneel had je in on-premises Active Directory een Group Policy Object (GPO) waarmee je wachtwoordcomplexiteitsregels kon instellen (minimaal 8 tekens, hoofdletter, cijfer en speciaal teken). Dat bleek in de praktijk niet zo effectief, omdat veel gebruikers clichématige variaties bedenken, zoals “Welkom!123” of “Passw0rd!”. Dit zijn patronen die cybercriminelen maar al te goed kennen. Bovendien vereisten sommige organisaties periodieke wachtwoordvervaldata, wat gebruikers vaak verleidde tot het cyclisch incrementeren van een cijfer: “Welkom!123” wordt dan “Welkom!124” en ga zo maar door.

Kortom, de “klassieke” AD-wachtwoordregels bieden niet genoeg weerstand tegen de geavanceerde aanvalsmethodes van nu. Denk aan woordenlijstaanvallen, credential stuffing (aanvallen met eerder gelekte combinaties van e-mail en wachtwoord) en moderne brute force-technieken die razendsnel talloze variaties doorlopen.

1.2 Banned passwords in Microsoft 365 en Entra ID

Banned passwords zijn wachtwoorden die expliciet niet toegestaan zijn in je omgeving. Microsoft onderhoudt zelf een dynamische lijst van deze ‘verboden woorden’, gebaseerd op de meest voorkomende zwakke wachtwoorden en termen die wereldwijd circuleren in databestanden van gelekte credentials. Deze lijst wordt continu geüpdatet, mede op basis van wat de AI-modellen van Microsoft 365 Defender en Entra ID Protection oppikken over actuele trends.

Denk bijvoorbeeld aan:

• Veelvoorkomende (Engelse) woorden (“password”, “qwerty”, “abc123”).
• Namen van seizoenen en maanden (“Summer2025”, “Winter2025”).
• Sportteams, filmtitels en popculturele referenties die in top-lijstjes voorkomen (“StarWars123”).
• Regionale varianten (“Welkom1”, “Welkom2025!”).

Op het moment dat een gebruiker een nieuw wachtwoord wil instellen (bijvoorbeeld omdat het oude is verlopen of omdat hij die zelf wil wijzigen), doet Microsoft een check in de cloud of het nieuwe wachtwoord voorkomt in de banned-lijst of sterk lijkt op een ban. Als dat zo is, wijst het systeem dit wachtwoord direct af en moet de gebruiker iets sterkers kiezen.

1.3 Real-time checks met de cloud

Het krachtige van Microsofts benadering is dat de check real-time in de cloud gebeurt. Zo kun je in on-premises AD een minimale complexiteitsregel hebben, maar zodra een gebruiker synchroniseert met Entra ID (Azure AD), zal die extra cloud intelligence op de achtergrond zorgen dat simpele of bekende wachtwoorden gewoon niet worden geaccepteerd. Dit is dus anders dan alleen de statische AD-Complexiteitsregel.

Op deze manier bespaar je je helpdesk talloze reset-acties achteraf, want de gebruiker kan simpelweg niet eens “Passw0rd!” kiezen. Het systeem geeft (optioneel) een melding als “Het wachtwoord dat je gekozen hebt is te zwak of staat op de banned list; kies een veiliger wachtwoord.” Dat scheelt frustratie op de lange termijn én verkleint je aanvalsoppervlak direct.

2. Hoe werkt Azure AD/Entra ID Password Protection?

2.1 Cloud-only scenario

In een cloud-only scenario (dus zonder on-prem AD), is het vrij eenvoudig:

1. Azure AD (ook wel Entra ID) heeft standaard het concept van smart password protection. Als je een licentie hebt voor Azure AD Premium (P1 of P2), kun je de “banned password”-functionaliteit configureren.
2. Gebruikers die hun wachtwoord wijzigen via de portal (portal.office.com) of via self-service password reset (SSPR), worden automatisch gevalideerd tegen de dynamische lijst.
3. Je kunt ook custom banned-woorden toevoegen (bijv. je bedrijfsnaam, productnamen of veelvoorkomende variaties). In de Entra ID-portal configureer je dit onder Security > Authentication methods > Password protection.

2.2 Hybride scenario (on-prem + cloud)

De meeste organisaties in 2025 zitten in een hybride modus: ze hebben nog on-premises AD, maar synchroniseren accounts met Entra ID. Voor hen is Microsoft Azure AD Password Protection for On-premises (onderdeel van de bredere Entra ID/AD Premium) interessant. Het werkt als volgt:

1. Password Protection proxy service: je installeert een proxy en filter agent in je on-prem omgeving.
2. Registratie: deze agents registreren zich bij je Azure AD-tenant.
3. Realtime policy downloads: de on-prem agent downloadt de banned-lijst en andere configuraties vanuit Azure AD.
4. Intercept: als een gebruiker op een on-prem Domain Controller zijn wachtwoord wijzigt (via Ctrl+Alt+Del of via kinit in Linux-AD-omgevingen), controleert de filter agent de nieuwe passphrase tegen de cloud policy.
5. Deny: als het wachtwoord in de banned-lijst staat (of er sterk op lijkt), wordt het geweigerd. Anders wordt het doorgezet.

Hiermee kun je dus je bestaande on-prem AD-wachtwoordregels vervangen of aanvullen met cloud intelligence. Zo is je lokale AD net zo beschermd tegen zwakke wachtwoorden als een cloud-only tenant.

3. Minimaliseren van het aanvalsoppervlak: voorbij alleen wachtwoorden

3.1 Waarom is dit zo belangrijk?

Mensen denken soms: “Oké, ik heb MFA. Dan maakt een zwak wachtwoord niet zoveel uit.” Maar:

• Je kunt niet garanderen dat alle services en scenario’s MFA afdwingen. Denk aan oudere protocollen, RDP-sessies of legacy API’s die geen MFA ondersteunen.
• Een goede basis van een sterk wachtwoord + MFA is dubbel zo krachtig.
• Een gecompromitteerd wachtwoord kan leiden tot offline password cracking, laten we zeggen dat een hash buitgemaakt is. Als dat wachtwoord extreem zwak is, is die hash zo gekraakt.
• Er zijn scenario’s waarin MFA door “phishing van de MFA-prompt” of door geavanceerde ‘token replay’-technieken omzeild kan worden. Een sterk wachtwoord maakt het de aanvaller toch lastiger.

Een proactieve wachtwoordbescherming verkleint dus het aanvalsoppervlak aanzienlijk.

3.2 Andere technieken: Windows Hello for Business en passwordless

Microsoft zet zelf natuurlijk ook in op passwordless methodes, zoals Windows Hello for Business (met biometrie of PIN), FIDO2-security keys of de Microsoft Authenticator-app. Toch heb je in een hybride scenario bijna altijd nog gebruikers die af en toe hun password moeten resetten of accounts die nog niet volledig passwordless zijn. In die “mix” is password protection een onmisbare brug.

3.3 GPO’s en fine-tuning

In 2025 zien we nog steeds dat veel beheerders GPO’s gebruiken voor “Password must be at least 14 characters long” en “Require complex characters”. Prima, maar combineer dit met Azure AD Password Protection, zodat je niet alleen op statische regels vertrouwt. Best practice is om in AD:

• Minimum length op 12 of hoger te zetten.
• Password expiration (als je dat nog gebruikt) niet te kort in te stellen, want dat leidt tot slechte praktijken. Microsoft adviseert tegenwoordig om te werken met ‘no expiry’ en wél continue monitoring (en bannen).
• Don’t store LAN Manager hash: Zorg dat LM-hashes volledig uitgeschakeld zijn (een ouderwetse, zwakke hashmethode).
• Use unique SALT: Moderne hashing in AD is NTLMv2, maar je wilt LM en NTLMv1 uitfaseren via GPO.

Zo geef je je omgeving een solide basis, terwijl de “banned password” en “smart password policy” het vernuftige deel opvangen.

4. Praktische implementatiestappen en PowerShell-commando’s

4.1 Azure AD Password Protection activeren

1. Licentiecheck: Zorg dat je minimaal Azure AD Premium P1 hebt.
2. Ga naar de portal: In de Entra Admin Center (voorheen Azure AD) ga je naar Security > Authentication methods > Password protection.
3. Policy Settings: Je hebt hier typically 2 instellingen:
   • Enforce: Zet op On als je wil dat de banned-lijst daadwerkelijk toegepast wordt.
   • Custom banned passwords: Hier kun je eigen woorden toevoegen, gescheiden door komma’s of regeleinden.
4. Test: Probeer met een testaccount een te eenvoudig wachtwoord in te stellen. Je zou moeten zien dat de portal het weigert.

4.2 Password Protection on-prem installeren

1. Download: Haal de Azure AD Password Protection DC Agent en de Azure AD Password Protection Proxy op via Microsoft Download Center.
2. Installeer Proxy: Installeer de Proxy op een Windows Server (kan op DC of een aparte server). Tijdens de installatie moet je je Entra ID Global Admin-gegevens invoeren om te registreren.
3. Installeer DC Agent: Doe dit op elke DC waar je de password filter wilt activeren. Ook hier voer je referenties in om de agent te koppelen met je tenant.
4. Configureer: Via PowerShell-commando’s kun je de status en de mode instellen:

Import-Module AzureADPasswordProtection

Register-AzureADPasswordProtectionForest

Set-AzureADPasswordProtectionProxy -ProxyMode “Enabled”

Verification: Check of je DC’s nu de policy binnenhalen:

Get-AzureADPasswordProtectionSummary

Je moet zien dat de status op “Enforced” staat.

4.3 PowerShell: Custom banned words toevoegen

Je kunt via de Entra Admin Center (GUI) custom banned words toevoegen, maar als je liever PowerShell gebruikt (of automation), kan dat:

# In 2025 is de module AzureAD vaak vervangen door Microsoft.Graph,

# maar ter illustratie laten we hier de 'AzureAD' cmdlets zien:

Connect-AzureAD

# Ophalen van huidige policy:

$pwdPolicy = Get-AzureADPolicy | Where-Object {$_.Type -eq "PasswordHashSync"}

# Stel custom banned word list in (bijv. productnamen):

$bannedWords = "Contoso,Contoso2025,Welcome,Welkom"

Set-AzureADPolicy -Id $pwdPolicy.Id -Definition @("BannedPasswordList=$bannedWords")

# Check

Get-AzureADPolicy | fl

Houd er rekening mee dat Microsoft de Graph API en MSOnline-modules regelmatig wijzigt, dus de exacte cmdlets kunnen veranderen. Check altijd de meest recente documentatie.

5. Best practices voor wachtwoordbeleid in 2025

5.1 Maak gebruik van passphrases

In plaats van “complexe” regels met hoofdletters, cijfers en vreemde tekens, adviseert Microsoft tegenwoordig passphrases. Bijvoorbeeld: “MijnGroteHondAt5Koekjes!”. Zo’n zin is voor een gebruiker eenvoudiger te onthouden en is vaak langer (20+ karakters). De banned-lijst scant dan of er geen al te voor de hand liggende woorden in zitten.

5.2 Vermijd geforceerde periodieke vernieuwing

Oude best practices stelden dat je wachtwoorden elke 30, 60 of 90 dagen moet laten vervallen. Nieuwe inzichten (en NIST-richtlijnen) tonen dat frequente verplichte vernieuwing juist leidt tot slechtere wachtwoorden (gebruikers gaan incrementeren of opschrijven). Beter is:

• Geen vaste vervaldatum, óf een lange periode (bijv. 180 dagen).
• Risk-based updates: Als je Identity Protection ziet dat een wachtwoord mogelijk gelekt is, dwing je meteen een reset af.

5.3 Combineer met MFA

Zonder MFA blijft wachtwoordbescherming een zwak punt in je securityketen. Zet dus niet alleen password protection in, maar ook:

• Conditional Access-beleidsregels met MFA.
• Risk-based sign-in in Entra ID.
• Self-service password reset (SSPR) met MFA-verificatie.

Zo heb je een gelaagde aanpak waarin een gecompromitteerd wachtwoord niet direct het einde van de wereld betekent, omdat een aanvaller alsnog MFA moet omzeilen.

5.4 Schakel door op passwordless (waar mogelijk)

De ideale situatie (zeker in 2025) is dat je op termijn overstapt naar passwordless voor al je moderne apps, met FIDO2-sleutels of Windows Hello for Business. Maar tot die tijd is Password Protection een essentieel vangnet.

5.5 Train gebruikers en communiceer

Technische maatregelen zijn onmisbaar, maar vergeet niet:

• Gebruikers moeten begrijpen waarom hun “favoriete” wachtwoord ineens niet meer kan.
• Duidelijke instructie: “Gebruik liever een wachtzin van 16+ tekens, bijvoorbeeld ‘IkhouvanPannenkoeken2025!’.”
• Maak het eenvoudig: laat hen via Self-Service Password Reset het proces doorlopen, zodat je helpdesk niet overbelast raakt.

6. Use cases en praktijkvoorbeelden

6.1 MKB met hybride AD

Stel, je bent een middelgroot bedrijf met 200 man personeel, on-prem Windows Server 2016 DC’s en Office 365 E3-licenties plus aparte Azure AD Premium P1. Je synchroniseert accounts met Azure AD Connect. Veel gebruikers wisselen elk kwartaal hun wachtwoord (oud GPO-beleid).

• Stap 1: Installeer de Azure AD Password Protection Proxy en DC Agents.
• Stap 2: Zet password expiration op 180 dagen in GPO (of schaf het helemaal af), want je vertrouwt op de banned-lijst en MFA.
• Stap 3: Communiceer naar gebruikers dat er nieuwe regels gelden, en adviseer passphrases.
• Stap 4: Gebruikers komen erachter dat “Welkom2025!” niet meer mag; ze moeten iets sterkers kiezen.
• Resultaat: Minder slechte wachtwoorden, minder helpdeskvragen, en één securitylaag extra tegen dictionary-attacks.

6.2 Enterprise multinational

Grote multinational met meerdere forests en 20.000+ medewerkers. Men heeft Microsoft 365 E5-licenties, Defender for Identity, Entra ID Protection en Sentinel.

• Stap 1: Rol passwordless uit voor de kern van het personeel dat op moderne apparaten werkt.
• Stap 2: Voor legacy systemen die nog wachtwoorden vereisen, activeer je Azure AD Password Protection on-prem.
• Stap 3: Creëer custom banned-lijsten met bedrijfsnamen, productcoderingen en de top 500 meest gelekte wachtwoorden in eigen landstalen.
• Stap 4: Integreer met Sentinel: als er een user is met 5 mislukte inlogpogingen binnen 30 seconden, stuur direct alert.
• Stap 5: Tuning & awareness: monitor of er veel “false rejections” zijn. Zo ja, update je custom banned-lijst.

Zo’n scenario laat zien dat ook in complexe, internationale omgevingen de cloudgebaseerde password check helpt om consistent beleid te houden.

6.3 Non-profit met gasten en vrijwilligers

Een non-profit organisatie heeft veel gastgebruikers in Teams en SharePoint. Die gasten vallen óók onder Azure AD, en ook daarvoor werkt de banned-lijst. Zodra een gastgebruiker een account registreert of wachtwoord wijzigt, wordt de password protection-check uitgevoerd. Dit garandeert dat externe toegang niet ineens een zwakke schakel vormt.

7. Veelgestelde vragen en valkuilen

1. V: Wat als mijn gebruikers heel creatief worden, maar toch op banned-lijst stuiten?
   A: Dit komt vooral voor als je custom woorden of bedrijfsnamen toevoegt. Wees niet te agressief, want dat kan tot frustratie leiden. Houd het bij écht zwakke woorden en combinaties.
2. V: Kan ik logs inzien van welke wachtwoorden geweigerd zijn?
   A: Je ziet geen exacte geweigerde wachtwoorden (vanwege privacy/security), maar je ziet wel events dat password protection iets blokkeert. In de Microsoft 365 Defender-portal kun je rapporten bekijken, en in de Event Viewer van je DC zie je “Password policy violation.”
3. V: Werkt dit ook voor serviceaccounts en machine-accounts?
   A: Ja, formeel wel, maar serviceaccounts gebruiken vaak random gehashte wachtwoorden of Kerberos SPN’s die niet via user input gaan. Banned-lijsten zijn vooral gericht op menselijke wachtwoordkeuzes.
4. V: Gaat dit niet tegen adviezen van NCSC in?
   A: Integendeel, de meeste nationale securitycentra (inclusief NCSC-NL) adviseren langer en unieker, liefst geen verplichte periodieke vernieuwing, en liever passphrases dan complexe maskers. Precisely wat Microsoft hier doet.
5. V: Moet ik nog iets doen met third-party password managers?
   A: Dat hangt af van je beleid. Password managers kunnen gebruikers stimuleren om unieke, lange wachtwoorden te genereren. Als dat wachtwoord toch op banned-lijst staat (bijv. omdat ‘Welkom’ erin zit), wordt het gewoon geblokkeerd. Er is dus geen conflict.

8. Conclusie

Password Protection in Entra ID (Azure AD) is een van de meest effectieve en laagdrempelige manieren om je aanvalsoppervlak te verkleinen. Door “banned passwords” en real-time checks te implementeren, voorkom je dat gebruikers (of gastgebruikers) zwakke, voorspelbare of veelvoorkomende wachtwoorden instellen. In hybride omgevingen kun je deze functionaliteit doortrekken naar je on-premises Active Directory, zodat je organisatie overal dezelfde beschermingsgraad heeft.

Deze aanpak is niet de silver bullet: combinatie met MFA, risk-based sign-in en (op termijn) passwordless is essentieel. Maar in 2025, waar talloze applicaties en scenario’s nog steeds een password prompt gebruiken, is dit wel een cruciale stap voorwaarts. Met de continu geüpdatete banned-lijst en de mogelijkheid tot custom woorden (denk aan bedrijfsnamen, productcodes), maak je het voor aanvallers een stuk lastiger om via simpele brute force of dictionary-attacks je omgeving binnen te dringen.

Kortom, wachtwoordbeveiliging is veel meer dan “een sterk wachtwoord verzinnen”. Het gaat om slimme, dynamische checks in de cloud, integratie met on-prem en goede user awareness. Met Azure AD Password Protection en de tips in deze blog kun je direct aan de slag om je identiteitspostuur te versterken – en hopelijk je helpdesk wat rustiger te maken.

Heb je vragen of wil je je ervaringen delen? Laat dan een reactie achter op ITCowboys.nl, of neem direct contact met me op via LinkedIn.

– Jordy Herber, ITCowboys.nl