Azure Active Directory Domain Services

Parlez-nous de l’expérience de téléchargement de PDF.
Documentation sur Azure AD Domain

Services
Découvrez comment utiliser Azure Active Directory Domain Services pour fournir une
authentification Kerberos ou NTLM aux applications ou joindre des machines virtuelles
Azure à un domaine managé.
À propos d’Azure AD Domain Services
ｅ VUE D’ENSEMBLE
Présentation d’Azure AD Domain Services
Comparer les solutions d’identité
ｐ CONCEPT
Comment fonctionne la synchronisation ?
FAQ
Bien démarrer
｀ DÉPLOYER
Créer un domaine managé
ｇ DIDACTICIEL
Joindre une machine virtuelle Windows Server à un domaine
Installer des outils de gestion
Configurer
ｇ DIDACTICIEL
Configurer le protocole LDAP sécurisé

ｃ GUIDE PRATIQUE
Activer la synchronisation de hachage de mot de passe
Créer une unité d’organisation
Configurer une délégation Kerberos contrainte
Sécuriser un domaine managé
Gérer
ｃ GUIDE PRATIQUE
Administrer la stratégie de groupe
Gérer DNS
Vérifier l’état d’intégrité
Configurer les notifications par e-mail
Activer les audits de sécurité
Joindre des machines virtuelles à un domaine
ｇ DIDACTICIEL
Windows Server
ｃ GUIDE PRATIQUE
Serveur Ubuntu
Red Hat Enterprise Linux
SUSE Linux Enterprise
Dépanner
ｃ GUIDE PRATIQUE
Problèmes courants
Messages d’alerte courants
Problèmes de groupe de sécurité réseau
Problèmes de protocole LDAP sécurisé

Présentation d’Azure Active Directory
Domain Services
Article • 12/04/2023
Azure Active Directory Domain Services (Azure AD DS) fournit des services de domaine
managés, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et
l’authentification Kerberos/NTLM. Vous utilisez ces services de domaine sans avoir à
déployer, gérer et apporter des correctifs aux contrôleurs de domaine dans le cloud.
Un domaine managé Azure AD DS vous permet d’exécuter des applications héritées

dans le cloud qui ne peuvent pas utiliser les méthodes d'authentification modernes ou
pour lesquelles vous ne voulez pas que les recherches de répertoire retournent
systématiquement à un environnement AD DS local. Vous pouvez effectuer un lift-and-
shift de ces applications héritées de votre environnement local à un domaine managé
sans devoir gérer l’environnement AD DS dans le cloud.
Azure AD DS s’intègre à votre locataire Azure AD existant. Cette intégration permet aux
utilisateurs de se connecter aux services et aux applications connectés au domaine
managé à l’aide de leurs informations d’identification existantes. Vous pouvez
également utiliser des comptes d’utilisateurs et des groupes existants pour sécuriser
l’accès aux ressources. Ces fonctionnalités fournissent une migration lift-and-shift plus
simple des ressources locales vers Azure.
Pour commencer, créez un domaine managé Azure AD DS à l’aide du portail Azure

.
Jetez un coup d’œil à notre courte vidéo pour en savoir plus sur Azure AD DS.
https://www.microsoft.com/fr-fr/videoplayer/embed/RE4LblD?
postJsllMsg=true&autoCaptions=fr-fr
Fonctionnement d’Azure AD DS
Quand vous créez un domaine managé Azure AD DS, vous définissez un espace de
noms unique. Cet espace de noms est le nom de domaine, par exemple
aaddscontoso.com. Deux contrôleurs de domaine Windows Server sont ensuite déployés
dans votre région Azure sélectionnée. Ce déploiement de contrôleurs de domaine est
appelé jeu de réplicas.
Vous n’avez pas besoin de gérer, configurer ou mettre à jour ces contrôleurs de
domaine. La plateforme Azure gère les contrôleurs de domaine comme faisant partie du
domaine managé, y compris les sauvegardes et le chiffrement au repos utilisant Azure
Disk Encryption.
Un domaine managé est configuré pour effectuer une synchronisation unidirectionnelle

à partir d’Azure AD, afin de fournir l’accès à un ensemble centralisé d’utilisateurs, de
groupes et d’informations d’identification. Vous pouvez créer des ressources
directement dans le domaine managé, mais elles ne sont pas resynchronisées sur Azure
AD. Dans Azure, les applications, les services et les machines virtuelles qui se connectent
au domaine managé peuvent ensuite utiliser des fonctionnalités AD DS courantes telles
que la jonction de domaine, la stratégie de groupe, LDAP et l’authentification
Kerberos/NTLM.
Dans un environnement hybride avec un environnement AD DS local, Azure AD Connect

synchronise les informations d’identité avec Azure AD, qui sont ensuite synchronisées
avec le domaine managé.
Azure AD DS réplique les informations d’identité à partir d’Azure AD, et fonctionne donc
avec des clients Azure AD qui sont uniquement cloud ou synchronisés avec un
environnement AD DS local. Le même ensemble de fonctionnalités Azure AD DS existe
pour les deux environnements.
Si vous disposez d’un environnement AD DS local existant, vous pouvez

synchroniser les informations des comptes d’utilisateurs pour fournir une identité
cohérente aux utilisateurs. Pour en savoir plus, consultez Synchronisation des
objets et des informations d’identification dans un domaine managé.
Pour les environnements cloud uniquement, vous n’avez pas besoin d’un
environnement AD DS local traditionnel pour utiliser les services d’identité
centralisés d’Azure AD DS.
Vous pouvez étendre un domaine managé pour avoir plusieurs jeux de réplicas par
locataire Azure AD. Les jeux de réplicas peuvent être ajoutés à n’importe quel réseau
virtuel appairé dans toute région Azure prenant en charge Azure AD DS. D’autres jeux
de réplicas dans des régions Azure différentes assurent la récupération d’urgence
géographique pour les applications héritées si une région Azure est mise hors
connexion. Pour plus d’informations, consultez Concepts et caractéristiques des jeux de
réplicas pour les domaines managés.
Jetez un coup d’œil à cette vidéo sur la façon dont Azure AD DS s’intègre à vos
applications et charges de travail pour fournir des services d’identité dans le cloud :
https://www.youtube-nocookie.com/embed/T1Nd9APNceQ
Pour voir des scénarios de déploiement d’Azure AD DS en action, vous pouvez explorer
les exemples suivants :
Azure AD DS pour les organisations hybrides

Azure AD DS pour les organisations cloud uniquement
Fonctionnalités et avantages d’Azure AD DS

Pour fournir des services d’identité aux applications et aux machines virtuelles dans le
cloud, Azure AD DS est entièrement compatible avec un environnement AD DS
traditionnel pour des opérations telles que la jonction de domaine, le protocole LDAP
sécurisé (LDAPS), la stratégie de groupe, la gestion de DNS ainsi que la prise en charge
des lectures et liaisons LDAP. La prise en charge de l’écriture LDAP est disponible pour
les objets créés dans le domaine managé, mais pas pour les ressources synchronisées à
partir d’Azure AD.
Pour en savoir plus sur les options d’identité, comparez Azure AD DS avec Azure AD, AD
DS sur des machines virtuelles Azure et AD DS en local.
Les fonctionnalités suivantes d’Azure AD DS simplifient les opérations de déploiement et

de gestion :
Expérience de déploiement simplifiée : Azure AD DS est activé pour votre

locataire Azure AD à l’aide d’un seul Assistant dans le Portail Azure.
Intégration à Azure AD : Les comptes d’utilisateur, les appartenances aux groupes
et les informations d’identification sont automatiquement disponibles à partir de
votre locataire Azure AD. Les nouveaux utilisateurs, groupes ou modifications
apportées aux attributs à partir de votre locataire Azure AD ou de votre
environnement AD DS local sont automatiquement synchronisés avec Azure AD
DS.
Les comptes d’annuaires externes liés à votre annuaire Azure AD ne sont pas
disponibles dans Azure AD DS. Les informations d’identification ne sont pas
disponibles pour ces annuaires externes et ne peuvent donc pas être
synchronisées dans un domaine managé.
Utilisation de vos informations d’identification/mots de passe d’entreprise : Les
mots de passe des utilisateurs dans Azure AD DS sont identiques à ceux dans votre
locataire Azure AD. Les utilisateurs peuvent utiliser leurs informations
d’identification d’entreprise pour joindre des machines à des domaines, se
connecter de manière interactive ou via le bureau à distance et s’authentifier sur le
domaine managé.
Authentification NTLM et Kerberos : Grâce à la prise en charge de
l’authentification NTLM et Kerberos, vous pouvez déployer des applications qui
reposent sur l’authentification intégrée de Windows.
Haute disponibilité : Azure AD DS inclut plusieurs contrôleurs de domaine, qui
fournissent une haute disponibilité pour votre domaine managé. Cette haute
disponibilité garantit le temps de fonctionnement du service et la résilience aux
défaillances.
Dans les régions qui prennent en charge les Zones de disponibilité Azure, ces
contrôleurs de domaine sont également répartis entre les zones pour une
résilience supplémentaire.
Les jeux de replicas permettent également de proposer la récupération
d’urgence géographique pour les applications héritées si une région Azure est
mise hors connexion.
Voici quelques aspects majeurs d’un domaine managé :
Le domaine géré est un domaine autonome. et non une extension du domaine

local.
Si nécessaire, vous pouvez créer des approbations de forêt sortantes
unidirectionnelles entre Azure AD DS et un environnement AD DS local. Pour
plus d’informations, consultez Concepts et fonctionnalités des forêts pour
Azure AD DS.
Votre équipe informatique n’a pas à gérer, à appliquer les correctifs ni à analyser
les contrôleurs de domaine pour ce domaine managé.
Pour les environnements hybrides qui exécutent AD DS localement, vous n’avez pas
besoin de gérer la réplication Active Directory sur le domaine managé. Les comptes
d’utilisateur, les appartenances aux groupes et les informations d’identification de votre
annuaire local sont synchronisés avec Azure AD via Azure AD Connect. Ces comptes
utilisateur, appartenances aux groupes et informations d’identification sont
automatiquement disponibles dans le domaine géré.
Étapes suivantes
Pour en savoir plus sur les différentes entre Azure AD DS et d’autres solutions d’identité
et sur le fonctionnement de la synchronisation, consultez les articles suivants :
Comparer Azure AD DS avec Azure AD, Active Directory Domain Services sur des
machines virtuelles Azure et Active Directory Domain Services en local
Comprendre comment la solution Azure AD Domain Services est synchronisée
avec votre répertoire Azure AD
Pour découvrir comment administrer un domaine managé, consultez Concepts de
gestion pour les comptes d’utilisateur, les mots de passe et l’administration dans
Azure AD DS.
Pour commencer, créez un domaine managé à l’aide du portail Azure.

Comparer les services Active Directory
Domain Services automanagés, Azure
Active Directory et les services Azure
Active Directory Domain Services
managés
Article • 12/04/2023
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). Au lieu de cela, vous pouvez simplement
utiliser Azure Active Directory.
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.
Azure Active Directory (Azure AD) : gestion des identités et des appareils mobiles
basée sur le cloud qui fournit des services d’authentification et de compte
d’utilisateur pour les ressources telles que Microsoft 365, le portail Azure ou les
applications SaaS.
Azure AD 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 plus d’informations sur Azure AD, consultez Qu’est-ce qu’Azure Active
Directory ?
Azure Active Directory Domain Services (Azure AD DS) : 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.
Azure AD DS s’intègre à Azure AD, qui peut lui-même 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 Azure AD et en local, consultez
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.
Pour commencer, créez un domaine managé Azure AD DS à l’aide du portail Azure

.
Azure AD DS et instance AD DS automanagée

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 avec Azure Active Directory Domain Services
(Azure AD DS). 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 Active Directory Domain Services (AD DS). Vous continuez
ensuite à administrer ces ressources.
Avec Azure AD DS, 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.
Azure AD DS 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 Azure AD DS 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,
Azure AD DS offre une expérience de domaine managé avec charge administrative
minimale. Pour plus d’informations, consultez Concepts de gestion pour les comptes
d’utilisateur, les mots de passe et l’administration dans Azure AD DS.
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é Azure AD
DS et un domaine automanagé AD DS :
Fonctionnalité Azure AD DS AD DS automanagé
Service managé ✓ ✕
Fonctionnalité Azure AD DS AD DS automanagé
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 Basé sur des ressources Basée sur des ressources
contrainte et basé sur des comptes
Structure d’unité ✓ ✓
d’organisation personnalisée
Stratégie de groupe ✓ ✓
Extensions de schéma ✕ ✓
Approbations de ✓ (approbations de forêt sortantes ✓

domaine/forêt AD unidirectionnelles uniquement)
LDAP sécurisé (LDAPS) ✓ ✓
Lecture LDAP ✓ ✓
Écriture LDAP ✓ (dans le domaine managé) ✓
Déploiements géolocalisés ✓ ✓
Azure AD DS et Azure AD
Azure AD 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 Azure
AD, ce qui fournit une identité à l’appareil. Par la suite, Azure AD authentifie l’appareil
lorsqu’un utilisateur se connecte à Azure AD et utilise cet 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
à Azure AD. Ce mécanisme offre les mêmes avantages que l’inscription d’un appareil
personnel à Azure AD, par exemple pour permettre aux utilisateurs de se connecter à
l’appareil à l’aide de leurs informations d’identification d’entreprise.
Les appareils joints à Azure AD vous offrent les avantages suivants :
Authentification unique (SSO) pour les applications sécurisées par Azure AD

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 à Azure AD 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 Mécanisme

d’appareils
Appareils personnels Windows 10, iOS, Appareils inscrits sur

Android, macOS Azure AD
Appareil appartenant à l’organisation et non Windows 10 Appareil joints Azure

joint à AD DS local AD
Appareil appartenant à l’organisation et Windows 10 Appareils joints Azure

joint à AD DS local AD hybrides
Sur un appareil inscrit ou joint à Azure AD, 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 à Azure AD DS, 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 Joint à Azure AD Joint à Azure AD DS
Appareil Azure AD Domaine managé Azure AD DS

contrôlé par
Représentation Objets appareil dans le Objets ordinateur dans le domaine managé

dans l’annuaire répertoire Azure AD Azure AD DS
Authentification Protocoles OAuth et OpenID Protocoles Kerberos et NTLM

Connect
Gestion Logiciels de gestion des Stratégie de groupe

appareils mobiles (GAM) tels
qu’Intune
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 Machines virtuelles de serveur déployées

bureau des utilisateurs finaux dans Azure
Si l’environnement local AD DS et Azure AD 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 Azure AD 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. De ce fait, Azure AD DS ne pourra pas valider les informations
d’identification des utilisateurs
Étapes suivantes
Pour bien démarrer avec l’utilisation d’Azure AD DS, créez un domaine managé Azure
AD DS à l’aide du portail Azure.
Consultez également les pages Concepts de gestion pour les comptes d’utilisateur, les
mots de passe et l’administration dans Azure AD DS et Synchronisation des objets et
des informations d’identification dans un domaine managé.
Tutoriel : Créer et configurer un
domaine managé Azure Active Directory
Domain Services
Article • 02/08/2023
managés, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP, et
l’authentification Kerberos/NTLM entièrement compatible avec Windows Server Active
Directory. Vous consommez ces services de domaine sans déployer, gérer et mettre à
jour avec des correctifs les contrôleurs de domaine vous-même. Azure AD DS s’intègre à
votre locataire Azure AD existant. Cette intégration permet aux utilisateurs de se
connecter en utilisant leurs informations d’identification d’entreprise, et vous pouvez
utiliser des groupes et des comptes d’utilisateur existants pour sécuriser l’accès aux
ressources.
Vous pouvez créer un domaine managé avec des options de configuration par défaut
pour le réseau et la synchronisation, ou définir ces paramètres manuellement. Ce tutoriel
montre comment utiliser les options par défaut pour créer et configurer un domaine
managé Azure AD DS avec le portail Azure.
Dans ce tutoriel, vous allez apprendre à :
＂ Comprendre les exigences DNS pour un domaine managé

＂ Créer un domaine managé
＂ Activer la synchronisation de hachage de mot de passe
Si vous n’avez pas d’abonnement Azure, créez un compte avant de commencer.
Prérequis
Pour effectuer ce tutoriel, vous avez besoin des ressources et des privilèges suivants :
Un abonnement Azure actif.
Si vous n’avez pas d’abonnement Azure, créez un compte .
Un locataire Azure Active Directory associé à votre abonnement, synchronisé avec
un annuaire local ou un annuaire cloud uniquement.
Si nécessaire, créez un locataire Azure Active Directory ou associez un
abonnement Azure à votre compte.
Vous avez besoin des rôles Administrateur d’applications et Administrateur de
groupes Azure AD dans votre locataire pour activer Azure AD DS.
Vous avez besoin du rôle Azure Contributeur aux services de domaine pour créer
les ressources Azure AD DS requises.
Vous avez besoin d’un réseau virtuel avec des serveurs DNS qui peuvent interroger
l’infrastructure nécessaire, comme le stockage. Des serveurs DNS qui ne peuvent
pas effectuer de requêtes Internet générales peuvent empêcher de créer un
domaine managé.
Bien que ce ne soit pas obligatoire pour Azure AD DS, nous vous recommandons de
configurer la réinitialisation de mot de passe en libre-service (SSPR) pour le locataire
Azure AD. Les utilisateurs peuvent changer leur mot de passe sans SSPR, mais SSPR aide
s’ils oublient leur mot de passe et doivent les réinitialiser.
） Important
Vous ne pouvez pas déplacer le domaine managé dans un autre abonnement, un

autre groupe de ressources ou une autre région après l’avoir créé. Veillez à
sélectionner l’abonnement, le groupe de ressources et la région les plus appropriés
quand vous déployez le domaine managé.
Connectez-vous au portail Azure.

Dans ce tutoriel, vous créez et configurez le domaine managé avec le portail Azure. Pour
commencer, connectez-vous au portail Azure .

Pour lancer l’Assistant Activer Azure AD Domain Services, procédez comme suit :
1. Dans le menu du Portail Azure ou dans la page Accueil, sélectionnez Créer une
ressource.
2. Entrez Domain Services dans la barre de recherche, puis choisissez Azure AD
Domain Services dans les suggestions de recherche.
3. Dans la page Azure AD Domain Services, cliquez sur le bouton Créer. L’Assistant
Activer Azure AD Domain Services est lancé.
4. Sélectionnez l’Abonnement Azure dans lequel vous souhaitez créer le domaine
managé.
5. Sélectionnez le Groupe de ressources auquel le domaine managé doit appartenir.
Choisissez de Créer ou de sélectionner un groupe de ressources existant.
Quand vous créez un domaine managé, vous spécifiez un nom DNS. Voici quelques
considérations liées au choix de ce nom DNS :
Nom de domaine intégré : Par défaut, le nom de domaine intégré de l’annuaire

est utilisé (un suffixe .onmicrosoft.com). Si vous voulez activer l’accès LDAP sécurisé
au domaine managé via Internet, vous ne pouvez pas créer un certificat numérique
pour sécuriser la connexion avec ce domaine par défaut. Microsoft détient le
domaine .onmicrosoft.com : une autorité de certification n’émettra donc pas de
certificat.
Noms de domaine personnalisés : L’approche la plus courante consiste à spécifier
un nom de domaine personnalisé, en général celui que vous possédez déjà et qui
est routable. Quand vous utilisez un domaine personnalisé routable, le trafic peut
s’écouler correctement en fonction des besoins pour prendre en charge vos
applications.
Suffixes de domaine non routables : D’une façon générale, nous vous
recommandons d’éviter un suffixe de nom de domaine non routable, comme
contoso.local. Le suffixe .local n’est pas routable et peut entraîner des problèmes de
résolution DNS.
 Conseil
Si vous créez un nom de domaine personnalisé, faites attention aux espaces de

noms DNS existants. Bien qu’il soit pris en charge, il est recommandé d’utiliser un
nom de domaine distinct de n’importe quel espace de noms DNS Azure ou local
existant.
Par exemple, si vous disposez de l’espace de noms DNS existant contoso.com, créez
un domaine managé avec le nom de domaine personnalisé aaddscontoso.com. Si
vous devez utiliser le protocole LDAP sécurisé, vous devez inscrire et avoir ce nom
de domaine personnalisé pour générer les certificats requis.
Vous devrez peut-être créer des enregistrements DNS supplémentaires pour

d’autres services dans votre environnement, ou des redirecteurs DNS conditionnels
entre les espaces de noms DNS existants dans votre environnement. Par exemple, si
vous exécutez un serveur web qui héberge un site à l’aide du nom DNS racine, il
peut y avoir des conflits de nommage qui nécessitent des entrées DNS
supplémentaires.
Dans ces tutoriels et articles de guide pratique, le domaine personnalisé

aaddscontoso.com est utilisé comme exemple simple. Dans toutes les commandes,
spécifiez votre propre nom de domaine.
Les restrictions de nom DNS suivantes s’appliquent également :
Restrictions de préfixe de domaine : Vous ne pouvez pas créer de domaine

managé avec un préfixe de plus de 15 caractères. Le préfixe du nom de domaine
spécifié (par exemple, aaddscontoso dans le nom de domaine aaddscontoso.com)
doit contenir au maximum 15 caractères.
Conflits de noms de réseau : Le nom de domaine DNS de votre domaine managé
ne doit pas déjà exister dans le réseau virtuel. En particulier, recherchez les
scénarios suivants, qui aboutiraient à un conflit de noms :
Si vous avec un domaine Active Directory avec le même nom de domaine DNS
sur le réseau virtuel Azure.
Si le réseau virtuel dans lequel vous envisagez d’activer le domaine managé a
une connexion VPN avec votre réseau local. Dans ce scénario, veillez à ne pas
avoir de domaine portant le même nom de domaine DNS sur votre réseau local.
Si vous avez un service cloud Azure avec ce nom sur le réseau virtuel Azure.
Renseignez les champs de la fenêtre De base du portail Azure pour créer un domaine
managé :
1. Entrez un Nom de domaine DNS pour votre domaine managé, en tenant compte
des points précédents.
2. Choisissez l’Emplacement Azure dans lequel créer le domaine managé. Si vous

choisissez une région qui prend en charge les Zones de disponibilité Azure, les
ressources Azure AD DS sont réparties entre les zones pour assurer une
redondance supplémentaire.
 Conseil
Les Zones de disponibilité sont des emplacements physiques uniques au sein

d’une région Azure. Chaque zone de disponibilité est composée d’un ou de
plusieurs centres de données équipés d’une alimentation, d’un système de
refroidissement et d’un réseau indépendants. Pour garantir la résilience, un
minimum de trois zones distinctes sont activées dans toutes les régions.
Vous ne devez rien configurer pour la répartition d’Azure AD DS entre les

zones. La plateforme Azure gère automatiquement la répartition de zone des
ressources. Pour plus d’informations et pour connaître la disponibilité
régionale, consultez Que sont les zones de disponibilité dans Azure ?
3. La référence SKU détermine le niveau de performance et la fréquence de

sauvegarde. Vous pouvez changer de référence SKU après la création du domaine
managé en cas de changement des besoins métier. Pour plus d’informations,
consultez Concepts relatifs aux références SKU dans Azure AD DS.
Pour ce tutoriel, sélectionnez la référence SKU Standard.
4. Une forêt est une construction logique utilisée par Active Directory Domain
Services pour regrouper un ou plusieurs domaines.
Pour créer rapidement un domaine managé, vous pouvez sélectionner Vérifier + créer
afin d’accepter d’autres options de configuration par défaut. Quand vous choisissez
cette option de création, les paramètres par défaut suivants sont configurés :
Crée un réseau virtuel nommé aadds-vnet qui utilise la plage d’adresses IP

10.0.2.0/24.
Crée un sous-réseau appelé aadds-subnet qui utilise la plage d’adresses IP
10.0.2.0/24.
Synchronise tous les utilisateurs entre Azure AD et le domaine managé.
７ Notes
Vous ne devez pas utiliser d'adresses IP publiques pour les réseaux virtuels et leurs
sous-réseaux en raison des problèmes suivants :
Rareté de l'adresse IP : Les adresses IP publiques IPv4 sont limitées, et leur

demande dépasse souvent l'offre disponible. En outre, il existe un
chevauchement potentiel d'adresses IP avec des points de terminaison
publics.
Risques de sécurité : L'utilisation d'adresses IP publiques pour les réseaux

virtuels expose vos appareils directement à Internet, ce qui augmente le
risque d'accès non autorisé et d'attaques potentielles. Sans mesures de
sécurité appropriées, vos appareils peuvent devenir vulnérables à diverses
menaces.
Complexité : La gestion d'un réseau virtuel avec des adresses IP publiques

peut être plus complexe que l'utilisation d'adresses IP privées, car cela
nécessite de gérer des plages d'adresses IP externes et d'assurer une
segmentation et une sécurité appropriées du réseau.
Il est fortement recommandé d'utiliser des adresses IP privées. Si vous utilisez une
adresse IP publique, assurez-vous que vous êtes le propriétaire/utilisateur dédié
des adresses IP choisies dans la plage publique que vous avez choisie.
Sélectionnez Vérifier + créer pour accepter ces options de configuration par défaut.
Déployer le domaine managé

Dans la page Résumé de l’Assistant, examinez les paramètres de configuration du
domaine managé. Vous pouvez revenir à n’importe quelle étape de l’Assistant pour faire
des modifications. Pour redéployer un domaine managé sur un autre client Azure AD en
utilisant ces mêmes options de configuration, vous pouvez également télécharger un
modèle pour l’automatisation.
1. Pour créer le domaine managé, sélectionnez Créer. Une remarque s’affiche pour
signaler que certaines options de configuration, telles que le nom DNS ou le
réseau virtuel, ne sont plus modifiables une fois que le domaine managé Azure
AD DS a été créé. Pour continuer, sélectionnez OK.
2. Le processus d’approvisionnement de votre domaine managé peut prendre jusqu’à

une heure. Vous voyez une notification dans le portail indiquant la progression de
votre déploiement Azure AD DS. Sélectionnez la notification pour voir la
progression détaillée du déploiement.
3. La page se charge avec les mises à jour du processus de déploiement, y compris la

création de ressources dans votre annuaire.
4. Sélectionnez votre groupe de ressources, tel que myResourceGroup, puis choisissez

votre domaine managé dans la liste des ressources Azure, par exemple
aaddscontoso.com. L’onglet Vue d’ensemble montre que le domaine managé est
actuellement en cours de Déploiement. Vous ne pouvez pas configurer le domaine
managé tant qu’il n’est pas entièrement provisionné.
5. Lorsque le domaine managé est entièrement approvisionné, l’onglet Vue

d’ensemble affiche l’état du domaine comme En cours d’exécution.
） Important
Le domaine managé est associé à votre locataire Azure AD. Pendant le processus
d’approvisionnement, Azure AD DS crée deux applications d’entreprise nommées
Services de contrôleur de domaine et AzureActiveDirectoryDomainControllerServices
dans le locataire Azure AD. Ces applications d’entreprise sont nécessaires pour
entretenir votre domaine géré. Ne supprimez pas ces applications.
Mettre à jour les paramètres DNS pour le

réseau virtuel Azure
Avec Azure AD DS correctement déployé, configurez maintenant le réseau virtuel pour
permettre à d’autres machines virtuelles et applications connectées d’utiliser le domaine
managé. Pour fournir cette connectivité, mettez à jour les paramètres du serveur DNS
pour que votre réseau virtuel pointe vers les deux adresses IP où le domaine managé est
déployé.
1. L’onglet Vue d’ensemble pour votre domaine managé montre quelques Étapes de
configuration obligatoires. La première étape de configuration est de mettre à
jour les paramètres du serveur DNS pour votre réseau virtuel. Une fois les
paramètres DNS correctement configurés, cette étape n’apparaît plus.
Les adresses listées sont les contrôleurs de domaine à utiliser dans le réseau
virtuel. Dans cet exemple, ces adresses sont 10.0.2.4 et 10.0.2.5. Vous pouvez
trouver ultérieurement ces adresses IP sous l’onglet Propriétés.
2. Pour mettre à jour les paramètres du serveur DNS pour le réseau virtuel,
sélectionnez le bouton Configurer. Les paramètres DNS sont configurés
automatiquement pour votre réseau virtuel.
 Conseil
Si vous avez sélectionné un réseau virtuel existant au cours des étapes précédentes,
les machines virtuelles connectées au réseau obtiennent les nouveaux paramètres
DNS seulement après un redémarrage. Vous pouvez redémarrer les machines
virtuelles en utilisant le portail Azure, Azure PowerShell ou Azure CLI.
Activer les comptes d’utilisateur pour Azure AD

DS
Pour authentifier les utilisateurs sur le domaine managé, Azure AD DS nécessite les
hachages de mot de passe dans un format adapté à l’authentification NTLM (NT LAN
Manager) et Kerberos. Azure AD ne génère pas et ne stocke pas les hachages de mot de
passe au format nécessaire pour l’authentification NTLM ou Kerberos tant que vous
n’activez pas Azure AD DS pour votre locataire. Pour des raisons de sécurité, Azure AD
ne stocke pas non plus d’informations d’identification de mot de passe sous forme de
texte en clair. Par conséquent, Azure AD ne peut pas générer automatiquement ces
hachages de mot de passe NTLM ou Kerberos en fonction des informations
d’identification existantes des utilisateurs.
７ Notes
Une fois configurés de façon appropriée, les hachages de mot de passe utilisables
sont stockés dans le domaine managé. Si vous supprimez le domaine managé, tout
hachage de mot de passe stocké à ce stade est également supprimé.
Les informations d’identification synchronisées dans Azure AD ne peuvent pas être

réutilisées si vous créez par la suite un domaine managé : vous devez reconfigurer
la synchronisation de hachage de mot de passe pour stocker à nouveau les
hachages de mot de passe. Les machines virtuelles ou les utilisateurs auparavant
joints à un domaine ne pourront pas s’authentifier immédiatement : Azure AD doit
générer et stocker les hachages de mot de passe dans le nouveau domaine
managé.
Azure AD Connect Cloud Sync n’est pas pris en charge avec Azure AD DS. Les
utilisateurs locaux doivent être synchronisés à l’aide d’Azure AD Connect pour
pouvoir accéder aux machines virtuelles jointes à un domaine. Pour plus
d’informations, consultez Processus de synchronisation du hachage de mot de
passe pour Azure AD DS et Azure AD Connect.
Les étapes de génération et de stockage de ces hachages de mot de passe sont

différentes pour les comptes d’utilisateur cloud uniquement créés dans Azure AD et
pour les comptes d’utilisateur qui sont synchronisés à partir de votre annuaire local avec
Azure AD Connect.
Un compte d’utilisateur uniquement dans le cloud est un compte qui a été créé dans
votre répertoire Azure AD à l’aide du portail Azure ou d’applets de commande
PowerShell Azure AD. Ces comptes d’utilisateurs ne sont pas synchronisés à partir d’un
annuaire local.
Dans ce tutoriel, nous utilisons un compte d’utilisateur de base cloud uniquement.

Pour plus d’informations sur les étapes supplémentaires nécessaires pour utiliser
Azure AD Connect, consultez Synchroniser les hachages de mot de passe pour les
comptes d’utilisateur synchronisés à partir de votre annuaire Active Directory local
vers votre domaine managé.
 Conseil
Si votre locataire Azure AD utilise une combinaison d’utilisateurs cloud uniquement

et d’utilisateurs provenant de votre annuaire Active Directory local, vous devez
effectuer ces deux ensembles d’étapes.
Pour les comptes d’utilisateurs cloud uniquement, les utilisateurs doivent changer leur
mot de passe avant de pouvoir utiliser Azure AD DS. Ce processus de changement du
mot de passe entraîne la génération et le stockage dans Azure AD des hachages de mot
de passe pour l’authentification Kerberos et NTLM. Le compte n’est pas synchronisé
entre Azure AD et Azure AD DS tant que le mot de passe n’a pas été changé. Vous
pouvez faire expirer les mots de passe de tous les utilisateurs cloud du locataire qui
doivent utiliser Azure AD DS, ce qui force le changement de mot de passe à la
connexion suivante, ou demander aux utilisateurs cloud de changer manuellement leur
mot de passe. Pour ce tutoriel, nous changeons manuellement le mot de passe d’un
utilisateur.
Pour qu’un utilisateur puisse réinitialiser son mot de passe, le locataire Azure AD doit
être configuré pour la réinitialisation du mot de passe en libre-service.
Pour changer le mot de passe d’un utilisateur cloud uniquement, l’utilisateur doit
effectuer les étapes suivantes :
1. Accédez à la page Panneau d’accès Azure AD à l’adresse

https://myapps.microsoft.com .
2. En haut à droite, sélectionnez votre nom, puis choisissez Profil dans le menu
déroulant.
3. Dans la page Profil, sélectionnez Changer le mot de passe.
4. Dans la page Changer le mot de passe, entrez votre mot de passe existant
(l’ancien), puis entrez un nouveau mot de passe et confirmez-le.
5. Sélectionnez Envoyer.
Une fois que vous avez changé votre mot de passe, quelques minutes sont nécessaires
pour que le nouveau mot de passe soit utilisable dans Azure AD DS et que vous puissiez
vous connecter aux ordinateurs joints au domaine managé.
Étapes suivantes
Dans ce didacticiel, vous avez appris à :
＂ Comprendre les exigences DNS pour un domaine managé

＂ Ajouter des utilisateurs d’administration à la gestion du domaine
＂ Activer les comptes d’utilisateur pour Azure AD DS et générer les hachages de mot
de passe
Avant de joindre des machines virtuelles au domaine et de déployer des applications qui
utilisent le domaine managé, configurez un réseau virtuel Azure pour les charges de
travail des applications.
Configurer un réseau virtuel Azure pour que les charges de travail des applications
utilisent votre domaine managé
Tutoriel : Configurer un réseau virtuel
pour un domaine managé Azure Active
Directory Domain Services
Article • 01/06/2023
Pour fournir la connectivité nécessaire aux utilisateurs et aux applications, un domaine

managé Azure Active Directory Domain Services (Azure AD DS) est déployé dans un
sous-réseau de réseau virtuel Azure. Ce sous-réseau de réseau virtuel doit être utilisé
uniquement pour les ressources du domaine managé qui sont fournies par la
plateforme Azure.
Lorsque vous créez vos propres machines virtuelles et applications, celles-ci ne doivent
pas être déployées dans le même sous-réseau de réseau virtuel. Créez et déployez vos
applications dans un sous-réseau de réseau virtuel séparé, ou dans un autre réseau
virtuel qui est appairé avec le réseau virtuel Azure AD DS.
Ce tutoriel vous montre comment créer et configurer un sous-réseau de réseau virtuel

dédié ou comment appairer un réseau différent avec le réseau virtuel du domaine
managé Azure AD DS.
＂ Utiliser correctement les options de connectivité de réseau virtuel pour les

ressources jointes au domaine Azure AD DS
＂ Créer une plage d’adresses IP et un sous-réseau supplémentaire dans le réseau
virtuel Azure AD DS
＂ Configurer l’appairage du réseau virtuel avec un réseau séparé d’Azure AD DS
Prérequis
Vous avez besoin des rôles Azure AD Administrateur d’applications et
Administrateur de groupes dans votre locataire pour activer Azure AD DS.
Un domaine managé Azure Active Directory Domain Services activé et configuré
dans votre locataire Azure AD.
Si nécessaire, le premier tutoriel crée et configure un domaine managé Azure
Active Directory Domain Services.

Options de connectivité pour les charges de

travail des applications
Dans le tutoriel précédent, vous avez créé un domaine managé en utilisant certaines
options de configuration par défaut pour le réseau virtuel. Ces options par défaut ont
créé un réseau virtuel et un sous-réseau de réseau virtuel Azure. Les contrôleurs de
domaine Azure AD DS qui fournissent les services du domaine managé sont connectés à
ce sous-réseau de réseau virtuel.
Quand vous créez et exécutez des machines virtuelles qui doivent accéder au domaine
managé, vous devez leur fournir la connectivité réseau nécessaire. Cette connectivité
réseau peut être fournie de l’une des manières suivantes :
Créez un sous-réseau de réseau virtuel supplémentaire sur le réseau virtuel du

domaine managé. Ce sous-réseau supplémentaire est l’endroit où vous créez et
connectez vos machines virtuelles.
Comme ces machines virtuelles font partie du même réseau virtuel, elles
peuvent automatiquement résoudre les noms et communiquer avec les
contrôleurs de domaine Azure AD DS.
Configurez l’appairage de réseaux virtuels Azure entre le réseau virtuel du domaine
managé et un ou plusieurs réseaux virtuels distincts. Vous créez et connectez vos
machines virtuelles dans ces réseaux virtuels séparés.
Quand vous configurez l’appairage de réseaux virtuels, vous devez également
configurer les paramètres DNS pour utiliser la résolution de noms par les
En règle générale, vous utilisez une seule de ces options de connectivité réseau. Le choix
est souvent dicté par la façon dont vous souhaitez gérer vos différentes ressources
Azure.
Si vous souhaitez gérer les machines virtuelles connectées et Azure AD DS dans un

même groupe de ressources, créez un sous-réseau de réseau virtuel
supplémentaire pour les machines virtuelles.
Si vous préférez les gérer séparément, utilisez l’appairage de réseaux virtuels.
Vous pouvez également choisir d’utiliser l’appairage de réseaux virtuels pour
fournir la connectivité réseau aux machines virtuelles dans votre environnement
Azure qui sont déjà connectées à un réseau virtuel existant.
Dans ce tutoriel, vous devez configurer une seule de ces options de connectivité de
réseau virtuel.
Pour plus d’informations sur la planification et la configuration du réseau virtuel,

consultez Considérations relatives au réseau pour Azure Active Directory Domain
Services.
Créer un sous-réseau de réseau virtuel

Par défaut, le réseau virtuel Azure créé avec le domaine managé contient un seul sous-
réseau de réseau virtuel. Ce sous-réseau doit être utilisé uniquement par la plateforme
Azure qui fournit les services du domaine managé. Pour créer et utiliser vos propres
machines virtuelles dans ce réseau virtuel Azure, créez un sous-réseau supplémentaire.
Pour créer un sous-réseau de réseau virtuel dédié aux machines virtuelles et aux charges
de travail des applications, effectuez les étapes suivantes :
1. Dans le portail Azure, sélectionnez le groupe de ressources de votre domaine

managé, par exemple myResourceGroup. Dans la liste des ressources, choisissez le
réseau virtuel par défaut, comme aadds-vnet ici.
2. Dans le menu à gauche dans la fenêtre du réseau virtuel, sélectionnez Espace

d’adressage. Le réseau virtuel est créé avec l’espace d’adressage unique
10.0.2.0/24, qui est utilisé par le sous-réseau par défaut.
Ajoutez une plage d’adresses IP supplémentaire au réseau virtuel. La taille de cette

plage d’adresses et la plage d’adresses IP réelle à utiliser dépendent des autres
ressources réseau qui sont déjà déployées. La plage d’adresses IP ne doit pas
chevaucher les plages d’adresses existantes dans votre environnement Azure ou
local. Assurez-vous d’utiliser une plage d’adresses IP suffisamment grande pour le
nombre de machines virtuelles que vous prévoyez de déployer dans le sous-
réseau.
Dans l’exemple suivant, la plage d’adresses IP supplémentaire 10.0.3.0/24 est

ajoutée. Quand vous êtes prêt, sélectionnez Enregistrer.
3. Ensuite, dans le menu à gauche dans la fenêtre du réseau virtuel, sélectionnez

Sous-réseaux, puis choisissez + Sous-réseau pour ajouter un sous-réseau.
4. Entrez un nom pour le sous-réseau, par exemple, workloads (charges de travail). Si

nécessaire, mettez à jour la plage d’adresses si vous souhaitez utiliser un sous-
ensemble de la plage d’adresses IP qui a été configurée pour le réseau virtuel lors
des étapes précédentes. Pour le moment, conservez les valeurs par défaut des
options telles que le groupe de sécurité réseau, la table de routage et les points de
terminaison de service.
Dans l’exemple suivant, le sous-réseau workloads qui est créé utilise la plage
d’adresses IP 10.0.3.0/24 :
5. Lorsque vous êtes prêt, sélectionnez OK. Il faut quelques instants pour créer le
sous-réseau de réseau virtuel.
Quand vous créez une machine virtuelle qui doit utiliser le domaine managé, veillez à
sélectionner ce sous-réseau de réseau virtuel. Ne créez pas vos machines virtuelles dans
le sous-réseau aadds-subnet par défaut. Si vous sélectionnez un autre réseau virtuel,
vous ne fournissez pas la connectivité réseau et la résolution DNS nécessaires pour
l’accès au domaine managé, sauf si vous configurez le peering de réseaux virtuels.
Configurer le peering de réseaux virtuels

Vous souhaitez peut-être utiliser un réseau virtuel Azure existant pour les machines
virtuelles, ou conserver votre réseau virtuel séparé du domaine managé. Pour utiliser le
domaine managé, les machines virtuelles situées dans d’autres réseaux virtuels doivent
pouvoir communiquer avec les contrôleurs de domaine Azure AD DS. Il est possible de
fournir cette connectivité par l’appairage de réseaux virtuels Azure.
L’appairage de réseaux virtuels Azure vous permet de connecter deux réseaux virtuels
sans avoir besoin d’un périphérique de réseau privé virtuel (VPN). Vous pouvez ainsi
connecter rapidement des réseaux virtuels et définir les flux de trafic dans votre
environnement Azure.
Pour plus d’informations sur l’appairage, consultez cette vue d’ensemble de l’appairage
de réseaux virtuels Azure.
Pour appairer un réseau virtuel avec le réseau virtuel du domaine managé, effectuez les
étapes suivantes :
1. Choisissez le réseau virtuel par défaut créé pour votre domaine managé, nommé
aadds-vnet.
2. Dans le menu à gauche dans la fenêtre du réseau virtuel, sélectionnez Appairages.
3. Pour créer un appairage, sélectionnez + Ajouter. Dans l’exemple suivant, le réseau

virtuel par défaut aadds-vnet est appairé avec un autre réseau virtuel nommé
myVnet. Configurez les paramètres suivants avec vos propres valeurs :
Nom du peering de aadds-vnet avec un réseau virtuel distant :

identificateur descriptif des deux réseaux, par exemple aadds-vnet-to-myvnet
Type de déploiement de réseau virtuel : Resource Manager
Abonnement: abonnement du réseau virtuel avec lequel vous souhaitez
effectuer l’appairage, par exemple Azure
Réseau virtuel : réseau virtuel à appairer, par exemple myVnet
Nom du peering de myVnet à aadds-vnet : identificateur descriptif des deux
réseaux, par exemple myvnet-to-aadds-vnet
Conservez les autres paramètres par défaut de l’accès au réseau virtuel ou du trafic
transféré, sauf si votre environnement a des exigences spécifiques, puis
sélectionnez OK.
4. Il faut quelques instants pour créer l’appairage entre le réseau virtuel Azure AD DS
et le réseau virtuel que vous avez sélectionné. Une fois l’appairage terminé, la
colonne État d’appairage indique Connecté, comme dans l’exemple ci-dessous :
Pour que les machines virtuelles du réseau virtuel appairé puissent utiliser le domaine
managé, vous devez configurer les serveurs DNS avec la résolution de noms correcte.
Configurer les serveurs DNS dans le réseau virtuel

appairé
Pour permettre aux machines virtuelles et aux applications déployées sur le réseau
virtuel appairé de communiquer correctement avec le domaine managé, vous devez
mettre à jour les paramètres DNS. Les adresses IP des contrôleurs de domaine
Azure AD DS doivent être configurées en tant que serveurs DNS sur le réseau virtuel
appairé. Il existe deux façons de configurer les contrôleurs de domaine comme serveurs
DNS dans le réseau virtuel appairé :
Configurez les serveurs DNS du réseau virtuel Azure pour qu’ils utilisent les
Configurez le serveur DNS existant actuellement utilisé sur le réseau virtuel appairé
afin qu’il transfère les requêtes au domaine managé à l’aide de la redirection DNS
conditionnelle. Ces étapes varient selon le serveur DNS existant qui est utilisé.
Dans ce tutoriel, vous configurez les serveurs DNS du réseau virtuel Azure afin qu’ils
transfèrent toutes les requêtes aux contrôleurs de domaine Azure AD DS.
1. Dans le portail Azure, sélectionnez le groupe de ressources du réseau virtuel

appairé, myResourceGroup, par exemple. Dans la liste des ressources, choisissez le
réseau virtuel appairé, myVnet ici.
2. Dans le menu à gauche dans la fenêtre du réseau virtuel, sélectionnez Serveurs

DNS.
3. Par défaut, un réseau virtuel utilise les serveurs DNS intégrés fournis par Azure.
Choisissez d’utiliser des serveurs DNS Personnalisés. Entrez les adresses IP des
contrôleurs de domaine Azure AD DS, qui sont habituellement 10.0.2.4 et 10.0.2.5.
Vérifiez ces adresses IP dans la fenêtre Vue d’ensemble de votre domaine managé
dans le portail.
4. Quand vous êtes prêt, sélectionnez Enregistrer. Il faut quelques instants pour
mettre à jour les serveurs DNS pour le réseau virtuel.
5. Pour appliquer les nouveaux paramètres DNS aux machines virtuelles, redémarrez
les machines virtuelles qui sont connectées au réseau virtuel appairé.
Quand vous créez une machine virtuelle qui doit utiliser le domaine managé, veillez à
sélectionner ce réseau virtuel appairé. Si vous sélectionnez un autre réseau virtuel, vous
ne fournissez pas la connectivité réseau et la résolution DNS nécessaires pour l’accès au
domaine managé.
Étapes suivantes
＂ Utiliser correctement les options de connectivité de réseau virtuel pour les

ressources jointes au domaine Azure AD DS
＂ Créer une plage d’adresses IP et un sous-réseau supplémentaire dans le réseau
virtuel Azure AD DS
＂ Configurer l’appairage du réseau virtuel avec un réseau séparé d’Azure AD DS
Pour voir ce domaine managé en action, créez et joignez une machine virtuelle au
domaine.
Joindre une machine virtuelle Windows Server à votre domaine managé
Tutoriel : Joindre une machine
virtuelle Windows Server à un domaine
managé par Azure Active Directory
Domain Services
Article • 22/06/2023
Directory. Avec un domaine managé Azure AD DS, vous pouvez fournir des
fonctionnalités de jonction de domaine et de gestion à des machines virtuelles dans
Azure. Ce tutoriel montre comment créer une machine virtuelle Windows Server, puis la
joindre à un domaine managé.
＂ Créer une machine virtuelle Windows Server

＂ Connecter la machine virtuelle Windows Server à un réseau virtuel Azure
＂ Joindre la machine virtuelle au domaine managé
Prérequis
Pour effectuer ce didacticiel, vous avez besoin des ressources suivantes :
Si nécessaire, créez et configurez un domaine managé Azure Active Directory
Domain Services.
Un compte d’utilisateur membre du domaine managé.
Vérifiez que la synchronisation du hachage de mot de passe ou que la
réinitialisation du mot de passe en libre-service d’Azure AD Connect a été
effectuée pour que le compte puisse se connecter au domaine managé.
Un hôte Azure Bastion déployé dans votre réseau virtuel Azure AD DS.
Si nécessaire, créez un hôte Azure Bastion.
Si vous disposez déjà d’une machine virtuelle que vous voulez joindre à un domaine,
passez à la section expliquant comment joindre la machine virtuelle au domaine
managé.

Dans ce tutoriel, vous allez créer une machine virtuelle Windows Server à joindre à votre
domaine managé avec le portail Azure. Pour commencer, connectez-vous au portail
Azure .
Créer une machine virtuelle Windows Server

Pour voir comment joindre un ordinateur à un domaine managé, créons une machine
virtuelle Windows Server. Cette machine virtuelle est connectée à un réseau virtuel
Azure qui fournit la connectivité au domaine managé. Le processus de jonction à un
domaine managé est identique à celui d’un domaine Active Directory Domain Services
local normal.
Si vous disposez déjà d’une machine virtuelle que vous voulez joindre à un domaine,
passez à la section expliquant comment joindre la machine virtuelle au domaine
managé.
ressource.
2. Dans Bien démarrer, choisissez Windows Server 2016 Datacenter.

3. Dans la fenêtre De base, configurez les paramètres principaux de la machine
virtuelle. Conservez les paramètres par défaut pour Options de disponibilité, Image
et Taille.
Paramètre Valeur suggérée
Resource Sélectionnez ou créez un groupe de ressources, par exemple

group myResourceGroup
Nom de la Entrez un nom pour la machine virtuelle, par exemple myVM

machine
virtuelle
Région Choisissez la région où créer votre machine virtuelle, par exemple USA Est.
Nom Entrez un nom d’utilisateur pour le compte d’administrateur local à créer sur
d’utilisateur la machine virtuelle, par exemple azureuser
Mot de Entrez puis confirmez un mot de passe sécurisé pour l’administrateur local à
passe créer sur la machine virtuelle. Ne spécifiez pas les informations
d’identification d’un compte d’utilisateur du domaine. Windows LAPS n'est
pas pris en charge.
4. Par défaut, les machines virtuelles créées dans Azure sont accessibles à partir
d’Internet à l’aide de RDP. Quand RDP est activé, des attaques de connexion
automatique sont susceptibles de se produire, ce qui peut désactiver les comptes
portant des noms courants, comme admin ou administrator, en raison d’un trop
grand nombre de tentatives de connexion.
RDP doit être activé seulement quand c’est nécessaire et être limité à un ensemble
de plages d’adresses IP autorisées. Cette configuration permet d’améliorer la
sécurité de la machine virtuelle et de réduire le champ des attaques potentielles.
Vous pouvez aussi créer et utiliser un hôte Azure Bastion qui autorise l’accès
uniquement via le portail Azure sur TLS. Dans l’étape suivante de ce tutoriel, vous
allez utiliser un hôte Azure Bastion pour vous connecter de façon sécurisée à la
machine virtuelle.
Sous Ports d’entrée publics, sélectionnez Aucun.
5. Quand vous avez terminé, sélectionnez Suivant : Disques.
6. Dans le menu déroulant pour le Type de disque de système d’exploitation,

choisissez SSD Standard, puis sélectionnez Suivant : Mise en réseau.
7. Votre machine virtuelle doit se connecter à un sous-réseau du réseau virtuel Azure

qui peut communiquer avec le sous-réseau où votre domaine managé est déployé.
Nous recommandons de déployer un domaine managé sur son propre sous-
réseau dédié. Ne déployez pas votre machine virtuelle sur le même sous-réseau
que votre domaine managé.
Il existe deux manières principales de déployer votre machine virtuelle et de se

connecter à un sous-réseau de réseau virtuel approprié :
Créez ou sélectionnez un sous-réseau existant sur le même réseau virtuel que

celui où votre domaine managé est déployé.
Sélectionnez un sous-réseau dans un réseau virtuel Azure qui lui est connecté
avec le peering de réseau virtuel Azure.
Si vous sélectionnez un sous-réseau de réseau virtuel qui n’est pas connecté au

sous-réseau de votre domaine managé, vous ne pouvez pas joindre la machine
virtuelle au domaine managé. Pour ce tutoriel, créons un sous-réseau dans le
réseau virtuel Azure.
Dans le volet Mise en réseau, sélectionnez le réseau virtuel où le domaine managé

est déployé, par exemple aaads-vnet
8. Dans cet exemple, le sous-réseau aaads-subnet existant est celui auquel le

domaine managé domaine est connecté. Ne connectez pas votre machine virtuelle
à ce sous-réseau. Pour créer un sous-réseau pour la machine virtuelle, sélectionnez
Gérer la configuration du sous-réseau.
9. Dans le menu à gauche dans la fenêtre du réseau virtuel, sélectionnez Espace
d’adressage. Le réseau virtuel est créé avec l’espace d’adressage unique
10.0.2.0/24, qui est utilisé par le sous-réseau par défaut. D’autres sous-réseaux,
comme pour workloads ou Azure Bastion, peuvent aussi déjà exister.
Ajoutez une plage d’adresses IP supplémentaire au réseau virtuel. La taille de cette

plage d’adresses et la plage d’adresses IP réelle à utiliser dépendent des autres
ressources réseau qui sont déjà déployées. La plage d’adresses IP ne doit pas
chevaucher les plages d’adresses existantes dans votre environnement Azure ou
local. Assurez-vous d’utiliser une plage d’adresses IP suffisamment grande pour le
nombre de machines virtuelles que vous prévoyez de déployer dans le sous-
réseau.
Dans l’exemple suivant, la plage d’adresses IP supplémentaire 10.0.5.0/24 est

ajoutée. Quand vous êtes prêt, sélectionnez Enregistrer.
10. Ensuite, dans le menu à gauche dans la fenêtre du réseau virtuel, sélectionnez
Sous-réseaux, puis choisissez + Sous-réseau pour ajouter un sous-réseau.
11. Sélectionnez + Sous-réseau, puis entrez un nom pour le sous-réseau, par exemple
gestion. Spécifiez une Plage d’adresses (bloc CIDR) , par exemple 10.0.5.0/24.
Vérifiez que cette plage d’adresses IP ne chevauche pas d’autres plages d’adresses
Azure ou locales existantes. Laissez les autres options avec leur valeur par défaut,
puis sélectionnez OK.
12. La création du sous-réseau prend quelques secondes. Une fois qu’il est créé,
sélectionnez le X pour fermer la fenêtre du sous-réseau.
13. De retour dans le volet Mise en réseau pour créer une machine virtuelle, choisissez
le sous-réseau que vous avez créé dans le menu déroulant, par exemple gestion. Là
encore, veillez à choisir le sous-réseau approprié et ne déployez pas votre machine
virtuelle sur le même sous-réseau que votre domaine managé.
14. Pour IP publique, sélectionnez Aucune dans le menu déroulant. Quand vous
utilisez Azure Bastion dans ce tutoriel pour vous connecter à la gestion, vous
n’avez pas besoin qu’une adresse IP publique soit affectée à la machine virtuelle.
15. Laissez les autres options avec leur valeur par défaut, puis sélectionnez Gestion.
16. Définissez Diagnostics de démarrage sur Désactivé. Laissez les autres options avec
leur valeur par défaut, puis sélectionnez Vérifier + créer.
17. Passez en revue vos paramètres de la machine virtuelle, puis sélectionnez Créer.
La création de la machine virtuelle ne nécessite que quelques minutes. Le portail Azure

montre l’état du déploiement. Quand votre machine virtuelle est prête, sélectionnez
Accéder à la ressource.
Se connecter à la machine virtuelle Windows
Server
Pour vous connecter de façon sécurisée à vos machines virtuelles, utilisez un hôte Azure
Bastion. Avec Azure Bastion, un hôte managé est déployé dans votre réseau virtuel et
fournit aux machines virtuelles des connexions RDP ou SSH basées sur le web. Aucune
adresse IP publique n’est requise pour les machines virtuelles et vous n’avez pas besoin
d’ouvrir de règles de groupe de sécurité réseau pour le trafic distant externe. Vous vous
connectez aux machines virtuelles à l’aide du portail Azure à partir de votre navigateur
web. Si nécessaire, créez un hôte Azure Bastion.
Pour utiliser un hôte Bastion pour vous connecter à votre machine virtuelle, procédez
comme suit :
1. Dans le volet Vue d’ensemble de votre machine virtuelle, sélectionnez Se

connecter, puis Bastion.
2. Entrez les informations d’identification pour votre machine virtuelle que vous avez
spécifiées dans la section précédente, puis sélectionnez Se connecter.
Si nécessaire, autorisez votre navigateur web à ouvrir des fenêtres contextuelles pour
afficher la connexion Bastion. Il faut quelques secondes pour établir la connexion à votre
machine virtuelle.
Joindre la machine virtuelle au domaine

managé
Maintenant que la machine virtuelle est créée et qu’une connexion RDP basée sur le
web a été établie à l’aide d’Azure Bastion, joignons la machine virtuelle Windows Server
au domaine managé. Ce processus est identique à celui d’un ordinateur qui se connecte
à un domaine Active Directory Domain Services local normal.
1. Si Gestionnaire de serveur ne s’ouvre pas par défaut lorsque vous vous connectez
à la machine virtuelle, sélectionnez le menu Démarrer, puis choisissez Gestionnaire
de serveur.
2. Dans le volet gauche de la fenêtre Gestionnaire de serveur, cliquez sur l’option

Serveur local. Sous Propriétés dans le volet droit, choisissez Groupe de travail.
3. Dans la fenêtre Propriétés système, sélectionnez Modifier pour joindre le domaine

managé.
4. Dans la zone Domaine, spécifiez le nom de votre domaine managé, par exemple
aaddscontoso.com, puis sélectionnez OK.
5. Entrez les informations d’identification du domaine pour vous joindre au domaine.
Fournissez les informations d’identification d’un utilisateur membre du domaine
managé. Le compte doit faire partie du domaine managé ou du locataire Azure
AD : les comptes d’annuaires externes associés à votre locataire Azure AD ne
peuvent pas s’authentifier correctement au cours du processus de jonction de
domaine.
Les informations d’identification du compte peuvent être spécifiées de l’une des

manières suivantes :
Format UPN (recommandé) : Entrez le suffixe du nom de l’utilisateur principal

(UPN) pour le compte d’utilisateur, tel qu’il est configuré dans Azure AD. Par
exemple, le suffixe UPN de l’utilisateur contosoadmin serait
contosoadmin@aaddscontoso.onmicrosoft.com . Il existe deux cas d’utilisation
courants dans lesquels le format UPN peut être utilisé de façon fiable pour se
connecter au domaine, au lieu du format SAMAccountName :
Si le préfixe UPN d’un utilisateur est long, par exemple
deehasareallylongname, le SAMAccountName peut être généré
automatiquement.
Si plusieurs utilisateurs ont le même préfixe UPN au sein de votre locataire
Azure AD, par exemple, dee, leur format SAMAccountName peut être
généré automatiquement.
Format SAMAccountName : Entrez le nom du compte au format
SAMAccountName. Par exemple, le SAMAccountName de l’utilisateur
contosoadmin serait AADDSCONTOSO\contosoadmin .
6. Quelques secondes sont nécessaires pour la jonction au domaine managé. Quand

c’est terminé, le message suivant vous accueille dans le domaine :
Sélectionnez OK pour continuer.
7. Pour terminer le processus de jonction au domaine managé, redémarrez la

machine virtuelle.
 Conseil
Vous pouvez joindre une machine virtuelle à un domaine en utilisant PowerShell
avec l’applet de commande Add-Computer. L’exemple suivant joint le domaine
AADDSCONTOSO, puis redémarre la machine virtuelle. À l’invite, entrez les
informations d’identification d’un utilisateur membre du domaine managé :
Add-Computer -DomainName AADDSCONTOSO -Restart
Pour joindre une machine virtuelle à un domaine sans vous y connecter et

configurer manuellement la connexion, vous pouvez utiliser l’applet de commande
Azure PowerShell Set-AzVmAdDomainExtension.
Une fois la machine virtuelle Windows Server redémarrée, toutes les stratégies
appliquées dans le domaine managé sont envoyées (push) à la machine virtuelle. Vous
pouvez également vous connecter à la machine virtuelle Windows Server en utilisant des
informations d’identification du domaine appropriées.
Nettoyer les ressources

Dans le tutoriel suivant, vous utiliserez cette machine virtuelle Windows Server pour
installer les outils de gestion qui vous permettent d’administrer le domaine managé. Si
vous ne voulez pas continuer cette série de tutoriels, passez en revue les étapes de
nettoyage suivantes pour supprimer la machine virtuelle. Sinon, passez au tutoriel
suivant.
Annuler la jonction de la machine virtuelle au domaine

managé
Pour supprimer la machine virtuelle du domaine managé, réeffectuez les étapes
permettant de joindre la machine virtuelle à un domaine. Au lieu de joindre le domaine
managé, choisissez de joindre un groupe de travail, comme le WORKGROUP (groupe de
travail) par défaut. Une fois la machine virtuelle redémarrée, l’objet ordinateur est
supprimé du domaine managé.
Si vous supprimez la machine virtuelle sans annuler la jonction au domaine, un objet

ordinateur orphelin est laissé dans Azure AD DS.
Supprimer la machine virtuelle

Si vous ne voulez pas utiliser cette machine virtuelle Windows Server, supprimez-la en
effectuant les étapes suivantes :
1. Dans le menu de gauche, sélectionnez Groupes de ressources.
2. Choisissez votre groupe de ressources, par exemple myResourceGroup.
3. Sélectionnez votre machine virtuelle, par exemple myVM, puis sélectionnez
Supprimer. Sélectionnez Oui pour confirmer la suppression de la ressource. La
suppression de la machine virtuelle prend quelques minutes.
4. Une fois la machine virtuelle supprimée, sélectionnez le disque du système
d’exploitation, la carte d’interface réseau et les autres ressources avec le préfixe
myVM- , et supprimez-les.
Résoudre les problèmes de jonction à un

domaine
La machine virtuelle Windows Server doit être jointe avec succès au domaine managé,
de la même façon qu’un ordinateur local normal est joint à un domaine Active Directory
Domain Services. Si la machine virtuelle Windows Server ne peut pas se joindre au
domaine managé, cela indique qu’il existe un problème lié à la connectivité ou aux
informations d’identification. Consultez les sections de dépannage suivantes pour
effectuer avec succès la jonction au domaine managé.
Problèmes de connectivité
Si vous ne recevez pas d’invite demandant des informations d’identification pour la
jonction au domaine, c’est qu’il y a un problème de connectivité. La machine virtuelle ne
peut pas atteindre le domaine managé sur le réseau virtuel.
Après avoir essayé chacune de ces étapes de dépannage, réessayez de joindre la

machine virtuelle Windows Server au domaine managé.
Vérifiez que la machine virtuelle est connectée au même réseau virtuel que celui où
Azure AD DS est activé, ou qu’elle a une connexion réseau appairée.
Effectuez un test Ping du nom de domaine DNS du domaine managé, par exemple
ping aaddscontoso.com .
Si le test Ping échoue, essayez d’effectuer un test Ping des adresses IP du

domaine managé, par exemple ping 10.0.0.4 . L’adresse IP de votre
environnement est affiché dans la page Propriétés quand vous sélectionnez le
domaine managé dans votre liste de ressources Azure.
Si le test ping de l’adresse IP aboutit contrairement à celui du domaine, il se
peut que la fonction DNS ne soit pas correctement configurée. Vérifiez que les
adresses IP du domaine managé sont configurées en tant que serveurs DNS
pour le réseau virtuel.
Essayez de vider le cache du résolveur DNS sur la machine virtuelle en utilisant la
commande ipconfig /flushdns .
Problèmes liés aux informations d’identification

Si vous recevez une invite demandant des informations d’identification pour joindre le
domaine, puis une erreur après avoir entré ces informations d’identification, cela signifie
que la machine virtuelle est en mesure de se connecter au domaine managé. Les
informations d’identification que vous avez fournies n’autorisent pas la machine virtuelle
à se joindre au domaine managé.
Après avoir essayé chacune de ces étapes de dépannage, réessayez de joindre la

machine virtuelle Windows Server au domaine managé.
Vérifiez que le compte d’utilisateur spécifié appartient au domaine managé.

Vérifiez que le compte fait partie du domaine managé ou du locataire Azure AD.
Les comptes de répertoires externes associés à votre Client Azure AD ne peuvent
pas s’authentifier correctement au cours du processus de jonction de domaine.
Essayez en utilisant le format UPN pour spécifier les informations d’identification,
par exemple contosoadmin@aaddscontoso.onmicrosoft.com . S’il existe de nombreux
utilisateurs avec le même préfixe UPN sur votre locataire, ou si votre préfixe UPN
est très long, le SAMAccountName de votre compte peut être généré
automatiquement. Dans ces cas-là, le format SAMAccountName de votre compte
peut être différent de ce que vous attendez ou de ce que vous utilisez dans votre
domaine local.
Vérifiez que vous avez activé la synchronisation de mot de passe avec votre
domaine managé. Si vous n’effectuez pas cette étape de configuration, les
hachages de mot de passe nécessaires ne seront pas présents dans le domaine
managé et votre tentative de connexion ne pourra pas être authentifiée
correctement.
Attendez la fin de la synchronisation du mot de passe. Quand le mot de passe d’un
compte d’utilisateur est changé, une synchronisation automatique en arrière-plan
à partir d’Azure AD met à jour le mot de passe dans Azure AD DS. Il faut un certain
temps pour que le mot de passe soit disponible pour être utilisé dans une jonction
de domaine.
Étapes suivantes
＂ Créer une machine virtuelle Windows Server

＂ Se connecter à la machine virtuelle Windows Server sur un réseau virtuel Azure
＂ Joindre la machine virtuelle au domaine managé
Pour administrer votre domaine managé, configurez une machine virtuelle de gestion en
utilisant le Centre d’administration Active Directory.
Installer des outils d’administration sur une machine virtuelle de gestion

Tutoriel : Créer une machine virtuelle de
gestion pour configurer et administrer
un domaine managé Azure Active
Article • 01/06/2023
Azure Active Directory Domain Services (Azure AD DS) fournit des services de domaines
Directory. Vous administrez ce domaine managé avec les mêmes outils d’administration
de serveur distant (RSAT, Remote Server Administration Tool) qu’avec un domaine Active
Directory Domain Services local. Comme Azure AD DS est un service managé, vous ne
pouvez pas effectuer certaines tâches d’administration, comme utiliser le protocole RDP
(Remote Desktop Protocol) pour vous connecter aux contrôleurs de domaine.
Ce tutoriel explique comment configurer une machine virtuelle Windows Server dans
Azure et comment installer les outils nécessaires à l’administration d’un domaine Azure
AD DS managé.
＂ Comprendre les tâches d’administration disponibles dans un domaine managé

＂ Installer les outils d’administration Active Directory sur une machine virtuelle
Windows Server
＂ Utiliser le Centre d’administration Active Directory pour effectuer des tâches
courantes
Prérequis
Si nécessaire, consultez le premier tutoriel pour créer et configurer un domaine
managé Azure Active Directory Domain Services.
Une machine virtuelle Windows Server jointe au domaine managé.
Si nécessaire, consultez le tutoriel précédent pour créer et joindre une machine
virtuelle Windows Server à un domaine managé.
Un compte d’utilisateur membre du groupe Administrateurs Azure AD DC dans
votre locataire Azure AD.
Un hôte Azure Bastion déployé dans votre réseau virtuel Azure AD DS.
Si nécessaire, créez un hôte Azure Bastion.

Dans ce tutoriel, vous créez et vous configurez une machine virtuelle de gestion avec le
portail Azure. Pour commencer, connectez-vous au portail Azure .
Tâches d’administration disponibles dans Azure

AD DS
Azure AD DS fournit un domaine managé que vos utilisateurs, vos applications et vos
services vont utiliser. Cette approche change certaines des tâches de gestion disponibles
que vous pouvez effectuer, ainsi que les privilèges dont vous disposez dans le domaine
managé. Ces tâches et autorisations peuvent être différentes de celles que vous
rencontrez avec un environnement Active Directory Domain Services local normal. Vous
ne pouvez pas vous connecter aux contrôleurs du domaine managé avec Bureau à
distance.
Tâches d’administration pouvant être effectuées sur un

domaine géré
Les membres du groupe AAD DC Administrators bénéficient de privilèges leur
permettant d’effectuer les tâches suivantes sur le domaine managé :
Configurer l’objet de stratégie de groupe intégré pour les conteneurs Ordinateurs

AADDC et Utilisateurs AADDC dans le domaine managé.
administrer le DNS sur le domaine géré ;
Créer et administrer des unités d’organisation personnalisées dans le domaine
managé.
obtenir un accès d’administrateur aux ordinateurs joints au domaine géré ;
Privilèges d’administrateur dont vous ne disposez pas sur

un domaine managé
Le domaine managé est verrouillé : vous ne disposez donc pas de privilèges permettant
d’effectuer certaines tâches d’administration sur le domaine. Voici quelques exemples de
tâches que vous ne pouvez pas effectuer :
Étendre le schéma du domaine managé.

Vous connecter aux contrôleurs de domaine du domaine managé avec Bureau à
distance.
Ajouter des contrôleurs de domaine au domaine managé.
Vous ne disposez pas des privilèges Administrateur de domaine ou Administrateur
d’entreprise pour le domaine managé.
Se connecter à la machine virtuelle Windows

Server
Dans le tutoriel précédent, une machine virtuelle Windows Server a été créée et jointe
au domaine managé. Utilisez cette machine virtuelle pour installer les outils de gestion.
Si nécessaire, suivez les étapes du tutoriel pour créer et joindre une machine virtuelle
Windows Server à un domaine managé.
７ Notes
Dans ce tutoriel, vous utilisez une machine virtuelle Windows Server dans Azure qui
est jointe au domaine managé. Vous pouvez également utiliser un client Windows,
comme Windows 10, qui est joint au domaine managé.
Pour plus d’informations sur l’installation des outils d’administration sur un client
Windows, consultez Installer les outils d’administration de serveur distant .
Pour commencer, connectez-vous à la machine virtuelle Windows Server comme suit :
1. Dans le portail Azure, sélectionnez Groupes de ressources sur le côté gauche.

Choisissez le groupe de ressources où votre machine virtuelle a été créée, par
exemple myResourceGroup, puis sélectionnez la machine virtuelle, par exemple
myVM.
2. Dans le volet Vue d’ensemble de votre machine virtuelle, sélectionnez Se
connecter, puis Bastion.
3. Entrez les informations d’identification pour votre machine virtuelle, puis

sélectionnez Se connecter.
Si nécessaire, autorisez votre navigateur web à ouvrir des fenêtres contextuelles pour
afficher la connexion Bastion. Il faut quelques secondes pour établir la connexion à votre
machine virtuelle.
Installer les outils d’administration Active

Directory
Dans un domaine managé, vous utilisez les mêmes outils d’administration que dans les
environnements AD DS locaux, comme le Centre d’administration Active Directory
(ADAC) ou AD PowerShell. Ces outils peuvent être installés dans le cadre de la
fonctionnalité Outils d’administration de serveur distant sur des ordinateurs Windows
Server et des ordinateurs clients. Les membres du groupe Administrateurs AAD DC
peuvent administrer les domaines managés à distance en utilisant ces outils
d’administration AD à partir d’un ordinateur joint au domaine managé.
Pour installer les outils d’administration Active Directory sur une machine virtuelle jointe
au domaine, effectuez les étapes suivantes :
de serveur.
2. Dans le volet Tableau de bord de la fenêtre Gestionnaire de serveur, sélectionnez

Ajouter des rôles et des fonctionnalités.
3. Dans la page Avant de commencer de l’Assistant Ajout de rôles et de

fonctionnalités, sélectionnez Suivant.
4. Pour le Type d’installation, laissez l’option Installation basée sur un rôle ou une
fonctionnalité cochée et sélectionnez Suivant.
5. Dans la page Sélection du serveur, choisissez la machine virtuelle actuelle dans le

pool de serveurs, par exemple myvm.aaddscontoso.com, puis sélectionnez Suivant.
6. Sur la page Rôles de serveurs, cliquez sur Suivant.
7. Dans la page Fonctionnalités, développez le nœud Outils d’administration de

serveur distant, puis développez le nœud Outils d’administration de rôles.
Choisissez la fonctionnalité Outils AD DS et AD LDS dans la liste des outils

d’administration de rôles, puis sélectionnez Suivant.
8. Dans la page Confirmation, sélectionnez Installer. L’installation des outils
d’administration peut prendre une ou deux minutes.
9. Une fois l’installation de la fonctionnalité terminée, sélectionnez Fermer pour

quitter l’Assistant Ajout de rôles et de fonctionnalités.
Utiliser les outils d’administration Active

Directory
Une fois les outils d’administration installés, voyons comment les utiliser pour
administrer le domaine managé. Vérifiez que vous êtes connecté à la machine virtuelle
avec un compte d’utilisateur membre du groupe Administrateurs AAD DC.
1. Dans le menu Démarrer, sélectionnez Outils d’administration Windows. Les outils

d’administration Active Directory installés à l’étape précédente figurent dans la
liste.
2. Sélectionnez Centre d’administration Active Directory.

3. Pour explorer le domaine managé, choisissez le nom de domaine dans le volet
gauche, par exemple aaddscontoso. Deux conteneurs nommés Ordinateurs AADDC
et Utilisateurs AADDC se trouvent en haut de la liste.
4. Pour voir les utilisateurs et les groupes appartenant au domaine managé,

sélectionnez le conteneur Utilisateurs AADDC. Les comptes d’utilisateur et les
groupes de votre locataire Azure AD sont listés dans ce conteneur.
Dans l’exemple de sortie suivant, un compte d’utilisateur nommé Contoso Admin et

un groupe pour Administrateurs AAD DC figurent dans ce conteneur.
5. Pour voir les ordinateurs qui sont joints au domaine managé, sélectionnez le
conteneur Ordinateurs AADDC. Une entrée pour la machine virtuelle actuelle, par
exemple myVM figure dans la liste. Les comptes d’ordinateurs de tous les appareils
joints au domaine managé sont stockés dans le conteneur Ordinateurs AADDC.
Les actions courantes du Centre d’administration Active Directory, comme la

réinitialisation du mot de passe d’un compte d’utilisateur ou la gestion de
l’appartenance à un groupe, sont disponibles. Ces actions fonctionnent seulement pour
les utilisateurs et les groupes créés directement dans le domaine managé. Les
informations d’identité ne sont synchronisées que depuis Azure AD vers Azure AD DS. Il
n’y a pas de mise à jour depuis Azure AD DS vers Azure AD. Vous ne pouvez pas
changer les mots de passe ou l’appartenance à un groupe managé pour les utilisateurs
synchronisés à partir d’Azure AD et obtenir la synchronisation de ces modifications.
Vous pouvez également utiliser le Module Active Directory pour Windows PowerShell, qui
est installé dans le cadre des outils d’administration, pour gérer les actions courantes
dans votre domaine managé.
Étapes suivantes
＂ Comprendre les tâches d’administration disponibles dans un domaine managé

＂ Installer les outils d’administration Active Directory sur une machine virtuelle
Windows Server
＂ Utiliser le Centre d’administration Active Directory pour effectuer des tâches
courantes
Pour interagir de façon sécurisée avec votre domaine managé à partir d’autres
applications, activez le protocole LDAPS.
Configurer le protocole LDAP sécurisé pour votre domaine managé

Tutoriel : Configurer le protocole LDAP
sécurisé pour un domaine managé
Azure Active Directory Domain Services
Article • 16/03/2023
Pour communiquer avec votre domaine managé Azure Active Directory Domain Services
(Azure AD DS), le protocole LDAP (Lightweight Directory Access Protocol) est utilisé. Par
défaut, le trafic LDAP n’est pas chiffré, ce qui constitue un problème de sécurité pour de
nombreux environnements.
Avec Azure AD DS, vous pouvez configurer le domaine managé pour qu’utilise le
protocole LDAPS (Lightweight Directory Access Protocol sécurisé). Quand vous utilisez le
protocole LDAP sécurisé, le trafic est chiffré. Le protocole LDAP sécurisé est également
appelé LDAP over SSL (Secure Sockets Layer) / TLS (Transport Layer Security).
Ce tutoriel vous montre comment configurer LDAPS pour un domaine managé Azure
AD DS.
＂ Créer un certificat numérique pour une utilisation avec Azure AD DS

＂ Activer le protocole LDAP sécurisé pour Azure AD DS
＂ Configurer le protocole LDAP sécurisé pour une utilisation sur l’internet public
＂ Lier et tester le protocole LDAP sécurisé pour un domaine managé
Prérequis
Domain Services.
L’outil LDP.exe installé sur votre ordinateur.
Si nécessaire, installez les outils d’administration de serveur distant (RSAT) pour
Active Directory Domain Services et LDAP.
Administrateur de groupes dans votre locataire pour activer le protocole LDAP
sécurisé.

Dans ce tutoriel, vous configurez le protocole LDAP sécurisé pour le domaine managé
en utilisant le portail Azure. Pour commencer, connectez-vous au portail Azure .
Créer un certificat pour le protocole LDAP

sécurisé
Pour utiliser le protocole LDAP sécurisé, un certificat numérique est utilisé pour chiffrer
la communication. Ce certificat numérique est appliqué à votre domaine managé et
permet à des outils comme LDP.exe d’utiliser une communication chiffrée sécurisée lors
de l’interrogation des données. Il existe deux manières de créer un certificat pour un
accès LDAP sécurisé au domaine managé :
Un certificat auprès d’une autorité de certification publique ou d’une autorité de

certification d’entreprise.
Si votre organisation obtient ses certificats auprès d’une autorité de certification
publique, obtenez le certificat LDAP sécurisé auprès de cette dernière. Si vous
utilisez dans votre organisation une autorité de certification d’entreprise,
obtenez le certificat LDAP sécurisé auprès de cette dernière.
Une autorité de certification publique fonctionne seulement quand vous utilisez
un nom DNS personnalisé avec votre domaine managé. Si le nom de domaine
DNS de votre domaine managé se termine par .onmicrosoft.com, vous ne
pouvez pas créer de certificat numérique pour sécuriser la connexion avec ce
domaine par défaut. Microsoft détient le domaine .onmicrosoft.com : une
autorité de certification publique n’émettra donc pas de certificat. Dans ce cas
de figure, créez un certificat auto-signé et utilisez-le pour configurer le
protocole LDAP sécurisé.
Un certificat auto-signé que vous créez vous-même.
Cette approche est adaptée à des fins de test et c’est ce que montre ce tutoriel.
Le certificat que vous demandez ou que vous créez doit répondre aux exigences
suivantes. Votre domaine managé rencontre des problèmes si vous activez le protocole
LDAP sécurisé avec un certificat non valide :
Émetteur approuvé : le certificat doit être émis par une autorité approuvée par les
ordinateurs qui se connectent au domaine managé à l’aide du protocole LDAP
sécurisé. Cette autorité peut être une autorité de certification publique ou une
autorité de certification d’entreprise approuvée par ces ordinateurs.
Durée de vie : le certificat doit être valide pour les 3 à 6 mois à venir. L’accès du
protocole LDAP sécurisé à votre domaine géré est interrompu lorsque le certificat
expire.
Nom du sujet : le nom du sujet du certificat doit correspondre à votre domaine
managé. Par exemple, si le nom de votre domaine est aaddscontoso.com, le nom
du sujet du certificat doit être * .aaddscontoso.com.
Le nom DNS ou le nom alternatif du sujet du certificat doit être un certificat
générique pour garantir le bon fonctionnement du protocole LDAP sécurisé
avec Azure AD Domain Services. Les contrôleurs de domaine utilisent des noms
aléatoires, et peuvent être supprimés ou ajoutés pour garantir que le service
reste disponible.
Utilisation de la clé : Le certificat doit être configuré pour les signatures
numériques et le chiffrage des clés.
Rôle du certificat : le certificat doit être valide pour l’authentification de serveur
TLS.
Plusieurs outils sont disponibles pour créer un certificat auto-signé, parmi lesquels
OpenSSL, Keytool, MakeCert et l’applet de commande New-SelfSignedCertificate.
Dans ce tutoriel, nous allons créer un certificat auto-signé pour le protocole LDAP
sécurisé en utilisant l’applet de commande New-SelfSignedCertificate.
Ouvrez une fenêtre PowerShell en tant qu’Administrateur, puis exécutez les commandes
suivantes. Remplacez la variable $dnsName par le nom DNS utilisé par votre propre
domaine managé, par exemple aaddscontoso.com :
PowerShell
# Define your own DNS name used by your managed domain

$dnsName="aaddscontoso.com"
# Get the current date to set a one-year expiration

$lifetime=Get-Date
# Create a self-signed certificate for use with Azure AD DS

New-SelfSignedCertificate -Subject *.$dnsName `
-NotAfter $lifetime.AddDays(365) -KeyUsage DigitalSignature,
KeyEncipherment `
-Type SSLServerAuthentication -DnsName *.$dnsName, $dnsName
L’exemple de sortie suivant montre que le certificat a été généré avec succès et qu’il est
stocké dans le magasin de certificats local (LocalMachine\MY) :
Sortie
PS C:\WINDOWS\system32> New-SelfSignedCertificate -Subject *.$dnsName `

>> -NotAfter $lifetime.AddDays(365) -KeyUsage DigitalSignature,
KeyEncipherment `
>> -Type SSLServerAuthentication -DnsName *.$dnsName, $dnsName.com
PSParentPath: Microsoft.PowerShell.Security\Certificate::LocalMachine\MY
Thumbprint Subject
---------- -------
959BD1531A1E674EB09E13BD8534B2C76A45B3E6 CN=aaddscontoso.com
Comprendre et exporter les certificats

nécessaires
Pour utiliser le protocole LDAP sécurisé, le trafic réseau est chiffré avec une
infrastructure à clé publique (PKI).
Une clé privée est appliquée au domaine managé.

Cette clé privée est utilisée pour déchiffrer le trafic LDAP sécurisé. La clé privée
doit être appliquée seulement au domaine managé, et ne doit pas être
distribuée à grande échelle sur des ordinateurs clients.
Un certificat qui inclut la clé privée utilise le format de fichier .PFX.
Au moment de l’exportation du certificat, vous devez spécifier l’algorithme de
chiffrement TripleDES-SHA1. Cela s’applique uniquement au fichier .pfx et n’a
aucun impact sur l’algorithme utilisé par le certificat lui-même. Notez que
l’option TripleDES-SHA1 est disponible uniquement à partir de Windows
Server 2016.
Une clé publique est appliquée aux ordinateurs clients.
Cette clé publique est utilisée pour chiffrer le trafic LDAP sécurisé. La clé
publique peut être distribuée aux ordinateurs clients.
Les certificats sans clé privée utilisent le format de fichier .CER.
Ces deux clés, les clés privées et publiques, permettent de garantir que seuls les
ordinateurs appropriés peuvent communiquer entre eux. Si vous utilisez une autorité de
certification publique ou une autorité de certification d’entreprise, vous recevez un
certificat qui inclut la clé privée et qui peut être appliqué à un domaine managé. La clé
publique doit déjà être connue et approuvée par les ordinateurs clients.
Dans ce tutoriel, vous avez créé un certificat auto-signé avec la clé privée : vous devez
donc exporter les composants privés et publics appropriés.
Exporter un certificat pour Azure AD DS

Pour pouvoir utiliser le certificat numérique créé à l’étape précédente avec votre
domaine managé, vous devez d’abord exporter le certificat vers un fichier de certificat
.PFX qui contient la clé privée.
1. Pour ouvrir la boîte de dialogue Exécuter, sélectionnez les touches WindowsR.
2. Ouvrez la console MMC (Microsoft Management Console) en entrant mmc dans la

boîte de dialogue Exécuter, puis sélectionnez OK.
3. Sur l’invite Contrôle de compte d’utilisateur, cliquez sur Oui pour lancer la console
MMC en tant qu’administrateur.
4. Dans le menu Fichier, sélectionnez Ajouter/Supprimer un composant logiciel

enfichable.
5. Dans l’Assistant Composant logiciel enfichable Certificats, choisissez Compte

d’ordinateur, puis cliquez sur Suivant.
6. Dans la page Sélectionner un ordinateur, sélectionnez Ordinateur local (celui sur

lequel s’exécute cette console) , puis sélectionnez Terminer.
7. Dans la boîte de dialogue Ajouter ou supprimer des composants logiciels

enfichables, sélectionnez OK et ajoutez le composant logiciel enfichable Certificats
dans la console MMC.
8. Dans la fenêtre MMC, développez Racine de la console. Sélectionnez Certificats

(ordinateur local) , puis développez le nœud Personnel, puis le nœud Certificats.
9. Le certificat auto-signé créé à l’étape précédente est affiché, par exemple

aaddscontoso.com. Cliquez avec le bouton droit sur ce certificat, puis choisissez
Toutes les tâches Exporter…
10. Dans l’Assistant Exportation de certificat, sélectionnez Suivant.
11. La clé privée du certificat doit être exportée. Si la clé privée n’est pas incluse dans
le certificat exporté, l’action d’activation du protocole LDAP sécurisé pour votre
domaine managé échoue.
Dans la page Exporter la clé privée, cliquez sur Oui, exporter la clé privée, puis
sélectionnez Suivant.
12. Les domaines managés prennent uniquement en charge le format de fichier de

certificat .PFX qui inclut la clé privée. N’exportez pas le certificat au format de
fichier de certificat .CER sans la clé privée.
Sur la page Format de fichier d’exportation, sélectionnez le format de fichier

Échange d’informations personnelles - PKCS #12 (.PFX) pour le certificat exporté.
Cochez la case pour Inclure tous les certificats dans le chemin d’accès de certification
si possible :
13. Comme ce certificat est utilisé pour déchiffrer des données, vous devez en
contrôler l’accès avec soin. Vous pouvez utiliser un mot de passe pour protéger le
certificat. Sans le mot de passe correct, le certificat ne peut pas être appliqué à un
service.
Dans la page Sécurité, choisissez l’option Mot de passe pour protéger le fichier de
certificat .PFX. L’algorithme de chiffrement doit être TripleDES-SHA1. Entrez et
confirmez un mot de passe, puis sélectionnez Suivant. Ce mot de passe est utilisé
dans la section suivante pour activer le protocole LDAP sécurisé pour votre
domaine managé.
Si vous effectuez une exportation à l’aide de l’applet de commande PowerShell

export-pfxcertificate, vous devez passer l’indicateur -CryptoAlgorithmOption en
utilisant TripleDES_SHA1.
14. Dans la page Fichier à exporter, spécifiez le nom du fichier et l’emplacement où
vous voulez exporter le certificat, par exemple C:\Users\accountname\azure-ad-
ds.pfx. Notez le mot de passe et l’emplacement du fichier .PFX, car vous devrez
fournir ces informations aux étapes suivantes.
15. Dans la page de vérification, sélectionnez Terminer pour exporter le certificat vers
un fichier de certificat .PFX. Une boîte de dialogue de confirmation s’affiche quand
le certificat a été exporté avec succès.
16. Laissez la console MMC ouverte pour l’utiliser dans la section suivante.
Exporter un certificat pour les ordinateurs clients

Les ordinateurs clients doivent approuver l’émetteur du certificat LDAP sécurisé afin
d’être en mesure de se connecter au domaine managé avec LDAPS. Les ordinateurs
clients ont besoin d’un certificat pour chiffrer correctement les données qui sont
déchiffrées par Azure AD DS. Si vous utilisez une autorité de certification publique,
l’ordinateur doit approuver automatiquement ces émetteurs de certificats et disposer
d’un certificat correspondant.
Dans ce tutoriel, vous utilisez un certificat auto-signé et vous générez un certificat
incluant la clé privée de l’étape précédente. À présent, exportons puis installons le
certificat auto-signé dans le magasin de certificats de confiance sur l’ordinateur client :
1. Revenez à la console MMC pour le magasin Certificats (ordinateur local) Personnel

> Certificats. Le certificat auto-signé créé à une étape précédente est affiché, par
exemple aaddscontoso.com. Cliquez avec le bouton droit sur ce certificat, puis
choisissez Toutes les tâches Exporter…
2. Dans l’Assistant Exportation de certificat, sélectionnez Suivant.
3. Comme vous n’avez pas besoin de la clé privée pour les clients, dans la page
Exporter la clé privée, sélectionnez Non, ne pas exporter la clé privée, puis
4. Dans la page Format de fichier d’exportation, sélectionnez le format de fichier

X.509 encodé en base 64 (.cer) pour le certificat exporté :
5. Dans la page Fichier à exporter, spécifiez le nom du fichier et l’emplacement où

vous voulez exporter le certificat, par exemple C:\Users\accountname\azure-ad-ds-
client.cer.
6. Dans la page de vérification, sélectionnez Terminer pour exporter le certificat vers
un fichier de certificat .CER. Une boîte de dialogue de confirmation s’affiche quand
le certificat a été exporté avec succès.
Le fichier de certificat .CER peut désormais être distribué sur des ordinateurs clients qui
doivent approuver la connexion LDAP sécurisée au domaine managé. Installons le
certificat sur l’ordinateur local.
1. Ouvrez l’Explorateur de fichiers et accédez à l’emplacement où vous avez

enregistré le fichier de certificat .CER, par exemple C:\Users\accountname\azure-
ad-ds-client.cer.
2. Cliquez avec le bouton droit sur le fichier de certificat .CER, puis choisissez Installer
le certificat.
3. Dans l’Assistant Importation de certificat, choisissez de stocker le certificat dans la

Machine locale, puis sélectionnez Suivant :
4. Quand vous y êtes invité, choisissez Oui pour permettre à l’ordinateur d’apporter
des modifications.
5. Choisissez de Sélectionner automatiquement le magasin de certificats en

fonction du type de certificat, puis sélectionnez Suivant.
6. Dans la page de vérification, sélectionnez Terminer pour importer le certificat .CER.
Une boîte de dialogue de confirmation s’affiche quand le certificat a été importé
avec succès.
Activer le protocole LDAP sécurisé pour Azure

AD DS
Avec un certificat numérique créé et exporté incluant la clé privée, et l’ordinateur client
défini pour approuver la connexion, activez maintenant le protocole LDAP sécurisé sur
votre domaine managé. Pour activer le protocole LDAP sécurisé sur un domaine
managé, effectuez les étapes de configuration suivantes :
1. Dans le portail Azure , entrez domain services (services de domaine) dans la zone
Rechercher des ressources. Sélectionnez Azure AD Domain Services dans les
résultats de la recherche.
2. Choisissez votre domaine managé, par exemple aaddscontoso.com.
3. Sur le côté gauche de la fenêtre Azure AD DS, choisissez LDAP sécurisé.
4. Par défaut, l’accès LDAP sécurisé à votre domaine managé est désactivé. Basculez
LDAP sécurisé sur Activer.
5. L’accès LDAP sécurisé à votre domaine managé via Internet est désactivé par
défaut. Quand vous activez l’accès LDAP sécurisé public, votre domaine est
vulnérable aux attaques par force brute via Internet. À l’étape suivante, un groupe
de sécurité réseau est configuré pour verrouiller l’accès seulement aux plages
d’adresses IP sources nécessaires.
Basculez Autorisez l’accès LDAP sécurisé sur Internet sur Activer.
6. Sélectionnez l’icône de dossier en regard de Fichier .PFX avec certificat LDAP

sécurisé. Accédez au chemin du fichier .PFX, puis sélectionnez le certificat créé à
l’étape précédente qui inclut la clé privée.
） Important
Comme indiqué dans la section précédente concernant les exigences en

matière de certificats, vous ne pouvez pas utiliser un certificat d’une autorité
de certification publique avec le domaine .onmicrosoft.com par défaut.
Microsoft détient le domaine .onmicrosoft.com : une autorité de certification
publique n’émettra donc pas de certificat.
Vérifiez que votre certificat est au format approprié. Si ce n’est pas le cas, la
plateforme Azure génère des erreurs de validation de certificat quand vous
activez le protocole LDAP sécurisé.
7. Entrez le Mot de passe pour déchiffrer le fichier .PFX défini dans une étape
précédente quand le certificat a été exporté vers un fichier .PFX.
8. Sélectionnez Enregistrer pour activer le protocole LDAP sécurisé.
Une notification vous informe que le protocole LDAP sécurisé est en cours de
configuration pour le domaine managé. Vous ne pouvez pas modifier d’autres
paramètres pour le domaine managé tant que cette opération n’est pas terminée.
L’activation du protocole LDAP sécurisé pour votre domaine managé prend quelques
minutes. Si le certificat LDAP sécurisé que vous fournissez ne correspond pas aux
critères demandés, l’action d’activation du protocole LDAP sécurisé pour le domaine
managé échoue.
Voici quelques raisons d’échec courantes : le nom de domaine est incorrect, l’algorithme
de chiffrement du certificat n’est pas TripleDES-SHA1 ou le certificat expire ou a déjà
expiré. Vous pouvez recréer le certificat avec des paramètres valides, puis activer le
protocole LDAP sécurisé en utilisant ce certificat mis à jour.
Modifier un certificat arrivant à expiration

1. Créez un certificat LDAP sécurisé de remplacement en suivant les étapes de
création d’un certificat pour le protocole LDAP sécurisé.
2. Pour appliquer le certificat de remplacement à Azure AD DS, dans le menu de
gauche d’Azure AD DS dans le portail Azure, sélectionnez LDAP sécurisé, puis
Modifier le certificat.
3. Distribuez le certificat à tous les clients qui se connectent à l’aide du protocole
LDAP sécurisé.
Verrouiller l’accès LDAP sécurisé via Internet

Quand vous activez l’accès LDAP sécurisé via Internet à votre domaine managé, cela
crée une menace de sécurité. Le domaine managé est accessible depuis Internet sur le
port TCP 636. Il est recommandé de restreindre l’accès au domaine managé à des
adresses IP connues spécifiques pour votre environnement. Une règle de groupe de
sécurité réseau Azure peut être utilisée pour limiter l’accès au protocole LDAP sécurisé.
Créons une règle pour autoriser l’accès LDAP sécurisé entrant sur le port TCP 636 à
partir d’un ensemble spécifique d’adresses IP. Une règle DenyAll par défaut avec une
priorité inférieure s’applique à tous les autres trafics entrants provenant d’Internet, de
sorte que seules les adresses spécifiées peuvent atteindre votre domaine managé en
utilisant le protocole LDAP sécurisé.
1. Dans le portail Azure, sélectionnez Groupes de ressources sur le côté gauche.
2. Choisissez votre groupe de ressources, par exemple myResourceGroup, puis

sélectionnez votre groupe de sécurité réseau, par exemple aaads-nsg.
3. La liste des règles de sécurité de trafic entrant et sortant existantes s’affiche. Sur le
côté gauche de la fenêtre du groupe de sécurité réseau, choisissez Paramètres
Règles de sécurité de trafic entrant.
4. Sélectionnez Ajouter, puis créez une règle pour autoriser le port TCP636. Pour
améliorer la sécurité, choisissez la source Adresses IP, puis spécifiez votre propre
adresse ou plage d’adresses IP pour votre organisation.
Paramètre Valeur
Source Adresses IP
Adresses IP sources / Plages Adresse ou plage d’adresses IP valide pour votre

CIDR environnement
Source port ranges *
Destination Quelconque
Plages de ports de destination 636
Protocol TCP
Paramètre Valeur
Action Allow
Priority 401
Nom AllowLDAPS
5. Quand vous êtes prêt, sélectionnez Ajouter pour enregistrer et appliquer la règle.
Configurer une zone DNS pour l’accès externe

Avec l’accès LDAP sécurisé activé via Internet, mettez à jour la zone DNS afin que les
ordinateurs clients puissent détecter ce domaine managé. L’Adresse IP externe de LDAP
sécurisé figure sous l’onglet Propriétés pour votre domaine managé :
Configurez votre fournisseur DNS externe pour créer un enregistrement d’hôte, par
exemple ldaps, qui doit être résolu en cette adresse IP externe. Pour tester localement
d’abord sur votre ordinateur, vous pouvez ’abord créer une entrée dans le fichier hosts
de Windows. Pour modifier le fichier hosts sur votre ordinateur local, ouvrez le Bloc-
notes en tant qu’administrateur, puis ouvrez le fichier
C:\Windows\System32\drivers\etc\hosts
L’exemple d’entrée DNS suivant, avec votre fournisseur DNS externe ou dans le fichier
hosts local, résout le trafic pour ldaps.aaddscontoso.com avec l’adresse IP externe
168.62.205.103 :
168.62.205.103 ldaps.aaddscontoso.com
Tester les requêtes sur le domaine managé

Pour vous connecter et vous lier à votre domaine managé, et effectuer une recherche
sur LDAP, vous devez utiliser l’outil LDP.exe. Cet outil est inclus dans le package Outils
d’administration de serveur distant (RSAT). Pour plus d’informations, consultez Installer
les outils d’administration de serveur distant.
1. Ouvrez LDP.exe, puis connectez-vous au domaine managé. Sélectionnez

Connexion, puis choisissez Se connecter... .
2. Entrez le nom de domaine DNS LDAP sécurisé de votre domaine managé créé à
l’étape précédente, par exemple ldaps.aaddscontoso.com. Pour utiliser le protocole
LDAP sécurisé, définissez Port sur 636, puis cochez la case pour SSL.
3. Sélectionnez OK pour vous connecter au domaine managé.
Ensuite, créez une liaison à votre domaine managé. Les utilisateurs (et les comptes de
service) ne peuvent pas établir des liaisons simples LDAP si vous désactivez la
synchronisation de hachage des mots de passe NTLM sur votre domaine managé. Pour
plus d’informations sur la désactivation de la synchronisation de hachage de mot de
passe NTLM, consultez Sécuriser votre domaine managé.
1. Sélectionnez l’option de menu Connexion, puis choisissez Lier... .

2. Fournissez les informations d’identification d’un compte d’utilisateur appartenant
au domaine managé. Entrez le mot de passe du compte d’utilisateur, puis entrez
votre domaine, par exemple aaddscontoso.com.
3. Pour Type de liaison, choisissez l’option pour Liaison avec informations
d’identification.
4. Sélectionnez OK pour établir une liaison à votre domaine managé.
Pour voir les objets stockés dans votre domaine managé :
1. Sélectionnez l’option de menu Afficher, puis choisissez Arborescence.
2. Laissez le champ BaseDN vide, puis sélectionnez OK.
3. Choisissez un conteneur, par exemple Utilisateurs AADDC, puis cliquez avec le

bouton droit sur le conteneur et choisissez Rechercher.
4. Laissez tels quels les champs préremplis, puis sélectionnez Exécuter. Les résultats
de la requête sont affichés dans la fenêtre de droite, comme illustré dans l’exemple
de sortie suivant :
Pour interroger directement un conteneur spécifique, dans le menu Afficher
Arborescence, vous pouvez spécifier un BaseDN, comme OU=AADDC
Users,DC=AADDSCONTOSO,DC=COM ou OU=AADDC
Computers,DC=AADDSCONTOSO,DC=COM. Pour plus d’informations sur la façon de
mettre en forme et de créer des requêtes, consultez Principes de base des requêtes
LDAP.
７ Notes
Si un certificat auto-signé est utilisé, assurez-vous qu’il a été ajouté dans les
autorités de certification racines de confiance pour que LDAPS fonctionne avec
LDP.exe
Nettoyer les ressources

Si vous avez ajouté une entrée DNS au fichier hosts local de votre ordinateur pour tester
la connectivité dans le cadre de ce tutoriel, supprimez cette entrée et ajoutez un
enregistrement formel dans votre zone DNS. Pour supprimer l’entrée du fichier hosts
local, effectuez les étapes suivantes :
1. Sur votre machine locale, ouvrez le Bloc-notes en tant qu’administrateur.

2. Recherchez et ouvrez le fichier C:\Windows\System32\drivers\etc\hosts
3. Supprimez la ligne de l’enregistrement que vous avez ajouté, par exemple
168.62.205.103 ldaps.aaddscontoso.com
Dépannage
Si vous voyez une erreur indiquant que LDAP.exe ne peut pas se connecter, essayez
d’examiner les différentes phases de l’établissement de la connexion :
1. Configuration du contrôleur de domaine

2. Configuration du client
3. Réseau
4. Établissement de la session TLS
Pour que le nom d’objet du certificat corresponde, le contrôleur de domaine utilise le

nom de domaine Azure AD DS (et non le nom de domaine Azure AD) pour rechercher le
certificat dans son magasin de certificats. Les fautes d’orthographe, par exemple,
empêchent le contrôleur de domaine de sélectionner le bon certificat.
Le client tente d’établir la connexion TLS en utilisant le nom que vous avez fourni. Le
trafic doit aller jusqu’au bout. Le contrôleur de domaine envoie la clé publique du cert
d’authentification serveur. Le cert doit avoir l’utilisation appropriée dans le certificat, le
nom signé dans le nom d’objet doit être compatible pour que le client sache que le
serveur est le nom DNS auquel vous vous connectez (autrement dit, un caractère
générique fonctionne sans faute d’orthographe) et le client doit faire confiance à
l’émetteur. Vous pouvez rechercher les problèmes dans cette chaîne dans le journal
système de l’observateur d’événements et filtrer les événements où la source est égale à
Schannel. Une fois ces éléments en place, ils forment une clé de session.
Pour plus d’informations, consultez l’établissement d’une liaison TLS.
Étapes suivantes
＂ Créer un certificat numérique pour une utilisation avec Azure AD DS

＂ Activer le protocole LDAP sécurisé pour Azure AD DS
＂ Configurer le protocole LDAP sécurisé pour une utilisation sur l’internet public
＂ Lier et tester le protocole LDAP sécurisé pour un domaine managé
Configurer la synchronisation de hachage du mot de passe pour un

environnement Azure AD hybride
Tutoriel : Activer la synchronisation du
mot de passe dans Azure
Active Directory Domain Services pour
les environnements hybrides
Article • 06/04/2023 • 5 minutes de lecture
Pour les environnements hybrides, un locataire Azure Active Directory (Azure AD) peut
être configuré pour se synchroniser avec un environnement Active Directory Domain
Services (AD DS) local à l’aide d’Azure AD Connect. Par défaut, Azure AD Connect ne
synchronise pas les hachages de mot de passe NTLM (NT LAN Manager) et Kerberos
existants demandés pour Azure Active Directory Domain Services (Azure AD DS).
Pour utiliser Azure AD DS avec des comptes synchronisés à partir d’un environnement
AD DS local, vous devez configurer Azure AD Connect afin de synchroniser ces hachages
de mot de passe nécessaires pour l’authentification NTLM et Kerberos. Une fois
Azure AD Connect configuré, un événement de création de compte ou de modification
de mot de passe local synchronise également les hachages de mot de passe existants
avec Azure AD.
Vous n’avez pas besoin d’effectuer ces étapes si vous utilisez des comptes cloud
uniquement sans environnement AD DS local.
Dans ce tutoriel, vous allez voir comment :
＂ Découvrir pourquoi les hachages de mot de passe NTLM et Kerberos existants sont
nécessaires
＂ Configurer la synchronisation de hachage du mot de passe existant pour Azure AD
Connect
Prérequis
Pour effectuer ce didacticiel, vous avez besoin des ressources suivantes :
Un locataire Azure Active Directory associé à votre abonnement et qui est
synchronisé avec un annuaire local à l’aide d’Azure AD Connect.
Si nécessaire, activez Azure AD Connect pour la synchronisation de hachage du
mot de passe.
Domain Services.
Synchronisation de hachage du mot de passe à

l’aide d’Azure AD Connect
Azure AD Connect est utilisé pour synchroniser des objets tels que des comptes et des
groupes d’utilisateurs à partir d’un environnement AD DS local dans un locataire
Azure AD. Dans le cadre du processus, la synchronisation de hachage du mot de passe
permet à des comptes d’utiliser le même mot de passe dans l’environnement AD DS
local et dans Azure AD.
hachages de mot de passe dans un format adapté à l’authentification NTLM et Kerberos.
Azure AD ne stocke pas les hachages de mot de passe au format exigé pour
l’authentification NTLM ou Kerberos tant que vous n’activez pas Azure AD DS pour votre
locataire. Pour des raisons de sécurité, Azure AD ne stocke pas non plus d’informations
d’identification de mot de passe sous forme de texte en clair. Par conséquent, Azure AD
ne peut pas générer automatiquement ces hachages de mot de passe NTLM ou
Kerberos en fonction des informations d’identification existantes des utilisateurs.
Azure AD Connect peut être configuré pour synchroniser les hachages de mot de passe
NTLM ou Kerberos exigés pour Azure AD DS. Vérifiez que vous avez effectué les étapes
nécessaires pour activer Azure AD Connect pour la synchronisation de hachage de mot
de passe. Si vous aviez une instance d’Azure AD Connect, téléchargez et mettez à jour la
dernière version pour garantir que vous pouvez synchroniser les hachages de mot de
passe existant pour NTLM et Kerberos. Cette fonctionnalité n’est pas disponible dans les
versions antérieures d’Azure AD Connect ou avec l’outil DirSync existant. Azure AD
Connect version 1.1.614.0 ou ultérieure est nécessaire.
） Important
Azure AD Connect doit uniquement être installé et configuré pour la

synchronisation avec des environnements AD DS locaux. L’installation d’Azure AD
Connect n’est pas prise en charge dans un domaine managé Azure AD DS pour
resynchroniser des objets sur Azure AD.
Activer la synchronisation des hachages de mot

de passe
Une fois Azure AD Connect installé et configuré pour se synchroniser avec Azure AD,
configurez la synchronisation du hachage de mot de passe existante pour NTLM et
Kerberos. Un script PowerShell est utilisé pour configurer les paramètres obligatoires,
puis démarrer une synchronisation de mot de passe complète avec Azure AD. Une fois
ce processus de synchronisation du hachage de mot de passe Azure AD Connect
terminé, les utilisateurs peuvent se connecter aux applications avec Azure AD DS qui
utilisent des hachages de mot de passe NTLM ou Kerberos existants.
1. Sur l’ordinateur sur lequel Azure AD Connect est installé, dans le menu Démarrer,
ouvrez Azure AD Connect > Service de synchronisation.
2. Sélectionnez l’onglet Connecteurs. Les informations de connexion utilisées pour

établir la synchronisation entre l’environnement AD DS local et Azure AD sont
listées.
Le Type indique Windows Azure Active Directory (Microsoft) pour le connecteur

Azure AD ou Active Directory Domain Services pour le connecteur AD DS local.
Notez les noms de connecteurs à utiliser dans le script PowerShell à l’étape
suivante.
Dans cet exemple de capture d’écran, les connecteurs suivants sont utilisés :
Le connecteur Azure AD est nommé contoso.onmicrosoft.com - Azure AD

Le connecteur AD DS local est nommé onprem.contoso.com
3. Copiez et collez le script PowerShell suivant sur l’ordinateur sur lequel Azure AD
Connect est installé. Le script déclenche une synchronisation de mot de passe
complète qui inclut les hachages de mot de passe existants. Mettez à jour les
variables $azureadConnector et $adConnector avec les noms de connecteurs notés
à l’étape précédente.
Exécutez ce script sur chaque forêt AD pour synchroniser les hachages de mot de
passe NTLM et Kerberos de compte local avec Azure AD.
PowerShell
# Define the Azure AD Connect connector names and import the required
PowerShell module
$azureadConnector = "<CASE SENSITIVE AZURE AD CONNECTOR NAME>"
$adConnector = "<CASE SENSITIVE AD DS CONNECTOR NAME>"
Import-Module "C:\Program Files\Microsoft Azure AD

Sync\Bin\ADSync\ADSync.psd1"
Import-Module "C:\Program Files\Microsoft Azure Active Directory

Connect\AdSyncConfig\AdSyncConfig.psm1"
# Create a new ForceFullPasswordSync configuration parameter object

then
# update the existing connector with this new configuration
$c = Get-ADSyncConnector -Name $adConnector
$p = New-Object
Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParame
ter "Microsoft.Synchronize.ForceFullPasswordSync", String,
ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c
# Disable and re-enable Azure AD Connect to force a full password

synchronization
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -

TargetConnector $azureadConnector -Enable $false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector -

TargetConnector $azureadConnector -Enable $true
En fonction de la taille de votre annuaire en termes de nombre de comptes et de

groupes, la synchronisation des hachages de mot de passe existants avec
Azure AD peut prendre un certain temps. Après avoir été synchronisés avec
Azure AD, les mots de passe sont ensuite synchronisés avec le domaine managé.
Étapes suivantes
Dans ce tutoriel, vous avez appris à effectuer les opérations suivantes :
＂ Découvrir pourquoi les hachages de mot de passe NTLM et Kerberos existants sont
nécessaires
＂ Configurer la synchronisation de hachage du mot de passe existant pour Azure AD
Connect
Découvrir comment fonctionne la synchronisation dans un domaine managé

Azure AD Domain Services
Tutoriel : Créer et utiliser des jeux de
réplicas pour la résilience ou la
géolocalisation dans Azure Active
Article • 02/06/2023
Pour améliorer la résilience d’un domaine managé Azure Active Directory Domain
Services (Azure AD DS) ou pour effectuer un déploiement vers des zones géographiques
supplémentaires proches de vos applications, vous pouvez utiliser des jeux de réplicas.
Chaque espace de noms de domaine managé Azure AD DS, tel que aaddscontoso.com,
contient un jeu de réplicas initial. La possibilité de créer des jeux de réplicas
supplémentaires dans d’autres régions Azure fait bénéficier un domaine managé de la
résilience géographique.
Vous pouvez ajouter un jeu de réplicas à n’importe quel réseau virtuel appairé d’une
région Azure prenant en charge Azure AD DS.
＂ Comprendre la configuration requise des réseaux virtuels

＂ Créer un jeu de réplicas
＂ Supprimer un jeu de réplicas
Prérequis

Un domaine managé Azure Active Directory Domain Services créé à l’aide d’un
modèle de déploiement Azure Resource Manager et configuré dans votre locataire
Azure AD.
Domain Services.
） Important
Vous devez utiliser une référence (SKU) minimale d’Enterprise pour votre
domaine managé pour prendre en charge les ensembles de réplica. Si
nécessaire, changez de référence SKU pour un domaine managé.

Dans ce tutoriel, vous allez créer et gérer des jeux de réplicas à partir du portail Azure.
Pour commencer, connectez-vous au portail Azure .
Mise en réseau - Éléments à prendre en compte

Les réseaux virtuels qui hébergent des jeux de réplicas doivent pouvoir communiquer
entre eux. Les applications et les services qui dépendent d’Azure AD DS ont également
besoin d’une connectivité réseau avec les réseaux virtuels hébergeant les jeux de
réplicas. L’appairage de réseaux virtuels Azure doit être configuré entre tous les réseaux
virtuels pour créer un réseau entièrement maillé. Ces appairages permettent une
réplication intrasite efficace entre les jeux de réplicas.
Avant d’utiliser des jeux de réplicas dans Azure AD DS, prenez connaissance des
exigences pour les réseaux virtuels Azure :
Évitez les espaces d’adressage IP qui se chevauchent pour permettre l’appairage

de réseaux virtuels et le routage.
Créez des sous-réseaux avec suffisamment d’adresses IP pour prendre en charge
votre scénario.
Vérifiez qu’Azure AD DS possède son propre sous-réseau. Ne partagez pas ce
sous-réseau de réseau virtuel avec les machines virtuelles et services d’application.
Les réseaux virtuels appairés ne sont PAS transitifs.
 Conseil
Quand vous créez un jeu de réplicas sur le portail Azure, les appairages entre
réseaux virtuels sont créées automatiquement.
Si nécessaire, vous pouvez créer un réseau virtuel et un sous-réseau au moment
d’ajouter un jeu de réplicas sur le portail Azure. Vous pouvez aussi choisir des
ressources de réseau virtuel existantes dans la région de destination pour un jeu de
réplicas et laisser les appairages se créer automatiquement s’ils n’existent pas déjà.
Créer un jeu de réplicas

Quand vous créez un domaine managé, tel que aaddscontoso.com, un jeu de réplicas
initial est créé. Les jeux de réplicas supplémentaires partagent le même espace de noms
et la même configuration. Les modifications apportées à Azure AD DS, notamment en ce
qui concerne la configuration, l’identité de l’utilisateur et les informations
d’identification, les groupes, les objets de stratégie de groupe, les objets ordinateur et
autres modifications, sont appliquées à tous les jeux de réplicas du domaine managé via
la réplication AD DS.
Dans ce tutoriel, vous allez créer un jeu de réplicas supplémentaire dans une région
Azure différente de celle du jeu de réplicas Azure AD DS initial.
Pour créer un jeu de réplicas supplémentaire, effectuez les étapes suivantes :
1. Sur le portail Azure, recherchez et sélectionnez Azure AD Domain Services.
3. Sur le côté gauche, sélectionnez Jeux de réplicas. Chaque domaine managé

comprend un jeu de réplicas initial dans la région sélectionnée, comme le montre
la capture d’écran d’exemple ci-dessous :
Pour créer un jeu de réplicas supplémentaire, sélectionnez + Ajouter.
4. Dans la fenêtre Ajouter un jeu de réplicas, sélectionnez la région de destination, par

exemple USA Est.
Sélectionnez un réseau virtuel dans la région de destination, par exemple vnet-
eastus, puis choisissez un sous-réseau, par exemple aadds-subnet. Si nécessaire,
choisissez Créer nouveau pour ajouter un réseau virtuel dans la région de
destination, puis Gérer pour créer un sous-réseau pour Azure AD DS.
S’ils n’existent pas déjà, les appairages de réseaux virtuels Azure sont
automatiquement créés entre le réseau virtuel de votre domaine managé et le
réseau virtuel de destination.
La capture d’écran d’exemple suivante illustre le processus de création d’un jeu de

réplicas dans la région USA Est :
5. Quand vous êtes prêt, sélectionnez Enregistrer.
Le processus de création du jeu de réplicas prend un certain temps, car les ressources
sont créées dans la région de destination. Le domaine managé lui-même est ensuite
répliqué via la réplication AD DS.
Le jeu de réplicas est présenté comme étant en cours de provisionnement pendant que
le déploiement se produit, comme le montre la capture d’écran d’exemple suivante. Une
fois terminé, le jeu de réplicas indique qu’il est en cours d’exécution.
Supprimer un jeu de réplicas
Un domaine managé est actuellement limité à cinq réplicas : le jeu de réplicas initial et
quatre jeux de réplicas supplémentaires. Si vous n’avez plus besoin d’un jeu de réplicas
ou si vous voulez créer un jeu de réplicas dans une autre région, vous pouvez supprimer
les jeux de réplicas superflus.
） Important
Vous ne pouvez pas supprimer le dernier jeu de réplicas ou le jeu de réplicas initial
dans un domaine managé.
Pour supprimer un jeu de réplicas, effectuez les étapes suivantes :

3. Sur le côté gauche, sélectionnez Jeux de réplicas. Dans la liste des jeux de réplicas,
sélectionnez le menu contextuel ... en regard du jeu de réplicas à supprimer.
4. Sélectionnez Supprimer dans le menu contextuel, puis confirmez que vous voulez
supprimer le jeu de réplicas.
5. Dans la machine virtuelle de gestion Azure ADDS, accédez à la console DNS et
supprimez manuellement les enregistrements DNS pour les contrôleurs de
domaine du jeu de réplicas supprimé.
７ Notes
La suppression d’un jeu de réplicas peut être une opération longue.
Si vous n’avez plus besoin du réseau virtuel ou de l’appairage utilisé par le jeu de
réplicas, vous pouvez aussi supprimer ces ressources. Vérifiez qu’aucune autre ressource
d’application de l’autre région n’a besoin de connexions réseau avant de la supprimer.
Étapes suivantes
＂ Configurer le peering de réseaux virtuels

＂ Créer un jeu de réplicas dans une autre région géographique
＂ Supprimer un jeu de réplicas
Pour plus d’informations conceptuelles, découvrez comment les jeux de réplicas

fonctionnent dans Azure AD DS.
Concepts et fonctionnalités des jeux de réplicas

Tutoriel : Effectuer une simulation de
reprise d’activité à l’aide de jeux de
réplicas dans Azure Active Directory
Domain Services
Article • 01/06/2023
Cette rubrique montre comment effectuer une simulation de reprise d’activité (DR) pour
Azure AD Domain Services (Azure AD DS) à l’aide de jeux de réplicas. La mise hors
connexion de l’un des jeux de réplicas est simulée en modifiant les propriétés du réseau
virtuel afin de bloquer l’accès client à ce dernier. Il ne s’agit pas d’une véritable reprise
d’activité car le jeu de réplicas n’est pas mis hors connexion.
La simulation de reprise d’activité couvre les opérations suivantes :
1. Un ordinateur client est connecté à un jeu de réplicas donné. Il peut s’authentifier

auprès du domaine et effectuer des requêtes LDAP.
2. La connexion du client au jeu de réplicas va être arrêtée. Pour ce faire, l’accès au
réseau est restreint.
3. Le client établit ensuite une nouvelle connexion avec l’autre jeu de réplicas. Une
fois cette connexion établie, le client est capable de s’authentifier auprès du
domaine et d’effectuer des requêtes LDAP.
4. Le membre du domaine est redémarré, et un utilisateur du domaine peut ensuite
se connecter à l’issue du redémarrage.
5. Les restrictions d’accès au réseau sont supprimées et le client peut se connecter au
jeu de réplicas d’origine.
Prérequis
Les conditions suivantes doivent être remplies pour pouvoir effectuer la simulation de
reprise d’activité :
Une instance Azure AD DS active est déployée avec au moins un jeu de réplicas
supplémentaire en place. Le domaine doit être dans un état sain.
Un ordinateur client est joint au domaine hébergé Azure AD DS. Le client doit se
trouver dans son propre réseau virtuel, un peering de réseaux virtuels est activé
avec les deux réseaux virtuels des jeux de réplicas, et le réseau virtuel doit avoir les
adresses IP de tous les contrôleurs de domaine dans les jeux de réplicas listés dans
DNS.
Validation de l’environnement
1. Connectez-vous à l’ordinateur client à l’aide d’un compte de domaine.
2. Installez les outils RSAT Active Directory Domain Services.
3. Ouvrez une fenêtre PowerShell avec des privilèges élevés.
4. Effectuez les vérifications de validation de domaine de base :
Exécutez nslookup [domain] pour vérifier que la résolution DNS fonctionne

correctement.
Exécutez nltest /dsgetdc: pour retourner une réussite et indiquer quel
contrôleur de domaine est actuellement utilisé.
Exécutez nltest /dclist: pour retourner la liste complète des contrôleurs de
domaine dans l’annuaire.
5. Effectuez la validation de base des contrôleurs de domaine sur chaque contrôleur

de domaine inclus dans l’annuaire (vous pouvez obtenir la liste complète à partir
de la sortie de nltest/dclist:) :
Exécutez nltest /sc_reset:[domain name]\[domain controller name] pour

établir une connexion sécurisée avec le contrôleur de domaine.
Exécutez Get-AdDomain pour récupérer les paramètres de base de l’annuaire.
Effectuer une simulation de reprise d’activité

Vous allez effectuer ces opérations pour chaque jeu de réplicas inclus dans l’instance
Azure AD DS. Ainsi, vous allez simuler une panne pour chaque jeu de réplicas. Lorsque
des contrôleurs de domaine ne sont pas accessibles, le client bascule automatiquement
vers un contrôleur de domaine accessible et cette expérience doit se dérouler sans
heurts pour l’utilisateur final ou la charge de travail. Il est donc primordial que les
applications et services ne pointent pas vers un contrôleur de domaine spécifique.
1. Identifiez les contrôleurs de domaine dans le jeu de réplicas dont vous voulez
simuler la mise hors connexion.
2. Sur l’ordinateur client, connectez-vous à l’un des contrôleurs de domaine en
utilisant nltest /sc_reset:[domain]\[domain controller name] .
3. Dans le portail Azure, accédez au peering de réseaux virtuels du client et mettez à
jour les propriétés afin que tout le trafic entre le client et le jeu de réplicas soit
bloqué.
a. Sélectionnez le réseau appairé à mettre à jour.
b. Sélectionnez l’option permettant de bloquer tout le trafic réseau qui entre dans
le réseau virtuel ou en sort.
4. Sur l’ordinateur client, essayez de rétablir une connexion sécurisée aux deux
contrôleurs de domaine de l’étape 2 en utilisant la même commande nltest. Ces
opérations doivent échouer, car la connectivité réseau a été bloquée.
5. Exécutez Get-AdDomain et Get-AdForest pour obtenir les propriétés d’annuaire de
base. Ces appels aboutissent, car ils accèdent automatiquement à l’un des
contrôleurs de domaine dans l’autre jeu de réplicas.
6. Redémarrez le client et connectez-vous avec le même compte de domaine. Celui-ci
indique que l’authentification fonctionne encore comme prévu et que les
connexions ne sont pas bloquées.
7. Dans le portail Azure, accédez au peering de réseaux virtuels du client et mettez à
jour les propriétés afin que tout le trafic soit débloqué. Cette opération annule les
modifications apportées à l’étape 3.
8. Sur l’ordinateur client, essayez de rétablir une connexion sécurisée aux contrôleurs
de domaine de l’étape 2 en utilisant la même commande nltest. Ces opérations
doivent aboutir, car la connectivité réseau a été débloquée.
Ces opérations montrent que le domaine est toujours disponible, même si l’un des jeux
de réplicas est inaccessible par le client. Effectuez cette série d’étapes pour chaque jeu
de réplicas inclus dans l’instance Azure AD DS.
Résumé
Une fois que vous aurez terminé ces étapes, vous allez voir que les membres du
domaine continuent d’accéder à l’annuaire si l’un des jeux de réplicas n’est pas
accessible dans Azure AD DS. Vous pouvez simuler le même comportement en bloquant
tout l’accès réseau pour un jeu de réplicas au lieu d’un ordinateur client, mais nous vous
le déconseillons. Cette façon de procéder ne modifie pas le comportement du point de
vue du client, mais elle affecte l’intégrité de votre instance Azure AD DS tant que l’accès
réseau n’est pas restauré.
Étapes suivantes
＂ Valider la connectivité du client aux contrôleurs de domaine dans un jeu de réplicas

＂ Bloquer le trafic réseau entre le client et le jeu de réplicas
＂ Valider la connectivité du client aux contrôleurs de domaine dans un autre jeu de
réplicas
Pour plus d’informations conceptuelles, découvrez comment les jeux de réplicas

fonctionnent dans Azure AD DS.
Concepts et fonctionnalités des jeux de réplicas

Tutoriel : Créer et configurer un
Domain Services avec des options de
configuration avancées
ressources.
Vous pouvez créer un domaine managé avec des options de configuration par défaut
pour la mise en réseau et la synchronisation, ou définir manuellement ces paramètres.
Ce tutoriel montre comment définir ces options de configuration avancées pour créer et
configurer un domaine managé Azure AD DS avec le portail Azure.
＂ Configurer les paramètres de réseau virtuel et DNS pour un domaine managé

＂ Activer la synchronisation de hachage de mot de passe
Prérequis
Bien que ce ne soit pas obligatoire pour Azure AD DS, nous vous recommandons de
configurer la réinitialisation de mot de passe en libre-service (SSPR) pour le locataire
Azure AD. Les utilisateurs peuvent changer leur mot de passe sans SSPR, mais SSPR aide
s’ils oublient leur mot de passe et doivent les réinitialiser.
） Important
Une fois que vous avez créé un domaine managé, vous ne pouvez pas le déplacer
dans un autre abonnement, groupe de ressources ou région. Veillez à sélectionner
l’abonnement, le groupe de ressources et la région les plus appropriés quand vous
déployez le domaine managé.

Créer un domaine managé et configurer les

paramètres de base
Pour lancer l’Assistant Activer Azure AD Domain Services, procédez comme suit :
ressource.
2. Entrez Domain Services dans la barre de recherche, puis choisissez Azure AD
Domain Services dans les suggestions de recherche.
3. Dans la page Azure AD Domain Services, cliquez sur le bouton Créer. L’Assistant
Activer Azure AD Domain Services est lancé.
4. Sélectionnez l’Abonnement Azure dans lequel vous souhaitez créer le domaine
managé.
5. Sélectionnez le Groupe de ressources auquel le domaine managé doit appartenir.
Choisissez de Créer ou de sélectionner un groupe de ressources existant.
Quand vous créez un domaine managé, vous spécifiez un nom DNS. Voici quelques
considérations liées au choix de ce nom DNS :

certificat.
applications.
résolution DNS.
 Conseil

noms DNS existants. Il est recommandé d’utiliser un nom de domaine distinct de
tout espace de noms DNS local ou Azure existant.

supplémentaires.
Dans ces tutoriels et articles de guide pratique, le domaine personnalisé

aaddscontoso.com est utilisé comme exemple simple. Dans toutes les commandes,

Renseignez les champs de la fenêtre De base du portail Azure pour créer un domaine
managé :
1. Entrez un Nom de domaine DNS pour votre domaine managé, en tenant compte
des points précédents.
2. Choisissez l’Emplacement Azure dans lequel créer le domaine managé. Si vous

choisissez une région qui prend en charge les Zones de disponibilité, les
ressources Azure AD DS sont réparties entre les zones pour assurer une
redondance supplémentaire.
 Conseil
Les Zones de disponibilité sont des emplacements physiques uniques au sein

d’une région Azure. Chaque zone de disponibilité est composée d’un ou de
refroidissement et d’un réseau indépendants. Pour garantir la résilience, un
minimum de trois zones distinctes sont activées dans toutes les régions.
Vous ne devez rien configurer pour la répartition d’Azure AD DS entre les

zones. La plateforme Azure gère automatiquement la répartition de zone des
ressources. Pour plus d’informations et pour connaître la disponibilité
régionale, consultez Que sont les zones de disponibilité dans Azure ?
3. La référence SKU détermine le niveau de performance et la fréquence de

sauvegarde. Vous pouvez changer de référence SKU après la création du domaine
managé en cas de changement des besoins métier. Pour plus d’informations,
consultez Concepts relatifs aux références SKU dans Azure AD DS.
Pour ce tutoriel, sélectionnez la référence SKU Standard.
4. Une forêt est une construction logique utilisée par Active Directory Domain
Services pour regrouper un ou plusieurs domaines.
5. Pour configurer manuellement des options supplémentaires, choisissez Suivant -

Réseau. Sinon, sélectionnez Vérifier + créer pour accepter les options de
configuration par défaut, puis passez à la section Déployer votre domaine managé.
Quand vous choisissez cette option de création, les paramètres par défaut suivants
sont configurés :
Crée un réseau virtuel nommé aadds-vnet qui utilise la plage d’adresses IP

10.0.1.0/24.
Crée un sous-réseau appelé aadds-subnet qui utilise la plage d’adresses IP
10.0.1.0/24.
Synchronise tous les utilisateurs entre Azure AD et le domaine managé.
Créer et configurer le réseau virtuel

Pour fournir une connectivité, un réseau virtuel Azure et un sous-réseau dédié sont
nécessaires. Azure AD DS est activé dans ce sous-réseau du réseau virtuel. Dans ce
tutoriel, vous créez un réseau virtuel, mais vous pouvez aussi choisir d’utiliser un réseau
virtuel existant. Dans les deux approches, vous devez créer un sous-réseau dédié qui
sera utilisé par Azure AD DS.
Voici certains éléments à prendre en compte pour ce sous-réseau de réseau virtuel

dédié :
Le sous-réseau doit avoir au moins 3 à 5 adresses IP disponibles dans sa plage

d’adresses pour prendre en charge les ressources Azure AD DS.
Ne sélectionnez pas le sous-réseau de passerelle pour le déploiement d’Azure AD
DS. Le déploiement d’Azure AD DS dans un sous-réseau de passerelle n’est pas pris
en charge.
Ne déployez pas d’autres machines virtuelles sur le sous-réseau. Les applications et
les machines virtuelles utilisent souvent des groupes de sécurité réseau pour
sécuriser la connectivité. L’exécution de ces charges de travail dans un sous-réseau
distinct vous permet d’appliquer ces groupes de sécurité réseau sans interrompre
la connexion à votre domaine managé.
Pour plus d’informations sur la planification et la configuration du réseau virtuel,

consultez Considérations relatives au réseau pour Azure Active Directory Domain
Services.
Renseignez les champs de la fenêtre Réseau comme suit :
1. Dans la page Réseau, choisissez un réseau virtuel où déployer Azure AD DS dans le
menu déroulant, ou sélectionnez Créer.
a. Si vous choisissez de créer un réseau virtuel, entrez un nom pour ce nouveau
réseau, comme myVnet, puis spécifiez une plage d’adresses, par exemple
10.0.1.0/24.
b. Créez un sous-réseau dédié avec un nom explicite, par exemple DomainServices.
Spécifiez une plage d’adresses, par exemple 10.0.1.0/24.

Veillez à choisir une plage d’adresses qui se trouve dans votre plage d’adresses IP
privée. Les plages d’adresses IP qui ne vous appartiennent pas et qui se trouvent
dans l’espace d’adressage public provoquent des erreurs dans Azure AD DS.
2. Sélectionnez un sous-réseau de réseau virtuel, par exemple DomainServices.
3. Quand vous êtes prêt, choisissez Suivant - Administration.
Configurer le groupe d’administration

Un groupe d’administration spécial nommé Administrateurs AAD DC est utilisé pour la
gestion du domaine Azure AD DS. Les membres de ce groupe bénéficient
d’autorisations d’administration sur les machines virtuelles jointes au domaine managé.
Sur les machines virtuelles jointes au domaine, ce groupe est ajouté au groupe des
administrateurs locaux. Les membres de ce groupe peuvent aussi utiliser Bureau à
distance pour se connecter à distance aux machines virtuelles jointes au domaine.
） Important
Vous ne disposez pas des autorisations Administrateur de domaine ou

Administrateur d’entreprise sur un domaine managé avec Azure AD DS. Ces
autorisations sont réservées par le service et ne sont pas disponibles pour les
utilisateurs au sein du locataire.
Au lieu de cela, le groupe Administrateurs AAD DC vous permet d’effectuer des

opérations privilégiées. Ces opérations incluent l’appartenance au groupe
d’administration sur les machines virtuelles jointes au domaine ainsi que la
configuration de la stratégie de groupe.
L’Assistant crée automatiquement le groupe Administrateurs AAD DC dans votre
annuaire Azure AD. Si vous disposez d’un groupe du même nom dans votre répertoire
Azure AD, l’Assistant sélectionne ce groupe. Vous pouvez aussi choisir d’ajouter des
utilisateurs supplémentaires à ce groupe Administrateurs AAD DC lors du processus de
déploiement. Ces étapes peuvent être effectuées ultérieurement.
1. Pour ajouter des utilisateurs supplémentaires à ce groupe Administrateurs AAD DC,

sélectionnez Gérer l’appartenance au groupe.
2. Sélectionnez le bouton Ajouter des membres, puis recherchez et sélectionnez les

utilisateurs dans votre annuaire Azure AD. Par exemple, recherchez votre propre
compte, puis ajoutez-le au groupe Administrateurs AAD DC.
3. Si vous le souhaitez, changez les destinataires ou ajoutez des destinataires

supplémentaires auxquels doivent être envoyées les notifications des alertes
générées dans le domaine managé qui nécessitent une attention particulière.
4. Quand vous êtes prêt, choisissez Suivant - Synchronisation.
Configurer la synchronisation
Azure AD DS vous permet de synchroniser tous les utilisateurs et les groupes
disponibles dans Azure AD, ou d’effectuer une synchronisation limitée seulement à des
groupes spécifiques. Vous pouvez modifier l’étendue de synchronisation maintenant, ou
une fois que le domaine managé est déployé. Pour plus d’informations, consultez
Synchronisation limitée d’Azure AD Domain Services.
1. Pour ce tutoriel, choisissez de synchroniser Tous les utilisateurs et groupes. Ce

choix de synchronisation est l’option par défaut.
2. Sélectionnez Revoir + créer.
Déployer le domaine managé

Dans la page Résumé de l’Assistant, examinez les paramètres de configuration du
domaine managé. Vous pouvez revenir à n’importe quelle étape de l’Assistant pour faire
des modifications. Pour redéployer un domaine managé sur un autre client Azure AD en
utilisant ces mêmes options de configuration, vous pouvez également télécharger un
modèle pour l’automatisation.
1. Pour créer le domaine managé, sélectionnez Créer. Une remarque s’affiche pour
signaler que certaines options de configuration, telles que le nom DNS ou le
réseau virtuel, ne sont plus modifiables une fois que le domaine managé Azure
AD DS a été créé. Pour continuer, sélectionnez OK.
2. Le processus d’approvisionnement de votre domaine managé peut prendre jusqu’à

une heure. Vous voyez une notification dans le portail indiquant la progression de
votre déploiement Azure AD DS. Sélectionnez la notification pour voir la
progression détaillée du déploiement.
3. Sélectionnez votre groupe de ressources, tel que myResourceGroup, puis choisissez

votre domaine managé dans la liste des ressources Azure, par exemple
aaddscontoso.com. L’onglet Vue d’ensemble montre que le domaine managé est
actuellement en cours de Déploiement. Vous ne pouvez pas configurer le domaine
managé tant qu’il n’est pas entièrement provisionné.
4. Lorsque le domaine managé est entièrement approvisionné, l’onglet Vue

d’ensemble affiche l’état du domaine comme En cours d’exécution.
） Important
Le domaine managé est associé à votre locataire Azure AD. Pendant le processus
d’approvisionnement, Azure AD DS crée deux applications d’entreprise nommées
Services de contrôleur de domaine et AzureActiveDirectoryDomainControllerServices
dans le locataire Azure AD. Ces applications d’entreprise sont nécessaires pour
entretenir votre domaine géré. Ne supprimez pas ces applications.
Mettre à jour les paramètres DNS pour le

réseau virtuel Azure
Avec Azure AD DS correctement déployé, configurez maintenant le réseau virtuel pour
permettre à d’autres machines virtuelles et applications connectées d’utiliser le domaine
managé. Pour fournir cette connectivité, mettez à jour les paramètres du serveur DNS
pour que votre réseau virtuel pointe vers les deux adresses IP où le domaine managé est
déployé.
1. L’onglet Vue d’ensemble pour votre domaine managé montre quelques Étapes de
configuration obligatoires. La première étape de configuration est de mettre à
jour les paramètres du serveur DNS pour votre réseau virtuel. Une fois les
paramètres DNS correctement configurés, cette étape n’apparaît plus.
Les adresses listées sont les contrôleurs de domaine à utiliser dans le réseau
virtuel. Dans cet exemple, ces adresses sont 10.0.1.4 et 10.0.1.5. Vous pouvez
trouver ultérieurement ces adresses IP sous l’onglet Propriétés.
2. Pour mettre à jour les paramètres du serveur DNS pour le réseau virtuel,
sélectionnez le bouton Configurer. Les paramètres DNS sont configurés
automatiquement pour votre réseau virtuel.
 Conseil
Si vous avez sélectionné un réseau virtuel existant au cours des étapes précédentes,
les machines virtuelles connectées au réseau obtiennent les nouveaux paramètres
DNS seulement après un redémarrage. Vous pouvez redémarrer les machines
virtuelles en utilisant le portail Azure, Azure PowerShell ou Azure CLI.
Activer les comptes d’utilisateur pour Azure AD

DS
７ Notes
Une fois configurés de façon appropriée, les hachages de mot de passe utilisables
sont stockés dans le domaine managé. Si vous supprimez le domaine managé, tout
hachage de mot de passe stocké à ce stade est également supprimé.
Les informations d’identification synchronisées dans Azure AD ne peuvent pas être

réutilisées si vous créez par la suite un domaine managé : vous devez reconfigurer
la synchronisation de hachage de mot de passe pour stocker à nouveau les
hachages de mot de passe. Les machines virtuelles ou les utilisateurs auparavant
joints à un domaine ne pourront pas s’authentifier immédiatement : Azure AD doit
générer et stocker les hachages de mot de passe dans le nouveau domaine
managé.
Pour plus d’informations, consultez Processus de synchronisation du hachage de

mot de passe pour Azure AD DS et Azure AD Connect.
Les étapes de génération et de stockage de ces hachages de mot de passe sont

différentes pour les comptes d’utilisateur cloud uniquement créés dans Azure AD et
pour les comptes d’utilisateur qui sont synchronisés à partir de votre annuaire local avec
Azure AD Connect.
Un compte d’utilisateur uniquement dans le cloud est un compte qui a été créé dans
votre répertoire Azure AD à l’aide du portail Azure ou d’applets de commande
PowerShell Azure AD. Ces comptes d’utilisateurs ne sont pas synchronisés à partir d’un
annuaire local.
Dans ce tutoriel, nous utilisons un compte d’utilisateur de base cloud uniquement. Pour
plus d’informations sur les étapes supplémentaires nécessaires pour utiliser Azure AD
Connect, consultez Synchroniser les hachages de mot de passe pour les comptes
d’utilisateur synchronisés à partir de votre annuaire Active Directory local vers votre
domaine managé.
 Conseil
Si votre locataire Azure AD utilise une combinaison d’utilisateurs cloud uniquement

et d’utilisateurs provenant de votre annuaire Active Directory local, vous devez
effectuer ces deux ensembles d’étapes.
mot de passe avant de pouvoir utiliser Azure AD DS. Ce processus de changement du
mot de passe entraîne la génération et le stockage dans Azure AD des hachages de mot
de passe pour l’authentification Kerberos et NTLM. Le compte n’est pas synchronisé
entre Azure AD et Azure AD DS tant que le mot de passe n’a pas été changé. Vous
pouvez faire expirer les mots de passe de tous les utilisateurs cloud du locataire qui
doivent utiliser Azure AD DS, ce qui force le changement de mot de passe à la
connexion suivante, ou demander aux utilisateurs cloud de changer manuellement leur
mot de passe. Pour ce tutoriel, nous changeons manuellement le mot de passe d’un
utilisateur.
Pour qu’un utilisateur puisse réinitialiser son mot de passe, le locataire Azure AD doit
être configuré pour la réinitialisation du mot de passe en libre-service.
Pour changer le mot de passe d’un utilisateur cloud uniquement, l’utilisateur doit
effectuer les étapes suivantes :
1. Accédez à la page Panneau d’accès Azure AD à l’adresse

https://myapps.microsoft.com .
2. En haut à droite, sélectionnez votre nom, puis choisissez Profil dans le menu
déroulant.
3. Dans la page Profil, sélectionnez Changer le mot de passe.
4. Dans la page Changer le mot de passe, entrez votre mot de passe existant
(l’ancien), puis entrez un nouveau mot de passe et confirmez-le.
5. Sélectionnez Envoyer.
Une fois que vous avez changé votre mot de passe, quelques minutes sont nécessaires
pour que le nouveau mot de passe soit utilisable dans Azure AD DS et que vous puissiez
vous connecter aux ordinateurs joints au domaine managé.
Étapes suivantes
＂ Configurer les paramètres de réseau virtuel et DNS pour un domaine managé

＂ Activer les comptes d’utilisateur pour Azure AD DS et générer les hachages de mot
de passe
Pour voir ce domaine managé en action, créez et joignez une machine virtuelle au
domaine.
Joindre une machine virtuelle Windows Server à votre domaine managé

Tutoriel : Créer une approbation de forêt
sortante pour un domaine local dans
Article • 12/04/2023
Vous pouvez créer une approbation unidirectionnelle sortante entre Azure AD DS et un
ou plusieurs environnements AD DS locaux. Cette relation d’approbation permet aux
utilisateurs, applications et ordinateurs de s’authentifier auprès d’un domaine local à
partir du domaine managé Azure AD DS. Une approbation de forêt peut permettre aux
utilisateurs d’accéder aux ressources dans différents scénarios, par exemple :
Environnements ne permettant pas la synchronisation des hachages de mot de

passe ou dans lesquels des utilisateurs se connectent exclusivement à l’aide de
cartes à puce et ne connaissent pas leur mot de passe
Scénarios hybrides qui nécessitent toujours l’accès à des domaines locaux
Les approbations peuvent être créées dans n’importe quel domaine. Le domaine
bloquera automatiquement la synchronisation à partir d’un domaine local pour tous les
comptes d’utilisateur qui ont été synchronisés avec Azure AD DS. Cela empêche les
collisions d’UPN lorsque les utilisateurs s’authentifient.
＂ Configurer DNS dans un environnement AD DS local pour prendre en charge la

connectivité Azure AD DS
＂ Créer une approbation de forêt unidirectionnelle entrante dans un environnement
AD DS local
＂ Créer une approbation de forêt unidirectionnelle sortante dans Azure AD DS
＂ Tester et valider la relation d’approbation à des fins d'authentification et d’accès aux
ressources
Prérequis

Un domaine managé Azure Active Directory Domain Services

Domain Services.
） Important
Vous devez utiliser une référence (SKU) minimale d’Enterprise pour votre
domaine managé. Si nécessaire, changez de référence SKU pour un domaine
managé.

Dans ce tutoriel, vous créez et vous configurez une approbation de forêt sortante à
partir d'Azure AD DS avec le portail Azure. Pour commencer, connectez-vous au portail
Azure . Vous avez besoin des rôles Azure AD Administrateur d’applications et
Administrateur de groupes dans votre locataire pour modifier une instance Azure AD
DS.
Mise en réseau - Éléments à prendre en compte

Le réseau virtuel qui héberge la forêt Azure AD DS nécessite une connexion réseau à
votre instance Active Directory locale. Les applications et les services nécessitent
également une connexion au réseau virtuel hébergeant la forêt Azure AD DS. La
connexion réseau à la forêt Azure AD DS doit être toujours active et stable, à défaut de
quoi les utilisateurs risquent de ne pas pouvoir s’authentifier ou accéder aux ressources.
Avant de configurer une approbation de forêt dans Azure AD DS, assurez-vous que
votre mise en réseau entre Azure et l’environnement local répond aux conditions
requises suivantes :
Utilisez des adresses IP privées. Ne vous fiez pas à DHCP avec attribution
d’adresses IP dynamiques.
Évitez les espaces d’adressage IP qui se chevauchent pour permettre au routage et
à l’appairage de réseaux virtuels de bien communiquer entre Azure et les réseaux
locaux.
Un réseau virtuel Azure a besoin d’un sous-réseau de passerelle pour configurer
une connexion Azure VPN de site à site (S2S) ou ExpressRoute.
Créez des sous-réseaux avec suffisamment d’adresses IP pour prendre en charge
votre scénario.
Assurez-vous qu'Azure AD DS possède son propre sous-réseau. Ne partagez pas
ce sous-réseau de réseau virtuel avec les machines virtuelles et services
d’application.
Les réseaux virtuels appairés ne sont PAS transitifs.
Des appairages de réseaux virtuels Azure doivent être créées entre tous les
réseaux virtuels pour lesquels vous souhaitez utiliser l’approbation de forêt
Azure AD DS vers l’environnement AD DS local.
Fournissez une connectivité réseau continue à votre forêt Active Directory locale.
N’utilisez pas de connexions à la demande.
Vérifiez la présence d’une résolution de noms (DNS) continue entre votre nom de
forêt Azure AD DS et votre nom de forêt Active Directory locale.
Configurer DNS dans le domaine local

Pour résoudre correctement le domaine managé à partir de l’environnement local, vous
serez peut-être amené à ajouter des redirecteurs aux serveurs DNS existants. Si vous
n’avez pas configuré l’environnement local de manière à ce qu’il communique avec le
domaine managé, effectuez les étapes suivantes à partir d’une station de travail de
gestion pour le domaine AD DS local :
1. Sélectionnez DémarrerOutils d’administrationDNS.
2. Sélectionnez votre zone DNS, par exemple aaddscontoso.com.
3. Sélectionnez Redirecteurs conditionnels, puis cliquez avec le bouton droit et

sélectionnez Nouveau redirecteur conditionnel...
4. Entrez votre autre Domaine DNS, par exemple contoso.com, puis entrez les
adresses IP des serveurs DNS pour cet espace de noms, comme illustré dans
l’exemple suivant :
5. Cochez la case pour Stocker ce redirecteur conditionnel dans Active Directory, et

le répliquer comme suit, puis sélectionnez l’option Tous les serveurs DNS de ce
domaine, comme illustré dans l’exemple suivant :
） Important
Si le redirecteur conditionnel est stocké dans la forêt et non dans le domaine,

il échoue.
6. Pour créer le redirecteur conditionnel, sélectionnez OK.
Créer une approbation de forêt entrante dans

le domaine local
Le domaine AD DS local nécessite une approbation de forêt entrante pour le domaine
managé. Cette approbation doit être créée manuellement dans le domaine AD DS local ;
sa création n'est pas possible à partir du portail Azure.
Pour configurer l’approbation entrante sur le domaine AD DS local, procédez comme

suit à partir d’une station de travail de gestion pour le domaine AD DS local :
1. Sélectionnez DémarrerOutils d’administrationDomaines et approbations Active

Directory.
2. Cliquez avec le bouton droit sur le domaine, par exemple onprem.contoso.com, puis
sélectionnez Propriétés.
3. Choisissez l’onglet Approbations, puis Nouvelle approbation.
4. Entrez le nom du domaine Azure AD DS, comme aaddscontoso.com, puis
5. Sélectionnez l’option permettant de créer une approbation de forêt, puis une
approbation unidirectionnelle : entrante.
6. Choisissez de créer l’approbation pour ce domaine uniquement. À l’étape
suivante, vous allez créer l’approbation dans le portail Azure pour le domaine
managé.
7. Choisissez d’utiliser l'authentification à l'échelle de la forêt, puis entrez et
confirmez un mot de passe d’approbation. Ce même mot de passe est également
entré dans le portail Azure à la section suivante.
8. Parcourez les fenêtres suivantes avec les options par défaut, puis sélectionnez
l’option pour Non, ne pas confirmer l'approbation sortante.
9. Sélectionnez Terminer.
Si l’approbation de forêt n’est plus nécessaire pour un environnement, procédez comme

suit pour la supprimer du domaine local :
1. Sélectionnez DémarrerOutils d’administrationDomaines et approbations Active

Directory.
2. Cliquez avec le bouton droit sur le domaine, par exemple onprem.contoso.com, puis
3. Choisissez l’onglet Approbations, puis Domaines qui approuvent ce domaine
(approbations entrantes) , cliquez sur l’approbation à supprimer, puis cliquez sur
Supprimer.
4. Sous l’onglet Approbations, sous Domaines approuvés par ce domaine
(approbations sortantes) , cliquez sur l’approbation à supprimer, puis cliquez sur
Supprimer.
5. Cliquez sur Non, supprimer l’approbation du domaine local uniquement.
Créer une approbation de forêt sortante dans

Azure AD DS
Une fois le domaine AD DS local configuré pour résoudre le domaine managé et une
approbation de forêt entrante créée, créez l’approbation de forêt sortante. Cette
approbation de forêt sortante établit la relation d’approbation entre le domaine AD DS
local et le domaine managé.
Pour créer l’approbation sortante destinée au domaine managé dans le portail Azure,
effectuez les étapes suivantes :
1. Dans le portail Azure, recherchez et sélectionnez Azure AD Domain Services, puis

sélectionnez votre domaine managé, par exemple aaddscontoso.com.
2. Dans le menu de gauche du domaine managé, sélectionnez Approbations, puis +

Ajouter une approbation.
3. Entrez un nom d’affichage qui identifie votre approbation, puis le nom DNS de la
forêt locale approuvée, par exemple onprem.contoso.com.
4. Indiquez le même mot de passe d’approbation que celui utilisé à la section

précédente pour configurer l’approbation de forêt entrante pour le domaine
AD DS local.
5. Fournissez au moins deux serveurs DNS pour le domaine AD DS local, par exemple
10.1.1.4 et 10.1.1.5.
6. Lorsque vous êtes prêt, enregistrez l’approbation de forêt sortante.

Si l’approbation de forêt n’est plus nécessaire pour un environnement, procédez comme
suit pour la supprimer d’Azure AD DS :
1. Dans le portail Azure, recherchez et sélectionnez Azure AD Domain Services, puis

sélectionnez votre domaine managé, par exemple aaddscontoso.com.
2. Dans le menu de gauche du domaine managé, sélectionnez Approbations,
choisissez l’approbation, puis cliquez sur Supprimer.
3. Spécifiez le mot de passe d’approbation qui a été utilisé pour configurer
l’approbation de forêt, puis cliquez sur OK.
Valider l’authentification des ressources

Les scénarios courants suivants vous permettent de vérifier que l’approbation de forêt
authentifie correctement les utilisateurs et l’accès aux ressources :
Authentification des utilisateurs locaux à partir de la forêt Azure AD DS

Accéder aux ressources de la forêt Azure AD DS à l’aide de l’utilisateur local
Activer le partage de fichiers et d'imprimantes
Créer un groupe de sécurité et ajouter des membres
Créer un partage de fichiers pour l’accès inter-forêts
Valider l'authentification inter-forêts vers une ressource
Authentification des utilisateurs locaux à partir de la forêt

Azure AD DS
Vous devez disposer d’une machine virtuelle Windows Server jointe au domaine
managé. Utilisez cette machine virtuelle pour vérifier que votre utilisateur local peut
s’authentifier sur une machine virtuelle. Si nécessaire, créez une machine virtuelle
Windows et joignez-la au domaine managé.
1. Connectez-vous à la machine virtuelle Windows Server jointe à la forêt Azure

AD DS en utilisant Azure Bastion et vos informations d’identification
d’administrateur Azure AD DS.
2. Ouvrez une invite de commandes et utilisez la commande whoami pour afficher le

nom unique de l’utilisateur actuellement authentifié :
Console
whoami /fqdn
3. Utilisez la commande runas pour vous authentifier en tant qu’utilisateur à partir

du domaine local. Dans la commande suivante, remplacez
userUpn@trusteddomain.com par l’UPN d’un utilisateur du domaine local approuvé.
La commande vous invite à entrer le mot de passe de l’utilisateur :
Console
Runas /u:userUpn@trusteddomain.com cmd.exe
4. Si l’authentification aboutit, une nouvelle invite de commandes s’ouvre. Le titre de

la nouvelle invite de commandes comprend running as
userUpn@trusteddomain.com .
5. Utilisez whoami /fqdn dans la nouvelle invite de commandes pour afficher le nom
unique de l’utilisateur authentifié à partir de l'instance Active Directory locale.
Accéder aux ressources de la forêt Azure AD DS à l’aide

de l’utilisateur local
À l’aide de la machine virtuelle Windows Server jointe à la forêt Azure AD DS, vous
pouvez tester le scénario permettant aux utilisateurs d’accéder aux ressources
hébergées dans la forêt quand ils s’authentifient à partir d’ordinateurs du domaine local
auprès d’utilisateurs du domaine local. Les exemples suivants vous montrent comment
créer et tester différents scénarios courants.
Activer le partage de fichiers et d’imprimantes

1. Connectez-vous à la machine virtuelle Windows Server jointe à la forêt Azure
AD DS en utilisant Azure Bastion et vos informations d’identification
d’administrateur Azure AD DS.
2. Ouvrez Paramètres Windows, puis recherchez et sélectionnez Centre Réseau et

partage.
3. Sélectionnez l’option permettant de modifier les paramètres de partage avancés.
4. Sous Profil du domaine, sélectionnez Activer le partage de fichiers et

d'imprimantes, puis Enregistrer les modifications.
5. Fermez Centre Réseau et partage.
1. Ouvrez Utilisateurs et ordinateurs Active Directory.
2. Cliquez avec le bouton droit sur le nom de domaine, sélectionnez Nouveau, puis
Unité d'organisation.
3. Dans la zone de nom, entrez LocalObjects, puis sélectionnez OK.
4. Sélectionnez et cliquez avec le bouton droit sur LocalObjects dans le volet de

navigation. Sélectionnez Nouveau, puis Groupe.
5. Entrez FileServerAccess dans la zone Nom du groupe. Pour Étendue du groupe,

sélectionnez Domaine local, puis OK.
6. Dans le volet de contenu, double-cliquez sur FileServerAccess. Sélectionnez

Membres, Ajouter, puis Emplacements.
7. Sélectionnez votre instance Active Directory locale dans l'affichage Emplacement,

puis OK.
8. Entrez Utilisateurs du domaine dans la zone Entrer les noms des objets à
sélectionner. Sélectionnez Vérifier les noms, fournissez les informations
d’identification de l'instance Active Directory locale, puis sélectionnez OK.
７ Notes
La relation d'approbation étant unidirectionnelle, vous devez fournir les

informations d’identification. Cela signifie que les utilisateurs du domaine
managé Azure AD DS ne pourront pas accéder aux ressources ni rechercher
des utilisateurs ou groupes dans le domaine (local) approuvé.
9. Le groupe Utilisateurs du domaine de votre instance Active Directory locale doit
être membre du groupe FileServerAccess. Sélectionnez OK pour enregistrer le
groupe et fermer la fenêtre.
1. Sur la machine virtuelle Windows Server jointe à la forêt Azure AD DS, créez un

dossier et attribuez-lui un nom, par exemple CrossForestShare.
2. Cliquez avec le bouton droit sur le dossier, puis sélectionnez Propriétés.
3. Sélectionnez l'onglet Sécurité, puis Modifier.
4. Dans la boîte de dialogue Autorisations pour CrossForestShare, sélectionnez
Ajouter.
5. Entrez FileServerAccess dans Entrer les noms des objets à sélectionner, puis
sélectionnez OK.
6. Sélectionnez FileServerAccess dans la liste Noms des groupes ou des utilisateurs.
Dans la liste Autorisations pour FileServerAccess, sélectionnez Autoriser pour les
autorisations Modifier et Écrire, puis OK.
7. Sélectionnez l’onglet Partage, puis Partage avancé.
8. Sélectionnez Partager ce dossier, puis entrez un nom de partage de fichiers facile
à retenir dans Nom du partage, par exemple CrossForestShare.
9. Sélectionnez Autorisations. Dans la liste Autorisations pour tous, sélectionnez
Autoriser pour l'autorisation Modifier.
10. Sélectionnez OK deux fois, puis Fermer.
Valider l’authentification inter-forêts sur une ressource

1. Connectez-vous à un ordinateur Windows joint à votre instance Active Directory
locale à l’aide d’un compte d’utilisateur de votre instance Active Directory locale.
2. À l’aide de l'Explorateur Windows, connectez-vous au partage que vous avez créé

à l’aide du nom d’hôte complet et le partage, par exemple .
3. Pour valider l’autorisation d’écriture, cliquez avec le bouton droit dans le dossier,
sélectionnez Nouveau, puis Document texte. Utilisez le nom par défaut Nouveau
document texte.
Si les autorisations d’écriture sont correctement définies, un nouveau document

texte est créé. Les étapes suivantes permettent d'ouvrir, de modifier et de
supprimer le fichier, selon vos besoins.
4. Pour valider l’autorisation de lecture, ouvrez Nouveau document texte.

5. Pour valider l’autorisation de modification, ajoutez du texte au fichier et fermez le
Bloc-notes. Lorsque vous êtes invité à enregistrer les modifications, sélectionnez
Enregistrer.
6. Pour valider l’autorisation de suppression, cliquez avec le bouton droit sur

Nouveau document texte, puis sélectionnez Supprimer. Sélectionnez Oui pour
confirmer la suppression du fichier.
Étapes suivantes

connectivité Azure AD DS
AD DS local
＂ Créer une approbation de forêt unidirectionnelle sortante dans Azure AD DS
ressources
Pour plus d’informations conceptuelles sur les forêts dans Azure AD DS, consultez
Fonctionnement des relations d’approbation pour les forêts dans Active Directory.
Activer Azure Active Directory Domain
Services à l’aide de PowerShell
Article • 11/05/2023
ressources.
Cet article vous montre comment activer Azure à l’aide de PowerShell.
７ Notes
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir

avec Azure. Pour commencer, consultez Installer Azure PowerShell. Pour savoir
comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell
depuis AzureRM vers Az.
Prérequis
Pour effectuer ce qui est décrit dans cet article, vous avez besoin des ressources
suivantes :
Installez et configurez Azure PowerShell.

Si nécessaire, suivez les instructions pour installer le module Azure PowerShell
et vous connecter à votre abonnement Azure.
Veillez à vous connecter à votre abonnement Azure à l’aide de l’applet de
commande Connect-AzAccount.
Installez et configurez Azure AD PowerShell.

Si nécessaire, suivez les instructions pour installer le module Azure AD
PowerShell et vous connecter à Azure AD.
Veillez à vous connecter à votre locataire Azure AD à l’aide de l’applet de
commande Connect-AzureAD.
Vous devez disposer des privilèges d’Administrateur global dans votre locataire
Azure AD pour activer Azure AD DS.
Vous avez besoin de privilèges de Contributeur dans votre abonnement Azure pour
créer les ressources Azure AD DS nécessaires.
） Important
Tant que le module PowerShell Az.ADDomainServices est en préversion, vous

devez l’installer séparément à l’aide de l’applet de commande Install-
Module .
Azure PowerShell
Install-Module -Name Az.ADDomainServices
Créer les ressources Azure AD nécessaires

Azure AD DS nécessite un principal de service pour s’authentifier et communiquer, et un
groupe Azure AD pour définir les utilisateurs qui disposent d’autorisations
d’administration dans le domaine managé.
Commencez par créer un principal de service Azure AD à l’aide d’un ID d’application

spécifique nommé Domain Controller Services. La valeur d’ID est 2565bd9d-da50-47d4-
8b85-4c97f669dc36 pour Azure Global et 6ba9a5d4-8456-4118-b521-9c5ca10cdf84 pour
les autres clouds Azure. Ne modifiez pas cet ID d’application.
Créez un principal du service Azure AD à l’aide de l’applet de commande New-

AzureADServicePrincipal :
PowerShell
New-AzureADServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-4c97f669dc36"
Créez ensuite un groupe Azure AD nommé AAD DC Administrators. Les utilisateurs

ajoutés à ce groupe se voient ensuite accorder des autorisations pour effectuer des
tâches d’administration dans le domaine managé.
Obtenez d’abord l’ID d’objet du groupe Administrateurs AAD DC en utilisant l’applet de

commande Get-AzureADGroup. Si le groupe n’existe pas, créez-le avec le groupe
Administrateurs AAD DC en utilisant l’applet de commande New-AzureADGroup :
PowerShell
# First, retrieve the object ID of the 'AAD DC Administrators' group.
$GroupObjectId = Get-AzureADGroup `
-Filter "DisplayName eq 'AAD DC Administrators'" | `
Select-Object ObjectId
# If the group doesn't exist, create it
if (!$GroupObjectId) {
$GroupObjectId = New-AzureADGroup -DisplayName "AAD DC Administrators" `
-Description "Delegated group to administer Azure AD Domain Services" `
-SecurityEnabled $true `
-MailEnabled $false `
-MailNickName "AADDCAdministrators"
else {
Write-Output "Admin group already exists."
Une fois le groupe Administrateurs AAD DC créé, obtenez l’ID d’objet de l’utilisateur
souhaité en utilisant l’applet de commande Get-AzureADUser, puis ajoutez l’utilisateur
au groupe en utilisant l’applet de commande Add-AzureADGroupMember.
Dans l’exemple suivant, l’ID d’objet utilisateur du compte a le nom d’utilisateur principal
(UPN) admin@contoso.onmicrosoft.com . Remplacez ce compte d’utilisateur par l’UPN de
l’utilisateur que vous souhaitez ajouter au groupe AAD DC Administrators :
PowerShell
# Retrieve the object ID of the user you'd like to add to the group.
$UserObjectId = Get-AzureADUser `
-Filter "UserPrincipalName eq 'admin@contoso.onmicrosoft.com'" | `
# Add the user to the 'AAD DC Administrators' group.
Add-AzureADGroupMember -ObjectId $GroupObjectId.ObjectId -RefObjectId

$UserObjectId.ObjectId
Créer des ressources réseau

Dans un premier temps, inscrivez le fournisseur de ressources Azure AD Domain
Services à l’aide de l’applet de commande Register-AzResourceProvider :
Azure PowerShell
Register-AzResourceProvider -ProviderNamespace Microsoft.AAD
Créez ensuite un groupe de ressources avec l’applet de commande New-

AzResourceGroup. Dans l’exemple suivant, le groupe de ressources est nommé
myResourceGroup et est créé dans la région westus. Utilisez votre propre nom et la
région souhaitée :
Azure PowerShell
$ResourceGroupName = "myResourceGroup"
$AzureLocation = "westus"
# Create the resource group.
New-AzResourceGroup `
-Name $ResourceGroupName `
-Location $AzureLocation
Créez le réseau virtuel et des sous-réseaux pour Azure AD Domain Services. Deux sous-
réseaux sont créés : un pour DomainServices et un autre pour Workloads. Azure AD DS
est déployé dans le sous-réseau dédié DomainServices. Ne déployez pas d’autres
applications ou charges de travail dans ce sous-réseau. Utilisez le sous-réseau
indépendant Workloads ou d’autres sous-réseaux pour le reste de vos machines
virtuelles.
Créez les sous-réseaux à l’aide de l’applet de commande New-

AzVirtualNetworkSubnetConfig, puis créez le réseau virtuel à l’aide de l’applet de
commande New-AzVirtualNetwork.
Azure PowerShell
$VnetName = "myVnet"
# Create the dedicated subnet for Azure AD Domain Services.
$SubnetName = "DomainServices"
$AaddsSubnet = New-AzVirtualNetworkSubnetConfig `
-Name $SubnetName `
-AddressPrefix 10.0.0.0/24
# Create an additional subnet for your own VM workloads
$WorkloadSubnet = New-AzVirtualNetworkSubnetConfig `
-Name Workloads `
# Create the virtual network in which you will enable Azure AD Domain
Services.
$Vnet= New-AzVirtualNetwork `
-ResourceGroupName $ResourceGroupName `
-Location westus `
-Name $VnetName `
-AddressPrefix 10.0.0.0/16 `
-Subnet $AaddsSubnet,$WorkloadSubnet
Créer un groupe de sécurité réseau

Azure AD DS a besoin d’un groupe de sécurité réseau pour sécuriser les ports
nécessaires au domaine managé et bloquer tout autre trafic entrant. Un groupe de
sécurité réseau (NSG) contient la liste des règles qui autorisent ou rejettent le trafic
réseau vers le trafic d’un réseau virtuel Azure. Dans Azure AD DS, le groupe de sécurité
réseau agit comme une couche de protection supplémentaire pour verrouiller l’accès au
domaine managé. Pour afficher les ports obligatoires, consultez Groupes de sécurité
réseau et ports nécessaires.
Les cmdlets PowerShell suivantes utilisent New-AzNetworkSecurityRuleConfig pour

créer les règles, puis New-AzNetworkSecurityGroup pour créer le groupe de sécurité
réseau. Le groupe de sécurité réseau et les règles sont ensuite associés au sous-réseau
de réseau virtuel à l’aide de la cmdlet Set-AzVirtualNetworkSubnetConfig.
Azure PowerShell
$NSGName = "aaddsNSG"
# Create a rule to allow inbound TCP port 3389 traffic from Microsoft secure
access workstations for troubleshooting
$nsg201 = New-AzNetworkSecurityRuleConfig -Name AllowRD `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 201 `
-SourceAddressPrefix CorpNetSaw `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 3389
# Create a rule to allow TCP port 5986 traffic for PowerShell remote
management
$nsg301 = New-AzNetworkSecurityRuleConfig -Name AllowPSRemoting `
-Access Allow `
-Protocol Tcp `
-Priority 301 `
-SourceAddressPrefix AzureActiveDirectoryDomainServices `
# Create the network security group and rules
$nsg = New-AzNetworkSecurityGroup -Name $NSGName `
-Location $AzureLocation `
-SecurityRules $nsg201,$nsg301
# Get the existing virtual network resource objects and information
$vnet = Get-AzVirtualNetwork -Name $VnetName -ResourceGroupName

$ResourceGroupName
$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name

$SubnetName
$addressPrefix = $subnet.AddressPrefix
# Associate the network security group with the virtual network subnet
Set-AzVirtualNetworkSubnetConfig -Name $SubnetName `
-VirtualNetwork $vnet `
-AddressPrefix $addressPrefix `
-NetworkSecurityGroup $nsg
$vnet | Set-AzVirtualNetwork

Créons maintenant un domaine managé. Définissez votre ID d’abonnement Azure, puis
attribuez un nom au domaine managé, par exemple aaddscontoso.com. Vous pouvez
obtenir votre ID d’abonnement à l’aide de l’applet de commande Get-AzSubscription.
Si vous choisissez une région qui prend en charge les Zones de disponibilité, les
ressources Azure AD DS sont réparties entre les zones pour assurer une redondance.
Les Zones de disponibilité sont des emplacements physiques uniques au sein d’une
région Azure. Chaque zone de disponibilité est composée d’un ou de plusieurs centres
de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau
indépendants. Pour garantir la résilience, un minimum de trois zones distinctes sont
activées dans toutes les régions.
Vous ne devez rien configurer pour la répartition d’Azure AD DS entre les zones. La
plateforme Azure gère automatiquement la répartition de zone des ressources. Pour
plus d’informations et pour connaître la disponibilité régionale, voir Zones de
disponibilité dans Azure.
Azure PowerShell
$AzureSubscriptionId = "YOUR_AZURE_SUBSCRIPTION_ID"
$ManagedDomainName = "aaddscontoso.com"
# Enable Azure AD Domain Services for the directory.
$replicaSetParams = @{
Location = $AzureLocation
SubnetId =
"/subscriptions/$AzureSubscriptionId/resourceGroups/$ResourceGroupName/provi
ders/Microsoft.Network/virtualNetworks/$VnetName/subnets/DomainServices"
$replicaSet = New-AzADDomainServiceReplicaSetObject @replicaSetParams
$domainServiceParams = @{
Name = $ManagedDomainName
ResourceGroupName = $ResourceGroupName
DomainName = $ManagedDomainName
ReplicaSet = $replicaSet
New-AzADDomainService @domainServiceParams
Créer la ressource et retourner le contrôle à l’invite PowerShell prend quelques minutes.

Le provisionnement du domaine managé se poursuit en arrière-plan et le déploiement
peut prendre jusqu’à une heure. Dans le portail Azure, la page Vue d’ensemble de votre
domaine managé indique l’état actuel tout au long de cette phase de déploiement.
Une fois que le portail Azure a indiqué que le provisionnement du domaine managé
était terminé, voici les tâches qu’il convient d’effectuer :
Mettez à jour les paramètres DNS pour le réseau virtuel afin que les machines
virtuelles puissent trouver le domaine géré pour l’authentification ou la jonction de
domaine.
Pour configure le système DNS, sélectionnez votre domaine managé dans le
portail. Dans la fenêtre Vue d’ensemble, vous êtes invité à configurer
automatiquement ces paramètres DNS.
Activez la synchronisation de mot de passe avec Azure AD DS afin que les
utilisateurs finaux puissent se connecter au domaine managé avec leurs
informations d’identification d’entreprise.
Compléter le script PowerShell

Le script PowerShell complet suivant regroupe toutes les tâches présentées dans cet
article. Copiez le script et enregistrez-le dans un fichier avec une extension .ps1 . Pour
Azure Global, utilisez la valeur AppId 2565bd9d-da50-47d4-8b85-4c97f669dc36. Pour les
autres clouds Azure, utilisez la valeur AppId 6ba9a5d4-8456-4118-b521-9c5ca10cdf84.
Exécutez le script dans une console PowerShell locale ou Azure Cloud Shell.
７ Notes
Pour activer Azure AD DS, vous devez être administrateur général du locataire
Azure AD. Vous avez aussi besoin au moins de privilèges Contributeur dans
l’abonnement Azure.
Azure PowerShell
# Change the following values to match your deployment.
$AaddsAdminUserUpn = "admin@contoso.onmicrosoft.com"
$ResourceGroupName = "myResourceGroup"
$VnetName = "myVnet"
$AzureLocation = "westus"
$AzureSubscriptionId = "YOUR_AZURE_SUBSCRIPTION_ID"
$ManagedDomainName = "aaddscontoso.com"
# Connect to your Azure AD directory.
Connect-AzureAD
# Login to your Azure subscription.
Connect-AzAccount
# Create the service principal for Azure AD Domain Services.
# First, retrieve the object ID of the 'AAD DC Administrators' group.
# Create the delegated administration group for Azure AD Domain Services if

it doesn't already exist.
if (!$GroupObjectId) {
$GroupObjectId = New-AzureADGroup -DisplayName "AAD DC Administrators" `
-SecurityEnabled $true `
-MailEnabled $false `
else {
Write-Output "Admin group already exists."
# Now, retrieve the object ID of the user you'd like to add to the group.
-Filter "UserPrincipalName eq '$AaddsAdminUserUpn'" | `

# Register the resource provider for Azure AD Domain Services with Resource
Manager.
# Create the resource group.
-Name $ResourceGroupName `
-Location $AzureLocation
# Create the dedicated subnet for AAD Domain Services.
$SubnetName = "DomainServices"
$AaddsSubnet = New-AzVirtualNetworkSubnetConfig `
-Name DomainServices `
$WorkloadSubnet = New-AzVirtualNetworkSubnetConfig `
-Name Workloads `
# Create the virtual network in which you will enable Azure AD Domain
Services.
$Vnet=New-AzVirtualNetwork `
-Name $VnetName `
-AddressPrefix 10.0.0.0/16 `
-Subnet $AaddsSubnet,$WorkloadSubnet
$NSGName = "aaddsNSG"
# Create a rule to allow inbound TCP port 3389 traffic from Microsoft secure
access workstations for troubleshooting
$nsg201 = New-AzNetworkSecurityRuleConfig -Name AllowRD `
-Access Allow `
-Protocol Tcp `
-Priority 201 `
-SourceAddressPrefix CorpNetSaw `
# Create a rule to allow TCP port 5986 traffic for PowerShell remote
management
$nsg301 = New-AzNetworkSecurityRuleConfig -Name AllowPSRemoting `
-Access Allow `
-Protocol Tcp `
-Priority 301 `
-SourceAddressPrefix AzureActiveDirectoryDomainServices `
# Create the network security group and rules
$nsg = New-AzNetworkSecurityGroup -Name $NSGName `
-SecurityRules $nsg201,$nsg301
# Get the existing virtual network resource objects and information
$vnet = Get-AzVirtualNetwork -Name $VnetName -ResourceGroupName

$ResourceGroupName
$subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name

$SubnetName
$addressPrefix = $subnet.AddressPrefix
# Associate the network security group with the virtual network subnet
Set-AzVirtualNetworkSubnetConfig -Name $SubnetName `
-VirtualNetwork $vnet `
-AddressPrefix $addressPrefix `
-NetworkSecurityGroup $nsg
$vnet | Set-AzVirtualNetwork
# Enable Azure AD Domain Services for the directory.
$replicaSetParams = @{
Location = $AzureLocation
SubnetId =
"/subscriptions/$AzureSubscriptionId/resourceGroups/$ResourceGroupName/provi
ders/Microsoft.Network/virtualNetworks/$VnetName/subnets/DomainServices"
$replicaSet = New-AzADDomainServiceReplicaSet @replicaSetParams
$domainServiceParams = @{
Name = $ManagedDomainName
ResourceGroupName = $ResourceGroupName
DomainName = $ManagedDomainName
ReplicaSet = $replicaSet
New-AzADDomainService @domainServiceParams

domaine.
Étapes suivantes
Pour voir le domaine managé en action, vous pouvez joindre une machine virtuelle
Windows à un domaine, configurer le protocole LDAP sécurisé et configurer la
synchronisation du hachage de mot de passe.
Créer un domaine managé Azure Active
Directory Domain Services à l’aide d’un
modèle Resource Manager
Article • 01/06/2023
ressources.
Cet article vous montre comment créer un domaine managé à l’aide d’un modèle de
Azure Resource Manager. Les ressources de prise en charge sont créées à l’aide d’Azure
PowerShell.
Prérequis
suivantes :

Administrateur de groupes dans votre locataire pour activer Azure AD DS.
Exigences relatives aux noms DNS
Quand vous créez un domaine managé Azure AD DS, vous spécifiez un nom DNS. Voici
quelques considérations liées au choix de ce nom DNS :

certificat.
applications.
résolution DNS.
 Conseil

noms DNS existants. Il est recommandé d’utiliser un nom de domaine distinct de
tout espace de noms DNS local ou Azure existant.

supplémentaires.
Dans cet exemple et dans les articles de guide pratique, le domaine personnalisé
aaddscontoso.com est utilisé comme exemple rapide. Dans toutes les commandes,

Créer les ressources Azure AD nécessaires

Azure AD DS nécessite un principal du service et un groupe Azure AD. Ces ressources
permettent au domaine managé de synchroniser les données et de définir les
utilisateurs qui disposent d’autorisations administratives dans le domaine managé.
Dans un premier temps, inscrivez le fournisseur de ressources Azure AD Domain

Services à l’aide de l’applet de commande Register-AzResourceProvider :
PowerShell
Créez un principal de service Azure AD à l’aide de l’applet de commande New-

AzureADServicePrincipal pour permettre à Azure AD DS de communiquer et de
s’authentifier. Un ID d’application spécifique est utilisé. Il se nomme Domain Controller
Services et son ID est 2565bd9d-da50-47d4-8b85-4c97f669dc36 pour Azure Global. Pour
les autres clouds Azure, recherchez la valeur AppId 6ba9a5d4-8456-4118-b521-
9c5ca10cdf84.
PowerShell
Créez maintenant un groupe Azure AD nommé AAD DC Administrators à l’aide de

l’applet de commande New-AzureADGroup. Les utilisateurs ajoutés à ce groupe se
voient ensuite accorder des autorisations pour effectuer des tâches d’administration
dans le domaine managé.
PowerShell
New-AzureADGroup -DisplayName "AAD DC Administrators" `
-SecurityEnabled $true -MailEnabled $false `
Une fois le groupe AAD DC Administrators créé, ajoutez un utilisateur au groupe à l’aide
de l’applet de commande Add-AzureADGroupMember. Vous obtenez d’abord l’ID
d’objet du groupe AAD DC Administrators via l’applet de commande Get-
AzureADGroup et ensuite l’ID d’objet de l’utilisateur souhaité via l’applet de commande
Get-AzureADUser.
Dans l’exemple suivant, l’ID d’objet utilisateur du compte a le nom d’utilisateur principal
(UPN) admin@contoso.onmicrosoft.com . Remplacez ce compte d’utilisateur par l’UPN de
l’utilisateur que vous souhaitez ajouter au groupe AAD DC Administrators :
PowerShell
# First, retrieve the object ID of the newly created 'AAD DC Administrators'

group.
# Now, retrieve the object ID of the user you'd like to add to the group.
-Filter "UserPrincipalName eq 'admin@contoso.onmicrosoft.com'" | `

Pour finir, créez un groupe de ressources avec l’applet de commande New-

PowerShell
-Name "myResourceGroup" `
-Location "WestUS"
Si vous choisissez une région qui prend en charge les Zones de disponibilité, les
ressources Azure AD DS sont réparties entre les zones pour assurer une redondance
supplémentaire. Les Zones de disponibilité sont des emplacements physiques uniques
au sein d’une région Azure. Chaque zone de disponibilité est composée d’un ou de
refroidissement et d’un réseau indépendants. Pour garantir la résilience, un minimum de
trois zones distinctes sont activées dans toutes les régions.
Vous ne devez rien configurer pour la répartition d’Azure AD DS entre les zones. La
plateforme Azure gère automatiquement la répartition de zone des ressources. Pour
plus d’informations et pour connaître la disponibilité régionale, voir Zones de
disponibilité dans Azure.
Définition de ressource pour Azure AD DS

Dans le cadre de la définition de ressources Resource Manager, les paramètres de
configuration suivants sont requis :
Paramètre Valeur
domainName Le nom de domaine DNS de votre domaine managé, en prenant en

considération les points précédents sur les préfixes d’attribution de
noms et les conflits.
filteredSync Azure AD DS vous permet de synchroniser tous les utilisateurs et les

groupes disponibles dans Azure AD, ou d’effectuer une
synchronisation limitée seulement à des groupes spécifiques.
Pour en savoir plus sur la synchronisation limitée, consultez

Synchronisation limitée d’Azure AD Domain Services.
notificationSettings Si des alertes sont générées dans le domaine managé, des

notifications par e-mail peuvent être envoyées.
Les administrateurs généraux du locataire Azure et des membres du

groupe AAD DC Administrators peuvent être activés pour ces
notifications.
Si vous le souhaitez, vous pouvez ajouter des destinataires

supplémentaires auxquels doivent être envoyées les notifications des
alertes qui nécessitent une attention particulière.
Paramètre Valeur
domainConfigurationType Par défaut, un domaine managé est créé en tant que forêt
d’utilisateurs. Ce type de forêt synchronise tous les objets d’Azure
AD, notamment les comptes d’utilisateur créés dans un
environnement AD DS local. Vous n’avez pas besoin de spécifier une
valeur domainConfiguration pour créer une forêt d’utilisateurs.
Une forêt de ressources synchronise uniquement les utilisateurs et les

groupes créés directement dans Azure AD. Définissez la valeur sur
ResourceTrusting pour créer une forêt de ressources.
Pour plus d’informations sur les forêts de ressources, notamment sur

la raison pour laquelle vous pouvez en utiliser une et comment créer
des approbations de forêts avec des domaines AD DS locaux,
consultez Vue d’ensemble des forêts de ressources Azure AD DS.
La définition des paramètres condensés suivants montre comment ces valeurs sont
déclarées. Une forêt d’utilisateurs nommée aaddscontoso.com est créée avec tous les
utilisateurs d’Azure AD DS synchronisés avec le domaine managé :
JSON
"parameters": {
"domainName": {
"value": "aaddscontoso.com"
},
"filteredSync": {
"value": "Disabled"
},
"notificationSettings": {
"value": {
"notifyGlobalAdmins": "Enabled",
"notifyDcAdmins": "Enabled",
"additionalRecipients": []
},
[...]
Le type de ressource de modèle Resource Manager condensé suivant est ensuite utilisé
pour définir et créer le domaine managé. Un réseau virtuel et un sous-réseau Azure
doivent déjà exister ou être créés dans le cadre du modèle Resource Manager. Le
domaine managé est connecté à ce sous-réseau.
JSON
"resources": [
"apiVersion": "2017-06-01",
"type": "Microsoft.AAD/DomainServices",
"name": "[parameters('domainName')]",
"location": "[parameters('location')]",
"dependsOn": [
"[concat('Microsoft.Network/virtualNetworks/',
parameters('vnetName'))]"
],
"properties": {
"domainName": "[parameters('domainName')]",
"subnetId": "[concat('/subscriptions/',
subscription().subscriptionId, '/resourceGroups/', resourceGroup().name,
'/providers/Microsoft.Network/virtualNetworks/', parameters('vnetName'),
'/subnets/', parameters('subnetName'))]",
"filteredSync": "[parameters('filteredSync')]",
"notificationSettings": "[parameters('notificationSettings')]"
},
[...]
Ces paramètres et le type de ressource peuvent être utilisés dans le cadre d’un modèle
Resource Manager plus étendu pour déployer un domaine managé, comme indiqué
dans la section suivante.
Créer un domaine managé à l’aide d’un

exemple de modèle
L’exemple de modèle complet Resource Manager suivant crée un domaine managé et
les règles de réseau virtuel, de sous-réseau et de groupe de sécurité réseau associés. Les
règles de groupe de sécurité réseau sont requises pour sécuriser le domaine géré et
s’assurer que le trafic puisse circuler correctement. Une forêt d’utilisateurs avec le nom
DNS aaddscontoso.com est créée, avec tous les utilisateurs synchronisés à partir d’Azure
AD :
JSON
"$schema": "http://schema.management.azure.com/schemas/2015-01-
01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"apiVersion": {
"value": "2017-06-01"
},
"domainConfigurationType": {
"value": "FullySynced"
},
"domainName": {
"value": "aaddscontoso.com"
},
"filteredSync": {
"value": "Disabled"
},
"location": {
"value": "westus"
},
"notificationSettings": {
"value": {
"notifyGlobalAdmins": "Enabled",
"notifyDcAdmins": "Enabled",
"additionalRecipients": []
},
"subnetName": {
"value": "aadds-subnet"
},
"vnetName": {
"value": "aadds-vnet"
},
"vnetAddressPrefixes": {
"value": [
"10.1.0.0/24"
},
"subnetAddressPrefix": {
"value": "10.1.0.0/24"
},
"nsgName": {
"value": "aadds-nsg"
},
"resources": [
"apiVersion": "2017-06-01",
"type": "Microsoft.AAD/DomainServices",
"name": "[parameters('domainName')]",
"dependsOn": [
"[concat('Microsoft.Network/virtualNetworks/',
parameters('vnetName'))]"
],
"properties": {
"domainName": "[parameters('domainName')]",
"subnetId": "[concat('/subscriptions/',
'/providers/Microsoft.Network/virtualNetworks/', parameters('vnetName'),
'/subnets/', parameters('subnetName'))]",
"filteredSync": "[parameters('filteredSync')]",
"domainConfigurationType": "
[parameters('domainConfigurationType')]",
"notificationSettings": "
[parameters('notificationSettings')]"
},
"type": "Microsoft.Network/NetworkSecurityGroups",
"name": "[parameters('nsgName')]",
"properties": {
"securityRules": [
"name": "AllowSyncWithAzureAD",
"properties": {
"access": "Allow",
"priority": 101,
"direction": "Inbound",
"protocol": "Tcp",
"sourceAddressPrefix":
"AzureActiveDirectoryDomainServices",
"sourcePortRange": "*",
"destinationAddressPrefix": "*",
"destinationPortRange": "443"
},
"name": "AllowPSRemoting",
"properties": {
"access": "Allow",
"priority": 301,
"protocol": "Tcp",
"sourceAddressPrefix":
"AzureActiveDirectoryDomainServices",
},
"name": "AllowRD",
"properties": {
"access": "Allow",
"priority": 201,
"protocol": "Tcp",
"sourceAddressPrefix": "CorpNetSaw",
},
"apiVersion": "2018-04-01"
},
"type": "Microsoft.Network/virtualNetworks",
"name": "[parameters('vnetName')]",
"apiVersion": "2018-04-01",
"dependsOn": [
"[concat('Microsoft.Network/NetworkSecurityGroups/',
parameters('nsgName'))]"
],
"properties": {
"addressSpace": {
"addressPrefixes": "[parameters('vnetAddressPrefixes')]"
},
"subnets": [
"name": "[parameters('subnetName')]",
"properties": {
"addressPrefix": "
[parameters('subnetAddressPrefix')]",
"networkSecurityGroup": {
"id": "[concat('/subscriptions/',
'/providers/Microsoft.Network/NetworkSecurityGroups/',
parameters('nsgName'))]"
],
"outputs": {}
Ce modèle peut être déployé à l’aide de votre méthode de déploiement préférée,

comme le Portail Azure, Azure PowerShell ou un pipeline CI/CD. L’exemple suivant utilise
l’applet de commande New-AzResourceGroupDeployment. Spécifiez vos propres nom
de groupe de ressources et nom de fichier de modèle :
PowerShell
New-AzResourceGroupDeployment -ResourceGroupName "myResourceGroup" -

TemplateFile <path-to-template>

domaine.
Étapes suivantes
Pour voir le domaine managé en action, vous pouvez joindre une machine virtuelle
Windows à un domaine, configurer le protocole LDAP sécurisé et configurer la
synchronisation du hachage de mot de passe.
Configuration d’une synchronisation à
étendue limitée entre Azure AD et Azure
Active Directory Domain Services à
l’aide d’Azure AD PowerShell
Article • 01/06/2023
Pour assurer des services d’authentification, Azure Active Directory Domain Services
(Azure AD DS) synchronise les utilisateurs et les groupes à partir d’Azure AD. Dans un
environnement hybride, les utilisateurs et les groupes d’un environnement Active
Directory Domain Services (AD DS) local peuvent d’abord être synchronisés avec Azure
AD via Azure AD Connect, puis avec Azure AD DS.
Par défaut, tous les utilisateurs et groupes d’un annuaire Azure AD sont synchronisés
avec un domaine managé Azure AD DS. Si vous avez des besoins spécifiques, vous
pouvez opter pour la synchronisation d’un ensemble défini d’utilisateurs.
Cet article vous montre comment créer un domaine managé qui utilise une
synchronisation délimitée, puis modifier ou désactiver le groupe d’utilisateurs ciblés à
l’aide d’Azure AD PowerShell. Vous pouvez également effectuer ces étapes à l’aide du
portail Azure.
Avant de commencer
Pour faire ce qui est décrit dans cet article, vous avez besoin des ressources et des
privilèges suivants :
Si nécessaire, suivez le tutoriel pour créer et configurer un domaine managé
Azure Active Directory Domain Services.
Administrateur de groupes dans votre locataire pour modifier l’étendue de
synchronisation Azure AD DS.
Vue d’ensemble de la synchronisation délimitée

avec un domaine managé. Si seuls quelques utilisateurs ont besoin d’accéder au
domaine managé, vous pouvez synchroniser uniquement ces comptes d’utilisateurs.
Cette synchronisation délimitée est basée sur les groupes. Quand vous configurez la
synchronisation délimitée basée sur les groupes, seuls les comptes d’utilisateurs qui
appartiennent aux groupes que vous spécifiez sont synchronisés avec le domaine
managé. Les groupes imbriqués ne sont pas synchronisés ; seuls les groupes
explicitement sélectionnés le sont.
Vous pouvez modifier l’étendue de synchronisation avant ou après la création du

domaine managé. L’étendue de la synchronisation est définie par un principal de service
avec l’identificateur d’application 2565bd9d-da50-47d4-8b85-4c97f669dc36. Pour éviter
toute perte d’étendue, ne supprimez pas ou ne modifiez pas le principal du service. Si ce
dernier supprimé par accident, l’étendue de synchronisation ne peut pas être récupérée.
Gardez à l’esprit les avertissements suivants si vous modifiez l’étendue de

synchronisation :
Une synchronisation complète se produit.

Les objets qui ne sont plus requis dans le domaine managé sont supprimés. De
nouveaux objets sont créés dans le domaine managé.
Pour en savoir plus sur le processus de synchronisation, consultez Comprendre la

synchronisation dans Azure AD Domain Services.
Script PowerShell pour la synchronisation

délimitée
Pour configurer la synchronisation délimitée à l’aide de PowerShell, commencez par
enregistrer le script suivant dans un fichier nommé Select-GroupsToSync.ps1 .
Ce script configure Azure AD DS de façon à synchroniser les groupes sélectionnés à

partir d’Azure AD. Tous les comptes d’utilisateurs qui font partie des groupes spécifiés
sont synchronisés avec le domaine managé.
Ce script est utilisé dans les étapes supplémentaires de cet article.
PowerShell
param (
[Parameter(Position = 0)]
[String[]]$groupsToAdd
Connect-AzureAD
$sp = Get-AzureADServicePrincipal -Filter "AppId eq '2565bd9d-da50-47d4-

8b85-4c97f669dc36'"
$role = $sp.AppRoles | where-object -FilterScript {$_.DisplayName -eq

"User"}
Write-Output
"`n*************************************************************************
***"
Write-Output "Total group-assignments need to be added:

$($groupsToAdd.Count)"
$newGroupIds = New-Object 'System.Collections.Generic.HashSet[string]'
foreach ($groupName in $groupsToAdd)
try
$group = Get-AzureADGroup -Filter "DisplayName eq '$groupName'"
$newGroupIds.Add($group.ObjectId)
Write-Output "Group-Name: $groupName, Id: $($group.ObjectId)"
catch
Write-Error "Failed to find group: $groupName. Exception:

$($_.Exception)."
Write-Output
"***************************************************************************
*`n"
Write-Output
"`n*************************************************************************
***"
$currentAssignments = Get-AzureADServiceAppRoleAssignment -ObjectId

$sp.ObjectId
Write-Output "Total current group-assignments: $($currentAssignments.Count),

SP-ObjectId: $($sp.ObjectId)"
$currAssignedObjectIds = New-Object
'System.Collections.Generic.HashSet[string]'
foreach ($assignment in $currentAssignments)
Write-Output "Assignment-ObjectId: $($assignment.PrincipalId)"
if ($newGroupIds.Contains($assignment.PrincipalId) -eq $false)
Write-Output "This assignment is not needed anymore. Removing it!

Assignment-ObjectId: $($assignment.PrincipalId)"
Remove-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId -

AppRoleAssignmentId $assignment.ObjectId
else
$currAssignedObjectIds.Add($assignment.PrincipalId)
Write-Output
"***************************************************************************
*`n"
Write-Output
"`n*************************************************************************
***"
foreach ($id in $newGroupIds)
try
if ($currAssignedObjectIds.Contains($id) -eq $false)
Write-Output "Adding new group-assignment. Role-Id: $($role.Id),

Group-Object-Id: $id, ResourceId: $($sp.ObjectId)"
New-AzureADGroupAppRoleAssignment -Id $role.Id -ObjectId $id -

PrincipalId $id -ResourceId $sp.ObjectId
else
Write-Output "Group-ObjectId: $id is already assigned."
catch
Write-Error "Exception occurred assigning Object-ID: $id. Exception:

$($_.Exception)."
Write-Output
"***************************************************************************
*`n"
Activer synchronisation délimitée

Pour activer la synchronisation délimitée basée sur les groupes pour un domaine
managé, procédez comme suit :
1. Commencez par définir "filteredSync" = "Enabled" sur la ressource Azure AD DS,
puis mettez à jour le domaine managé.
Lorsque vous y êtes invité, spécifiez les informations d’identification d’un

administrateur général pour vous connecter à votre locataire Azure AD à l’aide de
la cmdlet Connect-AzureAD :
PowerShell
# Connect to your Azure AD tenant

Connect-AzureAD
# Retrieve the Azure AD DS resource.
$DomainServicesResource = Get-AzResource -ResourceType

"Microsoft.AAD/DomainServices"
# Enable group-based scoped synchronization.
$enableScopedSync = @{"filteredSync" = "Enabled"}
# Update the Azure AD DS resource

Set-AzResource -Id $DomainServicesResource.ResourceId -Properties
$enableScopedSync
2. Spécifiez à présent la liste des groupes dont les utilisateurs doivent être
synchronisés avec le domaine managé.
Exécutez le script Select-GroupsToSync.ps1 et spécifiez la liste des groupes à

synchroniser. Dans l’exemple suivant, les groupes à synchroniser sont Select-
GroupsToSync.ps1 et GroupName2.
２ Avertissement
Vous devez inclure le groupe AAD DC Administrators dans la liste des groupes
configurés pour la synchronisation délimitée. Si vous n’incluez pas ce groupe,
le domaine managé est inutilisable.
PowerShell
.\Select-GroupsToSync.ps1 -groupsToAdd @("AAD DC Administrators",

"GroupName1", "GroupName2")
La changement de l’étendue de la synchronisation conduit le domaine managé à

resynchroniser toutes les données. Les objets qui ne sont plus nécessaires dans le
domaine managé sont supprimés, et la resynchronisation peut prendre du temps.
Modifier la synchronisation délimitée
Pour modifier la liste des groupes dont les utilisateurs doivent être synchronisés sur le
domaine managé, exécutez le script Select-GroupsToSync.ps1 et spécifiez la nouvelle
liste de groupes à synchroniser.
Dans l’exemple suivant, les groupes à synchroniser n’incluent plus GroupName2, mais
incluent maintenant GroupName3.
２ Avertissement
Vous devez inclure le groupe AAD DC Administrators dans la liste des groupes
configurés pour la synchronisation délimitée. Si vous n’incluez pas ce groupe, le
domaine managé est inutilisable.
Lorsque vous y êtes invité, spécifiez les informations d’identification d’un administrateur
général pour vous connecter à votre locataire Azure AD à l’aide de la cmdlet Connect-
AzureAD :
PowerShell
.\Select-GroupsToSync.ps1 -groupsToAdd @("AAD DC Administrators",

"GroupName1", "GroupName3")

Désactiver la synchronisation délimitée

Pour désactiver la synchronisation délimitée basée sur les groupes pour un domaine
managé, définissez "filteredSync" = "Disabled" sur la ressource Azure AD DS, puis mettez
à jour le domaine managé. À l’issue de cette opération, l’ensemble des utilisateurs et
des groupes sont définis pour être synchronisés à partir d’Azure AD.
Lorsque vous y êtes invité, spécifiez les informations d’identification d’un administrateur
général pour vous connecter à votre locataire Azure AD à l’aide de la cmdlet Connect-
AzureAD :
PowerShell
# Connect to your Azure AD tenant
Connect-AzureAD
# Retrieve the Azure AD DS resource.

# Disable group-based scoped synchronization.
$disableScopedSync = @{"filteredSync" = "Disabled"}
# Update the Azure AD DS resource

$disableScopedSync

Étapes suivantes
Créer une approbation de forêt Azure
Active Directory Domain Services avec
un domaine local à l’aide d’Azure
PowerShell
Article • 12/04/2023
Dans les environnements ne permettant pas la synchronisation des hachages de mot de

passe, ou en présence d’utilisateurs se connectant exclusivement à l’aide de cartes à
puce et ne connaissant pas leur mot de passe, vous pouvez créer une approbation
sortante à partir d’Azure Active Directory Domain Services (Azure AD DS) vers un ou
plusieurs environnements AD DS locaux. Cette relation d’approbation permet aux
utilisateurs, applications et ordinateurs de s’authentifier auprès d’un domaine local à
partir du domaine managé Azure AD DS. Dans ce cas, les hachages de mots de passe ne
sont jamais synchronisés.
Dans cet article, vous apprendrez comment :
＂ Créer une forêt Azure AD DS à l’aide d’Azure PowerShell

＂ Créer une approbation de forêt sortante unidirectionnelle dans le domaine managé
à l’aide d’Azure PowerShell
connectivité du domaine managé
AD DS local
ressources

） Important
Les forêts de domaine managé ne prennent actuellement pas en charge Azure

HDInsight et Azure Files. Les forêts de domaine managé par défaut prennent en
charge ces deux services supplémentaires.
Prérequis





Dans cet article, vous créez et vous configurez une approbation de forêt sortante à
partir d'un domaine managé avec le portail Azure. Pour commencer, connectez-vous au
portail Azure .
Processus de déploiement
Il s’agit d’un processus en plusieurs parties qui permet de créer une forêt de domaine
managé et la relation d’approbation avec un environnement AD DS local. La procédure
générale suivante crée votre environnement hybride approuvé :
1. Créez un principal de service de domaine managé.

2. Créez une forêt de domaine managé.
3. Créez une connectivité réseau hybride à l’aide d’un VPN site à site ou d’Express
Route.
4. Créez le côté domaine managé de la relation d’approbation.
5. Créez le côté AD DS local de la relation d’approbation.
Avant de commencer, assurez-vous de comprendre les considérations relatives au

réseau, l’attribution d’un nom à la forêt et la configuration DNS requise. Une fois que la
forêt du domaine managé est déployée, vous ne pouvez pas modifier son nom.
Créez le principal du service Azure AD

Azure AD DS nécessite un principal de service pour synchroniser les données depuis
Azure AD. Ce principal doit être créé dans votre locataire Azure AD avant la création de
la forêt de domaine managée.
Créez un principal du service Azure AD pour permettre à Azure AD DS de communiquer

et de s’authentifier. Un ID d’application spécifique est utilisé. Il se nomme Domain
Controller Services et son ID est 6ba9a5d4-8456-4118-b521-9c5ca10cdf84. Ne modifiez
pas cet ID d’application.
Créez un principal du service Azure AD à l’aide de l’applet de commande New-

AzureADServicePrincipal :
PowerShell
New-AzureADServicePrincipal -AppId "6ba9a5d4-8456-4118-b521-9c5ca10cdf84"

Pour créer un domaine managé, vous devez utiliser le script New-AzureAaddsForest . Ce
script fait partie d’un ensemble de commandes plus vaste qui prennent en charge les
domaines managés, notamment la création d’une forêt de liaison unidirectionnelle dans
une prochaine section. Ces scripts sont disponibles à partir de PowerShell Gallery et
sont signés numériquement par l’équipe d’ingénieurs d’Azure AD.
1. Créez tout d’abord un groupe de ressources avec la cmdlet New-

Azure PowerShell
-Name "myResourceGroup" `
-Location "WestUS"
2. Installez le script New-AaddsResourceForestTrust à partir de New-

AaddsResourceForestTrust à l’aide de la cmdlet Install-script :
PowerShell
Install-Script -Name New-AaddsResourceForestTrust
3. Passez en revue les paramètres suivants dans le script New-AzureAaddsForest .

Assurez-vous que vous disposez également des modules Azure PowerShell et
Azure AD PowerShell prérequis. Assurez-vous d’avoir planifié les exigences du
réseau virtuel pour fournir l’application et la connectivité locale.
Nom Paramètre de script Description
Abonnement -azureSubscriptionId ID d’abonnement utilisé pour la facturation

Azure AD DS. Vous pouvez obtenir la liste
des abonnements en utilisant la cmdlet Get-
AzureRMSubscription.
Groupe de - Nom du groupe de ressources pour le

ressources aaddsResourceGroupName domaine managé et les ressources associées.
Emplacement -aaddsLocation Région Azure devant héberger votre

domaine managé. Pour savoir quelles
régions sont disponibles, consultez Régions
prises en charge pour Azure AD DS.
Administrateur -aaddsAdminUser Nom de l’utilisateur principal du premier

Azure AD DS administrateur de domaine managé. Ce
compte doit être un compte d'utilisateur
cloud déjà existant dans votre Azure Active
Directory. L’utilisateur et l’utilisateur qui
exécute le script sont ajoutés au groupe AAD
DC Administrators.
Nom de -aaddsDomainName FQDN du domaine managé basé sur les

domaine instructions précédentes relatives au choix
Azure AD DS d’un nom de forêt.
Le script New-AzureAaddsForest peut créer le réseau virtuel Azure et le sous-réseau

Azure AD DS s’ils n’existent pas encore. Le script peut éventuellement créer les
sous-réseaux de la charge de travail, le cas échéant :
Nom du -aaddsVnetName Nom du réseau virtuel pour le domaine

réseau managé.
virtuel
Espace -aaddsVnetCIDRAddressSpace Plage d’adresses du réseau virtuel en

d’adressage notation CIDR (si création du réseau
virtuel).
Nom de -aaddsSubnetName Nom du sous-réseau du réseau virtuel

sous-réseau aaddsVnetName hébergeant le
Azure AD domaine managé. Ne déployez pas vos
DS propres machines virtuelles et charges
de travail dans ce sous-réseau.
Plage -aaddsSubnetCIDRAddressRange Plage d’adresses de sous-réseau en

d’adresses notation CIDR pour l’instance Azure
Azure AD AD DS, par exemple 192.168.1.0/24. Le
DS plage d’adresses doit être contenue
dans la plage d’adresses du réseau
virtuel et être différente des autres
sous-réseaux.
Nom du -workloadSubnetName Nom facultatif d’un sous-réseau dans le

sous-réseau réseau virtuel aaddsVnetName à créer
de la charge pour vos propres charges de travail
de travail d’application. La machines virtuelles et
(facultatif) les applications peuvent également
être connectées à un réseau virtuel
Azure appairé à la place.
Plage - Plage d’adresses de sous-réseau

d’adresses workloadSubnetCIDRAddressRange facultative en notation CIDR pour la
de la charge charge de travail d’application, par
de travail exemple 192.168.2.0/24. Le plage
(facultatif) d’adresses doit être contenue dans la
plage d’adresses du réseau virtuel et
être différente des autres sous-réseaux.
4. À présent, créez une forêt de domaine managé à l’aide du script New-

AzureAaaddsForest . L’exemple suivant crée une forêt nommée addscontoso.com et
un sous-réseau de charge de travail. Indiquez vos propres noms de paramètre et

plages d’adresses IP ou réseaux virtuels existants.
Azure PowerShell
New-AzureAaddsForest `
-azureSubscriptionId <subscriptionId> `
-aaddsResourceGroupName "myResourceGroup" `
-aaddsLocation "WestUS" `
-aaddsAdminUser "contosoadmin@contoso.com" `
-aaddsDomainName "aaddscontoso.com" `
-aaddsVnetName "myVnet" `
-aaddsVnetCIDRAddressSpace "192.168.0.0/16" `
-aaddsSubnetName "AzureADDS" `
-aaddsSubnetCIDRAddressRange "192.168.1.0/24" `
-workloadSubnetName "myWorkloads" `
-workloadSubnetCIDRAddressRange "192.168.2.0/24"
La création de la forêt de domaine managé et la prise en charge des ressources

prennent un certain temps. Autorisez l’exécution du script. Passez à la section
suivante pour configurer votre connectivité réseau locale pendant que la forêt
Azure AD est en cours de configuration en arrière-plan.
Configurer et valider les paramètres réseau

Pendant que le déploiement du domaine managé suit son cours, configurez et validez la
connectivité réseau hybride avec le centre de données local. Vous avez également
besoin d’une machine virtuelle de gestion à utiliser avec le domaine managé pour une
maintenance régulière. Une partie de la connectivité hybride existe peut-être déjà dans
votre environnement ou vous devez peut-être travailler avec d’autres personnes de
votre équipe pour configurer les connexions.
Avant de commencer, assurez-vous de comprendre les considérations et
recommandations relatives au réseau.
1. Créez la connectivité hybride de votre réseau local à Azure à l’aide d’une

connexion VPN Azure ou Azure ExpressRoute. La configuration du réseau hybride
n’entre pas dans le cadre de cette documentation et elle existe peut-être déjà dans
votre environnement. Pour plus de détails sur des scénarios spécifiques, consultez
les articles suivants :
VPN de site à site Azure.

Vue d’ensemble d’Azure ExpressRoute.
） Important
Si vous créez une connexion directement vers votre réseau virtuel de domaine
managé, utilisez un sous-réseau de passerelle distinct. Ne créez pas la
passerelle dans le sous-réseau du domaine managé.
2. Pour administrer un domaine managé, vous devez créer une machine virtuelle de
gestion, la joindre au domaine managé, puis installer les outils de gestion AD DS
requis.
Lors du déploiement de domaine managé, créez une machine virtuelle Windows

Server, puis installez les outils de gestion AD DS de base pour installer les outils de
gestion nécessaires. Attendez une des prochaines étapes après la réussite du
déploiement du domaine pour joindre la machine virtuelle de gestion au domaine
managé.
3. Validez la connectivité réseau entre votre réseau local et le réseau virtuel Azure.
Confirmez que le contrôleur de domaine local peut se connecter à la machine

virtuelle managée à l’aide de ping ou du bureau à distance, par exemple.
Vérifiez que votre machine virtuelle de gestion peut se connecter à vos
contrôleurs de domaine locaux, de nouveau à l’aide d’un utilitaire, tel que
ping .

Choisissez votre domaine managé, tel que aaddscontoso.com et attendez que le
statut soit signalé comme En cours d’exécution.
Lors de l’exécution, mettez à jour les paramètres DNS du réseau virtuel Azure, puis
activez les comptes d’utilisateur pour Azure AD DS afin de finaliser les
configurations de votre domaine managé.
5. Prenez note des adresses DNS affichées sur la page de présentation. Vous avez
besoin de ces adresses lors de la configuration du côté Active Directory local de la
relation d’approbation dans une section suivante.
6. Redémarrez la machine virtuelle de gestion afin qu’elle reçoive les nouveaux

paramètres DNS et qu’elle joigne la machine virtuelle au domaine managé.
7. Une fois la machine virtuelle de gestion jointe au domaine managé, reconnectez-

vous à l’aide du bureau à distance.
À partir d’une invite de commandes, utilisez nslookup et le nom du domaine

managé afin de valider la résolution de noms pour la forêt.
Console
nslookup aaddscontoso.com
La commande doit retourner deux adresses IP pour la forêt.
Créer l’approbation de forêt

L’approbation de forêt se fait en deux parties : l’approbation de forêt sortante
unidirectionnelle dans le domaine managé, et l’approbation de la forêt entrante
unidirectionnelle dans la forêt AD DS locale. Vous créez manuellement les deux côtés de
cette relation d’approbation. Lorsque les deux côtés sont créés, les utilisateurs et les
ressources peuvent s’authentifier avec succès à l’aide de l’approbation de forêt. Un
domaine managé prend en charge jusqu’à cinq approbations de forêt sortante
unidirectionnelle vers des forêts locales.
Créer le côté domaine managé de la relation

d’approbation
Utilisez le script Add-AaddsResourceForestTrust pour créer le côté domaine managé de
la relation d’approbation. Tout d’abord, installez le script Add-AaddsResourceForestTrust
à partir de Add-AaddsResourceForestTrust à l’aide de la cmdlet Install-script :
PowerShell
Install-Script -Name Add-AaddsResourceForestTrust
Maintenant, apportez les informations suivantes au script :

Nom de - FQDN du domaine managé, par exemple

domaine ManagedDomainFqdn aaddscontoso.com
Azure AD DS
Nom de -TrustFqdn FQDN de la forêt approuvée, par exemple

domaine AD onprem.contoso.com
DS local
Nom convivial -TrustFriendlyName Nom convivial de la relation d’approbation.

de
l’approbation
Adresses IP -TrustDnsIPs Une liste, séparée par des virgules, des adresses de
DNS AD DS serveur DNS IPv4 pour le domaine approuvé listé.
locales
Mot de passe -TrustPassword Mot de passe complexe pour la relation d’approbation.

d'approbation Ce mot de passe est également entré lors de la création
de l’approbation entrante unidirectionnelle dans l’AD
DS local.
Informations -Credentials Informations d'identification permettant de

d'identification s’authentifier dans Azure. L’utilisateur doit être dans le
groupe AAD DC Administrators. S’il n’est pas fourni, le
script vous invite à l’authentification.
L’exemple suivant crée une relation d’approbation nommée myAzureADDSTrust vers

onprem.contoso.com. Utilisez vos propres noms de paramètre et vos propres mots de
passe.
Azure PowerShell
Add-AaddsResourceForestTrust `
-ManagedDomainFqdn "aaddscontoso.com" `
-TrustFqdn "onprem.contoso.com" `
-TrustFriendlyName "myAzureADDSTrust" `
-TrustDnsIPs "10.0.1.10,10.0.1.11" `
-TrustPassword <complexPassword>
） Important
N’oubliez pas votre mot de passe d’approbation. Vous devez utiliser le même mot
de passe lors de la création du côté local de l’approbation.
Configurer DNS dans le domaine local
Pour résoudre correctement le domaine managé à partir de l’environnement local, vous
serez peut-être amené à ajouter des redirecteurs aux serveurs DNS existants. Si vous
n’avez pas configuré l’environnement local de manière à ce qu’il communique avec le
domaine managé, effectuez les étapes suivantes à partir d’une station de travail de
gestion pour le domaine AD DS local :
1. Sélectionnez Démarrer | Outils d'administration | DNS.

2. Cliquez avec le bouton droit sur le serveur DNS, comme myAD01, sélectionnez
Propriétés.
3. Sélectionnez Redirecteurs, puis Modifier pour ajouter des redirecteurs
supplémentaires.
4. Ajoutez les adresses IP du domaine managé, telles que 10.0.1.4 et 10.0.1.5.
5. À partir d’une invite de commandes locale, validez la résolution de noms à l’aide
de nslookup du nom du domaine managé. Par exemple, Nslookup
aaddscontoso.com doit retourner les deux adresses IP pour le domaine managé.
Créer une approbation de forêt entrante dans

le domaine local
Le domaine AD DS local nécessite une approbation de forêt entrante pour le domaine
managé. Cette approbation doit être créée manuellement dans le domaine AD DS local ;
sa création n'est pas possible à partir du portail Azure.
Pour configurer l’approbation entrante sur le domaine AD DS local, procédez comme

suit à partir d’une station de travail de gestion pour le domaine AD DS local :
1. Sélectionnez Démarrer | Outils d'administration | Domaines et approbations

Active Directory
2. Cliquez avec le bouton droit sur un domaine, par exemple onprem.contoso.com,
3. Sélectionnez l'onglet Approbations, puis Nouvelle approbation.
4. Entrez le nom du domaine managé, tel que aaddscontoso.com, puis sélectionnez
Suivant
5. Sélectionnez l’option permettant de créer une approbation de forêt, puis une
approbation unidirectionnelle : entrante.
6. Choisissez de créer l’approbation pour ce domaine uniquement. À l’étape
suivante, vous allez créer l’approbation dans le portail Azure pour le domaine
managé.
7. Choisissez d’utiliser l'authentification à l'échelle de la forêt, puis entrez et
confirmez un mot de passe d’approbation. Ce même mot de passe est également
entré dans le portail Azure à la section suivante.
8. Parcourez les fenêtres suivantes avec les options par défaut, puis sélectionnez
l’option pour Non, ne pas confirmer l'approbation sortante. Vous ne pouvez pas
valider la relation d’approbation, car votre compte administrateur délégué au
domaine managé ne dispose pas des autorisations requises. Ce comportement est
normal.
9. Sélectionnez Terminer.
Valider l’authentification des ressources

Les scénarios courants suivants vous permettent de vérifier que l’approbation de forêt
authentifie correctement les utilisateurs et l’accès aux ressources :
Authentification des utilisateurs locaux à partir de la forêt Azure AD DS

Accéder aux ressources de la forêt Azure AD DS en tant qu’utilisateur local
Activer le partage de fichiers et d'imprimantes
Valider l'authentification inter-forêts vers une ressource
Authentification des utilisateurs locaux à partir de la forêt

Azure AD DS
Vous devez avoir une machine virtuelle Windows Server jointe à la forêt de ressources
du domaine managé. Utilisez cette machine virtuelle pour vérifier que votre utilisateur
local peut s’authentifier sur une machine virtuelle.
1. Connectez-vous à la machine virtuelle Windows Server jointe au domaine managé

à l’aide du Bureau à distance et de vos informations d’identification
d’administrateur de domaine managé. Si une erreur d'authentification au niveau
du réseau s'affiche, vérifiez que le compte d’utilisateur que vous avez utilisé ne
correspond pas un compte d’utilisateur de domaine.
 Conseil
Pour vous connecter en toute sécurité à vos machines virtuelles jointes à

Azure AD Domain Services, vous pouvez utiliser le service hôte Azure Bastion
dans les régions Azure prises en charge.
2. Ouvrez une invite de commandes et utilisez la commande whoami pour afficher le
nom unique de l’utilisateur actuellement authentifié :
Console
whoami /fqdn
3. Utilisez la commande runas pour vous authentifier en tant qu’utilisateur à partir

du domaine local. Dans la commande suivante, remplacez
userUpn@trusteddomain.com par l’UPN d’un utilisateur du domaine local approuvé.
La commande vous invite à entrer le mot de passe de l’utilisateur :
Console
Runas /u:userUpn@trusteddomain.com cmd.exe
4. Si l’authentification aboutit, une nouvelle invite de commandes s’ouvre. Le titre de

la nouvelle invite de commandes comprend running as
userUpn@trusteddomain.com .
5. Utilisez whoami /fqdn dans la nouvelle invite de commandes pour afficher le nom
unique de l’utilisateur authentifié à partir de l'instance Active Directory locale.
Accéder aux ressources dans Azure AD DS en tant

qu’utilisateur local
À l’aide de la machine virtuelle Windows Server jointe au domaine managé, vous pouvez
tester le scénario permettant aux utilisateurs d’accéder aux ressources hébergées dans
la forêt quand ils s’authentifient à partir d’ordinateurs du domaine local en tant
qu’utilisateurs du domaine local. Les exemples suivants vous montrent comment créer
et tester différents scénarios courants.
Activer le partage de fichiers et d’imprimantes
1. Connectez-vous à la machine virtuelle Windows Server jointe au domaine managé

à l’aide du Bureau à distance et de vos informations d’identification
d’administrateur de domaine managé. Si une erreur d'authentification au niveau
du réseau s'affiche, vérifiez que le compte d’utilisateur que vous avez utilisé ne
correspond pas un compte d’utilisateur de domaine.
 Conseil
Pour vous connecter en toute sécurité à vos machines virtuelles jointes à
Azure AD Domain Services, vous pouvez utiliser le service hôte Azure Bastion
dans les régions Azure prises en charge.
2. Ouvrez Paramètres Windows, puis recherchez et sélectionnez Centre Réseau et

partage.
3. Sélectionnez l’option permettant de modifier les paramètres de partage avancés.
4. Sous Profil du domaine, sélectionnez Activer le partage de fichiers et

d'imprimantes, puis Enregistrer les modifications.
5. Fermez Centre Réseau et partage.
1. Ouvrez Utilisateurs et ordinateurs Active Directory.
2. Cliquez avec le bouton droit sur le nom de domaine, sélectionnez Nouveau, puis
Unité d'organisation.
3. Dans la zone de nom, entrez LocalObjects, puis sélectionnez OK.
4. Sélectionnez et cliquez avec le bouton droit sur LocalObjects dans le volet de

navigation. Sélectionnez Nouveau, puis Groupe.
5. Entrez FileServerAccess dans la zone Nom du groupe. Pour Étendue du groupe,

sélectionnez Domaine local, puis OK.
6. Dans le volet de contenu, double-cliquez sur FileServerAccess. Sélectionnez

Membres, Ajouter, puis Emplacements.
7. Sélectionnez votre instance Active Directory locale dans l'affichage Emplacement,

puis OK.
8. Entrez Utilisateurs du domaine dans la zone Entrer les noms des objets à
sélectionner. Sélectionnez Vérifier les noms, fournissez les informations
d’identification de l'instance Active Directory locale, puis sélectionnez OK.
７ Notes
La relation d'approbation étant unidirectionnelle, vous devez fournir les

informations d’identification. Cela veut dire que les utilisateurs du domaine
managé ne peuvent pas accéder aux ressources ni rechercher des utilisateurs
ou des groupes dans le domaine (local) approuvé.
9. Le groupe Utilisateurs du domaine de votre instance Active Directory locale doit

être membre du groupe FileServerAccess. Sélectionnez OK pour enregistrer le
groupe et fermer la fenêtre.

1. Sur la machine virtuelle Windows Server jointe au domaine managé, créez un
dossier et donnez-lui un nom, tel que CrossForestShare.
2. Cliquez avec le bouton droit sur le dossier, puis sélectionnez Propriétés.
3. Sélectionnez l'onglet Sécurité, puis Modifier.
4. Dans la boîte de dialogue Autorisations pour CrossForestShare, sélectionnez
Ajouter.
5. Entrez FileServerAccess dans Entrer les noms des objets à sélectionner, puis
sélectionnez OK.
6. Sélectionnez FileServerAccess dans la liste Noms des groupes ou des utilisateurs.
Dans la liste Autorisations pour FileServerAccess, sélectionnez Autoriser pour les
autorisations Modifier et Écrire, puis OK.
7. Sélectionnez l’onglet Partage, puis Partage avancé…
8. Sélectionnez Partager ce dossier, puis entrez un nom de partage de fichiers facile
à retenir dans Nom du partage, par exemple CrossForestShare.
9. Sélectionnez Autorisations. Dans la liste Autorisations pour tous, sélectionnez
Autoriser pour l'autorisation Modifier.
10. Sélectionnez OK deux fois, puis Fermer.
Valider l’authentification inter-forêts sur une ressource

1. Connectez-vous à un ordinateur Windows joint à votre instance Active Directory
locale à l’aide d’un compte d’utilisateur de votre instance Active Directory locale.
2. À l’aide de l'Explorateur Windows, connectez-vous au partage que vous avez créé

à l’aide du nom d’hôte complet et le partage, par exemple .
3. Pour valider l’autorisation d’écriture, cliquez avec le bouton droit dans le dossier,
sélectionnez Nouveau, puis Document texte. Utilisez le nom par défaut Nouveau
document texte.
Si les autorisations d’écriture sont correctement définies, un nouveau document

texte est créé. Les étapes suivantes permettent d'ouvrir, de modifier et de
supprimer le fichier, selon vos besoins.
4. Pour valider l’autorisation de lecture, ouvrez Nouveau document texte.
5. Pour valider l’autorisation de modification, ajoutez du texte au fichier et fermez le

Bloc-notes. Lorsque vous êtes invité à enregistrer les modifications, sélectionnez
Enregistrer.
6. Pour valider l’autorisation de suppression, cliquez avec le bouton droit sur

Nouveau document texte, puis sélectionnez Supprimer. Sélectionnez Oui pour
confirmer la suppression du fichier.
Mettre à jour ou supprimer l’approbation de la

forêt sortante
Si vous devez mettre à jour une forêt sortante unidirectionnelle existante depuis le
domaine managé, vous pouvez utiliser les scripts Get-AaddsResourceForestTrusts et
Set-AaddsResourceForestTrust . Ces scripts vous aident dans les scénarios où vous
souhaitez mettre à jour le nom convivial de la forêt d’approbation ou le mot de passe

d’approbation. Pour supprimer une approbation sortante unidirectionnelle depuis le
domaine managé, vous pouvez utiliser le script Remove-AaddsResourceForestTrust . Vous
devez supprimer manuellement l’approbation de forêt sortante unidirectionnelle dans la
forêt AD DS locale associée.
Mettre à jour une approbation de forêt

En cas de fonctionnement normal, le domaine managé et la forêt locale négocient un
processus de mise à jour de mot de passe régulier. Cela fait partie du processus normal
de sécurité de la relation d’approbation AD DS. Vous n’avez pas besoin d’opérer une
rotation du mot de passe d’approbation manuellement, sauf si la relation d’approbation
a rencontré un problème et que vous souhaitez réinitialiser manuellement un mot de
passe connu. Pour en savoir plus, consultez Changements de mot de passe de l’objet de
domaine approuvé.
L’exemple suivant illustre la procédure de mise à jour d’une relation d’approbation

existante si vous devez réinitialiser manuellement le mot de passe d’approbation
sortant :
1. Installez les scripts Get-AaddsResourceForestTrusts et Set-

AaddsResourceForestTrust à partir de Get-AaddsResourceForestTrusts à l’aide de la
cmdlet Set-AaddsResourceForestTrust :
PowerShell
Install-Script -Name Get-AaddsResourceForestTrusts,Set-

AaddsResourceForestTrust
2. Avant de pouvoir mettre à jour l’approbation existante, obtenez la ressource

d’approbation à l’aide du script Get-AaddsResourceForestTrusts . Dans l’exemple
suivant, l’approbation existante est attribuée à un objet nommé existingTrust.
Spécifiez votre propre nom de forêt de domaine managé et le nom de forêt locale
à mettre à jour :
PowerShell
$existingTrust = Get-AaddsResourceForestTrust `
-TrustFriendlyName "myAzureADDSTrust"
3. Pour mettre à jour le mot de passe d’approbation existant, utilisez le script Set-
AaddsResourceForestTrust . Spécifiez l’objet d’approbation existant d’une étape
précédente, puis un nouveau mot de passe de relation d’approbation. Étant donné

que PowerShell ne garantit pas de complexité de mot de passe, assurez-vous de
générer et utiliser un mot de passe sécurisé pour votre environnement.
PowerShell
Set-AaddsResourceForestTrust `
-Trust $existingTrust `
-TrustPassword <newComplexPassword>
Supprimer une approbation de forêt

Si vous n’avez plus besoin d’une approbation de forêt sortante unidirectionnelle du
domaine managé vers une forêt AD DS locale, vous pouvez la supprimer. Assurez-vous
qu’aucune application et aucun service n’a besoin de s’authentifier sur la forêt AD DS
locale avant de supprimer l’approbation. Vous devez supprimer manuellement
l’approbation entrante unidirectionnelle dans la forêt AD DS locale également.
1. Installez le script Remove-AaddsResourceForestTrust à partir de Remove-

AaddsResourceForestTrust à l’aide de la cmdlet Install-script :
PowerShell
Install-Script -Name Remove-AaddsResourceForestTrust
2. À présent, supprimez l’approbation de forêt à l’aide du script Remove-

AaddsResourceForestTrust . Dans l’exemple suivant, le nom de l’approbation
myAzureADDSTrust entre la forêt du domaine managé nommé aaddscontoso.com
et la forêt locale onprem.contoso.com est supprimé. Spécifiez votre propre nom de
forêt de domaine managé et le nom de la forêt locale à supprimer :
PowerShell
Remove-AaddsResourceForestTrust `
-TrustFriendlyName "myAzureADDSTrust"
Pour supprimer l’approbation entrante unidirectionnelle de la forêt AD DS locale,

connectez-vous à un ordinateur de gestion avec accès à la forêt AD DS locale et
procédez comme suit :
1. Sélectionnez Démarrer | Outils d’administration | Domaines et approbations

Active Directory.
2. Cliquez avec le bouton droit sur un domaine, par exemple onprem.contoso.com, et
3. Choisissez l’onglet Approbation, puis sélectionnez l’approbation entrante existante
de votre forêt de domaine managé.
4. Sélectionnez Supprimer, puis confirmez que vous souhaitez supprimer
l’approbation entrante.
Étapes suivantes
Dans cet article, vous avez appris à effectuer les opérations suivantes :
＂ Créer un domaine managé avec Azure PowerShell

＂ Créer une approbation de forêt sortante unidirectionnelle dans le domaine managé
à l’aide d’Azure PowerShell
＂ Configurer un DNS dans un environnement AD DS local pour prendre en charge la
connectivité du domaine managé
AD DS local
ressources
Pour plus d’informations conceptuelles sur les types de forêts dans Azure AD DS,
consultez Fonctionnement des relations d’approbation pour les forêts dans Active
Directory.
Concepts de gestion pour les comptes
d’utilisateur, les mots de passe et
l’administration dans Azure Active
Lorsque vous créez et exécutez un domaine managé Azure Active Directory Domain
Services (AD DS), il existe des différences de comportement par rapport à un
environnement AD DS local traditionnel. Vous utilisez les mêmes outils d’administration
dans Azure AD DS en tant que domaine automanagé, mais vous ne pouvez pas accéder
directement aux contrôleurs de domaine (DC). Il existe également des différences de
comportement pour les stratégies de mot de passe et les hachages de mot de passe en
fonction de la source de la création du compte d’utilisateur.
Cet article conceptuel explique en détail comment administrer un domaine managé et le

comportement différent des comptes d’utilisateur en fonction de la façon dont ils sont
créés.
Gestion de domaine
Un domaine managé est un espace de noms DNS associé à un annuaire. Dans un
domaine managé, les contrôleurs de domaine (DC) qui contiennent toutes les
ressources telles que les utilisateurs et les groupes, les informations d’identification et
les stratégies font partie du service managé. Pour la redondance, deux contrôleurs de
domaine sont créés dans le cadre d’un domaine managé. Vous ne pouvez pas vous
connecter à ces contrôleurs de domaine pour effectuer des tâches de gestion. Au lieu de
cela, vous créez une machine virtuelle de gestion qui est jointe au domaine managé,
puis vous installez vos outils de gestion AD DS standard. Vous pouvez utiliser les
composants logiciels enfichables du Centre d’administration Active Directory ou de
MMC (Microsoft Management Console) comme les objets DNS ou de stratégie de
groupe.
Création d’un compte d'utilisateur

Les comptes d’utilisateurs peuvent être créés dans un domaine managé de plusieurs
façons. La plupart des comptes d’utilisateurs sont synchronisés à partir d’Azure AD, qui
peuvent également inclure un compte d’utilisateur synchronisé à partir d’un
environnement AD DS local. Vous pouvez également créer manuellement des comptes
directement dans un domaine managé. Certaines caractéristiques, telles que la
synchronisation de mot de passe initiale ou la stratégie de mot de passe, se comportent
différemment selon le mode et l’emplacement de création des comptes d’utilisateur.
Le compte d’utilisateur peut être synchronisé à partir d’Azure AD. Cela comprend
les comptes d’utilisateurs uniquement dans le cloud créés directement dans
Azure AD, et les comptes d’utilisateur hybrides synchronisés à partir d’un
environnement AD DS local à l’aide d’Azure AD Connect.
La majorité des comptes d’utilisateur dans un domaine managé sont créés par
le biais du processus de synchronisation à partir d’Azure AD.
Le compte d’utilisateur peut être créé manuellement dans un domaine managé et
n’existe pas dans Azure AD.
Si vous avez besoin de créer des comptes de service pour des applications qui
s’exécutent uniquement dans un domaine managé, vous pouvez les créer
manuellement dans le domaine managé. La synchronisation étant
unidirectionnelle à partir d’Azure AD, les comptes d’utilisateurs créés dans un
domaine managé ne sont pas resynchronisés avec Azure AD.
Stratégie de mot de passe

Azure AD DS comprend une stratégie de mot de passe par défaut qui définit des
paramètres pour les éléments tels que le verrouillage de compte, l’âge maximum du
mot de passe et la complexité du mot de passe. Les paramètres tels que la stratégie de
verrouillage de compte s’appliquent à tous les utilisateurs dans un domaine managé
quelle que soit la façon dont l’utilisateur a été créé comme indiqué dans la section
précédente. Certains paramètres, comme la longueur minimale et la complexité du mot
de passe, s’appliquent uniquement aux utilisateurs créés directement dans un domaine
managé.
Vous pouvez créer vos propres stratégies de mot de passe personnalisées pour
remplacer la stratégie par défaut dans un domaine managé. Ces stratégies
personnalisées peuvent ensuite être appliquées à des groupes d’utilisateurs spécifiques
en fonction des besoins.
Pour plus d’informations sur les différences dans la façon dont les stratégies de mot de
passe sont appliquées en fonction de la source de la création de l’utilisateur, consultez
Stratégies de mot de passe et de verrouillage de compte sur les domaines managés.
Hachages de mot de passe

mot de passe avant de pouvoir utiliser le domaine managé. Ce processus de
changement du mot de passe entraîne la génération et le stockage dans Azure AD des
hachages de mot de passe pour l’authentification Kerberos et NTLM. Le compte n’est
pas synchronisé entre Azure AD et Azure AD DS tant que le mot de passe n’a pas été
modifié.
Pour les utilisateurs synchronisés à partir d’un environnement AD DS local à l’aide

d’Azure AD Connect, activez la synchronisation des hachages de mot de passe .
） Important
Azure AD Connect synchronise uniquement les hachages de mot de passe hérités

lorsque vous activez Azure AD DS pour votre client Azure AD. Les hachages de mot
de passe hérités ne sont pas utilisés si vous utilisez uniquement Azure AD Connect
pour synchroniser un environnement AD DS local avec Azure AD.
Si vos applications héritées n’utilisent pas l’authentification NTLM ou les liaisons

simples LDAP, nous vous recommandons de désactiver la synchronisation de
hachage de mot de passe NTLM pour Azure AD DS. Pour plus d’informations,
consultez Désactiver les suites de chiffrement faible et la synchronisation des
hachages des informations d’identification NTLM.
Une fois configurés de façon appropriée, les hachages de mot de passe utilisables sont
stockés dans le domaine managé. Si vous supprimez le domaine managé, tout hachage
de mot de passe stocké à ce stade est également supprimé. Les informations
d’identification synchronisées dans Azure AD ne peuvent pas être réutilisées si vous
créez par la suite un domaine managé : vous devez reconfigurer la synchronisation de
hachage de mot de passe pour stocker à nouveau les hachages de mot de passe. Les
machines virtuelles ou les utilisateurs auparavant joints à un domaine ne pourront pas
s’authentifier immédiatement : Azure AD doit générer et stocker les hachages de mot de
passe dans le nouveau domaine managé. Pour plus d’informations, consultez Processus
de synchronisation du hachage de mot de passe pour Azure AD DS et Azure AD
Connect.
） Important

Connect n’est pas prise en charge dans un domaine managé pour resynchroniser
des objets sur Azure AD.
Forêts et approbations
Une forêt est une construction logique utilisée par Active Directory Domain Services (AD
DS) pour regrouper un ou plusieurs domaines. Les domaines stockent alors les objets
pour un utilisateur ou des groupes et fournissent des services d’authentification.
Dans Azure AD DS, la forêt ne contient qu’un seul domaine. Les forêts AD DS locales
contiennent souvent de nombreux domaines. Dans les grandes organisations, en
particulier après des fusions et acquisitions, vous pouvez vous retrouver avec plusieurs
forêts locales qui contiennent chacune plusieurs domaines.
Par défaut, un domaine managé est créé en tant que forêt d’utilisateurs. Ce type de forêt
synchronise tous les objets d’Azure AD, notamment les comptes d’utilisateur créés dans
un environnement AD DS local. Les comptes d’utilisateur peuvent directement
s’authentifier auprès du domaine managé, par exemple pour se connecter à une
machine virtuelle jointe à un domaine. Une forêt d’utilisateurs fonctionne lorsque les
hachages de mot de passe peuvent être synchronisés et que les utilisateurs n’utilisent
pas de méthode de connexion exclusive, comme l’authentification par carte à puce.
Dans une forêt Azure AD DS de ressources, les utilisateurs s’authentifient sur une forêt à
approbation unique à partir de leur AD DS local. Avec cette approche, les objets
utilisateur et les hachages de mot de passe ne sont pas synchronisés avec Azure AD DS.
Les objets utilisateur et les informations d’identification existent uniquement dans
l’instance AD DS locale. Cette approche permet aux entreprises d’héberger des
ressources et des plateformes d’application dans Azure qui dépendent de
l’authentification classique, par exemple LDAPS, Kerberos ou NTLM, en éliminant les
problèmes et craintes en matière d’authentification.
Références SKU Azure AD DS

Dans Azure AD DS, les performances et fonctionnalités disponibles sont basées sur la
référence SKU. Vous sélectionnez une référence SKU lorsque vous créez le domaine
managé et pouvez changer de références SKU au fil des besoins de votre entreprise, une
fois le domaine managé déployé. Le tableau suivant présente les références SKU
disponibles ainsi que leurs différences :
Nom de la référence (SKU) Nombre maximal d'objets Fréquence de sauvegarde
Standard Illimité Tous les 5 jours
Entreprise Illimité Tous les 3 jours
Premium Illimité Quotidien
Avant ces références SKU Azure AD DS, un modèle de facturation basé sur le nombre
d’objets (comptes d’utilisateurs et d’ordinateurs) dans le domaine managé était utilisé. Il
n’existe plus de tarification variable en fonction du nombre d’objets du domaine
managé.
Pour plus d’informations, consultez la page de tarification Azure AD DS .
Performances du domaine managé

Les performances du domaine varient selon la manière dont l’authentification est
implémentée pour une application. Des ressources de calcul supplémentaires peuvent
contribuer à améliorer le temps de réponse aux requêtes et réduire le délai des
opérations de synchronisation. Plus le niveau de référence SKU augmente, plus les
ressources de calcul disponibles pour le domaine managé augmentent aussi. Surveillez
les performances de vos applications et planifiez les ressources requises.
Si les besoins de votre entreprise ou de vos applications évoluent et qu'il vous faut une
puissance de calcul supplémentaire pour votre domaine managé, vous pouvez opter
pour une autre référence SKU.
Fréquence de sauvegarde
La fréquence de sauvegarde détermine la fréquence de prise d'un instantané du
domaine managé. Les sauvegardes relèvent d'un processus automatisé managé par la
plateforme Azure. En cas de problème lié à votre domaine managé, le support Azure
peut vous aider à procéder à une restauration à partir d'une sauvegarde. La
synchronisation étant unidirectionnelle depuis Azure AD, les problèmes survenant dans
un domaine managé n’ont pas d’impact sur Azure AD ou les environnements et
fonctionnalités AD DS locaux.
Plus le niveau de référence SKU augmente, plus la fréquence de ces instantanés de
sauvegarde augmente aussi. Examinez les besoins de votre entreprise et l’objectif de
point de récupération afin de déterminer la fréquence de sauvegarde requise pour votre
domaine managé. Si les besoins de votre entreprise ou de vos applications évoluent et
que vous avez besoin de sauvegardes plus fréquentes, vous pouvez opter pour une
autre référence SKU.
Étapes suivantes
Pour commencer, créons un domaine managé Azure AD DS.
Cas d’usage et scénarios courants pour
Article • 01/06/2023
managés, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et
l’authentification Kerberos/NTLM. Azure AD DS s’intègre à votre locataire Azure AD
existant, permettant ainsi aux utilisateurs de se connecter à l’aide de leurs informations
d’identification actuelles. Vous utilisez ces services de domaine sans avoir à déployer,
gérer et corriger des contrôleurs de domaine dans le cloud, ce qui permet un lift-and-
shift plus fluide des ressources locales sur Azure.
Cet article décrit quelques scénarios métier courants dans lesquels Azure AD DS offre de
la valeur et répond à ces besoins.
Méthodes courantes pour fournir des solutions

d’identité dans le cloud
Lorsque vous migrez des charges de travail existantes vers le cloud, les applications
prenant en charge les répertoires peuvent utiliser LDAP pour l’accès en lecture ou en
écriture à un répertoire AD DS local. Les applications s’exécutant sous Windows Server
sont généralement déployées sur des machines virtuelles jointes à un domaine, et
peuvent être gérées de façon sécurisée à l’aide de la stratégie de groupe. Pour
authentifier les utilisateurs finaux, les applications peuvent également s’appuyer sur
l’authentification intégrée de Windows, telle que l’authentification Kerberos ou NTLM.
Les administrateurs informatiques utilisent souvent l’une des solutions suivantes pour
fournir un service d’identité aux applications qui s’exécutent dans Azure :
Configurez une connexion VPN de site à site entre les charges de travail qui
s’exécutent dans Azure et un environnement AD DS local.
Les contrôleurs de domaine locaux fournissent ensuite l’authentification par le
biais de la connexion VPN.
Créez des contrôleurs de domaine de réplication à l’aide de machines virtuelles
Azure pour étendre le domaine ou la forêt AD DS à partir de l’environnement local.
Les contrôleurs de domaine qui s’exécutent sur des machines virtuelles Azure
assurent l’authentification et répliquent les informations d’annuaire à partir de
l’environnement AD DS local.
Déployez un environnement AD DS autonome dans Azure à l’aide de contrôleurs
de domaine qui s’exécutent sur des machines virtuelles Azure.
Les contrôleurs de domaine qui s’exécutent sur des machines virtuelles Azure
assurent l’authentification, mais aucune information d’annuaire n’est répliquée à
partir d’un environnement AD DS local.
Grâce à ces approches, les connexions VPN au répertoire local rendent les applications
vulnérables aux problèmes ou pannes réseau temporaires. Si vous déployez des
contrôleurs de domaine à l’aide de machines virtuelles dans Azure, l’équipe
informatique doit gérer les machines virtuelles, puis sécuriser, corriger, superviser,
sauvegarder et dépanner les contrôleurs de domaine.
Azure AD DS offre des alternatives à la nécessité de créer des connexions VPN dans un
environnement AD DS local ou d’exécuter et de gérer des machines virtuelles dans
Azure pour fournir des services d’identité. En tant que service managé, Azure AD DS
réduit la complexité de la création d’une solution d’identité intégrée pour les
environnements hybrides et cloud uniquement.
Comparer Azure AD DS avec Azure AD et AD DS automanagé sur des machines

virtuelles Azure ou en local
Azure AD DS pour les organisations hybrides

De nombreuses organisations exécutent une infrastructure hybride qui comprend des
charges de travail d’application cloud et locales. Les applications héritées migrées vers
Azure dans le cadre d’une stratégie lift-and-shift peuvent utiliser des connexions LDAP
traditionnelles pour fournir des informations d’identité. Pour prendre en charge cette
infrastructure hybride, les informations d’identité d’un environnement AD DS local
peuvent être synchronisées avec un locataire Azure AD. Azure AD DS peut ensuite
fournir ces applications héritées dans Azure avec une source d’identités, sans qu’il soit
nécessaire de configurer ni de gérer la connectivité des applications vers les services
d’annuaire locaux.
Examinons un exemple de Litware Corporation, une organisation hybride qui exécute

des ressources locales et Azure :
Les applications et charges de travail de serveurs nécessitant des services de
domaine sont déployées dans un réseau virtuel dans Azure.
Cela peut inclure des applications héritées migrées vers Azure dans le cadre
d’une stratégie lift-and-shift.
Afin de synchroniser les informations d’identité du répertoire local avec le locataire
Azure AD, la société Litware Corporation a déployé Azure AD Connect.
Les informations d’identité incluent les comptes d’utilisateurs et les
appartenances aux groupes.
L’équipe informatique de Litware active Azure AD DS pour son locataire Azure AD
dans ce réseau virtuel ou un réseau virtuel homologué.
Les applications et machines virtuelles déployées dans le réseau virtuel Azure
peuvent ensuite utiliser des fonctionnalités Azure AD DS telles que la jonction de
domaine, la lecture LDAP, la liaison LDAP, l’authentification NTLM et Kerberos et la
stratégie de groupe.
） Important

Azure AD DS pour les organisations cloud

uniquement
Un locataire cloud uniquement Azure AD ne dispose pas d’une source d’identité locale.
Par exemple, les comptes d’utilisateur et les appartenances aux groupes sont créés et
gérés directement dans Azure AD.
Examinons maintenant un exemple pour Contoso, une organisation cloud uniquement

qui utilise Azure AD pour l’identité. Toutes les identités des utilisateurs, leurs
informations d’identification et les appartenances aux groupes sont créées et gérées
dans Azure AD. Il n’existe aucune configuration supplémentaire d’Azure AD Connect
pour synchroniser des informations d’identité à partir d’un répertoire local.
Les applications et charges de travail de serveurs nécessitant des services de

domaine sont déployées dans un réseau virtuel dans Azure.
L’équipe informatique de Contoso active Azure AD DS pour son locataire Azure AD
dans ce réseau virtuel ou un réseau virtuel homologué.
Les applications et machines virtuelles déployées dans le réseau virtuel Azure
peuvent ensuite utiliser des fonctionnalités Azure AD DS telles que la jonction de
domaine, la lecture LDAP, la liaison LDAP, l’authentification NTLM et Kerberos et la
Administration sécurisée des machines

virtuelles Azure
Pour vous permettre d’utiliser un jeu unique d’informations d’identification AD, les
machines virtuelles Azure peuvent être jointes à un domaine managé par Azure AD DS.
Cette approche réduit les problèmes de gestion des informations d’identification,
comme la maintenance des comptes administrateurs locaux sur chaque machine
virtuelle ou des comptes et mots de passe distincts entre les environnements.
Les machines virtuelles jointes à un domaine managé peuvent également être
administrées et sécurisées à l’aide d’une stratégie de groupe. Les bases de référence de
sécurité exigées peuvent être appliquées aux machines virtuelles pour les verrouiller
conformément aux directives de sécurité de l’entreprise. Par exemple, vous pouvez
utiliser des fonctionnalités de gestion de stratégie de groupe pour restreindre les types
d’applications pouvant être exécutés sur ces machines virtuelles.
Intéressons-nous à un exemple de scénario courant. Les serveurs et d’autres

infrastructures arrivant en fin de vie, Contoso souhaite transférer de nombreuses
applications actuellement hébergées en local vers le cloud. La norme informatique
actuelle exige que les serveurs hébergeant les applications d’entreprise soient joints à
un domaine et gérés au moyen d’une stratégie de groupe.
L’administrateur informatique de Contoso préfère joindre à un domaine les machines

virtuelles déployées sur Azure pour en faciliter l’administration, car les utilisateurs
peuvent alors se connecter à l’aide de leurs informations d’identification d’entreprise.
Quand elles sont jointes à un domaine, les machines virtuelles peuvent aussi être
configurées pour se conformer aux bases de référence de sécurité exigées avec des
objets stratégie de groupe. Contoso préfère ne pas déployer, superviser et gérer ses
propres contrôleurs de domaine dans Azure.
Azure AD DS convient parfaitement à ce cas d’usage. Un domaine managé vous permet

de joindre des machines virtuelles à un domaine, d’utiliser un seul jeu d’informations
d’identification et d’appliquer une stratégie de groupe. Le domaine étant managé, vous
n’avez pas besoin de configurer et de gérer les contrôleurs de domaine vous-même.
Notes de déploiement
Les considérations de déploiement suivantes s’appliquent à cet exemple de cas d’usage :
Les domaines managés utilisent une seule structure d’unité d’organisation plate
par défaut. Toutes les machines virtuelles jointes à un domaine se trouvent dans
une seule unité d’organisation. Si vous le souhaitez, vous pouvez créer des unités
d’organisation personnalisées.
Azure AD DS utilise un objet de stratégie de groupe (GPO) intégré pour les
conteneurs d’utilisateurs et d’ordinateurs. Pour plus de contrôle, vous pouvez créer
des GPO personnalisés et les cibler vers des unités d’organisation personnalisées.
Azure AD DS prend en charge le schéma de l’objet de base de l’ordinateur AD.
Vous ne pouvez pas étendre le schéma de l’objet de l’ordinateur.
Lift-and-shift des applications locales qui

utilisent une authentification par liaison LDAP
Comme exemple de scénario, Contoso dispose d’une application locale achetée auprès
d’un éditeur de logiciels indépendant il y a de nombreuses années. L’application est
actuellement en mode de maintenance par l’éditeur et nécessite des modifications hors
de prix. Cette application possède un front-end web qui collecte les informations
d’identification de l’utilisateur à l’aide d’un formulaire web, puis authentifie les
utilisateurs en effectuant une liaison LDAP vers l’environnement AD DS local.
Contoso souhaite faire migrer cette application vers Azure. L’application doit continuer à
fonctionner en l’état, sans nécessiter de modifications. De plus, les utilisateurs doivent
être en mesure de s’authentifier à l’aide de leurs informations d’identification
d’entreprise existantes, sans formation supplémentaire. Les utilisateurs finaux doivent
clairement savoir où l’application s’exécute.
Pour ce scénario, Azure AD DS permet aux applications d’effectuer des liaisons LDAP
dans le cadre du processus d’authentification. Les applications locales héritées peuvent
être faire l’objet d’un lift-and-shift vers Azure et continuer à authentifier en toute
transparence les utilisateurs sans avoir besoin d’apporter des modifications à leur
configuration ou expérience utilisateur.
Assurez-vous que l’application n’a pas besoin de modifier/d’écrire dans l’annuaire.

L’accès en écriture LDAP à un domaine managé n’est pas pris en charge.
Vous ne pouvez pas modifier les mots de passe directement sur un domaine
managé. Les utilisateurs finaux peuvent modifier leur mot de passe soit à l’aide du
mécanisme de modification de mot de passe en libre-service Azure AD, soit depuis
le répertoire local. Ces modifications sont automatiquement synchronisées et
disponibles dans le domaine managé.
Lift-and-shift des applications locales qui

utilisent une lecture LDAP pour accéder à
l’annuaire
Comme dans l’exemple de scénario précédent, supposons que Contoso a une
application métier locale développée il y a presque une décennie. Cette application
prend en charge les annuaires et a été conçue pour utiliser le protocole LDAP pour lire
les informations/attributs des utilisateurs à partir d’AD DS. L’application ne modifie pas
les attributs et n’écrit pas dans l’annuaire.
Contoso souhaite migrer cette application vers Azure et mettre hors-service l’ancien
matériel local qui l’héberge actuellement. L’application ne peut pas être réécrite pour
utiliser des API d’annuaire modernes comme l’API Microsoft Graph basée sur REST. Une
option lift-and-shift est nécessaire pour migrer l’application afin qu’elle s’exécute dans
le cloud, sans modification de code ni réécriture de l’application.
Pour faciliter ce scénario, Azure AD DS permet aux applications d’effectuer des lectures
LDAP depuis le domaine managé afin d’obtenir les informations d’attribut nécessaires.
L’application n’a pas besoin d’être réécrite, si bien qu’un lift-and-shift sur Azure permet
aux utilisateurs de continuer à l’utiliser sans même qu’ils ne se rendent compte que son
emplacement d’exécution a changé.
Assurez-vous que l’application n’a pas besoin de modifier/d’écrire dans l’annuaire.

L’accès en écriture LDAP à un domaine managé n’est pas pris en charge.
Vérifiez que l’application ne nécessite pas un schéma Active Directory
étendu/personnalisé. Les extensions de schéma ne sont pas prises en charge dans
Azure AD DS.
Migrer une application de service ou démon

locale vers Azure
Certaines applications incluent plusieurs niveaux, dont l’un doit effectuer des appels
authentifiés à un niveau back-end, tel qu’une base de données. Les comptes de service
Active Directory sont couramment utilisés dans ces scénarios. Lorsque vous effectuez un
lift-and-shift d’une application vers Azure, Azure AD DS vous permet de continuer à
utiliser des comptes de service de la même façon. Vous pouvez choisir d’utiliser le même
compte de service que celui synchronisé à partir de votre annuaire local sur Azure AD ou
de créer une unité d’organisation personnalisée, puis de créer un compte de service
distinct dans cette unité d’organisation. Quelle que soit l’approche, les applications
continuent de fonctionner de la même façon pour effectuer des appels authentifiés à
d’autres niveaux et services.
Dans cet exemple de scénario, Contoso est équipé d’une application de coffre de
logiciel personnalisée qui inclut un front-end web, un serveur SQL et un serveur FTP
back-end. L’authentification intégrée de Windows qui utilise des comptes de service
authentifie le font-end web auprès du serveur FTP. Le serveur web frontal est configuré
pour fonctionner comme un compte de service. Le serveur principal est configuré pour
autoriser l’accès depuis le compte de service pour le serveur web frontal. Contoso ne
souhaite pas déployer et gérer ses propres machines virtuelles contrôleurs de domaine
dans le cloud pour déplacer cette application sur Azure.
Pour ce scénario, les serveurs qui hébergent le front-end web, le serveur SQL et le
serveur FTP peuvent être migrés vers des machines virtuelles Azure et joints à un
domaine managé. Les machines virtuelles peuvent alors utiliser le même compte de
service dans leur annuaire local pour les besoins d’authentification de l’application,
lequel est synchronisé par le biais d’Azure AD à l’aide d’Azure AD Connect.
Vérifiez que les applications utilisent un nom d’utilisateur et un mot de passe pour
l’authentification. L’authentification basée sur un certificat ou une carte à puce
n’est pas prise en charge par Azure AD DS.
Vous ne pouvez pas modifier les mots de passe directement sur un domaine
managé. Les utilisateurs finaux peuvent modifier leur mot de passe soit à l’aide du
mécanisme de modification de mot de passe en libre-service Azure AD, soit depuis
le répertoire local. Ces modifications sont automatiquement synchronisées et
disponibles dans le domaine managé.
Déploiements des services Bureau à distance

Windows Server dans Azure
Vous pouvez utiliser Azure AD DS pour fournir des services de domaine managés à vos
serveurs Bureau à distance déployés sur Azure.
Pour plus d’informations sur ce scénario de déploiement, consultez le guide pratique

pour intégrer Azure AD Domain Services à votre déploiement RDS.
Clusters HDInsight joints à un domaine

Vous pouvez configurer un cluster Azure HDInsight qui est joint à un domaine managé
avec Apache Ranger activé. Vous pouvez créer et appliquer des stratégies Hive par le
biais d’Apache Ranger et autoriser des utilisateurs, comme des scientifiques des
données, à se connecter à Hive à l’aide d’outils ODBC, comme Excel ou Tableau. Nous
poursuivons nos efforts pour ajouter d’autres charges de travail, comme HBase, Spark et
Storm à HDInsight joint à un domaine.
Pour plus d’informations sur ce scénario de déploiement, consultez le guide pratique

pour configurer des clusters HDInsight joints à un domaine.
Étapes suivantes
Pour bien démarrer, vous devez Créer et configurer un domaine managé Azure Active
Directory Domain Services.
Concepts et fonctionnalités des jeux de
réplicas pour Azure Active Directory
Domain Services
Article • 01/06/2023
Lorsque vous créez un domaine managé Azure Active Directory Domain Services (Azure
AD DS), vous définissez un espace de noms unique. Cet espace de noms est le nom de
domaine, par exemple aaddscontoso.com. Deux contrôleurs de domaine sont ensuite
déployés dans la région Azure sélectionnée. Ce déploiement de contrôleurs de domaine
est appelé jeu de réplicas.
Vous pouvez étendre un domaine managé pour avoir plusieurs jeux de réplicas par
locataire Azure AD. Les jeux de réplicas peuvent être ajoutés à n’importe quel réseau
virtuel appairé dans toute région Azure prenant en charge Azure AD DS. D’autres jeux
de réplicas dans des régions Azure différentes assurent la récupération d’urgence
géographique pour les applications héritées si une région Azure est mise hors
connexion.
７ Notes
Les jeux de réplicas ne vous permettent pas de déployer plusieurs domaines

managés uniques dans un seul locataire Azure. Chaque jeu de réplicas contient les
mêmes données.
Fonctionnement des jeux de réplicas

Quand vous créez un domaine managé, tel que aaddscontoso.com, un jeu de réplicas
initial est créé. Les jeux de réplicas supplémentaires partagent le même espace de noms
et la même configuration. Les modifications apportées à Azure AD DS, notamment en ce
qui concerne la configuration, l’identité de l’utilisateur et les informations
d’identification, les groupes, les objets de stratégie de groupe, les objets ordinateur et
autres modifications, sont appliquées à tous les jeux de réplicas du domaine managé via
la réplication AD DS.
Vous créez chaque jeu de réplicas dans un réseau virtuel. Chaque réseau virtuel doit être
appairé à tous les autres réseaux virtuels qui hébergent le jeu de réplicas d’un domaine
managé. Cette configuration crée une topologie de réseau maillé qui prend en charge la
réplication de répertoire. Un réseau virtuel peut prendre en charge plusieurs jeux de
réplicas, à condition que chaque jeu de réplicas soit dans un sous-réseau virtuel
différent.
Tous les jeux de réplicas sont placés dans le même site Active Directory. Par conséquent,
toutes les modifications sont propagées à l’aide de la réplication intrasite pour une
convergence rapide.
７ Notes
Il n’est pas possible de définir des sites distincts ni de définir des paramètres de
réplication entre des jeux de réplicas.
Le diagramme suivant montre un domaine managé avec deux jeux de réplicas. Le

premier jeu de réplicas est créé avec l’espace de noms du domaine. Un deuxième jeu de
réplicas est créé après cela :
７ Notes
Les jeux de réplicas garantissent la disponibilité des services d’authentification dans
les régions où un jeu de réplicas est configuré. Pour qu’une application ait une
redondance géographique en cas de panne régionale, la plateforme d’application
qui s’appuie sur le domaine managé doit également résider dans l’autre région.
La résilience des autres services requis pour que l’application fonctionne, comme
Machines virtuelles Azure ou Azure App Service, n’est pas fournie par les jeux de
réplicas. La conception de la disponibilité d’autres composants d’application doit
tenir compte des caractéristiques de résilience des services qui composent
l’application.
L’exemple suivant montre un domaine managé avec trois jeux de réplicas afin de
renforcer la résilience et de garantir la disponibilité des services d’authentification. Dans
les deux exemples, les charges de travail des applications se trouvent dans la même
région que le jeu de réplicas du domaine managé :
Points à prendre en considération pour le
déploiement
Le niveau tarifaire par défaut pour un domaine managé est le SKU Entreprise, qui prend
en charge plusieurs jeux de réplicas. Pour créer des jeux de réplicas supplémentaires si
vous êtes passé au niveau tarifaire Standard, mettez à niveau le domaine managé vers
Entreprise ou Premium.
Le nombre maximal de jeux de réplicas pris en charge est de cinq, y compris le premier
réplica créé lors de la création du domaine managé.
La facturation de chaque jeu de réplicas est basée sur le niveau tarifaire de la
configuration du domaine. Par exemple, si vous avez un domaine managé qui utilise le
niveau tarifaire Entreprise et que vous avez trois jeux de réplicas, votre abonnement est
facturé à l’heure pour chacun des trois jeux de réplicas.
Forum aux questions
Puis-je créer un jeu de réplicas dans un abonnement

différent de celui de mon domaine managé ?
Non. Les jeux de réplicas doivent se trouver dans le même abonnement que le domaine
managé.
Combien de jeux de réplicas puis-je créer ?

Vous pouvez créer un maximum de cinq jeux de réplicas : le jeu de réplicas initial pour le
domaine managé, plus quatre jeux de réplicas supplémentaires.
Comment les informations d’utilisateur et de groupe

sont-elles synchronisées avec mes jeux de réplicas ?
Tous les jeux de réplicas sont connectés les uns aux autres à l’aide d’un appairage de
réseaux virtuels maillés. Un jeu de réplicas reçoit les mises à jour des utilisateurs et des
groupes d’Azure AD. Ces modifications sont ensuite répliquées sur les autres jeux de
réplicas à l’aide de la réplication AD DS intrasite sur le réseau appairé.
À l’instar de l’instance AD DS locale, un état déconnecté prolongé peut entraîner une
interruption de la réplication. Les réseaux virtuels appairés n’étant pas transitifs, les
exigences de conception pour les jeux de réplicas nécessitent une topologie réseau
entièrement maillée.
Comment apporter des modifications à mon domaine

managé après la création des jeux de réplicas ?
Les modifications au sein du domaine managé fonctionnent comme auparavant. Vous
créez et utilisez une machine virtuelle de gestion, avec ses outils RSAT, qui est jointe au
domaine managé. Vous pouvez joindre autant de machines virtuelles de gestion au
domaine managé que vous le souhaitez.
Étapes suivantes
Pour commencer à utiliser des jeux de réplicas, créez et configurez un domaine managé
Azure AD DS. Une fois le domaine déployé, créez et utilisez des jeux de réplicas
supplémentaires.
Fonctionnement des relations
d’approbation pour les forêts dans
Active Directory
Article • 12/04/2023
Active Directory Domain Services (AD DS) assure la sécurité sur plusieurs domaines ou
forêts par l’intermédiaire de relations d’approbation de domaine et de forêt. Pour que
l’authentification puisse s’effectuer entre les approbations, Windows doit d’abord
vérifier que le domaine demandé par un utilisateur, un ordinateur ou un service dispose
d’une relation d’approbation avec le domaine du compte demandeur.
Pour vérifier cette relation d’approbation, le système de sécurité de Windows calcule un

chemin d’approbation entre le contrôleur de domaine du serveur qui reçoit la demande
et un contrôleur de domaine dans le domaine du compte demandeur.
Les mécanismes de contrôle d’accès fournis par AD DS et le modèle de sécurité

distribué de Windows fournissent un environnement pour le fonctionnement des
approbations de domaine et de forêt. Afin que ces approbations fonctionnent
correctement, chaque ressource ou ordinateur doit être doté d’un chemin d’approbation
direct vers un contrôleur de domaine dans le domaine où il se trouve.
Le chemin d’approbation est implémenté par le service Net Logon, au moyen d’une
connexion authentifiée d’appel de procédure distante (RPC) à l’autorité de domaine
approuvé. Un canal sécurisé s’étend également à d’autres domaines AD DS par le biais
de relations d’approbation entre domaines. Ce canal sécurisé est utilisé pour obtenir et
vérifier des informations de sécurité, entre autres les identificateurs de sécurité (SID)
pour les utilisateurs et les groupes.
７ Notes
Azure AD DS prend en charge uniquement les approbations transitives

unidirectionnelles où le domaine managé approuve d’autres domaines. Aucun
autre sens ou type d’approbation n’est pris en charge.
Pour une vue d’ensemble de la manière dont les approbations s’appliquent à Azure
AD DS, consultez Concepts et fonctionnalités de la forêt.
Pour commencer à utiliser des approbations dans Azure AD DS, créez un domaine
managé qui utilise des approbations de forêt.
Flux des relations d’approbation
Le flux des communications sécurisées sur les approbations conditionne l’élasticité
d’une approbation. La façon dont vous créez ou configurez une approbation détermine
l’étendue de la communication à l’intérieur d’une forêt, ou entre les forêts.
Le flux de la communication sur les approbations est déterminé par le sens de

l’approbation. Les approbations peuvent être unidirectionnelles ou bidirectionnelles,
transitives ou non transitives.
Le schéma suivant montre que tous les domaines de l’arborescence 1 et de

l’arborescence 2 présentent des relations d’approbation transitive par défaut. Ainsi, les
utilisateurs de l’arborescence 1 peuvent accéder aux ressources des domaines de
l’arborescence 2, et les utilisateurs de l’arborescence 2 peuvent accéder aux ressources de
l’arborescence 1, lorsque les autorisations appropriées sont affectées au niveau de la
ressource.
Approbations unidirectionnelles et bidirectionnelles

Les relations d’approbation permettant l’accès aux ressources peuvent être
unidirectionnelles ou bidirectionnelles.
Une approbation unidirectionnelle est un chemin d’authentification à sens unique, créé
entre deux domaines. Dans une approbation unidirectionnelle entre le domaine A et le
domaine B, les utilisateurs du domaine A peuvent accéder aux ressources du domaine B.
En revanche, les utilisateurs du domaine B ne peuvent pas accéder aux ressources du
domaine A.
Certaines approbations unidirectionnelles peuvent être non transitives ou transitives,

selon le type d’approbation créé.
Dans une approbation bidirectionnelle, le domaine A approuve le domaine B, et le

domaine B approuve le domaine A. Cette configuration signifie que les demandes
d’authentification peuvent être transmises entre les deux domaines, dans les deux sens.
Certaines relations bidirectionnelles peuvent être non transitives ou transitives, selon le
type d’approbation créé.
Toutes les approbations de domaine dans une forêt AD DS sont des approbations
transitives bidirectionnelles. Lorsqu’un domaine enfant est créé, une approbation
transitive bidirectionnelle est automatiquement créée entre le nouveau domaine enfant
et le domaine parent.
Approbations transitives et non transitives

La transitivité détermine si une approbation peut être étendue en dehors des deux
domaines avec lesquels elle a été formée.
Une approbation transitive peut être utilisée pour étendre les relations
d’approbation à d’autres domaines.
Une approbation non transitive peut être utilisée pour refuser des relations
d’approbation à d’autres domaines.
Chaque fois que vous créez un domaine dans une forêt, une relation d’approbation
transitive bidirectionnelle est automatiquement créée entre le nouveau domaine et son
domaine parent. Si des domaines enfants sont ajoutés au nouveau domaine, le chemin
d’approbation remonte la hiérarchie de domaine, étendant le chemin d’approbation
initial créé entre le nouveau domaine et son domaine parent. Les relations
d’approbation transitive remontent dans une arborescence de domaine au fur et à
mesure qu’elle se forme, créant ainsi des approbations transitives entre tous les
domaines de l’arborescence de domaine.
Les demandes d’authentification suivent ces chemins d’approbation, si bien que les
comptes de n’importe quel domaine de la forêt peuvent être authentifiés par n’importe
quel autre domaine de la forêt. Avec un processus d’authentification unique, les
comptes disposant des autorisations appropriées peuvent accéder aux ressources de
n’importe quel domaine de la forêt.
Approbations de forêts
Les approbations de forêt vous aident à gérer les infrastructures AD DS segmentées, et à
prendre en charge l’accès aux ressources et à d’autres objets dans plusieurs forêts. Les
approbations de forêt sont utiles pour les fournisseurs de services, les sociétés
expérimentant fusions ou acquisitions, les extranets collaboratifs d’entreprise et les
sociétés cherchant une solution d’autonomie administrative.
En vous appuyant sur les approbations de forêt, vous pouvez lier deux forêts différentes
pour former une relation d’approbation transitive unidirectionnelle ou bidirectionnelle.
Une approbation de forêt permet aux administrateurs de connecter deux forêts AD DS
au moyen d’une seule relation d’approbation, pour fournir une expérience
d’authentification et d’autorisation transparente dans les forêts.
Une approbation de forêt peut uniquement être créée entre un domaine racine de forêt
dans une forêt et un domaine racine de forêt dans une autre forêt. Il n’est possible de
créer des approbations de forêt qu’entre deux forêts, et celles-ci ne peuvent pas être
étendues implicitement à une troisième forêt. Ce comportement signifie que si une
approbation de forêt est créée entre la forêt 1 et la forêt 2, et qu’une autre approbation
de forêt est créée entre la forêt 2 et la forêt 3, la forêt 1 n’entretient aucune relation
d’approbation implicite avec la forêt 3.
Le schéma suivant illustre deux relations d’approbation de forêt distinctes entre trois
forêts AD DS d’une même organisation.
Cet exemple de configuration fournit l’accès suivant :
Les utilisateurs de la forêt 2 peuvent accéder aux ressources de n’importe quel

domaine de la forêt 1 ou de la forêt 3
domaine de la forêt 2
domaine de la forêt 2
Cette configuration n’autorise pas les utilisateurs de la forêt 1 à accéder aux ressources
de la forêt 3, ou inversement. Pour permettre aux utilisateurs de la forêt 1 et de la forêt 3
de partager des ressources, vous devez créer une approbation transitive bidirectionnelle
entre ces deux forêts.
Si une approbation de forêt unidirectionnelle est créée entre deux forêts, les membres
de la forêt approuvée peuvent utiliser les ressources situées dans la forêt d’approbation.
Par contre, l’approbation ne fonctionne que dans un seul sens.
Par exemple, lorsqu’une approbation de forêt unidirectionnelle est créée entre la forêt 1
(la forêt approuvée) et la forêt 2 (la forêt d’approbation) :
Les membres de la forêt 1 peuvent accéder aux ressources situées dans la forêt 2.
Les membres de la forêt 2 ne peuvent pas accéder aux ressources situées dans la
forêt 1 au moyen de la même approbation.
） Important
Azure AD Domain Services ne prend en charge qu’une approbation de forêt

unidirectionnelle vers un environnement Active Directory local.
Conditions de l’approbation de forêt

Avant de pouvoir créer une approbation de forêt, vous devez vérifier que vous disposez
de l’infrastructure DNS (Domain Name System) appropriée. Les approbations de forêt ne
peuvent être créées que si l’une des configurations DNS suivantes est disponible :
Un serveur DNS racine unique est le serveur DNS racine pour les deux espaces de
noms DNS de forêt : la zone racine contient les délégations de chaque espace de
noms DNS, et les indications de racine de tous les serveurs DNS incluent le serveur
DNS racine.
En l’absence de serveur DNS racine partagé, les serveurs DNS racines de chaque
espace de noms DNS de forêt utilisent des redirecteurs conditionnels DNS, afin
que chaque espace de noms DNS route les requêtes de noms dans l’autre espace
de noms.
） Important
Toute forêt Azure AD Domain Services avec une approbation doit utiliser cette
configuration DNS. L’hébergement d’un espace de noms DNS autre que
l’espace de noms DNS de la forêt n’est pas une fonctionnalité d’Azure AD
Domain Services. L’utilisation de redirecteurs conditionnels constitue la
configuration appropriée.
En l’absence de serveur DNS racine partagé, les serveurs DNS racines de chaque
espace de noms DNS de forêt utilisent des zones secondaires DNS, configurées
dans chaque espace de noms DNS pour router les requêtes de noms dans l’autre
espace de noms.
Pour créer une approbation de forêt, vous devez être membre du groupe Admins du
domaine (dans le domaine racine de la forêt), ou du groupe Administrateurs de
l’entreprise dans Active Directory. Chaque approbation se voit attribuer un mot de passe
que les administrateurs des deux forêts doivent connaître. Les membres administrateurs
de l’entreprise dans les deux forêts peuvent créer les approbations dans les deux forêts
à la fois et, dans ce scénario, un mot de passe aléatoire par chiffrement est généré et
écrit automatiquement pour les deux forêts.
Une forêt de domaine managé prend en charge jusqu’à cinq approbations de forêt
sortante unidirectionnelle vers des forêts locales. L’approbation de forêt sortante pour
Azure AD Domain Services est créée dans le portail Azure. Vous ne créez pas
l’approbation manuellement avec le domaine managé proprement dit. L’approbation de
forêt entrante doit être configurée par un utilisateur disposant des privilèges
précédemment indiqués dans l’instance Active Directory locale.
Interactions et processus d’approbation

De nombreuses transactions inter-domaines et inter-forêts dépendent des approbations
de domaine ou de forêt pour effectuer diverses tâches. Cette section décrit les
processus et les interactions qui se produisent lorsque des ressources sont accessibles
dans les approbations et que les références d’authentification sont évaluées.
Vue d’ensemble du traitement de la référence

d’authentification
Lorsqu’une demande d’authentification est référencée dans un domaine, le contrôleur
de domaine de ce domaine doit déterminer si une relation d’approbation existe avec le
domaine à partir duquel la demande est envoyée. Le sens de l’approbation et son type,
transitif ou non transitif, doivent également être déterminés avant d’authentifier
l’utilisateur pour l’accès aux ressources du domaine. Le processus d’authentification qui
se produit entre des domaines approuvés varie en fonction du protocole
d’authentification utilisé. Les protocoles Kerberos V5 et NTLM traitent différemment les
références de l’authentification sur un domaine.
Traitement de la référence Kerberos V5

Le protocole d’authentification Kerberos V5 dépend du service Net Logon sur les
contrôleurs de domaine pour les informations d’authentification et d’autorisation du
client. Le protocole Kerberos se connecte à un centre de distribution de clés (KDC) en
ligne, et au magasin de comptes Active Directory pour les tickets de session.
Le protocole Kerberos utilise également des approbations pour les services d’accord de
tickets (TGS) inter-domaines, et pour valider des certificats PAC (Privilege Attribute
Certificate) sur un canal sécurisé. Le protocole Kerberos procède à une authentification
inter-domaine uniquement auprès des domaines Kerberos dotés de systèmes
d’exploitation non Windows, tels qu’un domaine Kerberos MIT ; il n’a pas besoin
d’interagir avec le service Net Logon.
Si le client utilise Kerberos V5 pour l’authentification, il demande un ticket au serveur

dans le domaine cible, à partir d’un contrôleur de domaine dans son domaine de
compte. Le KDC Kerberos agit comme intermédiaire approuvé entre le client et le
serveur, et fournit une clé de session qui permet aux deux parties de s’authentifier
mutuellement. Si le domaine cible est différent du domaine actuel, le KDC suit un
processus logique permettant de déterminer si une demande d’authentification peut
être référencée :
1. Le domaine actuel est-il approuvé directement par le domaine du serveur qui est
demandé ?
Si c’est le cas, envoyez au client une référence au domaine demandé.

Sinon, passez à l’étape suivante.
2. Existe-t-il une relation d’approbation transitive entre le domaine actuel et le

prochain domaine sur le chemin d’approbation ?
Si c’est le cas, envoyez au client une référence au prochain domaine sur le

chemin d’approbation.
Sinon, envoyez un message d’authentification refusée au client.
Traitement de la référence NTLM

Le protocole d’authentification NTLM dépend du service Net Logon sur les contrôleurs
de domaine pour les informations d’authentification et d’autorisation du client. Ce
protocole authentifie les clients qui n’utilisent pas l’authentification Kerberos. NTLM
utilise des approbations pour passer les demandes d’authentification entre les
domaines.
Si le client utilise NTLM pour l’authentification, la demande initiale d’authentification est

directement envoyée, du client au serveur de ressources dans le domaine cible. Ce
serveur crée un défi auquel le client répond. Le serveur envoie ensuite la réponse de
l’utilisateur à un contrôleur de domaine dans son domaine de comptes d’ordinateur. Ce
contrôleur de domaine vérifie le compte d’utilisateur par rapport à sa base de données
de comptes de sécurité.
Si le compte n’existe pas dans la base de données, le contrôleur de domaine détermine

s’il faut procéder à l’authentification directe, transférer la demande ou la refuser à l’aide
de la logique suivante :
1. Le domaine actuel a-t-il une relation d’approbation directe avec le domaine de

l’utilisateur ?
Si c’est le cas, le contrôleur de domaine envoie les informations

d’identification du client à un contrôleur de domaine dans le domaine de
l’utilisateur pour l’authentification directe.
Sinon, passez à l’étape suivante.
2. Le domaine actuel a-t-il une relation d’approbation transitive avec le domaine de

l’utilisateur ?
Si c’est le cas, transmettez la demande d’authentification au domaine suivant

dans le chemin d’approbation. Ce contrôleur de domaine répète le processus
en vérifiant les informations d’identification de l’utilisateur par rapport à sa
propre base de données de comptes de sécurité.
Sinon, envoyez un message de connexion refusée au client.
Traitement Kerberos des demandes d’authentification sur

les approbations de forêt
Lorsque deux forêts sont connectées par une approbation de forêt, les demandes
d’authentification effectuées à l’aide des protocoles NTLM ou Kerberos V5 peuvent être
acheminées entre les forêts pour fournir un accès aux ressources dans les deux forêts.
Lorsqu’une approbation de forêt est établie pour la première fois, chaque forêt collecte
tous les espaces de noms approuvés dans sa forêt partenaire, et stocke les informations
dans un objet domaine approuvé. Les espaces de noms approuvés incluent les noms
d’arborescence de domaine, les suffixes de nom d’utilisateur principal (UPN), les suffixes
de nom de principal du service (SPN) et les espaces de noms d’ID de sécurité (SID)
utilisés dans l’autre forêt. Les objets domaine approuvé (TDO) sont répliqués dans le
catalogue global.
７ Notes
Les autres suffixes UPN sur les approbations ne sont pas pris en charge. Si un
domaine local utilise le même suffixe UPN qu’Azure AD DS, la connexion doit
utiliser sAMAccountName.
Avant que les protocoles d’authentification puissent suivre le chemin d’approbation de

la forêt, le nom de principal du service (SPN) de l’ordinateur de la ressource doit être
résolu en un emplacement dans l’autre forêt. Un principal du service peut porter l’un des
noms suivants :
le nom DNS d’un hôte ;

le nom DNS d’un domaine ;
le nom unique d’un objet point de connexion de service.
Quand une station de travail dans une forêt tente d’accéder à des données sur un
ordinateur de ressource dans une autre forêt, le processus d’authentification Kerberos
contacte le contrôleur de domaine pour obtenir un ticket de service vers le SPN de
l’ordinateur de la ressource. Une fois que le contrôleur de domaine a interrogé le
catalogue global et déterminé que le SPN n’est pas dans la même forêt que le
contrôleur de domaine, le contrôleur de domaine renvoie une référence pour son
domaine parent à la station de travail. À ce stade, la station de travail interroge le
domaine parent pour obtenir le ticket de service, et continue de suivre la chaîne de
référence jusqu’à atteindre le domaine dans lequel se trouve la ressource.
Le schéma et les étapes ci-dessous fournissent une description détaillée du processus

d’authentification Kerberos qui est utilisé lorsque des ordinateurs exécutant Windows
essaient d’accéder aux ressources depuis un ordinateur situé dans une autre forêt.
1. Utilisateur1 s’authentifie sur StationDeTravail1 à l’aide des informations
d’identification depuis le domaine europe.tailspintoys.com. L’utilisateur tente
ensuite d’accéder à une ressource partagée sur le ServeurDeFichiers1 situé dans la
forêt usa.wingtiptoys.com.
2. La StationDeTravail1 contacte le KDC Kerberos sur un contrôleur de domaine de

son domaine, le CDEnfant1, et demande un ticket de service pour obtenir le SPN
du ServeurDeFichiers1.
3. Le CDEnfant1 ne trouve pas le SPN dans sa base de données de domaine et

interroge le catalogue global pour voir si des domaines de la forêt tailspintoys.com
contiennent ce SPN. Étant donné qu’un catalogue global est limité à sa propre
forêt, le SPN est introuvable.
Le catalogue global consulte ensuite sa base de données pour obtenir des

informations sur les approbations de forêt établies avec sa forêt. S’il en trouve, il
compare les suffixes de nom figurant dans l’objet TDO de l’approbation de forêt
au suffixe du SPN cible pour trouver une correspondance. Lorsqu’une
correspondance est trouvée, le catalogue global retourne une indication de
routage au CDEnfant1.
Les indications de routage permettent de diriger les demandes d’authentification

vers la forêt de destination. Les indications sont utilisées uniquement lorsque tous
les canaux d’authentification classiques, tels que le contrôleur de domaine local,
puis le catalogue global, ne parviennent pas à localiser un SPN.
4. Le CDEnfant1 renvoie une référence pour son domaine parent à la
StationDeTravail1.
5. La StationDeTravail1 contacte un contrôleur de domaine dans le CDRacineDeForêt1

(son domaine parent) pour obtenir une référence à un contrôleur de domaine
(CDRacineDeForêt2) dans le domaine racine de forêt de la forêt wingtiptoys.com.
6. La StationDeTravail1 contacte le CDRacineDeForêt2 dans la forêt wingtiptoys.com

pour obtenir un ticket de service vers le service demandé.
7. Le CDRacineDeForêt2 contacte son catalogue global à la recherche du SPN ; le

catalogue global trouve une correspondance pour le SPN et la renvoie au
CDRacineDeForêt2.
8. Le CDRacineDeForêt2 retourne ensuite la référence vers usa.wingtiptoys.com à la

StationDeTravail1.
9. La StationDeTravail1 contacte le KDC sur le CDEnfant2 et négocie le ticket pour

que l’Utilisateur1 puisse accéder au ServeurDeFichiers1.
10. Une fois que la StationDeTravail1 dispose d’un ticket de service, elle envoie ce
ticket de service au ServeurDeFichiers1 qui lit les informations d’identification de
sécurité de l’Utilisateur1 et élabore un jeton d’accès en conséquence.
Objet domaine approuvé

Chaque approbation de domaine ou de forêt au sein d’une organisation est représentée
par un objet domaine approuvé (TDO) stocké dans le conteneur Système au sein de son
domaine.
Contenu TDO
Les informations contenues dans un objet TDO varient selon que cet objet a été créé par
une approbation de domaine ou par une approbation de forêt.
Lors de la création d’une approbation de domaine, des attributs, tels que le nom de
domaine DNS, le SID de domaine, le type d’approbation, la transitivité de l’approbation
et le nom de domaine réciproque sont représentés dans l’objet TDO. Les objets TDO
d’approbation de forêt stockent des attributs supplémentaires pour identifier tous les
espaces de noms approuvés à partir de la forêt partenaire. Ces attributs incluent les
noms d’arborescence de domaine, les suffixes de nom d’utilisateur principal (UPN), les
suffixes de nom de principal du service (SPN) et les espaces de noms d’ID de sécurité
(SID).
Étant donné que les approbations sont stockées dans Active Directory sous la forme
d’objets TDO, tous les domaines d’une forêt ont connaissance des relations
d’approbation en place dans l’ensemble de la forêt. De même, lorsque deux ou plusieurs
forêts sont jointes par l’intermédiaire d’approbations de forêt, les domaines racines de
forêt dans chaque forêt ont connaissance des relations d’approbation qui sont en place
dans tous les domaines des forêts approuvées.
Modification du mot de passe TDO

Les deux domaines d’une relation d’approbation partagent un mot de passe, celui-ci est
stocké dans l’objet TDO, dans Active Directory. Dans le cadre du processus de
maintenance des comptes, tous les 30 jours, le contrôleur du domaine d’approbation
modifie le mot de passe stocké dans l’objet TDO. Dans la mesure où toutes les
approbations bidirectionnelles sont en fait deux approbations unidirectionnelles allant
dans des directions opposées, le processus se produit deux fois pour les approbations
bidirectionnelles.
Une approbation comprend une partie d’approbation et une partie approuvée. Dans la
partie approuvée, tout contrôleur de domaine accessible en écriture peut être utilisé
pour le processus. Dans la partie d’approbation, l’émulateur de contrôleur de domaine
principal procède à la modification du mot de passe.
Pour modifier un mot de passe, les contrôleurs de domaine suivent le processus décrit

ici :
1. L’émulateur de contrôleur de domaine principal dans le domaine d’approbation

crée un nouveau mot de passe. Un contrôleur de domaine dans le domaine
approuvé ne lance jamais la modification du mot de passe. Elle est toujours initiée
par l’émulateur de contrôleur de domaine principal du domaine d’approbation.

définit le champ OldPassword de l’objet TDO sur le champ NewPassword actuel.

affecte le nouveau mot de passe au champ NewPassword de l’objet TDO. En
conservant une copie du mot de passe précédent, vous pouvez revenir à l’ancien
mot de passe si jamais le contrôleur de domaine du domaine approuvé ne parvient
pas à recevoir la modification, ou si la modification n’est pas répliquée avant
qu’une demande utilisant le nouveau mot de passe d’approbation soit effectuée.

effectue un appel distant à un contrôleur de domaine dans le domaine approuvé,
afin de lui demander de définir le mot de passe du compte d’approbation sur le
nouveau mot de passe.
5. Le contrôleur de domaine dans le domaine approuvé remplace le mot de passe

d’approbation par le nouveau mot de passe.
6. Dans chaque partie de l’approbation, les mises à jour sont répliquées sur les autres
contrôleurs de domaine dans le domaine. Dans le domaine d’approbation, la
modification déclenche une réplication urgente de l’objet domaine approuvé.
Le mot de passe est désormais modifié sur les deux contrôleurs de domaine. La
réplication normale distribue les objets TDO aux autres contrôleurs de domaine dans le
domaine. Toutefois, il est possible que le contrôleur de domaine dans le domaine
d’approbation modifie le mot de passe sans parvenir à correctement mettre à jour un
contrôleur de domaine dans le domaine approuvé. Ce scénario peut se produire à cause
d’un canal sécurisé, exigé dans le processus de modification du mot de passe, et qui n’a
pas pu être établi. Il est également possible que le contrôleur de domaine dans le
domaine approuvé ne soit pas disponible à un moment donné dans le processus, et
qu’il ne reçoive pas le mot de passe mis à jour.
Pour gérer les situations dans lesquelles la modification du mot de passe n’est pas
convenablement communiquée, le contrôleur de domaine dans le domaine
d’approbation ne modifie jamais le nouveau mot de passe, sauf s’il a été dûment
authentifié (configuration d’un canal sécurisé) à l’aide du nouveau mot de passe. Ce
comportement explique pourquoi l’ancien et le nouveau mot de passe sont conservés
dans l’objet TDO du domaine d’approbation.
Une modification de mot de passe n’est pas finalisée tant que l’authentification utilisant
le mot de passe n’est pas réussie. L’ancien mot de passe stocké peut être utilisé sur le
canal sécurisé jusqu’à ce que le contrôleur de domaine du domaine approuvé reçoive le
nouveau mot de passe, ce qui permet de bénéficier d’un service sans interruption.
Si l’authentification avec le nouveau mot de passe échoue, à cause du mot de passe non
valide, le contrôleur de domaine d’approbation tente de procéder à l’authentification à
l’aide de l’ancien mot de passe. S’il s’authentifie correctement avec l’ancien mot de
passe, il reprend le processus de modification du mot de passe dans un délai de
15 minutes.
Les mises à jour des mots de passe d’approbation doivent être répliquées dans un délai
de 30 jours sur les contrôleurs de domaine des deux parties de l’approbation. Si le mot
de passe d’approbation est modifié après ce délai de 30 jours, et qu’un contrôleur de
domaine ne possède que le mot de passe N-2, il ne peut pas utiliser l’approbation
depuis la partie d’approbation, et il ne peut pas créer de canal sécurisé dans la partie
approuvée.
Ports réseau utilisés par les approbations

Dans la mesure où les approbations doivent être déployées sur plusieurs limites du
réseau, elles peuvent être amenées à s’étendre sur un ou plusieurs pare-feu. Lorsque
c’est le cas, vous pouvez transmettre par tunnel le trafic d’approbation à travers un
pare-feu, ou ouvrir des ports spécifiques dans le pare-feu pour autoriser le trafic.
） Important
Active Directory Domain Services ne prend pas en charge la restriction du trafic

RPC Active Directory sur des ports spécifiques.
Pour en savoir plus sur les ports nécessaires dans une approbation de forêt, consultez la
section Windows Server 2008 et versions ultérieures de l’article du Support Microsoft
Guide pratique de configuration d’un pare-feu pour les domaines et les approbations
Active Directory .
Services et outils associés

Pour prendre en charge les approbations et l’authentification, quelques fonctionnalités
et outils de gestion supplémentaires sont utilisés.
Net Logon
Le service Net Logon gère un canal sécurisé, depuis un ordinateur Windows vers un
contrôleur de domaine. Il est également utilisé dans les processus suivants, liés à
l’approbation :
Gestion et configuration de l’approbation - Net Logon permet de conserver les

mots de passe d’approbation, de collecter les informations d’approbation et de
vérifier les approbations en interagissant avec le processus LSA et l’objet domaine
approuvé.
Pour les approbations de forêt, les informations d’approbation incluent

l’enregistrement des informations d’approbation de forêt (FTInfo) ; celui-ci
comprend l’ensemble des espaces de noms qu’une forêt approuvée entend gérer,
annoté à l’aide d’un champ indiquant si chaque revendication est approuvée par la
forêt d’approbation.
Authentification - Fournit sur un canal sécurisé les informations d’identification de

l’utilisateur à un contrôleur de domaine, et retourne pour cet utilisateur les SID de
domaine et les droits d’utilisateur.
Emplacement du contrôleur de domaine - Permet de rechercher ou de localiser les

contrôleurs de domaine dans un ou plusieurs domaines.
Validation directe - Les informations d’identification des utilisateurs dans d’autres

domaines sont traitées par Net Logon. Lorsqu’un domaine d’approbation doit
vérifier l’identité d’un utilisateur, il transmet pour contrôle, via Net Logon, les
informations d’identification de l’utilisateur au domaine approuvé.
Vérification du certificat PAC (Privilege Attribute Certificate) - Lorsqu’un serveur

utilisant le protocole Kerberos pour l’authentification doit vérifier le certificat PAC
dans un ticket de service, il envoie, pour contrôle, ce certificat à son contrôleur de
domaine sur le canal sécurisé.
Autorité de sécurité locale

L’autorité de sécurité locale (LSA) est un sous-système protégé qui conserve des
informations se rapportant à tous les aspects de la sécurité locale sur un système.
Regroupés sous l’appellation de « stratégie de sécurité locale », l’autorité LSA fournit
différents services de traduction entre les noms et les identificateurs.
Le sous-système de sécurité LSA fournit des services en mode noyau et en mode

utilisateur pour valider l’accès aux objets, vérifier les privilèges de l’utilisateur et générer
des messages d’audit. LSA est chargé de vérifier la validité de tous les tickets de session
présentés par les services, dans des domaines approuvés ou non approuvés.
Outils d'administration
Les administrateurs peuvent utiliser Domaines et approbations Active Directory, Netdom
et Nltest pour exposer, créer, supprimer ou modifier des approbations.
Domaines et approbations Active Directory est la console MMC (Microsoft

Management Console) qui est utilisée pour gérer les approbations de domaine, les
niveaux fonctionnels de domaine et de forêt et les suffixes de nom d’utilisateur
principal.
Les outils en ligne de commande Netdom et Nltest peuvent être utilisés pour
rechercher, afficher, créer et gérer les approbations. Ces outils communiquent
directement avec l’autorité LSA sur un contrôleur de domaine.
Étapes suivantes
Pour prendre en main la création d’un domaine managé avec une approbation de forêt,
consultez Créer et configurer un domaine managé Azure AD DS. Vous pouvez ensuite
créer une approbation de forêt sortante vers un domaine local.
Synchronisation des objets et des
informations d’identification dans un
Domain Services
Article • 12/04/2023
Les objets et les informations d’identification d’un domaine managé Azure Active
Directory Domain Services (Azure AD DS) peuvent être créés localement dans le
domaine ou synchronisés à partir d’un locataire Azure Active Directory (Azure AD).
Lorsque vous déployez Azure AD DS pour la première fois, une synchronisation
automatique à sens unique est configurée et démarrée pour répliquer les objets à partir
d’Azure AD. Cette synchronisation unidirectionnelle continue à s’exécuter en arrière-plan
pour maintenir à jour le domaine managé Azure AD DS avec les modifications apportées
par Azure AD. Aucune synchronisation n’est effectuée à partir d’Azure AD DS vers Azure
AD.
Dans un environnement hybride, les objets et les informations d’identification d’un

domaine AD DS local peuvent être synchronisés avec Azure AD à l’aide d’Azure AD
Connect. Une fois que ces objets sont synchronisés avec succès sur Azure AD, la
synchronisation en arrière-plan automatique rend ces objets et informations
d’identification disponibles pour les applications utilisant le domaine managé.
Le diagramme suivant illustre le fonctionnement de la synchronisation entre Azure AD

DS, Azure AD et un environnement AD DS local facultatif :
Synchronisation à partir d’Azure AD vers Azure

AD DS
Les comptes d’utilisateur, les appartenances aux groupes et les hachages des
informations d’identification sont synchronisés dans une direction, d’Azure AD à Azure
AD DS. Ce processus de synchronisation est automatique. Il est inutile de configurer,
surveiller ou gérer le processus de synchronisation. La synchronisation initiale peut durer
de quelques heures à quelques jours, en fonction du nombre d’objets contenus dans
l’annuaire Azure AD. Une fois la synchronisation initiale terminée, les modifications
apportées à Azure AD, telles que les modifications de mot de passe ou d’attribut, sont
alors automatiquement synchronisées avec Azure AD DS.
Lorsqu’un utilisateur est créé dans Azure AD, il n’est pas synchronisé avec Azure AD DS
tant qu’il n’a pas modifié son mot de passe dans Azure AD. Ce processus de
changement du mot de passe entraîne la génération et le stockage dans Azure AD des
hachages de mot de passe pour l’authentification Kerberos et NTLM. Les hachages de
mot de passe sont nécessaires pour authentifier correctement un utilisateur dans Azure
AD DS.
Le processus de synchronisation est unidirectionnel par nature. Il n’existe aucune

synchronisation inverse des modifications d’Azure AD DS vers Azure AD. Un domaine
managé est en grande partie en lecture seule, à l’exception des unités d’organisation
personnalisées que vous pouvez créer. Vous ne pouvez pas changer les attributs
utilisateur, les mots de passe utilisateur ou les appartenances aux groupes au sein d’un
domaine managé.
Synchronisation délimitée et filtre de groupe

Vous pouvez limiter la synchronisation aux comptes d’utilisateur qui proviennent du
cloud. Dans cette étendue de synchronisation, vous pouvez appliquer un filtre pour des
groupes d’utilisateurs spécifiques. Vous pouvez choisir entre les groupes cloud
uniquement, les groupes locaux, ou les deux. Pour plus d’informations sur la
configuration de la synchronisation délimitée, consultez Configurer la synchronisation
délimitée.
Synchronisation des attributs et mappage avec
Azure AD DS
Le tableau suivant répertorie certains attributs courants et la façon dont ils sont
synchronisés avec Azure AD DS.
Attribut dans Source Notes

Azure AD DS
UPN Attribut UPN de L’attribut UPN du locataire Azure AD est synchronisé tel
l’utilisateur dans quel pour Azure AD DS. La méthode la plus fiable pour
votre locataire se connecter à un domaine managé consiste à utiliser
Azure AD l’UPN.
Attribut dans Source Notes
Azure AD DS
SAMAccountName Attribut L’attribut SAMAccountName provient de l’attribut

mailNickname de mailNickname dans le locataire Azure AD. Si plusieurs
l’utilisateur, dans comptes d’utilisateurs ont le même attribut
le locataire Azure mailNickname, SAMAccountName est généré
AD ou généré automatiquement. Si le paramètre mailNickname ou
automatiquement préfixe UPN dépasse 20 caractères, SAMAccountName
est généré automatiquement pour répondre à la limite
de 20 caractères sur les attributs SAMAccountName.
Mots de passe Mot de passe Les hachages de mot de passe hérités requis pour
utilisateur du l’authentification NTLM ou Kerberos sont synchronisés
locataire Azure à partir du locataire Azure AD. Si le locataire Azure AD
AD est configuré pour la synchronisation hybride à l’aide
d’Azure AD Connect, ces hachages de mot de passe
proviennent de l’environnement AD DS local.
SID Généré Le SID principal pour les comptes de

groupe/utilisateur automatiquement groupe/d’utilisateur est généré automatiquement dans
principal Azure AD DS. Cet attribut ne correspond pas au SID de
groupe/d’utilisateur principal de l’objet dans un
environnement AD DS local. Cette incompatibilité est
due au fait que le domaine managé a un espace de
noms SID différent de celui du domaine AD DS local.
Historique des SID SID d’utilisateur L'attribut SidHistory pour les utilisateurs et les groupes
des utilisateurs et et de groupe dans Azure AD DS est défini de sorte à correspondre au
groupes principal local SID de groupe ou d’utilisateur principal correspondant
dans un environnement AD DS local. Cette
fonctionnalité permet de faciliter la migration des
applications sur site vers Azure AD DS, étant donné que
vous n’avez pas besoin de redéfinir les ACL des
ressources.
 Conseil
Se connecter au domaine managé en utilisant le format UPN : l’attribut

SAMAccountName, tel que AADDSCONTOSO\driley , peut être généré
automatiquement pour certains comptes d’utilisateur dans un domaine managé. La
valeur de SAMAccountName générée automatiquement pour l’utilisateur peut
différer du préfixe UPN de ce dernier, donc n’est pas toujours un moyen fiable de
se connecter.
Par exemple, si plusieurs utilisateurs ont le même attribut mailNickname ou si des

utilisateurs ont des préfixes UPN anormalement longs, la valeur SAMAccountName
pour ces utilisateurs peut être générée automatiquement. Utilisez le format UPN,
tel que driley@aaddscontoso.com , pour vous connecter de manière fiable à un
domaine managé.
Mappage d’attributs pour les comptes d’utilisateur

Le tableau suivant illustre la façon dont certains attributs pour les objets utilisateur dans
Azure AD sont synchronisés avec les attributs correspondants dans Azure AD DS.
Attribut utilisateur dans Attribut utilisateur dans Azure AD DS

Azure AD
accountEnabled userAccountControl (définit ou efface le bit

ACCOUNT_DISABLED)
city l
companyName companyName
country co
department department
displayName displayName
employeeId employeeId
facsimileTelephoneNumber facsimileTelephoneNumber
givenName givenName
jobTitle title
mail mail
mailNickName msDS-AzureADMailNickname
mailNickName SAMAccountName (peut parfois être généré

automatiquement)
manager manager
mobile mobile
objectid msDS-aadObjectId
onPremiseSecurityIdentifier sidHistory
passwordPolicies userAccountControl (définit ou efface le bit

DONT_EXPIRE_PASSWORD)
Attribut utilisateur dans Attribut utilisateur dans Azure AD DS
Azure AD
physicalDeliveryOfficeName physicalDeliveryOfficeName
postalCode postalCode
preferredLanguage preferredLanguage
proxyAddresses proxyAddresses
state st
streetAddress streetAddress
surname sn
telephoneNumber telephoneNumber
userPrincipalName userPrincipalName
Mappage d’attributs pour les groupes

Le tableau suivant illustre la façon dont certains attributs pour les objets de groupe dans
Azure AD sont synchronisés avec les attributs correspondants dans Azure AD DS.
Attribut de groupe dans Azure Attribut de groupe dans Azure AD DS

AD
displayName displayName
displayName SAMAccountName (peut parfois être généré

automatiquement)
mail mail
mailNickName msDS-AzureADMailNickname
objectid msDS-AzureADObjectId
onPremiseSecurityIdentifier sidHistory
proxyAddresses proxyAddresses
securityEnabled groupType
Synchronisation d’AD DS local vers Azure AD et

Azure AD DS
Azure AD Connect est utilisé pour synchroniser les comptes d’utilisateur, les
appartenances aux groupes et les hachages d’informations d’identification à partir d’un
environnement AD DS local vers Azure AD. Les attributs des comptes d’utilisateur tels
que l’UPN et l’identificateur de sécurité (SID) sont synchronisés en local. Pour vous
connecter à l’aide d'Azure AD DS, les hachages de mot de passe hérités requis pour
l'authentification NTLM et Kerberos sont également synchronisés avec Azure AD.
） Important

Si vous configurez l’écriture différée, les modifications d’Azure AD sont resynchronisées

dans l’environnement AD DS local. Par exemple, si un utilisateur modifie son mot de
passe à l’aide de la gestion des mots de passe en libre-service d’Azure AD, le mot de
passe est mis à jour dans l’environnement AD DS local.
７ Notes
Utilisez toujours la version la plus récente d’Azure AD Connect pour vous assurer
d'avoir les correctifs pour tous les bogues connus.
Synchronisation d’un environnement local à plusieurs

forêts
De nombreuses organisations disposent d’un environnement AD DS local relativement
complexe qui comprend plusieurs forêts. Azure AD Connect prend en charge la
synchronisation des utilisateurs, groupes et hachages d’informations d’identification à
partir d’environnements à plusieurs forêts vers Azure AD.
Azure AD a un espace de noms bien plus simple et plat. Pour permettre aux utilisateurs
d’accéder de manière fiable aux applications sécurisées par Azure AD, résolvez les
conflits d’UPN entre comptes d’utilisateur dans des forêts différentes. Les domaines
managés utilisent une structure d’unité d’organisation plate, similaire à Azure AD. Tous
les comptes d’utilisateurs et les groupes sont stockés dans le conteneur Utilisateurs
AADDC, en dépit de la synchronisation effectuée à partir de forêts ou de domaines
locaux différents, même si vous avez configuré une structure d’unités d’organisation
hiérarchique locale. Le domaine managé aplatit toutes les structures d’unités
d’organisation hiérarchiques.
Comme nous l’avons vu précédemment, il n’existe aucune synchronisation d’Azure AD

DS vers Azure AD. Vous pouvez créer une unité d’organisation personnalisée dans Azure
AD DS, puis des utilisateurs, des groupes ou des comptes de service au sein de ces
unités d’organisation personnalisées. Aucun des objets créés dans les unités
d’organisation personnalisées n’est de nouveau synchronisé avec Azure AD. Ces objets
sont uniquement disponibles dans le domaine managé et ne sont pas visibles dans les
applets de commande Azure AD PowerShell, l’API Microsoft Graph ou l’interface
utilisateur de gestion Azure AD.
Éléments qui ne sont pas synchronisés avec

Azure AD DS
Les objets ou attributs suivants ne sont pas synchronisés à partir d’un environnement
AD DS local vers Azure AD ou Azure AD DS :
Exlure les attributs : Vous pouvez choisir d’exclure certains attributs de la

synchronisation avec Azure AD à partir d’un environnement AD DS local à l’aide
d’Azure AD Connect. Ces attributs exclus ne sont alors pas disponibles dans Azure
AD DS.
Stratégies de groupe : Les stratégies de groupe configurées dans un
environnement AD DS local ne sont pas synchronisées avec Azure AD DS.
Dossier Sysvol : Le contenu du dossier Sysvol dans un environnement AD DS local
n’est pas synchronisé avec Azure AD DS.
Objets ordinateur : Les objets ordinateur pour les ordinateurs joints à un
environnement AD DS local ne sont pas synchronisés avec Azure AD DS. Ces
ordinateurs n’ont pas de relation d’approbation avec le domaine managé et
n’appartiennent qu’à l’environnement AD DS local. Dans Azure AD DS, seuls les
objets ordinateur pour les ordinateurs que vous avez explicitement joints au
domaine managé s’affichent.
Attributs SidHistory des utilisateurs et groupes : les SID de l’utilisateur principal et
du groupe principal d’un environnement AD DS local sont synchronisés avec Azure
AD DS. Toutefois, les attributs SidHistory existants pour les utilisateurs et les
groupes ne sont pas synchronisés de l’environnement AD DS vers Azure AD DS.
Structures d’unités d’organisation (OU) : Les unités d’organisation définies dans
un environnement AD DS local ne sont pas synchronisées avec Azure AD DS. Il
existe deux unités d’organisation intégrées dans Azure AD DS : une pour les
utilisateurs et une pour les ordinateurs. Le domaine managé a une structure
d’unité d’organisation plate. Vous pouvez choisir de créer une unité d’organisation
personnalisée dans votre domaine managé.
Considérations relatives à la sécurité et à la

synchronisation de hachage du mot de passe
Lorsque vous activez Azure AD DS, les hachages de mot de passe hérités pour
l’authentification NTLM et Kerberos sont requis. Azure AD ne stocke pas les mots de
passe en texte clair. Par conséquent, ces hachages ne peuvent pas être générés
automatiquement pour les comptes d'utilisateur existants. Les hachages de mot de
passe compatibles NTLM et Kerberos sont toujours stockés sous forme chiffrée dans
Azure AD.
Les clés de chiffrement sont uniques pour chaque locataire Azure AD. Ces hachages sont
chiffrés afin que seul Azure AD DS ait accès aux clés de déchiffrement. Aucun autre
service ni composant d’Azure AD n’a accès aux clés de déchiffrement.
Les hachages de mot de passe hérités sont ensuite synchronisés à partir d’Azure AD
dans les contrôleurs de domaine pour un domaine managé. Les disques de ces
contrôleurs de domaine managé dans Azure AD DS sont chiffrés à l’arrêt. Ces hachages
de mot de passe sont stockés et sécurisés sur ces contrôleurs de domaine de la même
manière que les mots de passe stockés et sécurisés dans un environnement AD DS local.
Pour les environnements Azure AD cloud uniquement, les utilisateurs doivent

réinitialiser/modifier leur mot de passe afin que les hachages de mot de passe requis
soient générés et stockés dans Azure AD. Pour tout compte d’utilisateur cloud créé dans
Azure AD après l’activation d’Azure AD Domain Services, les hachages de mot de passe
sont générés et stockés dans des formats compatibles NTLM et Kerberos. Tous les
comptes d’utilisateur cloud doivent modifier leur mot de passe pour pouvoir être
synchronisés avec Azure AD DS.
Pour les comptes d’utilisateurs hybrides synchronisés à partir d’un environnement AD

DS local à l’aide d’Azure AD Connect, vous devez configurer Azure AD Connect pour
synchroniser les hachages de mot de passe dans des formats compatibles NTLM et
Kerberos.
Étapes suivantes
Pour plus d’informations sur les détails de la synchronisation de mot de passe, consultez
Fonctionnement de la synchronisation de hachage du mot de passe avec Azure AD
Connect.
Pour commencer à utiliser Azure AD DS, créez un domaine managé.
Implémenter la synchronisation de
hachage de mot de passe avec la
synchronisation Azure AD Connect
Article • 18/05/2023
Cet article vous fournit les informations nécessaires pour synchroniser vos mots de
passe utilisateur à partir d’une instance Active Directory (AD) locale vers une instance
Azure Active Directory (Azure AD) dans le cloud.
Fonctionnement de la synchronisation de
hachage de mot de passe
Le service de domaine Active Directory stocke les mots de passe sous forme de valeur
de hachage du mot de passe réel de l’utilisateur. Une valeur de hachage est le résultat
d’une fonction mathématique unidirectionnelle (« algorithme de hachage »). Il n’existe
aucune méthode pour retrouver la version en texte brut du mot de passe à partir du
résultat d’une fonction unidirectionnelle.
Pour synchroniser votre mot de passe, Azure AD Connect Sync extrait le hachage de
votre mot de passe à partir de l’instance Active Directory local. Un traitement de sécurité
supplémentaire est appliqué au hachage du mot de passe avant sa synchronisation avec
le service d’authentification Azure Active Directory. Les mots de passe sont synchronisés
pour chaque utilisateur et par ordre chronologique.
Le flux de données réel du processus de synchronisation du hachage de mot de passe

est similaire à celui de la synchronisation des données de l’utilisateur. Cependant, les
mots de passe sont synchronisés plus fréquemment que la fenêtre de synchronisation
d’annuaire standard pour d’autres attributs. Le processus de hachage de synchronisation
de mot de passe s’exécute toutes les deux minutes. Vous ne pouvez pas modifier la
fréquence de ce processus. Quand vous synchronisez un mot de passe, il remplace le
mot de passe cloud existant.
La première fois que vous activez la fonctionnalité de synchronisation de hachage de

mot de passe, elle effectue une synchronisation initiale des mots de passe de tous les
utilisateurs concernés. Avant le basculement de vos domaines, le déploiement par
étapes vous permet de tester des groupes d’utilisateurs de manière sélective, grâce à
nos outils d’authentification cloud, comme le service Azure Active Directory Multifactor
Authentication (MFA), la fonctionnalité « Accès conditionnel » d’Azure AD, la
fonctionnalité « Informations d’identification fuitées » d’Identity Protection, la solution
Identity Governance… Et bien d’autres. Vous ne pouvez pas définir explicitement un
sous-ensemble de mots de passe utilisateur à synchroniser. Toutefois, s’il y a plusieurs
connecteurs, il est possible de désactiver la synchronisation du hachage de mot de
passe pour certains connecteurs, mais pas pour d’autres, à l’aide de l’applet de
commande Set-ADSyncAADPasswordSyncConfiguration.
Lorsque vous modifiez un mot de passe local, le mot de passe mis à jour est
synchronisé, plus souvent en quelques minutes. La fonctionnalité de synchronisation de
hachage de mot de passe tente automatiquement d’effectuer à nouveau les tentatives
de synchronisation ayant échoué. Si une erreur se produit lors d’une tentative de
synchronisation de mot de passe, une erreur est enregistrée dans l’Observateur
d’événements.
La synchronisation d’un mot de passe n’a aucun impact sur l’utilisateur actuellement
connecté. La session en cours n’est pas immédiatement affectée par une modification
du mot de passe synchronisé effectuée tout en étant connecté à un service cloud.
Toutefois, lorsque le service cloud vous oblige à vous authentifier à nouveau, vous devez
fournir votre nouveau mot de passe.
Un utilisateur doit entrer ses informations d’identification d’entreprise une deuxième

fois pour s’authentifier auprès d’Azure AD, qu’il soit connecté à son réseau d’entreprise
ou non. Ce modèle peut être réduit, cependant, si l’utilisateur coche la case « Maintenir
la connexion » lors de la connexion. Cette sélection définit un cookie de session qui
ignore l’authentification pendant 180 jours. Le comportement KMSI peut être activé ou
désactivé par l’administrateur Azure AD. De plus, vous pouvez réduire les invites de mot
de passe en activant la jonction Azure AD ou la jonction Azure AD Hybride qui
connectent automatiquement les utilisateurs lorsqu’ils utilisent des appareils de votre
entreprise connectés au réseau de votre entreprise.
Autres avantages
En règle générale, la synchronisation de hachage de mot de passe est plus simple
à implémenter qu’un service de fédération. Elle ne nécessite pas de serveurs
supplémentaires et élimine la dépendance vis-à-vis d’un service de fédération
hautement disponible pour authentifier les utilisateurs.
La synchronisation de hachage de mot de passe peut également être activée en
plus de la fédération. Vous pouvez l’utiliser comme solution de secours si votre
service de fédération connaît une défaillance.
７ Notes
La synchronisation de mot de passe est uniquement prise en charge pour
l'utilisateur de type d'objet dans Active Directory. Elle n'est pas prise en charge
pour le type d'objet iNetOrgPerson.
Description détaillée du fonctionnement de la

synchronisation de hachage de mot de passe
La section suivante explique en détail comment fonctionne la synchronisation du
hachage de mot de passe entre Active Directory et Azure AD.
1. Toutes les deux minutes, l’agent de synchronisation du hachage de mot de passe

qui se trouve sur le serveur AD Connect demande des hachages de mots de passe
stockés (l’attribut unicodePwd) à un contrôleur de domaine. Cette demande utilise
le protocole de réplication MS-DRSR permettant de synchroniser les données
entre les contrôleurs de domaine. Le compte de service doit disposer des
autorisations Répliquer les changements d’annuaires et Répliquer les changements
d’annuaire Tout d’Active Directory (accordées par défaut lors de l’installation) pour
obtenir les hachages de mot de passe.
2. Avant l’envoi, le contrôleur de domaine chiffre le hachage de mot de passe MD4 à
l’aide d’une clé qui est un hachage MD5 de la clé de session RPC et un salt. Il
envoie ensuite le résultat à l’agent de synchronisation de hachage de mot de passe
via RPC. Le contrôleur de domaine passe également le salt à l’agent de
synchronisation à l’aide du protocole de réplication du contrôleur de domaine,
pour que l’agent puisse déchiffrer l’enveloppe.
3. Une fois que l’agent de synchronisation de hachage de mot de passe dispose de
l’enveloppe chiffrée, il utilise MD5CryptoServiceProvider et le salt pour générer une
clé afin de déchiffrer les données reçues dans leur format MD4 d’origine. L’agent
de synchronisation du hachage de mot de passe n’a jamais accès au mot de passe
en texte clair. L’utilisation de MD5 par l’agent de synchronisation de hachage de
mot de passe est strictement destinée à assurer la compatibilité du protocole de
réplication avec le contrôleur de domaine, et uniquement en local entre le
contrôleur de domaine et l’agent de synchronisation de hachage de mot de passe.
4. L’agent de synchronisation de hachage de mot de passe étend le hachage de mot
de passe binaire de 16 octets à 64 octets en convertissant d’abord le hachage en
chaîne hexadécimale de 32 octets, puis en reconvertissant cette chaîne au format
binaire avec l’encodage UTF-16.
5. L’agent de synchronisation de hachage de mot de passe ajoute pour chaque
utilisateur un salt de 10 octets de long au fichier binaire de 64 octets pour
renforcer la protection du hachage d’origine.
6. L’agent de synchronisation de hachage de mot de passe combine alors le hachage
MD4 et le salt par utilisateur, puis place le tout dans la fonction PBKDF2 . 1 000
itérations de l’algorithme de hachage à clé HMAC-SHA256 sont utilisées. Pour plus
d’informations, consultez le Livre blanc Azure AD .
7. L’agent de synchronisation de hachage de mot de passe prend le hachage de 32
octets résultant, concatène le salt par utilisateur et le nombre d’itérations SHA256
(pour une utilisation par Azure AD), puis transmet la chaîne d’Azure AD Connect à
Azure AD par TLS.
8. Lorsqu’un utilisateur tente de se connecter à Azure AD et entre son mot de passe,
le mot de passe est traité par le même processus MD4+salt+PBKDF2+HMAC-
SHA256. Si le hachage résultant correspond au hachage stocké dans Azure AD,
l’utilisateur a entré le bon mot de passe et est authentifié.
７ Notes
Le hachage MD4 d’origine n’est pas transmis à Azure AD. Au lieu de cela, le
hachage SHA256 du hachage MD4 d’origine est transmis. Par conséquent, si le
hachage stocké dans Azure AD est obtenu, il ne peut pas être utilisé dans une
attaque de type pass-the-hash locale.
７ Notes
La valeur de hachage du mot de passe n’est JAMAIS stockée dans SQL. Ces valeurs
sont traitées uniquement en mémoire avant d’être envoyées à Azure AD.
Considérations relatives à la sécurité

Lors de la synchronisation des mots de passe, la version en texte brut de votre mot de
passe n’est exposée ni à la fonctionnalité de synchronisation de hachage de mot de
passe, ni à Azure AD, ni à l’un des services associés.
L’authentification de l’utilisateur s’effectue par rapport à Azure AD plutôt que sur

l’instance Active Directory de l’organisation. Les données de mot de passe SHA256
stockées dans Azure AD (hachage du hachage MD4 d’origine) sont plus sécurisées que
celles qui sont stockées dans Active Directory. En outre, étant donné que ce hachage
SHA256 ne peut pas être déchiffré, il ne peut pas être réimporté dans l’environnement
Active Directory de l’organisation et présenté sous la forme d’un mot de passe
utilisateur valide dans une attaque de type pass-the-hash.
Remarques sur les stratégies de mot de passe

Deux types de stratégies de mot de passe sont affectés par l’activation de la
synchronisation de hachage de mot de passe :
Stratégie de complexité de mot de passe

Stratégie d’expiration de mot de passe
Stratégie de complexité de mot de passe
Quand vous activez la synchronisation de hachage de mot de passe, les stratégies de

complexité de mot de passe dans votre instance Active Directory locale remplacent les
stratégies de complexité dans le cloud pour les utilisateurs synchronisés. Vous pouvez
utiliser tous les mots de passe valides de votre instance Active Directory locale pour
accéder aux services Azure AD.
７ Notes
Les mots de passe des utilisateurs créés directement dans le cloud sont toujours
soumis aux stratégies de mot de passe définies dans le cloud.
Stratégie d’expiration de mot de passe
Si un utilisateur est concerné par la synchronisation de hachage de mot de passe, par

défaut le mot de passe de compte cloud est défini sur Ne jamais expirer.
Vous pouvez continuer à vous connecter aux services cloud à l’aide d’un mot de passe
synchronisé qui a expiré dans votre environnement local. Votre mot de passe cloud est
mis à jour la prochaine fois que vous modifiez le mot de passe dans l’environnement
local.
CloudPasswordPolicyForPasswordSyncedUsersEnabled
S’il existe des utilisateurs synchronisés qui interagissent uniquement avec des services
intégrés Azure AD et qui doivent également respecter une stratégie d’expiration de mot
de passe, vous pouvez les forcer à respecter votre stratégie d’expiration de mot de
passe Azure AD en activant la fonctionnalité
CloudPasswordPolicyForPasswordSyncedUsersEnabled (dans le module PowerShell
MSOnline déconseillé qui s’appelait
EnforceCloudPasswordPolicyForPasswordSyncedUsers).
Quand CloudPasswordPolicyForPasswordSyncedUsersEnabled est désactivé (ce qui est le

paramètre par défaut), Azure AD Connect donne à l’attribut PasswordPolicies la valeur
DisablePasswordExpiration. Cette action est effectuée chaque fois que le mot de passe
d’un utilisateur est synchronisé, et indique à Azure AD qu’il faut ignorer la stratégie
d’expiration du mot de passe cloud pour cet utilisateur. Vous pouvez vérifier la valeur de
l’attribut à l’aide du module Azure AD PowerShell à l’aide de la commande suivante :
(Get-MgUser -UserId <User Object ID> -Property PasswordPolicies).PasswordPolicies
Pour activer la fonctionnalité CloudPasswordPolicyForPasswordSyncedUsersEnabled,

exécutez les commandes suivantes en utilisant le module PowerShell Graph comme
indiqué ci-dessous :
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.CloudPasswordPolicyForPasswordSyncedUsersEnabled =
$true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
Une fois la fonctionnalité activée, Azure AD n’accède pas à chaque utilisateur

synchronisé pour supprimer la valeur DisablePasswordExpiration de l’attribut
PasswordPolicies. Au lieu de cela, la valeur DisablePasswordExpiration est supprimée de
PasswordPolicies lors de la synchronisation de hachage de mot de passe suivante pour
chaque utilisateur, lors de modification de mot de passe suivante dans l’annuaire Active
Directory local.
Une fois la fonctionnalité CloudPasswordPolicyForPasswordSyncedUsersEnabled activée,

les nouveaux utilisateurs sont provisionnés sans valeur PasswordPolicies.
 Conseil
Il est recommandé d’activer CloudPasswordPolicyForPasswordSyncedUsersEnabled
avant d’activer la synchronisation du hachage de mot de passe, de sorte que la
synchronisation initiale du hachage de mot de passe n’ajoute pas la valeur
DisablePasswordExpiration à l’attribut PasswordPolicies pour les utilisateurs.
La stratégie de mot de passe Azure AD par défaut oblige les utilisateurs à changer leurs
mots de passe tous les 90 jours. Si votre stratégie dans Active Directory est également
de 90 jours, les deux stratégies doivent correspondre. Cependant, si la stratégie AD n’est
pas de 90 jours, vous pouvez mettre à jour la stratégie de mot de passe Azure AD pour
qu’elle corresponde à l’aide de la commande PowerShell Update-MgDomain
(précédemment : Set-MsolPasswordPolicy).
Azure AD prend en charge une stratégie d’expiration de mot de passe distincte pour
chaque domaine inscrit.
Inconvénient : si des comptes synchronisés doivent avoir des mots de passe sans
expiration dans Azure AD, vous devez ajouter explicitement la valeur
DisablePasswordExpiration à l’attribut PasswordPolicies de l’objet utilisateur dans Azure
AD. Vous pouvez effectuer cette opération en exécutant la commande suivante.
Update-MgUser -UserID <User Object ID> -PasswordPolicies
"DisablePasswordExpiration"
７ Notes
Pour les utilisateurs hybrides dont la valeur PasswordPolicies est définie sur
DisablePasswordExpiration , cette valeur bascule sur None après le changement
d’un mot de passe en local.
７ Notes
Les commandes PowerShell Update-MgDomain et Set-MsolPasswordPolicy

(dépréciée) ne fonctionnent pas sur les domaines fédérés.
７ Notes
Les commandes PowerShell Set-MgUser et Set-AzureADUser (dépréciée) ne

fonctionnent pas sur les domaines fédérés.
Synchronisation des mots de passe temporaires et « Forcer la
modification du mot de passe à la prochaine ouverture de session »
Il est courant de forcer un utilisateur à modifier son mot de passe lors de sa première
ouverture de session, en particulier après la réinitialisation d’un mot de passe
d’administrateur. Il s’agit généralement de définir un mot de passe « temporaire ». Vous
devez pour cela sélectionner l’indicateur « L’utilisateur doit changer le mot de passe à la
prochaine ouverture de session » sur un objet utilisateur dans Active Directory (AD).
La fonctionnalité de mot de passe temporaire permet de s’assurer que le transfert de

propriété des informations d’identification est effectué lors de la première utilisation,
afin de réduire la durée pendant laquelle plusieurs personnes ont connaissance de ces
informations d’identification.
Pour prendre en charge les mots de passe temporaires dans Azure AD pour les
utilisateurs synchronisés, vous pouvez activer la fonctionnalité
ForcePasswordChangeOnLogOn en exécutant la commande suivante sur votre serveur
Azure AD Connect :
Set-ADSyncAADCompanyFeature -ForcePasswordChangeOnLogOn $true
７ Notes
forcer un utilisateur à changer son mot de passe lors de la prochaine ouverture de

session nécessite en même temps un changement du mot de passe. Azure AD
Connect ne récupère pas de lui-même l’indicateur de changement forcé du mot de
passe. Cela s’ajoute au changement de mot de passe détecté qui se produit
pendant la synchronisation du hachage de mot de passe.
Si l’utilisateur a l’option « Le mot de passe n’expire jamais » défini dans Active
Directory (AD), l’indicateur qui force la modification du mot de passe ne sera pas
défini dans Active Directory (AD). par conséquent, l’utilisateur ne sera pas invité à
modifier le mot de passe lors de la prochaine connexion.
Un nouvel utilisateur créé dans Active Directory avec l’indicateur « L’utilisateur doit
changer le mot de passe à la prochaine ouverture de session » est toujours
approvisionné dans Azure AD avec une stratégie de mot de passe « Forcer le
changement de mot de passe lors de la prochaine connexion », que la
fonctionnalité ForcePasswordChangeOnLogOn soit true ou false. Il s’agit d’une
logique interne Azure AD, car le nouvel utilisateur est approvisionné sans mot de
passe, tandis que la fonctionnalité ForcePasswordChangeOnLogOn affecte
uniquement les scénarios de réinitialisation de mot de passe administrateur.
Ｕ Attention
Vous devez utiliser cette fonctionnalité uniquement quand la réinitialisation de mot

de passe en libre-service (SSPR) et la réécriture du mot de passe sont activées sur le
locataire. Ainsi, si un utilisateur modifie son mot de passe via SSPR, il sera
synchronisé avec Active Directory.
Expiration du compte
Si votre organisation utilise l’attribut accountExpires dans le cadre de la gestion des
comptes d’utilisateur, il n’est pas synchronisé avec Azure AD. Par conséquent, un
compte Active Directory expiré dans un environnement configuré pour la
synchronisation de hachage de mot de passe sera toujours actif dans Azure AD. Nous
vous recommandons d’utiliser un script PowerShell planifié qui désactive les comptes
AD des utilisateurs, une fois qu’ils ont expiré (utilisez la cmdlet Set-ADUser). À l’inverse,
au cours du processus de suppression de l’expiration d’un compte AD, le compte doit
être réactivé.
Remplacement des mots de passe synchronisés

Un administrateur peut réinitialiser manuellement votre mot de passe directement dans
Azure AD à l’aide de Windows PowerShell (sauf si l’utilisateur se trouve dans un
domaine fédéré).
Dans ce cas, le nouveau mot de passe remplace votre mot de passe synchronisé et
toutes les stratégies de mot de passe définies dans le cloud s’appliquent au nouveau
mot de passe.
Si vous modifiez de nouveau votre mot de passe local, le nouveau mot de passe est
synchronisé avec le cloud et il remplace le mot de passe mis à jour manuellement.
La synchronisation d’un mot de passe n’a aucun impact sur l’utilisateur Azure connecté.
Votre session de service cloud en cours n’est pas immédiatement affectée par une
modification de mot de passe synchronisé effectuée lorsque vous êtes connecté à un
service cloud. L’option Maintenir la connexion (KMSI) étend la durée de cette différence.
Lorsque le service cloud vous oblige à vous authentifier à nouveau, vous devez fournir
votre nouveau mot de passe.
Processus de synchronisation du hachage de
mot de passe pour Azure AD Domain Services
Si vous utilisez Azure AD Domain Services pour fournir une authentification héritée pour
les applications et les services qui doivent utiliser Kerberos, LDAP ou NTLM, certains
processus supplémentaires font partie du flux de synchronisation du hachage de mot de
passe. Azure AD Connect utilise le processus suivant supplémentaire pour synchroniser
les hachages de mot de passe vers Azure AD pour une utilisation dans Azure AD
Domain Services :
） Important

Connect n’est pas prise en charge dans un domaine managé Azure AD DS pour
resynchroniser des objets sur Azure AD.
Azure AD Connect synchronise uniquement les hachages de mot de passe hérités

lorsque vous activez Azure AD DS pour votre client Azure AD. Les étapes suivantes
ne sont pas utilisées si vous utilisez uniquement Azure AD Connect pour
synchroniser un environnement AD DS local avec Azure AD.
Si vos applications héritées n’utilisent pas l’authentification NTLM ou les liaisons

simples LDAP, nous vous recommandons de désactiver la synchronisation de
hachage de mot de passe NTLM pour Azure AD DS. Pour plus d’informations,
consultez Désactiver les suites de chiffrement faible et la synchronisation des
hachages des informations d’identification NTLM.
1. Azure AD Connect récupère la clé publique pour l’instance de Azure AD Domain

Services du locataire.
2. Lorsqu’un utilisateur modifie son mot de passe, le contrôleur de domaine local
stocke le résultat de la modification du mot de passe (hachages) dans deux
attributs :
unicodePwd pour le hachage de mot de passe NTLM.

supplementalCredentials pour le hachage de mot de passe Kerberos.
3. Azure AD Connect détecte les modifications de mot de passe via le canal de

duplication d’annuaire (modifications d’attributs nécessitant une réplication vers
d’autres contrôleurs de domaine).
4. Pour chaque utilisateur dont le mot de passe a changé, Azure AD Connect effectue
les étapes suivantes :
Génère une clé symétrique AES 256 bits aléatoire.

Génère un vecteur d’initialisation aléatoire requis pour le premier cycle de
chiffrement.
Extrait les hachages de mot de passe Kerberos à partir des attributs
supplementalCredentials.
Vérifie le paramètre SyncNtlmPassword de configuration de sécurité Azure AD
Domain Services.
Si ce paramètre est désactivé, génère un hachage NTLM aléatoire à forte
entropie (différent du mot de passe de l’utilisateur). Ce hachage est
ensuite combiné avec les hachages de mot de passe Kerberos exacts de
l'attribut supplementalCredentials dans une structure de données.
S’il est activé, combine la valeur de l’attribut unicodePwd avec les hachages
de mot de passe Kerberos extraits de l’attribut supplementalCredentials
dans une structure de données.
Chiffre la structure de données unique à l’aide de la clé symétrique AES.
Chiffre la clé symétrique AES à l’aide de la clé publique Azure AD Domain
Services du locataire.
5. Azure AD Connect transmet la clé symétrique AES chiffrée, la structure de données

chiffrées contenant les hachages de mot de passe et le vecteur d’initialisation à
Azure AD.
6. Azure AD stocke la clé symétrique AES chiffrée, la structure de données chiffrée et
le vecteur d’initialisation de l’utilisateur.
7. Azure AD pousse la clé symétrique AES chiffrée, la structure de données chiffrée et
le vecteur d’initialisation à l’aide d’un mécanisme de synchronisation interne sur
une session HTTP chiffrée à Azure AD Domain Services.
8. Azure AD Domain Services récupère la clé privée pour l’instance du locataire à
partir du coffre de clés Azure.
9. Pour chaque ensemble de données chiffré (représentant la modification du mot de
passe d’un seul utilisateur), Azure AD Domain Services effectue les étapes
suivantes :
Utilise sa clé privée pour déchiffrer la clé symétrique AES.

Utilise la clé symétrique AES avec le vecteur d’initialisation pour déchiffrer la
structure de données chiffrée qui contient les hachages de mot de passe.
Écrit les hachages de mot de passe Kerberos qu’il reçoit sur le contrôleur de
domaine Azure AD Domain Services. Les hachages sont enregistrés dans
l’attribut supplementalCredentials de l’objet utilisateur, qui est chiffré sur la
clé publique du contrôleur de domaine Azure AD Domain Services.
Azure AD Domain Services écrit le hachage de mot de passe NTLM reçu dans
le contrôleur de domaine Azure AD Domain Services. Le hachage est
enregistré dans l’attribut unicodePwd de l’objet utilisateur, qui est chiffré à la
clé publique du contrôleur de domaine Azure AD Domain Services.
Activer la synchronisation de hachage de mot

de passe
） Important
Si vous migrez depuis AD FS (ou d’autres technologies de fédération) vers la

méthode de synchronisation de hachage du mot de passe, veuillez consulter
Ressources pour la migration d’applications vers Azure AD.
La synchronisation de hachage de mot de passe est activée automatiquement si vous

installez Azure AD Connect avec la configuration rapide. Pour plus d’informations, voir
Bien démarrer avec Azure AD Connect à l’aide de paramètres rapides.
Si vous utilisez des paramètres personnalisés lors de l’installation d’Azure AD Connect, la

synchronisation de hachage de mot de passe est disponible dans la page de connexion
utilisateur. Pour plus d’informations, consultez Installation personnalisée d’Azure AD
Connect.
Synchronisation de hachage de mot de passe et FIPS
Si votre serveur a été verrouillé selon la norme Federal Information Processing Standard
(FIPS), MD5 est désactivé.
Pour activer MD5 pour la synchronisation de hachage de mot de passe, procédez

comme suit :
1. Accédez à %programfiles%\Microsoft Azure AD Sync\Bin.

2. Ouvrez miiserver.exe.config.
3. Accédez au nœud configuration/runtime (à la fin du fichier).
4. Ajoutez le nœud suivant : <enforceFIPSPolicy enabled="false"/>
5. Enregistrez vos modifications.
6. Redémarrez pour que les modifications soient prises en compte.
Pour référence, cet extrait de code indique ce que vous devez obtenir :
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false"/>
</runtime>
</configuration>
Pour plus d’informations sur la sécurité et FIPS, voir Synchronisation, chiffrement et
conformité à la norme FIPS du hachage de mot de passe Azure AD .
Résoudre les problèmes de synchronisation de

hachage de mot de passe
Si vous rencontrez des problèmes avec la synchronisation de hachage de mot de passe,
consultez Troubleshoot password hash synchronization (Résoudre les problèmes de
synchronisation de hachage de mot de passe).
Étapes suivantes
Synchronisation Azure AD Connect : personnaliser les options de synchronisation
Intégration des identités locales dans Azure Active Directory
Ressources pour la migration d’applications vers Azure AD
Attributs personnalisés pour Azure
Pour diverses raisons, les entreprises ne peuvent pas souvent modifier le code des
applications héritées. Les applications peuvent par exemple utiliser un attribut
personnalisé, comme un ID d’employé personnalisé, et s’en servir pour les opérations
LDAP.
Azure AD prend en charge l’ajout de données personnalisées aux ressources au moyen

d’extensions. Azure Active Directory Domain Services (Azure AD DS) peut synchroniser
les types d’extensions suivants à partir d’Azure AD, vous permettant donc également
d’utiliser des applications qui dépendent des attributs personnalisés avec Azure AD DS :
onPremisesExtensionAttributes est un ensemble de 15 attributs pouvant stocker

des attributs étendus de chaîne utilisateur.
Les extensions de répertoire autorisent l’extension du schéma d’objets annuaire
spécifiques, tels que des utilisateurs et des groupes, avec des attributs fortement
typés au travers de l’inscription auprès d’une application dans le locataire.
Les deux types d’extensions peuvent être configurés à l’aide d’Azure AD Connect pour
les utilisateurs managés localement ou de l’API MSGraph pour les utilisateurs cloud
uniquement.
７ Notes
Les types d’extensions suivants ne sont pas pris en charge pour la synchronisation :
Attributs personnalisés de sécurité dans Azure AD (préversion)

Extensions de schéma MSGraph
Extensions d’ouverture MSGraph
Configuration requise
La référence SKU minimale prise en charge pour les attributs personnalisés est la
référence SKU Entreprise. Si vous utilisez la version Standard, vous devez mettre à niveau
le domaine managé vers Enterprise ou Premium. Pour plus d’informations, consultez
Tarification pour domaine Azure Active Directory .
Fonctionnement des attributs personnalisés
Après la création d’un domaine managé, cliquez sur Attributs personnalisés
(préversion) sous Paramètres pour activer la synchronisation des attributs. Cliquez sur
Enregistrer pour confirmer les modifications.
Activer la synchronisation des attributs

prédéfinis
Cliquez sur OnPremisesExtensionAttributes pour synchroniser les attributs
extensionAttribute1-15, également appelés attributs personnalisés d’échange.
Synchroniser les attributs de l'extension du

répertoire Azure AD
Il s’agit des attributs étendus d’utilisateur ou de groupe définis dans votre locataire
Azure AD.
Sélectionnez + Ajouter pour sélectionner les attributs personnalisés à synchroniser. La

liste montre les propriétés d’extension disponibles dans votre locataire. Vous pouvez
filtrer la liste grâce à la barre de recherche.
Si vous ne voyez pas l’extension du répertoire recherchée, entrez l’appId d’application
associée à l’extension, puis cliquez sur Rechercher pour charger uniquement les
propriétés d’extension de cette application. Cette recherche est utile lorsque plusieurs
applications utilisent de nombreuses extensions dans votre locataire.
７ Notes
Si vous souhaitez afficher les extensions du répertoire synchronisées par Azure AD

Connect, cliquez sur Application d’entreprise et recherchez l’ID d’application du
Tenant Schema Extension App. Pour plus d’informations, consultez
Synchronisation Azure AD Connect : Extensions du répertoire.
Cliquez sur Sélectionner, puis Enregistrer pour confirmer la modification.
Azure AD DS remplit la totalité des utilisateurs et des groupes synchronisés avec les
valeurs d’attribut personnalisées intégrées. Les valeurs d’attribut personnalisées sont
progressivement renseignées pour les objets contenant l’extension du répertoire dans
Azure AD. Pendant le processus de synchronisation de renvoi, les modifications
incrémentielles sont suspendues dans Azure AD et la durée de synchronisation dépend
de la taille du locataire.
Pour vérifier l’état du renvoi, cliquez sur Intégrité du Service d'annuaire Azure AD et
vérifiez que l’analyse de l’horodatage de la synchronisation avec Azure AD a été mise à
jour dans l’heure suivant l’intégration. Une fois mise à jour, le remplissage est terminé.
Étapes suivantes
Pour configurer onPremisesExtensionAttributes ou des extensions du répertoire pour les
utilisateurs cloud uniquement dans Azure AD, voir Options de données personnalisées
dans Microsoft Graph.
Pour synchroniser onPremisesExtensionAttributes ou des extensions du répertoire

depuis un emplacement local vers Azure AD, configurez Azure AD Connect.
Considérations relatives à la conception du réseau
virtuel et options de configuration pour Azure Active
Article • 02/06/2023
Azure Active Directory Domain Services (AD DS) fournit des services d’authentification et de gestion à d’autres applications

et charges de travail. La connectivité réseau est une composante clé. Sans ressources de réseau virtuel correctement
configurées, les applications et les charges de travail ne peuvent pas communiquer avec les fonctionnalités fournies par
Azure AD DS ni les utiliser. Planifiez la configuration requise de votre réseau virtuel pour vous assurer qu’Azure AD DS
puisse servir vos applications et vos charges si nécessaire.
Cet article décrit les points et les conditions à prendre en compte lors de la conception pour qu’un réseau virtuel Azure
prenne en charge Azure AD DS.
Conception du réseau virtuel Azure

Pour assurer la connectivité réseau et autoriser les applications et les services à s’authentifier auprès d’un domaine managé
Azure AD DS, vous devez utiliser un réseau virtuel et un sous-réseau Azure. Dans l’idéal, le domaine managé doit être
déployé dans son propre réseau virtuel.
Vous pouvez inclure un sous-réseau d’application distinct dans le même réseau virtuel pour héberger votre machine
virtuelle de gestion ou vos charges de travail pour les petites applications. Un réseau virtuel distinct pour les charges de
travail d’application plus volumineuses ou complexes homologuées au réseau virtuel Azure AD DS, est généralement la
conception la plus appropriée.
Si vous respectez les conditions décrites dans les sections suivantes pour le réseau virtuel et le sous-réseau, vous pouvez
choisir d’autres conceptions.
Tout au long de votre conception du réseau virtuel pour Azure AD DS, les considérations suivantes s’appliquent :
Azure AD DS doit être déployé dans la même région Azure que votre réseau virtuel.
À ce stade, vous ne pouvez déployer qu’un seul domaine managé par locataire Azure AD. Le domaine managé est
déployé sur une seule région. Assurez-vous de créer ou de sélectionner un réseau virtuel dans une région qui
prend en charge Azure AD DS .
Tenez compte de la proximité des autres régions Azure et des réseaux virtuels qui hébergent les charges de travail de
votre application.
Pour réduire la latence, gardez vos applications principales à proximité du sous-réseau du réseau virtuel, à dans la
même région que celui-ci, pour votre domaine managé. Vous pouvez utiliser le peering du réseau virtuel ou les
connexions de réseau privé virtuel (VPN) entre les réseaux virtuels Azure. Ces options de connexion sont
présentées dans une prochaine section.
Le réseau virtuel ne peut pas s’appuyer sur des services DNS autres que ceux fournis par le domaine managé.
Azure AD DS fournit son propre service DNS. Le réseau virtuel doit être configuré pour utiliser ces adresses de
service DNS. La résolution de noms pour des espaces de noms supplémentaires peut être accomplie à l’aide de
redirecteurs conditionnels.
Vous ne pouvez pas utiliser les paramètres de serveur DNS personnalisés pour diriger des requêtes en provenance
d’autres serveurs DNS, y compris sur des machines virtuelles. Les ressources du réseau virtuel doivent utiliser le
service DNS fourni par le domaine managé.
） Important
Vous ne pouvez pas déplacer Azure AD DS vers un autre réseau virtuel une fois le service activé.
Un domaine managé se connecte à un sous-réseau dans un réseau virtuel Azure. Concevez ce sous-réseau pour
Azure AD DS en prenant en compte les considérations suivantes :
Un domaine managé doit être déployé dans son propre sous-réseau. L’utilisation d’un sous-réseau, d’un sous-réseau
de passerelle ou de passerelles distantes dans l’appairage de réseaux virtuels n’est pas prise en charge.
Un groupe de sécurité réseau est créé pendant le déploiement d’un domaine managé. Ce groupe de sécurité réseau
contient les règles requises pour permettre une communication de service appropriée.
Ne créez et n’utilisez pas un groupe de sécurité réseau existant avec vos propres règles personnalisées.
Un domaine managé requiert de 3 à 5 adresses IP. Assurez-vous que la plage d’adresses IP de votre sous-réseau peut
fournir ce nombre d’adresses.
La restriction des adresses IP disponibles peut empêcher Ale domaine managé de gérer deux contrôleurs de
domaine.
L’exemple de diagramme suivant présente une conception valide dans laquelle le domaine managé possède son propre
sous-réseau. Le sous-réseau de passerelle pour la connectivité externe et les charges de travail d’application sont dans un
sous-réseau connecté du réseau virtuel :
Connexions au réseau virtuel Azure AD DS

Comme indiqué dans la section précédente, vous pouvez uniquement créer un domaine managé dans un réseau virtuel
unique dans Azure et un seul domaine managé par locataire Azure AD. Si l’on se base sur cette architecture, vous devrez
peut-être connecter un ou plusieurs réseaux virtuels qui hébergent les charges de travail de votre application sur votre
réseau virtuel de domaine managé.
Vous pouvez connecter des charges de travail d’application hébergées sur d’autres réseaux virtuels Azure en utilisant l’une
des méthodes suivantes :
Peering de réseau virtuel

Réseau privé virtuel (VPN)
Peering de réseau virtuel

VNET Peering est un mécanisme permettant de connecter deux réseaux virtuels situés dans la même région via le réseau
principal Azure. Vous pouvez connecter des réseaux virtuels dans différentes régions à l’aide du peering de réseaux virtuels
mondiaux. Une fois homologués, les deux réseaux virtuels permettent aux ressources, telles que les machines virtuelles, de
communiquer directement entre elles à l’aide d’adresses IP privées. Le peering de réseaux virtuels vous permet de déployer
un domaine managé géré avec vos charges de travail d’applications déployées dans d’autres réseaux virtuels.
Pour plus d’informations, consultez la page Vue d’ensemble du peering du réseau virtuel Azure.
Réseau privé virtuel (VPN)

Vous pouvez connecter deux réseaux virtuels (connexion de réseau virtuel à réseau virtuel) de la même manière que vous
pouvez configurer un réseau virtuel à un emplacement de site local. Ces deux connexions font appel à une passerelle VPN
pour créer un tunnel sécurisé utilisant Ipsec/IKE. Ce modèle de connexion vous permet de déployer le domaine managé
dans un réseau virtuel Azure, puis de connecter des emplacements locaux ou d’autres clouds.
Pour plus d’informations sur l’utilisation de réseaux privés virtuels, consultez la page Configurer une connexion de
passerelle VPN de réseau virtuel à réseau virtuel à l’aide du portail Azure.
Résolution de noms lors de la connexion de réseaux virtuels

Les réseaux virtuels connectés au réseau virtuel du domaine managé disposent généralement de leurs propres paramètres
DNS. Lorsque vous connectez des réseaux virtuels, cela ne permet pas de configurer automatiquement la résolution de
noms du réseau virtuel en cours de connectés afin de résoudre les services fournis par le domaine managé. La résolution de
noms de réseaux virtuels en cours de connexion doit être configurée pour permettre aux charges de travail d’application de
localiser le domaine managé.
Vous pouvez activer la résolution de noms à l’aide de redirecteurs DNS conditionnels sur le serveur DNS qui prend en
charge les réseaux virtuels connectés, ou en utilisant les adresses IP DNS du réseau virtuel du domaine managé.
Ressources réseau utilisées par Azure AD DS

Un domaine managé crée des ressources réseau au cours du déploiement. Ces ressources sont nécessaires au bon
fonctionnement et à la bonne gestion du domaine managé et ne doivent pas être configurées manuellement.
Ne verrouillez pas les ressources de mise en réseau utilisées par Azure AD DS. Si les ressources de mise en réseau sont
verrouillées, elles ne peuvent pas être supprimées. Lorsque les contrôleurs de domaine doivent être reconstruits dans ce
cas, de nouvelles ressources de mise en réseau avec des adresses IP différentes doivent être créées.
Ressource Description
Azure
Ressource Description
Azure
Cartes Azure AD DS héberge le domaine managé sur deux contrôleurs de domaine (DC) qui s’exécutent sur Windows Server en
d'interface tant que machines virtuelles Azure. Chaque machine virtuelle dispose d’une interface réseau virtuelle qui se connecte à
réseau votre sous-réseau de réseau virtuel.
Adresse IP Azure AD DS communique avec le service de synchronisation et de gestion à l’aide d’une adresse IP publique de
publique référence SKU standard. Pour plus d’informations sur les adresse IP publique, consultez la page Types d’adresses IP et
standard méthodes d’allocation dans Azure.
dynamique
Azure Azure AD DS utilise un équilibreur de charge de référence SKU standard pour la traduction d’adresses réseau (NAT) et
Standard l’équilibrage de charge (en cas d’utilisation avec le protocole LDAP sécurisé). Pour plus d’informations sur les équilibreurs
Load Balancer de charge Azure, consultez Qu’est-ce que Azure Load Balancer ?
Règles de Azure AD DS crée et utilise les règles NAT de trafic entrant sur l’équilibreur de charge pour une communication à distance
traduction PowerShell sécurisée. Si un équilibreur de charge de référence SKU standard est utilisé, il aura également une règle NAT
d’adresses sortante. Pour l’équilibreur de charge de référence SKU de base, aucune règle NAT sortante n’est requise.
réseau (NAT)
Règles Quand un domaine managé est configuré pour le LDAP sécurisé sur le port TCP 636, trois règles sont créées et utilisées
d'équilibrage sur un équilibreur de charge pour répartir le trafic.
de charge
２ Avertissement
Ne supprimez ni ne modifiez aucune des ressources réseau créées par Azure AD DS, telles que la configuration
manuelle de l’équilibreur de charge ou des règles. Si vous supprimez ou modifiez l’une des ressources réseau, le
service Azure AD DS peut être interrompu.
Groupes de sécurité réseau et ports requis

Un groupe de sécurité réseau (NSG) contient une liste des règles qui autorisent ou refusent le trafic réseau vers un réseau
virtuel Azure. Lorsque vous déployez un domaine managé, un groupe de sécurité réseau est créé avec un ensemble de
règles permettant au service de fournir des fonctions d’authentification et de gestion. Ce groupe de sécurité réseau par
défaut est associé au sous-réseau de réseau virtuel dans lequel votre domaine managé est déployé.
Les sections suivantes traitent des groupes de sécurité réseau et des exigences relatives aux ports entrants et sortants.
Connectivité entrante
Les règles entrantes de groupe de sécurité réseau suivantes sont requises pour permettre au domaine managé de fournir
des services d’authentification et de gestion. Ne modifiez pas et ne supprimez pas ces règles de groupe de sécurité réseau
pour le sous-réseau de réseau virtuel pour votre domaine managé.
Source Balise du service source Source Destination Service Plages de Protocol Action Obligatoire Objectif
port ports de
ranges destination
Balise AzureActiveDirectoryDomainServices * Quelconque WinRM 5986 TCP Allow Oui Gestion

du de votre
service domaine.
Balise CorpNetSaw * Quelconque RDP 3389 TCP Allow Facultatif Débogage

du pour la
service prise en
charge
Notez que l’étiquette de service CorpNetSaw n’est pas disponible à l’aide de Portail Azure, tout comme la règle de groupe
de sécurité réseau pour CorpNetSaw doit être ajoutée à l’aide de PowerShell.
Azure AD DS s’appuie également sur les règles de sécurité par défaut AllowVnetInBound et
AllowAzureLoadBalancerInBound.
Capture d’écran des règles du groupe de sécurité réseau.
La règle AllowVnetInBound autorise tout le trafic au sein du réseau virtuel qui permet aux contrôleurs de domaine de
communiquer et de répliquer correctement, ainsi que d’autoriser la jonction de domaine et d’autres services de domaine
aux membres du domaine. Pour plus d'informations sur les ports requis pour Windows, consultez la Vue d'ensemble des
services et exigences de ports réseau pour Windows.
La règle AllowAzureLoadBalancerInBound est également requise afin que le service puisse communiquer correctement sur
l’équilibreur de charge pour gérer les contrôleurs de domaine. Ce groupe de sécurité réseau, qui sécurise Azure AD DS, est
nécessaire pour que le domaine managé fonctionne correctement. Ne supprimez pas ce groupe de sécurité réseau.
L’équilibreur de charge ne fonctionnera pas correctement sans ce groupe.
Si nécessaire, vous pouvez créer le groupe de sécurité réseau et les règles requis à l’aide d’Azure PowerShell.
２ Avertissement
Lorsque vous associez un groupe de sécurité réseau mal configuré ou une table d’itinéraire définie par l’utilisateur au
sous-réseau dans lequel le domaine managé est déployé, vous risquez de perturber la capacité de Microsoft à traiter
et à gérer le domaine. La synchronisation entre votre locataire Azure AD et votre domaine managé est également
interrompue. Suivez toutes les exigences répertoriées pour éviter une configuration non prise en charge qui risque de
perturber la synchronisation, les mises à jour correctives ou la gestion.
Si vous utilisez le protocole LDAP sécurisé, vous pouvez ajouter la règle de port TCP 636 requise pour autoriser le trafic
externe, si nécessaire. L’ajout de cette règle ne place pas vos règles de groupe de sécurité réseau dans un état non pris
en charge. Pour plus d’informations, consultez Verrouiller l’accès LDAP sécurisé via Internet.
Le SLA Azure ne s’applique pas aux déploiements qui sont bloqués pour les mises à jour ou la gestion par un groupe
de sécurité réseau mal configuré ou par une table de routage définie par l’utilisateur. Une configuration réseau
rompue peut également empêcher l’application des correctifs de sécurité.
Connectivité sortante
Pour une connectivité entrante, vous pouvez conserver AllowVnetOutbound et AllowInternetOutBound ou restreindre le
trafic sortant en utilisant les ServiceTags répertoriés dans le tableau suivant. Le ServiceTag pour AzureUpdateDelivery doit
être ajouté via PowerShell.
Numéro de port Protocol Source Destination Action Obligatoire Objectif

sortant
443 TCP Quelconque AzureActiveDirectoryDomainServices Allow Oui Communication avec le

service de gestion Azure
AD Domain Services.
443 TCP Quelconque AzureMonitor Allow Oui Analyse des machines

virtuelles.
443 TCP Quelconque Stockage Allow Oui Communication avec le

stockage Azure.
443 TCP Quelconque AzureActiveDirectory Allow Oui Communication avec

Azure Active Directory.
443 TCP Quelconque AzureUpdateDelivery Allow Oui Communication avec

Windows Update.
80 TCP Quelconque AzureFrontDoor.FirstParty Allow Oui Téléchargement des

correctifs à partir de
Windows Update.
Numéro de port Protocol Source Destination Action Obligatoire Objectif
sortant
443 TCP Quelconque GuestAndHybridManagement Allow Oui Gestion automatisée des

correctifs de sécurité.
Port 5986 – -gestion à l’aide de la communication à distance PowerShell

Utilisé pour effectuer des tâches de gestion à l’aide de la communication à distance PowerShell sur votre domaine
managé.
Sans accès à ce port, votre domaine managé ne peut pas être mis à jour, configuré, sauvegardé ou surveillé.
Vous pouvez limiter l'accès entrant à ce port avec l’étiquette de service AzureActiveDirectoryDomainServices.
Port 3389 – gestion à l’aide du bureau à distance

Utilisé pour les connexions Bureau à distance aux contrôleurs de domaine de votre domaine managé.
La règle de groupe de sécurité réseau par défaut utilise la balise de service CorpNetSaw pour restreindre davantage le
trafic.
Cette balise de service autorise uniquement les stations de travail à accès sécurisé sur le réseau d’entreprise
Microsoft à utiliser le bureau à distance pour le domaine managé.
L’accès est autorisé uniquement avec la justification métier, par exemple pour les scénarios de gestion ou de
résolution des problèmes.
Cette règle peut être définie sur Refuser et définie uniquement sur Autoriser quand cela est nécessaire. La plupart des
tâches de gestion et de surveillance sont effectuées à l’aide de la communication à distance PowerShell. Le RDP n'est
utilisé que dans les rares cas où Microsoft a besoin de se connecter à distance à votre domaine managé pour une
résolution des problèmes avancée.
Vous ne pouvez pas sélectionner manuellement la balise de service CorpNetSaw dans le portail si vous essayez de modifier
cette règle de groupe de sécurité réseau. Vous devez utiliser Azure PowerShell ou Azure CLI pour configurer manuellement
une règle qui utilise la balise de service CorpNetSaw.
Par exemple, vous pouvez utiliser le script suivant pour créer une règle autorisant le protocole RDP :
PowerShell
Get-AzNetworkSecurityGroup -Name "nsg-name" -ResourceGroupName "resource-group-name" | Add-

AzNetworkSecurityRuleConfig -Name "new-rule-name" -Access "Allow" -Protocol "TCP" -Direction "Inbound" -
Priority "priority-number" -SourceAddressPrefix "CorpNetSaw" -SourcePortRange "*" -DestinationPortRange
"3389" -DestinationAddressPrefix "*" | Set-AzNetworkSecurityGroup
Itinéraires définis par l’utilisateur

Les itinéraires définis par l’utilisateur ne sont pas créés par défaut et ne sont pas nécessaires au bon fonctionnement
d’Azure AD DS. Si vous devez utiliser des tables d’itinéraire, évitez de modifier l’itinéraire 0.0.0.0. Les modifications
apportées à cet itinéraire perturbent Azure AD Domain Services et place le domaine managé dans un état non pris en
charge.
Vous devez également acheminer le trafic entrant à partir des adresses IP incluses dans les balises de service Azure
respectives vers le sous-réseau du domaine managé. Pour plus d’informations sur les balises de service et leur adresse IP
associée , consultez la page Plages et balises de service Azure IP – Cloud public .
Ｕ Attention
Ces plages IP de centre de données Azure peuvent être modifiées sans préavis. Vérifiez que vous disposez des
processus vous permettant de valider que vous disposez des dernières adresses IP.
Étapes suivantes
Pour plus d’informations sur certaines ressources réseau et options de connexion utilisées par Azure AD DS, consultez les
articles suivants :
Peering de réseaux virtuels Azure

Passerelles VPN Azure
Groupes de sécurité réseau Azure
Qu’est-ce qu’Azure Active Directory ?
Article • 02/08/2023
Azure Active Directory (Azure AD) est un service de gestion des identités et des accès
basée sur le cloud. Azure AD permet à vos collaborateurs d’accéder à des ressources
externes telles que Microsoft 365, le portail Azure et des milliers d’autres applications
SaaS. Azure Active Directory les aide également à accéder aux ressources internes,
notamment les applications situées sur votre intranet d’entreprise et les applications
cloud développées pour votre organisation. Pour découvrir comment créer un locataire,
consultez Démarrage rapide : Créer un locataire dans Azure Active Directory.
Pour connaître les différences entre Active Directory et Azure Active Directory, consultez
Comparer Active Directory et Azure Active Directory. Vous pouvez également vous
reporter aux affiches de la série Microsoft Cloud pour architectes d’entreprise afin de
mieux comprendre les services d’identité de base dans Azure, comme Azure AD et
Microsoft 365.
Qui utilise Azure AD ?

Azure AD offre différents avantages aux membres de votre organisation en fonction de
leur rôle :
Les administrateurs informatiques utilisent Azure AD pour contrôler l’accès aux

applications et ressources en fonction des besoins métier. Par exemple, en tant
qu’administrateur informatique, vous pouvez utiliser Azure AD pour exiger que
l’accès aux ressources importantes de l’organisation soit soumis à l’authentification
multifacteur. Vous pouvez aussi utiliser Azure AD pour automatiser le
provisionnement des utilisateurs entre Windows Server AD et vos applications
cloud, notamment Microsoft 365. Azure AD vous offre enfin des outils puissants
pour vous aider à protéger automatiquement les identités et informations
d’identification des utilisateurs et à répondre à vos exigences en matière de
gouvernance. Pour commencer, inscrivez-vous pour essayer gratuitement Azure
Active Directory Premium pendant 30 jours .
Les développeurs d’applications peuvent utiliser Azure AD comme fournisseur

d’authentification basé sur des normes qui les aide à ajouter l’authentification
unique (SSO) aux applications qui fonctionnent avec les informations
d’identification d’utilisateur existantes. Les développeurs peuvent également
utiliser les API Azure AD pour créer des expériences personnalisées à l’aide de
données organisationnelles. Pour commencer, inscrivez-vous pour essayer
gratuitement Azure Active Directory Premium pendant 30 jours . Pour plus
d’informations, vous pouvez également consulter Azure Active Directory pour les
développeurs.
Les abonnés Microsoft 365, Office 365, Azure ou Dynamics CRM Online utilisent

déjà Azure AD, car chaque locataire Microsoft 365, Office 365, Azure et Dynamics
CRM Online est automatiquement un locataire Azure AD. Vous pouvez
immédiatement commencer à gérer l’accès à vos applications cloud intégrées.
Quelles sont les licences Azure AD ?

Les services professionnels en ligne de Microsoft comme Microsoft 365 ou Microsoft
Azure utilisent Azure AD pour les activités de connexion et la protection de vos
identités. Si vous vous abonnez à un service en ligne Microsoft pour entreprise, vous
disposez automatiquement d’un accès gratuit à Azure AD .
Pour enrichir votre implémentation Azure AD, vous pouvez ajouter des fonctionnalités
payantes en procédant à une mise à niveau vers les licences Azure Active Directory
Premium P1 ou Premium P2. Les licences payantes Azure AD s’appuient sur votre
annuaire gratuit existant. Les licences offrent un libre-service, une surveillance
améliorée, des rapports de sécurité et un accès sécurisé pour vos utilisateurs mobiles.
７ Notes
Pour connaître la structure de prix de ces licences, consultez les tarifs d’Azure
Active Directory .
Pour plus d’informations sur les tarifs d’Azure AD, contactez le forum Azure Active
Directory .
Azure Active Directory Free. Offre la gestion des utilisateurs et des groupes, la
synchronisation d’annuaires locaux, des rapports de base, des changements de
mot de passe en libre-service pour les utilisateurs cloud ainsi que l’authentification
unique sur Azure, Microsoft 365 et bon nombre d’applications SaaS populaires.
Azure Active Directory Premium P1. En plus des fonctionnalités Free, la licence P1
offre à vos utilisateurs hybrides l’accès aux ressources locales et cloud. Elle prend
également en charge des fonctionnalités administratives avancées, notamment les
groupes dynamiques, la gestion de groupes libre-service, Microsoft Identity
Manager et la réécriture dans le cloud pour faire bénéficier à vos utilisateurs locaux
de la réinitialisation de mot de passe en libre-service.
Azure Active Directory Premium P2. En plus des fonctionnalités Free et P1, la
licence P2 offre Azure Active Directory Identity Protection pour fournir un accès
conditionnel en fonction des risques à vos applications et aux données critiques de
l’entreprise. Elle propose également Privileged Identity Management pour faciliter
la découverte, la restriction et la supervision des administrateurs et leur accès aux
ressources et, au besoin, fournir un accès juste-à-temps.
Licences pour les fonctionnalités avec « paiement à l’utilisation ». Vous pouvez

également obtenir des licences pour des fonctionnalités, par exemple Azure Active
Directory B2C (entreprise-client). B2C peut vous aider à doter vos applications
orientées clients de solutions de gestion des identités et des accès. Pour plus
d’informations, consultez la documentation sur Azure Active Directory B2C.
Pour plus d’informations sur l’association d’un abonnement Azure à Azure AD, consultez
Associer ou ajouter un abonnement Azure à Azure Active Directory. Pour plus
d’informations sur l’attribution de licences à vos utilisateurs, consultez Guide pratique :
affecter ou supprimer des licences Azure Active Directory.
Quelles sont les fonctionnalités disponibles

dans Azure AD ?
Après avoir choisi votre licence Azure AD, vous avez accès à une partie ou à la totalité
des fonctionnalités suivantes :
Category Description
Gestion des Gérez vos applications cloud et locales avec le proxy d’application,
applications l’authentification unique, le portail Mes applications et les applications
SaaS (software as a service). Pour plus d’informations, consultez Guide
pratique pour offrir un accès à distance sécurisé aux applications locales
et la documentation sur la gestion des applications.
Authentification Gérez la réinitialisation de mot de passe libre-service Azure Active

Directory, l’authentification multifacteur, la liste de mots de passe interdits
et le verrouillage intelligent. Pour plus d’informations, consultez la
documentation sur Azure AD Authentication.
Azure Active Créez des applications qui connectent toutes les identités Microsoft et
Directory pour les obtiennent des jetons pour appeler Microsoft Graph, d’autres API
développeurs Microsoft ou des API personnalisées. Pour plus d’informations, consultez
Plateforme d’identités Microsoft (Azure Active Directory pour
développeurs).
Entreprise-entreprise Gérez vos utilisateurs invités et partenaires externes tout en conservant le

(B2B) contrôle de vos données d’entreprise. Pour plus d’informations, consultez
la documentation sur Azure Active Directory B2B.
Entreprise-client Personnalisez et contrôlez la façon dont les utilisateurs s’inscrivent, se

(B2C) connectent et gèrent leurs profils quand ils utilisent vos applications. Pour
plus d’informations, consultez la documentation sur Azure Active
Directory B2C.
Accès conditionnel Gérez l’accès à vos applications cloud. Pour plus d’informations, consultez
la documentation sur l’accès conditionnel dans Azure AD.
Gestion des Gérez la façon dont vos appareils cloud ou locaux accèdent à vos données
appareils d’entreprise. Pour plus d’informations, consultez la documentation sur la
gestion des appareils Azure AD.
Services de domaine Joignez des machines virtuelles Azure à un domaine sans contrôleur de
domaine. Pour plus d’informations, consultez la documentation sur
Azure AD Domain Services.
Utilisateurs Gérez les attributions de licences, accédez à des applications et configurez

d’entreprise des délégués à l’aide de groupes et de rôles d’administrateur. Pour plus
d’informations, consultez la documentation sur la gestion des utilisateurs
Identité hybride Utilisez Azure Active Directory Connect et Connect Health pour fournir
une identité d’utilisateur unique pour l’authentification et l’autorisation
auprès de toutes les ressources, indépendamment de l’emplacement
(cloud ou local). Pour plus d’informations, consultez la documentation sur
les identités hybrides.
Gouvernance des Gérez l’identité de votre organisation au moyen de contrôles d’accès pour
identités vos employés, partenaires commerciaux, fournisseurs, services et
applications. Vous pouvez également effectuer des révisions d’accès. Pour
plus d’informations, consultez la documentation sur Azure AD Identity
Governance et Révisions d’accès Azure AD.
Identity Protection Détectez les vulnérabilités potentielles qui affectent les identités de votre
organisation, configurez des stratégies pour répondre aux actions
suspectes et prenez les mesures appropriées pour les résoudre. Pour plus
d’informations, consultez Azure AD Identity Protection.
Identités gérées Fournissez à vos services Azure une identité managée automatiquement
pour les ressources dans Azure AD qui peut authentifier n’importe quel service
Azure d’authentification pris en charge par Azure AD, notamment Key Vault.
Pour plus d’informations, consultez Identités managées pour les
ressources Azure.
Privileged Identity Gérez, contrôlez et supervisez l’accès au sein de votre organisation. Cette
Management (PIM) fonctionnalité inclut l’accès aux ressources dans Azure AD et Azure, ainsi
qu’à d’autres services Microsoft Online, comme Microsoft 365 ou Intune.
Pour plus d’informations, consultez Qu’est-ce qu’Azure AD Privileged

Identity Management ?.
Rapports et analyse Obtenez des insights sur la sécurité et les modèles d’utilisation de votre
environnement. Pour plus d’informations, consultez Rapports et
supervision Azure Active Directory.
Identités de charge Il s’agit d’une identité utilisée par une charge de travail logicielle (telle
de travail qu’une application, un service, un script ou un conteneur) pour
authentifier et accéder à d’autres services et ressources. Pour plus
d’informations, consultez la F.A.Q. de l’identité de charge de travail.
Terminologie
Pour mieux comprendre Azure AD et sa documentation, nous vous recommandons de
passer en revue les termes suivants.
Terme ou Description
concept
Identité Une chose qui peut être authentifiée. Une identité peut être un utilisateur
avec un nom d’utilisateur et un mot de passe. Les identités incluent
également des applications ou autres serveurs qui peuvent nécessiter
l’authentification via des clés secrètes ou des certificats.
Compte Une identité qui a des données associées. Vous ne pouvez pas avoir de
compte sans identité.
Compte Identité créée par le biais d’Azure AD ou d’un autre service cloud Microsoft
Azure AD comme Microsoft 365. Les identités sont stockées dans Azure AD et sont
accessibles à tout abonnement à un service cloud de votre organisation. Ce
compte est parfois appelé un compte professionnel ou scolaire.
Administrateur Ce rôle d’administrateur d’abonnement classique est théoriquement le

de comptes propriétaire du compte de facturation d’un abonnement. Ce rôle permet de
gérer tous les abonnements d’un compte. Si vous souhaitez en savoir plus,
veuillez consulter la rubrique Rôles d’administrateur de rôles Azure, de rôles
Azure AD et d’abonnements classiques.
Administrateur Ce rôle d’administrateur d’abonnement classique vous permet de gérer toutes

de services les ressources Azure, notamment l’accès à celles-ci. Ce rôle a un droit d’accès
équivalent à celui d’un utilisateur qui se voit attribuer le rôle Propriétaire au
niveau de l’étendue de l’abonnement. Si vous souhaitez en savoir plus,
veuillez consulter la rubrique Rôles d’administrateur de rôles Azure, de rôles
Azure AD et d’abonnements classiques.
concept
Propriétaire Ce rôle vous permet de gérer toutes les ressources Azure, notamment l’accès
à celles-ci. Ce rôle est basé sur un système d’autorisation plus récent appelé
« contrôle d’accès en fonction du rôle Azure » (Azure RBAC) qui permet de
gérer avec précision l’accès aux ressources Azure. Si vous souhaitez en savoir
plus, veuillez consulter la rubrique Rôles d’administrateur de rôles Azure, de
rôles Azure AD et d’abonnements classiques.
Administrateur Ce rôle d’administrateur est automatiquement attribué au créateur du

général Azure locataire Azure AD. Vous pouvez avoir plusieurs administrateurs généraux,
AD mais seuls les administrateurs généraux peuvent attribuer des rôles
d’administrateur (notamment d’autres rôles Administrateur général) aux
utilisateurs. Pour plus d’informations sur les rôles d’administrateur, consultez
Autorisations de rôles d’administrateur dans Azure Active Directory.
Abonnement Permet de payer les services cloud Azure. Vous pouvez avoir plusieurs
Azure abonnements, lesquels sont liés à une carte de crédit.
Client Azure Une instance dédiée et approuvée d’Azure AD. Le locataire est
automatiquement créé quand votre organisation s’inscrit à un abonnement
de service cloud Microsoft. Ces abonnements comprennent Microsoft Azure,
Microsoft Intune ou Microsoft 365. Un locataire Azure représente une seule
organisation.
Locataire unique Un locataire Azure qui accède à d’autres services dans un environnement
dédié est considéré comme un locataire unique.
Multi-locataire Les locataires Azure qui accèdent à d’autres services dans un environnement
partagé entre plusieurs organisations sont considérés comme multilocataires.
Annuaire Chaque locataire Azure a un annuaire Azure AD dédié et approuvé. L’annuaire

Azure AD Azure AD inclut les utilisateurs, groupes et applications du locataire. Il permet
d’effectuer les fonctions de gestion des identités et des accès pour les
ressources des locataires.
Domaine Chaque nouvel annuaire Azure AD est fourni avec un nom de domaine initial,
personnalisé par exemple domainname.onmicrosoft.com . En plus de ce nom initial, vous
pouvez également ajouter les noms de domaine de votre organisation. Les
noms de domaine de votre organisation incluent les noms que vous utilisez
pour votre activité et que vos utilisateurs utilisent pour accéder aux ressources
de votre organisation, à la liste. L’ajout de noms de domaine personnalisés
vous permet de créer des noms d’utilisateur qui sont familiers à vos
utilisateurs, par exemple alain@contoso.com.
Compte Comptes personnels qui permettent d’accéder à vos produits et services

Microsoft cloud Microsoft orientés consommateur. Ces produits et services
(également comprennent Outlook, OneDrive, Xbox LIVE ou Microsoft 365. Votre compte
appelé MSA)
concept
Microsoft est créé et stocké dans le système de comptes d’identité des

consommateurs de Microsoft.
Étapes suivantes
S’inscrire à Azure Active Directory Premium
Associer un abonnement Azure à votre annuaire Azure Active Directory
Check-list pour le déploiement des fonctionnalités d’Azure Active Directory

Premium P2
Qu’est-ce que l’architecture Azure Active
Directory ?
Article • 28/07/2023
Azure Active Directory (Azure AD) vous permet de gérer en toute sécurité l’accès aux
ressources et aux services Azure pour vos utilisateurs. Azure AD comprend une suite
complète de fonctionnalités de gestion des identités. Pour plus d’informations sur les
fonctionnalités d’Azure AD, voir Qu’est Azure Active Directory ?
Azure AD permet de créer et de gérer des utilisateurs et des groupes, et d’activer des
autorisations pour octroyer et refuser l’accès aux ressources d’entreprise. Pour plus
d’informations sur la gestion des identités, voir Principes de base de la gestion des
identités Azure.
Architecture Azure AD
L’architecture distribuée géographiquement d’Azure AD combine des fonctionnalités de
surveillance complète, de redirection automatique, de basculement et de récupération
qui apportent disponibilité et performances à l’échelle de l’entreprise.
Les éléments d’architecture suivants sont traités dans cet article :
Conception de l’architecture de service

Extensibilité
Disponibilité continue
Centres de données
Conception de l’architecture de service

La méthode la plus courante pour créer un système riche en données, accessible et
pratique, consiste à s’appuyer sur des éléments fondamentaux indépendants : des unités
d’échelle. Au niveau des données Azure AD, les unités d’échelle s’appellent des
partitions.
Le niveau de données possède plusieurs services frontaux offrant une fonctionnalité de

lecture-écriture. Le diagramme suivant montre comment les composants d’une partition
à répertoire unique sont délivrés entre des centres de données géographiquement
distribués.
Les composants de l’architecture Azure AD incluent un réplica principal et des réplicas
secondaires.
Réplica principal
Le réplica principal reçoit tous les écrits pour la partition à laquelle il appartient. Toute
opération d’écriture est immédiatement répliquée vers un réplica secondaire dans un
autre centre de données avant de renvoyer une notification de réussite à l’appelant, afin
de garantir la durabilité géo-redondante des écritures.
Réplicas secondaires
Toutes les lectures de répertoire sont traitées à partir des réplicas secondaires qui se
trouvent dans des centres de données répartis entre différentes zones géographiques. Il
existe plusieurs réplicas secondaires, car les données sont répliquées de manière
asynchrone. Les lectures de répertoire, notamment les requêtes d’authentification, sont
traitées à partir de centres de données proches des clients. Les réplicas secondaires sont
responsables de l’évolutivité de lecture.
Extensibilité
L’évolutivité est la capacité d’un service à se développer pour répondre aux exigences
croissantes en matière de performances. L’évolutivité d’écriture est obtenue en
partitionnant les données. L’évolutivité de lecture est obtenue en répliquant les données
d’une partition vers plusieurs réplicas secondaires répartis dans le monde.
Les requêtes à partir d’applications d’annuaire sont routées vers le centre de données le
plus proche. Les écritures sont redirigées en toute transparence vers le réplica principal
pour assurer la cohérence en lecture-écriture. Les réplicas secondaires développent de
manière significative l’échelle des partitions, car les répertoires traitent généralement les
lectures.
Les applications de répertoire se connectent aux centres de données les plus proches.
Cette connexion améliore les performances, et une montée en charge devient donc
possible. Dans la mesure où une partition de répertoire peut avoir plusieurs réplicas
secondaires, ces derniers peuvent être placés plus près des clients de répertoire. Seuls
les composants de service de répertoire interne gourmands en écriture ciblent
directement le réplica principal actif.
Disponibilité continue
La disponibilité (ou le temps d’activité) définit la capacité d’un système à s’exécuter sans
interruption. La haute disponibilité d’Azure AD s’appuie sur le fait que les services
peuvent transmettre rapidement le trafic entre plusieurs centres de données répartis
géographiquement. Chaque centre de données est indépendant, ce qui permet les
modes d’échec décorrélés. Dans cette conception haute disponibilité, Azure AD n’exige
aucun temps d’arrêt pour les activités de maintenance.
La conception de partition Azure AD est simplifiée par rapport à la conception d’AD

entreprise, grâce à une conception principale unique qui inclut un processus de
basculement du réplica principal soigneusement orchestré et déterministe.
Tolérance de panne
Un système est plus disponible s’il est tolérant aux pannes de matériel, de logiciel et de
réseau. Pour chaque partition sur le répertoire, il existe un réplica maître hautement
disponible : le réplica principal. Seules les écritures sur la partition sont effectuées sur ce
réplica. Ce réplica est en cours de surveillance étroite et continue, et les écritures
peuvent être basculées immédiatement vers un autre réplica (qui devient alors le
nouveau réplica) si une défaillance est détectée. Pendant le basculement, une perte de
disponibilité de l’écriture de 1 à 2 minutes est possible. La disponibilité de lecture n’est
pas affectée pendant cette période.
Les opérations de lecture (largement supérieures aux opérations d’écriture) s’effectuent

uniquement dans les réplicas secondaires. Étant donné que les réplicas secondaires sont
idempotents, la perte d’un réplica dans une partition donnée est facilement compensée
en dirigeant les lectures vers un autre réplica, généralement situé dans le même centre
de données.
Durabilité des données
Avant d’être acceptée, une écriture doit être validée durablement sur au moins deux
centres de données. Cela se produit lorsque vous commencez par valider l’écriture sur le
serveur principal et que vous répliquez immédiatement l’écriture dans au moins l’un des
autres centres de données. Grâce à cette action d’écriture, le risque de perte
catastrophique du centre de données hébergeant le réplica principal n’entraîne pas de
perte de données.
Azure AD maintient un objectif de délai de récupération (RTO) de zéro pour ne pas

perdre de données lors des basculements. notamment :
Émission de jeton et lectures de répertoire

RTO de 5 minutes environ seulement possible pour les écritures de répertoire
Centres de données
Les réplicas d’Azure AD sont stockés dans des centres du monde entier. Pour plus
d’informations, consultez l’article Infrastructure globale Azure .
Azure AD fonctionne dans les centres de données avec les caractéristiques suivantes :
Les services AD Authentication, Graph et autres se trouvent derrière le service de

passerelle. La passerelle gère l’équilibrage de charge de ces services. Elle bascule
automatiquement si des serveurs défaillants sont détectés par les sondes
d’intégrité transactionnelles. En fonction de ces sondes d’intégrité, la passerelle
achemine dynamiquement le trafic vers les centres de données sains.
Pour les lectures, le répertoire possède des réplicas secondaires et des services
frontaux correspondants dans une configuration en mode actif/actif opérant dans
plusieurs centres de données. En cas de défaillance d’un centre de données, le
trafic est automatiquement routé vers un autre centre de données.
Pour les écritures, l’annuaire bascule le réplica principal entre les centres de
données par le biais des procédures de basculement planifié (le nouveau réplica
principal est synchronisé avec l’ancien) ou d’urgence. La durabilité des données est
obtenue en répliquant toute validation vers au moins deux centres de données.
Cohérence des données

Le modèle de répertoire est l’une des cohérences finales. Un problème classique avec les
systèmes de réplication distribués asynchrones est que les données renvoyées à partir
d’un réplica « spécifique » ne sont peut-être pas à jour.
Azure AD fournit une cohérence en lecture-écriture pour les applications qui ciblent un
réplica secondaire en routant ses écritures vers le réplica principal et en extrayant
simultanément les écritures sur le réplica secondaire.
Les écritures d’application utilisant l’API Microsoft Graph d’Azure AD n’ont pas à
conserver des affinités avec le réplica de répertoire pour la cohérence en lecture-
écriture. Le service API Microsoft Graph conserve une session logique qui a une affinité
avec un réplica secondaire utilisé pour les lectures. L’affinité est capturée dans un « jeton
de réplica » mis en cache par le service à l’aide d’un cache distribué dans le centre de
données de réplica secondaire. Ce jeton est ensuite utilisé pour les opérations suivantes
dans la même session logique. Pour continuer à utiliser la même session logique, les
demandes suivantes doivent être acheminées vers le même centre de données Azure
AD. Vous ne pouvez pas poursuivre une session logique si les requêtes client d’annuaire
sont routées vers plusieurs centres de données Azure AD. Dans cette situation, le client a
plusieurs sessions logiques présentant des cohérences en lecture-écriture
indépendantes.
７ Notes
Les écritures sont immédiatement répliquées sur le réplica secondaire pour lequel
les lectures de la session logique ont été émises.
Sauvegarde au niveau du service
Azure AD implémente la sauvegarde quotidienne des données de l’annuaire, et peut

utiliser ces sauvegardes pour restaurer les données en cas de problème à l’échelle du
service.
Le répertoire implémente également des suppressions réversibles au lieu de

suppressions définitives pour certains types d’objets. L’administrateur client peut
annuler toute suppression accidentelle de ces objets dans les 30 jours. Pour plus
d’informations, consultez l’API pour restaurer des objets supprimés.
Métriques et supervision
L’exécution d’un service haute disponibilité requiert des mesures et des capacités
d’analyse hautes performances. Azure AD analyse et signale en permanence les mesures
d’intégrité des services clés et les critères de réussite pour chacun de ses services. Nous
développons et affinons en permanence les mesures, surveillant et alertant pour chaque
scénario au sein de chaque service Azure AD, mais aussi sur tous les autres services.
Si un quelconque service Azure AD ne fonctionne pas comme prévu, les mesures

nécessaires à sa restauration sont prises immédiatement. La mesure la plus importante
suivie par Azure AD est la vitesse à laquelle un problème sur site peut être détecté et
résolu. Nous investissons massivement dans la surveillance et les alertes pour réduire le
temps de détection (cible TTD : <5 minutes)et dans la disponibilité opérationnelle pour
réduire le temps de résolution (cible TTM : <30 minutes).
Opérations sécurisées
Utilisation de contrôles opérationnels, tels que l’authentification multifacteur (MFA) pour

toute opération, et audit de toutes les opérations. Utilisation également et en
permanence d’un système d’élévation juste-à-temps pour accorder l’accès temporaire
nécessaire à toute tâche opérationnelle à la demande. Pour plus d’informations, voir
Cloud de confiance .
Étapes suivantes
Guide du développeur Azure Active Directory
Configuration de la synchronisation à
étendue limitée entre Azure AD et Azure
l’aide du Portail Azure
Pour assurer des services d’authentification, Azure Active Directory Domain Services
(Azure AD DS) synchronise les utilisateurs et les groupes à partir d’Azure AD. Dans un
environnement hybride, les utilisateurs et les groupes d’un environnement Active
Directory Domain Services (AD DS) local peuvent d’abord être synchronisés avec Azure
AD à l’aide d’Azure AD Connect, puis avec un domaine managé Azure AD DS.
avec un domaine managé. Si seuls certains utilisateurs ont besoin d’utiliser Azure AD DS,
vous pouvez choisir de synchroniser uniquement des groupes d’utilisateurs. Vous
pouvez filtrer la synchronisation pour les groupes locaux, cloud uniquement ou les deux.
Cet article explique comment configurer la synchronisation à étendue limitée, puis

modifier ou désactiver l’ensemble des utilisateurs inclus à l’aide du Portail Azure. Vous
pouvez également suivre cette procédure avec PowerShell.
Avant de commencer
Administrateur de groupes dans votre locataire pour modifier l’étendue de
synchronisation Azure AD DS.
Vue d’ensemble de la synchronisation délimitée
avec un domaine managé. Vous pouvez limiter la synchronisation aux comptes
d’utilisateur créés dans Azure AD ou synchroniser tous les utilisateurs.
Si seulement quelques groupes d’utilisateurs ont besoin d’accéder au domaine managé,

vous pouvez sélectionner Filtrer par droit de groupe pour synchroniser uniquement ces
groupes. Cette synchronisation délimitée est basée sur les groupes uniquement. Quand
vous configurez la synchronisation délimitée basée sur les groupes, seuls les comptes
d’utilisateurs qui appartiennent aux groupes que vous spécifiez sont synchronisés avec
le domaine managé. Les groupes imbriqués ne sont pas synchronisés ; seuls les groupes
que vous spécifiez le sont.
Vous pouvez modifier l’étendue de synchronisation avant ou après la création du

domaine managé. L’étendue de la synchronisation est définie par un principal de service
avec l’identificateur d’application 2565bd9d-da50-47d4-8b85-4c97f669dc36. Pour éviter
toute perte d’étendue, ne supprimez pas ou ne modifiez pas le principal du service. Si ce
dernier supprimé par accident, l’étendue de synchronisation ne peut pas être récupérée.
Gardez à l’esprit les avertissements suivants si vous modifiez l’étendue de

synchronisation :
Une synchronisation complète se produit.

Les objets qui ne sont plus requis dans le domaine managé sont supprimés. De
nouveaux objets sont créés dans le domaine managé.

Activation de la synchronisation à étendue

limitée
Pour activer la synchronisation à étendue limitée sur le Portail Azure, procédez comme
suit :

Choisissez votre domaine managé, par exemple aaddscontoso.com.
2. Sélectionnez Synchronisation dans le menu de gauche.
3. Pour Étendue de synchronisation, sélectionnez Tout ou Cloud uniquement.

4. Pour filtrer la synchronisation des groupes sélectionnés, cliquez sur Afficher les
groupes sélectionnés, choisissez de synchroniser les groupes cloud uniquement,
les groupes locaux ou les deux. Par exemple, la capture d’écran suivante montre
comment synchroniser uniquement trois groupes créés dans Azure AD. Seuls les
utilisateurs qui appartiennent à ces groupes auront leurs comptes synchronisés
avec Azure AD DS.
5. Pour ajouter des groupes, cliquez sur Ajouter des groupes, puis recherchez et
choisissez les groupes à ajouter.
6. Une fois que toutes les modifications ont été apportées, sélectionnez Enregistrer
l’étendue de la synchronisation.

domaine managé sont supprimés ; la resynchronisation est susceptible de prendre du
temps.
Modifier la synchronisation délimitée

Pour modifier la liste des groupes dont les utilisateurs doivent être synchronisés avec le
domaine managé, effectuez les étapes suivantes :

3. Pour ajouter un groupe, choisissez + Ajouter des groupes dans la partie
supérieure, puis choisissez les groupes à ajouter.
4. Pour supprimer un groupe de l’étendue de la synchronisation, sélectionnez-le dans
la liste des groupes actuellement synchronisés et choisissez Supprimer les
groupes.
5. Une fois que toutes les modifications ont été apportées, sélectionnez Enregistrer
l’étendue de la synchronisation.

temps.
Désactiver la synchronisation délimitée

Pour désactiver la synchronisation délimitée basée sur les groupes pour un domaine
managé, effectuez les étapes suivantes :

3. Désélectionnez la case à cocher Afficher les groupes sélectionnés, puis cliquez sur
Enregistrer l’étendue de synchronisation.

temps.
Étapes suivantes
Créer une unité d’organisation (UO) sur
un domaine dans un domaine managé
Article • 01/06/2023
Les unités d’organisation (UO) dans un domaine managé Active Directory Domain
Services (AD DS) vous permettent de regrouper logiquement des objets tels que des
comptes d’utilisateur, des comptes de service ou des comptes d’ordinateur. Vous
pouvez ensuite affecter des administrateurs à des unités d’organisation spécifiques et
appliquer une stratégie de groupe, donc des paramètres de configuration ciblés.
Les domaines managés Azure AD DS incluent les deux UO intégrées suivantes :
Ordinateurs AADDC : contient des objets ordinateur associés à tous les ordinateurs
qui sont joints au domaine managé.
Utilisateurs AADDC : comprend les utilisateurs et les groupes qui y sont
synchronisés à partir du locataire Azure AD.
Lors de la création et de l’exécution des charges de travail utilisant Azure AD DS, vous
devrez peut-être créer des comptes de service pour que les applications s’authentifient
elles-mêmes. Pour organiser ces comptes de service, vous créez souvent une unité
d’organisation personnalisée dans le domaine managé, puis des comptes de service au
sein de cette unité d’organisation.
Dans un environnement hybride, les unités d’organisation créées dans un

environnement AD DS local ne sont pas synchronisées avec le domaine managé. Les
domaines managés utilisent une structure d’unité d’organisation plate. Tous les comptes
d’utilisateurs et les groupes sont stockés dans le conteneur Utilisateurs AADDC, en dépit
de la synchronisation effectuée à partir de forêts ou de domaines locaux différents,
même si vous y avez configuré une structure d’unités d’organisation hiérarchique.
Cet article vous explique comment créer une UO dans votre domaine géré.
Avant de commencer
Une machine virtuelle de gestion Windows Server jointe au domaine managé
Azure AD DS.
Si nécessaire, suivez le tutoriel Créer une machine virtuelle de gestion.
Considérations et limitations relatives aux

unités d’organisation personnalisées
Lorsque vous créez des unités d’organisation personnalisées dans un domaine managé,
vous bénéficiez d’une plus grande souplesse de gestion pour la gestion des utilisateurs
et l’application de la stratégie de groupe. Par rapport à un environnement AD DS local, il
existe certaines limitations et considérations à prendre en compte lors de la création et
de la gestion d’une structure d’unité d’organisation personnalisée dans un domaine
managé :
Pour créer des unités d’organisation personnalisées, les utilisateurs doivent être
membres du groupe Administrateurs AAD DC.
Un utilisateur qui crée une unité d’organisation personnalisée se voit accorder des
privilèges d’administration (contrôle total) sur cette unité d’organisation et est le
propriétaire de la ressource.
Par défaut, le groupe Administrateurs AAD DC a également le contrôle total sur
l’unité d’organisation personnalisée.
Une unité d’organisation pour Utilisateurs AADDC est créée et contient tous les
comptes d’utilisateur synchronisés à partir de votre locataire Azure AD.
Vous ne pouvez pas déplacer des utilisateurs ou des groupes de l’unité
d’organisation Utilisateurs AADDC vers des unités d’organisation personnalisées
que vous créez. Seuls les comptes d’utilisateurs ou les ressources créés dans le
domaine managé peuvent être déplacés dans des unités d’organisation
personnalisées.
Les comptes d’utilisateur, groupes, comptes de service et objets ordinateur que
vous créez dans des unités d’organisation personnalisées ne sont pas disponibles
Ces objets n’apparaissent pas à l’aide de l’API Microsoft Graph ou dans
l’interface utilisateur Azure AD ; ils sont uniquement disponibles dans votre
domaine managé.
Créer une unité d’organisation personnalisée

Pour créer une unité d’organisation personnalisée, vous utilisez les outils
d’administration Active Directory à partir d’une machine virtuelle jointe à un domaine. Le
Centre d’administration Active Directory vous permet d’afficher, de modifier et de créer
des ressources dans un domaine managé, notamment des unités d’organisation.
７ Notes
Pour créer une unité d’organisation personnalisée dans un domaine managé, vous
devez être connecté à un compte d’utilisateur membre du groupe d
administrateurs du contrôleur de domaine AAD.
1. Connectez-vous à votre machine virtuelle de gestion. Pour connaître les différentes

étapes vous permettant de vous connecter au portail Azure, consultez la page Se
connecter à une machine virtuelle Windows Server.
2. Dans l’écran d’accueil, sélectionnez Outils d’administration. La liste des outils de

gestion disponibles qui ont été installés dans le tutoriel Créer une machine
virtuelle de gestion s’affiche à l’écran.
3. Pour créer et gérer des unités d’organisation, sélectionnez Centre d’administration

Active Directory dans la liste des outils d’administration.
4. Dans le volet de gauche, choisissez votre domaine managé, par exemple

aaddscontoso.com. Une liste des unités d’organisation et des ressources s’affiche :
5. Le volet Tâches s’affiche sur le côté droit du Centre d’administration Active
Directory. Sous le domaine, par exemple aaddscontoso.com, sélectionnez Nouveau
> Unité d’organisation.
6. Dans la boîte de dialogue Créer une unité d’organisation, indiquez un Nom pour
la nouvelle unité d’organisation, par exemple MyCustomOu. Fournissez une brève
description de l’unité d’organisation, telle qu’unité d’organisation personnalisée
pour les comptes de service. Si vous le souhaitez, vous pouvez également
renseigner le champ Managée par de l’unité d’organisation. Sélectionnez OKpour
créer l’unité d’organisation personnalisée.
7. De retour dans le Centre d’administration Active Directory, l’unité d’organisation

personnalisée est désormais listée et peut être utilisée :
Étapes suivantes
Pour plus d’informations sur l’utilisation des outils d’administration ou la création et
l’utilisation de comptes de service, consultez les articles suivants :
Centre d'administration Active Directory : Prise en main

Guide pas à pas des comptes de service (éventuellement en anglais)
Créer un compte de service administré
de groupe (gMSA) dans Azure Active
Article • 01/06/2023
Les applications et les services ont souvent besoin d’une identité pour s’authentifier
auprès d’autres ressources. Par exemple, un service web peut avoir besoin de
s’authentifier auprès d’un service de base de données. Si une application ou un service
possède plusieurs instances, comme une batterie de serveurs web, la création et la
configuration manuelles des identités pour ces ressources prend beaucoup de temps.
À la place, il est possible de créer un compte de service administré de groupe (gMSA)

dans un domaine managé Azure Active Directory Domain Services (Azure AD DS). Le
système d’exploitation Windows gère automatiquement les informations d’identification
d’un gMSA, ce qui simplifie la gestion de grands groupes de ressources.
Cet article vous explique comment créer un gMSA dans un domaine managé à l’aide
d’Azure PowerShell.
Avant de commencer
Azure AD DS.
Vue d’ensemble des comptes de service
administrés
Un compte de service administré autonome (sMSA) est un compte de domaine dont le
mot de passe est managé automatiquement. Cette approche simplifie la gestion des
noms de principal du service (SPN) et permet de déléguer la gestion à d’autres
administrateurs. Vous n’avez pas besoin de créer et de faire tourner manuellement les
informations d’identification du compte.
Un compte de service administré de groupe (gMSA) offre la même simplification de la

gestion, mais pour plusieurs serveurs du domaine. Un gMSA permet à toutes les
instances d’un service hébergé sur une batterie de serveurs d’utiliser le même principal
de service pour que les protocoles d’authentification mutuelle fonctionnent. Lorsqu’un
compte de service administré de groupe (gMSA) est utilisé comme principal de service,
le système d’exploitation Windows gère à nouveau le mot de passe du compte au lieu
de compter sur l’administrateur.
Pour en savoir plus, consultez Vue d’ensemble des comptes de service administrés de
groupe (gMSA).
Utilisation des comptes de service dans Azure

AD DS
Comme les domaines managés sont verrouillés et managés par Microsoft, certaines
considérations sont à prendre en compte lors de l’utilisation de comptes de service :
Créez des comptes de service dans les unités d’organisation personnalisées d’un
domaine managé.
Vous ne pouvez pas créer de compte de service dans les unités d’organisation
intégrées Utilisateurs AADDC et Ordinateurs AADDC.
À la place, Créez une unité d’organisation personnalisée dans le domaine
managé, puis créez des comptes de service dans cette unité d’organisation.
La clé racine des services de distribution de clés (KDS) est précréée.
La clé racine KDS est utilisée pour générer et récupérer des mots de passe pour
les comptes de service administrés de groupe (gMSA). Dans Azure AD DS, la
racine KDS est créée pour vous.
Vous n’avez pas les privilèges nécessaires pour en créer un autre ou afficher la
clé racine KDS par défaut.
Créer un compte de service administré de
groupe (gMSA)
Tout d’abord, créez une unité d’organisation personnalisée à l’aide de la cmdlet New-
ADOrganizationalUnit. Pour plus d’informations sur la création et la gestion d’unités
d’organisation personnalisées, consultez Unités d’organisation personnalisées dans
Azure AD DS.
 Conseil
Pour effectuer ces étapes afin de créer un gMSA, utilisez votre machine virtuelle
de gestion. Cette machine virtuelle de gestion doit déjà disposer des applets de
commande AD PowerShell nécessaires et de la connexion au domaine géré.
L’exemple suivant crée une unité d’organisation personnalisée nommée myNewOU dans
le domaine managé nommé aaddscontoso.com. Utilisez votre unité d’organisation et
votre nom de domaine managé :
PowerShell
New-ADOrganizationalUnit -Name "myNewOU" -Path "DC=aaddscontoso,DC=COM"
Créez maintenant un compte de service administré de groupe (gMSA) à l’aide de la

cmdlet New-ADServiceAccount. Les exemples de paramètres suivants sont définis :
-Name est défini sur WebFarmSvc

Le paramètre -Path spécifie l’unité d’organisation personnalisée pour le compte de
service administré de groupe (gMSA) créé à l’étape précédente.
Les entrées DNS et les noms de principal de service sont définis pour
WebFarmSvc.aaddscontoso.com
Les principaux dans AADDSCONTOSO-SERVER$ sont autorisés à récupérer le mot
de passe et à utiliser l’identité.
Spécifiez vos propres noms et noms de domaine.
PowerShell
New-ADServiceAccount -Name WebFarmSvc `
-DNSHostName WebFarmSvc.aaddscontoso.com `
-Path "OU=MYNEWOU,DC=aaddscontoso,DC=com" `
-KerberosEncryptionType AES128, AES256 `
-ManagedPasswordIntervalInDays 30 `
-ServicePrincipalNames
http/WebFarmSvc.aaddscontoso.com/aaddscontoso.com, `
http/WebFarmSvc.aaddscontoso.com/aaddscontoso, `
http/WebFarmSvc/aaddscontoso.com, `
http/WebFarmSvc/aaddscontoso `
-PrincipalsAllowedToRetrieveManagedPassword AADDSCONTOSO-SERVER$
Les applications et les services peuvent maintenant être configurés pour utiliser le
compte de service administré de groupe (gMSA) en fonction des besoins.
Étapes suivantes
Pour en savoir plus sur les comptes de service administrés de groupe (gMSA), consultez
Prise en main des comptes de service administrés de groupe.
Administrer la stratégie de groupe dans
un domaine géré par Azure Active
Article • 01/06/2023
Les paramètres des objets utilisateur et ordinateur dans

Azure Active Directory Domain Services (Azure AD DS) sont souvent managés à l’aide
d’objets de stratégie de groupe (GPO). Azure AD DS inclut des objets de stratégie de
groupe intégrés pour les conteneurs Utilisateurs AADDC et Ordinateurs AADDC. Vous
pouvez personnaliser ces objets de stratégie de groupe intégrés pour configurer la
stratégie de groupe selon les besoins de votre environnement. Les membres du groupe
Administrateurs Azure AD DC disposent de privilèges d’administration de stratégie de
groupe pour le domaine managé Azure AD DS et peuvent également créer des objets
de stratégie de groupe et des unités d’organisation (OU) personnalisés. Pour plus
d’informations sur la stratégie de groupe et son fonctionnement, consultez la page Vue
d’ensemble de la stratégie de groupe.
Dans un environnement hybride, les stratégies de groupe configurées dans un

environnement AD DS local ne sont pas synchronisées avec Azure AD DS. Pour définir
les paramètres de configuration des utilisateurs ou des ordinateurs dans Azure AD DS,
modifiez l’un des objets de stratégie de groupe par défaut ou créez un objet de
stratégie de groupe personnalisé.
Cet article indique comment installer les outils de gestion de stratégie de groupe,
modifier les objets de stratégie de groupe intégrés et créer des objets de stratégie de
groupe personnalisés.
Si vous vous intéressez à la stratégie de gestion des serveurs, y compris les machines
Azure et hybrides connectées, pensez à lire sur l’article sur la fonctionnalité
configuration Invité d’Azure Policy.
Avant de commencer
Azure AD DS.
Si nécessaire, suivez les étapes du tutoriel pour créer et joindre une machine
７ Notes
Vous pouvez utiliser des modèles d'administration de stratégies de groupe en

copiant les nouveaux modèles sur la station de travail de gestion. Copiez les fichiers
.admx sous %SYSTEMROOT%\PolicyDefinitions et copiez les fichiers .adml spécifiques
à l'environnement local sous %SYSTEMROOT%\PolicyDefinitions\[Language-
CountryRegion] , sachant que Language-CountryRegion correspond à la langue et à la
région des fichiers .adml.
Par exemple, copiez la version Anglais (États-Unis) des fichiers .adml dans le dossier
\en-us .
Installez les outils de gestion de stratégie de

groupe
Pour créer et configurer les objets de stratégie de groupe (GPO), vous devez installer les
outils de gestion de stratégie de groupe. Ces outils peuvent être installés en tant que
fonctionnalité de Windows Server. Pour plus d’informations sur l’installation des outils
d’administration sur un client Windows, consultez Installer les outils d’administration de
serveur distant.

2. Le Gestionnaire de serveur doit s’ouvrir par défaut quand vous vous connectez à
la machine virtuelle. Si ce n’est pas le cas, dans le menu Démarrer, sélectionnez
Gestionnaire de serveur.



8. Sur la page Fonctionnalités, sélectionnez la fonctionnalité Gestion des stratégies

de groupe.
9. Dans la page Confirmation, sélectionnez Installer. L’installation des outils de

gestion des stratégies de groupe peut prendre une ou deux minutes.

Ouvrez la Console de gestion des stratégies de
groupe et modifiez un objet
Il existe des objets de stratégie de groupe (GPO) par défaut pour les utilisateurs et les
ordinateurs dans un domaine managé. La fonctionnalité de gestion des stratégie de
groupe étant installée grâce à la section précédente, nous allons pouvoir afficher et
modifier un objet de stratégie de groupe existant. Dans la section suivante, vous allez
créer un objet de stratégie de groupe personnalisé.
７ Notes
Pour administrer une stratégie de groupe dans un domaine managé, vous devez
être connecté à un compte d’utilisateur membre du groupe d’administrateurs
AAD DDC.
1. Dans l’écran d’accueil, sélectionnez Outils d’administration. Une liste des outils de
gestion disponibles s’affiche, dont la gestion des stratégie de groupe installée
dans la section précédente.
2. Cliquez sur Gestion des stratégies de groupe pour ouvrir la console de gestion
des stratégies de groupe (GPMC).
Il existe deux objets de stratégie de groupe (GPO) intégrés dans un domaine managé :
un pour le conteneur Ordinateurs AADDC et un autre pour le conteneur AADDC
utilisateurs. Vous pouvez personnaliser ces objets de stratégie de groupe pour
configurer la stratégie de groupe selon vos besoins dans votre domaine managé.
1. Dans la console Gestion des stratégies de groupe, développez le nœud

Forest: aaddscontoso.com. Ensuite, développez les nœuds Domaines.
Il existe deux conteneurs pour Ordinateurs AADDC et Utilisateurs AADDC. Un objet

de stratégie de groupe par défaut est appliqué à chacun de ces conteneurs.
2. Ces objets de stratégie de groupe intégrés peuvent être personnalisés pour

configurer des stratégies de groupe particulières sur votre domaine managé.
Cliquez avec le bouton droit sur l’un des objets de stratégie de groupe, tel que
Objets de stratégie de groupe ordinateurs AADDC, puis choisissez Modifier... .
3. L’outil Éditeur de gestion des stratégies de groupe s’ouvre pour vous permettre de
personnaliser l’objet de stratégie de groupe, comme les stratégies de compte :
Lorsque vous avez terminé, sélectionnez Fichier > Enregistrer pour enregistrer la
stratégie. Les ordinateurs actualisent la stratégie de groupe par défaut toutes les
90 minutes et appliquent les modifications que vous avez apportées.
Créez un objet de stratégie de groupe

personnalisé
Pour regrouper des paramètres de stratégie similaires, vous créez souvent des objets de
stratégie de groupe supplémentaires au lieu d’appliquer tous les paramètres requis dans
le l’objet de stratégie de groupe unique par défaut. Avec Azure AD DS, vous pouvez
créer ou importer vos propres objets de stratégie de groupe personnalisés et les
associer à une unité d’organisation personnalisée. Si vous devez d’abord créer une unité
d’organisation personnalisée, consultez la page Créer une unité d’organisation
personnalisée dans un domaine managé.
1. Dans la console gestion des stratégies de groupe, sélectionnez votre unité

d’organisation personnalisée (OU), telle que MyCustomOU. Cliquez avec le bouton
droit sur l’unité d’organisation puis sélectionnez Créer un objet de stratégie de
groupe et le lier ici… :
2. Indiquez le nom du nouvel objet de stratégie de groupe, tel que Mon objet de
stratégie de groupe personnalisé, puis sélectionnez OK. Vous pouvez
éventuellement baser cet objet de stratégie de groupe personnalisé sur un objet
de stratégie de groupe existant et un ensemble d’options de stratégie.
3. Un objet de stratégie de groupe est créé et associé à votre unité d’organisation
personnalisée. Pour configurer les paramètres de stratégie, cliquez avec le bouton
droit sur l’objet de stratégie de groupe personnalisé et sélectionnez Modifier… :
4. L’outil Éditeur de gestion des stratégies de groupe s’ouvre pour vous permettre
de personnaliser l’objet de stratégie de groupe :
Lorsque vous avez terminé, sélectionnez Fichier > Enregistrer pour enregistrer la
stratégie. Les ordinateurs actualisent la stratégie de groupe par défaut toutes les
90 minutes et appliquent les modifications que vous avez apportées.
Étapes suivantes
Pour plus d’informations sur les paramètres de stratégie de groupe disponibles et que
vous pouvez configurer à l’aide de la console de gestion des stratégies de groupe,
consultez la page Utiliser les éléments de préférence de stratégie de groupe.
Administrer DNS et créer des
redirecteurs conditionnels dans un
Domain Services
Article • 01/06/2023
Azure AD DS inclut un serveur DNS qui fournit la résolution de noms pour le domaine
managé. Ce serveur DNS comprend des enregistrements DNS intégrés et des mises à
jour pour les composants clés qui permettent l’exécution du service.
Lorsque vous exécutez vos propres applications et services, il se peut que vous deviez
créer des enregistrements DNS pour des machines qui ne sont pas jointes au domaine,
ou configurer des adresses IP virtuelles pour des équilibreurs de charge ou des
redirecteurs DNS externes. Les utilisateurs qui appartiennent au groupe Administrateurs
AAD DC bénéficient de privilèges d’administration DNS sur le domaine managé Azure
AD DS, et peuvent créer et modifier des enregistrements DNS personnalisés.
Dans un environnement hybride, les zones DNS et les enregistrements configurés dans
d'autres espaces de noms DNS, comme un environnement AD DS local, ne sont pas
synchronisés avec le domaine managé. Pour résoudre les ressources nommées dans
d’autres espaces de noms DNS, créez et utilisez des redirecteurs conditionnels pointant
vers des serveurs DNS existants dans votre environnement.
Cet article explique comment installer les Outils du serveur DNS, puis utiliser la console
DNS pour gérer les enregistrements et créer des redirecteurs conditionnels dans Azure
AD DS.
７ Notes
La création ou la modification de conseils racine ou de redirecteurs DNS au niveau

du serveur ne sont pas prises en charge et entraîneront des problèmes pour le
domaine managé Azure AD DS.
Avant de commencer
Connectivité à partir de votre réseau virtuel Azure AD DS vers l’emplacement où
vos autres espaces de noms DNS sont hébergés.
Cette connectivité peut être assurée moyennant une connexion Azure
ExpressRoute ou Passerelle VPN Azure.
Machine virtuelle de gestion Windows Server jointe au domaine managé.
Installer les Outils du serveur DNS

Pour créer et modifier des enregistrements DNS dans un domaine managé, vous devez
installer les outils du serveur DNS. Ces outils peuvent être installés en tant que
fonctionnalité de Windows Server. Pour plus d’informations sur l’installation des outils
d’administration sur un client Windows, consultez Installer les outils d’administration de
serveur distant.

de serveur.



8. Dans la page Fonctionnalités, développez le nœud Outils d’administration de

serveur distant, puis développez le nœud Outils d’administration de rôles.
Sélectionnez la fonctionnalité Outils du serveur DNS dans la liste Outils
d’administration de rôles.
9. Dans la page Confirmation, sélectionnez Installer. L’installation des outils du

serveur DNS peut prendre une ou deux minutes.

Ouvrir la console Gestion du service DNS pour

administrer le serveur DNS
Une fois les outils du serveur DNS installés, vous pouvez administrer les enregistrements
DNS sur le domaine managé.
７ Notes
Pour administrer DNS dans un domaine managé, vous devez être connecté à un
compte d’utilisateur membre du groupe d’administrateurs AAD DDC.
1. Dans l’écran d’accueil, sélectionnez Outils d’administration. Une liste des outils de
gestion disponibles s’affiche, dont le DNS installé dans la section précédente.
Sélectionnez DNS pour lancer la console Gestion du service DNS.
2. Dans la boîte de dialogue Connexion au serveur DNS, sélectionnez L’ordinateur

suivant, puis entrez le nom de domaine DNS du domaine managé, par exemple
aaddscontoso.com :
3. La console DNS se connecte au domaine managé spécifié. Développez Zones de

recherche directe ou Zones de recherche inversée pour créer vos entrées DNS
requises ou modifier des enregistrements existants en fonction des besoins.
２ Avertissement
Lorsque vous gérez des enregistrements à l’aide des Outils du serveur DNS, veillez
à ne pas supprimer ou modifier les enregistrements DNS intégrés qu’Azure AD DS
utilise. Les enregistrements DNS intégrés incluent les enregistrements DNS de
domaine, les enregistrements de serveur de noms et d’autres enregistrements
utilisés pour le lieu du contrôleur de domaine. Si vous modifiez ces
enregistrements, les services de domaine sont interrompus sur le réseau virtuel.
Créer des redirecteurs conditionnels

Une zone DNS Azure AD DS doit uniquement contenir la zone et les enregistrements du
domaine managé proprement dit. Ne créez pas de zones supplémentaires dans le
domaine managé pour résoudre les ressources nommées dans d’autres espaces de
noms DNS. Privilégiez les redirecteurs conditionnels dans le domaine managé pour
indiquer au serveur DNS à quel emplacement résoudre les adresses de ces ressources.
Dans un serveur DNS, un redirecteur conditionnel est une option de configuration qui
vous permet de définir un domaine DNS, par exemple contoso.com, vers lequel
transférer les requêtes. À la différence du serveur DNS local qui tente de résoudre les
requêtes pour les enregistrements de ce domaine, les requêtes DNS sont transférées au
DNS configuré pour ce domaine. Cette configuration garantit le renvoi des
enregistrements DNS qui conviennent, car vous ne créez pas de zone DNS locale avec
des enregistrements en double dans le domaine managé pour refléter ces ressources.
Pour créer un redirecteur conditionnel dans votre domaine managé, procédez comme
suit :
1. Sélectionnez votre zone DNS, par exemple aaddscontoso.com.
2. Sélectionnez Redirecteurs conditionnels, puis cliquez avec le bouton droit et

sélectionnez Nouveau redirecteur conditionnel...
3. Entrez votre autre Domaine DNS, par exemple contoso.com, puis entrez les
adresses IP des serveurs DNS pour cet espace de noms, comme illustré dans
4. Cochez la case pour Stocker ce redirecteur conditionnel dans Active Directory, et
le répliquer comme suit, puis sélectionnez l’option Tous les serveurs DNS de ce
domaine, comme illustré dans l’exemple suivant :
） Important
Si le redirecteur conditionnel est stocké dans la forêt et non dans le domaine,

il échoue.
5. Pour créer le redirecteur conditionnel, sélectionnez OK.
La résolution de noms des ressources dans d’autres espaces de noms à partir de

machines virtuelles connectées au domaine managé doit maintenant être correctement
résolue. Les requêtes correspondant au domaine DNS configuré dans le redirecteur
conditionnel sont transmises aux serveurs DNS qui conviennent.
Étapes suivantes
Pour plus d’informations sur la gestion DNS, consultez l’article Outils DNSsur Technet.
Vérifier l’intégrité d’un domaine géré
par les services de domaine Azure
Active Directory
Article • 01/06/2023
Azure Active Directory Domain Services (Azure AD DS) exécute des tâches en arrière-
plan pour assurer que le domaine géré est intègre et à jour. Ces tâches incluent la
réalisation de sauvegardes, l’application de mises à jour de sécurité et la synchronisation
des données à partir d’Azure AD. En cas de problème avec le domaine managé Azure
AD DS, ces tâches peuvent ne pas s’effectuer correctement. Pour examiner et résoudre
les problèmes éventuels, vous pouvez vérifier l’état d’intégrité d’un domaine managé à
l’aide du portail Azure.
Cet article vous montre comment consulter l’état d’intégrité d’Azure AD DS et

comprendre les informations ou les alertes montrées.
Afficher l’état d’intégrité

L’état d’intégrité d’un domaine managé peut être vérifié à l’aide du portail Azure. Vous
pouvez consulter les informations relatives à l’heure de la dernière sauvegarde et
synchronisation avec Azure AD, ainsi que toutes les alertes qui indiquent un problème
avec l’intégrité du domaine managé. Pour afficher l’état d’intégrité d’un domaine
2. Sélectionnez votre domaine managé, par exemple aaddscontoso.com.
3. Sur le côté gauche de la fenêtre de ressources Azure AD DS, sélectionnez Intégrité.

L’exemple de capture d’écran suivant montre un domaine managé intègre et l’état
de la dernière sauvegarde et synchronisation d’Azure AD :
Le timestamp Dernière évaluation de la page d’intégrité indique la date de la dernière
vérification du domaine managé. L’intégrité d’un domaine managé est évaluée toutes
les heures. Si vous apportez des modifications à un domaine managé, attendez le
prochain cycle d’évaluation pour voir l’état d’intégrité à jour.
L’état affiché dans le coin supérieur droit indique l’intégrité globale du domaine
managé. L’état prend en compte toutes les alertes existantes de votre domaine. Le
tableau suivant détaille les indicateurs d’état disponibles :
Statut Icône Explication
Exécution en Le domaine managé fonctionne normalement et n’a pas d’alertes

cours critiques ou d’avertissement. Le domaine peut avoir des alertes
d’information.
Doit être Il n’existe aucune alerte critique sur le domaine managé, mais il existe
surveillé une ou plusieurs alertes d’avertissement qui doivent être traitées.
(avertissement)
Doit être Il y a une ou plusieurs alertes critiques sur le domaine managé qui
surveillé doivent être traitées. Vous avez peut-être également des alertes
(critique) d’avertissement et/ou d’information.
Déploiement Le domaine managé est en cours de déploiement.

en cours
Comprendre les analyses et les alertes

L’état d’intégrité d’un domaine managé présente deux types d’informations : les
analyses et les alertes. Les analyses indiquent l’heure à laquelle les tâches principales en
arrière-plan se sont terminées. Les alertes fournissent des informations ou des
suggestions pour améliorer la stabilité du domaine géré.
Analyses
Les analyses sont des zones d’un domaine managé qui sont vérifiées régulièrement. S’il
existe des alertes actives pour le domaine managé, cela peut entraîner le signalement
d’un problème par une des analyses. Azure AD DS surveille actuellement les zones
suivantes :
Sauvegarde
Synchronisation avec Azure AD
Analyse de sauvegarde
L’analyse de sauvegarde vérifie que les sauvegardes régulières automatisées du
domaine managé s’exécutent correctement. Le tableau suivant détaille l’état de l’analyse
de sauvegarde disponible :
Valeur de Explication
détail
Jamais Cet état est normal pour les nouveaux domaines managés. La première
sauvegardé sauvegarde doit être créée 24 heures après le déploiement du domaine managé.
Si cet état persiste, ouvrez une demande de support Azure.
La dernière Cet intervalle de temps correspond à l’état attendu pour l’analyse de sauvegarde.
sauvegarde Les sauvegardes régulières automatisées doivent avoir lieu au cours de cette
a été période.
effectuée
entre 1 et 14
jours
auparavant.
La dernière Un intervalle de temps supérieur à deux semaines indique un problème avec les
sauvegarde sauvegardes régulières automatisées. Les alertes critiques actives peuvent
a été empêcher le domaine managé d’être sauvegardé. Résolvez les alertes actives pour
effectuée il y le domaine managé. Si l’analyse de sauvegarde ne met pas à jour l’état pour
a plus de 14 signaler une sauvegarde récente, ouvrez une demande de support Azure.
jours.
Synchronisation avec Azure AD Monitor

Un domaine managé se synchronise régulièrement avec Azure Active Directory. Le
nombre d’utilisateurs et d’objets de groupe et le nombre de modifications effectuées
dans l’annuaire Azure AD depuis la dernière synchronisation, affectent le temps
nécessaire à la synchronisation. Si le domaine managé a été synchronisé pour la
dernière fois il y a plus de trois jours, recherchez et résolvez les alertes actives. Si
l’analyse de synchronisation ne met pas à jour l’état pour afficher une synchronisation
récente après avoir répondu aux alertes actives, ouvrez une demande de support Azure.
Alertes
Des alertes sont générées pour les problèmes d’un domaine managé qui doivent être
adressés pour que le service s’exécute correctement. Chaque alerte explique le
problème et fournit une URL qui décrit les étapes spécifiques pour résoudre le
problème. Pour plus d’informations sur les alertes possibles et leurs solutions, consultez
Dépannage des alertes.
Les alertes d’état d’intégrité sont classées selon les niveaux de gravité suivants :
Les alertes critiques sont des problèmes ayant un impact sérieux sur le domaine
managé. Ces alertes doivent être traitées immédiatement. La plateforme Azure ne
peut pas surveiller, gérer, mettre à jour et synchroniser le domaine managé tant
que les problèmes ne sont pas résolus.
Les alertes d’avertissement vous informent des problèmes qui peuvent avoir un
impact sur les opérations du domaine managé si le problème persiste. Ces alertes
fournissent aussi des recommandations pour sécuriser le domaine managé.
Les alertes d’information sont des notifications qui n’ont pas d’impact négatif sur
le domaine managé. Les alertes d’information fournissent des informations sur ce
qui se passe dans le domaine managé.
Étapes suivantes
Pour plus d’informations sur les alertes affichées dans la page d’état d’intégrité,
consultez Résoudre les alertes sur votre domaine managé
Vérifier les métriques de flotte d’Azure
Article • 01/06/2023
Les administrateurs peuvent utiliser les métriques Azure Monitor pour configurer une
étendue pour Azure Active Directory Domain Services (Azure AD DS) et obtenir des
insights sur l’exécution du service.
Vous pouvez accéder aux métriques Azure AD DS à
partir de deux emplacements :
Dans les métriques Azure Monitor, cliquez sur Nouveau graphique>Sélectionner

une étendue et sélectionnez l’instance Azure AD DS :
Dans Azure AD DS, sous Supervision, cliquez sur Métriques :

La capture d’écran suivante montre comment sélectionner des métriques
combinées pour le temps processeur total et les recherches LDAP :
Vous pouvez également afficher les métriques pour une flotte d’instances Azure
AD DS :
La capture d’écran suivante montre les métriques combinées pour le temps
processeur total, les requêtes DNS et les recherches LDAP par instance de rôle :
Définitions et descriptions des métriques

Vous pouvez sélectionner une métrique pour plus d’informations sur la collecte de
données.
Le tableau suivant décrit les métriques qui sont disponibles pour Azure AD DS.
Métrique Description
DNS – Nombre Le nombre moyen de requêtes reçues par le serveur DNS chaque seconde. Elle
total de est soutenue par les données du compteur de performances du contrôleur de
requêtes domaine et peut être filtrée ou fractionnée par instance de rôle.
reçues/s
Nombre total de Le nombre moyen de réponses envoyées par le serveur DNS chaque seconde.
réponses Elle est soutenue par les données du compteur de performances du contrôleur
envoyées/s de domaine et peut être filtrée ou fractionnée par instance de rôle.
NTDS – Liaisons Le nombre de liaisons LDAP réussies par seconde pour l’objet NTDS. Elle est
LDAP réussies/s soutenue par les données du compteur de performances du contrôleur de
domaine et peut être filtrée ou fractionnée par instance de rôle.
% d’octets Le rapport du nombre d’octets dédiés sur la limite dédiée. La mémoire dédiée
validés utilisés est la mémoire physique utilisée pour laquelle de l’espace a été réservé dans
le fichier d’échange au cas où elle ait besoin d’être écrite sur disque. La limite
dédiée est déterminée par la taille du fichier d'échange. Si ce dernier est
agrandi, la limite de la mémoire dédiée augmente et le rapport diminue. Ce
compteur correspond à la valeur de pourcentage actuelle uniquement ; il ne
s’agit pas d’une moyenne. Elle est soutenue par les données du compteur de
performances du contrôleur de domaine et peut être filtrée ou fractionnée par
instance de rôle.
Temps Durée (en pourcentage) que le processeur met pour exécuter des threads
processeur total actifs. Elle est calculée en mesurant le pourcentage de temps passé par le
processeur à exécuter le thread inactif, puis en soustrayant cette valeur de
100 %. (Chaque processeur a un thread inactif qui consomme des cycles
quand aucun autre thread n'est prêt à s'exécuter.) Ce compteur est l'indicateur
principal de l'activité du processeur et affiche le pourcentage moyen de temps
d'occupation observé sur l'intervalle échantillon. Il convient de noter que le
calcul comptable permettant de déterminer si le processeur est inactif est
effectué à un intervalle d’échantillonnage interne de l’horloge système
(10 ms). Sur les processeurs rapides d’aujourd’hui, le % de temps processeur
peut donc sous-estimer l’utilisation du processeur, car le processeur peut
passer beaucoup de temps à la maintenance des threads entre les intervalles
d’échantillonnage de l’horloge système. Les applications de minutage basées
sur la charge de travail sont un exemple d’applications qui seront très
probablement mesurées de façon incorrecte, car les minuteurs sont signalés
juste après l’échantillon. Elle est soutenue par les données du compteur de
instance de rôle.
Authentifications Le nombre de fois où les clients utilisent un ticket pour s’authentifier auprès
Kerberos de cet ordinateur par seconde. Elle est soutenue par les données du compteur
de performances du contrôleur de domaine et peut être filtrée ou fractionnée
par instance de rôle.
Authentifications Le nombre d’authentifications NTLM traitées par seconde pour Active

NTLM Directory sur ce contrôleur de domaine ou pour les comptes locaux sur ce
serveur membre. Elle est soutenue par les données du compteur de
instance de rôle.
% de temps Temps écoulé en pourcentage que tous les threads de processus DNS ont
processeur (dns) passé à utiliser le processeur pour exécuter des instructions. Une instruction
est l’unité de base d’exécution dans un ordinateur, un thread est l’objet qui
exécute les instructions et un processus est l’objet créé lorsqu’un programme
est exécuté. Le code exécuté pour gérer des interruptions dues au matériel et
gérer des conditions d'interruption est inclus dans ce compte. Elle est
soutenue par les données du compteur de performances du contrôleur de
% de temps Temps écoulé en pourcentage que tous les threads de processus lsass ont
processeur passé à utiliser le processeur pour exécuter des instructions. Une instruction
(lsass) est l’unité de base d’exécution dans un ordinateur, un thread est l’objet qui
exécute les instructions et un processus est l’objet créé lorsqu’un programme
est exécuté. Le code exécuté pour gérer des interruptions dues au matériel et
gérer des conditions d'interruption est inclus dans ce compte. Elle est
soutenue par les données du compteur de performances du contrôleur de
NTDS – Le nombre moyen de recherches par seconde pour l’objet NTDS. Elle est
Recherches soutenue par les données du compteur de performances du contrôleur de
LDAP/s domaine et peut être filtrée ou fractionnée par instance de rôle.
Alerte Azure Monitor

Vous pouvez configurer des alertes de métrique pour qu’Azure AD DS soit averti des
problèmes possibles. Les alertes de métrique sont un type d’alerte pour Azure Monitor.
Pour plus d’informations sur les autres types alertes, consultez Présentation des alertes
Azure Monitor.
Pour afficher et gérer l’alerte Azure Monitor, un utilisateur doit avoir des rôles Azure
Monitor affectés.
Dans Azure Monitor ou les métriques Azure AD DS, cliquez sur Nouvelle alerte et
configurez une instance Azure AD DS comme étendue. Choisissez ensuite les métriques
que vous souhaitez mesurer dans la liste des signaux disponibles :
La capture d’écran suivante montre comment définir une alerte de métrique avec un
seuil pour Temps processeur total :
Vous pouvez également configurer une notification d’alerte, qui peut être un e-mail, un
SMS ou un appel vocal :
La capture d’écran suivante montre une alerte de métrique déclenchée pour le Temps
processeur total :
Dans ce cas, une notification par e-mail est envoyée après une activation d’alerte :
Une autre notification par e-mail est envoyée après la désactivation de l’alerte :
Sélectionner plusieurs ressources
Vous pouvez activer la sélection de plusieurs ressources pour mettre en corrélation les
données entre les types de ressources.
Étapes suivantes
Vérifier l’intégrité d’un domaine géré par les services de domaine Azure Active
Directory
Configurer des notifications par e-mail
pour les problèmes rencontrés dans
Article • 01/06/2023
L’intégrité d’un domaine managé Azure Active Directory Domain Services (Azure AD DS)
est supervisée par la plateforme Azure. Les alertes relatives au domaine managé
s’affichent dans la page État d’intégrité du portail Azure. Pour assurer des interventions
en temps voulu quand des problèmes surviennent, il est possible de configurer des
notifications par e-mail pour signaler les alertes d’intégrité dès qu’elles sont détectées
dans le domaine managé Azure AD DS.
Cet article vous montre comment configurer les destinataires des notifications par e-
mail pour un domaine managé.
Vue d’ensemble des notifications par e-mail

Pour être alerté des problèmes qui touchent un domaine managé, vous pouvez
configurer des notifications par e-mail. Celles-ci indiquent le domaine managé dans
lequel l’alerte est présente, l’heure de détection et fournit un lien vers la page d’état
d’intégrité du portail Azure. Vous pouvez ensuite suivre les conseils de dépannage
fournis pour résoudre les problèmes.
L’exemple de notification par e-mail présenté ci-dessous indique qu’un avertissement

ou une alerte critique a été généré dans le domaine managé :
２ Avertissement
Assurez-vous toujours que l’e-mail provient d’un expéditeur Microsoft vérifié avant
de cliquer sur les liens contenus dans le message. Les notifications par e-mail
proviennent toujours de l’adresse azure-noreply@microsoft.com .
Pourquoi est-ce que je recevrais des notifications par e-

mail ?
Azure AD DS envoie des notifications par e-mail pour les faits nouveaux importants qui
touchent le domaine managé. Ces notifications concernent uniquement les problèmes
urgents qui ont un impact sur le service et qui doivent être traités immédiatement.
Chaque notification par e-mail est déclenchée par une alerte sur le domaine managé.
Les alertes s’affichent aussi sur le portail Azure et sont visibles dans la page d’état
d’intégrité d’Azure AD DS.
Azure AD DS n’envoie pas d’e-mails à des fins publicitaires, commerciales ou de mise à

jour.
Quand est-ce que je recevrai des notifications par e-mail ?

Les notifications sont envoyées aussitôt qu’une nouvelle alerte est détectée dans un
domaine managé. Si l’alerte n’est pas résolue, d’autres notifications de rappel sont
envoyées par e-mail tous les quatre jours.
Qui doit recevoir les notifications par e-mail ?

La liste des destinataires pour Azure AD DS doit être composée de personnes capables
d’administrer le domaine managé et d’y apporter des modifications. Cette liste doit être
considérée comme celle des « premiers intervenants » pour tout type d’alerte et de
problème.
Vous pouvez ajouter jusqu’à cinq destinataires supplémentaires pour les notifications
par e-mail. Si vous voulez que les notifications par e-mail soient envoyées à plus de cinq
destinataires, créez une liste de distribution et ajoutez-la à la liste de notification.
Vous pouvez aussi décider que tous les administrateurs généraux de l’annuaire Azure AD
et tous les membres du groupe Administrateurs AAD DC recevront les notifications par
e-mail. Azure AD DS peut envoyer les notifications à 100 adresses e-mail au maximum,
en incluant la liste des administrateurs généraux et des administrateurs AAD DC.
Configurer les notifications par e-mail

Pour examiner les destinataires existants des notifications par e-mail ou pour ajouter des
destinataires supplémentaires, effectuez les étapes suivantes :

3. Dans la partie gauche de la fenêtre de ressources Azure AD DS, sélectionnez
Paramètres de notification. Les destinataires existants des notifications par e-mail
s’affichent.
4. Pour ajouter un destinataire, entrez son adresse e-mail dans le tableau des
destinataires supplémentaires.
5. Quand vous avez terminé, sélectionnez Enregistrer dans le volet de navigation du
haut.
２ Avertissement
Quand vous modifiez les paramètres de notification, vous mettez à jour les
paramètres de notification du domaine managé tout entier, pas seulement les
vôtres.
Forum aux questions
J’ai reçu une notification par e-mail pour une alerte, mais
lorsque j’ai ouvert une session, le portail Azure ne
contenait pas d’alerte. Que s’est-il passé ?
Une alerte qui été résolue ne figure plus sur le portail Azure. La raison la plus probable
est qu’un autre destinataire des notifications par e-mail a résolu l’alerte dans votre
domaine managé ou elle a été résolue automatiquement par la plateforme Azure.
Pourquoi ne puis-je pas modifier les paramètres de

notification ?
Si vous ne parvenez pas à accéder à la page des paramètres de notification sur le portail
Azure, c’est que vous n’avez pas les autorisations permettant de modifier le domaine
managé. Contactez un administrateur général pour obtenir les autorisations permettant
de modifier les ressources Azure AD DS ou pour être retiré de la liste des destinataires.
Je ne reçois pas de notifications par e-mail, même si j’ai

fourni mon adresse e-mail. Pourquoi ?
Recherchez des notifications dans le dossier de courrier indésirable de votre boîte de
réception et veillez à autoriser l’expéditeur de azure-noreply@microsoft.com .
Étapes suivantes
Pour plus d’informations sur la résolution de certains problèmes susceptibles d’être
signalés, consultez Résoudre les alertes dans un domaine managé.
Désactiver ou supprimer un domaine
managé Azure Active Directory Domain
Services à partir du portail Azure
Article • 01/06/2023
Si vous n’avez plus besoin d’un domaine managé Azure Active Directory Domain
Services (Azure AD DS), vous pouvez le supprimer. Il n’existe aucune option permettant
de désactiver de façon provisoire ou définitive un domaine managé Azure AD DS. La
suppression du domaine managé ne supprime pas et n’impacte pas défavorablement le
locataire Azure AD.
Cet article explique comment utiliser le portail Azure domaine pour supprimer un
domaine managé.
２ Avertissement
La suppression est définitive et ne peut pas être annulée.
Quand vous supprimez un domaine managé, voici ce qu’il se passe :
Les contrôleurs de domaine pour le domaine managé sont déprovisionnés et

supprimés du réseau virtuel.
Les données sur le domaine managé sont supprimées définitivement. Ces
données incluent les unités d’organisation personnalisées, les stratégies de
groupe, les enregistrements DNS personnalisés, les principaux de service, les
GMSA, etc. que vous avez créés.
Les machines jointes au domaine managé perdent leur relation d’approbation
avec ce domaine et doivent être disjointes de celui-ci.
Vous ne pouvez pas vous connecter à ces machines en utilisant des
informations d’identification AD. Pour cela, vous devez utiliser les
informations d’identification de l’administrateur local de la machine.
Supprimer le domaine managé

Pour supprimer un domaine managé, procédez comme suit :

2. Sélectionnez le nom de votre domaine managé, par exemple aaddscontoso.com.
3. Dans la page Vue d’ensemble, sélectionnez Supprimer. Pour confirmer la
suppression, tapez à nouveau le nom du domaine managé, puis sélectionnez
Supprimer.
La suppression du domaine managé peut prendre entre 15 et 20 minutes, ou plus.
Étapes suivantes
N’hésitez pas à faire part de vos commentaires concernant les fonctionnalités que
vous aimeriez voir dans Azure AD DS.
Si vous voulez redémarrer avec Azure AD DS, consultez Créer et configurer un domaine
managé Azure Active Directory Domain Services.
Modifier la référence SKU d'un domaine
Servicess existant
Article • 12/04/2023
Dans Azure Active Directory Domain Services (Azure AD DS), les performances et
fonctionnalités disponibles sont basées sur le type de référence SKU. Ces différences de
fonctionnalités incluent la fréquence de sauvegarde ou le nombre maximal
d’approbations de forêts sortantes unidirectionnelles.
Vous sélectionnez une référence SKU lorsque vous créez le domaine managé, et vous
pouvez augmenter ou diminuer la référence SKU lorsque les besoins de votre entreprise
évoluent, après le déploiement du domaine managé. Les besoins de l'entreprise
évoluent notamment lorsqu'il lui faut effectuer des sauvegardes plus fréquentes ou
créer des approbations de forêts supplémentaires. Pour plus d’informations sur les
limites et la tarification des différentes références SKU, consultez les pages Concepts
relatifs aux références SKU Azure AD et Tarification Azure AD DS .
Cet article vous explique comment modifier la référence SKU d'un domaine managé
Azure AD DS à l’aide du portail Azure.
Avant de commencer
Si nécessaire, suivez le didacticiel pour créer et configurer un domaine managé.
Limitations relatives aux changements de

références SKU
Vous pouvez augmenter ou diminuer les références SKU une fois le domaine managé
déployé. Toutefois, les références SKU Premium et Entreprise définissent une limite
quant au nombre d’approbations que vous pouvez créer. Vous ne pouvez pas opter
pour une référence SKU dont la limite maximale est inférieure à celle que vous avez
configurée.
Par exemple, si vous avez créé sept approbations sur la référence SKU Premium, vous ne
pouvez pas opter pour la référence SKU Entreprise. La référence SKU Entreprise prend en
charge un maximum de cinq approbations.
Pour plus d’informations sur ces limites, consultez Fonctionnalités et limites des
références SKU Azure AD DS.
Sélectionner une nouvelle référence SKU

Pour modifier la référence SKU d'un domaine managé à l'aide du portail Azure,
1. Sur le Portail Microsoft Azure, recherchez et sélectionnez Azure AD Domain

Services. Choisissez votre domaine managé dans la liste, par exemple
aaddscontoso.com.
2. Dans le menu gauche de la page Azure AD DS, sélectionnez Paramètres >

Référence SKU.
3. Dans le menu déroulant, sélectionnez la référence SKU souhaitée pour votre
domaine managé. Si vous disposez d’une forêt de ressources, vous ne pouvez pas
sélectionner la référence SKU Standard car les approbations de forêts sont
uniquement disponibles sur la référence SKU Entreprise ou supérieure.
Sélectionnez la référence SKU de votre choix dans le menu déroulant, puis

Enregistrer.
Le changement de type de référence SKU peut prendre une ou deux minutes.
Étapes suivantes
Si vous disposez d’une forêt de ressources et souhaitez créer des approbations
supplémentaires une fois la référence SKU modifiée, consultez Créer une approbation
de forêt sortante vers un domaine local dans Azure AD DS.
Instructions d’Azure AD pour l’extraction
de données
Article • 01/06/2023
Ce document décrit comment récupérer des données à partir de Azure Active Directory
Domain Services (Azure AD DS).
７ Notes
Cet article explique comment supprimer les données personnelles de l’appareil ou

du service et il peut être utilisé dans le cadre de vos obligations en vertu du
Règlement général sur la protection des données. Pour obtenir des informations
générales concernant le Règlement général sur la protection des données (RGPD),
consultez la section relative au RGPD du Centre de gestion de la confidentialité
de Microsoft et la section relative au RGPD du Portail d’approbation de
services .
Utilisez Azure Active Directory pour créer, lire,

mettre à jour et supprimer des objets
utilisateur
Vous pouvez créer un utilisateur dans le portail Azure AD ou avec Graph PowerShell ou
API Graph. Vous pouvez aussi lire, mettre à jour et supprimer des utilisateurs. Les
sections suivantes montrent comment effectuer ces opérations dans le portail Azure AD.
Créer, lire ou mettre à jour un utilisateur

Vous pouvez créer un utilisateur à l’aide du portail Azure Active Directory.
Pour ajouter
un nouvel utilisateur, procédez comme suit :
1. Connectez-vous au portail Azure avec le rôle Administrateur d’utilisateurs de

l’organisation.
2. Recherchez et sélectionnez Azure Active Directory à partir de n’importe quelle

page.
3. Sélectionnez Utilisateurs, puis Nouvel utilisateur.

4. Sur la page Utilisateur, entrez les informations pour cet utilisateur :
Nom. Obligatoire. Prénom et nom du nouvel utilisateur. Par exemple, Mary

Parker.
Nom d’utilisateur. Obligatoire. Nom d’utilisateur du nouvel utilisateur. Par

exemple : mary@contoso.com .
Groupes. Si vous le souhaitez, vous pouvez ajouter l’utilisateur à un ou

plusieurs groupes existants.
Rôle d’annuaire : si vous devez attribuer des autorisations d’administration

Azure AD à l’utilisateur, vous pouvez les ajouter à un rôle Azure AD.
Informations sur l’emploi : Vous pouvez ajouter ici des informations

supplémentaires sur l’utilisateur.
5. Copiez le mot de passe généré automatiquement fourni dans le champ Mot de

passe. Vous devrez fournir ce mot de passe à l’utilisateur pour qu’il se connecte la
première fois.
6. Sélectionnez Create (Créer).
L’utilisateur est créé et ajouté à votre organisation Azure AD.
Pour lire ou mettre à jour un utilisateur, recherchez et sélectionnez un l’utilisateur, par

exemple Mary Parker. Modifiez n’importe quelle propriété, puis cliquez sur Enregistrer.
Supprimer un utilisateur
Pour supprimer un utilisateur, effectuez les étapes suivantes :
1. Recherchez et sélectionnez l'utilisateur que vous souhaitez supprimer de votre

locataire Azure AD. Par exemple, Mary Parker.
2. Sélectionnez Supprimer l’utilisateur.
L’utilisateur est supprimé et n’apparaît plus sur la page Utilisateurs : Tous les
utilisateurs. L’utilisateur est affiché sur la page Utilisateurs supprimés pendant 30 jours
et peut être restauré durant cette période.
Lorsqu'un utilisateur est supprimé, toutes les licences utilisées par celui-ci sont mises à
la disposition d'autres utilisateurs.
Utiliser les outils RSAT pour se connecter à un

domaine managé Azure AD DS et voir les
utilisateurs
Connectez-vous à une station de travail administrative avec un compte utilisateur
membre du groupe Administrateurs AAD DC. Les étapes suivantes nécessitent
l’installation des outils d’administration de serveur distant (RSAT).
1. Dans le menu Démarrer, sélectionnez Outils d’administration Windows. Les outils

d’administration Active Directory sont répertoriés.
2. Sélectionnez Centre d’administration Active Directory.

3. Pour explorer le domaine managé, choisissez le nom de domaine dans le volet
gauche, par exemple aaddscontoso. Deux conteneurs nommés Ordinateurs AADDC
et Utilisateurs AADDC se trouvent en haut de la liste.
4. Pour voir les utilisateurs et les groupes appartenant au domaine managé,

sélectionnez le conteneur Utilisateurs AADDC. Les comptes d’utilisateur et les
groupes de votre locataire Azure AD sont listés dans ce conteneur.
Dans l’exemple de sortie suivant, un compte d’utilisateur nommé Contoso Admin et

un groupe pour Administrateurs AAD DC figurent dans ce conteneur.
5. Pour voir les ordinateurs qui sont joints au domaine managé, sélectionnez le
conteneur Ordinateurs AADDC. Une entrée pour la machine virtuelle actuelle, par
exemple myVM figure dans la liste. Les comptes d’ordinateurs de tous les appareils
joints au domaine managé sont stockés dans le conteneur Ordinateurs AADDC.
Vous pouvez également utiliser le Module Active Directory pour Windows PowerShell, qui
est installé dans le cadre des outils d’administration, pour gérer les actions courantes
dans votre domaine managé.
Étapes suivantes
Vue d’ensemble d’Azure AD DS
Renforcer un domaine géré des services
de domaine Azure Active Directory
Article • 11/05/2023
Par défaut, Azure Active Directory Domain Services (Azure AD DS) permet l’utilisation de
chiffrements comme NTLM v1 et TLS v1. Certaines applications héritées peuvent avoir
besoin de ces chiffrements, mais étant considérés comme faibles, vous pouvez les
désactiver si vous n’en avez pas l’utilité. Si vous disposez d’une connectivité hybride
locale reposant sur Azure AD Connect, vous pouvez aussi désactiver la synchronisation
des hachages de mot de passe NTLM.
Cet article explique comment renforcer un domaine managé à l’aide d’un paramètre tel
que :
Désactiver les chiffrements NTLM v1 et TLS v1

Désactiver la synchronisation de hachage de mot de passe NTLM
Désactiver la possibilité de modifier les mots de passe avec le chiffrement RC4
Activer le blindage Kerberos
Signature LDAP
Liaison du canal LDAP
Prérequis
suivantes :
Domain Services.
Utiliser les paramètres de sécurité pour
renforcer votre domaine
1. Connectez-vous au portail Azure .
4. Sur le côté gauche, sélectionnez Paramètres de sécurité.
5. Cliquez sur Activer ou Désactiver pour les paramètres suivants :
Mode TLS 1.2 uniquement

Authentification NTLM v1
Synchronisation de mot de passe NTLM
Chiffrement Kerberos RC4
Blindage Kerberos
Signature LDAP
Liaison du canal LDAP
Affecter la conformité Azure Policy pour

l’utilisation de TLS 1.2
En plus des paramètres de sécurité, Microsoft Azure stratégie a un paramètre de
conformité pour appliquer l’utilisation du protocole TLS 1.2. La stratégie n’a aucun
impact tant qu’elle n’est pas affectée. Quand la stratégie est affectée, elle apparaît en
Conformité :
Si l’affectation est Audit, la conformité indique si l’instance de Azure AD DS est

conforme.
Si l’attribution est Refusée, la conformité empêche la création d’une instance
d’Azure AD DS si TLS 1.2 n’est pas requis et empêche toute mise à jour d’une
instance Azure AD DS jusqu’à ce que TLS 1.2 soit requis.
Auditer les échecs NTLM

Bien que la désactivation de la synchronisation de mot de passe NTLM améliore la
sécurité, de nombreuses applications et de nombreux services ne sont pas conçus pour
fonctionner sans elle. Par exemple, la connexion à une ressource par son adresse IP, telle
que la gestion de serveur DNS ou le protocole RDP, échoue avec l’erreur Accès refusé. Si
vous désactivez la synchronisation de mot de passe NTLM et que votre application ou
service ne fonctionne pas comme prévu, vous pouvez vérifier les échecs
d’authentification NTLM en activant l’audit de sécurité pour la catégorie d’événements
Ouverture/fermeture de session>Auditer l’ouverture de session, où NTLM est spécifié
en tant que package d’authentification dans les détails de l’événement. Pour plus
d’informations, consultez Activer les audits de sécurité pour Azure Active Directory
Domain Services.
Utiliser PowerShell pour renforcer votre
domaine
Si nécessaire, installez et configurez Azure PowerShell. Veillez à vous connecter à votre
abonnement Azure à l’aide de l’applet de commande Connect-AzAccount.
Toujours si nécessaire, installez et configurez Azure AD PowerShell. Veillez à vous

connecter à votre locataire Azure AD à l’aide de l’applet de commande Connect-
AzureAD.
Pour désactiver les suites de chiffrement faible et la synchronisation de hachage

d’informations d’identification NTLM, connectez-vous à votre compte Azure, puis
obtenez la ressource Azure AD DS à l’aide de l’applet de commande Get-AzResource :
 Conseil
Si vous obtenez une erreur avec la commande Get-AzResource indiquant que la

ressource Microsoft.AAD/DomainServices n’existe pas, élevez votre accès pour
gérer tous les abonnements et groupes d’administration Azure.
PowerShell
Login-AzAccount

Ensuite, définissez DomainSecuritySettings pour configurer les options de sécurité

suivantes :
1. Désactivez la prise en charge de NTLM v1.

2. Désactiver la synchronisation des hachages de mots de passe NTLM à partir de
votre instance Active Directory locale.
3. Désactivez TLS v1.
） Important
Les utilisateurs et les comptes de service ne peuvent pas établir de liaisons simples
LDAP si vous désactivez la synchronisation de hachage de mot de passe NTLM
dans votre domaine managé Azure AD DS. Si vous devez établir des liaisons
simples LDAP, ne définissez pas l’option de configuration de sécurité
"SyncNtlmPasswords"="Disabled"; dans la commande suivante.
PowerShell
$securitySettings =
@{"DomainSecuritySettings"=@{"NtlmV1"="Disabled";"SyncNtlmPasswords"="Disabl
ed";"TlsV1"="Disabled";"KerberosRc4Encryption"="Disabled";"KerberosArmoring"
="Disabled"}}
Enfin, appliquez les paramètres de sécurité définis au domaine managé à l’aide de

l’applet de commande Set-AzResource. Spécifiez la ressource Azure AD DS de la
première étape ainsi que les paramètres de sécurité de l’étape précédente.
PowerShell

$securitySettings -ApiVersion “2021-03-01” -Verbose -Force
L’application des paramètres de sécurité au domaine managé prend quelques instants.
） Important
Après avoir désactivé NTLM, effectuez une synchronisation de hachage de mot de

passe complète dans Azure AD Connect pour supprimer tous les hachages de mot
de passe du domaine géré. Si vous désactivez NTLM mais ne forcez pas la
synchronisation du hachage de mot de passe, les hachages de mot de passe NTLM
d’un compte d’utilisateur ne sont supprimés que lors de la prochaine modification
de mot de passe. Ce comportement peut permettre à un utilisateur de continuer à
se connecter s’il a des informations d’identification mises en cache sur un système
où NTLM est utilisé comme méthode d’authentification.
Une fois que le hachage de mot de passe NTLM est différent du hachage de mot
de passe Kerberos, le recours à NTLM ne fonctionnera pas. Les informations
d’identification mises en cache ne fonctionnent pas non plus si la machine virtuelle
dispose d’une connectivité au contrôleur de domaine géré.
Étapes suivantes
Pour en savoir plus sur le processus de synchronisation, consultez Synchronisation des
objets et des informations d’identification dans un domaine managé.
Configurer la délégation Kerberos
contrainte (KCD) dans Azure Active
Article • 01/06/2023
Pendant leur exécution, les applications peuvent avoir besoin d’accéder à des ressources
dans le contexte d’un autre utilisateur. Active Directory Domain Services (AD DS) prend
en charge un mécanisme, appelé délégation Kerberos, qui autorise ce cas d’usage. La
délégation Kerberos contrainte (KCD) s’appuie alors sur ce mécanisme pour définir les
ressources accessibles dans le contexte de l’utilisateur.
Les domaines managés Azure Active Directory Domain Services (Azure AD DS) étant
plus sécurisés que les environnements AD DS locaux classiques, utilisez un mécanisme
KCD plus sécurisé basé sur les ressources.
Cet article vous montre comment configurer la délégation Kerberos contrainte basée sur
les ressources dans un domaine managé Azure AD DS.
Prérequis
suivantes :
Domain Services.
Azure AD DS.
virtuelle Windows Server à un domaine managé, puis installez les outils de
gestion AD DS.
Vue d’ensemble de la délégation Kerberos

contrainte
La délégation Kerberos permet à un compte d’emprunter l’identité d’un autre compte
pour accéder à des ressources. Par exemple, une application web qui accède à un
composant web back-end peut emprunter sa propre identité comme s’il s’agissait d’un
autre compte d’utilisateur au moment d’établir la connexion back-end. La délégation
Kerberos n’est pas sécurisée dans le sens où le compte qui emprunte l’identité peut
accéder à n’importe quelles ressources sans aucune limitation.
En revanche, la délégation Kerberos contrainte (KCD) restreint les services ou les

ressources auxquels une application ou un serveur déterminé peut se connecter en
empruntant une autre identité. Le mécanisme KCD classique exige des privilèges
d’administrateur de domaine pour configurer le compte de domaine d’un service, et il
contraint le compte à s’exécuter sur un seul domaine.
Le mécanisme KCD classique présente aussi quelques inconvénients. Par exemple, dans
les anciens systèmes d’exploitation, les administrateurs de service n’avaient aucun
moyen utile de savoir quels services front-end déléguaient vers les services de
ressources qu’ils possédaient. Tout service front-end qui pouvait déléguer vers un
service de ressources constituait un point d’attaque potentiel. Si un serveur qui
hébergeait un service front-end configuré pour déléguer vers des services de ressources
était compromis, les services de ressources pouvaient l’être tout autant.
Dans un domaine managé, il n’existe pas de privilèges d’administrateur de domaine. De

ce fait, le mécanisme classique de délégation Kerberos contrainte basé sur les comptes
ne peut pas être configuré dans un domaine managé. À la place, il est possible d’utiliser
le mécanisme KCD basé les ressources, qui est aussi plus sécurisé.
KCD basée sur la ressource

Windows Server 2012 et les versions ultérieures offrent la possibilité aux administrateurs
de service de configurer la délégation contrainte pour leur service. Ce modèle est appelé
KCD basé sur les ressources. Avec cette approche, l’administrateur de service back-end
peut octroyer ou refuser à des services front-end spécifiques le droit d’utiliser KCD.
La KCD basée sur la ressource est configurée à l’aide de PowerShell. Vous devez utiliser
les applets de commande Set-ADComputer ou Set-ADUser, selon que le compte
d’emprunt est un compte d’ordinateur ou un compte de service/compte d’utilisateur.
Configurer le mécanisme KCD basé sur les

ressources pour un compte d’ordinateur
Dans ce scénario, supposons que vous avez une application web qui s’exécute sur
l’ordinateur nommé contoso-webapp.aaddscontoso.com.
L’application web doit accéder à une API web qui s’exécute sur l’ordinateur nommé
contoso-api.aaddscontoso.com dans le contexte des utilisateurs du domaine.
Pour configurer ce scénario, effectuez les étapes suivantes :
1. Créer une unité d’organisation personnalisée Vous pouvez déléguer des

autorisations pour gérer cette unité d’organisation personnalisée aux utilisateurs
du domaine managé.
2. Joignez les machines virtuelles (à la fois celles qui exécutent l’application web et
celles qui exécutent l’API web) au domaine managé. Créez ces comptes
d’ordinateur dans l’unité d’organisation personnalisée de l’étape précédente.
７ Notes
Les comptes d’ordinateur de l’application web et de l’API web doivent se

trouver dans une unité d’organisation personnalisée dans laquelle vous êtes
autorisé à configurer le mécanisme KCD basé sur les ressources. Vous ne
pouvez pas configurer le mécanisme KCD basé sur les ressources pour un
compte d’ordinateur situé dans le conteneur intégré Ordinateurs du contrôleur
de domaine AAD.
3. Enfin, configurez le mécanisme KCD basé sur les ressources à l’aide de l’applet de
commande PowerShell Set-ADComputer.
Sur votre machine virtuelle de gestion jointe au domaine, connectez-vous avec un

compte d’utilisateur membre du groupe Azure AD DC Administrators, puis
exécutez les applets de commande suivantes. Indiquez vos propres noms
d’ordinateur, si nécessaire :
PowerShell
$ImpersonatingAccount = Get-ADComputer -Identity contoso-

webapp.aaddscontoso.com
Set-ADComputer contoso-api.aaddscontoso.com -
PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
Configurer le mécanisme KCD basé sur les

ressources pour un compte d’utilisateur
Dans ce scénario, supposons que vous disposez d’une application web qui s’exécute en
tant que compte de service nommé appsvc. L’application web doit accéder à une API
web qui s’exécute en tant que compte de service nommé backendsvc dans le contexte
des utilisateurs du domaine. Pour configurer ce scénario, effectuez les étapes suivantes :

du domaine managé.
2. Joignez les machines virtuelles qui exécutent la ressource/API web back-end au

domaine managé. Créez son compte d’ordinateur dans l’unité d’organisation
personnalisée.
3. Créez le compte de service (par exemple, appsvc) utilisé pour exécuter l’application
web dans l’unité d’organisation personnalisée.
７ Notes
Là encore, le compte d’ordinateur de la machine virtuelle de l’API web et le

compte de service de l’application web doivent se trouver dans une unité
d’organisation personnalisée dans laquelle vous êtes autorisé à configurer le
mécanisme KCD basé sur les ressources. Vous ne pouvez pas configurer le
mécanisme KCD basé sur les ressources pour les comptes situés dans les
conteneurs intégrés AAD DC Computers ou AAD DC Users. Cela signifie aussi
que vous ne pouvez pas utiliser de comptes d’utilisateurs synchronisés à partir
d’Azure AD pour configurer le mécanisme KCD basé sur les ressources. Vous
devez créer et utiliser des comptes de service spécifiquement créés dans
Azure AD DS.
4. Enfin, configurez le mécanisme KCD basé sur les ressources à l’aide de l’applet de
commande PowerShell Set-ADUser.
Sur votre machine virtuelle de gestion jointe au domaine, connectez-vous avec un

compte d’utilisateur membre du groupe Azure AD DC Administrators, puis
exécutez les applets de commande suivantes. Indiquez vos propres noms de
service en fonction des besoins :
PowerShell
$ImpersonatingAccount = Get-ADUser -Identity appsvc
Set-ADUser backendsvc -PrincipalsAllowedToDelegateToAccount

$ImpersonatingAccount
Étapes suivantes
Pour en savoir plus sur le fonctionnement de la délégation dans Active Directory
Domain Services, consultez Vue d’ensemble de la délégation Kerberos contrainte.
Stratégies de mot de passe et de
verrouillage de compte sur des
domaines managés Azure Active
Article • 09/05/2023
Pour gérer la sécurité des utilisateurs dans Azure AD DS (Azure Active Directory Domain
Services), vous pouvez définir des stratégies de mot de passe affinées qui contrôlent les
paramètres de verrouillage des comptes ou la longueur minimale et la complexité des
mots de passe. Une stratégie de mot de passe affinée par défaut est créée et appliquée
à tous les utilisateurs membres d’un domaine managé Azure AD DS. Pour fournir un
contrôle précis et répondre à des besoins d’entreprise ou de conformité spécifiques, il
est possible de créer et d’appliquer des stratégies supplémentaires à des utilisateurs ou
groupes spécifiques.
Cet article montre comment créer et configurer une stratégie de mot de passe affinée
dans Azure AD DS à partir du Centre d’administration Active Directory.
７ Notes
Les stratégies de mot de passe ne sont disponibles que pour les domaines
managés créés à l’aide du modèle de déploiement Resource Manager.
Avant de commencer
Le domaine managé doit avoir été créé à l’aide d’un modèle de déploiement
Resource Manager.
Machine virtuelle de gestion Windows Server jointe au domaine managé.
Paramètres de la stratégie de mot de passe par

défaut
Les stratégies de mot de passe affinées (SMPA) vous permettent d’appliquer des
restrictions spécifiques pour les stratégies de verrouillage de compte et de mot de passe
à différents utilisateurs d’un domaine. Par exemple, vous pouvez sécuriser les comptes
privilégiés en leur appliquant des paramètres de verrouillage de compte plus stricts que
pour les comptes non privilégiés standard. Vous pouvez créer plusieurs stratégies de
mot de passe affinées dans un domaine managé et spécifier l’ordre de priorité selon
lequel elles doivent être appliquées aux utilisateurs.
Pour plus d’informations sur les stratégies de mot de passe et l’utilisation du Centre
d’administration Active Directory, consultez les articles suivants :
En savoir plus sur les stratégies de mot de passe affinées

Configurer des stratégies de mot de passe affinées à partir du Centre
d’administration Active Directory
Les stratégies sont distribuées par le biais de l’association de groupes dans un domaine
managé et les modifications que vous apportez sont appliquées à la connexion
utilisateur suivante. La modification de la stratégie ne déverrouille pas un compte
d’utilisateur qui est déjà verrouillé.
Les stratégies de mot de passe se comportent un peu différemment en fonction de la

manière dont le compte d’utilisateur auquel elles sont appliquées a été créé. Deux
méthodes sont possibles pour créer un compte d’utilisateur dans Azure AD DS :
Le compte d’utilisateur peut être synchronisé à partir d’Azure AD. Cette méthode
concerne les comptes d’utilisateur cloud uniquement qui sont créés directement
dans Azure, et les comptes d’utilisateur hybrides qui sont synchronisés à partir
d’un environnement AD DS local à l’aide d’Azure AD Connect.
La majorité des comptes d’utilisateur dans Azure AD DS sont créés par le biais
du processus de synchronisation à partir d’Azure AD.
Le compte d’utilisateur peut être créé manuellement dans un domaine managé et
n’existe pas dans Azure AD.
Quelle que soit la méthode de création de compte d’utilisateur choisie, les stratégies de
verrouillage de compte suivantes sont appliquées à tous les utilisateurs par la stratégie
de mot de passe par défaut dans Azure AD DS :
Durée de verrouillage de compte : 30

Nombre d’échecs d’ouverture de session autorisés : 5
Réinitialisation du nombre d’échecs d’ouverture de session après : 2 minutes
Âge maximal du mot de passe (durée de vie) : 90 jours
Avec ces paramètres par défaut, les comptes d’utilisateurs sont verrouillés pendant 30
minutes si cinq mots de passe non valides sont utilisés en l’espace de 2 minutes. Les
comptes sont déverrouillés automatiquement après 30 minutes.
Les verrouillages de comptes se produisent uniquement dans le domaine managé. Les

comptes d’utilisateur sont verrouillés uniquement dans Azure AD DS et seulement en
cas d’échec des tentatives de connexion au domaine managé. Les comptes d’utilisateur
qui ont été synchronisés à partir d’Azure AD ou localement ne sont pas verrouillés dans
leurs répertoires sources, mais uniquement dans Azure AD DS.
Si vous utilisez une stratégie de mot de passe Azure AD qui spécifie un âge maximal du
mot de passe supérieur à 90 jours, ce paramètre d’âge est appliqué à la stratégie par
défaut dans Azure AD DS. Vous pouvez configurer une stratégie de mot de passe
personnalisée pour définir un âge maximal du mot de passe différent dans Azure AD DS.
Soyez vigilant si l’âge maximal du mot de passe configuré dans une stratégie de mot de
passe Azure AD DS est inférieur à celui défini dans Azure AD ou dans un environnement
AD DS local. Dans ce scénario, le mot de passe d’un utilisateur peut expirer dans Azure
AD DS avant que l’utilisateur ne soit invité à le changer dans Azure AD ou dans un
environnement AD DS local.
Pour les comptes d’utilisateur créés manuellement dans un domaine managé, les
paramètres de mot de passe supplémentaires suivants sont également appliqués à
partir de la stratégie par défaut. Ces paramètres ne s’appliquent pas aux comptes
d’utilisateur synchronisés à partir d’Azure AD, car un utilisateur ne peut pas mettre à
jour son mot de passe directement dans Azure AD DS.
Longueur minimale du mot de passe (caractères) : 7

Les mots de passe doivent respecter les conventions de complexité
Vous ne pouvez pas modifier les paramètres de verrouillage de compte ou de mot de

passe dans la stratégie de mot de passe par défaut. En revanche, les membres du
groupe Administrateurs AAD DC peuvent créer des stratégies de mot de passe
personnalisées et les configurer pour qu’elles remplacent (prioritairement) la stratégie
intégrée par défaut, comme cela est expliqué dans la section suivante.
Créer une stratégie de mot de passe

personnalisée
Après avoir créé et exécuté plusieurs applications dans Azure, vous souhaiterez peut-
être configurer une stratégie de mot de passe personnalisée. Par exemple, vous pouvez
créer une stratégie pour définir différents paramètres de stratégie de verrouillage de
compte.
Les stratégies de mot de passe personnalisées sont appliquées aux groupes dans un
domaine managé. Cette configuration remplace de fait la stratégie par défaut.
Pour créer une stratégie de mot de passe personnalisée, utilisez les outils
d’administration Active Directory à partir d’une machine virtuelle jointe à un domaine. Le
Centre d’administration Active Directory vous permet d’afficher, de modifier et de créer
des ressources dans un domaine managé, notamment des unités d’organisation.
７ Notes
Pour créer une stratégie de mot de passe personnalisée dans un domaine managé,
vous devez être connecté à un compte d’utilisateur membre du groupe
Administrateurs AAD DC.

2. Pour créer et gérer des unités d’organisation, sélectionnez Centre d’administration

Active Directory dans la liste des outils d’administration.
3. Dans le volet gauche, choisissez votre domaine managé, par exemple

aaddscontoso.com.
4. Ouvrez le conteneur Système, puis la classe d’objets PSC (Password Settings

Container).
Une stratégie de mot de passe intégrée pour le domaine managé s’affiche. Vous ne
pouvez pas modifier cette stratégie intégrée. Vous devez créer une stratégie de
mot de passe personnalisée pour remplacer la stratégie par défaut.
5. Dans le volet des tâches à droite, sélectionnez Nouveau > Paramètres de mot de
passe.
6. Dans la boîte de dialogue Créer des paramètres de mot de passe, entrez un nom
pour la stratégie, par exemple MyCustomFGPP.
7. Quand plusieurs stratégies de mot de passe ont été définies, la stratégie appliquée
à un utilisateur est celle qui a la précédence, ou priorité, la plus élevée. Plus le
numéro est faible, plus la priorité est élevée. La stratégie de mot de passe par
défaut a une priorité de 200.
Définissez la précédence de votre stratégie de mot de passe personnalisée pour

remplacer la valeur par défaut, par exemple 1.
8. Modifiez les autres paramètres de la stratégie de mot de passe comme vous le

souhaitez. Les paramètres de verrouillage de compte s’appliquent à tous les
utilisateurs, mais prennent effet uniquement dans le domaine managé et non dans
Azure AD lui-même.
9. Décochez Protéger contre la suppression accidentelle. Si cette option est
sélectionnée, vous ne pouvez pas enregistrer la SMPA.
10. Dans la section S’applique directement à, cliquez sur le bouton Ajouter. Dans la
boîte de dialogue Sélectionner Utilisateurs ou Groupes, sélectionnez le bouton
Emplacements.
11. Dans la boîte de dialogue Emplacements, développez le nom de domaine, par

exemple aaddscontoso.com, puis sélectionnez une unité d’organisation, par
exemple Utilisateurs AADDC. Si vous avez à disposition une unité d’organisation
personnalisée qui contient un groupe d’utilisateurs auquel vous souhaitez
appliquer une stratégie, sélectionnez cette unité d’organisation.
12. Tapez le nom de l’utilisateur ou du groupe auquel vous souhaitez appliquer la
stratégie. Sélectionnez Vérifier les noms pour valider le compte.
13. Cliquez sur OK pour enregistrer votre stratégie de mot de passe personnalisée.
Étapes suivantes
Pour plus d’informations sur les stratégies de mot de passe et l’utilisation du Centre
d’administration Active Directory, consultez les articles suivants :
En savoir plus sur les stratégies de mot de passe affinées

Configurer des stratégies de mot de passe affinées à partir du Centre
d’administration Active Directory
Activer les audits de sécurité et de DNS
pour Azure Active Directory Domain
Services
Article • 11/05/2023
Les audits de sécurité et de DNS Azure Active Directory Domain Services (Azure AD DS)
permettent à Azure de diffuser en continu les événements aux ressources ciblées. Ces
ressources incluent le Stockage Microsoft Azure, les espaces de travail Azure Log
Analytics ou Azure Event Hub. Après avoir activé les événements d’audit de sécurité, le
service de domaine Azure AD DS envoie tous les événements audités pour la catégorie
sélectionnée à la ressource ciblée.
Vous pouvez archiver les événements dans les événements de diffusion en continu et de
Stockage Microsoft Azure à un logiciel SIEM (Security Information and Event
Management) (ou équivalent) à l’aide d’Azure Event Hubs ou effectuer votre propre
analyse et utiliser des espaces de travail Log Analytics, à partir du Portail Microsoft
Azure.
Destinations des audits de sécurité

Vous pouvez utiliser des espaces de travail Stockage Azure, Azure Event Hubs ou Azure
Log Analytics comme ressources cibles pour les audits de sécurité Azure Active Directory
Domain Services. Et vous pouvez combiner ces destinations. Par exemple, vous pouvez
un espace de travail Stockage Azure pour l’archivage d’événements d’audit de sécurité,
et un espace de travail Azure Log Analytics pour analyser et créer des rapport sur les
informations à court terme.
La table suivante présente les scénarios pour chaque type de ressource de destination.
） Important
Vous devez créer la ressource cible avant d’activer les audits de sécurité Azure
Active Directory Domain Services. Vous pouvez créer ces ressources en utilisant le
Portail Microsoft Azure, Azure PowerShell ou Azure CLI.
Ressource Scénario
cible
Ressource Scénario
cible
Stockage Utilisez cette cible si votre besoin principal repose sur le stockage des
Azure événements d’audit de sécurité à des fins d’archivage. Les autres cibles peuvent
être utilisées à des fins d’archivage ; toutefois, ces cibles fournissent des
fonctionnalités au-delà du besoin principal d’archivage.
Avant d’activer les événements d’audit de sécurité Azure AD DS, vous devez

d’abord créer un compte de stockage Azure.
Hubs Utilisez cette cible si votre besoin principal repose sur le partage des événements
d'événements d’audit de sécurité avec un autre logiciel tel qu’un logiciel d’analyse de données
Azure ou un logiciel de gestion des informations et des événements de sécurité (SIEM).
Avant d’activer les événements d’audit de sécurité Azure AD DS, créez un hub
Event Hub avec le Portail Microsoft Azure.
Espace de Utilisez cette cible si votre besoin principal repose sur l’analyse et le passage en
travail Azure revue des audits de sécurité directement à partir du Portail Microsoft Azure.
Log Analytics
Avant d’activer les événements d’audit de sécurité Azure AD DS, créez un espace
de travail Log Analytics dans le Portail Microsoft Azure.
Activer des événements d’audit de sécurité à

l’aide du Portail Microsoft Azure
Pour activer les événements d’audit de sécurité Azure AD DS à l’aide du Portail Microsoft
Azure, procédez comme suit.
） Important
Les audits de sécurité Azure AD DS ne sont pas rétroactifs. Vous ne pouvez pas
récupérer ou répéter des événements du passé. Le service Active Directory Domain
Services ne peut envoyer que des événements qui se produisent une fois les audits
de sécurité activés.
1. Connectez-vous au portail Azure.
2. Sur le Portail Microsoft Azure, recherchez et sélectionnez Azure AD Domain

Services. Choisissez votre domaine managé, par exemple aaddscontoso.com.
3. Dans la fenêtre Azure AD DS, sélectionnez Paramètres de diagnostic sur la partie

gauche.
4. Aucun diagnostic n’est configuré par défaut. Pour vous lancer, sélectionnez
Ajouter le paramètre de diagnostic.
5. Saisissez un nom pour la configuration de diagnostic, par exemple aadds-audit.
Cochez la case correspondant à la destination de l’audit de sécurité ou de DNS de

votre choix. Vous pouvez choisir un espace de travail Log Analytics, un compte
Stockage Azure, un hub d’événements Azure ou une solution de partenaire. Ces
ressources de destination doivent déjà figurer dans votre abonnement Azure. Vous
ne pouvez pas créer de ressources de destination dans cet assistant.
Espaces de travail Azure Log Analytics

Sélectionnez Envoyer à Log Analytics, puis choisissez l’abonnement et
l’espace de travail Log Analytics que vous souhaitez utiliser pour stocker
les événements d’audit.
Azure Storage
Sélectionnez Archiver dans un compte de stockage, puis Configurer.
Sélectionnez l’abonnement et le compte de stockage que vous souhaitez
utiliser pour archiver les événements d’audit.
Lorsque vous êtes prêt, sélectionnez OK.
Hubs Azure Event Hub
Sélectionnez Diffuser vers Event Hub, puis choisissez Configurer.
Sélectionnez l’abonnement et l’espace de noms Event Hub. Si nécessaire,
choisissez également un nom de hub Event Hub, puis un nom de
stratégie Event Hub.
Lorsque vous êtes prêt, sélectionnez OK.
Solution partenaire
Sélectionnez Envoyer à une solution de partenaire, puis choisissez
l’abonnement et la destination que vous souhaitez utiliser pour stocker
les événements d’audit.
6. Sélectionnez les catégories de journaux à inclure pour la ressource cible

particulière. Si vous envoyez les événements d’audit à un compte de Stockage
Microsoft Azure, vous pouvez également configurer une stratégie de rétention qui
définisse le nombre de jours pendant lesquels conserver les données. Un
paramètre par défaut de 0 conserve toutes les données et ne fait pas pivoter les
événements après un certain laps de temps.
Vous pouvez sélectionner différentes catégories de journaux pour chaque

ressource cible dans une même configuration. Cela vous permet par exemple de
choisir les catégories de journaux à conserver pour Log Analytics ainsi que les
catégories de journaux à archiver.
7. Cela fait, sélectionnez Enregistrer pour valider vos modifications. Les ressources
cibles commencent à recevoir des événements d’audit Azure AD DS peu après
l’enregistrement de la configuration.
Activer les événements d’audit de sécurité et de

DNS via Azure PowerShell
Pour activer les événements d’audit de sécurité et de DNS Azure AD DS à l’aide d’Azure
PowerShell, effectuez les étapes suivantes. Si nécessaire, commencez par installer le
module Azure PowerShell et vous connecter à votre abonnement Azure.
） Important
Les audits Azure AD DS ne sont pas rétroactifs. Vous ne pouvez pas récupérer ou
répéter des événements du passé. Azure AD DS ne peut envoyer que des
événements qui se produisent une fois les audits activés.
1. Connectez-vous à votre abonnement Azure à l’aide de la cmdlet Connect-

AzAccount. À l’invite, saisissez vos informations d’identification de compte.
Azure PowerShell
Connect-AzAccount
2. Créez la ressource cible pour les événements d’audit.
Espaces de travail Azure Log Analytics - Créer un espace de travail Log

Analytics avec Azure PowerShell.
Stockage Microsoft Azure - Créer un compte de stockage avec Azure

PowerShell
Azure Event Hub - Créer un hub Event Hub à l’aide d’Azure PowerShell. Vous
devrez peut-être également utiliser la cmdlet New-
AzEventHubAuthorizationRule pour créer une règle d’autorisation qui
accorde à Azure Active Directory Domain Services des autorisations d’accès à
l’espace de noms Event Hub. La règle d’autorisation doit inclure les droits
Manage (Gérer), Listen (Écouter) et Send (Envoyer).
） Important
Vérifiez que vous définissez la règle d’autorisation sur l’espace de noms

du hub Event Hub, et non sur le hub lui-même.
3. Récupérez l’ID de ressource de votre domaine Azure AD DS géré à l’aide de la

cmdlet Get-AzResource. Créez une variable nommée $aadds.ResourceId pour
contenir la valeur :
Azure PowerShell
$aadds = Get-AzResource -name aaddsDomainName
4. Configurez les paramètres de diagnostic Azure à l’aide de l’applet de commande

Set-AzDiagnosticSetting pour utiliser la ressource cible pour les événements
d’audit Azure AD Domain Services. Dans les exemples suivants, la variable
$aadds.ResourceId de l’étape précédente est utilisée.
Stockage Microsoft Azure : remplacez storageAccountId par le nom de votre

compte de stockage :
PowerShell
Set-AzDiagnosticSetting `
-ResourceId $aadds.ResourceId `
-StorageAccountId storageAccountId `
-Enabled $true
Azure Event Hubs : remplacez eventHubName par le nom de votre hub Event
Hub, et eventHubRuleId par l’ID de votre règle d’autorisation :
PowerShell
Set-AzDiagnosticSetting -ResourceId $aadds.ResourceId `
-EventHubName eventHubName `
-EventHubAuthorizationRuleId eventHubRuleId `
-Enabled $true
Espaces de travail Azure Log Analytics : remplacez workspaceId par l’ID de

l’espace de travail Log Analytics :
PowerShell
Set-AzureRmDiagnosticSetting -ResourceId $aadds.ResourceId `
-WorkspaceID workspaceId `
-Enabled $true
Interroger et afficher les événements d’audit de

sécurité et de DNS à l’aide d’Azure Monitor
Les espaces de travail Log Analytics vous permettent d’afficher et d’analyser les
événements d’audit de sécurité et de DNS à l’aide d’Azure Monitor et du langage de
requête Kusto. Ce langage de requête est conçu pour être utilisé en lecture seule,
offrant des capacités d’analyse puissantes et une syntaxe facile à lire. Pour en savoir plus
sur la prise en main des langages de requête Kusto, consultez les articles suivants :
Documentation Azure Monitor

Prise en main de Log Analytics dans Azure Monitor
Bien démarrer avec les requêtes de journal Azure Monitor.
Créer et partager des tableaux de bord de données Log Analytics
Les exemples de requêtes suivants peuvent être utilisés pour lancer l’analyse des
événements d’audit depuis Azure AD DS.
Exemple de requête 1
Affichez tous les événements de verrouillage de compte au cours des sept derniers
jours :
Kusto
AADDomainServicesAccountManagement
| where TimeGenerated >= ago(7d)
| where OperationName has "4740"
Affichez tous les événements de verrouillage de compte (4740) entre le 3 juin 2020 à 9 h
00 et le 10 juin 2020 à minuit, triés par ordre croissant de date et d’heure :
Kusto
| where TimeGenerated >= datetime(2020-06-03 09:00) and TimeGenerated <=

datetime(2020-06-10)
| sort by TimeGenerated asc
Affichez les événements de connexion de compte survenus sept jours plus tôt pour
l’utilisateur de compte nommé :
Kusto
AADDomainServicesAccountLogon
| where "user" == tolower(extract("Logon Account:\t(.+[0-9A-Za-

z])",1,tostring(ResultDescription)))
l’utilisateur de compte nommé qui a tenté de se connecter à l’aide d’un mot de passe
incorrect (0xC0000006a) :
Kusto

| where "0xc000006a" == tolower(extract("Error Code:\t(.+[0-9A-Fa-

f])",1,tostring(ResultDescription)))
l’utilisateur de compte nommé qui a tenté de se connecter alors que le compte était
verrouillé (0xC0000234) :
Kusto

| where "0xc0000234" == tolower(extract("Error Code:\t(.+[0-9A-Fa-

Affichez le nombre d’événements de connexion de compte survenus sept jours plus tôt
pour toutes les tentatives de connexion qui se sont produites pour tous les utilisateurs
verrouillés :
Kusto
| where "0xc0000234" == tolower(extract("Error Code:\t(.+[0-9A-Fa-

| summarize count()
Auditer les catégories d’événements de

sécurité et de DNS
Les audits de sécurité et de DNS Azure AD DS s’alignent sur l’audit traditionnel des
contrôleurs de domaine AD DS classiques. Dans les environnements hybrides, la
réutilisation de modèles d’audit existants garantit que la même logique peut être
utilisée lors de l’analyse des événements. Selon le scénario que vous devez dépanner ou
analyser, différentes catégories d’événements d’audit doivent être ciblées.
Les catégories d’événements d’audit suivantes sont disponibles :
Nom de la Description
catégorie d’audit
Connexion de Audite les tentatives d’authentification de données de compte sur un

compte contrôleur de domaine ou sur un gestionnaire de comptes de sécurité
local.
- Les événements et les paramètres de stratégie d’ouverture et de

fermeture de session suivent les tentatives d’accès à un ordinateur
particulier. Les paramètres et les événements de cette catégorie se
concentrent sur la base de données de compte qui est utilisée. Cette
catégorie comprend les sous-catégories suivantes :
-Auditer la validation des informations d’identification
-Auditer le service d’authentification Kerberos
-Auditer les opérations de ticket du service Kerberos
-Auditer d’autres événements d’ouverture/fermeture de session
Gestion de compte Audite les modifications apportées aux groupes et comptes d’utilisateurs
et d’ordinateurs. Cette catégorie comprend les sous-catégories suivantes :
-Auditer la gestion des groupes d’applications
-Auditer la gestion des comptes d’ordinateur
-Auditer la gestion des groupes de distribution
-Auditer d’autres événements de gestion des comptes
-Auditer la gestion des groupes de sécurité
-Auditer la gestion des comptes d’utilisateur
Serveur DNS Audite les modifications apportées aux environnements DNS. Cette
- DNSServerAuditsDynamicUpdates (préversion)
- DNSServerAuditsGeneral (préversion)
Suivi des détails Audit les activités des applications et utilisateurs individuels sur
l’ordinateur concerné et le fonctionnement de cet ordinateur. Cette
-Auditer l’activité DPAPI
-Auditer l’activité Plug-and-Play
-Auditer la création de processus
-Auditer la fin du processus
-Auditer les événements RPC
Accès aux services Audite les tentatives d’accès aux objets dans Active Directory Domain
d’annuaire Services (AD DS) et de modification de ces derniers. Ces événements
d’audit sont journalisés uniquement sur des contrôleurs de domaine. Cette
-Auditer la réplication du service d’annuaire détaillé
-Auditer l’accès au service d’annuaire
-Auditer les modifications du service d’annuaire
-Auditer la réplication du service d’annuaire

Ouverture/fermeture Audite les tentatives d’ouverture de session sur un ordinateur de manière

de session interactive ou par le biais d’un réseau. Ces événements sont utiles pour le
suivi de l’activité de l’utilisateur et l’identification des attaques potentielles
sur les ressources réseau. Cette catégorie comprend les sous-catégories
suivantes :
-Auditer le verrouillage du compte
-Auditer les revendications utilisateur/de périphérique
-Auditer le mode étendu IPsec
-Auditer l’appartenance à un groupe
-Auditer le mode principal IPsec
-Auditer le mode rapide IPsec
-Auditer la fermeture de session
-Auditer l’ouverture de session
-Auditer le serveur NPS (Network Policy Server)
-Auditer d’autres événements d’ouverture/fermeture de session
-Auditer l’ouverture de session spéciale
Accès aux objets Audite les tentatives d’accès à des objets ou types d’objets spécifiques sur
un ordinateur ou réseau. Cette catégorie comprend les sous-catégories
suivantes :
-Auditer l’application générée
-Auditer les services de certification
-Auditer le partage de fichiers détaillé
-Auditer le partage de fichiers
-Auditer le système de fichiers
-Auditer la connexion de la plateforme de filtrage

-Auditer le rejet de paquet par la plateforme de filtrage
-Auditer la manipulation de handle
-Auditer l’objet de noyau
-Auditer d’autres événements d’accès à l’objet
-Auditer le registre
-Auditer le stockage amovible
-Auditer SAM
-Auditer la stratégie d’accès centralisée intermédiaire

Modification de Audite les modifications apportées aux stratégies de sécurité importantes

stratégie sur un réseau ou un système local. Les stratégies sont généralement
établies par les administrateurs pour faciliter la sécurisation des ressources
réseau. La supervision des modifications ou des tentatives de modification
de ces stratégies peut être un aspect important de la gestion de la sécurité
pour un réseau. Cette catégorie comprend les sous-catégories suivantes :
-Auditer la modification de la stratégie d’audit
-Auditer la modification de stratégie d’authentification
-Auditer la modification de la stratégie d’autorisation
-Auditer la modification de la stratégie de plateforme de filtrage
-Auditer la modification de la stratégie de niveau règle MPSSVC
-Auditer d’autres événements de modification de stratégie
Utilisation des Audite l’utilisation de certaines autorisations sur un ou plusieurs systèmes.

privilèges Cette catégorie comprend les sous-catégories suivantes :
-Auditer l’utilisation de privilèges non sensibles
-Auditer l’utilisation de privilèges sensibles
-Auditer d’autres événements d’utilisation de privilèges
Système Audite les modifications de niveau système apportées à un ordinateur non

incluses dans les autres catégories et qui ont des implications de sécurité
potentielles. Cette catégorie comprend les sous-catégories suivantes :
-Auditer le pilote IPSEC
-Auditer d’autres événements système
-Auditer la modification de l’état de la sécurité
-Auditer l’extension du système de sécurité
-Auditer l’intégrité du système
ID d’événements par catégorie

Les audits de sécurité et de DNS Azure AD DS enregistrent les ID d’événement suivants
lorsque l’action spécifique déclenche un événement pouvant être audité :
Nom de la ID d’événement
catégorie
d’événements
Sécurité de la 4767, 4774, 4775, 4776, 4777

connexion de
compte
Nom de la ID d’événement
catégorie
d’événements
Sécurité de la gestion 4720, 4722, 4723, 4724, 4725, 4726, 4727, 4728, 4729, 4730, 4731, 4732,
des comptes 4733, 4734, 4735, 4737, 4738, 4740, 4741, 4742, 4743, 4754, 4755, 4756,
4757, 4758, 4764, 4765, 4766, 4780, 4781, 4782, 4793, 4798, 4799, 5376,
5377
Sécurité du suivi des None

détails
Serveur DNS 513-523, 525-531, 533-537, 540-582
Sécurité de l’accès 5136, 5137, 5138, 5139, 5141

DS
Sécurité de 4624, 4625, 4634, 4647, 4648, 4672, 4675, 4964

l’ouverture/fermeture
de session
Sécurité de l’accès None

aux objets
Sécurité de la 4670, 4703, 4704, 4705, 4706, 4707, 4713, 4715, 4716, 4717, 4718, 4719,
modification de 4739, 4864, 4865, 4866, 4867, 4904, 4906, 4911, 4912
stratégie
Sécurité de 4985
l’utilisation des
privilèges
Sécurité système 4612, 4621
Étapes suivantes
Pour plus d’informations sur Kusto, consultez les articles suivants :
Vue d’ensemble du langage de requête Kusto.

Tutoriel Kusto pour vous familiariser avec les principes fondamentaux des
requêtes.
Exemples de requêtes qui vous aident à découvrir de nouvelles façons de voir vos
données.
Meilleures pratiques de Kusto pour optimiser vos requêtes.
Examiner les événements d’audit de
sécurité dans Azure Active Directory
Domain Services à l’aide d’Azure
Monitor Workbooks
Article • 01/06/2023
Pour mieux comprendre l’état de votre domaine managé Azure Active Directory Domain
Services (Azure AD DS), vous pouvez activer des événements d’audit de sécurité. Il est
alors possible d’examiner ces événements d’audit de sécurité à l’aide des classeurs
Azure Monitor qui combinent du texte, des requêtes analytiques et des paramètres dans
des rapports interactifs enrichis. Azure AD DS comprend des modèles de classeurs pour
avoir une vue d’ensemble de la sécurité et l’activité des comptes et vous permettre ainsi
d’explorer les événements d’audit et de gérer votre environnement.
Cet article explique comment utiliser des classeurs Azure Monitor pour examiner les
événements d’audit de sécurité dans Azure AD DS.
Avant de commencer
Événements d’audit de sécurité activés pour votre domaine managé qui diffusent
en continu des données vers un espace de travail Log Analytics.
Si nécessaire, activer les audits de sécurité pour Azure AD DS.
Vue d’ensemble des classeurs Azure Monitor

Lorsque les événements d’audit de sécurité sont activés dans Azure AD DS, il peut être
difficile d’analyser et d’identifier les problèmes dans le domaine managé. Azure Monitor
vous permet d’agréger ces événements d’audit de sécurité et d’interroger les données.
Les classeurs Azure Monitor vous permettent de visualiser ces données afin d’accélérer
et de faciliter l’identification des problèmes.
Les modèles de classeur sont des rapports organisés conçus pour une réutilisation
flexible par plusieurs utilisateurs et équipes. Lorsque vous ouvrez un modèle de classeur,
les données de votre environnement Azure Monitor sont chargées. Vous pouvez utiliser
des modèles sans incidence sur les autres utilisateurs de votre organisation, et vous
pouvez enregistrer vos classeurs basés sur le modèle.
Azure AD DS comprend les deux modèles de classeurs suivants :
Rapport Vue d’ensemble de la sécurité

Rapport d’activité de compte
Pour plus d’informations sur la modification et la gestion des classeurs, consultez Vue
d’ensemble des classeurs Azure Monitor.
Utiliser le classeur de rapport Vue d’ensemble

de la sécurité
Pour vous aider à mieux comprendre l’utilisation et à identifier les menaces de sécurité
potentielles, le rapport Vue d’ensemble de la sécurité résume les données de connexion
et identifie les comptes que vous souhaitez peut-être vérifier. Vous pouvez afficher les
événements dans une plage de dates particulière et descendre dans la hiérarchie des
événements de connexion spécifiques, tels que les tentatives de mot de passe
incorrectes ou l’endroit où le compte a été désactivé.
Pour accéder au modèle de classeur pour le rapport de vue d’ensemble de la sécurité,

1. Sur le portail Azure, recherchez et sélectionnez Services de domaine Azure AD.
3. Dans le menu de gauche, choisissez Supervision > Workbooks

4. Choisissez le Rapport Vue d’ensemble de la sécurité.
5. Dans les menus déroulants en haut du classeur, sélectionnez votre abonnement

Azure, puis un espace de travail Azure Monitor.
Choisissez un intervalle de temps, par exemple 7 derniers jours, comme indiqué

dans la capture d’écran suivante :
Vous pouvez également modifier les options de l’affichage Mosaïque et de

l’affichage Graphique pour analyser et visualiser les données selon vos besoins.
6. Pour descendre dans la hiérarchie des types d’événement, sélectionnez l’une des
cartes Résultat de connexion par exemple Compte verrouillé, comme illustré dans
7. La partie inférieure du rapport Vue d’ensemble de la sécurité figure sous le
graphique décompose ensuite le type d’activité sélectionné. Sur le côté droit, vous
pouvez filtrer par nom d’utilisateur impliqué, comme indiqué dans l’exemple de
rapport suivant :
Utiliser le classeur du rapport d’activité de

compte
Pour vous aider à résoudre les problèmes liés à un compte d’utilisateur spécifique, le
rapport d’activité du compte distingue les informations détaillées du journal des
événements d’audit. Vous pouvez vérifier si un nom d’utilisateur ou un mot de passe
incorrect a été fourni lors de la connexion, ainsi que la source de la tentative de
connexion.
Pour accéder au modèle de classeur pour le rapport d’activité du compte, procédez

comme suit :
1. Sur le portail Azure, recherchez et sélectionnez Services de domaine Azure AD.
3. Dans le menu de gauche, choisissez Supervision > Workbooks
4. Choisissez le rapport d’activité de compte.
5. Dans les menus déroulants en haut du classeur, sélectionnez votre abonnement

Azure, puis un espace de travail Azure Monitor.
Choisissez une Période, par exemple Les 30 derniers jours, puis la manière dont
vous souhaitez que l’affichage Mosaïque représente les données.
Vous pouvez filtrer par Nom d’utilisateur du compte, par exemple felix, comme
indiqué dans l’exemple de rapport suivant :

La zone située sous le graphique affiche les événements de connexion individuels,
ainsi que des informations telles que le résultat de l’activité et la station de travail
source. Ces informations peuvent aider à identifier les sources répétées
d’événements de connexion qui peuvent provoquer le verrouillage de compte ou
indiquer une attaque potentielle.
Comme pour le rapport Vue d’ensemble de la sécurité, vous pouvez accéder aux
différentes vignettes en haut du rapport pour visualiser et analyser les données en
fonction des besoins.
Enregistrer et modifier les classeurs

Les deux classeurs de modèles fournis par Azure AD DS constituent un excellent point
de départ pour effectuer votre analyse de données. Si vous avez besoin d’une plus
grande précision dans les requêtes et investigations de données, vous pouvez
enregistrer vos classeurs et modifier les requêtes.
1. Pour enregistrer une copie de l’un des modèles de classeur, sélectionnez Modifier
> Enregistrer sous > Rapports partagés, puis entrez un nom et enregistrez-le.
2. À partir de votre copie du modèle, sélectionnez Modifier pour passer en mode
d’édition. Vous pouvez choisir le bouton bleu Modifier en regard d’une partie du
rapport afin de la modifier.
Tous les graphiques et tables des classeurs Azure Monitor sont générés à l’aide de
requêtes Kusto. Pour plus d’informations sur la création de vos requêtes, consultez
Requêtes de journal Azure Monitor et Didacticiel sur les requêtes Kusto.
Étapes suivantes
Si vous devez ajuster les stratégies de mot de passe et de verrouillage, consultez la
rubrique Stratégies de mot de passe et de verrouillage de compte sur les domaines
managés.
Pour les problèmes liés aux utilisateurs, découvrez résoudre les problèmes de connexion
de compte et les problèmes de verrouillage de compte.
Sécuriser l’accès à distance aux
machines virtuelles dans Azure Active
Article • 01/06/2023
Pour sécuriser l’accès à distance aux machines virtuelles qui s’exécutent dans un
domaine managé Azure Active Directory Domain Services (Azure AD DS), vous pouvez
utiliser les services Bureau à distance (RDS) et le serveur NPS (Network Policy Server).
Azure AD DS authentifie les utilisateurs quand ils demandent l’accès par le biais de
l’environnement des services Bureau à distance. Pour renforcer la sécurité, vous pouvez
intégrer Azure AD Multi-Factor Authentication afin de fournir une invite
d'authentification supplémentaire pendant les événements de connexion. Pour fournir
cette fonctionnalité, Azure AD Multi-Factor Authentication utilise une extension NPS.
） Important
La méthode recommandée pour se connecter en toute sécurité à vos machines

virtuelles dans un domaine managé Azure AD DS consiste à utiliser Azure Bastion,
un service PaaS complètement managé par la plateforme, que vous approvisionnez
à l’intérieur de votre réseau virtuel. Un hôte bastion offre une connectivité sécurisée
et transparente suivant le protocole RDP (Remote Desktop Protocol) à vos
machines virtuelles directement dans le portail Azure via le protocole SSL. Lorsque
vous vous connectez via un hôte bastion, vos machines virtuelles n’ont pas besoin
d’adresse IP publique, et vous n’avez pas besoin d’utiliser des groupes de sécurité
réseau pour exposer l’accès au protocole RDP sur le port TCP 3389.
Nous vous recommandons vivement d’utiliser le service Azure Bastion dans toutes
les régions où il est pris en charge. Dans les régions où Azure Bastion n’est pas
disponible, suivez les étapes décrites dans cet article en attendant que le service
soit disponible. Veillez à attribuer des adresses IP publiques aux machines virtuelles
jointes à Azure AD DS où tout le trafic RDP entrant est autorisé.
Pour plus d’informations, consultez Présentation d’Azure Bastion.
Cet article explique comment configurer les services Bureau à distance dans Azure AD
DS et comment utiliser l'extension NPS d'Azure AD Multi-Factor Authentication.
Prérequis
suivantes :
Domain Services.
Un sous-réseau de charges de travail créé dans votre réseau virtuel Azure Active
Si nécessaire, configurez un réseau virtuel pour une instance Azure Active
Déployer et configurer l’environnement de

Bureau à distance
Pour commencer, créez au minimum deux machines virtuelles Azure exécutant Windows
Server 2016 ou Windows Server 2019. Pour assurer la redondance et la haute
disponibilité de votre environnement de Bureau à distance, vous pouvez ajouter des
hôtes supplémentaires et équilibrer la charge ultérieurement.
Un déploiement des services Bureau à distance suggéré comprend les deux machines
virtuelles suivantes :
RDGVM01 : exécute les serveurs Broker pour les connexions Bureau à distance,
Accès Web des services Bureau à distance et Passerelle des services Bureau à
distance.
RDSHVM01 : exécute le serveur Hôte de session Bureau à distance.
Assurez-vous que les machines virtuelles sont déployées dans un sous-réseau de

charges de travail de votre réseau virtuel Azure AD DS, puis joignez les machines
virtuelles à un domaine managé. Pour plus d’informations, découvrez comment créer
une machine virtuelle Windows Server et la joindre à un domaine managé.
Le déploiement de l’environnement de Bureau à distance contient un certain nombre

d’étapes. Le guide de déploiement de Bureau à distance existant peut être utilisé sans
modification spécifique dans un domaine managé :
1. Connectez-vous aux machines virtuelles créées pour l’environnement de Bureau à

distance à l’aide d’un compte faisant partie du groupe Administrateurs Azure AD
DC, par exemple, contosoadmin.
2. Pour créer et configurer des services Bureau à distance, utilisez le Guide de
déploiement de l’environnement de Bureau à distance existant. Distribuez les
composants du serveur Bureau à distance sur vos machines virtuelles Azure à votre
guise.
Spécificité d’Azure AD DS : lorsque vous configurez le gestionnaire de

licences des services Bureau à distance, définissez-le sur mode Par appareil,
non Par utilisateur comme indiqué dans le Guide de déploiement.
3. Si vous souhaitez fournir l’accès à l’aide d’un navigateur web, Configurez le client
web Bureau à distance pour vos utilisateurs.
Avec le Bureau à distance déployé dans le domaine managé, vous pouvez gérer et
utiliser le service comme vous le feriez avec un domaine AD DS local.
Déployer et configurer le serveur NPS

(Network Policy Server) et l'extension NPS
d'Azure AD MFA
Si vous le souhaitez, vous pouvez renforcer la sécurité de l'expérience de connexion
utilisateur en intégrant l'environnement de Bureau à distance à Azure AD Multi-Factor
Authentication. Avec cette configuration, les utilisateurs reçoivent une invite
supplémentaire pendant la connexion pour confirmer leur identité.
Pour fournir cette fonctionnalité, un serveur NPS (Network Policy Server) supplémentaire
est installé dans votre environnement avec l'extension NPS d'Azure AD Multi-Factor
Authentication. Cette extension s’intègre avec Azure AD pour demander et retourner
l’état des invites d’authentification multifacteur.
Les utilisateurs doivent être inscrits pour utiliser Azure AD Multi-Factor Authentication,
ce qui peut nécessiter des licences Azure AD supplémentaires.
Pour intégrer Azure AD Multi-Factor Authentication dans votre environnement de

Bureau à distance Azure AD DS, créez un serveur NPS et installez l'extension :
1. Créez une machine virtuelle Windows Server 2016 ou 2019 supplémentaire, par
exemple, NPSVM01, qui est connectée à un sous-réseau de charges de travail dans
votre réseau virtuel Azure AD DS. Joignez la machine virtuelle au domaine managé.
2. Connectez-vous à la machine virtuelle NPS en tant que compte faisant partie du
groupe Administrateurs Azure AD DC, par exemple, contosoadmin.
3. Dans le Gestionnaire de serveur, sélectionnez Ajouter des rôles et des
fonctionnalités, puis installez le rôle Services de stratégie et d’accès réseau.
4. Consultez l'article de procédure existant pour installer et configurer l'extension
NPS d'Azure AD MFA.
Une fois le serveur NPS et l'extension NPS d'Azure AD Multi-Factor Authentication

installés, consultez la section suivante pour les configurer en vue de leur utilisation avec
l'environnement de Bureau à distance.
Intégrer la Passerelle des services Bureau à

distance et Azure AD Multi-Factor
Authentication
Pour intégrer l'extension NPS d'Azure AD Multi-Factor Authentication, consultez l'article
de procédure expliquant comment intégrer votre infrastructure de Passerelle des
services Bureau à distance à l'aide de l'extension NPS (Network Policy Server) et d'Azure
AD.
Les options de configuration supplémentaires suivantes sont nécessaires pour

l’intégration avec un domaine managé :
1. N’Enregistrez pas le serveur NPS dans Active Directory. Cette étape échoue dans
un domaine managé.
2. À l’étape 4 pour configurer la stratégie réseau, activez également la case à cocher
Ignorer les propriétés de numérotation des comptes d’utilisateurs.
3. Si vous utilisez Windows Server 2019 pour le serveur NPS et l'extension NPS

d'Azure AD Multi-Factor Authentication, exécutez la commande suivante pour
mettre à jour le canal sécurisé afin de permettre au serveur NPS de communiquer
correctement :
PowerShell
sc sidtype IAS unrestricted
Les utilisateurs sont désormais invités à entrer un facteur d’authentification

supplémentaire lorsqu’ils se connectent, par exemple un message texte ou une invite
dans l’application Microsoft Authenticator.
Étapes suivantes
Pour plus d’informations sur l’amélioration de la résilience de votre déploiement,
consultez Services Bureau à distance – Haute disponibilité.
Pour plus d’informations sur la sécurisation de la connexion utilisateurs, consultez

Fonctionnement : Azure AD Multi-Factor Authentication.
Base de référence de sécurité d’Azure
Article • 12/04/2023
Cette base de référence de sécurité applique les conseils du benchmark de sécurité

cloud Microsoft version 1.0 à Azure services de domaine Active Directory. Le benchmark
de sécurité cloud Microsoft fournit des recommandations sur la façon dont vous pouvez
sécuriser vos solutions cloud sur Azure. Le contenu est regroupé selon les contrôles de
sécurité définis par le benchmark de sécurité cloud Microsoft et les conseils associés
applicables à Azure services de domaine Active Directory.
Vous pouvez surveiller cette base de référence de sécurité et ses recommandations à

l’aide de Microsoft Defender pour le cloud. Azure Policy définitions sont répertoriées
dans la section Conformité réglementaire du tableau de bord Microsoft Defender pour
le cloud.
Lorsqu’une fonctionnalité a des définitions de Azure Policy pertinentes, elles sont

répertoriées dans cette base de référence pour vous aider à mesurer la conformité aux
contrôles et recommandations du benchmark de sécurité cloud Microsoft. Certaines
recommandations peuvent nécessiter un plan de Microsoft Defender payant pour
activer certains scénarios de sécurité.
７ Notes
Les fonctionnalités non applicables à Azure services de domaine Active Directory

ont été exclues. Pour voir comment Azure services de domaine Active Directory
entièrement mappé au benchmark de sécurité cloud Microsoft, consultez le fichier
de mappage complet de la base de référence de sécurité Azure services de
domaine Active Directory .
Profil de sécurité
Le profil de sécurité résume les comportements à fort impact d’Azure services de
domaine Active Directory, ce qui peut entraîner des considérations de sécurité accrues.
Attribut de comportement du service Valeur
Catégorie de produit Identité
Le client peut accéder à HOST/OS Aucun accès

Attribut de comportement du service Valeur
Le service peut être déployé dans le réseau virtuel du client Vrai
Stocke le contenu client au repos Vrai
Sécurité du réseau
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Sécurité
réseau.
NS-1 : Établir des limites de segmentation réseau
Fonctionnalités
Intégration du réseau virtuel
Description : Le service prend en charge le déploiement dans le Réseau virtuel privé

(VNet) du client. Plus d’informations
Pris en charge Activé par défaut Responsabilité de la configuration
True True Microsoft
Conseils de configuration : Aucune configuration supplémentaire n’est requise, car elle

est activée sur un déploiement par défaut.
Référence : Considérations relatives à la conception de réseaux virtuels et options de

configuration pour Azure services de domaine Active Directory
Prise en charge des groupes de sécurité réseau
Description : Le trafic réseau de service respecte l’attribution de règles groupes de

sécurité réseau sur ses sous-réseaux. Plus d’informations
Vrai False Customer
Conseils de configuration : Utilisez des groupes de sécurité réseau (NSG) pour

restreindre ou surveiller le trafic par port, protocole, adresse IP source ou adresse IP de
destination. Créez des règles de groupe de sécurité réseau pour restreindre les ports
ouverts de votre service (par exemple, empêcher l’accès aux ports de gestion à partir de
réseaux non approuvés). N’oubliez pas que par défaut, les groupes de sécurité réseau
refusent tout le trafic entrant, mais autorisent le trafic provenant du réseau virtuel et
d’Azure Load Balancers.
Référence : Considérations relatives à la conception de réseaux virtuels et options de

configuration pour Azure services de domaine Active Directory
NS-2 : Sécuriser les services cloud avec des contrôles

réseau
Fonctionnalités
Azure Private Link
Description : Fonctionnalité de filtrage IP native du service pour le filtrage du trafic

réseau (à ne pas confondre avec le groupe de sécurité réseau ou Pare-feu Azure). Plus
d’informations
False Non applicable Non applicable
Conseils de configuration : cette fonctionnalité n’est pas prise en charge pour sécuriser
ce service.
Désactiver l’accès public au réseau
Description : le service prend en charge la désactivation de l’accès au réseau public à

l’aide d’une règle de filtrage de liste de contrôle d’accès IP au niveau du service (pas de
groupe de sécurité réseau ou de Pare-feu Azure) ou à l’aide d’un commutateur bascule «
Désactiver l’accès réseau public ». Plus d’informations
ce service.
Gestion des identités

Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Gestion des
identités.
IM-1 : utiliser le système centralisé d’identité et

d’authentification
Fonctionnalités
Azure AD Authentication requis pour l’accès au plan de données
Description : Le service prend en charge l’utilisation de l’authentification Azure AD pour

l’accès au plan de données. Plus d’informations
ce service.
Méthodes d’authentification locales pour l’accès au plan de

données
Description : méthodes d’authentification locales prises en charge pour l’accès au plan

de données, telles qu’un nom d’utilisateur et un mot de passe locaux. Plus
d’informations
Vrai False Customer
Remarques sur les fonctionnalités : évitez d’utiliser des comptes ou des méthodes
d’authentification locaux. Ceux-ci doivent être désactivés dans la mesure du possible.
Utilisez plutôt Azure AD pour vous authentifier lorsque cela est possible.
Conseils de configuration : Évitez l’utilisation de méthodes ou de comptes

d’authentification locaux. Ceux-ci doivent être désactivés dans la mesure du possible.
Utilisez plutôt des comptes synchronisés à partir d’Azure AD pour vous authentifier si
possible.
Référence : Création de compte d’utilisateur

IM-3 : gérer les identités d’application de façon sécurisée
et automatique
Fonctionnalités
Identités managées
Description : les actions de plan de données prennent en charge l’authentification à

l’aide d’identités managées. Plus d’informations
Conseils de configuration : Cette fonctionnalité n’est pas prise en charge pour sécuriser
ce service.
Principaux de service
Description : Le plan de données prend en charge l’authentification à l’aide de

principaux de service. Plus d’informations
ce service.
Accès privilégié
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Accès
privilégié.
PA-1 : Séparer et limiter les utilisateurs hautement

privilégiés/administratifs
Fonctionnalités
Comptes Administration locaux
Description : le service a le concept d’un compte d’administration local. Plus

d’informations
Prise en charge Activé par défaut Responsabilité de la configuration
ce service.
PA-7 : Suivre le principe JEA, Just Enough Administration

(privilège minimum)
Fonctionnalités
RBAC Azure pour le plan de données
Description : Azure Role-Based Access Control (Azure RBAC) peut être utilisé pour gérer
l’accès aux actions de plan de données du service. Plus d’informations
ce service.
PA-8 : Déterminer le processus d’accès pour la prise en

charge du fournisseur de cloud
Fonctionnalités
Customer Lockbox
Description : Customer Lockbox peut être utilisé pour l’accès au support Microsoft. Plus
d’informations

ce service.
Protection des données

Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Protection
des données.
DP-1 : Découvrir, classer et étiqueter des données

sensibles
Fonctionnalités
Découverte et classification des données sensibles
Description : Les outils (tels qu’Azure Purview ou Azure Information Protection) peuvent
être utilisés pour la découverte et la classification des données dans le service. Plus
d’informations
ce service.
DP-2 : surveiller les anomalies et les menaces ciblant les

données sensibles
Fonctionnalités
Protection contre les fuites/pertes de données
Description : Le service prend en charge la solution DLP pour surveiller le déplacement

des données sensibles (dans le contenu du client). Plus d’informations
ce service.
DP-3 : chiffrer les données sensibles en transit
Fonctionnalités
Données dans le chiffrement du transit
Description : Le service prend en charge le chiffrement des données en transit pour le

plan de données. Plus d’informations
Vrai False Customer
Conseils de configuration : Activez le transfert sécurisé dans les services où il existe une
fonctionnalité de chiffrement de données natives dans le transit intégrée. Appliquez
HTTPS à tous les services et applications web et assurez-vous que TLS v1.2 ou version
ultérieure est utilisé. Les versions héritées telles que SSL 3.0 et TLS v1.0 doivent être
désactivées. Pour la gestion à distance de Machines Virtuelles, utilisez SSH (pour Linux)
ou RDP/TLS (pour Windows) au lieu d’un protocole non chiffré.
Référence : Tutoriel : Configurer ldap sécurisé pour un domaine managé Azure services
de domaine Active Directory
DP-4 : activer le chiffrement des données au repos par

défaut
Fonctionnalités
Chiffrement des données au repos à l’aide de clés de plateforme
Description : Le chiffrement des données au repos à l’aide de clés de plateforme est pris
en charge. Tout contenu client au repos est chiffré avec ces clés gérées par Microsoft.
Plus d’informations
True True Microsoft
Remarques sur les fonctionnalités : les utilisateurs ne peuvent pas configurer la

fonctionnalité et elle est activée par défaut.

DP-5 : utiliser l’option de clé gérée par le client dans le

chiffrement des données au repos si nécessaire
Fonctionnalités
Chiffrement des données au repos à l’aide de cmk
Description : le chiffrement des données au repos à l’aide de clés gérées par le client est
pris en charge pour le contenu client stocké par le service. Plus d’informations
ce service.
DP-6 : Utiliser un processus sécurisé de gestion de clés
Fonctionnalités
Gestion des clés dans Azure Key Vault
Description : Le service prend en charge l’intégration d’Azure Key Vault pour toutes les
clés client, secrets ou certificats. Plus d’informations

ce service.
Gestion des ressources

Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Gestion des
ressources.
AM-2 : Utiliser uniquement des services approuvés
Fonctionnalités
Prise en charge d’Azure Policy
Description : Les configurations de service peuvent être surveillées et appliquées via

Azure Policy. Plus d’informations
True True Microsoft
Remarques sur les fonctionnalités : le client n’a pas la possibilité de configurer la

fonctionnalité sur le produit.

Référence : Stratégie intégrée Azure Active Directory
Journalisation et détection des menaces

Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft :
Journalisation et détection des menaces.
LT-1 : activer les fonctionnalités de détection des menaces
Fonctionnalités
Microsoft Defender pour l’offre de service/produit

Description : le service dispose d’une solution de Microsoft Defender spécifique à l’offre
pour surveiller et alerter sur les problèmes de sécurité. Plus d’informations
ce service.
LT-4 : Activer la journalisation pour l’investigation de

sécurité
Fonctionnalités
Journaux des ressources Azure
Description : le service produit des journaux de ressources qui peuvent fournir des
métriques et une journalisation améliorées spécifiques au service. Le client peut
configurer ces journaux de ressources et les envoyer à son propre récepteur de
données, comme un compte de stockage ou un espace de travail Log Analytics. Plus
d’informations
Vrai False Customer
Conseils de configuration : Les audits de sécurité Azure services de domaine Active

Directory (Azure AD DS) permettent à Azure de diffuser en continu les événements de
sécurité vers des ressources ciblées. Ces ressources incluent le Stockage Microsoft
Azure, les espaces de travail Azure Log Analytics ou Azure Event Hub. Après avoir activé
les événements d’audit de sécurité, le service de domaine Azure AD DS envoie tous les
événements audités pour la catégorie sélectionnée à la ressource ciblée.
Vous pouvez archiver les événements dans les événements de diffusion en continu et de
Stockage Microsoft Azure à un logiciel SIEM (Security Information and Event
Management) (ou équivalent) à l’aide d’Azure Event Hubs ou effectuer votre propre
analyse et utiliser des espaces de travail Log Analytics, à partir du Portail Microsoft
Azure.
Référence : Activer les audits de sécurité pour Azure services de domaine Active
Directory
Sauvegarde et récupération
Pour plus d’informations, consultez le benchmark de sécurité cloud Microsoft : Sauvegarde
et récupération.
BR-1 : Garantir des sauvegardes automatiques régulières
Fonctionnalités
Fonctionnalité de sauvegarde native du service
Description : le service prend en charge sa propre fonctionnalité de sauvegarde native

(s’il n’utilise pas Sauvegarde Azure). Plus d’informations
True True Microsoft
Remarques sur les fonctionnalités : l’utilisateur ne peut pas configurer le service, la

sauvegarde est activée par défaut et sa fréquence est déterminée par la référence SKU.

Référence : Détails de la sauvegarde et de la référence SKU pour Azure AD Domain

Services
Étapes suivantes
Consultez la vue d’ensemble du benchmark de sécurité cloud Microsoft
En savoir plus sur les bases de référence de la sécurité Azure
Joindre une machine virtuelle Windows
Server à un domaine managé Azure
l’aide d’un modèle Resource Manager
Article • 01/08/2023
Pour automatiser le déploiement et la configuration de machines virtuelles Azure, vous

pouvez utiliser un modèle Resource Manager. Ces modèles vous permettent de créer
des déploiements cohérents à chaque fois. Des extensions peuvent aussi être incluses
dans les modèles pour configurer automatiquement une machine virtuelle pendant le
déploiement. Une extension utile joint des machines virtuelles à un domaine et peut être
utilisée avec des domaines managés Azure Active Directory Domain Services (Azure AD
DS).
Cet article explique comment créer une machine virtuelle Windows Server et comment
la joindre à un domaine managé Azure AD DS à l’aide de modèles Resource Manager.
Vous allez aussi découvrir comment joindre une machine virtuelle Windows Server
existante à un domaine Azure AD DS.
Prérequis
Un compte d'utilisateur qui fait partie du groupe Administrateurs AAD DC.
Vue d’ensemble des modèles Azure Resource

Manager
Les modèles Resource Manager permettent de définir une infrastructure Azure dans du
code. Les ressources nécessaires, les connexions réseau ou la configuration des
machines virtuelles peuvent toutes être définies dans un modèle. Ces modèles vous
permettent de créer des déploiements cohérents et reproductibles à chaque fois, et une
nouvelle version peut être créée à mesure que vous y apportez des modifications. Pour
plus d’informations, consultez Vue d’ensemble des modèles Azure Resource Manager.
Chaque ressource est définie dans un modèle au format JavaScript Object Notation
(JSON). L’exemple JSON suivant utilise le type de ressource Microsoft.
Compute/virtualMachines/extensions pour installer l’extension de jonction de domaine
Active Directory. Il comporte des paramètres qui sont spécifiés au moment du
déploiement. Lorsque l’extension est déployée, la machine virtuelle est jointe au
domaine managé spécifié.
JSON
{
"apiVersion": "2015-06-15",
"type": "Microsoft.Compute/virtualMachines/extensions",
"name": "[concat(parameters('dnsLabelPrefix'),'/joindomain')]",
"dependsOn": [
"[concat('Microsoft.Compute/virtualMachines/',
parameters('dnsLabelPrefix'))]"
],
"properties": {
"publisher": "Microsoft.Compute",
"type": "JsonADDomainExtension",
"typeHandlerVersion": "1.3",
"autoUpgradeMinorVersion": true,
"settings": {
"Name": "[parameters('domainToJoin')]",
"OUPath": "[parameters('ouPath')]",
"User": "[concat(parameters('domainToJoin'), '\\',
parameters('domainUsername'))]",
"Restart": "true",
"Options": "[parameters('domainJoinOptions')]"
},
"protectedSettings": {
"Password": "[parameters('domainPassword')]"
}
}
}
Cette extension de machine virtuelle peut être déployée même si vous ne créez pas de
machine virtuelle dans le même modèle. Les exemples de cet article illustrent les deux
approches suivantes :
Créer une machine virtuelle Windows Server et la joindre à un domaine managé
Joindre une machine virtuelle Windows Server existante à un domaine managé
Créer une machine virtuelle Windows Server et

la joindre à un domaine managé
Si vous avez besoin d’une machine virtuelle Windows Server, vous pouvez en créer et
configurer une à l’aide d’un modèle Resource Manager. Lorsque la machine virtuelle est
déployée, une extension est alors installée pour joindre la machine virtuelle à un
domaine managé. Si vous disposez déjà d’une machine virtuelle et que vous voulez la
joindre à un domaine managé, passez à l’étape Joindre une machine virtuelle Windows
Server existante à un domaine managé.
Pour créer une machine virtuelle Windows Server et la joindre ensuite à un domaine
1. Accédez au modèle de démarrage rapide . Sélectionnez l’option Déployer dans

Azure.
2. Sur la page Déploiement personnalisé, entrez les informations suivantes pour

créer une machine virtuelle Windows Server et la joindre au domaine managé :
Paramètre Valeur
Abonnement Choisissez le même abonnement Azure que celui dans lequel vous avez
activé Azure AD Domain Services.
Resource group Choisissez le groupe de ressources de votre machine virtuelle.
Emplacement Sélectionnez l’emplacement de votre machine virtuelle.
Existing VNET Nom du réseau virtuel existant auquel connecter la machine virtuelle,
Name par exemple myVnet.
Existing Subnet Nom du sous-réseau du réseau virtuel existant, par exemple Workloads.
Name
DNS Label Prefix Entrez le nom DNS à utiliser pour la machine virtuelle, par exemple
myvm.
Taille de la Spécifiez une taille de machine virtuelle, par exemple Standard_DS2_v2.

machine
virtuelle
Domain To Join Nom DNS du domaine managé, par exemple aaddscontoso.com.

Paramètre Valeur
Domain Compte d’utilisateur dans le domaine managé qui doit être utilisé pour
Username joindre la machine virtuelle au domaine managé, par exemple
contosoadmin@aaddscontoso.com . Ce compte doit faire partie du domaine
managé.
Domain Mot de passe du compte d’utilisateur spécifié dans le paramètre

Password précédent.
Optional OU UO personnalisée dans laquelle ajouter la machine virtuelle. Si vous ne

Path spécifiez pas de valeur pour ce paramètre, la machine virtuelle est
ajoutée à l’unité d’organisation AAD DC Computers.
VM Admin Spécifiez le compte administrateur local à créer sur la machine virtuelle.

Username
VM Admin Spécifiez un mot de passe d’administrateur local pour la machine

Password virtuelle. Créez un mot de passe d’administrateur local fort pour être
protégé contre les attaques de mot de passe par force brute.
3. Passez en revue les conditions générales, puis cochez la case J’accepte les termes
et conditions mentionnés ci-dessus. Lorsque vous êtes prêt, sélectionnez
Purchase (Acheter) pour créer et joindre la machine virtuelle au domaine managé.
２ Avertissement
Gérez les mots de passe avec prudence. Le fichier de paramètres du modèle

demande le mot de passe d’un compte d’utilisateur faisant partie du domaine
managé. N’entrez pas manuellement de valeurs dans ce fichier et laissez-le
accessible sur les partages de fichiers ou à d’autres emplacements partagés.
Le déploiement prend quelques minutes. À l’issue de l’opération, la machine virtuelle

Windows est créée et jointe au domaine managé. La machine virtuelle peut être
managée ou connectée à l’aide de comptes de domaine.
Joindre une machine virtuelle Windows Server

existante à un domaine géré
Si vous disposez d’une machine virtuelle ou d’un groupe de machines virtuelles que
vous voulez joindre à un domaine managé, vous pouvez utiliser un modèle Resource
Manager pour ne déployer que l’extension de machine virtuelle.
Pour joindre une machine virtuelle Windows Server existante à un domaine managé,
1. Accédez au modèle de démarrage rapide . Sélectionnez l’option Déployer dans

Azure.
2. Sur la page Déploiement personnalisé, entrez les informations suivantes pour

joindre la machine virtuelle au domaine managé :
Paramètre Valeur
Abonnement Choisissez le même abonnement Azure que celui dans lequel vous avez
activé Azure AD Domain Services.
Resource group Choisissez le groupe de ressources avec votre machine virtuelle

existante.
Emplacement Sélectionnez l’emplacement de votre machine virtuelle existante.
VM list Entrez la liste séparée par des virgules des machines virtuelles existantes
à joindre au domaine managé, par exemple myVM1,myVM2.
Domain Join Compte d’utilisateur dans le domaine managé qui doit être utilisé pour
User Name joindre la machine virtuelle au domaine managé, par exemple
contosoadmin@aaddscontoso.com . Ce compte doit faire partie du domaine
managé.
Domain Join Mot de passe du compte d’utilisateur spécifié dans le paramètre

User Password précédent.
Optional OU UO personnalisée dans laquelle ajouter la machine virtuelle. Si vous ne

Path spécifiez pas de valeur pour ce paramètre, la machine virtuelle est
ajoutée à l’unité d’organisation AAD DC Computers.
3. Passez en revue les conditions générales, puis cochez la case J’accepte les termes
et conditions mentionnés ci-dessus. Lorsque vous êtes prêt, sélectionnez
Purchase (Acheter) pour joindre la machine virtuelle au domaine managé.
２ Avertissement
Gérez les mots de passe avec prudence. Le fichier de paramètres du modèle

demande le mot de passe d’un compte d’utilisateur faisant partie du domaine
managé. N’entrez pas manuellement de valeurs dans ce fichier et laissez-le
accessible sur les partages de fichiers ou à d’autres emplacements partagés.
Le déploiement prend quelques instants. Lorsque vous avez terminé, les machines
virtuelles Windows spécifiées sont jointes au domaine managé et peuvent être
managées ou connectées en utilisant des comptes du domaine.
Étapes suivantes
Dans cet article, vous avez utilisé la portail Azure pour configurer et déployer des
ressources à l’aide de modèles. Vous pouvez aussi déployer des ressources avec des
modèles Resource Manager à partir d’Azure PowerShell ou Azure CLI.
Joindre une machine virtuelle Linux
CentOS à un domaine managé par
Article • 01/06/2023
Pour permettre aux utilisateurs de se connecter à des machines virtuelles dans Azure en
utilisant un ensemble unique d’informations d’identification, vous pouvez joindre les
machines virtuelles à un domaine managé Azure Active Directory Domain Services
(Azure AD DS). Quand vous joignez une machine virtuelle à un domaine managé Azure
AD DS, les comptes d’utilisateurs et les informations d’identification du domaine
peuvent être utilisés pour se connecter aux serveurs et les gérer. Les appartenances aux
groupes du domaine managé sont également appliquées pour vous permettre de
contrôler l’accès aux fichiers ou aux services sur la machine virtuelle.
Cet article vous montre comment joindre une machine virtuelle Linux CentOS à un
domaine managé.
Prérequis
Des noms de machine virtuelle Linux uniques d’un maximum de 15 caractères pour
éviter les noms tronqués susceptibles de générer des conflits dans Active
Directory.
Créer une machine virtuelle Linux CentOS et s’y
connecter
Si vous disposez d’une machine virtuelle Linux CentOS dans Azure, connectez-vous-y en
utilisant SSH, puis passez à l’étape suivante pour commencer à configurer la machine
virtuelle.
Si vous avez besoin de créer une machine virtuelle Linux CentOS ou si vous souhaitez
créer une machine virtuelle de test dans le cadre de cet article, vous pouvez employer
l’une des méthodes suivantes :
Azure portal
Azure CLI
Azure PowerShell
Au moment de créer la machine virtuelle, faites attention aux paramètres de réseau

virtuel et veillez à ce que la machine virtuelle puisse communiquer avec le domaine
managé :
Déployez la machine virtuelle dans le réseau virtuel où vous avez activé Azure
Active Directory Domain Services ou dans un réseau virtuel appairé.
Déployez la machine virtuelle dans un sous-réseau différent de celui de votre
domaine managé.
Une fois la machine virtuelle déployée, suivez les étapes pour vous connecter à la
machine virtuelle avec SSH.
Configurer le fichier hosts

Pour que le nom d’hôte de la machine virtuelle soit correctement configuré pour le
domaine managé, modifiez le fichier /etc/hosts et définissez le nom d’hôte :
Bash
sudo vi /etc/hosts
Dans le fichier hosts, mettez à jour l’adresse localhost. Dans l’exemple suivant :
aaddscontoso.com est le nom de domaine DNS de votre domaine managé.

centos est le nom d’hôte de votre machine virtuelle CentOS que vous joignez au
domaine managé.
Mettez à jour ces noms avec vos propres valeurs :

config
127.0.0.1 centos.aaddscontoso.com centos
Quand vous avez terminé, enregistrez et quittez le fichier hosts à l’aide de la commande
:wq de l’éditeur.
Installer les packages nécessaires

La machine virtuelle a besoin de packages supplémentaires pour être jointe au domaine
managé. Pour installer et configurer ces packages, mettez à jour et installez les outils de
jonction de domaine à l’aide de yum :
Bash
sudo yum install adcli realmd sssd krb5-workstation krb5-libs oddjob oddjob-
mkhomedir samba-common-tools

managé
Maintenant que les packages nécessaires sont installés sur la machine virtuelle, joignez
celle-ci au domaine managé.
1. Utilisez la commande realm discover pour découvrir le domaine managé.

L’exemple suivant découvre le domaine AADDSCONTOSO.COM. Spécifiez votre
propre nom de domaine managé TOUT EN MAJUSCULES :
Bash
sudo realm discover AADDSCONTOSO.COM
Si la commande realm discover ne trouve pas votre domaine managé, examinez

les étapes de dépannage suivantes :
Vérifiez que le domaine est accessible à partir de la machine virtuelle. Essayez

ping aaddscontoso.com pour voir si une réponse positive est retournée.
Vérifiez que la machine virtuelle est déployée dans le réseau virtuel où le

domaine managé est disponible ou dans un réseau virtuel appairé.
Vérifiez que les paramètres de serveur DNS du réseau virtuel ont été mis à
jour pour pointer vers les contrôleurs de domaine du domaine managé.
2. À présent, initialisez Kerberos à l’aide de la commande kinit . Spécifiez un

utilisateur membre du domaine managé. Si nécessaire, ajoutez un compte
d’utilisateur à un groupe dans Azure AD.
Là encore, le nom de domaine managé doit être entré TOUT EN MAJUSCULES.

Dans l’exemple suivant, le compte nommé contosoadmin@aaddscontoso.com est
utilisé pour initialiser Kerberos. Entrez votre propre compte d’utilisateur qui fait
partie du domaine managé :
Bash
sudo kinit contosoadmin@AADDSCONTOSO.COM
3. Enfin, joignez la machine virtuelle au domaine managé à l’aide de la commande

realm join . Utilisez le même compte d’utilisateur faisant partie du domaine
managé et spécifié dans la commande précédente kinit , à savoir

contosoadmin@AADDSCONTOSO.COM :
Bash
sudo realm join --verbose AADDSCONTOSO.COM -U

'contosoadmin@AADDSCONTOSO.COM' --membership-software=adcli
La jonction de la machine virtuelle au domaine managé prend quelques instants.

L’exemple de sortie suivant montre que la machine virtuelle a bien été jointe au
domaine managé :
Sortie
Successfully enrolled machine in realm
Si votre machine virtuelle ne peut pas venir à bout du processus de jonction de

domaine, vérifiez que le groupe de sécurité réseau de la machine virtuelle autorise le
trafic Kerberos sortant sur le port TCP + UDP 464 vers le sous-réseau du réseau virtuel
de votre domaine managé.
Autoriser l’authentification par mot de passe

pour SSH
Par défaut, les utilisateurs ne peuvent se connecter à une machine virtuelle qu’avec
l’authentification par clé publique SSH. L’authentification par mot de passe échoue.
Quand vous joignez la machine virtuelle à un domaine managé, ces comptes de
domaine doivent utiliser l’authentification par mot de passe. Mettez à jour la
configuration SSH pour autoriser l’authentification par mot de passe comme suit.
1. Ouvrez le fichier sshd_conf avec un éditeur :
Bash
sudo vi /etc/ssh/sshd_config
2. Mettez à jour la ligne pour PasswordAuthentication sur yes :
Bash
PasswordAuthentication yes
Quand vous avez terminé, enregistrez et quittez le fichier sshd_conf à l’aide de la

commande :wq de l’éditeur.
3. Pour appliquer les modifications et permettre aux utilisateurs de se connecter à

l’aide d’un mot de passe, redémarrez le service SSH :
Bash
sudo systemctl restart sshd
Accorder les privilèges sudo au groupe «

Administrateurs du contrôleur de domaine
AAD »
Pour accorder des privilèges d’administration aux membres du groupe Administrateurs
du contrôleur de domaine AAD sur la machine virtuelle CentOS, ajoutez une entrée au
fichier /etc/sudoers. Une fois ajoutés, les membres du groupe Administrateurs du
contrôleur de domaine AAD peuvent utiliser la commande sudo sur la machine virtuelle
CentOS.
1. Ouvrez le fichier sudoers pour le modifier :
Bash
sudo visudo
2. Ajoutez l’entrée suivante à la fin du fichier /etc/sudoers. Étant donné que le nom de
groupe Administrateurs du contrôleur de domaine AAD contient un espace, incluez-
y une barre oblique inverse en guise de caractère d’échappement. Ajoutez votre
propre nom de domaine, par exemple aaddscontoso.com :
config
# Add 'AAD DC Administrators' group members as admins.
%AAD\ DC\ Administrators@aaddscontoso.com ALL=(ALL) NOPASSWD:ALL
Quand vous avez terminé, enregistrez et quittez l’éditeur à l’aide de la commande

Se connecter à la machine virtuelle à l’aide d’un

compte de domaine
Pour vérifier que la machine virtuelle a bien été jointe au domaine managé, démarrez
une nouvelle connexion SSH en utilisant un compte d’utilisateur du domaine. Vérifiez
qu’un répertoire de base a été créé et que l’appartenance au groupe du domaine est
appliquée.
1. Créez une connexion SSH à partir de votre console. Utilisez un compte de domaine
qui appartient au domaine managé en utilisant la commande ssh -l , comme
contosoadmin@aaddscontoso.com , puis entrez l’adresse de votre machine virtuelle,
par exemple centos.aaddscontoso.com. Si vous utilisez Azure Cloud Shell, utilisez
l’adresse IP publique de la machine virtuelle plutôt que le nom DNS interne.
Bash
sudo ssh -l contosoadmin@AADDSCONTOSO.com centos.aaddscontoso.com
2. Une fois connecté à la machine virtuelle, vérifiez que le répertoire de base a bien
été initialisé :
Bash
sudo pwd
Vous devez vous trouver dans le répertoire de base /home et votre propre
répertoire doit correspondre au compte d’utilisateur.
3. Vérifiez maintenant que les appartenances aux groupes sont correctement

résolues :
Bash
sudo id
Vos appartenances aux groupes du domaine managé doivent s’afficher.
4. Si vous vous êtes connecté à la machine virtuelle en tant que membre du groupe
Administrateurs AAD DC, vérifiez que vous pouvez bien utiliser la commande
sudo :
Bash
sudo yum update
Étapes suivantes
Si vous avez des difficultés à connecter la machine virtuelle au domaine managé ou à
vous connecter avec un compte de domaine, consultez Résoudre les problèmes de
jonction à un domaine.
Joindre une machine virtuelle CoreOs à
un domaine managé par Azure
Article • 01/06/2023
Cet article vous montre comment joindre une machine virtuelle CoreOS à un domaine
managé.
Prérequis
Directory.
Créer une machine virtuelle CoreOS et s’y
connecter
Si vous disposez d’une machine virtuelle Linux CoreOS dans Azure, connectez-vous-y en
virtuelle.
Si vous avez besoin de créer une machine virtuelle Linux CoreOS ou si vous souhaitez
Azure portal
Azure CLI
Azure PowerShell

managé :
instance Azure Active Directory Domain Services.

Console
sudo vi /etc/hosts

coreos est le nom d’hôte de votre machine virtuelle CoreOS que vous joignez au
domaine managé.

Console
127.0.0.1 coreos coreos.aaddscontoso.com
Configurer le service SSSD

Mettez à jour la configuration SSSD /etc/sssd/sssd.conf.
Console
sudo vi /etc/sssd/sssd.conf
Spécifiez votre propre nom de domaine managé pour les paramètres suivants :
domains TOUT EN MAJUSCULES

[domain/AADDSCONTOSO] où AADDSCONTOSO est TOUT EN MAJUSCULES
ldap_uri
ldap_search_base
krb5_server
krb5_realm TOUT EN MAJUSCULES
Console
[sssd]
config_file_version = 2
services = nss, pam
domains = AADDSCONTOSO.COM
[domain/AADDSCONTOSO]
id_provider = ad
auth_provider = ad
chpass_provider = ad
ldap_uri = ldap://aaddscontoso.com
ldap_search_base = dc=aaddscontoso,dc=com
ldap_schema = rfc2307bis
ldap_sasl_mech = GSSAPI
ldap_user_object_class = user
ldap_group_object_class = group
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_account_expire_policy = ad
ldap_force_upper_case_realm = true
fallback_homedir = /home/%d/%u
krb5_server = aaddscontoso.com
krb5_realm = AADDSCONTOSO.COM

managé
Une fois le fichier de configuration SSSD mis à jour, joignez la machine virtuelle au
domaine managé.
1. Dans un premier temps, utilisez la commande adcli info pour vérifier que vous
pouvez afficher les informations sur le domaine managé. L’exemple suivant
recueille des informations pour le domaine AADDSCONTOSO.COM. Spécifiez votre
Console
sudo adcli info AADDSCONTOSO.COM
Si la commande adcli info ne trouve pas votre domaine managé, examinez les
étapes de dépannage suivantes :


2. Joignez à présent la machine virtuelle au domaine managé à l’aide de la

commande adcli join . Spécifiez un utilisateur membre du domaine managé. Si
nécessaire, ajoutez un compte d’utilisateur à un groupe dans Azure AD.

partie du domaine managé.
Console
sudo adcli join -D AADDSCONTOSO.COM -U contosoadmin@AADDSCONTOSO.COM -K

/etc/krb5.keytab -H coreos.aaddscontoso.com -N coreos
La commande adcli join ne retourne pas d’informations dans le cas où la

jonction de la machine virtuelle au domaine managé a abouti.
3. Pour appliquer la configuration de jonction de domaine, démarrez le service SSSD :
Console
sudo systemctl start sssd.service

compte de domaine
appliquée.
par exemple coreos.aaddscontoso.com. Si vous utilisez Azure Cloud Shell, utilisez

Console
ssh -l contosoadmin@AADDSCONTOSO.com coreos.aaddscontoso.com

résolues :
Console
id
Étapes suivantes
Joindre une machine virtuelle
Red Hat Enterprise Linux à un domaine
managé par Azure Active Directory
Domain Services
Article • 10/04/2023
Cet article montre comment joindre une machine virtuelle Red Hat Enterprise Linux
(RHEL) à un domaine managé.
Prérequis
Directory.
Créer une machine virtuelle Linux RHEL et s’y
connecter
Si vous disposez d’une machine virtuelle Linux RHEL dans Azure, connectez-vous-y en
virtuelle.
Si vous avez besoin de créer une machine virtuelle Linux RHEL ou si vous souhaitez créer
une machine virtuelle de test dans le cadre de cet article, vous pouvez employer l’une
Azure portal
Azure CLI
Azure PowerShell

managé :

Bash
sudo vi /etc/hosts

rhel est le nom d’hôte de votre machine virtuelle RHEL que vous joignez au
domaine managé.

config
127.0.0.1 rhel rhel.aaddscontoso.com
RHEL 6
） Important
Tenez compte que Red Hat Enterprise Linux 6.X et Oracle Linux 6.x sont déjà
EOL.
RHEL 6.10 dispose d’un support ELS disponible, qui prendra fin en juin
2024 .

La machine virtuelle a besoin de packages supplémentaires pour être jointe au
domaine managé. Pour installer et configurer ces packages, mettez à jour et
installez les outils de jonction de domaine à l’aide de yum .
Bash
sudo yum install adcli sssd authconfig krb5-workstation

managé
Maintenant que les packages nécessaires sont installés sur la machine virtuelle,
joignez celle-ci au domaine managé.
1. Utilisez la commande adcli info pour découvrir le domaine managé.

L’exemple suivant découvre le domaine ADDDSCONTOSO.COM. Spécifiez
votre propre nom de domaine managé TOUT EN MAJUSCULES :
Bash
sudo adcli info aaddscontoso.com
Si la commande adcli info ne trouve pas votre domaine managé, examinez

Vérifiez que le domaine est accessible à partir de la machine virtuelle.

Essayez ping aaddscontoso.com pour voir si une réponse positive est
retournée.
Vérifiez que les paramètres de serveur DNS du réseau virtuel ont été mis
à jour pour pointer vers les contrôleurs de domaine du domaine
managé.
2. Commencez par joindre le domaine à l’aide de la commande adcli join .

Cette commande crée également le fichier Keytab pour l’authentification de la
machine. Utilisez un compte d’utilisateur membre du domaine managé.
Bash
sudo adcli join aaddscontoso.com -U contosoadmin
3. Configurez maintenant le fichier /ect/krb5.conf , et créez les fichiers

/etc/sssd/sssd.conf pour utiliser le domaine Active Directory
aaddscontoso.com .
Veillez à ce que AADDSCONTOSO.COM soit remplacé par votre
propre nom de domaine :
Ouvrez le fichier /etc/krb5.conf dans un éditeur :
Bash
sudo vi /etc/krb5.conf
Mettez à jour le fichier krb5.conf pour qu’il corresponde à l’exemple suivant :
config
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = AADDSCONTOSO.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
AADDSCONTOSO.COM = {
kdc = AADDSCONTOSO.COM
admin_server = AADDSCONTOSO.COM
[domain_realm]
.AADDSCONTOSO.COM = AADDSCONTOSO.COM
AADDSCONTOSO.COM = AADDSCONTOSO.COM
Créer le fichier /etc/sssd/sssd.conf :
Bash
Mettez à jour le fichier sssd.conf pour qu’il corresponde à l’exemple suivant :
config
[sssd]
services = nss, pam, ssh, autofs

domains = AADDSCONTOSO.COM
[domain/AADDSCONTOSO.COM]
id_provider = ad
4. Assurez-vous que les autorisations /etc/sssd/sssd.conf correspondent à 600

et qu'elles appartiennent à l'utilisateur racine :
Bash
sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf
5. Utilisez authconfig pour informer la machine virtuelle de l’intégration AD

Linux :
Bash
sudo authconfig --enablesssd --enablesssd auth --update
6. Démarrez et activez le service sssd :
Bash
sudo service sssd start
sudo chkconfig sssd on
Si votre machine virtuelle ne peut pas venir à bout du processus de jonction de

domaine, vérifiez que le groupe de sécurité réseau de la machine virtuelle autorise
le trafic Kerberos sortant sur le port TCP + UDP 464 vers le sous-réseau du réseau
virtuel de votre domaine managé.
Vérifiez maintenant que vous pouvez interroger les informations AD de l'utilisateur

via getent .
Bash
sudo getent passwd contosoadmin

pour SSH
Bash
config
Quand vous avez terminé, enregistrez et quittez le fichier sshd_conf à l’aide de

la commande :wq de l’éditeur.
3. Pour appliquer les changements et permettre aux utilisateurs de se connecter
avec un mot de passe, redémarrez le service SSH pour votre version de
distribution de RHEL :
Bash
sudo service sshd restart

AAD »
Pour accorder des privilèges d’administration aux membres du groupe AAD DC
Administrators sur la machine virtuelle RHEL, ajoutez une entrée au fichier /etc/sudoers.
Une fois ajoutés, les membres du groupe AAD DC Administrators peuvent utiliser la
commande sudo sur la machine virtuelle RHEL.
Bash
sudo visudo
config


compte de domaine
appliquée.
par exemple rhel.aaddscontoso.com. Si vous utilisez Azure Cloud Shell, utilisez
Bash
sudo ssh -l contosoadmin@AADDSCONTOSO.com rhel.aaddscontoso.com
été initialisé :
Bash
sudo pwd

résolues :
Bash
sudo id
sudo :
Bash
sudo yum update
Étapes suivantes
Joindre une machine virtuelle Ubuntu
Linux à un domaine managé par Azure
Cet article vous montre comment joindre une machine virtuelle Ubuntu Linux à un
domaine managé.
Prérequis
Un compte d’utilisateur membre du domaine managé. Vérifiez que l’attribut
SAMAccountName de l’utilisateur n’est pas généré automatiquement. Si plusieurs
comptes d’utilisateur du locataire Azure AD ont le même attribut mailNickname,
l’attribut SAMAccountName de chaque utilisateur est généré automatiquement.
Pour plus d’informations, consultez Comment les objets et les informations
d’identification sont synchronisés dans un domaine managé Azure Active Directory
Domain Services.
Directory.
Créer une machine virtuelle Ubuntu Linux et s’y

connecter
Si vous disposez d’une machine virtuelle Ubuntu Linux dans Azure, connectez-vous-y en
virtuelle.
Si vous avez besoin de créer une machine virtuelle Ubuntu Linux ou si vous souhaitez
Azure portal
Azure CLI
Azure PowerShell

managé :

Bash
sudo vi /etc/hosts
ubuntu est le nom d’hôte de votre machine virtuelle Ubuntu que vous joignez au
domaine managé.
config
127.0.0.1 ubuntu.aaddscontoso.com ubuntu

La machine virtuelle a besoin de packages supplémentaires pour être jointe au domaine
managé. Pour installer et configurer ces packages, mettez à jour et installez les outils de
jonction de domaine à l’aide de apt-get
Pendant l’installation de Kerberos, le package Krb5-user demande le nom de domaine

TOUT EN MAJUSCULES. Par exemple, si le nom de votre domaine managé est
aaddscontoso.com, entrez AADDSCONTOSO.COM en guise de domaine. L’installation
écrit les sections [realm] et [domain_realm] dans le fichier de configuration
/etc/krb5.conf. Veillez à spécifier le domaine TOUT EN MAJUSCULES :
Bash
sudo apt-get update
sudo apt-get install krb5-user samba sssd sssd-tools libnss-sss libpam-sss

ntp ntpdate realmd adcli
Configurer le protocole NTP (Network Time

Protocol)
Pour que la communication fonctionne correctement dans le domaine, la date et l’heure
de votre machine virtuelle Ubuntu doit être synchronisée avec celle du domaine
managé. Ajoutez le nom d’hôte NTP de votre domaine managé au fichier /etc/ntp.conf.
1. Ouvrez le fichier ntp.conf avec un éditeur :
Bash
sudo vi /etc/ntp.conf
2. Dans le fichier ntp.conf, créez une ligne pour ajouter le nom DNS de votre domaine
managé. Dans l’exemple suivant, une entrée est ajoutée pour aaddscontoso.com.
Utilisez votre propre nom DNS :
config
server aaddscontoso.com
Quand vous avez terminé, enregistrez et quittez le fichier ntp.conf à l’aide de la

3. Pour assurer la synchronisation de la machine virtuelle avec le domaine managé,

les étapes suivantes sont nécessaires :
Arrêter le serveur NTP

Mettre à jour la date et l’heure à partir du domaine managé
Démarrer le service NTP
Exécutez les commandes suivantes pour effectuer ces étapes. Utilisez votre propre
nom DNS avec la commande ntpdate :
Bash
sudo systemctl stop ntp
sudo ntpdate aaddscontoso.com
sudo systemctl start ntp

managé
Maintenant que les packages nécessaires sont installés sur la machine virtuelle et que
NTP est configuré, joignez la machine virtuelle au domaine managé.
1. Utilisez la commande realm discover pour découvrir le domaine managé.

L’exemple suivant découvre le domaine AADDSCONTOSO.COM. Spécifiez votre
Bash
sudo realm discover AADDSCONTOSO.COM
Si la commande realm discover ne trouve pas votre domaine managé, examinez


2. À présent, initialisez Kerberos à l’aide de la commande kinit . Spécifiez un

utilisateur membre du domaine managé. Si nécessaire, ajoutez un compte
d’utilisateur à un groupe dans Azure AD.

partie du domaine managé :
Bash
sudo kinit -V contosoadmin@AADDSCONTOSO.COM
3. Enfin, joignez la machine virtuelle au domaine managé à l’aide de la commande

realm join . Utilisez le même compte d’utilisateur faisant partie du domaine
managé et spécifié dans la commande précédente kinit , à savoir

contosoadmin@AADDSCONTOSO.COM :
Bash
sudo realm join --verbose AADDSCONTOSO.COM -U

'contosoadmin@AADDSCONTOSO.COM' --install=/
La jonction de la machine virtuelle au domaine managé prend quelques instants.

L’exemple de sortie suivant montre que la machine virtuelle a bien été jointe au
domaine managé :
Sortie
Successfully enrolled machine in realm
Si votre machine virtuelle ne peut pas accomplir le processus de jonction de domaine,

vérifiez que le groupe de sécurité réseau de la machine virtuelle autorise le trafic
Kerberos sortant sur le port TCP + UDP 464 vers le sous-réseau de réseau virtuel de
votre domaine managé.
Si vous avez reçu l’erreur Échec GSS non spécifié. Du code mineur peut fournir plus
d’informations (serveur introuvable dans la base de données Kerberos), ouvrez le fichier
/etc/krb5.conf et ajoutez le code suivant dans la section [libdefaults] , puis réessayez :
config
rdns=false
Mettre à jour la configuration SSSD

L’un des packages installés à une étape précédente était destiné à SSSD (System
Security Services Daemon). Quand un utilisateur tente de se connecter à une machine
virtuelle à l’aide d’informations d’identification de domaine, SSSD relaie la demande à
un fournisseur d’authentification. Dans ce scénario, SSSD utilise Azure AD DS pour
authentifier la demande.
1. Ouvrez le fichier sshd.conf avec un éditeur :
Bash
2. Commentez la ligne pour use_fully_qualified_names comme ceci :
config
# use_fully_qualified_names = True
Quand vous avez terminé, enregistrez et quittez le fichier sshd.conf à l’aide de la

3. Pour appliquer la modification, redémarrez le service SSSD :
Bash
sudo systemctl restart sssd
Configurer les paramètres de groupe et de

compte d’utilisateur
Une fois la machine virtuelle jointe au domaine managé et configurée pour
l’authentification, il reste quelques options de configuration utilisateur à définir. Parmi
ces changements de configuration figurent l’autorisation de l’authentification par mot
de passe et la création automatique de répertoires de base sur la machine virtuelle
locale quand les utilisateurs du domaine se connectent pour la première fois.
Autoriser l’authentification par mot de passe pour SSH

Bash
config


Bash
sudo systemctl restart ssh
Configurer la création automatique du répertoire de base

Pour activer la création automatique du répertoire de base quand un utilisateur se
connecte pour la première fois, procédez comme suit :
1. Ouvrez le fichier /etc/pam.d/common-session dans un éditeur :
Bash
sudo vi /etc/pam.d/common-session
2. Ajoutez la ligne suivante dans ce fichier en dessous de la ligne session optional

pam_sss.so :
config
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
Quand vous avez terminé, enregistrez et quittez le fichier common-session à l’aide

de la commande :wq de l’éditeur.
Accorder les privilèges sudo au groupe « Administrateurs

du contrôleur de domaine AAD »
Pour accorder des privilèges d’administration aux membres du groupe Administrateurs
AAD DC sur la machine virtuelle Ubuntu, ajoutez une entrée au fichier /etc/sudoers. Une
fois ajoutés, les membres du groupe Administrateurs AAD DC peuvent utiliser la
commande sudo sur la machine virtuelle Ubuntu.
Bash
sudo visudo
2. Ajoutez l’entrée suivante à la fin du fichier /etc/sudoers :
config
%AAD\ DC\ Administrators ALL=(ALL) NOPASSWD:ALL

Ctrl-X .
compte de domaine
appliquée.
qui appartient au domaine managé à l’aide de la commande ssh -l , par exemple
par exemple ubuntu.aaddscontoso.com. Si vous utilisez Azure Cloud Shell, utilisez
Bash
sudo ssh -l contosoadmin@AADDSCONTOSO.com ubuntu.aaddscontoso.com
été initialisé :
Bash
sudo pwd

résolues :
Bash
sudo id
sudo :
Bash
sudo apt-get update
Étapes suivantes
Joindre une machine virtuelle SUSE
Linux Enterprise à un domaine managé
par Azure Active Directory
Domain Services
Cet article montre comment joindre une machine virtuelle SUSE Linux Enterprise (SLE) à
un domaine managé.
Prérequis
Directory.
Créer une machine virtuelle Linux SLE et s’y
connecter
Si vous disposez d’une machine virtuelle Linux SLE dans Azure, connectez-vous-y en
virtuelle.
Si vous avez besoin de créer une machine virtuelle Linux SLE ou si vous souhaitez créer
une machine virtuelle de test dans le cadre de cet article, vous pouvez employer l’une
Azure portal
Azure CLI
Azure PowerShell

managé :

Bash
sudo vi /etc/hosts

linux-q2gr est le nom d’hôte de votre machine virtuelle SLE que vous joignez au
domaine managé.

config
127.0.0.1 linux-q2gr linux-q2gr.aaddscontoso.com

managé en utilisant SSSD
Pour joindre le domaine managé à l’aide de SSSD et du module User Logon
Management de YaST, procédez comme suit :
1. Installez le module YaST User Logon Management :
Bash
sudo zypper install yast2-auth-client
2. Ouvrez YaST.
3. Pour utiliser la découverte automatique DNS ultérieurement, configurez les

adresses IP de domaine managé (Active Directory server) en tant que serveur de
nom pour votre client.
Dans YaST, sélectionnez System > Network Settings.
4. Sélectionnez l’onglet Hostname/DNS, puis entrez la ou les adresses IP du domaine

managé dans la zone de texte Name Server 1. Ces adresses IP sont affichées dans
la fenêtre Propriétés du portail Azure pour votre domaine managé, par exemple
10.0.2.4 et 10.0.2.5.
Ajoutez vos propres adresses IP de domaine managé, puis sélectionnez OK.
5. Dans la fenêtre principale de YaST, choisissez Network Services>User Logon

Management.
Le module s’ouvre avec une vue d’ensemble montrant les différentes propriétés
réseau de votre ordinateur et la méthode d’authentification actuellement utilisée,
comme le montre l’exemple de capture d’écran suivant :
Pour commencer la modification, sélectionnez Change Settings.
Pour joindre une machine virtuelle à un domaine managé, procédez comme suit :
1. Dans la boîte de dialogue, sélectionnez Add Domain.
2. Spécifiez le nom de domaine (Domain name) correct, par exemple

aaddscontoso.com, puis spécifiez les services à utiliser pour les données d’identité
et l’authentification. Sélectionnez Microsoft Active Directory pour les deux.
Assurez-vous que l’option Enable the domain est sélectionnée.
3. Lorsque vous êtes prêt, sélectionnez OK.
4. Acceptez les paramètres par défaut dans la boîte de dialogue suivante, puis
sélectionnez OK.
5. La machine virtuelle installe des logiciels supplémentaires le cas échéant, puis

vérifie si le domaine managé est disponible.
Si tout est correct, la boîte de dialogue suivante s’affiche pour indiquer que la
machine virtuelle a découvert le domaine managé, mais que vous n’êtes pas
encore inscrit (Not yet enrolled).
6. Dans la boîte de dialogue, spécifiez le nom d’utilisateur (Username) et le mot de
passe (Password) d’un utilisateur qui fait partie du domaine managé. Si nécessaire,
ajoutez un compte d’utilisateur à un groupe dans Azure AD.
Pour vous assurer que le domaine actuel est activé pour Samba, activez l’option
Overwrite Samba configuration to work with this AD.
7. Pour vous inscrire, sélectionnez OK.
8. Un message s’affiche pour confirmer que vous êtes correctement inscrit. Pour
terminer, sélectionnez OK.
Une fois la machine virtuelle inscrite dans le domaine managé, configurez le client en
utilisant Manage Domain User Logon, comme illustré dans la capture d’écran suivante :
1. Pour autoriser les connexions à l’aide des données fournies par le domaine
managé, cochez la case de l’option Allow Domain User Logon.
2. Si vous le souhaitez, sous Enable domain data source, cochez les sources de
données supplémentaires nécessaires pour votre environnement. Ces options
incluent les utilisateurs autorisés à utiliser sudo ou les lecteurs réseau disponibles.
3. Pour permettre aux utilisateurs du domaine managé d’avoir des répertoires de

base sur la machine virtuelle, cochez la case de l’option Create Home Directories.
4. Dans la barre latérale, sélectionnez Service Options › Nom à changer, puis

Extended Options. Dans cette fenêtre, sélectionnez fallback_homedir ou
override_homedir, puis sélectionnez Add.
5. Spécifiez une valeur pour l’emplacement du répertoire de base. Pour que les
répertoires de base respectent le format /home/USER_NAME, utilisez /home/%u.
Pour plus d’informations sur les variables possibles, consultez la page man
sssd.conf ( man 5 sssd.conf ), section override_homedir.
6. Sélectionnez OK.
7. Pour enregistrer les modifications, sélectionnez OK. Vérifiez ensuite que les valeurs
affichées sont désormais correctes. Pour quitter la boîte de dialogue, sélectionnez
Cancel.
8. Si vous avez l’intention d’exécuter simultanément SSSD et Winbind (par exemple,
lors de la jointure via SSSD, mais en exécutant un serveur de fichiers Samba),
l’option Samba kerberos method doit être définie sur secrets and keytab dans
smb.conf. L’option SSSD ad_update_samba_machine_account_password doit
également être définie sur true dans sssd.conf. Ces options empêchent le keytab
système de se désynchroniser.

managé en utilisant Winbind
Pour joindre le domaine managé à l’aide de Winbind et du module Windows Domain
Membership de YaST, procédez comme suit :
1. Dans YaST, sélectionnez Network Services > Windows Domain Membership.
2. Entrez le domaine à joindre dans Domain or Workgroup dans l’écran Windows

Domain Membership. Entrez le nom de domaine managé, par exemple
aaddscontoso.com.
3. Afin d’utiliser la source SMB pour l’authentification Linux, activez l’option Use SMB
Information for Linux Authentication.
4. Pour créer automatiquement un répertoire de base local pour les utilisateurs de
domaine managé sur la machine virtuelle, activez l’option Create Home Directory
on Login.
5. Activez l’option Offline Authentication pour permettre aux utilisateurs du domaine

de se connecter même si le domaine managé est temporairement indisponible.
6. Si vous souhaitez modifier les plages UID et GID pour les utilisateurs et groupes
Samba, sélectionnez Expert Settings.
7. Configurez la synchronisation de l’heure NTP (Network Time Protocol) pour votre

domaine managé en sélectionnant NTP Configuration. Entrez les adresses IP du
domaine managé. Ces adresses IP sont affichées dans la fenêtre Propriétés du
portail Azure pour votre domaine managé, par exemple 10.0.2.4 et 10.0.2.5.
8. Sélectionnez OK et confirmez la jonction de domaine lorsque vous y êtes invité.
9. Indiquez le mot de passe d’un administrateur du domaine managé, puis

sélectionnez OK.
Une fois que vous avez joint le domaine managé, vous pouvez vous y connecter à partir
de votre station de travail à l’aide du gestionnaire d’affichage de votre bureau ou de la
console.

managé à l’aide de Winbind à partir de
l’interface de ligne de commande YaST
Pour joindre le domaine managé à l’aide de winbind et de l’interface de ligne de
commande YaST :
Joindre le domaine :
Bash
sudo yast samba-client joindomain domain=aaddscontoso.com user=<admin>

password=<admin password> machine=<(optional) machine account>

managé à l’aide de Winbind à partir du
terminal
Pour joindre le domaine managé à l’aide de Winbind et de l’interface de ligne de
commande samba net :
1. Installez le client Kerberos et samba-winbind :
Bash
sudo zypper in krb5-client samba-winbind
2. Modifiez les fichiers de configuration :
/etc/samba/smb.conf
config
[global]
workgroup = AADDSCONTOSO
usershare allow guests = NO #disallow guests from sharing
idmap config * : backend = tdb
idmap config * : range = 1000000-1999999
idmap config AADDSCONTOSO : backend = rid
idmap config AADDSCONTOSO : range = 5000000-5999999
kerberos method = secrets and keytab
realm = AADDSCONTOSO.COM
security = ADS
template homedir = /home/%D/%U
template shell = /bin/bash
winbind offline logon = yes
winbind refresh tickets = yes
/etc/krb5.conf
config
[libdefaults]
default_realm = AADDSCONTOSO.COM
clockskew = 300
[realms]
AADDSCONTOSO.COM = {
kdc = PDC.AADDSCONTOSO.COM
default_domain = AADDSCONTOSO.COM
admin_server = PDC.AADDSCONTOSO.COM
[domain_realm]
.aaddscontoso.com = AADDSCONTOSO.COM
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 1
/etc/security/pam_winbind.conf
config
[global]
cached_login = yes
krb5_auth = yes
krb5_ccache_type = FILE
warn_pwd_expire = 14
/etc/nsswitch.conf
config
passwd: compat winbind
group: compat winbind
3. Vérifiez que la date et l’heure dans Azure AD et Linux sont synchronisées. Pour ce
faire, vous pouvez ajouter le serveur Azure AD au service NTP :
a. Ajoutez la ligne suivante à /etc/ntp.conf :
config
server aaddscontoso.com
b. Redémarrez le service NTP :
Bash
sudo systemctl restart ntpd
4. Joignez le domaine :
Bash
sudo net ads join -U Administrator%Mypassword
5. Activez winbind comme source de connexion dans les modules PAM (Pluggable
Authentication Modules) Linux :
Bash
config pam-config --add --winbind
6. Activez la création automatique des répertoires de démarrage afin que les

utilisateurs puissent se connecter :
Bash
sudo pam-config -a --mkhomedir
7. Démarrez et activez le service Winbind :
Bash
sudo systemctl enable winbind
sudo systemctl start winbind

pour SSH
Bash
config


Bash
sudo systemctl restart sshd

AAD »
Pour accorder des privilèges administratifs aux membres du groupe AAD DC
Administrators sur la machine virtuelle SLE, ajoutez une entrée au fichier /etc/sudoers.
Une fois ajoutés, les membres du groupe AAD DC Administrators peuvent utiliser la
commande sudo sur la machine virtuelle SLE.
Bash
sudo visudo
config


compte de domaine
appliquée.
qui appartient au domaine managé à l’aide de la commande ssh -l , par exemple
par exemple linux-q2gr.aaddscontoso.com. Si vous utilisez Azure Cloud Shell,
utilisez l’adresse IP publique de la machine virtuelle plutôt que le nom DNS
interne.
Bash
sudo ssh -l contosoadmin@AADDSCONTOSO.com linux-q2gr.aaddscontoso.com
été initialisé :
Bash
sudo pwd

résolues :
Bash
sudo id
sudo :
Bash
sudo zypper update
Étapes suivantes
Authentification Active Directory pour
des machines virtuelles Linux non
jointes à un domaine
Article • 12/04/2023
Actuellement, la distribution Linux peut fonctionner en tant que membre des domaines
Active Directory, ce qui leur donne accès au système d’authentification AD. Pour tirer
parti de l’authentification AD dans certains cas, nous pouvons éviter la jonction AD. Pour
permettre aux utilisateurs de se connecter à une machine virtuelle Linux Azure avec un
compte Active Directory, vous avez différents choix. Une possibilité est de joindre la
machine virtuelle dans Active Directory. Une autre possibilité consiste à baser le flux
d’authentification via LDAP vers votre annuaire Active Directory sans joindre la machine
virtuelle sur AD. Cet article explique comment vous authentifier avec les informations
d’identification AD sur votre système Linux (CentosOS) basé sur LDAP.
Prérequis
Pour terminer le flux d’authentification, nous supposons que vous avez déjà :
Une instance Active Directory Domain Services déjà configurée.

Une machine virtuelle Linux (pour les tests, nous utilisons une machine basée sur
CentosOS).
Une infrastructure réseau qui autorise la communication entre Active Directory et
la machine virtuelle Linux.
Un compte d’utilisateur dédié pour lire des objets AD.
La machine virtuelle Linux doit disposer des packages suivants :
sssd
sssd-tools
sssd-ldap
openldap-clients
Un certificat LDAPS correctement configuré sur la machine virtuelle Linux.
Un certificat d’autorité de certification correctement importé dans le magasin de
certificats de la machine virtuelle Linux (le chemin varie en fonction de la
distribution Linux).
Configuration utilisateur Active Directory

Pour lire les utilisateurs dans Active Directory Domain Services, créez un ReadOnlyUser
dans AD. Pour créer un utilisateur, procédez comme suit :
1. Connectez-vous à votre contrôleur de domaine.

2. Cliquez sur Démarrer, puis sur Outils d’administration, puis cliquez sur Utilisateurs
et ordinateurs Active Directory pour démarrer la console Utilisateurs et ordinateurs
Active Directory.
3. Cliquez sur le nom de domaine que vous avez créé, puis développez son contenu.
4. Cliquez avec le bouton droit sur Utilisateurs, pointez sur Nouveau, puis cliquez sur
Utilisateur.
5. Tapez le prénom, le nom et le nom de connexion du nouvel utilisateur, puis cliquez
sur Suivant. Dans l’environnement lab, nous avons utilisé un utilisateur appelé
ReadOnlyUser.
6. Tapez un nouveau mot de passe, confirmez le mot de passe, puis cliquez pour
sélectionner l’une des cases à cocher suivantes si nécessaire :
Les utilisateurs doivent modifier le mot de passe à l’ouverture de session

suivante (recommandé pour la plupart des utilisateurs)
L’utilisateur ne peut pas changer de mot de passe
Le mot de passe n’expire jamais
Le compte est désactivé (si vous désactivez le compte, l’authentification
échoue)
7. Cliquez sur Suivant.
Passez en revue les informations que vous avez fournies et, si tout est correct, cliquez
sur Terminer.
７ Notes
L’environnement lab est basé sur :
Windows Server 2016, niveau fonctionnel de domaine et forêt.

Client Linux Centos 8.5.
Configuration de machines virtuelles Linux
７ Notes
Vous devez exécuter ces commandes avec l’autorisation sudo

Sur votre machine virtuelle Linux, installez les packages suivants : sssd sssd-tools sssd-
ldap openldap-client :
Bash
sudo dnf install -y sssd sssd-tools sssd-ldap openldap-clients
Après l’installation, vérifiez si la recherche LDAP fonctionne. Pour le vérifier, essayez une
recherche LDAP en suivant l’exemple ci-dessous :
Bash
sudo ldapsearch -H ldaps://contoso.com -x \
-D CN=ReadOnlyUser,CN=Users,DC=contoso,DC=com -w
Read0nlyuserpassword \
-b CN=Users,DC=contoso,DC=com
Si la requête LDAP fonctionne correctement, vous obtiendrez une sortie avec des
informations comme suit :
config
extended LDIF
LDAPv3
base <CN=Users,DC=contoso,DC=com> with scope subtree
filter: (objectclass=*)
requesting: ALL
Users, contoso.com
dn: CN=Users,DC=contoso,DC=com
objectClass: top
objectClass: container
cn: Users
description: Default container for upgraded user accounts
distinguishedName: CN=Users,DC=contoso,DC=com
instanceType: 4
whenCreated: 20220913115340.0Z
whenChanged: 20220913115340.0Z
uSNCreated: 5660
uSNChanged: 5660
showInAdvancedViewOnly: FALSE
name: Users
objectGUID:: i9MABLytKUurB2uTe/dOzg==
systemFlags: -1946157056
objectCategory: CN=Container,CN=Schema,CN=Configuration,DC=contoso,DC=com
isCriticalSystemObject: TRUE
dSCorePropagationData: 20220930113600.0Z
７ Notes
Si vous voyez une erreur, exécutez la commande suivante :
sudo ldapsearch -H ldaps://contoso.com -x
-D CN=ReadOnlyUser,CN=Users,DC=contoso,DC=com -w Read0nlyuserpassword
-b CN=Users,DC=contoso,DC=com -d 3
Résolvez les problèmes en fonction de la sortie.
Créer un fichier sssd.conf

Créez /etc/sssd/sssd.conf avec un contenu comme le suivant. N’oubliez pas de mettre à
jour les valeurs de ldap_uri, ldap_search_base et les ldap_default_bind_dn.
Commande pour la création de fichiers :
Bash
Exemple de sssd.conf :
config
[sssd]
domains = default
services = nss, pam
full_name_format = %1$s
[nss]
[pam]
[domain/default]
id_provider = ldap
cache_credentials = True
ldap_uri = ldaps://contoso.com
ldap_search_base = CN=Users,DC=contoso,DC=com
ldap_schema = AD
ldap_default_bind_dn = CN=ReadOnlyUser,CN=Users,DC=contoso,DC=com
ldap_default_authtok_type = obfuscated_password
ldap_default_authtok = generated_password
# Obtain the CA root certificate for your LDAPS connection.
ldap_tls_cacert = /etc/pki/tls/cacerts.pem
# This setting disables cert verification.
#ldap_tls_reqcert = allow
# Only if the LDAP directory doesn't provide uidNumber and gidNumber

attributes
ldap_id_mapping = True
# Consider setting enumerate=False for very large directories
enumerate = True
# Only needed if LDAP doesn't provide homeDirectory and loginShell

attributes
fallback_homedir = /home/%u
default_shell = /bin/bash
access_provider = permit
sudo_provider = ldap
auth_provider = ldap
autofs_provider = ldap
resolver_provider = ldap
Enregistrez le fichier avec la commande ESC + wq!.
７ Notes
Si vous n’avez pas de certificat TLS valide sous /etc/pki/tls/ appelé cacerts.pem, la
liaison ne fonctionne pas
Modifier l’autorisation pour sssd.conf et créer

le mot de passe obfusqué
Définissez l’autorisation sur sssd.conf sur 600 avec la commande suivante :
Bash
sudo chmod 600 /etc/sssd/sssd.conf
Après cela, créez un mot de passe obfusqué pour le compte de liaison de nom de
domaine. Vous devez insérer le mot de passe de domaine pour ReadOnlyUser :
Bash
sudo sss_obfuscate --domain default
Le mot de passe est placé automatiquement dans le fichier de configuration.
Configurer le service sssd

Démarrez le service sssd :
Bash
sudo systemctl start sssd
Configurez maintenant le service avec l’outil authconfig :
Bash
sudo authconfig --enablesssd --enablesssdauth --enablemkhomedir --updateall
À ce stade, redémarrez le service :
Bash
sudo systemctl restart sssd
Tester la configuration
La dernière étape consiste à vérifier que le flux fonctionne correctement. Pour vérifier
cela, essayez de vous connecter avec l’un de vos utilisateurs AD dans Active Directory.
Nous avons essayé avec un utilisateur appelé ADUser. Si la configuration est correcte,
vous obtenez le résultat suivant :
Sortie
[centosuser@centos8 ~]su - ADUser@contoso.com
Last login: Wed Oct 12 15:13:39 UTC 2022 on pts/0
[ADUser@Centos8 ~]$ exit
Vous êtes maintenant prêt à utiliser l’authentification AD sur votre machine virtuelle
Linux.
Déployer le proxy d’application Azure
AD pour un accès sécurisé aux
applications internes dans un domaine
Services
Article • 01/06/2023
Grâce à Azure AD Domain Services (Azure AD DS), vous pouvez transférer des
applications héritées lift-and-shift s’exécutant localement vers Azure. Le proxy
d’application Azure Active Directory (AD) vous aide à prendre en charge les Workers à
distance en publiant en toute sécurité les applications internes qui font partie d’un
domaine managé Azure AD DS afin qu’elles soient accessibles via Internet.
Si vous débutez avec le Proxy d'application Azure AD et que vous souhaitez en savoir
plus, consultez Comment fournir un accès à distance sécurisé aux applications internes.
Cet article explique comment créer et configurer un connecteur de Proxy d’application

Azure AD pour fournir un accès sécurisé aux applications dans un domaine managé.
Avant de commencer
Une licence Azure AD Premium est nécessaire pour utiliser le proxy
d’application Azure AD.
Domain Services.
Créer une machine virtuelle Windows jointe à
un domaine
Pour acheminer le trafic vers des applications qui s’exécutent dans votre environnement,
vous devez installer le composant connecteur de Proxy d’application Azure AD. Ce
connecteur Azure AD Application Proxy doit être installé sur une machine virtuelle
Windows Server jointe au domaine managé. Pour certaines applications, vous pouvez
déployer plusieurs serveurs sur lesquels le connecteur est installé. Cette option de
déploiement vous donne une plus grande disponibilité et vous permet de traiter des
charges d’authentification plus importantes.
La machine virtuelle qui exécute le connecteur Azure AD Application Proxy doit se

trouver sur le même réseau virtuel que votre domaine managé ou sur un réseau virtuel
appairé. Les machines virtuelles qui hébergent ensuite les applications que vous publiez
à l’aide du Proxy d’application doivent également être déployées sur le même réseau
virtuel Azure.
Pour créer une machine virtuelle pour le connecteur de Proxy d’application Azure AD,

du domaine managé. Les machines virtuelles pour le Proxy d'application Azure AD
et qui exécutent vos applications doivent faire partie de l’unité d’organisation
personnalisée et non de l’unité d’organisation des Ordinateurs AAD DC par défaut.
2. Joignez au domaine les machines virtuelles, celle qui exécute le connecteur de
Proxy d’application Azure AD et celles qui exécutent vos applications, sur le
domaine managé. Créez ces comptes d’ordinateur dans l’unité d’organisation
personnalisée de l’étape précédente.
Télécharger le connecteur de Proxy

d’application Azure AD
Pour télécharger le connecteur de Proxy d'application Azure AD, effectuez les étapes
suivantes. Le fichier d’installation que vous téléchargez est copié sur votre machine
virtuelle de Proxy d’application dans la section suivante.
1. Connectez-vous au Portail Azure avec un compte d’utilisateur disposant des

autorisations Administrateur d’entreprise dans Azure AD.
2. Recherchez et sélectionnez Azure Active Directory en haut du portail, puis
choisissez Applications d’entreprise.
3. Sélectionnez Proxy d’application dans le menu de gauche. Pour créer votre

premier connecteur et activer le Proxy d’application, sélectionnez le lien pour
télécharger un connecteur.
4. Sur la page de téléchargement, acceptez les termes du contrat de licence et

l'accord de confidentialité, puis sélectionnez Accepter les termes et télécharger.
Installer et inscrire le connecteur de Proxy

d'application Azure AD
Une fois qu’une machine virtuelle est prête à être utilisée en tant que connecteur de
Proxy d'application Azure AD, copiez et exécutez le fichier d’installation téléchargé à
partir du Portail Azure.
1. Copiez le fichier d’installation du connecteur de Proxy d'application Azure AD sur

votre machine virtuelle.
2. Exécutez le fichier d’installation, tel que AADApplicationProxyConnectorInstaller.exe.

Acceptez les termes du contrat de licence logicielle.
3. Au cours de l’installation, vous êtes invité à inscrire le connecteur auprès du Proxy

d’application de votre répertoire Azure AD.
Fournissez vos informations d’identification d’administrateur général dans

votre répertoire Azure AD. Les informations d’identification d’administrateur
général Azure AD peuvent être différentes de vos informations
d’identification Azure dans le portail
７ Notes
Le compte d'administrateur général utilisé pour inscrire le connecteur

doit appartenir au même répertoire que celui dans lequel vous avez
activé le service Proxy d’application.
Par exemple, si le domaine Azure AD est contoso.com, l’administrateur

général doit être admin@contoso.com ou tout autre alias valide sur ce
domaine.
Si l’option Configuration de sécurité renforcée d’Internet Explorer est activée

sur la machine virtuelle sur laquelle vous installez le connecteur, l’écran
d’inscription risque d’être bloqué. Pour autoriser l’accès, suivez les
instructions du message d’erreur ou désactivez la sécurité renforcée
d’Internet Explorer au cours du processus d’installation.
Si l’inscription du connecteur échoue, consultezDétecter un problème du

Proxy d’application.
4. À la fin de l’installation, une remarque s’affiche pour les environnements avec un

proxy sortant. Pour configurer le connecteur de Proxy d’application Azure AD et
qu’il fonctionne par le biais du proxy sortant, exécutez le script fourni, tel que
C:\Program Files\Microsoft AAD App Proxy connector\ConfigureOutBoundProxy.ps1 .
5. Dans la page du proxy d’application du Portail Azure, le nouveau connecteur est

répertorié avec l’état Actif, comme indiqué dans l’exemple suivant :
７ Notes
Pour fournit une haute disponibilité pour l’authentification des applications par le
biais du Proxy d’application Azure AD, vous pouvez installer des connecteurs sur
plusieurs machines virtuelles. Effectuez les étapes répertoriées dans la section
précédente pour installer le connecteur sur d’autres serveurs joints au domaine
managé.
Activer la délégation Kerberos contrainte basée

sur les ressources
Si vous voulez utiliser l’authentification unique pour vos applications avec
l’authentification Windows intégrée, octroyez aux connecteurs de Proxy d’application
Azure AD l’autorisation d’emprunter l’identité des utilisateurs, et d’envoyer et de
recevoir des jetons en leur nom. Pour octroyer ces autorisations, configurez la
délégation Kerberos contrainte (KCD) pour le connecteur afin d’accéder aux ressources
sur le domaine managé. Comme vous n’avez pas de privilèges d’administrateur de
domaine dans un domaine managé, les KCD de niveau de compte traditionnels ne
peuvent pas être configurés sur un domaine managé. Utilisez à la place KCD basée sur
des ressources.
Pour plus d’informations, consultez Configurer la délégation Kerberos contrainte (KCD)

dans Azure Active Directory Domain Services.
７ Notes
Vous devez vous connecter à un compte d’utilisateur membre du groupe

Administrateurs Azure AD DC de votre abonné Azure AD pour exécuter les cmdlets
PowerShell suivantes.
Les comptes d’ordinateur de votre machine virtuelle du connecteur Proxy

d’application et machines virtuelles d’application doivent se trouver dans une unité
d’organisation personnalisée dans laquelle vous êtes autorisé à configurer le KCD
basé sur des ressources. Vous ne pouvez pas configurer le mécanisme KCD basé sur
les ressources pour un compte d’ordinateur situé dans le conteneur intégré
Ordinateurs du contrôleur de domaine AAD.
Utilisez la commande Get-ADComputer pour récupérer les paramètres de l’ordinateur

sur lequel est installé le connecteur de Proxy d’application Azure AD. Sur votre machine
virtuelle de gestion jointe au domaine, connectez-vous avec un compte d’utilisateur
membre du groupe Azure AD DC Administrators, puis exécutez les applets de
commande suivantes.
L’exemple suivant obtient des informations sur le compte d’ordinateur nommé
appproxy.aaddscontoso.com. Fournissez votre propre nom d’ordinateur pour la machine
virtuelle de Proxy d'application Azure AD configurée dans les étapes précédentes.
PowerShell
$ImpersonatingAccount = Get-ADComputer -Identity appproxy.aaddscontoso.com
Pour chaque serveur d’applications qui exécute les applications derrière le Proxy
d'application Azure AD, utilisez la cmdlet PowerShell Set-ADComputer pour configurer
des KCD basés sur des ressources. Dans l’exemple suivant, le connecteur de Proxy
d’application Azure AD est autorisé à utiliser l’ordinateur appserver.aaddscontoso.com :
PowerShell
Set-ADComputer appserver.aaddscontoso.com -
PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount
Si vous déployez plusieurs connecteurs de Proxy d’application Azure AD, vous devez
configurer des KCD basés sur des ressources pour chaque instance de connecteur.
Étapes suivantes
Avec le Proxy d'application Azure AD intégré à Azure AD DS, publiez des applications
auxquelles les utilisateurs peuvent accéder. Pour plus d’informations, consultez Publier
des applications à l’aide du Proxy d’application Azure AD.
Configurer Azure Active Directory
Domain Services pour prendre en
charge la synchronisation de profils
utilisateur pour SharePoint Server
Article • 01/06/2023
SharePoint Server propose un service de synchronisation de profils utilisateur. Cette

fonctionnalité permet le stockage de profils utilisateur à un emplacement centralisé
accessible à divers sites et batteries de serveurs SharePoint. Pour configurer le service de
profil utilisateur SharePoint Server, les autorisations appropriées doivent être accordées
dans un domaine managé Azure Active Directory Domain Services (Azure AD DS). Pour
plus d’informations, consultez Synchronisation de profils utilisateur dans SharePoint
Server.
Cet article vous montre comment configurer Azure AD DS pour autoriser le service de
synchronisation de profils utilisateur SharePoint Server.
Avant de commencer
Azure AD DS.
Le nom du compte de service SharePoint pour le service de synchronisation de
profils utilisateur. Pour plus d’informations sur le compte de synchronisation des
profils, consultez Planifier des comptes d’administration et de service dans
SharePoint Server. Pour obtenir le nom du compte de synchronisation des profils sur
le site web SharePoint Central Administration, cliquez sur Application
Management (Gestion des applications)>Manage service applications (Gérer les
applications de service)>User Profile service application (Application de service
Profil utilisateur) . Pour plus d’informations, consultez Configurer la
synchronisation de profil à l’aide de l’importation Active Directory SharePoint dans
SharePoint Server.
Vue d’ensemble des comptes de service

Dans un domaine managé, un groupe de sécurité nommé AAD DC Service Accounts
existe dans l’unité d’organisation Users. Les privilèges suivants sont délégués aux
membres de ce groupe de sécurité :
Le privilège Répliquer les changements de répertoire au DSE racine.

Le privilège Répliquer les changements de répertoire dans le contexte de
nommage Configuration (conteneur cn=configuration ).
Le groupe de sécurité AAD DC Service Accounts est aussi membre du groupe intégré
Accès compatible pré-Windows 2000.
Quand il est ajouté à ce groupe de sécurité, le compte de service du service de

synchronisation de profils utilisateur SharePoint Server se voit accorder les privilèges
nécessaires à son bon fonctionnement.
Activer la prise en charge de la synchronisation

de profils utilisateur SharePoint Server
Le compte de service pour SharePoint Server a besoin des privilèges adéquats pour
répliquer les modifications apportées au répertoire et permettre à la synchronisation de
profils utilisateur SharePoint Server de fonctionner correctement. Pour fournir ces
privilèges, ajoutez le compte de service utilisé pour la synchronisation de profils
utilisateur SharePoint au groupe AAD DC Service Accounts.
À partir de votre machine virtuelle de gestion Azure AD DS, effectuez les étapes
suivantes :
７ Notes
Pour modifier l’appartenance au groupe dans un domaine managé, vous devez être
connecté à un compte d’utilisateur qui est membre du groupe AAD DC
Administrators.

2. Pour gérer l’appartenance au groupe, sélectionnez Centre d’administration Active

Directory dans la liste des outils d’administration.
3. Dans le volet de gauche, choisissez votre domaine managé, par exemple

aaddscontoso.com. Une liste d’unités d’organisation et de ressources existantes
s’affiche.
4. Sélectionnez l’unité d’organisation Users, puis choisissez le groupe de sécurité

AAD DC Service Accounts.
5. Sélectionnez Membres, puis choisissez Ajouter... .
6. Entrez le nom du compte de service SharePoint, puis sélectionnez OK. Dans

l’exemple suivant, le compte de service SharePoint se nomme spadmin :
Erreurs courantes et étapes de
dépannage pour Azure Active Directory
Domain Services
Article • 01/06/2023
En tant qu’élément central de l’identité et de l’authentification des applications, Azure

Active Directory Domain Services (Azure AD DS) rencontre parfois des problèmes. Si cela
vous arrive, les messages d’erreur courants et les étapes de dépannage associées sont là
pour vous aider à rétablir le service. De même, vous pouvez à tout moment formuler
une demande de support Azure pour bénéficier d’une aide supplémentaire.
Cet article indique les étapes à suivre pour résoudre les problèmes courants dans Azure
AD DS.
Vous ne pouvez pas activer les services de

domaine Azure AD pour votre annuaire
Azure AD
Si vous avez des difficultés à activer Azure AD DS, examinez ci-dessous les erreurs
courantes et les étapes à suivre pour les résoudre :
Exemple de message d’erreur Résolution :
Le nom aaddscontoso.com est déjà utilisé sur ce réseau. Spécifiez un Conflit de nom de
nom qui n’est pas utilisé. domaine dans le réseau
virtuel
Les services de domaine n’ont pas pu être activés pour ce client Azure L’application Domain
AD. Le service ne dispose pas des autorisations adéquates pour Services ne dispose pas
l’application appelée « Synchronisation des services de domaine Azure des autorisations
AD ». Supprimez l’application appelée « Synchronisation des services de adéquates pour
domaine Azure AD » et réessayez d’activer les services de domaine pour l’application de
votre client Azure AD. synchronisation d’Azure
AD Domain Services
Les services de domaine n’ont pas pu être activés pour ce client Azure L’application Domain
AD. L’application de services de domaine dans votre client Azure AD n’a Services n’est pas
pas les autorisations requises pour activer les services de domaine. configurée correctement
Supprimez l’application avec l’identificateur d’application d87dcbc6- dans votre locataire
a371-462e-88e3-28ad15ec4e64 et essayez ensuite d’activer les services Azure AD
de domaine pour votre client Azure AD.
Exemple de message d’erreur Résolution :
Les services de domaine n’ont pas pu être activés pour ce client Azure L’application Microsoft
AD. L’application Microsoft Azure AD est désactivée dans votre client Graph est désactivée
Azure AD. Activez l’application avec l’identificateur d’application dans votre client Azure
00000002-0000-0000-c000-000000000000 et essayez ensuite d’activer AD.
les services de domaine pour votre client Azure AD.
Conflit de nom de domaine

Message d’erreur
Le nom aaddscontoso.com est déjà utilisé sur ce réseau. Spécifiez un nom qui n’est pas
utilisé.
Résolution :
Vérifiez que vous n’avez pas d’environnement AD DS existant avec le même nom de
domaine sur le même réseau virtuel ou sur un réseau virtuel appairé. Par exemple, si
vous disposez d’un domaine AD DS nommé aaddscontoso.com qui s’exécute sur des
machines virtuelles Azure. Quand vous essayez d’activer un domaine managé Azure AD
DS avec le même nom de domaine (aaddscontoso.com) sur le réseau virtuel, l’opération
demandée échoue.
Cet échec est dû à des conflits de noms pour le nom de domaine sur le réseau virtuel.
Une recherche DNS vérifie si un environnement AD DS existant répond au nom de
domaine demandé. Pour résoudre cet échec, utilisez un nom différent pour configurer
votre domaine managé, ou supprimez le domaine AD DS existant, puis réessayez
d’activer Azure AD DS.
Autorisations inappropriées
Message d’erreur
Les services de domaine n’ont pas pu être activés pour ce client Azure AD. Le service ne
dispose pas des autorisations adéquates pour l’application appelée « Synchronisation des
services de domaine Azure AD ». Supprimez l’application appelée « Synchronisation des
services de domaine Azure AD » et réessayez d’activer les services de domaine pour votre
client Azure AD.
Résolution :
Vérifiez s’il existe une application nommée Azure AD Domain Services Sync dans votre
annuaire Azure AD. Si cette application existe, supprimez-la, puis réessayez d’activer
Azure AD DS. Pour rechercher une application existante et la supprimer si nécessaire,
effectuez les étapes suivantes :
1. Sur le portail Azure, sélectionnez Azure Active Directory dans le volet de

navigation gauche.
2. Sélectionnez Applications d’entreprise. Choisissez Toutes les application dans le
menu déroulant Type d’application, puis sélectionnez Appliquer.
3. Dans la zone de recherche, entrez Azure AD Domain Services Sync. Si l’application
existe, sélectionnez-la et choisissez Supprimer.
4. Une fois que vous avez supprimé l’application, essayez à nouveau d’activer Azure
AD DS.
Configuration non valide

Message d’erreur
Les services de domaine n’ont pas pu être activés pour ce client Azure AD. L’application de
services de domaine dans votre client Azure AD n’a pas les autorisations requises pour
activer les services de domaine. Supprimez l’application avec l’identificateur d’application
d87dcbc6-a371-462e-88e3-28ad15ec4e64 et essayez ensuite d’activer les services de
domaine pour votre client Azure AD.
Résolution :
Vérifiez si votre annuaire Azure AD contient une application nommée

AzureActiveDirectoryDomainControllerServices avec l’identificateur d’application
d87dcbc6-a371-462e-88e3-28ad15ec4e64. Si cette application existe, supprimez-la, puis
essayez à nouveau d’activer Azure AD DS.
Utilisez le script PowerShell suivant pour rechercher une instance d’application existante

et la supprimer si nécessaire :
PowerShell
$InformationPreference = "Continue"
$WarningPreference = "Continue"
$aadDsSp = Get-AzureADServicePrincipal -Filter "AppId eq 'd87dcbc6-a371-

462e-88e3-28ad15ec4e64'" -ErrorAction Ignore
if ($aadDsSp -ne $null)

{
Write-Information "Found Azure AD Domain Services application. Deleting

it ..."
Remove-AzureADServicePrincipal -ObjectId $aadDsSp.ObjectId
Write-Information "Deleted the Azure AD Domain Services application."
$identifierUri = "https://sync.aaddc.activedirectory.windowsazure.com"
$appFilter = "IdentifierUris eq '" + $identifierUri + "'"
$app = Get-AzureADApplication -Filter $appFilter
if ($app -ne $null)
Write-Information "Found Azure AD Domain Services Sync application.

Deleting it ..."
Remove-AzureADApplication -ObjectId $app.ObjectId
Write-Information "Deleted the Azure AD Domain Services Sync

application."
$spFilter = "ServicePrincipalNames eq '" + $identifierUri + "'"
$sp = Get-AzureADServicePrincipal -Filter $spFilter
if ($sp -ne $null)
Write-Information "Found Azure AD Domain Services Sync service

principal. Deleting it ..."
Remove-AzureADServicePrincipal -ObjectId $sp.ObjectId
Write-Information "Deleted the Azure AD Domain Services Sync service

principal."
Microsoft Graph désactivé

Message d’erreur
Les services de domaine n’ont pas pu être activés pour ce client Azure AD. L’application
Microsoft Azure AD est désactivée dans votre client Azure AD. Activez l’application avec
l’identificateur d’application 00000002-0000-0000-c000-000000000000 et essayez ensuite
d’activer les services de domaine pour votre client Azure AD.
Résolution :
Vérifiez si vous avez désactivé une application associée à l’identificateur 00000002-0000-

0000-c000-000000000000. Cette application est l’application Microsoft Azure AD et
fournit l’accès de l’API Graph à votre client Azure AD. Pour synchroniser votre locataire
Azure AD, cette application doit être activée.
Pour vérifier l’état de cette application existante et l’activer si nécessaire, effectuez les
étapes suivantes :

navigation gauche.
3. Dans la zone de recherche, entrez 00000002-0000-0000-c000-00000000000.
Sélectionnez l’application, puis choisissez Propriétés.
4. Si Activé pour que les utilisateurs se connectent est défini sur Non, définissez la
valeur sur Oui, puis sélectionnez Enregistrer.
5. Une fois que vous avez activé l’application, essayez à nouveau d’activer Azure AD
DS.
Les utilisateurs sont incapables de se connecter

aux services de domaine Asure AD gérés
Si des utilisateurs de votre locataire Azure AD ne peuvent pas se connecter au domaine
managé, effectuez les étapes de dépannage suivantes :
Format d’informations d’identification – Essayez d’utiliser le format UPN pour

spécifier les informations d’identification, par exemple
dee@aaddscontoso.onmicrosoft.com . Le format UPN est la méthode recommandée
pour spécifier les informations d’identification dans Azure AD DS. Vérifiez que cet
UPN est correctement configuré dans Azure AD.
La valeur SAMAccountName de votre compte, par exemple

AADDSCONTOSO\driley, peut être générée automatiquement s’il existe plusieurs
utilisateurs avec le même préfixe UPN dans votre locataire ou si votre préfixe UPN
est trop long. Par conséquent, le format SAMAccountName de votre compte peut
être différent de ce que vous attendiez ou de celui que vous utilisez dans votre
domaine local.
Synchronisation de mot de passe – Veillez à activer la synchronisation de mot de

passe pour les utilisateurs cloud uniquement ou pour les environnements hybrides
utilisant Azure AD Connect.
Comptes synchronisés hybrides : si les comptes d’utilisateurs affectés sont

synchronisés à partir d’un annuaire local, vérifiez les éléments suivants :
Vous avez déployé la dernière version recommandée d’Azure AD Connect

ou procédé à une mise à jour vers cette version.
Vous avez configuré Azure AD Connect pour effectuer une synchronisation

complète.
Selon la taille de votre répertoire, la mise à disposition des comptes

d’utilisateurs et des hachages d’informations d’identification dans le domaine
managé peut prendre un certain temps. Veillez à attendre suffisamment
longtemps avant d’essayer de vous authentifier pour le domaine managé.
Si le problème persiste après la vérification des étapes précédentes, essayez

de redémarrer Microsoft Azure Active Directory Sync Services. À partir de votre
serveur Azure AD Connect, ouvrez une invite de commandes et exécutez les
commandes suivantes :
Console
net stop 'Microsoft Azure AD Sync'
net start 'Microsoft Azure AD Sync'
Comptes cloud uniquement : si le compte d’utilisateur en question est un

compte d’utilisateur cloud uniquement, vérifiez que l’utilisateur a changé son
mot de passe après que vous avez activé Azure AD DS. Cette réinitialisation de
mot de passe entraîne la génération des hachages d’informations
d’identification nécessaires à la génération du domaine managé.
Vérifiez que le compte d’utilisateur est actif: par défaut, cinq tentatives de saisie
de mot de passe non valide en 2 minutes dans le domaine managé entraînent le
verrouillage d’un compte d’utilisateur pendant 30 minutes. L’utilisateur ne peut pas
se connecter tant que le compte est verrouillé. Après ces 30 minutes, le compte
d’utilisateur est automatiquement déverrouillé.
Les tentatives de saisie de mot de passe non valide dans le domaine managé ne
verrouillent pas le compte d’utilisateur dans Azure AD. Le compte d’utilisateur
est verrouillé uniquement dans votre domaine managé. Vérifiez l’état du compte
d’utilisateur dans la console d’administration Active Directory (ADAC) en utilisant
la machine virtuelle de gestion, et non dans Azure AD.
Vous pouvez aussi configurer des stratégies de mot de passe affinées pour
modifier le seuil et la durée de verrouillage par défaut.
Comptes externes – Vérifiez que le compte d’utilisateur en question n’est pas un

compte externe dans le locataire Azure AD. Les comptes Microsoft comme
dee@live.com ou les comptes d’utilisateurs d’un annuaire Azure AD externe sont
des exemples de comptes externes. Azure AD DS ne stocke pas les informations
d’identification pour les comptes d’utilisateurs externes et ne peut donc pas se
connecter au domaine managé.
Il existe une ou plusieurs alertes sur votre

domaine géré
La présence d’alertes actives dans le domaine managé peut empêcher le bon
fonctionnement du processus d’authentification.
Pour savoir s’il existe des alertes actives, vérifiez l’état d’intégrité d’un domaine managé.
Si des alertes sont présentes, résolvez les problèmes associés.
Les utilisateurs supprimés de votre client Azure

AD ne sont pas supprimés de votre domaine
géré
Azure AD protège contre la suppression accidentelle d’objets utilisateur. Quand vous
supprimez un compte d’utilisateur d’un locataire Azure AD, l’objet utilisateur
correspondant est déplacé dans la corbeille. Quand cette opération de suppression est
synchronisée avec votre domaine managé, le compte d’utilisateur correspondant est
marqué comme étant désactivé. Cette fonctionnalité vous permet de récupérer le
compte d’utilisateur, c’est-à-dire d’annuler sa suppression.
Le compte d’utilisateur reste dans un état désactivé dans le domaine managé, même si
vous recréez un compte d’utilisateur avec le même UPN dans le répertoire Azure AD.
Pour supprimer le compte d’utilisateur du domaine managé, vous devez forcer sa
suppression dans le locataire Azure AD.
Pour supprimer entièrement un compte d’utilisateur d’un domaine managé, supprimez

définitivement l’utilisateur de votre locataire Azure AD à l’aide du cmdlet PowerShell
Remove-MsolUser avec le paramètre -RemoveFromRecycleBin .
Étapes suivantes
Si vous continuez à rencontrer des problèmes, ouvrez une requête de support Azure
pour obtenir un résolution des problèmes supplémentaire.
Résoudre les problèmes de jonction à
un domaine avec un domaine managé
Article • 01/06/2023
Lorsque vous essayez de joindre une machine virtuelle ou de connecter une application
à un domaine managé Azure Active Directory Domain Services (Azure AD DS), vous
pouvez obtenir une erreur indiquant que vous ne pouvez pas le faire. Pour résoudre les
problèmes de jonction à un domaine, identifiez les points où vous avez un problème
parmi les suivants :
Si vous ne recevez pas d’invite d’authentification, la machine virtuelle ou

l’application ne peut pas se connecter au domaine managé Azure AD DS.
Commencez à résoudre les problèmes de connectivité pour la jonction à un
domaine.
Si vous recevez une erreur lors de l’authentification, la connexion au domaine
managé est établie.
Commencez à résoudre les problèmes liés aux informations d’identification lors
de la jonction à un domaine.
Problèmes de connectivité pour la jonction à

un domaine
Si la machine virtuelle ne peut pas trouver le domaine managé, il s’agit généralement
d’un problème de configuration ou de connexion réseau. Passez en revue les étapes
suivantes de résolution des problèmes pour localiser et résoudre le problème :
1. Vérifiez que la machine virtuelle est connectée au même réseau virtuel, ou à un

réseau virtuel appairé en tant que domaine managé. Si ce n’est pas le cas, la
machine virtuelle ne peut pas trouver le domaine et s’y connecter pour le
rejoindre.
Si la machine virtuelle n’est pas connectée au même réseau virtuel, vérifiez

que l’appairage de réseau virtuel ou la connexion VPN est Active (Actif) ou
Connected (Connecté) pour permettre au trafic de circuler correctement.
2. Effectuez un test Ping du domaine en utilisant le nom du domaine managé (par

exemple, ping aaddscontoso.com ).
Si la réponse au test Ping échoue, essayez d’effectuer un test Ping des
adresses IP du domaine affiché dans la page de présentation du portail pour
votre domaine managé, par exemple ping 10.0.0.4 .
Si le test Ping de l’adresse IP aboutit contrairement à celui du domaine, il se
peut que la fonction DNS ne soit pas correctement configurée. Vérifiez que
vous avez configuré les serveurs DNS du domaine managé pour le réseau
virtuel.
3. Essayez de vider le cache de résolution DNS sur la machine virtuelle, par exemple
ipconfig /flushdns .
Configuration du groupe de sécurité réseau

Lorsque vous créez un domaine managé, un groupe de sécurité réseau est également
créé avec les règles appropriées pour une opération réussie du domaine. Si vous
modifiez ou créez des règles de groupe de sécurité réseau, vous pouvez
involontairement bloquer les ports requis pour Azure AD DS afin de fournir des services
de connexion et d’authentification. Ces règles de groupe de sécurité réseau peuvent
provoquer des problèmes comme une synchronisation de mot de passe qui ne se
termine pas, des utilisateurs dans l’impossibilité de se connecter ou des problèmes de
Si vous continuez de rencontrer des problèmes de connexion, passez en revue les

étapes suivantes de résolution des problèmes :
1. Vérifiez l’état d’intégrité de votre domaine managé dans le portail Azure. Si vous
avez une alerte pour AADDS001, une règle de groupe de sécurité réseau bloque
l’accès.
2. Examinez les règles de groupe de sécurité réseau et ports requis. Vérifiez
qu’aucune règle de groupe de sécurité réseau appliquée à la machine virtuelle ou
au réseau virtuel à partir duquel vous vous connectez ne bloque ces ports réseau.
3. Une fois les problèmes de configuration d’un groupe de sécurité réseau résolus,
l’alerte AADDS001 disparaît de la page d’intégrité en 2 heures environ. Maintenant
que la connectivité réseau est disponible, essayez à nouveau de joindre la machine
virtuelle au domaine.
Problèmes liés aux informations

d’identification lors de la jonction à un
domaine
Si une boîte de dialogue s’affiche et vous demande d’entrer des informations
d’identification pour rejoindre le domaine managé, la machine virtuelle est en mesure
de se connecter au domaine à l’aide du réseau virtuel Azure. Le processus de jonction au
domaine échoue lors de l’authentification auprès du domaine ou de l’autorisation
d’effectuer le processus de jonction au domaine à l’aide des informations
d’identification fournies.
Pour résoudre les problèmes liés aux informations d’identification, passez en revue les
étapes suivantes de résolution des problèmes :
1. Essayez en utilisant le format UPN pour spécifier les informations d’identification,

par exemple dee@contoso.onmicrosoft.com . Vérifiez que cet UPN est correctement
configuré dans Azure AD.
La valeur de SAMAccountName pour votre compte peut être générée

automatiquement s’il existe plusieurs utilisateurs avec le même préfixe UPN
dans votre locataire ou si votre préfixe UPN est trop long. Par conséquent, le
format SAMAccountName de votre compte peut être différent de ce que vous
attendiez ou de celui que vous utilisez dans votre domaine local.
2. Essayez d’utiliser les informations d’identification d’un compte d’utilisateur faisant

partie du domaine managé pour joindre des machines virtuelles au domaine
managé.
3. Vérifiez que vous avez activé la synchronisation de mot de passe et que vous avez
attendu suffisamment de temps pour que la synchronisation de mot de passe
initiale se termine.
Étapes suivantes
Pour une compréhension plus approfondie des processus Active Directory dans le cadre
de l’opération de jonction à un domaine, consultez Problèmes de jonction et
d’authentification.
Si vous rencontrez toujours des problèmes pour joindre votre machine virtuelle au
domaine managé, trouvez de l’aide et ouvrez un ticket de support pour Azure Active
Directory.
Résoudre les problèmes de verrouillage
de compte avec un domaine managé
Article • 01/06/2023
Pour empêcher toute tentative de connexion malveillante, un domaine géré Azure

Active Directory Domain Services (Azure AD DS) verrouille les comptes après un seuil
défini. Ce verrouillage de compte peut également se produire par accident, sans
tentative de connexion malveillante. Par exemple, si un utilisateur entre plusieurs fois un
mot de passe incorrect ou qu’un service tente d’utiliser un ancien mot de passe, le
compte est verrouillé.
Cet article explique pourquoi les verrouillages de compte se produisent, comment

configurer ce comportement et examiner les audits de sécurité pour remédier aux
événements de verrouillage.
Qu’est-ce qu’un verrouillage de compte ?

Un compte utilisateur dans un domaine managé Azure AD DS est verrouillé lorsqu’un
seuil défini pour les tentatives de connexion infructueuses a été atteint. Ce
comportement de verrouillage de compte est conçu pour vous protéger contre les
tentatives répétées de connexion par force brute qui pourraient indiquer une attaque
numérique automatisée.
Par défaut, si cinq tentatives de mot de passe incorrectes ont lieu en l’espace de deux
minutes, le compte est verrouillé pendant 30 minutes.
Les seuils de verrouillage de compte par défaut sont configurés à l’aide d’une stratégie
de mot de passe affinée. En présence de conditions requises spécifiques, vous pouvez
remplacer ces seuils de verrouillage de compte par défaut. Cela étant, il est déconseillé
d’augmenter les limites de seuil pour tenter de réduire le nombre de verrouillages de
compte. Penchez-vous dans un premier temps sur la source du comportement de
verrouillage de compte.
Stratégie de mot de passe affinée

Les stratégies de mot de passe affinées (SMPA) vous permettent d’appliquer des
restrictions spécifiques pour les stratégies de verrouillage de compte et de mot de passe
à différents utilisateurs d’un domaine. La SMPA affecte uniquement les utilisateurs au
sein d’un domaine managé. Les utilisateurs de cloud et de domaine synchronisés dans le
domaine managé à partir d’Azure AD ne sont affectés que par les stratégies de mot de
passe définies à l’intérieur du domaine managé. Leurs comptes dans Azure AD ou dans
un répertoire local ne sont pas affectés.
Les stratégies sont distribuées par le biais de l’association de groupes dans le domaine
managé, et les modifications que vous apportez sont appliquées à la connexion
utilisateur suivante. La modification de la stratégie ne déverrouille pas un compte
d’utilisateur qui est déjà verrouillé.
Pour plus d’informations sur les stratégies de mot de passe affinées, ainsi que sur les
différences entre les utilisateurs créés directement dans Azure AD Directory et
synchronisés à partir d’Azure AD, consultez Configurer des stratégies de mot de passe et
de verrouillage de compte.
Raisons courantes d'un verrouillage de compte

Les raisons les plus courantes expliquant un verrouillage de compte, sans intention ou
facteur malveillant, incluent les scénarios suivants :
L’utilisateur s’est lui-même verrouillé.

Après une récente modification du mot de passe, l’utilisateur a-t-il continué
d'utiliser un précédent mot de passe ? La stratégie de verrouillage de compte
par défaut de cinq échecs de connexion en 2 minutes peut être due au fait que
l’utilisateur a utilisé par inadvertance un ancien mot de passe.
Une application ou un service est associé à un ancien mot de passe.
Si un compte est utilisé par des applications ou services, ces ressources peuvent
essayer à plusieurs reprises de se connecter à l’aide d’un ancien mot de passe.
Un tel comportement entraîne le verrouillage du compte.
Essayez de limiter l’utilisation du compte par plusieurs applications ou services
différents, et enregistrez les informations d’identification utilisées. En cas de
modification d'un mot de passe de compte, mettez à jour les applications ou
services associés en conséquence.
Le mot de passe a été modifié dans un environnement différent et le nouveau
mot de passe n’a pas encore été synchronisé.
Si un mot de passe de compte est modifié en dehors du domaine managé, par
exemple dans un environnement AD DS local, la synchronisation du mot de
passe modifié peut prendre plusieurs minutes via Azure AD et dans le domaine
managé.
Si l'utilisateur tente de se connecter à une ressource dans le domaine managé
avant la fin du processus de synchronisation du mot de passe, son compte est
verrouillé.
Résoudre les problèmes de verrouillage de

compte avec les audits de sécurité
Pour résoudre les problèmes liés aux événements de verrouillage de compte et à leur
source, activez les audits de sécurité pour Azure AD DS. Les événements d’audit sont
uniquement capturés à partir du moment où vous activez cette fonctionnalité.
Idéalement, vous devez activer les audits de sécurité avant d'être amené à remédier à un
problème de verrouillage de compte. Si un compte d’utilisateur se heurte à des
problèmes répétés de verrouillage, vous pouvez activer les audits de sécurité pour éviter
qu'ils se reproduisent.
Une fois les audits de sécurité activés, les exemples de requêtes suivants vous
expliquent comment examiner les Événements de verrouillage de compte, code 4740.
Affichez tous les événements de verrouillage de compte au cours des sept derniers
jours :
Kusto
Affichez tous les événements de verrouillage de compte au cours des sept derniers jours
pour le compte appelé driley.
Kusto
| where "driley" == tolower(extract("Logon Account:\t(.+[0-9A-Za-

Affichez tous les événements de verrouillage de compte entre le 26 juin 2020 à 9 h et le

1er juillet 2020 à minuit, triés par ordre croissant de date et d’heure :
Kusto
| where TimeGenerated >= datetime(2020-06-26 09:00) and TimeGenerated <=

datetime(2020-07-01)
| sort by TimeGenerated asc
Vous pouvez constater que la section détaillée « Source Workstation : » (« Station de

travail source ») est vide pour les événements 4776 et 4740. C'est parce que le mauvais
mot de passe a circulé sur une connexion réseau via d’autres appareils.
Par exemple, un serveur RADIUS peut transférer l’authentification à Azure AD DS.
03/04 19:07:29 [LOGON] [10752] contoso : SamLogon : ouverture de session réseau

transitive de contoso\Nagappan.Veerappan à partir de (via LOB11-RADIUS) entrée

transitive de contoso\Nagappan.Veerappan à partir de (via LOB11-RADIUS) retourne
0xC000006A

transitive de contoso\Nagappan.Veerappan à partir de (via LOB11-RADIUS) entrée

transitive de contoso\Nagappan.Veerappan à partir de (via LOB11-RADIUS) retourne
0xC000006A
Activez le protocole RDP sur vos contrôleurs de domaine dans le groupe de sécurité
réseau sur le back-end pour configurer la capture de diagnostics (netlogon). Pour plus
d'informations sur les exigences des groupes de sécurité, voir Règle de sécurité
entrantes.
Si vous avez déjà modifié le groupe de sécurité réseau par défaut, suivez Port 3389 :
gestion par bureau distant.
Pour activer le journal Netlogon sur n’importe quel serveur, suivez Activation de la
journalisation de débogage pour le service Netlogon.
Étapes suivantes
Pour plus d’informations sur les stratégies de mot de passe affinées afin d'ajuster les
seuils de verrouillage de compte, consultez Configurer des stratégies de mot de passe et
de verrouillage de compte.
domaine managé, trouvez de l’aide et ouvrez un ticket de support pour Azure Active
Directory.
Résoudre les problèmes de connexion
au compte avec un domaine managé
Article • 01/06/2023
Les raisons les plus courantes pour lesquelles un compte utilisateur ne peut pas se
connecter à un domaine Azure AD DS (Azure Active Directory) incluent les scénarios
suivants :
Le compte n’est pas encore synchronisé avec Azure AD DS.

Azure AD DS ne dispose pas des hachages de mot de passe pour permettre au
compte de se connecter.
Le compte est verrouillé.
 Conseil
Azure AD DS ne peut pas synchroniser les informations d’identification des

comptes qui sont externes au locataire Azure AD. Les utilisateurs externes ne
peuvent pas se connecter au domaine managé Azure AD DS.
Le compte n’est pas encore synchronisé avec

Azure AD DS
Selon la taille de votre répertoire, la mise à disposition des comptes d’utilisateurs et des
hachages d’informations d’identification dans le domaine managé peut prendre un
certain temps. Pour les annuaires de grande taille, cette synchronisation
unidirectionnelle initiale à partir d’Azure AD peut prendre entre quelques heures et un
ou deux jours. Patientez suffisamment longtemps avant d’effectuer une nouvelle
tentative d’authentification.
Pour les environnements hybrides qui utilisent Azure AD Connect pour synchroniser les
données d’annuaire locales avec Azure AD, assurez-vous que vous utilisez la dernière
version d’Azure AD Connect et que vous avez configuré Azure AD Connect pour
effectuer une synchronisation complète après avoir activé Azure AD DS. Si vous
désactivez Azure AD DS et que vous le réactivez, vous devez suivre ces étapes à
nouveau.
Si vous continuez d’avoir des problèmes avec des comptes qui ne se synchronisent pas
via Azure AD Connect, redémarrez le service Azure AD Sync. À partir de l’ordinateur sur
lequel Azure AD Connect est installé, ouvrez une fenêtre d’invite de commande et
exécutez les commandes suivantes :
Console
net stop 'Microsoft Azure AD Sync'
net start 'Microsoft Azure AD Sync'
Azure AD DS ne dispose pas des hachages de

mot de passe
Azure AD ne génère pas et ne stocke pas les hachages de mot de passe au format
nécessaire pour l’authentification NTLM ou Kerberos tant que vous n’activez pas Azure
AD DS pour votre locataire. Pour des raisons de sécurité, Azure AD ne stocke pas non
plus d’informations d’identification de mot de passe sous forme de texte en clair. Par
conséquent, Azure AD ne peut pas générer automatiquement ces hachages de mot de
passe NTLM ou Kerberos en fonction des informations d’identification existantes des
utilisateurs.
Environnements hybrides avec synchronisation locale

Pour les environnements hybrides utilisant Azure AD Connect pour la synchronisation à
partir d’un environnement AD DS local, vous pouvez générer et synchroniser localement
les hachages de mots de passe NTLM ou Kerberos requis dans Azure AD. Après avoir
créé un domaine managé, activez la synchronisation du hachage de mot de passe pour
Azure Active Directory Domain Services. Sans terminer cette étape de synchronisation
de hachage de mot de passe, vous ne pouvez pas vous connecter à un compte à l’aide
d’un domaine managé. Si vous désactivez Azure AD DS et que vous le réactivez, vous
devez suivre ces étapes à nouveau.
Pour plus d’informations, consultez la rubrique concernant le fonctionnement de la

synchronisation de hachage du mot de passe pour Azure AD DS.
Environnements cloud uniquement sans synchronisation

locale
Les domaines managés sans synchronisation locale (comptes Azure AD uniquement)
doivent également générer les hachages de mot de passe NTLM ou Kerberos requis. Si
un compte cloud uniquement ne peut pas se connecter, le mot de passe a-t-il été mis à
jour après l’activation d’Azure AD DS ?
Non, le mot de passe n’a pas été modifié.

Modifiez le mot de passe du compte pour générer les hachages de mot de
passe requis, puis attendez 15 minutes avant d’essayer de vous reconnecter.
Si vous désactivez Azure AD DS, puis le réactivez, chaque compte doit suivre à
nouveau la procédure de changement du mot de passe et de génération du
hachage de mot de passe requise.
Oui, le mot de passe a été modifié.
Essayez de vous connecter en utilisant le format UPN, tel que
driley@aaddscontoso.com , et non pas le format SAMAccountName, tel que
AADDSCONTOSO\deeriley .
Le format SAMAccountName peut être généré automatiquement pour les
utilisateurs dont le préfixe UPN est trop long ou identique à un autre utilisateur
sur le domaine managé. Le format UPN garantit des données uniques au sein
d’Azure AD.
Le compte est verrouillé

Un compte utilisateur dans un domaine managé est verrouillé lorsqu’un seuil défini pour
les tentatives de connexion infructueuses a été atteint. Ce comportement de
verrouillage de compte est conçu pour vous protéger contre les tentatives répétées de
connexion par force brute qui pourraient indiquer une attaque numérique automatisée.
Par défaut, si cinq tentatives de mot de passe incorrectes ont lieu en l’espace de deux
minutes, le compte est verrouillé pendant 30 minutes.
Pour plus d’informations et pour savoir comment résoudre les problèmes de blocage de
compte, consultez la rubrique Troubleshoot account lockout problems in Azure AD DS
(Résolution des problèmes de blocage de compte dans Azure AD DS).
Étapes suivantes
domaine managé, demandez de l’aide et ouvrez un ticket de support pour Azure Active
Directory.
Résoudre des erreurs d’annuaire
incompatible pour des domaines
managés Azure Active Directory Domain
Services existants
Article • 01/06/2023
Si un domaine managé Azure Active Directory Domain Services (Azure AD DS) affiche
une erreur de locataire incompatible, vous ne pouvez pas administrer le domaine
managé jusqu’à ce qu’elle soit résolue. Cette erreur se produit si le réseau virtuel Azure
sous-jacent est déplacé vers un autre annuaire Azure AD.
Cet article explique pourquoi l’erreur se produit et comment la résoudre.
Quelle est la cause de cette erreur ?

Une erreur d’annuaire incompatible se produit quand un domaine managé Azure AD DS
et un réseau virtuel appartiennent à deux locataires Azure AD différents. Par exemple,
vous pouvez avoir un domaine managé nommé aaddscontoso.com qui s’exécute dans le
locataire Azure AD de Contoso. Toutefois, le réseau virtuel Azure pour le domaine
managé fait partie du locataire Azure AD Fabrikam.
Le contrôle d’accès en fonction du rôle Azure (Azure RBAC) sert à limiter l’accès aux
ressources. Lorsque vous activez Azure AD DS dans un locataire Azure AD, les hachages
des informations d’identification sont synchronisés avec le domaine managé. Pour
effectuer cette opération, vous devez être un administrateur de locataire pour l’annuaire
Azure AD et l’accès aux informations d’identification doit être contrôlé.
Pour déployer des ressources sur un réseau virtuel Azure et contrôler le trafic, vous
devez disposer de privilèges d’administrateur sur le réseau virtuel sur lequel vous
déployez le domaine managé.
Pour qu’Azure RBAC fonctionne de manière cohérente et sécurise l’accès à toutes les
ressources utilisées par Azure AD DS, le domaine managé et le réseau virtuel doivent
appartenir au même locataire Azure AD.
Les règles suivantes s’appliquent aux déploiements :
Un annuaire Azure AD peut avoir plusieurs abonnements Azure.

Un abonnement Azure peut avoir plusieurs ressources telles que des réseaux
virtuels.
Un seul domaine managé est activé pour un annuaire Azure AD.
Un domaine managé peut être activé sur un réseau virtuel appartenant à l’un des
abonnements Azure du même locataire Azure AD.
Configuration valide
Dans l’exemple de scénario de déploiement suivant, le domaine managé Contoso est
activé dans le locataire Azure AD Contoso. Le domaine managé est déployé sur un
réseau virtuel appartenant à un abonnement Azure détenu par le locataire Azure AD
Contoso.
Le domaine managé et le réseau virtuel appartiennent tous deux au même locataire

Azure AD. Cet exemple de configuration est valide et entièrement pris en charge.
Configuration de locataire incompatible

Dans cet exemple de scénario de déploiement, le domaine managé Contoso est activé
dans le locataire Azure AD Contoso. Toutefois, le domaine managé est déployé dans un
réseau virtuel appartenant à un abonnement Azure détenu par le locataire Azure AD
Fabrikam.
Le domaine managé et le réseau virtuel appartiennent à deux locataires Azure AD
différents. Cet exemple de configuration correspond à un locataire incompatible et n’est
pas pris en charge. Le réseau virtuel doit être déplacé vers le même locataire Azure AD
que le domaine managé.
Résoudre l’erreur de locataire incompatible

Les deux options suivantes permettent de résoudre l’erreur d’annuaire incompatible :
Tout d’abord, supprimez le domaine managé de votre annuaire Azure AD. Ensuite,
créez un domaine managé de remplacement dans le même annuaire Azure AD que
le réseau virtuel que vous souhaitez utiliser. Quand vous êtes prêt, joignez au
domaine managé recréé toutes les machines précédemment jointes au domaine
supprimé.
Déplacez l’abonnement Azure contenant le réseau virtuel vers le même annuaire
Azure AD que le domaine managé.
Étapes suivantes
Pour plus d’informations sur la résolution des problèmes liés à Azure AD DS, consultez
le guide de résolution des problèmes.
Comprendre les états d’intégrité et
résoudre les domaines suspendus dans
Article • 01/06/2023
Quand Azure AD Domain Services (Azure AD DS) ne parvient pas à mettre en service un
domaine managé pendant une longue période, ça met ce domaine en état de
suspension. Si un domaine managé reste dans un état suspendu, il est automatiquement
supprimé. Pour assurer l’intégrité de votre domaine managé Azure AD DS et éviter la
suspension, résolvez toutes les alertes aussi rapidement que possible.
Cet article explique pourquoi les domaines managés sont suspendus et comment
récupérer un domaine suspendu.
Vue d’ensemble des états des domaines

managés
Tout au long du cycle de vie d’un domaine managé, différents états indiquent son
intégrité. Si le domaine managé signale un problème, résolvez rapidement la cause
sous-jacente pour empêcher l’état de continuer de se dégrader.
Un domaine managé peut avoir l’un des états suivants :
Exécution
Doit être surveillé
Suspendu
Supprimé
État En cours d’exécution
Un domaine managé qui est configuré correctement et sans problème se trouve dans
l’état En cours d’exécution. Il s’agit de l’état souhaité pour un domaine managé.
À quoi s’attendre
La plateforme Azure peut superviser régulièrement l’intégrité du domaine managé.
Les contrôleurs du domaine managé sont corrigés et mis à jour régulièrement.
Les modifications effectuées dans Azure Active Directory sont régulièrement
synchronisées avec le domaine managé.
Des sauvegardes du domaine managé sont effectuées régulièrement.
État Doit être surveillé

Un domaine managé présentant un ou plusieurs problèmes qui doivent être résolus se
trouve dans l’état Doit être surveillé. La page d’intégrité du domaine managé liste les
alertes et indique où un problème se pose.
Certaines alertes sont temporaires et résolues automatiquement par la plateforme

Azure. Pour d’autres alertes, vous pouvez résoudre le problème en suivant les étapes de
résolution indiquées. En cas d’alerte critique, formulez une demande de support Azure
pour bénéficier d’une aide supplémentaire.
Un groupe de sécurité réseau restrictif représente un exemple d’alerte. Dans cette

configuration, la plateforme Azure peut ne pas être en mesure de mettre à jour et de
superviser le domaine managé. Une alerte est générée et l’état passe à Doit être
surveillé.
Pour plus d’informations, consultez Résolution des alertes liées aux domaines managés.
Quand un domaine managé présente l’état Doit être surveillé, la plateforme Azure peut
ne pas être en mesure de superviser, corriger, mettre à jour ou sauvegarder des
données régulièrement. Dans certains cas, comme avec une configuration réseau non
valide, les contrôleurs du domaine managé peuvent être inaccessibles.
L’état du domaine managé n’est pas sain et la supervision continue de l’intégrité

peut s’arrêter jusqu’à la résolution de l’alerte.
Les contrôleurs du domaine managé ne peuvent pas être corrigés ou mis à jour.
Les modifications effectuées dans Azure Active Directory peuvent ne pas être
synchronisées avec le domaine managé.
Des sauvegardes du domaine managé ne sont peut-être pas effectuées.
Si vous résolvez des alertes non critiques qui ont un impact sur le domaine
managé, l’intégrité doit revenir à l’état En cours d’exécution.
Les alertes critiques sont déclenchées en cas de problèmes de configuration où la
plateforme Azure est incapable d’accéder aux contrôleurs de domaine. Si ces
alertes critiques ne sont pas résolues dans les 15 jours, le domaine managé passe à
l’état Suspendu.
État Suspendu
Un domaine managé passe à l’état Suspendu pour l’une des raisons suivantes :
Une ou plusieurs alertes critiques n’ont pas été résolues au bout de 15 jours.
Les alertes critiques peuvent être dues à une configuration incorrecte qui
bloque l’accès aux ressources dont a besoin Azure AD DS. Par exemple, l’alerte
AADDS104 : erreur réseau n’a pas été résolue pendant plus de 15 jours dans le
domaine managé.
Il y a un problème de facturation avec l’abonnement Azure ou l’abonnement Azure
a expiré.
Les domaines managés sont suspendus quand la plateforme Azure ne parvient pas à
gérer, superviser, corriger ou sauvegarder le domaine. Un domaine managé reste à l’état
Suspendu pendant 15 jours. Pour conserver l’accès au domaine managé, résolvez
immédiatement les alertes critiques.
Le comportement suivant se produit quand un domaine managé se trouve dans l’état
Suspendu :
Les contrôleurs du domaine managé sont déprovisionnés et ne sont pas

accessibles dans le réseau virtuel.
L’accès LDAP sécurisé au domaine managé via Internet, s’il est activé, cesse de
fonctionner.
Des échecs se produisent lors de l’authentification auprès du domaine managé, de
la connexion aux machines virtuelles jointes à un domaine ou des connexions via
LDAP/LDAPS.
Les sauvegardes du domaine managé ne sont plus effectuées.
La synchronisation avec Azure AD cesse.
Comment savoir si votre domaine managé a été
suspendu ?
Vous voyez une alerte dans la page d’intégrité Azure AD DS du portail Azure qui indique
que le domaine est suspendu. L’état du domaine indique également Suspendu.
Restaurer un domaine suspendu

Pour restaurer l’intégrité d’un domaine managé qui est dans l’état Suspendu, procédez
comme suit :
1. Dans le portail Azure, recherchez et sélectionnez Services de domaine.

2. Choisissez votre domaine managé dans la liste, par exemple aaddscontoso.com,
puis sélectionnez Intégrité.
3. Sélectionnez l’alerte, par exemple AADDS503 ou AADDS504, selon la cause de la
suspension.
4. Choisissez le lien de résolution fourni dans l’alerte et suivez les étapes indiquées.
Un domaine managé peut uniquement être restauré à la date de la dernière sauvegarde.

La date de la dernière sauvegarde est affichée dans la page Intégrité du domaine
managé. Toutes les modifications apportées après la dernière sauvegarde ne pourront
pas être restaurées. Les sauvegardes de domaine managé sont stockées pendant 30
jours. Les sauvegardes datant de plus de 30 jours sont supprimées.
Une fois que vous avez résolu les alertes quand le domaine managé est dans l’état
Suspendu, formulez une demande de support Azure pour revenir à un état sain. Si la
sauvegarde date de moins de 30 jours, le support Azure peut restaurer le domaine
managé.
État Supprimé
Si un domaine managé reste à l’état Suspendu pendant 15 jours, il est supprimé. Ce
processus est irrécupérable.
Quand un domaine managé passe à l’état Supprimé, le comportement suivant se
produit :
Toutes les ressources et sauvegardes du domaine managé sont supprimées.

Vous ne pouvez pas restaurer le domaine managé. Vous devez créer un domaine
managé de remplacement pour réutiliser Azure AD DS.
Lorsque le domaine managé est supprimé, vous n’êtes plus facturé pour celui-ci.
Étapes suivantes
Pour assurer l’intégrité de votre domaine managé et réduire le risque de suspension,
découvrez comment résoudre les alertes liés à votre domaine managé.
Résoudre les problèmes de connectivité
LDAP sécurisé dans un domaine managé
Article • 01/06/2023
Les applications et services qui utilisent le protocole LDAP (Lightweight Directory Access
Protocol) pour communiquer avec Azure Active Directory Domain Services (Azure AD
DS) peuvent être configurés pour utiliser le protocole LDAP sécurisé. Un certificat
approprié et les ports réseau requis doivent être ouverts pour que le protocole LDAP
sécurisé fonctionne correctement.
Cet article vous aide à résoudre les problèmes liés à l’accès LDAP sécurisé dans Azure
AD DS.
Problèmes de connexion courants

Si vous ne parvenez pas à vous connecter à un domaine managé Azure AD DS à l’aide
du protocole LDAP sécurisé, passez en revue les étapes de résolution des problèmes
suivantes. Après chaque étape de résolution d’un problème, réessayez de vous
connecter au domaine managé :
La chaîne émetteur du certificat LDAP sécurisé doit être approuvée sur le client.
Vous pouvez ajouter l’autorité de certification racine au magasin de certificats
racines de confiance sur le client pour établir la relation d’approbation.
Assurez-vous d’exporter et d’appliquer le certificat aux ordinateurs clients.
Vérifiez que le certificat LDAP sécurisé pour votre domaine managé présente le
nom DNS dans l’attribut Objet ou Autres noms de l’objet.
Passez en revue les conditions requises pour le certificat LDAP sécurisé et créez
un certificat de remplacement si nécessaire.
Vérifiez que le client LDAP, tel que ldp.exe se connecte au point de terminaison
LDAP sécurisé à l’aide d’un nom DNS, et non de l’adresse IP.
Le certificat appliqué au domaine managé n’inclut pas les adresses IP du service,
mais uniquement les noms DNS.
Vérifiez le nom de DNS auquel la client LDAP se connecte. Il doit correspondre à
l’adresse IP publique pour le protocole LDAP sécurisé sur le domaine managé.
Si le nom DNS correspond à l’adresse IP interne, mettez à jour l’enregistrement
DNS pour qu’il corresponde à l’adresse IP externe.
Pour la connectivité externe, le groupe de sécurité réseau doit inclure une règle qui
autorise le trafic vers le port TCP 636 à partir d’Internet.
Si vous pouvez vous connecter au domaine managé à l’aide du protocole LDAP
sécurisé à partir de ressources directement connectées au réseau virtuel, mais
pas à partir de connexions externes, vous devez créer une règle de groupe de
sécurité réseau pour autoriser le trafic LDAP sécurisé.
Étapes suivantes
Si vous rencontrez toujours des problèmes, formulez une demande de support Azure
Problèmes connus : Alertes courantes et
résolutions dans Azure Active Directory
Domain Services
Article • 15/03/2023
En tant qu’élément central de l’identité et de l’authentification des applications, Azure

Active Directory Domain Services (Azure AD DS) rencontre parfois des problèmes. Si
vous rencontrez des problèmes, les alertes courantes et les étapes de dépannage
associées sont là pour vous aider à rétablir le service. De même, vous pouvez à tout
moment formuler une demande de support Azure pour bénéficier d’une aide
supplémentaire.
Cet article fournit des solutions aux problèmes fréquemment rencontrés dans Azure AD
DS.
AADDS100 : Annuaire manquant
Message d’alerte
L’annuaire Azure AD associé à votre domaine géré a peut-être été supprimé. Le domaine
géré n’est plus dans une configuration prise en charge. Microsoft ne peut pas surveiller,
gérer, mettre à jour et synchroniser votre domaine géré.
Résolution
Cette erreur se produit généralement quand un abonnement Azure est déplacé vers un
nouvel annuaire Azure AD et que l’ancien annuaire Azure AD associé à Azure AD DS est
supprimé.
Cette erreur est irrécupérable. Pour résoudre l’alerte, supprimez votre domaine managé,
puis recréez-le dans votre nouveau répertoire. Si vous rencontrez des problèmes lors de
la suppression du domaine managé, créez une demande de support Azure pour obtenir
une assistance supplémentaire.
AADDS101 : Azure AD B2C est en cours

d’exécution dans cet annuaire
Message d’alerte
Les services de domaine Azure AD ne peuvent pas être activés dans un annuaire Azure AD
B2C.
Résolution
Azure AD DS se synchronise automatiquement avec un annuaire Azure AD. Si l’annuaire
Azure AD est configuré pour B2C, Azure AD DS ne peut pas être déployé et synchronisé.
Pour utiliser Azure AD DS, vous devez recréer votre domaine managé dans un annuaire
non Azure AD B2C en effectuant les étapes suivantes :
1. Supprimez le domaine managé de votre annuaire Azure AD existant.

2. Créez un annuaire Azure AD qui n’est pas un annuaire Azure AD B2C.
3. Créez un domaine managé de remplacement.
L’intégrité du domaine managé se met automatiquement à jour dans les deux heures, et
l’alerte est supprimée.
AADDS103 : L’adresse est dans une plage

d’adresses IP publiques
Message d’alerte
La plage d’adresses IP pour le réseau virtuel dans lequel vous avez activé les services de
domaine Azure AD est dans une plage d’adresses IP publiques. Les services de domaine
Azure AD doivent être activés dans un réseau virtuel avec une plage d’adresses IP privées.
Cette configuration affecte la capacité de Microsoft à surveiller, gérer, mettre à jour et
synchroniser votre domaine managé.
Résolution
Avant de commencer, assurez-vous de bien comprendre les espaces d’adressage privé
IP v4 .
À l’intérieur d’un réseau virtuel, les machines virtuelles peuvent effectuer des requêtes
sur les ressources Azure qui se trouvent dans la même plage d’adresses IP que celles
configurées pour le sous-réseau. Si vous configurez une plage d’adresses IP publiques
pour un sous-réseau, les demandes routées au sein d’un réseau virtuel peuvent ne pas
atteindre les ressources web prévues. Cette configuration risque d’entraîner des erreurs
imprévisibles avec Azure AD DS.
７ Notes
Si vous êtes propriétaire de la plage d’adresses IP dans l’Internet configuré sur

votre réseau virtuel, vous pouvez ignorer cette alerte. Il est toutefois impossible
pour Azure AD Domain Services de respecter le contrat SLA avec cette
configuration, car elle peut entraîner des erreurs imprévisibles.
Pour résoudre cette alerte, supprimez votre domaine managé existant et recréez-le sur
un réseau virtuel avec une plage d’adresses IP privées. Ce processus entraîne des
perturbations, car le domaine managé est indisponible, et toutes les ressources
personnalisées que vous avez créées, comme les unités d’organisation ou les comptes
de service, sont perdues.
1. Supprimez le domaine managé de votre annuaire.

2. Pour mettre à jour la plage d’adresses IP du réseau virtuel, recherchez et
sélectionnez Réseau virtuel dans le portail Azure. Sélectionnez le réseau virtuel
pour Azure AD DS qui a une plage d’adresses IP publiques définie alors qu’il ne le
devrait pas.
3. Sous Paramètres, sélectionnez Espace d’adressage.
4. Mettez à jour la plage d’adresses en choisissant la plage d’adresses existante et en
la modifiant, ou en ajoutant une plage d’adresses supplémentaire. Vérifiez que la
nouvelle plage d’adresses est dans une plage d’adresses IP privées. Quand vous
êtes prêt, Enregistrez les modifications.
5. Sélectionnez Sous-réseaux dans la navigation de gauche.
6. Choisissez le sous-réseau que vous souhaitez modifier ou créez-en un
supplémentaire.
7. Mettez à jour ou spécifiez une plage d’adresses IP privées, puis Enregistrez vos
modifications.
8. Créez un domaine managé de remplacement. Veillez à sélectionner le sous-réseau
de réseau virtuel mis à jour avec une plage d’adresses IP privées.
AADDS106 : Votre abonnement Azure est

introuvable
Message d’alerte
Votre abonnement Azure associé à votre domaine managé a été supprimé. Azure AD
Domain Services nécessite un abonnement actif pour continuer à fonctionner
correctement.
Résolution
Azure AD DS nécessite un abonnement actif et ne peut pas être déplacé vers un autre
abonnement. Si l’abonnement Azure auquel le domaine managé a été associé est
supprimé, vous devez recréer un abonnement Azure et un domaine managé.
1. Créez un abonnement Azure.

2. Supprimez le domaine managé de votre annuaire Azure AD existant.
3. Créez un domaine managé de remplacement.
AADDS107 : Votre abonnement Azure est

désactivé
Message d’alerte
Votre abonnement Azure associé à votre domaine managé n’est pas actif. Azure AD
Domain Services nécessite un abonnement actif pour continuer à fonctionner
correctement.
Résolution
Azure AD DS nécessite un abonnement actif. Si l’abonnement Azure auquel le domaine
managé était associé n’est pas actif, vous devez le renouveler pour réactiver
l’abonnement.
1. Renouvelez votre abonnement Azure.

2. Une fois l’abonnement renouvelé, une notification Azure AD DS vous permet de
réactiver le domaine managé.
Quand le domaine managé est réactivé, l’intégrité du domaine managé se met

automatiquement à jour dans les deux heures et l’alerte est supprimée.
AADDS108 : Annuaires déplacés
d’abonnements
Message d’alerte
L’abonnement utilisé par Azure AD Domain Services a été déplacé dans un autre
répertoire. Azure AD Domain Services nécessite un abonnement actif dans le même
répertoire pour continuer à fonctionner correctement.
Résolution
Azure AD DS nécessite un abonnement actif et ne peut pas être déplacé vers un autre
abonnement. Si l’abonnement Azure auquel le domaine managé était associé est
déplacé, replacez l’abonnement dans l’annuaire précédent, ou supprimez votre domaine
managé de l’annuaire existant et créez un domaine managé de remplacement dans
l’abonnement choisi.
AADDS109 : Les ressources pour votre domaine

managé sont introuvables
Message d’alerte
Une ressource utilisée pour votre domaine managé a été supprimée. Cette ressource est
requise pour qu’Azure AD Domain Services fonctionne correctement.
Résolution
Azure AD DS crée des ressources supplémentaires pour fonctionner correctement, telles
que des adresses IP publiques, des interfaces de réseau virtuel et un équilibreur de
charge. Si l’une de ces ressources est supprimée, le domaine managé est dans un état
non pris en charge et il ne peut pas être géré. Pour plus d’informations sur ces
ressources, consultez Ressources réseau utilisées par Azure AD DS.
Cette alerte est générée quand l’une de ces ressources requises est supprimée. Si la
ressource a été supprimée il y a moins de quatre heures, il est possible que la
plateforme Azure puisse la recréer automatiquement. Les étapes suivantes décrivent
comment vérifier l’état d’intégrité et l’horodatage pour la suppression des ressources :
1. Dans le portail Azure, recherchez et sélectionnez Services de domaine. Choisissez
votre domaine managé, par exemple aaddscontoso.com.
2. Dans le volet de navigation gauche, sélectionnez Intégrité.
3. Dans la page d’intégrité, sélectionnez l’alerte avec l’ID AADDS109.
4. L’alerte a un horodatage correspondant au moment où elle a été initialement

détectée. Si cet horodatage est inférieur à quatre heures, la plateforme Azure peut
être en mesure de recréer automatiquement la ressource et de résoudre l’alerte
par elle-même.
Il peut arriver, pour différentes raisons, que l’alerte date de plus de quatre heures.
Si c’est le cas, vous pouvez supprimer le domaine managé, puis créer un domaine
managé de remplacement afin d’appliquer une correction immédiate, ou vous
pouvez ouvrir une demande de support pour corriger l’instance. Selon la nature du
problème, le support peut avoir besoin de faire une restauration à partir d’une
sauvegarde.
AADDS110 : Le sous-réseau associé à votre

domaine managé est plein
Message d’alerte
Le sous-réseau sélectionné pour le déploiement d’Azure AD Domain Services est plein et
n’a pas l’espace nécessaire pour le contrôleur de domaine supplémentaire qui doit être
créé.
Résolution
Le sous-réseau de réseau virtuel pour Azure AD DS nécessite suffisamment d’adresses IP
pour les ressources créées automatiquement. Cet espace d’adressage IP inclut la
nécessité de créer des ressources de remplacement en cas d’événement de
maintenance. Pour réduire le risque de manquer d’adresses IP disponibles, ne déployez
pas d’autres ressources (par exemple, vos propres machines virtuelles) sur le même
sous-réseau de réseau virtuel que le domaine managé.
Cette erreur est irrécupérable. Pour résoudre l’alerte, supprimez votre domaine managé
existant, puis recréez-le. Si vous rencontrez des problèmes lors de la suppression du
domaine managé, créez une demande de support Azure pour obtenir une assistance
supplémentaire.
AADDS111 : Principal du service non autorisé
Message d’alerte
Un principal de service qu’Azure AD Domain Services utilise pour gérer votre domaine
n’est pas autorisé à gérer les ressources de l’abonnement Azure. Le principal du service doit
obtenir les autorisations nécessaires pour gérer votre domaine managé.
Résolution
Certains principaux de service générés automatiquement sont utilisés afin de gérer et de
créer des ressources pour un domaine managé. Si les autorisations d’accès pour l’un de
ces principaux de service sont modifiées, le domaine ne pourra pas gérer correctement
les ressources. Les étapes suivantes montrent comment comprendre et accorder des
autorisations d’accès à un principal de service :
1. Apprenez-en davantage sur le contrôle d’accès en fonction du rôle Azure et sur la

façon d’accorder un accès aux applications dans le portail Azure.
2. Passez en revue l’accès dont dispose le principal de service avec l’ID abba844e-
bc0e-44b0-947a-dc74e5d09022 et accordez l’accès qui a été refusé précédemment.
AADDS112 : Nombre insuffisant d’adresses IP

dans le domaine managé
Message d’alerte
Nous avons détecté que le sous-réseau du réseau virtuel dans ce domaine n’a peut-être
pas suffisamment d’adresses IP. Azure AD Domain Services a besoin d’au moins deux
adresses IP disponibles au sein du sous-réseau où il est activé. Nous vous recommandons
d’avoir au moins 3 à 5 adresses IP auxiliaires au sein de ce sous-réseau. Cela peut se
produire si d’autres machines virtuelles sont déployées au sein du sous-réseau, épuisant
ainsi le nombre d’adresses IP disponibles, ou s’il existe une restriction sur le nombre
d’adresses IP disponibles dans le sous-réseau.
Résolution
Le sous-réseau de réseau virtuel pour Azure AD DS nécessite suffisamment d’adresses IP
pour les ressources créées automatiquement. Cet espace d’adressage IP inclut la
nécessité de créer des ressources de remplacement en cas d’événement de
maintenance. Pour réduire le risque de manquer d’adresses IP disponibles, ne déployez
pas d’autres ressources (par exemple, vos propres machines virtuelles) sur le même
sous-réseau de réseau virtuel que le domaine managé.
Pour résoudre cette alerte, supprimez votre domaine managé existant et recréez-le sur
un réseau virtuel avec une plage d’adresses IP suffisamment grande. Ce processus
entraîne des perturbations, car le domaine managé est indisponible, et toutes les
ressources personnalisées que vous avez créées, comme les unités d’organisation ou les
comptes de service, sont perdues.
1. Supprimez le domaine managé de votre annuaire.

2. Pour mettre à jour la plage d’adresses IP du réseau virtuel, recherchez et
sélectionnez Réseau virtuel dans le portail Azure. Sélectionnez le réseau virtuel du
domaine managé qui a la petite plage d’adresses IP.
3. Sous Paramètres, sélectionnez Espace d’adressage.
4. Mettez à jour la plage d’adresses en choisissant la plage d’adresses existante et en
la modifiant, ou en ajoutant une plage d’adresses supplémentaire. Vérifiez que la
nouvelle plage d’adresses IP est suffisamment grande pour la plage de sous-
réseau du domaine managé. Quand vous êtes prêt, Enregistrez les modifications.
5. Sélectionnez Sous-réseaux dans la navigation de gauche.
6. Choisissez le sous-réseau que vous souhaitez modifier ou créez-en un
supplémentaire.
7. Mettez à jour ou spécifiez une plage d’adresses IP suffisamment grande, puis
Enregistrez vos modifications.
8. Créez un domaine managé de remplacement. Veillez à sélectionner le sous-réseau
de réseau virtuel mis à jour avec une plage d’adresses IP suffisamment importante.
AADDS113 : Des ressources sont irrécupérables
Message d’alerte
Les ressources utilisées par Azure AD Domain Services ont été détectées dans un état
inattendu et ne peuvent pas être récupérées.
Résolution
Azure AD DS crée des ressources supplémentaires pour fonctionner correctement, telles
que des adresses IP publiques, des interfaces de réseau virtuel et un équilibreur de
charge. Si l’une de ces ressources est modifiée, le domaine managé est dans un état non
pris en charge et il ne peut pas être géré. Pour plus d’informations sur ces ressources,
consultez Ressources réseau utilisées par Azure AD DS.
Cette alerte est générée quand l’une de ces ressources requises est modifiée et ne peut
pas être récupérée automatiquement par Azure AD DS. Pour résoudre l’alerte, ouvrez
une demande de support Azure pour corriger l’instance.
AADDS114 : Sous-réseau non valide
Message d’alerte
Le sous-réseau sélectionné pour le déploiement d’Azure AD Domain Services n’est pas
valide et ne peut pas être utilisé.
Résolution
Cette erreur est irrécupérable. Pour résoudre l’alerte, supprimez votre domaine managé
existant, puis recréez-le. Si vous rencontrez des problèmes lors de la suppression du
domaine managé, créez une demande de support Azure pour obtenir une assistance
supplémentaire.
AADDS115 : Des ressources sont verrouillées
Message d’alerte
Il est impossible d’opérer sur une ou plusieurs des ressources réseau utilisées par le
domaine managé, car l’étendue cible a été verrouillée.
Résolution
Les verrous de ressources peuvent être appliqués aux ressources Azure pour en
empêcher la modification ou la suppression. Azure AD DS étant un service managé, la
plateforme Azure doit pouvoir apporter des modifications à la configuration. Si un
verrou de ressource est appliqué à certains des composants Azure AD DS, la plateforme
Azure ne peut pas effectuer ses tâches de gestion.
Pour rechercher des verrous de ressources sur les composants Azure AD DS et les
supprimer, effectuez les étapes suivantes :
1. Pour chacun des composants réseau du domaine managé de votre groupe de
ressources (par exemple, réseau virtuel, carte réseau ou adresse IP publique),
consultez les journaux des opérations sur le Portail Azure. Ces journaux des
opérations doivent indiquer la raison pour laquelle une opération échoue et où un
verrou de ressource est appliqué.
2. Sélectionnez la ressource où un verrou est appliqué puis, sous Verrous,
sélectionnez et supprimez le ou les verrous.
AADDS116 : Des ressources sont inutilisables
Message d’alerte
En raison d’une ou de plusieurs restrictions de stratégie, il est impossible d’opérer sur une
ou plusieurs des ressources réseau utilisées par le domaine managé.
Résolution
Les stratégies sont appliquées aux ressources et aux groupes de ressources Azure qui
contrôlent les actions de configuration autorisées. Azure AD DS étant un service
managé, la plateforme Azure doit pouvoir apporter des modifications à la configuration.
Si une stratégie est appliquée à certains des composants Azure AD DS, la plateforme
Azure risque de ne pas pouvoir effectuer ses tâches de gestion.
Pour rechercher les stratégies appliquées sur les composants Azure AD DS et les mettre
à jour, effectuez les étapes suivantes :
1. Pour chacun des composants réseau du domaine managé de votre groupe de

ressources (par exemple, réseau virtuel, carte NIC ou adresse IP publique),
consultez les journaux des opérations sur le Portail Azure. Ces journaux des
opérations doivent indiquer la raison pour laquelle une opération échoue et où
une stratégie restrictive est appliquée.
2. Sélectionnez la ressource où une stratégie est appliquée puis, sous Stratégies,
sélectionnez et modifiez la stratégie pour qu’elle soit moins restrictive.
AADDS120 : le domaine managé a rencontré

une erreur lors de l’intégration d’un ou
plusieurs attributs personnalisés
Message d’alerte
Les propriétés d’extension Azure AD suivantes n’ont pas été correctement intégrées comme
qu’attributs personnalisés pour la synchronisation. Cela peut se produire si une propriété
est en conflit avec le schéma intégré : [extensions]
Résolution
２ Avertissement
Si le LDAPName d’un attribut personnalisé est en conflit avec un attribut de schéma

intégré AD existant, il ne peut pas être intégré et entraîne une erreur. Contactez le
Support Microsoft si votre scénario est bloqué. Pour plus d’informations, consultez
Intégration d’attributs personnalisés .
Passez en revue l’alerte Intégrité Azure AD DS, puis consultez les propriétés d’extension
Azure AD qui n’ont pas pu être intégrées. Accédez à la page Attributs personnalisés
pour rechercher le LDAPName Azure AD DS attendu de l’extension. Veillez à ce que
LDAPName ne soit pas en conflit avec un autre attribut de schéma AD ou qu’il s’agit de
l’un des attributs AD intégrés autorisés.
Suivez ensuite cette procédure pour réessayer d’intégrer l’attribut personnalisé dans la
page Attributs personnalisés :
1. Sélectionnez les attributs ayant échoué, puis cliquez sur Supprimer et Enregistrer.
2. Attendez la suppression de l’alerte d’intégrité ou vérifiez que les attributs
correspondants ont été supprimés de l’unité d’organisation
AADDSCustomAttributes d’une machine virtuelle jointe à un domaine.
3. Sélectionnez Ajouter, puis choisissez à nouveau les attributs souhaités, puis cliquez
sur Enregistrer.
Une fois l’intégration réussie, Azure AD DS remplit à nouveau les utilisateurs et les
groupes synchronisés avec les valeurs d’attribut personnalisées intégrées. Les valeurs
d’attribut personnalisées s’affichent progressivement, en fonction de la taille du
locataire. Pour vérifier l’état du remplissage, accédez à Intégrité Azure AD DS, puis
vérifiez que l’horodatage de Synchronisation avec le moniteur Azure AD a été mis à
jour au cours de la dernière heure.
AADDS500 : La synchronisation ne parvient pas

à se terminer depuis un certain temps
Message d’alerte
La dernière synchronisation du domaine managé avec Azure AD a eu lieu le [date]. Les
utilisateurs sont peut-être dans l’impossibilité de se connecter au domaine managé, ou les
appartenances aux groupes ne sont peut-être pas synchronisées avec Azure AD.
Résolution
Vérifiez l’intégrité d’Azure AD DS pour toutes les alertes qui indiquent des problèmes au
niveau de la configuration du domaine managé. Les problèmes de configuration réseau
peuvent bloquer la synchronisation à partir d’Azure AD. Si vous êtes en mesure de
résoudre les alertes qui indiquent un problème de configuration, attendez deux heures,
puis vérifiez à nouveau si la synchronisation s’est terminée avec succès.
Voici quelques raisons courantes qui provoquent l’arrêt de la synchronisation dans un

domaine managé :
La connectivité réseau requise est bloquée. Pour savoir comment vérifier si le

réseau virtuel Azure présente des problèmes et connaître les exigences, consultez
Résolution des problèmes relatifs aux groupes de sécurité réseau et Exigences
réseau d’Azure AD DS.
La synchronisation de mot de passe n’a pas été configurée ou ne s’est pas
terminée avec succès quand le domaine managé a été déployé. Vous pouvez
configurer la synchronisation de mot de passe pour les utilisateurs du cloud
uniquement ou pour les utilisateurs hybrides locaux.
AADDS501 : Il n’y a pas eu de sauvegarde

depuis un certain temps
Message d’alerte
La dernière sauvegarde du domaine managé a eu lieu le [date].
Résolution
Vérifiez l’intégrité d’Azure AD DS pour les alertes qui indiquent des problèmes avec la
configuration du domaine géré. Les problèmes liés à la configuration réseau peuvent
empêcher la plateforme Azure d’effectuer des sauvegardes. Si vous êtes en mesure de
résoudre les alertes qui indiquent un problème de configuration, attendez deux heures,
puis vérifiez à nouveau si la synchronisation s’est terminée avec succès.
AADDS503 : Suspension en raison de
l’abonnement désactivé
Message d’alerte
Le domaine managé est suspendu, car l’abonnement Azure associé au domaine n’est pas
actif.
Résolution
２ Avertissement
Si un domaine managé est suspendu pendant une période prolongée, il y a un

risque qu’il soit supprimé. Résolvez le motif de suspension le plus rapidement
possible. Pour plus d’informations, consultez Présentation des états suspendus
pour Azure AD DS.
Azure AD DS nécessite un abonnement actif. Si l’abonnement Azure auquel le domaine

managé était associé n’est pas actif, vous devez le renouveler pour réactiver
l’abonnement.
1. Renouvelez votre abonnement Azure.

2. Une fois l’abonnement renouvelé, une notification Azure AD DS vous permet de
réactiver le domaine managé.
Quand le domaine managé est réactivé, l’intégrité du domaine managé se met

automatiquement à jour dans les deux heures et l’alerte est supprimée.
AADDS504 : Suspension en raison d’une

configuration non valide
Message d’alerte
Le domaine managé est suspendu en raison d’une configuration non valide. Le service n’a
pas pu gérer, corriger ou mettre à jour les contrôleurs du domaine managé depuis un
certain temps.
Résolution
２ Avertissement

pour Azure AD DS.
configuration du domaine géré. Si vous êtes en mesure de résoudre les alertes qui
indiquent un problème de configuration, attendez deux heures, puis vérifiez de nouveau
que la synchronisation est terminée. Quand vous êtes prêt, créez une demande de
support Azure pour réactiver le domaine managé.
AADDS600 : alertes d’intégrité non résolues

pendant 30 jours
Message de l'alerte
Microsoft ne peut pas gérer les contrôleurs de domaine de ce domaine géré en raison
d’alertes d’intégrité non résolues [ID]. Cela bloque les mises à jour de sécurité critiques
ainsi qu’une migration planifiée vers Windows Server 2019 pour ces contrôleurs de
domaine. Suivez les étapes de l’alerte pour résoudre le problème. L’échec de la résolution
de ce problème dans les 30 jours entraînera la suspension du domaine managé.
Résolution
２ Avertissement

pour Azure AD DS.
configuration du domaine géré. Si vous parvenez à résoudre les alertes indiquant un
problème de configuration, attendez six heures et vérifiez à nouveau si l’alerte a été
supprimée. Ouvrez une demande de support Azure si vous avez besoin d’aide.
Étapes suivantes
Problèmes connus : Alertes de configuration réseau
dans Azure Active Directory Domain Services
Article • 01/06/2023
Pour une bonne communication entre les applications et services et Azure Active Directory Domain Services (Azure AD
DS), des ports réseau spécifiques doivent être ouverts afin d'autoriser le trafic. Dans Azure, vous contrôlez le flux du
trafic à l’aide de groupes de sécurité réseau. L’état d’intégrité d’un domaine managé Azure AD DS affiche une alerte si
les règles de groupe de sécurité réseau requises ne sont pas respectées.
Cet article vous aide à comprendre et à résoudre les alertes courantes découlant de problèmes de configuration des
groupes de sécurité réseau.
Alerte AADDS104 : Erreur réseau
Message d’alerte
Microsoft ne peut pas atteindre les contrôleurs de domaine pour ce domaine géré. Cela peut se produire si un groupe de
sécurité réseau (NSG) configuré sur votre réseau virtuel bloque l’accès à un domaine géré. Une autre raison possible est
s’il existe un itinéraire défini par l’utilisateur qui bloque le trafic entrant à partir d’Internet.
Les règles de groupe de sécurité réseau non valides sont la cause la plus courante d’erreurs réseau pour Azure AD DS.
Le groupe de sécurité réseau pour le réseau virtuel doit autoriser l’accès à des ports et protocoles spécifiques. Si ces
ports sont bloqués, la plateforme Azure ne peut pas surveiller ou mettre à jour le domaine managé. La synchronisation
entre le répertoire Azure AD et Azure AD DS est également impactée. Veillez à garder ces ports par défaut ouverts
pour éviter les interruptions de service.
Règles de sécurité par défaut

Les règles de sécurité de trafic entrant et sortant par défaut suivantes sont appliquées au groupe de sécurité réseau
d'un domaine managé. Ces règles sécurisent Azure AD DS et permettent à la plateforme Azure de surveiller, de gérer
et de mettre à jour le domaine managé.
Règles de sécurité de trafic entrant
Priority Nom Port Protocol Source Destination Action
301 AllowPSRemoting 5986 TCP AzureActiveDirectoryDomainServices Quelconque Allow
201 AllowRD 3389 TCP CorpNetSaw Quelconque Deny1
65 000 AllVnetInBound Quelconque Quelconque VirtualNetwork VirtualNetwork Allow
65 001 AllowAzureLoadBalancerInBound Quelconque Quelconque AzureLoadBalancer Quelconque Allow
65 500 DenyAllInBound Quelconque Quelconque Quelconque Quelconque Deny
1 Facultatif
pour le débogage. « Allow » si nécessaire pour le dépannage avancé.
７ Notes
Vous pouvez configurer LDAP sécurisé pour disposer d'une règle supplémentaire autorisant le trafic entrant.
Cette règle supplémentaire est requise pour une communication LDAPS correcte.
Règles de sécurité de trafic entrant
Priority Nom Port Protocol Source Destination Action
65 000 AllVnetOutBound Quelconque Quelconque VirtualNetwork VirtualNetwork Allow
65 001 AllowAzureLoadBalancerOutBound Quelconque Quelconque Quelconque Internet Allow
65 500 DenyAllOutBound Quelconque Quelconque Quelconque Quelconque Deny
７ Notes
Azure AD DS requiert un accès sortant non restreint depuis le réseau virtuel. Nous vous déconseillons de créer
d'autres règles de groupe de sécurité réseau pouvant restreindre l’accès sortant pour le réseau virtuel.
Vérifier et modifier les règles de sécurité existantes

Pour vérifier les règles de sécurité existantes et vous assurer que les ports par défaut sont ouverts, procédez comme
suit :
1. Dans le Portail Azure, recherchez et sélectionnez Groupes de sécurité réseau.
2. Sélectionnez le groupe de sécurité réseau associé à votre domaine managé, par exemple AADDS-contoso.com-
NSG.
3. Sur la page Vue d'ensemble, les règles de sécurité de trafic entrant et sortant existantes s’affichent.
Examinez les règles de trafic entrant et sortant, puis comparez-les à la liste des règles requises dans la section
précédente. Si nécessaire, sélectionnez et supprimez toutes les règles personnalisées qui bloquent le trafic requis.
Si l’une des règles requises est manquante, ajoutez une règle dans la section suivante.
Après avoir ajouté ou supprimé des règles pour autoriser le trafic requis, l’intégrité du domaine managé se met
automatiquement à jour dans les deux heures, et l’alerte est supprimée.
Ajouter une règle de sécurité

Pour ajouter une règle de sécurité manquante, procédez comme suit :

2. Sélectionnez le groupe de sécurité réseau associé à votre domaine managé, par exemple AADDS-contoso.com-
NSG.
3. Sous Paramètres dans le panneau de gauche, cliquez sur Règles de sécurité de trafic entrant ou Règles de sécurité
de trafic sortant selon la règle à ajouter.
4. Sélectionnez Ajouter, puis créez la règle requise en fonction du port, du protocole, de la direction, etc. Lorsque
vous êtes prêt, sélectionnez OK.
L’ajout et l’affichage de la règle de sécurité dans la liste prend quelques instants.
Étapes suivantes
Si vous rencontrez toujours des problèmes, formulez une demande de support Azure pour bénéficier d’une aide
supplémentaire.
Problèmes connus : Alertes liées aux
principaux de service dans Azure AD
Domain Services
Article • 01/06/2023
Les principaux de service sont des applications que la plateforme Azure utilise pour
gérer, mettre à jour et tenir à jour un domaine managé Azure AD DS (Azure Active
Directory Domain Services). Si un principal de service est supprimé, les fonctionnalités
dans le domaine managé Azure AD DS sont affectées.
Cet article vous aide à résoudre les alertes liées à la configuration des principaux de
service.
Alerte AADDS102 : Principal de service

introuvable
Message d’alerte
Un principal de service requis pour que les services de domaine Azure AD fonctionnent
correctement a été supprimé de votre annuaire Azure AD. Cette configuration affecte la
capacité de Microsoft à surveiller, gérer, mettre à jour et synchroniser votre domaine
managé.
Si un principal de service requis est supprimé, la plateforme Azure ne peut pas effectuer
de tâches de gestion automatisées. Le domaine managé risque de ne pas appliquer
correctement les mises à jour ou de ne pas effectuer de sauvegardes.
Vérifier les principaux de service manquants

Pour vérifier quel est le principal de service manquant à recréer, procédez ainsi :

navigation gauche.

3. Recherchez chacun des ID d’applications suivants. Pour Azure Global, recherchez la

valeur AppId 2565bd9d-da50-47d4-8b85-4c97f669dc36. Pour les autres clouds
Azure, recherchez la valeur AppId 6ba9a5d4-8456-4118-b521-9c5ca10cdf84. Si
aucune application existante n’est trouvée, suivez les étapes de Résolution pour
créer le principal de service ou réinscrivez l’espace de noms.
ID de l'application Résolution
2565bd9d-da50-47d4-8b85-4c97f669dc36 Recréer un principal de service manquant
443155a6-77f3-45e3-882b-22b3a8d431fb Réinscrire l’espace de noms Microsoft.AAD
abba844e-bc0e-44b0-947a-dc74e5d09022 Réinscrire l’espace de noms Microsoft.AAD
d87dcbc6-a371-462e-88e3-28ad15ec4e64 Réinscrire l’espace de noms Microsoft.AAD
Recréer un principal de service manquant

Si l’ID d’application 2565bd9d-da50-47d4-8b85-4c97f669dc36 est manquant dans votre
annuaire Azure AD dans Azure Global, effectuez les étapes suivantes avec Azure AD
PowerShell. Pour les autres clouds Azure, utilisez la valeur AppId 6ba9a5d4-8456-4118-
b521-9c5ca10cdf84. Pour plus d’informations, consultez Azure AD PowerShell.
1. Si nécessaire, installez le module Azure AD PowerShell, puis importez-le de la façon

suivante :
PowerShell
Install-Module AzureAD
Import-Module AzureAD
2. Maintenant, recréez le principal de service à l’aide de l’applet de commande New-

AzureAdServicePrincipal :
PowerShell
New-AzureAdServicePrincipal -AppId "2565bd9d-da50-47d4-8b85-

4c97f669dc36"
Réinscrire l’espace de noms Microsoft AAD

Si l’ID d’application 443155a6-77f3-45e3-882b-22b3a8d431fb, abba844e-bc0e-44b0-
947a-dc74e5d09022 ou d87dcbc6-a371-462e-88e3-28ad15ec4e64 est manquant dans
votre annuaire Azure AD, effectuez les étapes suivantes pour réinscrire le fournisseur de
ressources Microsoft.AAD :
1. Dans le portail Azure, recherchez et sélectionnez Abonnements.

2. Choisissez l’abonnement associé à votre domaine managé.
3. Dans la navigation de gauche, choisissez Fournisseurs de ressources.
4. Recherchez Microsoft.AAD, puis sélectionnez Réinscrire.
Alerte AADDS105 : La synchronisation du mot

de passe est obsolète
Message d’alerte
Le principal du service dont l’ID d’application est « d87dcbc6-a371-462e-88e3-
28ad15ec4e64 » a été supprimé, puis recréé. Cette nouvelle création laisse des
autorisations incohérentes sur les ressources Azure AD Domain Services nécessaires pour
traiter votre domaine managé. La synchronisation des mots de passe dans votre domaine
managé pourrait en être affectée.
Azure AD DS synchronise automatiquement les comptes d’utilisateur et les informations

d’identification à partir d’Azure AD. En cas de problème avec l’application Azure AD
utilisée pour ce processus, la synchronisation des informations d’identification entre
Azure AD DS et Azure AD échoue.
Résolution
Pour recréer l’application Azure AD utilisée pour la synchronisation des informations
d’identification, effectuez les étapes suivantes avec Azure AD PowerShell. Pour plus
d’informations, consultez Installer Azure AD PowerShell.
1. Si nécessaire, installez le module Azure AD PowerShell, puis importez-le de la façon

suivante :
PowerShell
Install-Module AzureAD
Import-Module AzureAD
2. Maintenant, supprimez l’ancienne application et l’ancien objet à l’aide des applets

de commande PowerShell suivantes :
PowerShell
$app = Get-AzureADApplication -Filter "IdentifierUris eq
'https://sync.aaddc.activedirectory.windowsazure.com'"
Remove-AzureADApplication -ObjectId $app.ObjectId
$spObject = Get-AzureADServicePrincipal -Filter "DisplayName eq 'Azure

AD Domain Services Sync'"
Remove-AzureADServicePrincipal -ObjectId $spObject
Une fois que vous avez supprimé les deux applications, la plateforme Azure les recrée
automatiquement et tente de reprendre la synchronisation de mot de passe. L’intégrité
du domaine managé se met automatiquement à jour dans les deux heures, et l’alerte est
supprimée.
Étapes suivantes
Problèmes connus : Alertes du
protocole LDAP sécurisé dans Azure
Article • 01/06/2023
Les applications et services qui utilisent le protocole LDAP (Lightweight Directory Access
Protocol) pour communiquer avec Azure Active Directory Domain Services (Azure AD
DS) peuvent être configurés pour utiliser le protocole LDAP sécurisé. Un certificat
approprié et les ports réseau requis doivent être ouverts pour que le protocole LDAP
sécurisé fonctionne correctement.
Cet article vous aide à comprendre et à résoudre les alertes courantes avec un accès
LDAP sécurisé dans Azure AD DS.
AADDS101 : Configuration du réseau LDAP

sécurisé
Message d’alerte
Le protocole LDAP sécurisé sur Internet est activé pour le domaine managé. Toutefois,
l’accès au port 636 n’est pas verrouillé à l’aide d’un Groupe de sécurité réseau (NSG). Cela
peut exposer les comptes d’utilisateurs du domaine managé à des attaques de mots de
passe par force brute.
Résolution
Lorsque vous activez le protocole LDAP sécurisé, il est recommandé de créer des règles
supplémentaires qui restreignent l’accès LDAPS entrant à des adresses IP spécifiques.
Ces règles protègent le domaine managé contre les attaques par force brute. Pour
mettre à jour le groupe de sécurité réseau afin de restreindre l’accès au port TCP 636
pour le protocole LDAP sécurisé, procédez comme suit :

2. Sélectionnez le groupe de sécurité réseau associé à votre domaine managé, par
exemple AADDS-contoso.com-NSG, puis sélectionnez Règles de sécurité de trafic
entrant
3. Sélectionnez + Ajouter afin de créer une règle pour le port TCP 636. Si nécessaire,
sélectionnez Avancé dans la fenêtre pour créer une règle.
4. Pour la Source, sélectionnez Adresses IP dans le menu déroulant. Entrez les
adresses IP sources auxquelles vous souhaitez accorder l’accès pour le trafic LDAP
sécurisé.
5. Choisissez Toutes en tant que Destination, puis entrez 636 dans Plages de ports de
destination.
6. Définissez Protocole sur TCP et Action sur Autoriser.
7. Spécifiez la priorité de la règle, puis saisissez un nom tel que RestrictLDAPS.
8. Lorsque vous êtes prêt, sélectionnez Ajouter pour créer la règle.
 Conseil
Le port TCP 636 n’est pas la seule règle nécessaire au bon fonctionnement d’Azure
AD DS. Pour en savoir plus, consultez Groupes de sécurité réseau et ports Azure
AD DS requis.
AADDS502 : Expiration du certificat LDAP

sécurisé
Message d’alerte
Le certificat LDAP sécurisé pour le domaine managé expirera le [date]].
Résolution
Créez un certificat LDAP sécurisé de remplacement en suivant les étapes de création
d’un certificat pour le protocole LDAP sécurisé. Appliquez le certificat de remplacement
à Azure AD DS et distribuez-le à tous les clients qui se connectent à l’aide du protocole
LDAP sécurisé.
Étapes suivantes
Az.ADDomainServices
Référence
Microsoft Azure PowerShell : applets de commande AdDomainServices
Service de domaine Active Directory

Get-AzADDomainService The Get Domain Service operation retrieves a json
representation of the Domain Service.
New-AzADDomainService The Create Domain Service operation creates a new

domain service with the specified parameters. If the
specific service already exists, then any patchable
properties will be updated and any immutable properties
will remain unchanged.
New- Create an in-memory object for ForestTrust.

AzADDomainServiceForestTrustObject
New- Create an in-memory object for ReplicaSet.

AzADDomainServiceReplicaSetObject
Remove-AzADDomainService The Delete Domain Service operation deletes an existing

Domain Service.
Update-AzADDomainService The Update Domain Service operation can be used to

update the existing deployment. The update call only
supports the properties listed in the PATCH body.
Définitions de stratégie intégrées
d’Azure Policy pour Azure Active
Article • 08/08/2023
Cette page est un index des définitions de stratégie intégrées d’Azure Policy pour Azure
Active Directory Domain Services. Pour obtenir des éléments intégrés supplémentaires
d’Azure Policy pour d’autres services, consultez Définitions intégrées d’Azure Policy.
Le nom de chaque définition de stratégie intégrée est un lien vers la définition de la

stratégie dans le portail Azure. Utilisez le lien figurant dans la colonne Version pour voir
la source dans le dépôt GitHub Azure Policy .

Nom Description Effet(s) Version
(Portail Azure) (GitHub)
Les domaines Utilisez le mode TLS 1.2 uniquement pour vos Audit, Refuser, 1.1.0
gérés par domaines gérés. Par défaut, Azure AD Domain Désactivé
Azure Active Services permet d’utiliser des méthodes de
Directory chiffrement comme NTLM v1 et TLS v1. Certaines
Domain applications héritées peuvent avoir besoin de ces
Services chiffrements, mais étant considérés comme
doivent utiliser faibles, vous pouvez les désactiver si vous n’en
le mode avez pas l’utilité. Quand le mode TLS 1.2
TLS 1.2 uniquement est activé, les clients effectuant une
uniquement demande qui n’utilise pas TLS 1.2 échouent. Pour
en savoir plus, rendez-vous sur
https://docs.microsoft.com/azure/active-
directory-domain-services/secure-your-domain.
Azure Active Azure Private Link vous permet de connecter vos AuditIfNotExists, 1.0.0
Directory doit réseaux virtuels aux services Azure sans Désactivé
utiliser une adresse IP publique au niveau de la source ou de
liaison privée la destination. La plateforme Private Link gère la
pour accéder connectivité entre le consommateur et les
aux services services sur le réseau principal Azure. En
Azure mappant des points de terminaison privés à
Azure AD, vous pouvez réduire les risques de
fuite de données. Pour en savoir plus, rendez-
vous à l’adresse suivante :
https://aka.ms/privateLinkforAzureADDocs . Il
Nom Description Effet(s) Version
(Portail Azure) (GitHub)
doit être utilisé uniquement à partir de réseaux

virtuels isolés vers des services Azure, sans accès
à Internet ou à d’autres services (M365).
Configurer Les points de terminaison privés vous DeployIfNotExists, 1.0.0

Private Link permettent de connecter vos réseaux virtuels aux Désactivé
pour Azure AD services Azure sans adresse IP publique au
avec des niveau de la source ou de la destination. En
points de mappant des points de terminaison privés à
terminaison Azure AD, vous pouvez réduire les risques de
privés fuite de données. Pour en savoir plus, rendez-
vous à l’adresse suivante :
https://aka.ms/privateLinkforAzureADDocs . Il
doit être utilisé uniquement à partir de réseaux
virtuels isolés vers des services Azure, sans accès
à Internet ou à d’autres services (M365).
Étapes suivantes
Consultez les définitions intégrées dans le dépôt Azure Policy de GitHub .
Consultez la Structure de définition Azure Policy.
Consultez la page Compréhension des effets de Policy.
Foire aux questions (FAQ) sur
Azure Active Directory (AD)
Domain Services
Forum aux questions
Cette page répond aux questions fréquemment posées sur les services de domaine
Configuration
Puis-je créer plusieurs domaines managés pour
un seul annuaire Azure AD ?
Non. Vous ne pouvez créer qu’un seul domaine managé pris en charge par Azure AD
Domain Services par annuaire Azure AD.
Puis-je activer Azure AD Domain Services dans

un réseau virtuel Classic ?
Les réseaux virtuels classiques ne sont pas pris en charge.
Pour plus d’informations, consultez l’annonce de dépréciation officielle .
Puis-je activer les services de domaine Azure AD

dans un réseau virtuel Azure Resource
Manager ?
Oui. Azure AD Domain Services peut être activé dans un réseau virtuel Azure Resource
Manager. Les réseaux virtuels Azure classiques ne sont plus disponibles quand vous
créez un domaine managé.
Puis-je activer Azure Active Directory Domain

Services dans un abonnement Azure CSP
(fournisseur de solutions de Cloud) ?
Oui. Pour plus d'informations, consultez Activer Azure Active Directory Domain Services
dans les abonnements Azure CSP.

dans un annuaire Azure AD fédéré ? Je ne
synchronise pas les hachages de mot de passe
avec Azure AD. Puis-je activer les services de
domaine Azure AD pour cet annuaire ?
Non. Les services de domaine Azure AD ont besoin d’un accès aux hachages de mot de
passe des comptes d’utilisateur afin d’authentifier les utilisateurs via NTLM ou Kerberos.
Dans un annuaire fédéré, les hachages de mot de passe ne sont pas stockés dans
l’annuaire Azure AD. Par conséquent, les services de domaine Azure AD ne fonctionnent
pas avec ces annuaires Azure AD.
Toutefois, si vous utilisez Azure AD Connect pour la synchronisation de hachage du mot

de passe, vous pouvez utiliser Azure AD Domain Services parce que les valeurs de
hachage du mot de passe sont stockées dans Azure AD.
Puis-je rendre les services de domaine Azure AD

disponibles dans plusieurs réseaux virtuels au
sein de mon abonnement ?
Le service lui-même ne prend pas directement en charge ce scénario. Votre domaine
managé n’est disponible que dans un seul réseau virtuel à la fois. Toutefois, vous pouvez
configurer la connectivité entre plusieurs réseaux virtuels afin d’exposer les services de
domaine Azure AD à d’autres réseaux virtuels. Pour plus d’informations, consultez
connexion aux réseaux virtuels dans Azure à l’aide de passerelles VPNou homologation
de réseaux virtuels.

à l’aide de PowerShell ?
Oui. Pour plus d'informations, consultez Activer Azure Active Directory Domain Services
à l’aide de PowerShell.
Puis-je activer Azure AD Domain Services à l’aide
d’un modèle Resource Manager ?
Oui, vous pouvez créer un domaine managé Azure AD Domain Services à l’aide d’un
modèle Resource Manager. Un principal de service et un groupe Azure AD pour
l'administration doivent être créés à l'aide du portail Azure ou d'Azure PowerShell avant
le déploiement du modèle. Pour plus d’informations, consultez Créer un domaine
managé Azure Active Directory Domain Services à l’aide d’un modèle Resource
Manager. Lorsque vous créez un domaine managé Azure AD Domain Services dans le
portail Azure, vous avez aussi la possibilité d'exporter le modèle pour l'utiliser avec
d’autres déploiements.
Puis-je ajouter des contrôleurs de domaine à un

domaine géré par les services de domaine
Azure AD ?
Non. Le domaine fourni par les services de domaine Azure AD est un domaine géré.
Vous n’avez pas besoin d’approvisionner, de configurer ou de gérer des contrôleurs de
domaine pour ce domaine. Ces activités de gestion sont fournies en tant que service par
Microsoft. Par conséquent, vous ne pouvez pas ajouter de contrôleurs de domaine
supplémentaires (en lecture/écriture ou en lecture seule) pour le domaine géré.
Les utilisateurs invités de mon annuaire peuvent-

ils utiliser Azure Active Directory Domain
Services ?
Non. Les utilisateurs invités de votre annuaire Azure AD qui utilisent le processus
d’invitation Azure AD B2B sont synchronisés avec votre domaine managé Azure AD
Domain Services. Toutefois, les mots de passe de ces utilisateurs ne sont pas stockés
dans votre annuaire Azure AD. C’est pourquoi Azure AD Domain Services n’a aucun
moyen de synchroniser les hachages NTLM et Kerberos pour ces utilisateurs dans votre
domaine managé. De tels utilisateurs ne peuvent pas se connecter ou joindre des
ordinateurs au domaine géré.
Une approbation de forêt bidirectionnelle peut-

elle être créée entre Azure AD DS et une forêt
locale ?
Non. Un domaine managé prend en charge jusqu’à cinq approbations de forêt sortante
unidirectionnelle vers des forêts locales.
Puis-je déplacer un domaine managé ?

Après avoir créé un domaine managé Azure AD Domain Services, vous ne pouvez pas le
déplacer vers un autre abonnement, groupe de ressources ou région. Pour résoudre ce
problème, vous pouvez supprimer le domaine managé à l’aide de PowerShell ou du
portail Azure, et le recréer avec la configuration souhaitée. Aucune opération de
restauration ne peut être fournie lors de la recréation du domaine managé.
Puis-je renommer un nom de domaine Azure AD

Domain Services existant ?
Non. Une fois que vous avez créé un domaine managé Azure AD Domain Services, vous
ne pouvez pas modifier le nom de domaine DNS. Choisissez le nom de domaine DNS
avec précaution lorsque vous créez le domaine managé. Pour savoir quels éléments
prendre en compte lorsque vous choisissez le nom de domaine DNS, consultez le
tutoriel pour créer et configurer un domaine managé Azure AD Domain Services.
Azure AD Domain Services inclut-il des options

de haute disponibilité ?
Oui. Chaque domaine managé Azure Active Directory Domain Services comprend deux
contrôleurs de domaine. Vous ne gérez pas ces contrôleurs de domaine et ne vous y
connectez pas, car ils font partie du service géré. Si vous déployez Azure AD Domain
Services dans une région qui prend en charge les Zones de disponibilité, les contrôleurs
de domaine sont répartis entre les zones. Dans les régions qui ne prennent pas en
charge les Zones de disponibilité, les contrôleurs de domaine sont distribués entre les
Groupes à haute disponibilité. Vous ne disposez d’aucune option de configuration ou
d’aucun contrôle de gestion sur cette distribution. Pour plus d’informations, voir Options
de disponibilité pour les machines virtuelles dans Azure.
Administration et opérations
Puis-je me connecter au contrôleur de domaine
de mon domaine géré à l’aide du Bureau à
distance ?
Non. Vous n’êtes pas autorisé à vous connecter aux contrôleurs de domaine pour le
domaine géré, via le Bureau à distance. Les membres du groupe Administrateurs Azure
AD DC peuvent administrer le domaine managé à l’aide des outils d’administration AD,
tels que le centre d’administration d’Active Directory (ADAC) ou AD PowerShell. Ces
outils sont installés à l’aide de la fonctionnalité Outils d’administration de serveur distant
sur un serveur Windows joint au domaine géré. Pour plus d’informations, consultez
Créer une machine virtuelle de gestion pour configurer et administrer un domaine
managé Azure AD Domain Services.
J’ai activé Azure AD Domain Services. Quel

compte d’utilisateur dois-je utiliser pour joindre
des ordinateurs à ce domaine ?
Tout compte d’utilisateur faisant partie du domaine managé peut joindre une machine
virtuelle. Les membres du groupe Administrateurs Azure AD DC disposent d’un accès
Bureau à distance aux machines qui ont été jointes au domaine managé.
Est-ce que je dispose des privilèges

d’administrateur de domaine pour le domaine
géré fourni par les services de domaine
Azure AD ?
Non. Vous ne disposez pas des privilèges d’administrateur sur le domaine géré. Les
privilèges Administrateur de domaine et Administrateur d’entreprise ne sont pas
disponibles pour vous dans le domaine. Les membres des groupes d’administrateurs de
domaine ou d’administrateurs d’entreprise de votre instance Active Directory locale ne
se voient accorder aucun privilège d’administrateur de domaine ou d’entreprise sur le
domaine managé.
Puis-je modifier les appartenances aux groupes à

l’aide de LDAP ou d’autres outils
d’administration AD sur des domaines gérés ?
Il n’est pas possible de modifier les utilisateurs et les groupes synchronisés à partir
d’Azure Active Directory sur Azure AD Domain Services, car leur source d’origine est
Azure Active Directory. Cela comprend le déplacement des utilisateurs ou des groupes
de l’unité d’organisation managée Utilisateurs AADDC vers une unité d’organisation
personnalisée. En revanche, tout utilisateur ou groupe provenant du domaine managé
peut être modifié.
Combien de temps faut-il pour que les

modifications que j’apporte à mon annuaire
Azure AD soient visibles dans mon domaine géré
?
Les modifications apportées à votre annuaire Azure AD à l’aide de l’interface utilisateur
d’Azure Active Directory ou de PowerShell sont synchronisées automatiquement avec
votre domaine géré. Ce processus de synchronisation se produit en arrière-plan. Il n’y a
pas de période définie pour cette synchronisation pour effectuer toutes les
modifications d’objets.
Puis-je étendre le schéma du domaine géré

fourni par les services de domaine Azure AD ?
Non. Le schéma est administré par Microsoft pour le domaine géré. Les extensions de
schéma ne sont pas prises en charge par les services de domaine Azure AD.
Puis-je modifier ou ajouter des enregistrements

DNS dans mon domaine géré ?
Oui. Les membres du groupe Administrateurs Azure AD DC bénéficient de privilèges
Administrateur DNS, afin de modifier les enregistrements DNS sur le domaine managé.
Ces utilisateurs peuvent utiliser la console du Gestionnaire DNS sur un ordinateur
exécutant Windows Server joint au domaine managé afin de gérer le système DNS. Pour
utiliser la console du Gestionnaire DNS, installez les outils de serveur DNS, qui font partie
de la fonctionnalité facultative Outils d’administration de serveur distant sur le serveur.
Pour plus d’informations, consultez Administrer DNS dans un domaine managé Azure
AD Domain Services.
Quelle est la stratégie de durée de vie des mots

de passe dans un domaine managé ?
Par défaut, la durée de vie des mots de passe dans un domaine managé Azure AD
Domain Services est de 90 jours. Cette durée de vie des mots de passe n’est pas
synchronisée avec celle configurée dans Azure AD. Par conséquent, il est possible qu’un
mot de passe utilisateur expire dans votre domaine managé, mais soit toujours valide
dans Azure AD. Dans les scénarios comme celui-ci, les utilisateurs doivent modifier leur
mot de passe dans Azure AD. Le nouveau mot de passe est ensuite synchronisé avec
votre domaine managé. Si vous souhaitez modifier la durée de vie par défaut d’un mot
de passe dans un domaine géré, vous pouvez créer et configurer des stratégies de mot
de passe personnalisées..
En outre, la stratégie de mot de passe Azure AD pour DisablePasswordExpiration est

synchronisée avec un domaine managé. Lorsque DisablePasswordExpiration est appliqué
à un utilisateur dans Azure AD, la valeur UserAccountControl pour l’utilisateur
synchronisé dans le domaine managé a DONT_EXPIRE_PASSWORD appliqué.
Lorsque les utilisateurs réinitialisent leur mot de passe dans Azure AD, l’attribut
forceChangePasswordNextSignIn=true est appliqué. Un domaine managé synchronise
cet attribut à partir de Azure AD. Lorsque le domaine managé détecte que
forceChangePasswordNextSignIn est défini pour un utilisateur synchronisé à partir de
Azure AD, l’attribut pwdLastSet dans le domaine managé est défini sur 0, ce qui invalide
le mot de passe actuellement défini.
Le service Azure AD Domain Services assure-t-il

une protection par verrouillage du compte AD ?
Oui. Cinq tentatives de saisie de mot de passe non valide en 2 minutes dans le domaine
managé entraînent le verrouillage d’un compte d’utilisateur pendant 30 minutes. Après
ces 30 minutes, le compte d’utilisateur est automatiquement déverrouillé. Les tentatives
de saisie de mot de passe non valide dans le domaine managé ne verrouillent pas le
compte d’utilisateur dans Azure AD. Le compte d’utilisateur est verrouillé uniquement
dans votre domaine managé Azure AD Domain Services. Pour plus d'informations,
consultez Stratégies de mot de passe et de verrouillage de compte sur les domaines
managés.
Puis-je configurer le système de fichiers DFS et la

réplication dans Azure AD Domain Services ?
Non. Le système de fichiers DFS (Distributed File System) et la réplication ne sont pas
disponibles lors de l’utilisation d’Azure AD Domain Services.
Comment les mises à jour Windows sont-elles

appliquées dans Azure AD Domain Services ?
Les contrôleurs de domaine dans un domaine managé appliquent automatiquement les
mises à jour Windows requises. Il n’y a rien à configurer ni à administrer ici. Veillez à ne
pas créer de règles de groupe de sécurité réseau qui bloquent le trafic sortant vers les
mises à jour Windows. Pour vos propres machines virtuelles jointes au domaine géré,
vous êtes responsable de la configuration et de l’application des mises à jour requises
du système d’exploitation et des applications.
Pourquoi les noms de mes contrôleurs de

domaine changent-ils ?
Il est possible que, durant la maintenance des contrôleurs de domaine, les noms de
ceux-ci changent. Pour éviter les problèmes liés à ce type de modification, il est
recommandé de ne pas utiliser les noms des contrôleurs de domaine codés en dur dans
des applications et/ou d’autres ressources de domaine, mais le nom de domaine
complet (FQDN). De cette façon, quels que soient les noms des contrôleurs de domaine,
vous n’aurez rien à reconfigurer après une modification de nom.
Le mot de passe du compte KRBTGT dans un

domaine managé est-il régulièrement restauré ?
Si c’est le cas, quelle est la fréquence ?
Le mot de passe du compte KRBTGT dans un domaine managé est restauré tous les sept
(7) jours.
Facturation et disponibilité
Les services de domaine Azure AD sont-ils
payants ?
Oui. Pour plus d’informations, consultez la page relative aux prix appliqués .
Le service peut-il être essayé gratuitement ?

Azure AD Domain Services est inclus dans l’essai gratuit d’Azure. Vous pouvez vous
inscrire pour bénéficier d’un essai gratuit d’un mois d’Azure .
Puis-je suspendre un domaine géré par Azure
AD Domain Services ?
Non. Une fois que vous avez activé un domaine géré par Azure AD Domain Services, le
service est disponible dans votre réseau virtuel sélectionné jusqu’à ce que vous
supprimiez le domaine géré. Il n’existe aucun moyen de suspendre le service. La
facturation horaire se poursuivra jusqu’à ce que vous supprimiez le domaine managé.
Puis-je basculer Azure AD Domain Services vers

une autre région pour un événement de
récupération d’urgence ?
Oui, afin de fournir une résilience géographique pour un domaine managé, vous pouvez
créer un jeu de réplicas supplémentaire sur un réseau virtuel appairé dans une région
Azure qui prend en charge Azure AD DS. Les jeux de réplicas partagent le même espace
de noms et la même configuration que le domaine managé.
Puis-je obtenir les services de domaine Azure AD

dans le cadre d’Enterprise Mobility Suite (EMS) ?
Ai-je besoin d’Azure AD Premium pour utiliser
les services de domaine Azure AD ?
Non. Les services de domaine Azure AD constituent un service Azure avec paiement à
l’utilisation et ne font pas partie d’EMS. Azure Active Directory Domain Services peut
être utilisé avec toutes les éditions d’Azure AD (Gratuit et Premium). La facturation se
fait à l’utilisation, sur une base horaire.
Puis-je créer un domaine enfant sous un

domaine managé ?
Non. Azure AD Domain Services a une conception à domaine unique et à forêt unique,
et vous ne pouvez pas créer de domaines enfants.
Dans quelles régions Azure le service est-il

disponible ?
Pour consulter une liste des régions Azure dans lesquelles les services de domaine Azure
AD sont disponibles, consultez la page Régions Azure .
Dépannage
Reportez-vous au Guide de résolution des problèmes pour trouver les solutions aux
problèmes courants liés à la configuration ou à l’administration d’Azure AD Domain
Services.
Étapes suivantes
Pour en savoir plus sur Azure AD Domain Services, consultez Présentation d’Azure Active
Pour bien démarrer, consultez Créer et configurer un domaine managé Azure Active
Disponibilité des fonctionnalités Azure
Article • 01/06/2023
La liste suivante répertorie la disponibilité des fonctionnalités Azure Active Directory

Domain Services (Azure AD DS) dans Azure Government.
Fonctionnalité Disponibilité
Configurer le protocole LDAPS ✅
Créer des approbations ✅
Créer des jeux de réplicas ✅
Configurer et définir l’étendue de la synchronisation des utilisateurs et des ✅

groupes
Configurer la synchronisation de hachage de mot de passe ✅
Configurer des stratégies de mot de passe et de verrouillage de compte ✅
Gérer la stratégie de groupe ✅
Gérer DNS ✅
Notifications par e-mail ✅
Configurer la délégation contrainte Kerberos ✅
Modèles d’audit et de classeurs Azure Monitor ✅
Machines virtuelles Windows avec jonction de domaine ✅
Machines virtuelles Linux avec jonction de domaine ✅
Déployer le proxy d’application Azure AD ✅
Activer la synchronisation de profils pour SharePoint ✅
Étapes suivantes
Questions fréquentes (FAQ)
Mises à jour de service
Tarification
Déploiement et gestion d'Azure Active
Directory Domain Services pour les
fournisseurs de solutions Azure Cloud
Article • 01/06/2023
Azure CSP (Fournisseurs de solutions Azure Cloud) est un programme destiné aux
partenaires Microsoft qui fournit un canal de licence pour divers services cloud
Microsoft. Azure CSP permet aux partenaires de gérer les ventes, de prendre en charge
les relations relatives à la facturation, de fournir un support technique et sur la
facturation et d’être le seul point de contact du client. De plus, Azure CSP fournit un
ensemble complet d’outils, notamment un portail libre-service et des API connexes. Ces
outils permettent aux partenaires CSP de provisionner et gérer facilement des
ressources Azure et de fournir une facturation pour les clients et leurs abonnements.
Le portail Espace partenaires est le point d’entrée de tous les partenaires Azure CSP. Il
fournit des fonctionnalités de gestion de client riches, un traitement automatisé, etc. Les
partenaires Azure CSP peuvent utiliser les fonctionnalités de l’Espace partenaires en
utilisant une interface utilisateur basée sur le web ou PowerShell et différents appels
d’API.
Le schéma suivant illustre le fonctionnement général du modèle CSP. Ici, Contoso

dispose d'un locataire Azure Active Directory (Azure AD). Il a un partenariat avec un
fournisseur de solutions cloud, qui déploie et gère les ressources de son abonnement
Azure CSP. Contoso peut également avoir des abonnements Azure ordinaires (directs),
qui lui sont facturés directement.
Le locataire du partenaire CSP présente trois groupes d’agents spéciaux : les agents
d’administration, les agents de support technique et les agents de vente.
Le groupe des agents d’administration est attribué au rôle d’administrateur de locataire
dans le locataire Azure AD de Contoso. Ainsi, un utilisateur appartenant au groupe
d’agents d’administration du partenaire CSP a des privilèges d’administration de
locataire dans le locataire Azure AD de Contoso.
Quand le partenaire CSP provisionne un abonnement Azure CSP pour Contoso, son
groupe d’agents d’administration est affecté au rôle de propriétaire pour cet
abonnement. Ainsi, les agents d’administration du partenaire CSP ont les privilèges
nécessaires pour provisionner des ressources Azure telles que des machines virtuelles,
des réseaux virtuels et Azure AD Domain Services pour le compte de Contoso.
Pour plus d’informations, consultez la présentation d’Azure CSP.
Avantages d’utiliser Azure AD DS dans un

abonnement Azure CSP
Directory Domain Service. Au fil des décennies, de nombreuses applications ont été
générées pour fonctionner avec Active Directory à l’aide de ces fonctionnalités. De
nombreux éditeurs de logiciels indépendants (ISV) ont généré et déployé des
applications dans les locaux de leurs clients. La prise en charge de ces applications est
difficile, car elle implique l’accès aux différents environnements dans lesquels les
applications sont déployées. Avec des abonnements Azure CSP, vous avez une solution
plus simple avec l’adaptabilité et la flexibilité d’Azure.
Azure AD DS prend en charge les abonnements Azure CSP. Vous pouvez déployer votre
application dans un abonnement Azure CSP lié à l’annuaire Azure AD de votre locataire.
Ainsi, vos employés (équipes du support) peuvent gérer, administrer et assurer la
maintenance des machines virtuelles sur lesquelles votre application est déployée à
l’aide des informations d’identification d’entreprise de votre organisation.
Vous pouvez également déployer un domaine managé Azure AD DS dans le locataire

Azure AD de votre client. Votre application est alors connectée au domaine managé de
votre client. Les fonctionnalités au sein de votre application qui s’appuient sur Kerberos
/ NTLM, LDAP ou l’API System.DirectoryServices fonctionnent de manière fluide dans le
domaine de votre client. Les clients profitent de la consommation de votre application
en tant que service, sans avoir à se soucier de la gestion de l’infrastructure sur laquelle
l’application est déployée.
Vous acquittez toute la facturation des ressources Azure que vous utilisez dans cet
abonnement, y compris Azure AD DS. Vous contrôlez en totalité la relation avec le client
en ce qui concerne les ventes, la facturation, le support technique, etc. Grâce à la
flexibilité de la plateforme Azure CSP, une petite équipe d’agents de support peut
prendre en charge de nombreux clients pour lesquels des instances de votre application
sont déployées.
Modèles de déploiement CSP pour Azure AD

DS
Il existe deux façons d’utiliser Azure AD DS avec un abonnement Azure CSP. Choisissez
celui qui convient, suivant l’importance qu’accordent vos clients à la sécurité et à la
simplicité.
Modèle de déploiement direct

Dans ce modèle de déploiement, Azure AD DS est activé au sein d’un réseau virtuel
appartenant à l’abonnement Azure CSP. Les agents d’administration du partenaire CSP
ont les privilèges suivants :
Privilèges d’administrateur général dans le locataire Azure AD du client.

Privilèges de propriétaire d’abonnement sur l’abonnement Azure CSP.
Dans ce modèle de déploiement, les agents d’administration du fournisseur CSP
peuvent gérer les identités pour le client. Ces agents d’administration peuvent effectuer
différentes tâches telles que l'approvisionnement de nouveaux utilisateurs et groupes
ou l'ajout d'applications dans le locataire Azure AD du client.
Ce modèle de déploiement peut être adapté aux petites organisations qui n’ont pas
d’administrateur d’identité dédié ou qui préfèrent que le partenaire CSP gère les
identités pour leur compte.
Modèle de déploiement appairé

Dans ce modèle de déploiement, Azure AD DS est activé au sein d’un réseau virtuel
appartenant au client, un abonnement Azure direct payé par le client. Le partenaire CSP
peut déployer des applications au sein d’un réseau virtuel appartenant à l’abonnement
CSP du client. Les réseaux virtuels peuvent être connectés à l’aide du peering de réseau
virtuel Azure.
Avec ce déploiement, les charges de travail ou applications déployées par le partenaire

CSP dans l’abonnement Azure CSP peuvent se connecter au domaine managé du client
provisionné dans l’abonnement Azure direct du client.
Ce modèle de déploiement fournit une séparation des privilèges et permet aux agents
de support technique du partenaire CSP d’administrer l’abonnement Azure et de
déployer et gérer les ressources qu’il contient. Toutefois, les agents de support
technique du partenaire CSP ne sont pas tenus de disposer de privilèges
d’administrateur général sur l’annuaire Azure AD du client. Les administrateurs d’identité
du client peuvent continuer à gérer les identités pour leur organisation.
Ce modèle de déploiement peut être adapté aux scénarios où un éditeur de logiciels

indépendant fournit une version hébergée de son application locale, qui doit également
se connecter à l’annuaire Azure AD du client.
Administrer Azure AD DS dans les

abonnements CSP
Tenez compte des considérations importantes suivantes quand vous administrez un
domaine managé dans un abonnement Azure CSP :
Les agents d’administration CSP peuvent approvisionner un domaine managé à

l’aide de leurs informations d’identification : Azure AD DS prend en charge les
abonnements Azure CSP. Les utilisateurs appartenant au groupe d’agents
d’administration d’un partenaire CSP peuvent approvisionner un nouveau domaine
managé.
Les fournisseurs de solutions cloud peuvent programmer au moyen d’un script

la création de domaines managés pour leurs clients à l’aide de PowerShell : Pour
plus d'informations, consultez Activer Azure AD DS à l’aide de PowerShell.
Les agents d’administration CSP ne peuvent pas effectuer de tâches de gestion

en continu sur le domaine managé à l’aide de leurs informations
d’identification : les utilisateurs administrateurs CSP ne peuvent pas effectuer de
tâches de gestion courantes dans le domaine managé à l’aide de leurs
informations d’identification. Ces utilisateurs étant externes au locataire Azure AD
du client, leurs informations d’identification ne sont pas disponibles dans le
locataire Azure AD du client. Azure AD DS n’a pas accès aux hachages de mot de
passe Kerberos et NTLM pour ces utilisateurs. Dès lors, les utilisateurs ne peuvent
pas être authentifiés sur les domaines managés.
２ Avertissement
Vous devez créer un compte d’utilisateur dans l’annuaire du client pour

effectuer des tâches d’administration courantes sur le domaine managé.
Vous ne pouvez pas vous connecter au domaine managé à l’aide des

informations d’identification d’un utilisateur administrateur CSP. Pour ce faire,
utilisez les informations d’identification d’un compte d’utilisateur appartenant
au locataire Azure AD du client. Vous avez besoin de ces informations
d’identification pour les tâches telles que la jonction de machines virtuelles au
domaine managé, l’administration du système DNS ou l’administration de la
Le compte d’utilisateur créé pour l’administration courante doit être ajouté au

groupe Administrateurs AAD DC : le groupe Administrateurs AAD DC dispose de
privilèges pour effectuer certaines tâches d’administration déléguée dans le
domaine managé. Ces tâches comprennent la configuration du système DNS, la
création d’unités d’organisation et l’administration de la stratégie de groupe.
Pour qu’un partenaire CSP effectue ces tâches sur un domaine managé, un compte
d’utilisateur doit être créé dans le locataire Azure AD du client. Les informations
d’identification pour ce compte doivent être partagées avec les agents
d’administration du partenaire CSP. De plus, ce compte d’utilisateur doit être
ajouté au groupe Administrateurs AAD DC pour qu’il puisse effectuer des tâches de
configuration sur le domaine managé.
Étapes suivantes
Pour commencez, inscrivez-vous au programme Fournisseur de solutions Azure Cloud.
Vous pourrez ensuite Activer Azure AD Domain Services à l’aide du portail Azure ou
d'Azure PowerShell.

Azure Active Directory Domain Services

Uploaded by

Copyright:

Available Formats

You might also like

Azure Active Directory Domain Services

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Azure Active Directory Domain Services

Uploaded by

Copyright:

Available Formats

Parlez-nous de l’expérience de téléchargement de PDF.

Documentation sur Azure AD Domain

À propos d’Azure AD Domain Services

Présentation d’Azure AD Domain Services

Comparer les solutions d’identité

Comment fonctionne la synchronisation ?

Créer un domaine managé

Joindre une machine virtuelle Windows Server à un domaine

Installer des outils de gestion

Configurer le protocole LDAP sécurisé

Activer la synchronisation de hachage de mot de passe

Créer une unité d’organisation

Configurer une délégation Kerberos contrainte

Sécuriser un domaine managé

Administrer la stratégie de groupe

Vérifier l’état d’intégrité

Configurer les notifications par e-mail

Activer les audits de sécurité

Joindre des machines virtuelles à un domaine

Red Hat Enterprise Linux

SUSE Linux Enterprise

Problèmes de groupe de sécurité réseau

Problèmes de protocole LDAP sécurisé

Un domaine managé Azure AD DS vous permet d’exécuter des applications héritées

Pour commencer, créez un domaine managé Azure AD DS à l’aide du portail Azure

Un domaine managé est configuré pour effectuer une synchronisation unidirectionnelle

Dans un environnement hybride avec un environnement AD DS local, Azure AD Connect

Si vous disposez d’un environnement AD DS local existant, vous pouvez

Azure AD DS pour les organisations hybrides

Fonctionnalités et avantages d’Azure AD DS

Les fonctionnalités suivantes d’Azure AD DS simplifient les opérations de déploiement et

Expérience de déploiement simplifiée : Azure AD DS est activé pour votre

Voici quelques aspects majeurs d’un domaine managé :

Le domaine géré est un domaine autonome. et non une extension du domaine

Pour commencer, créez un domaine managé à l’aide du portail Azure.

Pour commencer, créez un domaine managé Azure AD DS à l’aide du portail Azure

Azure AD DS et instance AD DS automanagée

Azure AD DS fournit un sous-ensemble plus petit de fonctionnalités à un environnement

Lorsque vous déployez et exécutez un environnement AD DS automanagé, vous devez

Les modèles de déploiement courants pour un environnement AD DS automanagé qui

Instance AD DS autonome et cloud uniquement : les machines virtuelles Azure

Fonctionnalité Azure AD DS AD DS automanagé

Déploiements sécurisés ✓ L’administrateur sécurisee

Serveur DNS ✓ (service géré) ✓

Approbations de ✓ (approbations de forêt sortantes ✓

LDAP sécurisé (LDAPS) ✓ ✓

Écriture LDAP ✓ (dans le domaine managé) ✓

Les appareils joints à Azure AD vous offrent les avantages suivants :

Authentification unique (SSO) pour les applications sécurisées par Azure AD

Type d’appareil Plateformes Mécanisme

Appareils personnels Windows 10, iOS, Appareils inscrits sur

Appareil appartenant à l’organisation et non Windows 10 Appareil joints Azure

Appareil appartenant à l’organisation et Windows 10 Appareils joints Azure

Sur un appareil inscrit ou joint à Azure AD, l’authentification de l’utilisateur s’effectue

Appareil Azure AD Domaine managé Azure AD DS

Représentation Objets appareil dans le Objets ordinateur dans le domaine managé

Authentification Protocoles OAuth et OpenID Protocoles Kerberos et NTLM

Gestion Logiciels de gestion des Stratégie de groupe