Comparer les services de domaine Active Directory autogérés, l’ID Microsoft Entra et les services de domaine Microsoft Entra gérés
Pour fournir des applications, des services ou des appareils qui accèdent à une identité centrale, il existe trois façons courantes d’utiliser des services basés sur Active Directory dans Azure. Ce choix dans les 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 cloud uniquement qui exécutent des appareils mobiles, il peut ne pas être judicieux de créer et d’exécuter votre propre solution d’identité Active Directory Domain Services (AD DS). Au lieu de cela, vous pouvez simplement utiliser l’ID Microsoft Entra.
Bien que les trois solutions d’identité basées sur Active Directory partagent un nom commun et une technologie, elles sont conçues pour fournir des services répondant à différentes demandes des clients. À haut niveau, ces solutions d’identité et ces ensembles de fonctionnalités sont les suivants :
- Active Directory Domain Services (AD DS) - Serveur LDAP 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 relations de confiance.
- 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’ordinateur 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ées sur le cloud qui fournit des services de compte d’utilisateur et d’authentification pour les 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 fonctionnent en mode natif dans le cloud.
- Pour plus d’informations sur l’ID Microsoft Entra, consultez Qu’est-ce que l’ID Microsoft Entra ?
- Microsoft Entra Domain Services : fournit des services de domaine managés avec un sous-ensemble de fonctionnalités AD DS traditionnelles compatibles, telles que la jonction de domaine, la stratégie de groupe, LDAP et Kerberos/NTLM.
- Domain Services s’intègre à l’ID Microsoft Entra, qui peut se synchroniser avec un environnement AD DS local. Cette capacité étend les cas d’utilisation d’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 l’ID Microsoft Entra et localement, consultez Comment les objets et les informations d’identification sont synchronisés dans un domaine managé.
Cet article de vue d’ensemble compare et contraste la façon dont ces solutions d’identité peuvent fonctionner ensemble, ou serait utilisé indépendamment, en fonction des besoins de votre organisation.
Services de domaine et AD DS auto-gérés
Si vous avez des applications et des services qui ont besoin d’accéder à des mécanismes d’authentification traditionnels tels que Kerberos ou NTLM, il existe deux façons de fournir des services de domaine Active Directory 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 auto-géré que vous créez et configurez à l’aide de ressources traditionnelles telles que des machines virtuelles, le système d’exploitation invité Windows Server et les services de domaine Active Directory (AD DS). Vous continuez ensuite à administrer ces ressources.
Avec Domain Services, les principaux composants de service sont déployés et gérés par Microsoft en tant qu’expérience de domaine managée. Vous ne déployez pas, gérez, corrigez et sécurisez l’infrastructure AD DS pour les composants tels que les machines virtuelles, le système d’exploitation Windows Server ou les contrôleurs de domaine (DCS).
Domain Services fournit un sous-ensemble plus petit de fonctionnalités à l’environnement AD DS auto-managé traditionnel, ce qui réduit la complexité de la conception et de la gestion. Par exemple, il n’existe pas de forêts AD, de domaine, de sites et de liens de réplication pour concevoir et gérer. 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 tels que Kerberos ou NTLM, les services de domaine offrent une expérience de domaine managé avec le minimum de surcharge administrative. Pour plus d’informations, consultez Concepts de gestion des comptes d’utilisateur, des mots de passe et de l’administration dans Domain Services.
Lorsque vous déployez et exécutez un environnement AD DS auto-géré, vous devez gérer tous les composants d’infrastructure et d’annuaire 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 auto-géré qui fournit une identité aux applications et services dans le cloud incluent les éléments suivants :
- AD DS autonome - Les machines virtuelles Azure sont configurées en tant que contrôleurs de domaine et un environnement AD DS distinct et cloud uniquement est créé. Cet environnement AD DS ne s’intègre pas à un environnement AD DS local. Un autre ensemble d’informations d’identification est utilisé pour se connecter et administrer des machines virtuelles dans le cloud.
- étendre le 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 réplica à partir du domaine AD DS local. Ces contrôleurs de domaine répliquent via une connexion VPN/ExpressRoute dans l'environnement AD DS local. Le domaine AD DS local est étendu efficacement à Azure.
Le tableau suivant présente certaines des fonctionnalités dont vous avez besoin pour votre organisation et les différences entre un domaine managé ou un domaine AD DS auto-géré :
| Fonctionnalité | domaine managé | AD DS automanagé |
|---|---|---|
| Service géré | ✓ | ✕ |
| déploiements sécurisés | ✓ | L’administrateur sécurise le déploiement |
| serveur DNS | ✓ (service managé) | ✓ |
| privilèges d’administrateur de domaine ou d’entreprise | ✕ | ✓ |
| Jonction de domaine | ✓ | ✓ |
| Authentification de domaine utilisant 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 | ✓ (L'aperçu nécessite la version Entreprise SKU) | ✓ |
| LDAP sécurisé (LDAPS) | ✓ | ✓ |
| Lecture LDAP | ✓ | ✓ |
| Écriture LDAP | ✓ (dans le domaine managé) | ✓ |
| déploiements géo-distribués | ✓ | ✓ |
Services de domaine et ID Microsoft Entra
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 d’entreprise à partir de ces appareils. Les utilisateurs peuvent également inscrire leur appareil personnel (un modèle BYO) avec l’ID Microsoft Entra, qui fournit à l’appareil une identité. 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. L’appareil peut être géré à l’aide de logiciels mdm (Mobile Device Management) comme Microsoft Intune. Cette capacité de gestion vous permet de restreindre l’accès aux ressources sensibles aux appareils gérés et conformes aux stratégies.
Les ordinateurs et ordinateurs portables traditionnels peuvent également se joindre à Microsoft Entra ID. Ce mécanisme offre les mêmes avantages que l’inscription d’un appareil personnel avec l’ID Microsoft Entra, 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 :
- Authentification unique (SSO) aux applications sécurisées par l’ID Microsoft Entra.
- 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 à l’aide des informations d’identification d’entreprise.
- Windows Hello Entreprise.
- Accès restreint aux applications et aux ressources à partir d’appareils conformes à la stratégie d’entreprise.
Les appareils peuvent être joints à l’ID Microsoft Entra avec ou sans déploiement hybride incluant 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 seraient 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 non joint à AD DS local | Windows 10 | Joint à Microsoft Entra |
| Appareil appartenant à l’organisation joint à un ad DS local | Windows 10 | Jonction hybride Microsoft Entra |
Sur un appareil joint ou inscrit à Microsoft Entra, l’authentification utilisateur se produit à l’aide de protocoles modernes OAuth / OpenID Connect. Ces protocoles sont conçus pour fonctionner sur Internet. Ils sont donc parfaits pour les scénarios mobiles où les utilisateurs accèdent aux ressources d’entreprise n’importe où.
Avec les appareils joints aux services de domaine, les applications peuvent utiliser les protocoles Kerberos et NTLM pour l’authentification, afin de 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 dans la façon dont les appareils sont représentés et peuvent s’authentifier sur le répertoire :
| Aspect | Jonction Microsoft Entra | Joint à Domain Services |
|---|---|---|
| Appareil contrôlé par | Microsoft Entra ID | Domaine géré par les services de domaine |
| Représentation dans le répertoire | Objets d’appareil dans le répertoire Microsoft Entra | Objets d'ordinateurs dans le domaine géré par les services de domaine |
| Authentification | Protocoles OAuth et OpenID Connect | Protocoles Kerberos et NTLM |
| Gestion | Logiciel de gestion des appareils mobiles (GPM) comme Intune | Stratégie de groupe |
| Réseautage | Fonctionne sur Internet | Doit être connecté à ou associé avec le réseau virtuel sur lequel le domaine managé est déployé. |
| Idéal pour... | Appareils mobiles ou de bureau des utilisateurs finaux | Machines virtuelles serveur déployées dans Azure |
Si les ID AD DS et Microsoft Entra locaux sont configurés pour l’authentification fédérée à l’aide d’AD FS, il n’existe aucun hachage de mot de passe (actuel/valide) disponible dans Azure DS. Les comptes d’utilisateur Microsoft Entra créés avant l’implémentation de l’authentification fed peuvent avoir un ancien hachage de mot de passe, mais cela ne correspond probablement pas à un hachage de leur mot de passe local. Par conséquent, les services de domaine ne pourront pas valider les informations d’identification des utilisateurs
Étapes suivantes
Pour commencer à utiliser Domain Services, créer un domaine managé Domain Services à l’aide du Centre d’administration Microsoft Entra.
Vous pouvez également en savoir plus sur les concepts de gestion pour les comptes d’utilisateur, les mots de passe et l’administration dans Domain Services et comment les objets et les informations d’identification sont synchronisés dans un domaine managé.