Comparer les services de domaine Active Directory autogérés, Microsoft Entra ID et les services de domaine Microsoft Entra gérés
Pour fournir aux applications, aux services ou aux appareils un accès à une identité centrale, il existe trois façons courantes d’utiliser des services Active Directory dans Azure. Ce choix de solutions d’identité vous offre la possibilité d’utiliser le répertoire le plus approprié pour les besoins de votre organisation. Par exemple, si vous gérez principalement des utilisateurs uniquement dans le cloud qui exécutent des appareils mobiles, il n’est pas judicieux de créer et d’exécuter votre propre solution d’identité Active Directory Domain Services (AD DS). Vous pouvez plutôt simplement utiliser Microsoft Entra ID.
Même si les trois solutions d’identité basées sur Active Directory ont un nom et une technologie en commun, elles sont conçues pour fournir des services qui répondent à différentes demandes des clients. Au niveau supérieur, ces solutions d’identité et ensembles de fonctionnalités sont les suivants :
- Active Directory Domain Services (AD DS) : serveur LDAP (Lightweight Directory Access Protocol) prêt pour l’entreprise qui fournit des fonctionnalités clés telles que l’identité et l’authentification, la gestion des objets ordinateur, la stratégie de groupe et les approbations.
- AD DS est un composant central dans de nombreuses organisations disposant d’un environnement informatique local et fournit des fonctionnalités d’authentification de compte d’utilisateur et de gestion d’ordinateurs de base.
- Pour plus d’informations, consultez Vue d’ensemble d’Active Directory Domain Services dans la documentation de Windows Server.
- Microsoft Entra ID – gestion des identités et des appareils mobiles basée sur le cloud qui fournit des services de compte utilisateur et d'authentification pour des ressources telles que Microsoft 365, le centre d'administration Microsoft Entra ou les applications SaaS.
- Microsoft Entra ID peut être synchronisé avec un environnement AD DS local pour fournir une identité unique aux utilisateurs qui travaillent en mode natif dans le cloud.
- Pour en savoir plus sur Microsoft Entra ID, reportez-vous à Qu'est-ce que Microsoft Entra ID ?
- Microsoft Entra Domain Services : fournit des services de domaine managés avec un sous-ensemble de fonctionnalités AD DS traditionnelles entièrement compatibles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l'authentification Kerberos/NTLM.
- Domain Services s'intègre à Microsoft Entra ID, qui lui-même peut se synchroniser avec un environnement AD DS local. Cette capacité étend les cas d’usage de l’identité centrale aux applications web traditionnelles qui s’exécutent dans Azure dans le cadre d’une stratégie lift-and-shift.
- Pour en savoir plus sur la synchronisation avec Microsoft Entra ID et en local, reportez-vous à Synchronisation des objets et des informations d'identification dans un domaine managé.
Cet article de vue d’ensemble compare la façon dont ces solutions d’identité peuvent fonctionner ensemble ou être utilisées indépendamment, en fonction des besoins de votre organisation.
Domain Services et AD DS autogéré
Si vous avez des applications et des services qui doivent accéder à des mécanismes d’authentification traditionnels tels que Kerberos ou NTLM, il existe deux façons de fournir Active Directory Domain Services dans le cloud :
- Un domaine managé que vous créez à l'aide de Microsoft Entra Domain Services. Microsoft crée et gère les ressources requises.
- Un domaine automanagé que vous créez et configurez à l’aide de ressources traditionnelles telles que les machines virtuelles, le système d’exploitation invité Windows Server et AD DS (Active Directory Domain Services). Vous continuez ensuite à administrer ces ressources.
Avec Domain Services, les composants de service de base sont déployés et gérés pour vous par Microsoft en tant qu'expérience de domaine managé. Vous ne pouvez pas déployer, gérer, corriger et sécuriser l’infrastructure AD DS pour des composants tels que les machines virtuelles, le système d’exploitation Windows Server ou les contrôleurs de domaine.
Domain Services fournit un sous-ensemble plus petit de fonctionnalités à un environnement AD DS automanagé traditionnel, ce qui réduit la complexité de la conception et de la gestion. Par exemple, il n’existe pas de forêts, de domaines, de sites et de liens de réplication Active Directory à concevoir ni à entretenir. Vous pouvez toujours créer des approbations de forêt entre des environnements Domain Services et locaux.
Pour les applications et les services qui s'exécutent dans le cloud et qui ont besoin d'accéder à des mécanismes d'authentification traditionnels, notamment Kerberos ou NTLM, Domain Services offre une expérience de domaine managé avec charge administrative minimale. Pour en savoir plus, reportez-vous à Concepts de gestion pour les comptes d'utilisateur, les mots de passe et l'administration dans Domain Services.
Lorsque vous déployez et exécutez un environnement AD DS automanagé, vous devez gérer tous les composants d’infrastructure et de répertoire associés. Il existe une surcharge de maintenance supplémentaire avec un environnement AD DS automanagé, mais vous pouvez ensuite effectuer des tâches supplémentaires, telles que l’extension du schéma ou la création d’approbations de forêt.
Les modèles de déploiement courants pour un environnement AD DS automanagé qui fournit l’identité aux applications et services dans le cloud sont les suivants :
- Instance AD DS autonome et cloud uniquement : les machines virtuelles Azure sont configurées en tant que contrôleurs de domaine et un environnement distinct AD DS cloud uniquement est créé. Cet environnement AD DS ne s’intègre pas à un environnement AD DS local. Un ensemble différent d’informations d’identification est utilisé pour la connexion et l’administration des machines virtuelles dans le cloud.
- Étendre un domaine local à Azure : un réseau virtuel Azure se connecte à un réseau local à l’aide d’une connexion VPN/ExpressRoute. Les machines virtuelles Azure se connectent à ce réseau virtuel Azure, ce qui leur permet de joindre un domaine à l’environnement AD DS local.
- Une alternative consiste à créer des machines virtuelles Azure et à les promouvoir en tant que contrôleurs de domaine de réplication à partir du domaine AD DS local. Ces contrôleurs de domaine répliquent via une connexion VPN/ExpressRoute vers l’environnement local AD DS. Le domaine AD DS local est efficacement étendu dans Azure.
Le tableau suivant présente certaines des fonctionnalités dont vous pouvez avoir besoin pour votre organisation, ainsi que les différences entre un domaine managé et un domaine automanagé AD DS :
| Fonctionnalité | Domaine managé | AD DS automanagé |
|---|---|---|
| Service managé | ✓ | ✕ |
| Déploiements sécurisés | ✓ | L’administrateur sécurisee le déploiement. |
| Serveur DNS | ✓ (service géré) | ✓ |
| Privilèges d’administrateur d’entreprise ou de domaine | ✕ | ✓ |
| jonction de domaine | ✓ | ✓ |
| Authentification de domaine à l’aide de NTLM et Kerberos | ✓ | ✓ |
| Délégation Kerberos contrainte | Basé sur des ressources | Basée sur des ressources et basé sur des comptes |
| Structure d’unité d’organisation personnalisée | ✓ | ✓ |
| Stratégie de groupe | ✓ | ✓ |
| Extensions de schéma | ✕ | ✓ |
| Approbations de domaine/forêt AD | ✓ (approbations de forêt sortantes unidirectionnelles uniquement) | ✓ |
| LDAP sécurisé (LDAPS) | ✓ | ✓ |
| Lecture LDAP | ✓ | ✓ |
| Écriture LDAP | ✓ (dans le domaine managé) | ✓ |
| Déploiements géolocalisés | ✓ | ✓ |
Domain Services et Microsoft Entra ID
Microsoft Entra ID vous permet de gérer l'identité des appareils utilisés par l'organisation et de contrôler l'accès aux ressources de l'entreprise depuis ces appareils. Les utilisateurs peuvent aussi inscrire leur appareil personnel (modèle BYO, bring-your-own) sur Microsoft Entra ID, ce qui fournit une identité à l'appareil. Microsoft Entra ID authentifie ensuite l'appareil lorsqu'un utilisateur se connecte à Microsoft Entra ID et utilise l'appareil pour accéder aux ressources sécurisées. Vous pouvez gérer l’appareil à l’aide de logiciels de gestion des appareils mobiles (MDM), tels que Microsoft Intune. Cette fonctionnalité de gestion vous permet de restreindre l’accès aux ressources sensibles à partir d’appareils gérés et conformes aux stratégies.
Les ordinateurs traditionnels et les ordinateurs portables peuvent également être joints à Microsoft Entra ID. Ce mécanisme offre les mêmes avantages que l'inscription d'un appareil personnel sur Microsoft Entra ID, par exemple pour permettre aux utilisateurs de se connecter à l'appareil à l'aide de leurs informations d'identification d'entreprise.
Les appareils joints à Microsoft Entra vous offrent les avantages suivants :
- L'authentification unique (SSO) pour les applications est sécurisée par Microsoft Entra ID.
- Itinérance compatible avec la stratégie de l’entreprise pour les paramètres utilisateur sur les appareils.
- Accès au Windows Store pour Entreprises avec vos informations d’identification professionnelles.
- Windows Hello Entreprise.
- Accès restreint aux applications et aux ressources sur les appareils conformes à la stratégie d’entreprise.
Les appareils peuvent être joints à Microsoft Entra ID avec ou sans déploiement hybride qui inclut un environnement AD DS local. Le tableau suivant présente les modèles de propriété d’appareil courants et la façon dont ils sont généralement joints à un domaine :
| Type d’appareil | Plateformes d’appareils | Mécanisme |
|---|---|---|
| Appareils personnels | Windows 10, iOS, Android, macOS | Inscrit auprès de Microsoft Entra |
| Appareil appartenant à l’organisation et non joint à AD DS local | Windows 10 | Joint à Microsoft Entra |
| Appareil appartenant à l’organisation et joint à AD DS local | Windows 10 | Jonction hybride Microsoft Entra |
Sur un appareil inscrit ou joint à Microsoft Entra, l'authentification de l'utilisateur s'effectue par le biais des protocoles modernes OAuth/OpenID Connect. Ces protocoles sont conçus pour fonctionner sur Internet et sont très utiles dans les scénarios de mobilité, où les utilisateurs accèdent aux ressources d’entreprise depuis n’importe quel endroit.
Avec les appareils joints à Domain Services, les applications peuvent utiliser les protocoles Kerberos et NTLM pour l'authentification. Par conséquent, ils peuvent prendre en charge les applications héritées migrées pour s'exécuter sur des machines virtuelles Azure dans le cadre d'une stratégie lift-and-shift. Le tableau suivant présente les différences entre la façon dont les appareils sont représentés et peuvent s’authentifier auprès du répertoire :
| Aspect | Jonction Microsoft Entra | Joint à Domain Services |
|---|---|---|
| Appareil contrôlé par | Microsoft Entra ID | Domaine managé par Domain Services |
| Représentation dans l’annuaire | Objets d'appareil dans le répertoire Microsoft Entra | Objets ordinateur dans le domaine managé Domain Services |
| Authentification | Protocoles OAuth et OpenID Connect | Protocoles Kerberos et NTLM |
| Gestion | Logiciels de gestion des appareils mobiles (GAM) tels qu’Intune | Stratégie de groupe |
| Mise en réseau | Fonctionne sur Internet | Doit être connecté ou appairé au réseau virtuel sur lequel le domaine managé est déployé |
| Idéal pour... | Appareils mobiles ou de bureau des utilisateurs finaux | Machines virtuelles de serveur déployées dans Azure |
Si l'environnement local AD DS et Microsoft Entra ID sont configurés pour l'authentification fédérée avec AD FS, aucun hachage de mot de passe (actuel/valide) n'est disponible dans Azure DS. Il est possible que les comptes d'utilisateurs Microsoft Entra créés avant l'implémentation de l'authentification fédérée disposent d'un ancien hachage de mot de passe, mais il est peu probable que celui-ci corresponde à un hachage de leur mot de passe local. Par conséquent, Domain Services ne pourra pas valider les informations d'identification des utilisateurs.
Étapes suivantes
Pour démarrer avec Domain Services, créez un domaine géré par Domain Services à l'aide du centre d'administration Microsoft Entra.
Consultez également les pages Concepts de gestion pour les comptes d'utilisateur, les mots de passe et l'administration dans Domain Services et Synchronisation des objets et des informations d'identification dans un domaine managé.