Legacy apps naar Azure migreren: wanneer kies je voor Microsoft Entra Domain Services en wanneer voor IaaS-domeincontrollers

By Mirko Peters · 2026-08-14

Vergelijk Microsoft Entra Domain Services met IaaS-domeincontrollers in Azure. Ontdek de architectuurafwegingen bij het migreren van legacy apps.

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

Bij het lift-and-shiften van legacy Windows-applicaties naar Azure staan architecten voor een cruciaal identiteitsdilemma: moet je traditionele Active Directory-domeincontroller-VM's uitrollen, of kies je voor beheerde cloudservices? Deze gids onderzoekt de architectuurafwegingen, de operationele lasten en de kostenimplicaties van Microsoft Entra Domain Services ten opzichte van zelfbeheerde IaaS-domeincontrollers voor legacy-workloads in Azure.

Belangrijkste punten

• Microsoft Entra Domain Services biedt beheerde mogelijkheden van traditionele Windows-domeinen, zonder dat IT-teams domeincontroller-VM's hoeven uit te rollen, te patchen of te herstellen.
• IaaS-domeincontrollers in Azure geven beheerders volledige controle, inclusief RDP-toegang en Domain Admin-bevoegdheden, maar verhogen de operationele last aanzienlijk.
• Legacy-workloads die afhankelijk zijn van LDAP, Kerberos, NTLM of Group Policy kunnen naadloos in Azure draaien via een beheerde compatibiliteitslaag voor domeinen.
• Entra Domain Services hanteert een strikt eenrichtingsmodel voor identiteitssynchronisatie: gebruikersaccounts moeten worden beheerd bij de autoritatieve bron en niet rechtstreeks in het beheerde domein.
• Welke identiteitsarchitectuur je kiest, hangt sterk af van applicatie-eisen zoals LDAP-schrijftoegang en schemawijzigingen.

Het legacy Azure-migratiedilemma

Een legacy bedrijfsapplicatie verplaatsen van een on-premises serverruimte naar een Azure-VM maakt die applicatie niet vanzelf cloud-native. Veel gevestigde Windows-applicaties, zoals verouderde ERP-systemen, financiële platforms en maatwerk .NET-applicaties, zijn gebouwd rond traditionele Active Directory. Wanneer deze workloads in de cloud terechtkomen, verwachten ze nog steeds dat ze directoryservices via LDAP kunnen bevragen, zich via Kerberos-tickets kunnen authenticeren of instellingen via Group Policy kunnen toepassen.

Cloudarchitecten moeten meteen een strategische keuze maken. Je kunt je Azure Virtual Network via een hybride VPN-tunnel terugkoppelen aan je on-premises domeincontrollers, maar dat brengt latentie met zich mee en vormt een gevaarlijk single point of failure als de netwerkverbinding wegvalt. Een alternatief is om nieuwe Windows Server-VM's in Azure op te zetten, ze te promoveren tot domeincontrollers en een gloednieuw forest of replicadomein te bouwen.

Zelf domeincontroller-VM's in Azure bouwen geeft je volledige controle, maar het maakt je cloudinfrastructuurteam ook tot actieve Active Directory-beheerders. Jij bent dan volledig verantwoordelijk voor patchen van het besturingssysteem, het monitoren van directoryreplicatie, het plannen van disaster recovery en het beveiligen van accounts met hoge privileges tegen credential theft. Voor organisaties die de operationele last willen beperken en tegelijk legacy-applicaties willen laten draaien, is dit vaak een onnodige belasting.

Entra Domain Services versus IaaS-domeincontrollers: de belangrijkste architectuurverschillen

Inzicht in het architectonische verschil tussen Microsoft Entra Domain Services en zelfgebouwde IaaS-domeincontrollers is essentieel voor het ontwerpen van robuuste Azure-cloudomgevingen. Entra Domain Services fungeert als een beheerde compatibiliteitslaag. Microsoft beheert en onderhoudt de onderliggende domeincontroller-infrastructuur achter de schermen en zorgt zo voor hoge beschikbaarheid, automatische back-ups en synchronisatie op de achtergrond met Entra ID.

Wanneer je Entra Domain Services gebruikt, kunnen je Azure-virtuele machines lid worden van het domein, LDAP-query's uitvoeren en Kerberos- of NTLM-aanmeldingen afhandelen, zonder dat je engineers ooit via Remote Desktop op een domeincontroller hoeven in te loggen. Deze beheerde dienst heeft echter een keerzijde: je geeft directe beheerdersbevoegdheden uit handen. Je hebt geen toegang tot het onderliggende besturingssysteem, je kunt het Active Directory-schema niet wijzigen en je krijgt geen Domain Admin- of Enterprise Admin-rechten.

Omgekeerd geven IaaS-domeincontrollers je volledige controle over de directoryarchitectuur. Je kunt het schema uitbreiden, aangepaste vertrouwensrelaties configureren, willekeurige organisatie-eenheden toevoegen en gespecialiseerde groepsbeleidsobjecten zonder beperkingen implementeren. Het nadeel van deze flexibiliteit is het onderhoud. Je team moet de volledige levenscyclus van het domein beheren, inclusief proactieve gezondheidscontroles, defragmentatie van de database en noodherstelprocedures als een domeincontroller uitvalt.

Operationele afwegingen en beheerrestricties

Voordat je kiest voor een beheerde domeinoplossing in Azure, moeten cloudbeheerders zorgvuldig evalueren hoe de dagelijkse operatie verandert. Met zelfgebouwde IaaS-domeincontrollers heeft je team granulaire controle over elk aspect van de directory. Je kunt aangepaste PowerShell-scripts schrijven om beheertaken te automatiseren, beveiligingsagents van derden rechtstreeks op de domeincontrollers installeren en replicatiefouten oplossen met native hulpprogramma's zoals repadmin.

Microsoft Entra Domain Services vervangt deze praktische aanpak door beheerrestricties. Beheer verloopt via een speciale groep, Entra Domain Services Administrators, met beheerhulpprogramma's die zijn geïnstalleerd op een afzonderlijke, aan het domein toegevoegde Windows-virtuele machine. Je kunt wel organisatie-eenheden aanmaken, DNS-records beheren en ondersteunde Groepsbeleid-instellingen toepassen, maar de kerninfrastructuur is strikt afgeschermd.

Daarnaast volgt identiteitsbeheer een strikt eenrichtingsmodel voor synchronisatie. Gebruikers- en groepsidentiteiten stromen vanuit je gezaghebbende bron, ofwel cloudgebruikers in Entra ID of gesynchroniseerde identiteiten uit een on-premises Active Directory, naar het beheerde domein. Probeer Entra Domain Services nooit als primaire directory te gebruiken om gebruikerskenmerken te wijzigen, want die wijzigingen worden niet teruggesynchroniseerd naar de bron en worden uiteindelijk overschreven.

Besliskader: de juiste architectuurkeuze maken

Welke aanpak het beste past, hangt af van de specifieke technische eisen van je organisatie en de lange termijn van je cloudstrategie. Als je primaire doel is om legacy-workloads naar Azure te migreren en de operationele last van het draaien van Windows Server-virtuele machines als domeincontroller weg te nemen, is een beheerde dienst bijna altijd de voorkeursroute.

Kies Microsoft Entra Domain Services wanneer:

• Je legacy-applicaties naar Azure migreert die LDAP-leesopzoekingen, Kerberos, NTLM of domein-join-mogelijkheden nodig hebben.
• Je organisatie de extra werkzaamheden van patchen, monitoren en herstellen van zelfgebouwde domeincontroller-virtuele machines in Azure wil vermijden.
• Je een cloud-first- of cloud-only-organisatie bent en traditionele domeindiensten nodig hebt voor een kleine subset van Azure-workloads, zonder on-premises infrastructuur op te bouwen.
• Applicaties standaard groepsbeleid of serviceaccountbeheer nodig hebben binnen een beveiligd virtueel netwerk.

Kies zelfgebouwde IaaS-domeincontrollers wanneer:

• Je legacy-applicaties LDAP-schrijftoegang nodig hebben of wijzigingen in het Active Directory-schema vereisen.
• Je enterprise-architectuur complexe multi-domeinforesten, aangepaste vertrouwensconfiguraties of directe toegang tot de besturingssystemen van domeincontrollers vereist.
• Je beveiligingsteam volledige beheerderscontrole eist, inclusief Enterprise Admin-rechten en directe implementatie van gespecialiseerde tools voor directory-auditing.

Conclusie en volgende stappen

Een robuuste identiteitsarchitectuur in Azure vraagt om per workload het juiste authenticatiemodel te kiezen. Moderne cloudapplicaties gebruiken Microsoft Entra ID voor veilige, op tokens gebaseerde single sign-on en multifactorauthenticatie, terwijl legacy-workloads vaak traditionele Windows-domeinservices nodig hebben. De keuze tussen beheerde cloudservices of je eigen IaaS-infrastructuur bepaalt hoeveel operationeel werk je team er blijvend van heeft.

Wil je dit onderwerp verder verkennen en meer horen over modern werkplekbeveiliging, cloudarchitectuur en Microsoft 365-strategieën? Luister dan de volledige discussie in de podcast. Luister de volledige aflevering om dieper in te gaan op identiteitsbeheer bij Microsoft.

Veelgestelde vragen

Kan ik via RDP verbinding maken met domeincontrollers wanneer ik Entra Domain Services gebruik?

Nee. Microsoft beheert de onderliggende domeincontrollerinfrastructuur volledig. Je hebt dus geen beheerderstoegang tot het besturingssysteem en kunt ook niet via Extern bureaublad verbinding maken met de domeincontrollers.

Wat gebeurt er met gebruikerswachtwoorden wanneer ik Entra Domain Services inschakel?

Voor authenticatie via Kerberos en NTLM heeft Entra Domain Services speciale hashgegevens nodig. Voor cloud-only gebruikers betekent dit meestal dat ze na het inschakelen van het beheerde domein hun wachtwoord moeten wijzigen, zodat de benodigde cryptografische hashes worden aangemaakt.

Kan ik het Active Directory-schema aanpassen in Entra Domain Services?

Nee. Omdat het een volledig beheerde cloudservice is, kunnen beheerders het onderliggende Active Directory-schema niet wijzigen en ook geen LDAP-schrijfbewerkingen uitvoeren die kernstructuren van de directory aanpassen.

Hoe worden identiteiten gesynchroniseerd met Entra Domain Services?

Identiteiten stromen eenrichtingsverkeer van je autoritatieve bron (Entra ID voor cloudgebruikers, of on-premises Active Directory via Microsoft Entra Connect) naar het beheerde domein. Wijzigingen die direct in het beheerde domein worden gemaakt, worden niet terug gesynchroniseerd naar de bron.