Welkom bij het achtste deel van onze blogserie over geavanceerde beveiligingsoplossingen in het Microsoft-ecosysteem. Hoewel het vorige zevendelige thema draaide om Geavanceerde E-mailbeveiliging en Anti-Phishing, richten we ons nu op een andere, minstens zo cruciale pijler: Identiteits- en Toegangsbeveiliging. In deze blog zoomen we in op twee belangrijke oplossingen die Microsoft biedt om aanvallen op identiteiten en accounts te detecteren en te blokkeren:

1. Defender for Identity: de dienst die je on-premises Active Directory (AD) en hybride AD-omgevingen monitort en verdacht gedrag herkent.
2. Entra ID Protection: de clouddienst (voorheen Azure AD Identity Protection) die risico’s opspoort rond aanmeldingen en gebruikers, en die kan ingrijpen met bijvoorbeeld Conditional Access en MFA.

We schrijven dit in 2025, een tijd waarin de hybride werkplek gemeengoed is en identiteitsaanvallen zich razendsnel ontwikkelen. Waar we ooit alleen Active Directory on-premises hadden, zien we nu dat veel organisaties in een hybride vorm zitten: deels on-prem AD, deels Entra ID (Azure AD) in de cloud. Deze dubbele identiteitssituatie kan complex zijn, maar ook biedt het krachtige mogelijkheden om zowel lokale als cloudaccounts te beveiligen. Precies daar komen Defender for Identity en Entra ID Protection om de hoek kijken.

Wat gaan we behandelen?

• Detectie van verdacht gedrag in on-premises AD en hybride scenario’s met Defender for Identity (voorheen bekend als Azure ATP).
• Hoe Entra ID Protection risicovolle aanmeldingen en identiteiten in de cloud monitort, en welke signalen er worden gebruikt.
• Inrichting van automatische responsacties, zoals het afdwingen van Multi-Factor Authentication (MFA) of wachtwoordreset, wanneer een risico hoog genoeg is.

Deze blog is semi-technisch, met voldoende diepgang voor de IT-professional of securityspecialist die de technologie wil begrijpen én configureren. We delen best practices, technische commando’s en scenario’s, zodat je na het lezen in staat bent om het binnen jouw organisatie in te zetten.

Laten we beginnen!

1. Overzicht: waarom Defender for Identity & Entra ID Protection?

1.1 De moderne aanval op identiteiten

In 2025 is identiteitsbeveiliging minstens zo belangrijk als endpoint- of e-mailsecurity. Aanvallers hebben ontdekt dat het kapen van een gebruikersaccount veel makkelijker kan zijn dan het doorbreken van firewalls of complexe netwerken. Een enkele gelukkige phishingaanval of onveilige wachtwoorden geven directe toegang tot bedrijfsdata.

Tegelijkertijd zien we dat identiteiten zich niet beperken tot “alleen cloud” of “alleen on-prem”. De realiteit is vaak hybride: gebruikers synchroniseren vanuit on-prem AD naar Entra ID, of ze gebruiken cloud-only accounts voor specifieke SaaS-toepassingen. Deze mengvorm betekent dat je beide werelden in de gaten moet houden:

• On-prem AD kan kwetsbaar zijn voor Pass-the-Hash, Pass-the-Ticket, Golden Ticket of andere laterale bewegingen.
• Entra ID is kwetsbaar voor brute force via internet, token replay, risicoaanmeldingen of misbruik van externe gasttoegang.

1.2 Defender for Identity in een notendop

Defender for Identity (vroeger Azure Advanced Threat Protection of Azure ATP) is een dienst die je lokale Active Directory-signalering realtime naar de cloud brengt. Dit werkt via sensoren op je Domain Controllers, die het verkeer (bijvoorbeeld Kerberos, NTLM, RPC) analyseren op gedragspatronen:

• Reconnaissance (aanvallers die AD scannen naar interessante accounts)
• Lateral movement (aanvallers die zich proberen te verplaatsen naar cruciale servers of domeinadmin-accounts)
• Privilege escalation (pogingen om extra rechten te bemachtigen)
• Pass-the-Hash/Pass-the-Ticket (hergebruik van inlogtokens)

Defender for Identity stuurt alerts naar de cloudportal (Defender-portal) zodra het verdacht gedrag ziet. Zo zie je direct waar de aanval plaatsvindt, welke accounts en machines betrokken zijn, en kun je gepaste maatregelen nemen.

1.3 Entra ID Protection in een notendop

Entra ID Protection (voorheen Azure AD Identity Protection) scant je cloudidentiteiten op basis van risico:

1. Sign-in risk: Is een aanmelding verdacht, bijvoorbeeld vanaf een ongebruikelijke locatie, een TOR-exitnode of via onmogelijke reistijd?
2. User risk: Is het account zelf gecompromitteerd, bijvoorbeeld door gelekte wachtwoorden of terugkerende verdachte aanmeldingen?

Entra ID Protection kan deze risico’s automatisch koppelen aan Conditional Access. Dit betekent dat als de risicoscore boven een bepaalde drempel komt, de gebruiker MFA moet uitvoeren, of zelfs zijn wachtwoord moet resetten voordat hij verder kan. Zo integreer je security in de inlogflow, zonder continu alles handmatig te hoeven controleren.

2. Defender for Identity: detectie van verdacht gedrag in on-premises AD

2.1 Architectuur en implementatie

Om Defender for Identity te gebruiken, installeer je Defender for Identity-sensoren (soms ook wel “sensor agents”) op elk van je Domain Controllers of Read-Only Domain Controllers (RODC). Deze sensoren lezen het netwerkverkeer en security events (Event 4776, 4768, 4769, enz.) uit. Vervolgens sturen ze de data naar de cloudservice van Defender for Identity.

Stapsgewijze implementatie:

1. Licenties: Defender for Identity is onderdeel van de Enterprise Mobility + Security E5-licentie of Microsoft 365 E5.
2. Portal-toegang: Je gaat naar de Microsoft 365 Defender-portal of de aparte Defender for Identity-portal om configuratie en alerts te beheren.
3. Sensorinstallatie: Download de sensor software en installeer deze op je Domain Controllers (Windows Server). Zorg dat je account voldoende rechten heeft (Local Administrator op DC’s).
4. Netwerkpoorttoegang: De sensor communiceert via poort 443 outbound naar de Defender-for-Identity-dienst. Zorg dat je firewall dit toestaat.
5. Verify & tune: Na installatie verschijnen je DC’s in de portal. Stel evt. exclusions in (bijvoorbeeld voor lab-accounts) en controleer of je events binnenkrijgt.

2.2 Detecties en hun waarde

Defender for Identity herkent meerdere aanvalsfasen. Enkele voorbeelden:

1. Reconnaissance:
   • LDAP Enumeration: Aanvallers kunnen zoeken naar de namen van admins, serviceaccounts en members van security groups.
   • Kerberoasting: Poging om serviceaccount hashes te bemachtigen via Kerberos.
2. Credentials Access & Lateral Movement:
   • Pass-the-Hash: De hash van een accountwachtwoord (NTLM) wordt ingezet om elders in te loggen zonder het wachtwoord zelf te kennen.
   • Pass-the-Ticket: Het misbruiken van Kerberos tickets (TGT/TGS).
   • Overpass-the-Hash: Een combinatie van NTLM hash met Kerberos tickets.
3. Privilege Escalation:
   • Golden Ticket: Het aanmaken van een vervalst Kerberos TGT waarmee je praktisch onbeperkt toegang hebt.
   • DC Shadow: Aanvalsmethode om DC-rollen te misbruiken voor replicatie van malafide AD-objecten.
4. Domain Dominance:
   • Eenmaal domain admin-privileges behaald, kan de aanvaller bijna alles. Defender for Identity signaleert ook abnormale activiteiten van domain admins (bijv. inlog op een workstation waarop ze nooit inloggen).

Zodra deze patronen worden gedetecteerd, krijg je in de portal alerts met risk scores en aanbevelingen. Bijvoorbeeld: “Abnormal number of NTLM authentications from user X on host Y – possible pass-the-hash.” Je kunt hier direct op inspelen.

2.3 Integratie met andere Microsoft 365-componenten

• Microsoft Sentinel: veel organisaties koppelen Defender for Identity aan Sentinel. Zo krijg je SIEM-events die je kunt correlateren met andere signalen (Defender for Endpoint, e-mail alerts, Entra ID logs).
• Defender for Endpoint: ziet Defender for Endpoint dat er op een specifieke server of client verdachte processen draaien, dan kan dat signaal in Defender for Identity worden meegenomen. Zo ontdek je sneller laterale beweging.
• Automated Investigation & Response (AIR): in sommige scenario’s kun je geautomatiseerde acties instellen, zoals het intrekken van sessies van een verdachte gebruiker of het isoleren van een endpoint als de aanval ernstig is.

3. Entra ID Protection: monitoren van risicovolle aanmeldingen en identiteiten

3.1 Basisprincipes van Entra ID Protection

Entra ID Protection (voorheen Azure AD Identity Protection) focust op cloudaanmeldingen in Entra ID. Het kijkt naar:

1. Risky sign-ins: Is er iets verdacht aan de aanmelding? Bijvoorbeeld:
   • Aanmelden vanuit een nooit eerder gebruikte locatie of vanaf twee locaties die geografisch niet haalbaar zijn binnen korte tijd (“Impossible travel”).
   • Aanmelden met credentials die op het dark web zijn gevonden of die overeenkomen met gelekte wachtwoorden.
   • Pogingen tot brute force of password spray (hele reeks aanmeldingen vanuit hetzelfde IP-adres).
2. Risky users: Als Entra ID genoeg verdachte aanmeldingen ziet voor een gebruiker, zal het deze gebruiker labelen als risky user. De risicoscore kan oplopen van “Low” naar “Medium” tot “High”.

Op basis hiervan kun je beleidsregels (policies) definiëren:

• User risk policy: Als een gebruiker “High risk” krijgt, wordt de accounttoegang geblokkeerd of moet de gebruiker bij de volgende aanmelding een wachtwoordreset doen.
• Sign-in risk policy: Als een aanmelding “Medium risk” is, moet de gebruiker MFA doen. Bij “High risk” misschien helemaal geen toegang.

3.2 Hoe Entra ID Protection data verzamelt

Entra ID Protection maakt gebruik van machine learning en wereldwijde telemetrie. Microsoft analyseert miljarden aanmeldingen per dag (over alle tenants), plus gegevens uit:

• Microsoft Threat Intelligence: lijsten met malafide IP-adressen, botnets, TOR-exitnodes.
• Credentiallekkages: databases met gelekte e-mail/wachtwoorden die Microsoft in handen krijgt via securitypartners of darkwebscans.
• Ongebruikelijk gedrag: het AI-systeem merkt op dat een bepaald account normaal alleen in Europa inlogt en nu ineens vanuit Azië inlogt op een tijdstip dat niet realistisch is.

Zodra een sign-in als risico wordt bestempeld, zie je in de Entra ID (Azure AD) blade van de Microsoft Entra Admin Center of in het Microsoft 365 Defender-portal een melding. Als je dat hebt ingericht, kan er direct een Conditional Access-beleid ingrijpen.

3.3 Voorbeeld van Conditional Access op basis van risk

Stel, je maakt een policy in Entra ID die zegt: “Als de sign-in risk = Medium of hoger, dan vereis ik MFA. Als de sign-in risk = High, dan blokkeer ik de aanmelding of dwing ik wachtwoordreset af.” De stappen:

1. Ga naar Entra ID (Azure AD) > Security > Identity Protection > Sign-in risk policy.
2. Configureer: Selecteer welke gebruikers/groepen vallen onder dit beleid.
3. Conditions: Zet sign-in risk op Medium and above.
4. Controls: Kies Require multi-factor authentication of Block access.
5. Enable het beleid.

Nu worden gebruikers die een risicovolle aanmelding doen automatisch aan strengere eisen onderworpen. Dit minimaliseert het risico dat een aanvaller met gestolen credentials zo maar naar binnen kan.

4. Inrichting van automatische responsacties (MFA afdwingen, password reset)

4.1 Automatisch MFA afdwingen

Bij Entra ID Protection kun je instellen dat een gebruiker met Medium risk eerst door MFA moet, ook al heeft hij die normaal niet ingesteld. Dit is een typische quick-win: als een account mogelijk gecompromitteerd is, moet de aanvaller extra hindernis nemen (MFA). Als het MFA-proces faalt, kun je de inlog afbreken en extra alarmen genereren.

4.2 Password reset bij hoge risk

Voor High risk users is de gangbare praktijk om password reset te vereisen. Dat kan op twee manieren:

1. Self-service password reset (SSPR): De gebruiker moet – voordat hij weer normale toegang krijgt – zijn wachtwoord via SSPR wijzigen en MFA ondergaan. Zo waarborg je dat echt de legitieme gebruiker toegang heeft.
2. Handmatig reset door helpdesk: In sommige scenario’s houd je het liever in eigen hand. Dan krijgt de security/admin-teams een alert en reset je het wachtwoord handmatig.

Door dit te automatiseren in Identity Protection, hoef je niet continu alerts te verwerken in je helpdesk. Het systeem kan direct actie ondernemen zodra de risicoscore te hoog is.

4.3 Defender for Identity-actie

Hoewel Defender for Identity zich richt op on-prem AD, kun je via integratie met Microsoft 365 Defender of Sentinel ook triggeren dat:

• De gebruiker in Entra ID wordt gemarkeerd als risico.
• Er een temporary ban komt op NTLM-authenticaties.
• In extreme gevallen: de gebruiker lidmaatschap van elevated AD-groepen verliest, of het account wordt geblokkeerd (hiervoor heb je vaak PowerShell-scripts of security-orchestratie nodig).

Deze cross-actie is wat hybridescenario’s zo krachtig maakt: een aanval op on-prem DC’s leidt tot automatische blokkade in de cloud, en vice versa.

5. Scenario’s en best practices

5.1 Hybride detectie van Pass-the-Hash en risk sign-ins

Een realistisch voorbeeld:

1. Een aanvaller weet via phishing de credentials van een on-prem AD-gebruiker te bemachtigen.
2. Die aanvaller logt zich lokaal in en voert een Pass-the-Hash-aanval uit om domeinadmin-toegang te krijgen. Defender for Identity detecteert abnormale Kerberos- en NTLM-acties en stuurt een alert “Suspicious lateral movement.”
3. Tegelijk probeert de aanvaller in de cloud (via Entra ID) toegang te krijgen tot Exchange Online en SharePoint, met diezelfde (gesynchroniseerde) credentials. Entra ID Protection registreert een inlog uit een ander land en stelt “Sign-in risk = High.”
4. Automatisch wordt MFA en daarna een wachtwoordreset geëist. Intussen kan de SOC of securitybeheerder in Defender for Identity bekijken welke accounts en servers zijn aangetast.
5. De combinatie van signalen uit on-prem (Defender for Identity) en cloud (Entra ID Protection) geeft het complete beeld, en de aanval wordt vroegtijdig afgebroken.

5.2 Gastgebruikers en B2B

In 2025 is Azure AD B2B (onderdeel van Entra ID) gemeengoed. Gastgebruikers zijn niet altijd medewerkers, maar externen die toegang hebben tot Teams, SharePoint of Power Apps. Identity Protection scant ook hun aanmeldingen. Als een gastaccount ineens een “High risk sign-in” vertoont, kun je dezelfde beleiden (MFA, block access) toepassen. Zo voorkom je dat een gecompromitteerde gasttoegang jouw organisatie bedreigt.

5.3 Minimale vereisten en zero trust

• Zorg voor MFA op alle accounts: Dit klinkt als een open deur, maar in de praktijk staan in 2025 nog steeds organisaties MFA deels uit of alleen voor admins. Conditional Access en Identity Protection helpen, maar als MFA niet is ingeschakeld, loop je enorm risico.
• Zorg voor hardening on-prem DC’s: Defender for Identity is waardevol, maar het is geen vervanging voor basismaatregelen: up-to-date patches, secure channel binding, SMB-signing, en beperking van admin-rechten.
• Pas Zero Trust toe: Verleen nooit blind alle AD-sessies toegang tot de cloud. Laat Identity Protection en Conditional Access “denken in risico”. Hoog risico = streng beleid. Dit is het hart van een Zero Trust-strategie.

6. Technische implementatierichtlijnen en commando’s

6.1 Defender for Identity installeren

1. PowerShell (optioneel): Hoewel je meestal via GUI installeert, kun je scripts maken om de sensor automatisch te distribueren. Een simpel voorbeeld van een script (niet volledig, ter illustratie):

# Voorbeeld: unattended installatie van de Defender for Identity sensor

# Variabelen

$SensorSetup = "C:\Temp\MDEIdentitySetup.exe" # Locatie van de sensor-setup

$AccessKey = "==JeUniekeAccessKeyVanuitDefenderPortal==" # Te halen uit de portal

# Uitvoeren

Start-Process $SensorSetup `

  -ArgumentList "/quiet /AccessKey=$AccessKey /InstallDir=C:\Program Files\Azure Advanced Threat Protection Sensor" `

  -Wait -NoNewWindow

1. Zorg voor benodigde rechten: De sensor heeft lokale adminrechten op de DC nodig en moet domein-Security-events kunnen uitlezen.
2. Valideer: Ga in de Defender for Identity-portal naar Settings > Sensors en controleer of de DC’s correct worden weergegeven.

6.2 Entra ID Protection instellen

1. User risk policy:
   • Ga naar Entra ID > Security > Identity Protection > User risk policy.
   • Kies Users or groups = All users (of begin met een pilotgroep).
   • Stel User risk = Medium and above in.
   • Actie = Require password change.
   • Activeer.
2. Sign-in risk policy:
   • Ga naar Entra ID > Security > Identity Protection > Sign-in risk policy.
   • Kies scope = All users (of pilot).
   • Stel Sign-in risk = Medium and above.
   • Actie = Require MFA.
   • Activeer.
3. Rapportages: Check regelmatig Entra ID > Security > Identity Protection > Overview om te zien welke sign-ins als risk werden gemarkeerd en wat er mee is gebeurd.

6.3 Correlatie met Sentinel

Wil je alerts en logs geautomatiseerd verwerken, overweeg dan Microsoft Sentinel. Met de juiste dataconnectoren:

• Defender for Identity connector: Stuurt on-prem AD alerts naar Sentinel.
• Azure AD (Entra ID) logs connector: Stuurt risk sign-ins en Identity Protection alerts naar Sentinel.
• KQL-queries: Met Kusto Query Language maak je correlation rules. Bijvoorbeeld:

let riskySignIns =

AADRiskySignins

| where RiskLevel != "none" and ResultType == "0"

| project UserPrincipalName, RiskLevel, IPAddress, TimeGenerated;

let identityAlerts =

SecurityAlert

| where ProductName == "Azure Advanced Threat Protection";

riskySignIns

| join identityAlerts on $left.UserPrincipalName==$right.AccountCustomEntity

| project TimeGenerated, UserPrincipalName, RiskLevel, IPAddress, AlertName, Description

| order by TimeGenerated desc

Hiermee zie je in één oogopslag of gebruikers die in Entra ID risky sign-ins hebben, ook on-prem AD alerts triggeren. Dat duidt sterk op een gecompromitteerd account.

7. Samenvattende best practices

1. Hybride mindset: Bescherm zowel je on-prem AD met Defender for Identity als je cloudaccounts met Entra ID Protection. Aanvallers zoeken altijd de zwakste schakel.
2. Licentiemodel: Check of je Microsoft 365 E5, EMS E5 of standalone Defender for Identity licenties hebt. Identity Protection is vaak inbegrepen bij Azure AD Premium P2 (onderdeel van EMS E5).
3. MFA everywhere: Zet MFA aan voor alle gebruikers. Laat Identity Protection risicogebaseerde beslissingen nemen, maar bouw een brede basis van MFA-verplichtingen.
4. Tijdige rapportage: Stel e-mailnotificaties in of gebruik Sentinel om alerts direct bij je SOC of IT-team te laten landen.
5. Automatisering: Maak gebruik van Conditional Access, user risk policies, en sign-in risk policies. Overweeg ook Automated Investigation & Response (AIR) in het Defender-portal en breid uit met Sentinel-playbooks.
6. Security awareness: Blijf gebruikers trainen in phishingherkenning en safe computing. Een groot deel van identiteitscompromissen begint bij gelekte of gestolen wachtwoorden.
7. Regelmatig review: Check je Defender for Identity-alerts en Entra ID Protection-rapporten wekelijks. Evalueer of drempels en acties nog passen bij de laatste dreigingsontwikkelingen.

8. Conclusie

Identiteitsbeveiliging is anno 2025 een hoeksteen van elke securitystrategie. Aanvallers focussen zich op accounts en credentials, omdat één succesvolle compromise vaak de sleutel is tot het hele netwerk. Met Defender for Identity en Entra ID Protection heb je twee krachtige pijlers in handen om zowel on-premises AD als cloudgebaseerde Entra ID te bewaken en automatisch te reageren op verdachte signalen.

Defender for Identity integreert naadloos met je Domain Controllers om schadelijke activiteiten (laterale beweging, privilege escalation, pass-the-hash) te detecteren. Entra ID Protection daarentegen scant je cloudidentiteiten op risicovolle sign-ins en kan gebruikers dwingen tot MFA of password resets. Samen vormen ze een hybride verdedigingsfront dat ongebruikelijke activiteiten direct aan het licht brengt, ongeacht of die on-prem of in de cloud plaatsvinden.

Het belangrijkste motto blijft: “Beveiliging is een continu proces.” De tools zijn er, maar je moet ze goed configureren, fine-tunen en vooral monitoren. Ook is het cruciaal om gebruikers op te leiden en processen op te zetten voor incidentrespons. Werk je bovendien met Microsoft Sentinel en andere Defender-componenten (zoals Defender for Endpoint, Defender for Cloud Apps), dan kun je die geïntegreerde aanpak verder versterken in een echte Zero Trust-architectuur.

Met deze blog sluiten we ons thema Identiteits- en Toegangsbeveiliging nog niet af, want er is uiteraard meer te ontdekken in de wereld van Conditional Access, Passwordless authenticatie, en advanced threat hunting. Maar als start is dit de basis: zorg dat je on-prem AD en je cloudaccounts elkaar versterken in plaats van verzwakken. Dan sta je in 2025 en daarna een heel stuk sterker tegen de geavanceerde identiteitsaanvallen die onvermijdelijk zullen blijven opduiken.

Heb je nog vragen, of wil je jouw eigen ervaringen delen? Laat het me weten via ITCowboys.nl of in de reacties!

– Jordy Herber, ITCowboys.nl