Migrer des applications héritées vers Azure : quand choisir Microsoft Entra Domain Services ou des contrôleurs de domaine IaaS

By Mirko Peters · 2026-08-14

Comparez Microsoft Entra Domain Services et les contrôleurs de domaine IaaS dans Azure. Découvrez les compromis d’architecture pour migrer des applications héritées.

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

Lorsque vous migrez en l’état des applications Windows héritées vers Azure, les architectes sont confrontés à un dilemme critique concernant l’identité : faut-il déployer des machines virtuelles de contrôleur de domaine Active Directory traditionnelles ou recourir à des services cloud managés ? Ce guide examine les compromis d’architecture, la charge opérationnelle et les implications financières du choix de Microsoft Entra Domain Services plutôt que de contrôleurs de domaine IaaS personnalisés pour les charges de travail héritées dans Azure.

Points clés

• Microsoft Entra Domain Services fournit les fonctionnalités d’un domaine Windows traditionnel sous forme managée, sans que les équipes informatiques aient à déployer, mettre à jour ou restaurer des machines virtuelles de contrôleur de domaine.
• Le déploiement de contrôleurs de domaine IaaS dans Azure offre aux administrateurs un contrôle total, y compris l’accès RDP et les privilèges d’administrateur de domaine, mais alourdit considérablement la charge opérationnelle.
• Les charges de travail qui reposent sur LDAP, Kerberos, NTLM ou la stratégie de groupe peuvent s’exécuter sans heurt dans Azure grâce à une couche de compatibilité de domaine managé.
• Entra Domain Services impose un modèle de synchronisation des identités strictement unidirectionnel : les comptes utilisateurs doivent être gérés à leur source faisant autorité, et non directement dans le domaine managé.
• Le choix de l’architecture d’identité adaptée dépend fortement des exigences applicatives, notamment l’accès en écriture LDAP et les modifications de schéma.

Le dilemme de la migration des charges héritées vers Azure

Déplacer une application métier héritée d’une salle serveur locale vers une machine virtuelle Azure ne rend pas automatiquement cette application « cloud native ». De nombreuses applications Windows établies, comme les anciens progiciels de gestion intégrée, les plateformes financières et les applications .NET personnalisées, ont été conçues autour d’Active Directory traditionnel. Lorsque ces charges de travail arrivent dans le cloud, elles attendent toujours d’interroger l’annuaire via LDAP, de s’authentifier à l’aide de tickets Kerberos ou d’appliquer des paramètres via la stratégie de groupe.

Les architectes cloud doivent immédiatement prendre une décision stratégique. Vous pouvez relier votre réseau virtuel Azure à vos contrôleurs de domaine locaux à l’aide d’un tunnel VPN hybride, mais cela introduit de la latence et crée un point de défaillance unique dangereux si la liaison réseau tombe. Vous pouvez aussi créer de nouvelles machines virtuelles Windows Server dans Azure, les promouvoir en contrôleurs de domaine et mettre en place une forêt ou un domaine réplica entièrement nouveaux.

Si la création de vos propres machines virtuelles de contrôleur de domaine dans Azure vous donne un contrôle total, elle fait aussi de votre équipe d’infrastructure cloud des administrateurs Active Directory à part entière. Vous devenez entièrement responsable de la mise à jour du système d’exploitation, de la surveillance de la réplication de l’annuaire, de la planification de la reprise après sinistre et de la protection des comptes à privilèges élevés contre le vol d’identifiants. Pour les organisations qui cherchent à réduire leur charge opérationnelle tout en maintenant leurs applications héritées en service, c’est souvent une contrainte inutile.

Entra Domain Services et contrôleurs de domaine IaaS : principales différences d’architecture

Comprendre la distinction architecturale entre l’utilisation de Microsoft Entra Domain Services et la mise en place de contrôleurs de domaine IaaS personnalisés est essentiel pour concevoir des environnements cloud Azure résilients. Entra Domain Services agit comme une couche de compatibilité managée. Microsoft exploite et maintient l’infrastructure sous-jacente des contrôleurs de domaine en coulisse, en assurant la haute disponibilité, les sauvegardes automatiques et la synchronisation en arrière-plan avec Entra ID.

Lorsque vous utilisez Entra Domain Services, vos machines virtuelles Azure peuvent rejoindre le domaine, exécuter des requêtes LDAP et gérer les authentifications Kerberos ou NTLM sans que vos ingénieurs aient jamais besoin de se connecter à distance à un contrôleur de domaine. Toutefois, ce service managé implique un compromis : vous renoncez au contrôle administratif direct. Vous ne pouvez pas accéder au système d’exploitation sous-jacent, vous ne pouvez pas modifier le schéma Active Directory, et vous ne recevez pas les privilèges Admins du domaine ou Administrateurs de l’entreprise.

À l’inverse, déployer des contrôleurs de domaine IaaS vous donne un pouvoir total sur l’architecture de l’annuaire. Vous pouvez étendre le schéma, configurer des relations d’approbation personnalisées, ajouter des unités d’organisation sans restriction et mettre en œuvre des objets de stratégie de groupe spécialisés. En contrepartie, cette flexibilité a un coût : la maintenance. Votre équipe doit gérer l’intégralité du cycle de vie du domaine, y compris les contrôles d’intégrité proactifs, la défragmentation de la base de données et les procédures de restauration d’urgence en cas de panne d’un contrôleur de domaine.

Compromis opérationnels et garde-fous administratifs

Avant de vous engager dans une approche de domaine managé dans Azure, les administrateurs cloud doivent évaluer précisément l’impact sur les opérations quotidiennes. Avec des contrôleurs de domaine IaaS personnalisés, votre équipe dispose d’un contrôle granulaire sur chaque aspect de l’annuaire. Vous pouvez écrire des scripts PowerShell personnalisés pour automatiser les tâches d’administration, installer directement sur les contrôleurs de domaine des agents de sécurité tiers et diagnostiquer les erreurs de réplication à l’aide d’utilitaires natifs comme repadmin.

Microsoft Entra Domain Services remplace cette approche pratique par des garde-fous managés. L’administration s’effectue via un groupe dédié, Entra Domain Services Administrators, à l’aide d’utilitaires de gestion installés sur une machine virtuelle Windows distincte, jointe au domaine. Bien que vous puissiez créer des unités d’organisation personnalisées, gérer les enregistrements DNS et appliquer les paramètres de stratégie de groupe pris en charge, vous êtes strictement tenu à l’écart de l’infrastructure centrale.

Par ailleurs, la gestion des identités suit un modèle de synchronisation strictement unidirectionnel. Les identités des utilisateurs et des groupes circulent depuis votre source faisant autorité (utilisateurs cloud uniquement dans Entra ID, ou identités synchronisées depuis un Active Directory local) vers le domaine managé. Ne tentez jamais de considérer Entra Domain Services comme un annuaire principal pour modifier les attributs des utilisateurs : ces modifications ne seront pas synchronisées en amont et finiront par être écrasées.

Cadre de décision : faire le bon choix d’architecture

Le choix de la bonne approche suppose d’évaluer les exigences techniques spécifiques de votre organisation ainsi que sa stratégie cloud à long terme. Si votre objectif principal est de migrer des charges de travail héritées vers Azure tout en supprimant la charge opérationnelle liée à l’exploitation de machines virtuelles Windows Server en tant que contrôleurs de domaine, un service managé est presque toujours la voie à privilégier.

Utilisez Microsoft Entra Domain Services lorsque :

• Vous migrez vers Azure des applications héritées qui nécessitent des recherches LDAP en lecture, Kerberos, NTLM ou des capacités de jonction au domaine.
• Votre organisation souhaite éviter la charge liée à l’application des correctifs, à la supervision et à la restauration des machines virtuelles de contrôleurs de domaine personnalisés dans Azure.
• Vous exploitez une organisation « cloud-first » ou exclusivement cloud et avez besoin de services de domaine traditionnels pour un petit sous-ensemble de charges de travail Azure, sans construire d’infrastructure sur site.
• Les applications requièrent l’application standard des stratégies de groupe ou la gestion des comptes de service au sein d’un réseau virtuel sécurisé.

Choisissez des contrôleurs de domaine IaaS personnalisés lorsque :

• Vos applications héritées requièrent un accès en écriture LDAP ou exigent des modifications du schéma Active Directory.
• L’architecture de votre entreprise impose des forêts multidomaines complexes, des configurations d’approbation personnalisées ou un accès direct aux systèmes d’exploitation des contrôleurs de domaine.
• Votre équipe de sécurité impose un contrôle administratif complet, y compris les privilèges Administrateurs de l’entreprise, et le déploiement direct d’outils spécialisés d’audit de l’annuaire.

Conclusion et prochaines étapes

La conception d’une architecture d’identité robuste dans Azure exige de faire correspondre chaque charge de travail au modèle d’authentification exact dont elle a besoin. Si les applications cloud modernes s’appuient sur Microsoft Entra ID pour une authentification unique sécurisée reposant sur des jetons, ainsi que sur l’authentification multifacteur, les charges de travail héritées nécessitent souvent les services de domaine Windows traditionnels. Le choix entre le déploiement de services cloud managés et la construction de votre propre infrastructure IaaS détermine la charge opérationnelle continue de votre équipe.

Pour approfondir ce sujet et entendre l’avis d’experts sur la sécurité du poste de travail moderne, l’architecture cloud et les stratégies Microsoft 365, écoutez la discussion complète dans le podcast. Écoutez l’épisode complet pour approfondir la gestion des identités Microsoft.

Questions fréquentes

Puis-je me connecter en RDP aux contrôleurs de domaine lorsque j’utilise Entra Domain Services ?

Non. Microsoft gère entièrement l’infrastructure sous-jacente des contrôleurs de domaine, ce qui signifie que vous n’avez pas d’accès administrateur au système d’exploitation et ne pouvez pas établir de connexion Bureau à distance vers les contrôleurs de domaine.

Que se passe-t-il pour les mots de passe des utilisateurs lorsque j’active Entra Domain Services ?

Pour que l’authentification Kerberos et NTLM réussisse, Entra Domain Services a besoin de données de hachage spécifiques. Pour les utilisateurs cloud uniquement, cela implique généralement que les utilisateurs modifient leur mot de passe une fois le domaine managé activé, afin de générer les hachages cryptographiques nécessaires.

Puis-je modifier le schéma Active Directory dans Entra Domain Services ?

Non. Comme il s’agit d’un service cloud entièrement managé, les administrateurs ne peuvent pas modifier le schéma Active Directory sous-jacent ni effectuer d’opérations d’écriture LDAP qui modifient les structures d’annuaire essentielles.

Comment les identités se synchronisent-elles avec Entra Domain Services ?

Les identités circulent de manière unidirectionnelle depuis votre source faisant autorité (Entra ID pour les utilisateurs cloud, ou Active Directory local via Microsoft Entra Connect) vers le domaine managé. Les modifications effectuées directement dans le domaine managé ne sont pas resynchronisées vers la source.