Azure Adconnect

Contents
Documentation des identités hybrides

Vue d’ensemble
L’Identité hybride
Tutoriels
Intégrer un environnement de forêt AD unique au cloud avec la synchronisation PHS
Intégrer un environnement de forêt AD unique au cloud avec l’authentification directe
(PTA)
Fédérer un environnement de forêt AD unique dans le cloud
Configurer PHS comme sauvegarde pour AD FS dans Azure AD Connect
Concepts
Identité hybride
Gestion gouvernée par le cloud pour les charges de travail locales
Créer une base d’identité solide en quatre étapes
Choisir une méthode d’authentification d’identité hybride
Azure AD Connect et Connect Health
Présentation d’Azure AD Connect et Connect Health
Qu’est-ce qu’Azure AD Connect V2.0 ?
Choisir l’authentification appropriée
Synchronisation des identités et résilience d’attribut en double
Synchronisation de hachage de mot de passe
Qu’est-ce que la synchronisation de hachage de mot de passe ?
Fonctionnement de la synchronisation de hachage de mot de passe
Synchronisation de hachage du mot de passe sélective
Authentification directe
Qu’est-ce que l'authentification directe ?
Fonctionnement de l’authentification directe
Limitations actuelles de l’authentification directe
Présentation approfondie de la sécurité sur l’authentification directe
Authentification directe et confidentialité de l’utilisateur
Fédération
Qu’est-ce que la fédération ?
Fonctionnement de la fédération
Liste de compatibilité de fédération Azure AD
Authentification unique
Qu’est-ce que l'authentification unique ?
Fonctionnement de l’authentification unique
Authentification unique et confidentialité de l’utilisateur
Synchronisation d’Azure AD Connect
Qu’est-ce que la synchronisation d’Azure AD Connect ?
Compte de service Azure ADSync
Fonctionnalités de la synchronisation d’Azure AD Connect
Qu’est-ce que le gestionnaire de service de synchronisation d'Azure AD Connect ?
Concepts techniques relatifs à la synchronisation d’Azure AD Connect Sync
Présentation de l’architecture de la synchronisation d’Azure AD Connect Sync
Présentation de l’approvisionnement déclaratif
Comprendre les expressions d’approvisionnement déclaratif
Présentation de la configuration par défaut
Présentation des utilisateurs et des contacts
Présentation des attributs des clichés
Guides pratiques
Installation et mise à niveau
Feuille de route de l’installation
Configuration requise pour l'installation
Choisir le type d'installation
Installer Azure AD Connect avec des paramètres Express (synchronisation du
hachage de mot de passe)
Installer la Fédération d’Azure AD Connect ou d’autres paramètres personnalisés
Importer et exporter des paramètres de configuration
Installer Azure AD Connect avec l’authentification directe (PTA)
Installer Azure AD Connect Health
Mise à jour automatique
Exécuter l’Assistant Installation une deuxième fois
Mettre à niveau vers une nouvelle version d’Azure AD Connect
Mettre à niveau à partir de DirSync ou d’Azure AD Sync
Installer à l’aide d’une base de données ADSync existante
Installer à l’aide d’autorisations administrateur déléguées SQL
Mettre à niveau les agents d’aperçu pour l’authentification directe
Déplacer la base de données Azure AD Connect de SQL Express vers SQL Server
Si vous disposez déjà d’Azure AD
Tâches postérieures à l’installation
Désinstaller Azure AD Connect
Planifier et concevoir
Principes de conception
Topologies pour Azure AD Connect
Facteurs affectant les performances d’Azure AD Connect
Comment les utilisateurs vont-ils se connecter
Remplissage de UserPrincipalName dans Azure AD
Considérations spécifiques concernant les instances
Migration
Passer de la fédération à l’authentification cloud
Déplacer des groupes d’une forêt à une autre
Migrer vers l’authentification cloud avec un lancement intermédiaire
Considérations relatives à la conception d'identités hybrides
Présentation des considérations relatives à la conception d'identités hybrides
Déterminer les exigences en matière d'identité
Déterminer la configuration requise pour la synchronisation
Déterminer la configuration requise pour l’authentification multifacteur
Déterminer la stratégie d’adoption du cycle de vie
Définir une politique de protection des données
Planifier les exigences en matière de protection des données
Déterminer les exigences de gestion de contenu
Déterminer les exigences de contrôle d’accès
Déterminer les exigences de réponse aux incidents
Planifier le cycle de vie des identités hybrides
Définir une stratégie d’adoption
Considérations relatives à la conception d'identités hybrides - Étapes suivantes
Comparaison des outils d’identités hybrides
Gestion d’Azure AD Connect
Activer l’écriture différée des appareils
Activer l’écriture différée des groupes
Options de l’appareil
Fonctionnalités supplémentaires dans Azure AD Connect
prévention des suppressions accidentelles
Activer la Corbeille Active Directory
Configurer le compte de connecteur AD DS
Modifier le mot de passe du compte de service Azure AD Sync
Changer le mot de passe du compte de connecteur Azure AD
Modifier le mot de passe du compte de connecteur AD DS
Gérer l'authentification directe
Prendre en main l'authentification directe
FAQ sur l’authentification directe
Désactiver PTA avec « Ne pas configurer » d’Azure AD Connect
Gérer les services de fédération
Gestion de la fédération avec Azure AD Connect
Prise en charge de plusieurs domaines pour la fédération
Fédérer plusieurs instances d’Azure AD avec une seule instance d’AD FS
Renouveler les certificats de fédération pour Office 365 et Azure AD
Mettre à jour le certificat SSL pour AD FS
Gérer la confiance AD FS avec Azure AD
Configurer des revendications de groupe pour les applications
Modifier l’algorithme de hachage pour le fournisseur de ressources Office 365
Utiliser un serveur SAML 2.0 en tant que fournisseur d’identité
Tâches post-configuration concernant la jonction Azure AD Hybride
Rotation d’urgence de certificats AD FS
Surperviser les modifications apportées à la configuration de fédération
Gérer l'authentification unique
Prendre en main l’authentification unique
Prendre en main l’authentification unique
FAQ sur l’authentification unique
Gérer Azure AD Connect Health
Opérations Azure AD Connect Health
Utiliser Azure AD Connect Health avec AD FS
Rapport d’adresse IP à risque pour Azure AD Connect Health avec AD FS
Workbook de rapport d’adresse IP à risque pour Azure AD Connect Health
Connexions AD FS dans Azure AD avec Connect Health
Utiliser Azure AD Connect Health pour la synchronisation
Utiliser Azure AD Connect Health avec AD DS
Données du service Health obsolètes
Diagnostiquer les erreurs de synchronisation d’attribut en double
Catalogue d’alertes de Azure AD Connect Health
Extraction de données Azure AD Connect Health
Gérer la synchronisation d’Azure AD Connect
Serveur de préproduction et reprise d’activité après sinistre
Meilleures pratiques pour la modification de la configuration par défaut
Modifier la configuration par défaut
Corriger des règles par défaut modifiées
Configurer les extensions de répertoire
Configurer un emplacement de données par défaut
Configurer le filtrage
Gérer le planificateur
Créer et personnaliser une règle de synchronisation
API de point de terminaison V2 pour la synchronisation d’Azure AD Connect
Gestionnaire de service de synchronisation d'Azure AD Connect
Gérer l’onglet Opérations du gestionnaire de service de synchronisation
Utiliser des connecteurs avec le gestionnaire de service
Metaverse designer
Recherche de métaverse
Dépanner
Présentation de l’agent d’administration Azure AD Connect
En quoi consiste le module PowerShell de ADConnectivityTools ?
Synchronisation d’objets uniques Azure AD Connect
Connectivité
Résolution des erreurs lors de la synchronisation
Objet non synchronisé
Ancre source pendant l’installation
Synchronisation d’objets à l’aide de la tâche de résolution des problèmes
Erreur de LargeObject provoquée par userCertificate
Comment récupérer depuis la limite de 10 Go de base de données locale
Connectivité SQL
Synchronisation d’attributs
Problèmes d’installation
Modifications de l’UPN
Résolution des problèmes de bout en bout des objets et attributs
Informations de référence
Ports et protocoles nécessaires à l’identité hybride
Historique des versions d’Azure AD Connect
Historique des versions d’Azure AD Connect Health
Historique des versions de l’agent Authentification directe Azure AD
Historique des versions du connecteur
Comptes et autorisations
FAQ Azure AD Connect
Forum Aux Questions (FAQ) Azure AD Connect Health
Considérations sur les identités hybrides pour Azure Government
Confidentialité des utilisateurs d’Azure AD Connect
Confidentialité des utilisateurs d’Azure AD Connect Health
Azure AD Connect en Allemagne
Abandon de la synchronisation de répertoires
Attributs synchronisés
Référence des fonctions
Application de TLS 1.2
Référence ADSync
Référence ADSyncConfig
Référence ADSyncTools
Référence de ADConnectivityTools
msExchUserHoldPolicies et cloudMSExchUserHoldPolicies
Archive de l’historique des versions Azure AD Connect
Présentation de l’identité hybride avec Azure Active
Directory
20/12/2021 • 2 minutes to read
Les entreprises et les organisations utilisent aujourd’hui de plus en plus souvent une combinaison d’applications
locales et cloud. Les utilisateurs doivent avoir accès à ces applications en local et dans le cloud, Les scénarios de
gestion des utilisateurs en local et dans le cloud constituent un défi.
Les solutions d'identité de Microsoft regroupent des fonctionnalités, locales et cloud. Ces solutions créent une
identité d'utilisateur unique commune pour l'authentification et l'autorisation d'accès à toutes les ressources,
indépendamment de leur l'emplacement. Nous appelons cette identité identité hybride .
Avec l’identité hybride pour Azure AD et la gestion de l’identité hybride, ces scénarios deviennent possibles.
Pour obtenir l’identité hybride avec Azure AD, l'une des trois méthodes d’authentification peut être utilisée, selon
vos scénarios. Ces trois méthodes sont les suivantes :
Synchronisation de hachage de mot de passe (PHS)
Authentification directe (PTA)
Fédération (AD FS)
Ces méthodes d’authentification s'accompagnent également de fonctionnalités d'authentification unique.
L’authentification unique connecte automatiquement les utilisateurs lorsque leurs appareils d’entreprise sont
connectés au réseau de l’entreprise.
Pour plus d'informations, consultez Choisir la méthode d’authentification adaptée à votre solution d’identité
hybride Azure Active Directory.
Scénarios et recommandations courants

Voici quelques scénarios courants de gestion des identités hybrides et des accès avec des recommandations
concernant l’option (ou les options) d’identité hybride la ou les mieux appropriées dans chaque cas.
J’A I B ESO IN DE : P H S ET SSO 1 P TA ET SSO 2 A D F S3
Synchroniser de nouveaux
comptes d’utilisateurs, de
contacts et de groupes
créés automatiquement
dans mon Active Directory
local vers le cloud.
Configurer mon locataire

pour des scénarios hybrides
Microsoft 365.
Permettre à mes utilisateurs

de se connecter et d’accéder
aux services cloud à l’aide
de leur mot de passe local.
J’A I B ESO IN DE : P H S ET SSO P TA ET SSO AD FS
Implémenter
l’authentification unique à
l’aide des informations
d’identification d’entreprise.
M’assurer qu’aucun
hachage du mot de passe
n’est stocké dans le cloud.
Activer des solutions

d’authentification
multifacteur cloud.
Activer des solutions

multifacteur locales.
Prendre en charge
l’authentification par carte à
puce pour mes utilisateurs.4
Afficher les notifications

d’expiration du mot de
passe dans le portail Office
et sur le bureau
Windows 10.
1 Synchronisation de hachage de mot de passe avec authentification unique (SSO).
2 Authentification directe et authentification unique.
3 Authentification unique fédérée avec AD FS.
4 AD FS peut être intégré à l’infrastructure de clé publique (PKI) de votre entreprise pour permettre
l’authentification à l’aide de certificats. Ces certificats peuvent être des certificats logiciels déployés via des
canaux d’approvisionnement approuvés tels que les certificats de gestion des périphériques mobiles (GPM),
d’objet de stratégie de groupe (GPO), de carte à puce (y compris les cartes PIV/CAC) ou Hello for Business
(approbation de certificat). Pour plus d’informations sur la prise en charge de l’authentification par carte à
puce, consultez ce blog.
Licences requises pour Azure AD Connect

L'utilisation de cette fonctionnalité est gratuite et incluse dans votre abonnement Azure.
Étapes suivantes
Qu’est-ce que la synchronisation de hachage de mot de passe (PHS) ?
Qu’est-ce que l’authentification directe (PTA) ?
Qu’est-ce que l’authentification unique ?
Tutoriel : Intégrer une forêt AD unique avec la
synchronisation du hachage de mot de passe (PHS)
Ce didacticiel vous guidera dans la création d’un environnement d’identité hybride à l’aide de la synchronisation
de hachage de mot de passe. Cet environnement peut ensuite servir à des fins de test ou pour se familiariser
avec le fonctionnement d’une identité hybride.
Prérequis
Voici les conditions préalables requises pour suivre ce didacticiel.
Un ordinateur où Hyper-V est installé. Il est recommandé d’utiliser Windows 10 ou Windows Server 2016.
Une carte réseau externe pour autoriser la machine virtuelle à communiquer avec Internet.
Un abonnement Azure
Une copie de Windows Server 2016
NOTE
Ce didacticiel utilise des scripts PowerShell pour vous permettre de créer l’environnement le plus vite possible. Chacun des
scripts utilise les variables déclarées au début des scripts. Vous pouvez et devez modifier les variables pour qu’elles
reflètent votre environnement.
Les scripts utilisés créent un environnement Active Directory général avant d’installer Azure AD Connect. Elles sont
pertinentes pour l’ensemble des didacticiels.
Des copies des scripts PowerShell utilisés dans ce didacticiel sont disponibles sur GitHub, ici.
Création d'une machine virtuelle

Tout d’abord, pour obtenir un environnement d’identité hybride fonctionnel, il faut créer une machine virtuelle
qui sera utilisée en tant que serveur Active Directory local. Effectuez les actions suivantes :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.
#Declare variables
$VMName = 'DC1'
$Switch = 'External'
$InstallMedia = 'D:\ISO\en_windows_server_2016_updated_feb_2018_x64_dvd_11636692.iso'
$Path = 'D:\VM'
$VHDPath = 'D:\VM\DC1\DC1.vhdx'
$VHDSize = '64424509440'
#Create New Virtual Machine

New-VM -Name $VMName -MemoryStartupBytes 16GB -BootDevice VHD -Path $Path -NewVHDPath $VHDPath -
NewVHDSizeBytes $VHDSize -Generation 2 -Switch $Switch
#Set the memory to be non-dynamic

Set-VMMemory $VMName -DynamicMemoryEnabled $false
#Add DVD Drive to Virtual Machine

Add-VMDvdDrive -VMName $VMName -ControllerNumber 0 -ControllerLocation 1 -Path $InstallMedia
#Mount Installation Media

$DVDDrive = Get-VMDvdDrive -VMName $VMName
#Configure Virtual Machine to Boot from DVD

Set-VMFirmware -VMName $VMName -FirstBootDevice $DVDDrive
Terminer le déploiement du système d’exploitation

Pour terminer la création de la machine virtuelle, vous devez terminer l’installation du système d’exploitation.
1. Gestionnaire Hyper-V, double-clic sur la machine virtuelle
2. Cliquez sur le bouton Démarrer.
3. Vous êtes invité à appuyer sur n’importe quelle touche pour démarrer à partir du CD ou DVD. Faites-le.
4. Sur l’écran de démarrage Windows Server, sélectionnez votre langue et cliquez sur Suivant .
5. Cliquez sur Installer maintenant .
6. Saisissez votre clé de licence et cliquez sur Suivant .
7. Acceptez les termes du contrat de licence et cliquez sur Suivant .
8. Sélectionnez Personnalisé : installer Windows uniquement (avancé)
9. Cliquez sur Suivant .
10. Une fois l’installation terminée, redémarrez la machine virtuelle, connectez-vous et exécutez les mises à jour
Windows pour vous assurer que la machine virtuelle est à jour. Installez les dernières mises à jour.
Installer les prérequis pour Active Directory

Maintenant que la machine virtuelle est en cours d’exécution, il faut effectuer quelques opérations avant
d’installer Active Directory. Autrement dit, il faut renommer la machine virtuelle, définir une adresse IP statique
et des informations DNS, et installer les outils d’administration de serveur distant. Effectuez les actions
suivantes :
#Declare variables
$ipaddress = "10.0.1.117"
$ipprefix = "24"
$ipgw = "10.0.1.1"
$ipdns = "10.0.1.117"
$ipdns2 = "8.8.8.8"
$ipif = (Get-NetAdapter).ifIndex
$featureLogPath = "c:\poshlog\featurelog.txt"
$newname = "DC1"
$addsTools = "RSAT-AD-Tools"
#Set static IP address

New-NetIPAddress -IPAddress $ipaddress -PrefixLength $ipprefix -InterfaceIndex $ipif -DefaultGateway $ipgw
# Set the DNS servers

Set-DnsClientServerAddress -InterfaceIndex $ipif -ServerAddresses ($ipdns, $ipdns2)
#Rename the computer

Rename-Computer -NewName $newname -force
#Install features
New-Item $featureLogPath -ItemType file -Force
Add-WindowsFeature $addsTools
Get-WindowsFeature | Where installed >>$featureLogPath
#Restart the computer

Restart-Computer
Créer un environnement Windows Server AD

Maintenant que la machine virtuelle a été créée et renommée, et qu’elle dispose d’une adresse IP statique, nous
pouvons installer et configurer Active Directory Domain Services. Effectuez les actions suivantes :
#Declare variables
$DatabasePath = "c:\windows\NTDS"
$DomainMode = "WinThreshold"
$DomainName = "contoso.com"
$DomaninNetBIOSName = "CONTOSO"
$ForestMode = "WinThreshold"
$LogPath = "c:\windows\NTDS"
$SysVolPath = "c:\windows\SYSVOL"
$Password = "Pass1w0rd"
$SecureString = ConvertTo-SecureString $Password -AsPlainText -Force
#Install AD DS, DNS and GPMC

start-job -Name addFeature -ScriptBlock {
Add-WindowsFeature -Name "ad-domain-services" -IncludeAllSubFeature -IncludeManagementTools
Add-WindowsFeature -Name "dns" -IncludeAllSubFeature -IncludeManagementTools
Add-WindowsFeature -Name "gpmc" -IncludeAllSubFeature -IncludeManagementTools }
Wait-Job -Name addFeature
#Create New AD Forest

Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath $DatabasePath -DomainMode $DomainMode -
DomainName $DomainName -SafeModeAdministratorPassword $SecureString -DomainNetbiosName $DomainNetBIOSName -
ForestMode $ForestMode -InstallDns:$true -LogPath $LogPath -NoRebootOnCompletion:$false -SysvolPath
$SysVolPath -Force:$true
Créer un utilisateur Windows Server AD
Maintenant que nous avons un environnement Active Directory, nous avons besoin d’un compte de test. Ce
compte sera créé dans l’environnement Active Directory local, puis synchronisé avec Azure AD. Effectuez les
actions suivantes :
#Declare variables
$Givenname = "Allie"
$Surname = "McCray"
$Displayname = "Allie McCray"
$Name = "amccray"
$Identity = "CN=ammccray,CN=Users,DC=contoso,DC=com"
#Create the user

New-ADUser -Name $Name -GivenName $Givenname -Surname $Surname -DisplayName $Displayname -AccountPassword
$SecureString
#Set the password to never expire

Set-ADUser -Identity $Identity -PasswordNeverExpires $true -ChangePasswordAtLogon $false -Enabled $true
Créer un locataire Azure AD

Nous devons maintenant créer un locataire Azure AD pour synchroniser nos utilisateurs vers le cloud. Pour créer
un client Azure AD, procédez comme suit.
1. Accédez au portail Azure et connectez-vous avec un compte qui dispose d’un abonnement Azure.
2. Cliquez sur l’icône plus (+) et recherchez Azure Active Director y .
3. Dans la liste des résultats, sélectionnez sur Azure Active Director y .
4. Sélectionnez Create (Créer).
5. Indiquez le nom de l’organisation avec le nom de domaine initial . Sélectionnez ensuite Créer . Votre
annuaire est alors créé.
6. Une fois cette opération terminée, cliquez sur ce lien pour gérer l’annuaire.
Créer un administrateur général dans Azure AD

Maintenant que nous avons un locataire Azure AD, nous allons créer un compte d’administrateur général. Ce
compte est utilisé pour créer le compte de connecteur Azure AD lors de l’installation d’Azure AD Connect. Le
compte de connecteur Azure AD sert à écrire des informations dans Azure AD. Pour créer le compte
d’administrateur général, procédez comme suit.
1. Sous Gérer , sélectionnez Utilisateurs .
2. Sélectionnez Tous les utilisateurs , puis + Nouvel utilisateur .
3. Renseignez un nom et un nom d’utilisateur pour cet utilisateur. Il s’agit de votre administrateur général pour
le locataire. Vous devez également définir le rôle d’annuaire sur Administrateur général . Vous pouvez
également afficher le mot de passe temporaire. Lorsque vous avez terminé, sélectionnez Créer .
4. Une fois cette opération terminée, ouvrez une nouvelle fenêtre de navigateur web et connectez-vous à
myapps.microsoft.com en utilisant le nouveau compte d’administrateur général et le mot de passe
temporaire.
5. Remplacez le mot de passe de l’administrateur général par quelque chose de facile à retenir.
Télécharger et installer Azure AD Connect

Il est maintenant temps de télécharger et d’installer Azure AD Connect. Une fois l’installation terminée, nous
aborderons l’installation rapide. Effectuez les actions suivantes :
1. Télécharger Azure AD Connect
2. Accédez à AzureADConnect.msi et double-cliquez sur ce fichier.
3. Sur l'écran d’accueil, sélectionnez la case pour accepter les termes du contrat de licence et cliquez sur
Continuer .
4. Sur l'écran Paramètres Express, cliquez sur Utiliser les paramètres Express .
5. Sur l’écran Connexion à Azure AD, entrez le nom d’utilisateur et le mot de passe de l’administrateur général
pour l’instance Azure AD. Cliquez sur Suivant .
6. Sur l’écran Connexion à AD DS, entrez le nom d’utilisateur et le mot de passe d’un compte d’administrateur
d’entreprise. Cliquez sur Suivant .
7. Sur l’écran Prêt à configurer, cliquez sur Installer .
8. Une fois l’installation terminée, cliquez sur Quitter .
9. Une fois l’installation terminée, déconnectez-vous puis reconnectez-vous avant d’utiliser le gestionnaire
Synchronization Service Manager ou l’éditeur de règles de synchronisation.
Vérifier les utilisateurs créés et l’exécution de la synchronisation

Nous allons maintenant vérifier que les utilisateurs de l’annuaire local ont été synchronisés et existent
maintenant dans le locataire Azure AD. Cette opération peut prendre quelques heures. Pour vérifier que les
utilisateurs sont synchronisés, procédez comme suit.
2. À gauche, sélectionnez Azure Active Director y
4. Vérifiez que les nouveaux utilisateurs apparaissent dans le client.
Tester la connexion avec un des utilisateurs

1. Accédez à https://myapps.microsoft.com.
2. Connectez-vous avec un compte d’utilisateur créé dans le nouveau locataire. Vous devez vous connecter en
utilisant le format suivant : (user@domain.onmicrosoft.com). Saisissez le même mot de passe que celui
utilisé par l’utilisateur pour se connecter en local.
Vous avez maintenant configuré un environnement d’identité hybride que vous pouvez utiliser à des fins de test
et pour vous familiariser avec les fonctionnalités d’Azure.
Étapes suivantes
Matériel et conditions préalables
Paramètres Express
Synchronisation de hachage de mot de passe|
Tutoriel : Intégrer une forêt AD unique avec
l’authentification directe (PTA)
Ce didacticiel vous guidera dans la création d’un environnement d’identité hybride à l’aide de l’authentification
directe. Cet environnement peut ensuite servir à des fins de test ou pour se familiariser avec le fonctionnement
d’une identité hybride.
Prérequis
Un abonnement Azure
Un domaine personnalisé qui peut être vérifié
NOTE

qui sera utilisée en tant que serveur Active Directory local.
NOTE
Si vous n’avez jamais exécuté de script dans PowerShell sur votre machine hôte, vous devrez exécuter
Set-ExecutionPolicy remotesigned et répondre Oui dans PowerShell, avant d’exécuter des scripts.
Effectuez les actions suivantes :

#Declare variables
$VMName = 'DC1'
$Path = 'D:\VM'
$VHDSize = '64424509440'






7. Acceptez les termes du contrat de licence et cliquez sur Suivant .

suivantes :
2. Exécutez Set-ExecutionPolicy remotesigned et répondez Oui à tous les [A]. Appuyez sur Entrée.
#Declare variables
$ipaddress = "10.0.1.117"
$ipprefix = "24"
$ipgw = "10.0.1.1"
$ipdns = "10.0.1.117"
$ipdns2 = "8.8.8.8"
$newname = "DC1"



#Install features

Restart-Computer

#Declare variables
$DomaninNetBIOSName = "CONTOSO"


DomainName $DomainName -SafeModeAdministratorPassword $SecureString -DomainNetbiosName $DomainNetBIOSName -

actions suivantes :
#Declare variables
$Surname = "McCray"
$Name = "amccray"
#Create the user

$SecureString



temporaire.
Ajoutez le nom de domaine personnalisé à votre annuaire.

Maintenant que nous disposons d’un locataire et d’un administrateur général, nous devons ajouter notre
domaine personnalisé afin qu’Azure puisse le vérifier. Effectuez les actions suivantes :
1. De retour sur le Portail Azure, veillez à fermer le panneau Tous les utilisateurs .
2. Sur la gauche, sélectionnez Noms de domaine personnalisé .
3. Sélectionnez Ajouter un domaine personnalisé .
4. Sous Noms de domaine personnalisé , saisissez le nom de votre domaine personnalisé dans la zone, et
cliquez sur Ajouter un domaine .
5. À l’écran du nom de domaine personnalisé, vous obtiendrez une information MX ou TXT. Cette information
doit être ajoutée aux informations DNS du registre du domaine sous votre domaine. Vous devez donc aller
dans votre registre de domaine, et saisir l’information TXT ou MX dans les réglages DNS de votre domaine.
Cela permettra à Azure de vérifier votre domaine. Cette opération peut durer jusqu’à 24 heures. Pour plus
d’informations, consultez la documentation Ajouter un domaine personnalisé.
6. Pour vous assurer qu’il a été vérifié, cliquez sur le bouton Vérifier.

Continuer .
4. Sur l’écran Paramètres Express, cliquez sur Personnaliser .
5. Sur l’écran Installer les composants nécessaires. Cliquez sur Installer .
6. Sur l’écran Connexion utilisateur, sélectionnez Authentification directe et Activer l’authentification
unique , puis cliquez sur Suivant .
7. Sur l’écran Connexion à Azure AD, entrez le nom d’utilisateur et le mot de passe de l’administrateur général
que nous avons créé ci-dessus, et cliquez sur Suivant .
8. Sur l’écran Connecter vos répertoires, cliquez sur Ajouter un réper toire . Sélectionnez ensuite Créer un
compte AD et saisissez le nom d’utilisateur et le mot de passe contoso\Administrator et cliquez sur OK .
10. Sur l’écran Configuration de la connexion à Azure AD, sélectionnez Continuer sans faire correspondre
tous les suffixes UPN à des domaines vérifiés et cliquez sur Suivant .
11. Sur l’écran Filtrage domaine et unité organisationnelle, cliquez sur Suivant .
12. Sur l’écran Identification unique de vos utilisateurs, cliquez sur Suivant .
13. Sur l’écran Filtrer les utilisateurs et appareils, cliquez sur Suivant .
14. Sur l’écran Fonctionnalités facultatives, cliquez sur Suivant .
15. Sur la page Activer les informations d’identification d’authentification unique, saisissez le nom d’utilisateur et
le mot de passe contoso\Administrateur, et cliquez sur Suivant .

4. Vérifiez que les nouveaux utilisateurs apparaissent dans le client

Étapes suivantes
Paramètres personnalisés
Tutoriel : Fédérer un environnement de forêt AD
unique dans le cloud
Ce didacticiel vous guidera dans la création d’un environnement d’identité hybride à l’aide de la fédération. Cet
environnement peut ensuite servir à des fins de test ou pour se familiariser avec le fonctionnement d’une
identité hybride.
Prérequis
Un abonnement Azure
Un domaine personnalisé qui peut être vérifié
NOTE

qui sera utilisée en tant que serveur Active Directory local.
NOTE
Si vous n’avez jamais exécuté de script dans PowerShell sur votre machine hôte, vous devrez exécuter
Set-ExecutionPolicy remotesigned et répondre Oui dans PowerShell, avant d’exécuter des scripts.

#Declare variables
$VMName = 'DC1'
$Path = 'D:\VM'
$VHDSize = '64424509440'






7. Cliquez sur J’accepte les termes du contrat de licence , puis sur Suivant .

suivantes :
2. Exécutez Set-ExecutionPolicy remotesigned et répondez Oui à tous les [A]. Appuyez sur Entrée.
#Declare variables
$ipaddress = "10.0.1.117"
$ipprefix = "24"
$ipgw = "10.0.1.1"
$ipdns = "10.0.1.117"
$ipdns2 = "8.8.8.8"
$newname = "DC1"



#Install features

Restart-Computer

#Declare variables
$DomainNetBIOSName = "CONTOSO"
$Password = ConvertTo-SecureString "Passw0rd" -AsPlainText -Force


DomainName $DomainName -SafeModeAdministratorPassword $Password -DomainNetbiosName $DomainNetBIOSName -

actions suivantes :
#Declare variables
$Surname = "McCray"
$Name = "amccray"
#Create the user

$SecureString

Créer un certificat pour AD FS

Nous allons maintenant créer un certificat TLS/SSL qui sera utilisé par AD FS. Il s’agira d’un certificat auto-signé,
destiné uniquement aux tests. Microsoft ne recommande pas à l’utilisation d’un certificat auto-signé dans un
environnement de production. Effectuez les actions suivantes :
#Declare variables
$DNSname = "adfs.contoso.com"
$Location = "cert:\LocalMachine\My"
#Create certificate
New-SelfSignedCertificate -DnsName $DNSname -CertStoreLocation $Location



temporaire.
Ajoutez le nom de domaine personnalisé à votre annuaire.

Maintenant que nous disposons d’un locataire et d’un administrateur général, nous devons ajouter notre
domaine personnalisé afin qu’Azure puisse le vérifier. Effectuez les actions suivantes :
1. De retour sur le Portail Azure, veillez à fermer le panneau Tous les utilisateurs .
2. Sur la gauche, sélectionnez Noms de domaine personnalisé .
3. Sélectionnez Ajouter un domaine personnalisé .
4. Sous Noms de domaine personnalisé , saisissez le nom de votre domaine personnalisé dans la zone, et
cliquez sur Ajouter un domaine .
5. À l’écran du nom de domaine personnalisé, vous obtiendrez une information MX ou TXT. Cette information
doit être ajoutée aux informations DNS du registre du domaine sous votre domaine. Vous devez donc aller
dans votre registre de domaine, et saisir l’information TXT ou MX dans les réglages DNS de votre domaine.
Cela permettra à Azure de vérifier votre domaine. Cette opération peut durer jusqu’à 24 heures. Pour plus
d’informations, consultez la documentation Ajouter un domaine personnalisé.
6. Pour vous assurer qu’il a été vérifié, cliquez sur le bouton Vérifier.

Continuer .
4. Sur l’écran Paramètres Express, cliquez sur Personnaliser .
5. Sur l’écran Installer les composants nécessaires. Cliquez sur Installer .
6. Sur l’écran Connexion utilisateur, sélectionnez Fédération avec AD FS et cliquez sur Suivant .
7. Sur l’écran Connexion à Azure AD, entrez le nom d’utilisateur et le mot de passe de l’administrateur
général que nous avons créé ci-dessus, et cliquez sur Suivant .
8. Sur l’écran Connecter vos répertoires, cliquez sur Ajouter un réper toire . Sélectionnez ensuite Créer
un compte AD et saisissez le nom d’utilisateur et le mot de passe contoso\Administrator et cliquez sur
OK .
10. Sur l’écran Configuration de la connexion à Azure AD, sélectionnez Continuer sans faire
correspondre tous les suffixes UPN à des domaines vérifiés et cliquez sur Suivant .
11. Sur l’écran Filtrage domaine et unité organisationnelle, cliquez sur Suivant .
12. Sur l’écran Identification unique de vos utilisateurs, cliquez sur Suivant .
13. Sur l’écran Filtrer les utilisateurs et appareils, cliquez sur Suivant .
14. Sur l’écran Fonctionnalités facultatives, cliquez sur Suivant .
15. Sur la page Informations d’identification de l’administrateur de domaine, saisissez le nom d’utilisateur et
le mot de passe contoso\Administrator, et cliquez sur Suivant .
16. Dans l’écran Batterie de serveurs AD FS, assurez-vous que Configurer une nouvelle batterie de
ser veurs AD FS est sélectionné.
17. Sélectionnez Utiliser un cer tificat installé sur les ser veurs de fédération et cliquez sur Parcourir .
18. Entrez DC1 dans la zone de recherche, et sélectionnez-le lorsque vous l’avez trouvé. Cliquez sur OK .
19. Dans la liste déroulante Fichier de cer tificat , sélectionnez le certificat adfs.contoso.com créé
précédemment. Cliquez sur Suivant .
20. Dans l’écran Serveur AD FS, cliquez sur Parcourir . Entrez DC1 dans la zone de recherche et sélectionnez-
le lorsque vous l’avez trouvé. Cliquez sur OK . Cliquez sur Suivant .
21. Dans l’écran Serveurs proxy d’application Web, cliquez sur Suivant .
22. Dans l’écran Compte de service AD FS, saisissez le nom d’utilisateur et le mot de passe
contoso\Administrator, puis cliquez sur Suivant .
23. Dans l’écran Domaine Azure AD, sélectionnez votre domaine personnalisé vérifié dans la liste déroulante,
puis cliquez sur Suivant .

4. Vérifiez que les nouveaux utilisateurs apparaissent dans le client

Étapes suivantes
Fédération avec Azure AD Connect
Tutoriel : Configurer PHS en tant que sauvegarde
pour AD FS dans Azure AD Connect
Ce tutoriel explique comment configurer la synchronisation de hachage de mot de passe en tant que
sauvegarde et basculement pour AD FS. Ce document explique également comment activer la synchronisation
de hachage de mot de passe en tant que méthode d’authentification principale, si AD FS a échoué ou n'est plus
disponible.
NOTE
Bien que ces étapes soient généralement effectuées en cas d’urgence ou de panne, il est recommandé de les tester et de
vérifier vos procédures avant qu’une panne ne se produise.
NOTE
Si vous n’avez pas accès au serveur Azure AD Connect ou si celui-ci n’a pas accès à Internet, vous pouvez contacter le
support Microsoft pour qu’il vous aide à apporter des changements à la partie Azure AD.
Prérequis
Ce tutoriel s'appuie sur le tutoriel : Fédérer un environnement de forêt AD unique dans le cloud, un prérequis
avant de suivre le présent tutoriel. Si vous n’avez pas terminé ce tutoriel, faites-le avant de suivre la procédure
décrite dans ce document.
IMPORTANT
Avant de passer à PHS, vous devez créer une sauvegarde de votre environnement AD FS. Pour cela, vous pouvez utiliser
l’outil de restauration rapide AD FS.
Activer PHS dans Azure AD Connect

La première étape, maintenant que nous disposons d'un environnement Azure AD Connect utilisant la
fédération, consiste à activer la synchronisation de hachage de mot de passe et à autoriser Azure AD Connect à
synchroniser les hachages.
1. Double-cliquez sur l’icône Azure AD Connect créée sur le bureau.
2. Cliquez sur Configurer .
3. Sur la page Tâches supplémentaires, sélectionnez Personnalisation des options de synchronisation ,
4. Entrez le nom d’utilisateur et le mot de passe de votre administrateur général. Ce compte a été créé ici dans
le précédent didacticiel.
5. Dans l’écran Connecter vos réper toires , cliquez sur Suivant .
6. Dans l'écran Filtrage domaine ou unité organisationnelle , cliquez sur Suivant .
7. Dans l’écran Fonctionnalités facultatives , cochez Synchronisation de hachage de mot de passe , puis
cliquez sur Suivant .
8. Dans l’écran Prêt à configurer , cliquez sur Configurer .

9. Une fois la configuration terminée, cliquez sur Quitter .
10. Et voilà ! Vous avez terminé. La synchronisation de hachage de mot de passe intervient et peut être utilisée
en tant que sauvegarde si AD FS n’est plus disponible.
Activer la synchronisation de hachage de mot de passe

Nous allons maintenant vous expliquer comment basculer vers la synchronisation de hachage de mot de passe.
Avant de commencer, réfléchissez aux conditions dans lesquelles vous devez effectuer le basculement.
N’effectuez pas le basculement pour des raisons temporaires, par exemple en cas de panne du réseau, de
problème mineur lié à AD FS ou de problème qui affecte un sous-ensemble de vos utilisateurs. Si vous décidez
d’effectuer le basculement car la résolution du problème prendrait trop de temps, effectuez les étapes suivantes :
IMPORTANT
Sachez que la synchronisation des hachages de mot de passe avec Azure AD prend du temps. Autrement dit, vous devrez
peut-être attendre la fin de l’opération de synchronisation qui peut durer 3 heures avant de pouvoir vous authentifier à
l’aide de hachages de mot de passe.

3. Sélectionnez Modifier la connexion utilisateur , puis cliquez sur Suivant .
le précédent didacticiel.
5. Dans l'écran Connexion de l’utilisateur , sélectionnez Synchronisation de hachage de mot de passe
et cochez la case Ne pas conver tir les comptes d'utilisateur .
6. Vérifiez que l'option par défaut Activer l’authentification unique est bien sélectionnée, puis cliquez
Suivant .
7. Dans l'écran Activer l'authentification unique , cliquez sur Suivant .
9. Une fois la configuration terminée, cliquez sur Quitter .
10. Les utilisateurs peuvent désormais utiliser leurs mots de passe pour se connecter à Azure et aux services
Azure.

Revenir à la fédération
Nous allons maintenant vous montrer comment revenir à la fédération. Pour cela, effectuez les étapes
suivantes :
3. Sélectionnez Modifier la connexion utilisateur , puis cliquez sur Suivant .
le précédent tutoriel.
5. Sur l’écran Connexion utilisateur , sélectionnez Fédération avec AD FS et cliquez sur Suivant .
6. Sur la page Informations d’identification de l’administrateur de domaine, saisissez le nom d’utilisateur et le
mot de passe contoso\Administrator, et cliquez sur Suivant .
7. Sur l’écran de la batterie de serveurs AD FS, cliquez sur Suivant .
8. Sur l’écran Domaine Azure AD , sélectionnez le domaine dans la liste déroulante, puis cliquez sur Suivant .
10. Une fois la configuration terminée, cliquez sur Suivant .
11. Sur l’écran Vérifier la connectivité de fédération , cliquez sur Vérifier . Vous devrez peut-être configurer
des enregistrements DNS (ajouter des enregistrements A et AAAA) pour que cette opération aboutisse.
12. Cliquez sur Quitter .
Réinitialiser la confiance entre AD FS et Azure

Nous devons maintenant réinitialiser la confiance entre AD FS et Azure.
3. Sélectionnez Gérer la fédération et cliquez sur Suivant .
4. Sélectionnez Réinitialiser la confiance Azure AD et cliquez sur Suivant .
5. Sur l’écran Connexion à Azure AD , entrez le nom d’utilisateur et le mot de passe de votre administrateur
général.
6. Dans l’écran Se connecter à AD FS , entrez le nom d’utilisateur contoso\Administrator et le mot de passe,
7. Sur l’écran Cer tificats , cliquez sur Suivant .
Test de connexion avec un utilisateur

Étapes suivantes
Paramètres Express
Comment Azure AD permet une gestion gouvernée
par le cloud pour les charges de travail locales
Azure Active Directory (Azure AD) est une solution IDaaS (Identity as a Service) complète utilisée par des
millions d’organisations, qui couvre tous les aspects de l’identité, de la gestion des accès et de la sécurité.
Azure AD conserve les identités de plus d’un milliard d’utilisateurs. Ceux-ci peuvent se connecter et accéder de
façon sécurisée aux types de ressources suivants :
Ressources externes telles que Microsoft 365, le portail Azure et des milliers d’autres applications SaaS
(Software-as-a-Service).
Ressources internes telles que les applications situées sur le réseau d’entreprise et intranet d’une
organisation, ainsi que les applications cloud développées par votre propre organisation
Les organisations peuvent utiliser Azure AD si elles sont « entièrement cloud », ou effectuer un déploiement
« hybride » si elles disposent de charges de travail locales. Un déploiement hybride d’Azure AD peut faire partie
de la stratégie d’une organisation souhaitant migrer ses ressources informatiques vers le cloud, ou souhaitant
continuer à intégrer l’infrastructure locale existante aux nouveaux services cloud.
Depuis le début, les organisations « hybrides » ont vu Azure AD comme une extension de leur infrastructure
locale. Avec ces déploiements, les points de contrôle sont l’administration de la gouvernance des identités
locales, Windows Server Active Directory et d’autres systèmes d’annuaire internes. Les utilisateurs et les
groupes sont synchronisés à partir de ces systèmes avec un annuaire cloud tel qu’Azure AD. Une fois que ces
identités se trouvent dans le cloud, elles peuvent être mises à disposition dans Microsoft 365, Azure et d’autres
applications.
Actuellement, les organisations transfèrent une plus grande partie de leur infrastructure informatique et de
leurs applications vers le cloud, et un grand nombre d’entre elles souhaitent bénéficier de la sécurité améliorée
et de la gestion simplifiée qui sont fournies par l’IDaaS. Découvrez comment les fonctionnalités IDaaS
d’Azure AD peuvent accélérer votre transition vers une gestion gouvernée par le cloud, en fournissant des
solutions et des fonctionnalités qui permettent d’adopter rapidement la gestion des identités dans Azure AD,
tout en continuant de prendre en charge les applications existantes.
Ce document décrit la stratégie de Microsoft concernant l’IDaaS hybride et explique comment les organisations
peuvent utiliser Azure AD pour leurs applications existantes.
Approche Azure AD concernant la gestion des identités gouvernée

par le cloud
Lorsque les organisations effectuent leur transition vers le cloud, elles veulent être sûres de garder le contrôle
sur l’intégralité de leur environnement. Elles veulent également plus de sécurité et plus de visibilité sur les
activités, ce qui est facilité par l’automatisation et les insights proactifs. La « gestion gouvernée par le
cloud » désigne la façon dont les organisations gèrent et gouvernent les utilisateurs, les applications, les
groupes et les appareils à partir du cloud.
En raison de la prolifération des applications SaaS et du rôle grandissant que jouent la collaboration et les
identités externes, les organisations doivent pouvoir gérer efficacement à grande échelle. Le nouveau paysage
des risques liés au cloud nécessite que les organisations soient plus réactives. Un acteur malveillant qui
compromet un utilisateur cloud risque d’affecter aussi bien les applications cloud que les applications locales.
Les organisations hybrides doivent pouvoir déléguer et automatiser les tâches qui étaient auparavant effectuées
manuellement par le service informatique. Pour automatiser les tâches, elles ont besoin d’API et de processus
qui orchestrent le cycle de vie des différentes ressources liées aux identités (utilisateurs, groupes, applications,
appareils). Elles pourront ainsi déléguer la gestion quotidienne de ces ressources à plusieurs personnes
n’appartenant pas au service informatique. Azure AD répond à ces exigences via la gestion des comptes
d’utilisateur et l’authentification native pour les utilisateurs, sans nécessiter d’infrastructure d’identité locale. Ne
pas avoir à créer d’infrastructure locale peut être avantageux pour les organisations qui ont de nouvelles
communautés d’utilisateurs (telles que des partenaires commerciaux) qui ne figurent pas dans leur annuaire
local, mais dont l’accès est indispensable pour atteindre les objectifs de l’entreprise.
En outre, la gestion ne serait pas complète sans la gouvernance. Dans le monde actuel, la gouvernance est
intégrée au système d’identité, il ne s’agit plus d’un module complémentaire. La gouvernance des identités offre
aux organisations la possibilité de gérer les identités et d’accéder au cycle de vie des employés, des fournisseurs,
des partenaires commerciaux, des services et des applications :
L’incorporation de la gouvernance des identités permet aux entreprises d’effectuer plus facilement leur
transition vers la gestion gouvernée par le cloud. En outre, elle permet de réduire la taille du service
informatique et facilite la gestion des utilisateurs invités. Enfin, comparé à ce dont peuvent bénéficier les
utilisateurs dans une infrastructure locale, elle fournit des insights plus approfondis et une plus grande
automatisation. Aujourd’hui, la gouvernance signifie que les organisations bénéficient de la transparence, de la
visibilité et du contrôle nécessaires pour l’accès aux ressources de l’organisation. Avec Azure AD, les équipes
chargées des opérations de sécurité et d’audit disposent d’une visibilité sur qui a (et qui doit avoir) accès aux
ressources de l’organisation (et sur quels appareils), sur ce que ces utilisateurs font de cet accès et si
l’organisation utilise un système de contrôle adapté permettant de supprimer ou de limiter l’accès,
conformément aux stratégies de l’entreprise ou aux réglementations en vigueur.
Ce nouveau modèle de gestion est avantageux pour les organisations qui disposent à la fois d’applications SaaS
et d’applications LOB, car il leur permet de gérer et de sécuriser plus facilement l’accès à ces applications. En
intégrant les applications à Azure AD, les organisations pourront utiliser et gérer l’accès des identités cloud et
locales de manière cohérente. La gestion du cycle de vie des applications devient plus automatisée, et Azure AD
fournit des insights riches sur l’utilisation des applications, ce qui n’était pas facilement réalisable avec la gestion
des identités locales. Grâce à Azure AD, aux groupes Microsoft 365 et aux fonctionnalités en libre-service de
Teams, les organisations peuvent facilement créer des groupes pour la gestion de l’accès et la collaboration. En
outre, elles peuvent ajouter et supprimer des utilisateurs en fonction des exigences relatives à la gestion de
l’accès et à la collaboration.
Les fonctionnalités Azure AD à sélectionner pour la gestion gouvernée par le cloud varient en fonction des
applications à utiliser, et de la façon dont ces applications sont intégrées à Azure AD. Les sections suivantes
décrivent les approches à suivre pour les applications intégrées à Azure Directory, ainsi que les applications qui
utilisent des protocoles de fédération (par exemple, SAML, OAuth ou OpenID Connect).
Gestion gouvernée par le cloud pour les applications intégrées à

Active Directory
Azure AD améliore la gestion des applications locales intégrées à Active Directory via l’accès à distance sécurisé
et l’accès conditionnel. En outre, Azure AD fournit des fonctionnalités de gestion du cycle de vie des comptes et
de gestion des informations d’identification pour les comptes AD existants de l’utilisateur, notamment :
Accès à distance sécurisé et accès conditionnel pour les applications locales
Pour de nombreuses organisations, la gestion de l’accès aux applications de bureau distantes et aux applications
web locales intégrées à Azure Directory, à partir du cloud, nécessite en premier lieu le déploiement du proxy
d’application devant ces applications afin de fournir un accès à distance sécurisé.
Après une authentification unique à Azure AD, les utilisateurs peuvent accéder aux applications cloud et locales
par le biais d’une URL externe ou un portail d’applications interne. Par exemple, le proxy d’application fournit
l’accès à distance et l’authentification unique aux applications Bureau à distance, SharePoint, Tableau, Qlik, ainsi
qu’aux applications métier (LOB). En outre, les stratégies d’accès conditionnel peuvent inclure l’affichage de
conditions d’utilisation et un processus permettant de vérifier que l’utilisateur a accepté ces conditions avant de
lui permettre d’accéder à une application.
Gestion automatique du cycle de vie des comptes Active Director y
La gouvernance des identités aide les organisations à trouver un équilibre entre productivité (vitesse à laquelle
des personnes peuvent accéder aux ressources dont elles ont besoin) et sécurité (comment leur accès doit
évoluer au fil du temps, par exemple à la suite de modifications de leur statut professionnel). La gestion du cycle
de vie des identités constitue le fondement de la gouvernance des identités. Une gouvernance efficace à grande
échelle implique la modernisation de l’infrastructure de gestion du cycle de vie des identités pour les
applications.
Pour de nombreuses organisations, le cycle de vie des identités des employés est lié à la représentation de
l’utilisateur concerné dans un système de gestion du capital humain. Pour les organisations qui utilisent
Workday comme système de gestion du capital humain, Azure AD peut garantir que les comptes d’utilisateur
dans AD seront automatiquement provisionnés et déprovisionnés pour les employés dans Workday. En
procédant ainsi, vous améliorez la productivité des utilisateurs grâce à l’automatisation des comptes birthright
et vous réduisez les risques en garantissant que l’accès aux applications sera automatiquement mis à jour
lorsqu’un utilisateur change de rôle ou quitte l’organisation. Le plan de déploiement de l’attribution d’utilisateurs
pilotée par Workday est un guide pas à pas qui décrit, dans un processus en cinq étapes, les bonnes pratiques
nécessaires à l’implémentation de Workday dans la solution d’attribution d’utilisateurs Active Directory.
Azure AD Premium inclut également Microsoft Identity Manager, qui peut importer des enregistrements à partir
d’autres systèmes locaux de gestion du capital humain, tels que SAP, Oracle eBusiness et Oracle PeopleSoft.
De plus en plus, la collaboration entreprise-entreprise nécessite que vous accordiez un accès aux personnes
extérieures à votre organisation. La collaboration Azure AD B2B permet aux entreprises de partager de façon
sécurisée leurs applications et leurs services avec des utilisateurs invités et des partenaires externes, tout en
gardant le contrôle de leurs données.
Azure AD peut créer automatiquement des comptes dans Active Directory pour les utilisateurs invités en
fonction des besoins. Ainsi, les invités peuvent accéder aux applications locales intégrées à Active Directory, sans
avoir besoin d’un autre mot de passe. Les entreprises peuvent définir des stratégies d’authentification
multifacteur (MFA) pour les utilisateurs invités afin que les vérifications MFA soient effectuées lors de
l’authentification du proxy d’application. En outre, les révisions d’accès qui sont effectuées au sujet des
utilisateurs cloud B2B s’appliquent également aux utilisateurs locaux. Par exemple, si l’utilisateur cloud est
supprimé via vos stratégies de gestion du cycle de vie, l’utilisateur local est également supprimé.
Gestion des informations d’identification pour les comptes Active Director y La réinitialisation de mot
de passe en libre-service d’Azure AD permet aux utilisateurs qui ont oublié leur mot de passe de se
réauthentifier et de réinitialiser leur mot de passe. Dans ce cas, les mots de passe modifiés sont écrits dans
l’instance locale d’Active Directory. Le processus de réinitialisation du mot de passe peut également utiliser les
stratégies de mot de passe de l’instance locale d’Active Directory : Lorsqu’un utilisateur réinitialise son mot de
passe, celui-ci est vérifié afin de garantir qu’il répond à la stratégie Active Directory locale avant d’être validé
dans l’annuaire. Le plan de déploiement de réinitialisation de mot de passe en libre-service décrit les bonnes
pratiques relatives au déploiement d’une telle réinitialisation sur le Web et dans Windows.
Enfin, pour les organisations qui autorisent les utilisateurs à modifier leurs mots de passe dans Active Directory,
Active Directory peut être configuré pour utiliser la même stratégie de mot de passe que l’organisation dans
Azure AD via la fonctionnalité de protection de mot de passe Azure AD (actuellement en préversion publique).
Lorsqu’une entreprise s’apprête à déplacer une application intégrée à Active Directory vers le cloud en déplaçant
le système d’exploitation qui l’héberge vers Azure, Azure AD Domain Services fournit des services de domaine
compatibles avec AD (comme la jonction de domaine, la stratégie de groupe ou l’authentification LDAP et
Kerberos/NTLM). Azure Active Directory Domain Services s’intègre au locataire Azure AD existant de
l’organisation, permettant ainsi aux utilisateurs de se connecter à l’aide de leurs informations d’identification
d’entreprise. En outre, vous pouvez utiliser des comptes d’utilisateurs et des groupes existants pour sécuriser
l’accès aux ressources, et garantir un « lift-and-shift » plus simple des ressources locales vers les services
d’infrastructure Azure.
Gestion gouvernée par le cloud pour les applications locales basées

sur la fédération
Si l’organisation utilise déjà un fournisseur d’identité local, le déplacement des applications vers Azure AD
permet un accès plus sécurisé et une gestion facilitée de la fédération. Azure AD permet de configurer un
contrôle d'accès granulaire par application, incluant Azure AD Multi-Factor Authentication, à l'aide de la
fonctionnalité d'accès conditionnel Azure AD. Azure AD prend en charge davantage de fonctionnalités, y compris
les certificats de signature de jeton propres à l’application et les dates d’expiration de certificat configurables.
Ces fonctionnalités, outils et conseils permettent aux organisations de mettre hors service leurs fournisseurs
d’identité locaux. Pour vous donner un exemple, le service informatique de Microsoft a déplacé vers Azure AD
17 987 applications qui étaient situées sur son instance interne des services de fédération Active Directory
(ADFS).
Pour commencer la migration des applications fédérées vers Azure AD comme fournisseur d’identité, reportez-
vous à la page https://aka.ms/migrateapps qui comprend des liens vers :
Le livre blanc Migrating Your Applications to Azure Active Directory présente les avantages de la
migration et explique comment la planifier en quatre phases clairement expliquées : la découverte, la
classification, la migration et la gestion continue. Vous serez guidé pour savoir comment penser ce
processus et diviser votre projet en éléments faciles à utiliser. Le document contient des liens vers des
ressources importantes qui vous aideront tout au long du processus.
Le guide de solution Migrating Application Authentication from Active Directory Federation Services to
Azure Active Directory explore plus en détail les mêmes quatre phases de planification et d’exécution d’un
projet de migration d’application. Dans ce guide, vous allez voir comment appliquer ces phases au
déplacement d’une application entre Active Directory Federation Services (AD FS) et Azure AD.
Le script de préparation à la migration des services de fédération Active Directory peut être exécuté sur
des serveurs locaux AD FS existants pour déterminer l’état de préparation des applications en vue de leur
migration vers Azure AD.
Gestion continue de l’accès aux applications locales et aux

applications cloud
Les organisations ont besoin d’un processus pour gérer un accès scalable. Les utilisateurs cumulent les droits
d’accès et se retrouvent avec plus de droits que ce qui avait été initialement prévu pour eux. En outre, les
entreprises doivent pouvoir procéder efficacement à une mise à l’échelle pour être en mesure de développer et
d’appliquer des contrôles et une stratégie d’accès de manière continue.
En règle générale, le service informatique délègue aux décideurs d’entreprise la prise de décision en matière
d’approbation d’accès. De plus, le service informatique peut impliquer les utilisateurs eux-mêmes. Par exemple,
les utilisateurs accédant à des données client confidentielles dans l’application marketing d’une société en
Europe doivent connaître les stratégies de l’entreprise. Il est également possible que les utilisateurs invités
n’aient pas connaissance des exigences de traitement des données appliquées par l’organisation.
Les organisations peuvent automatiser le processus de cycle de vie des accès à l’aide de technologies comme les
groupes dynamiques, couplées à l’attribution des utilisateurs dans les applications SaaS, ou comme les
applications intégrées respectant le standard SCIM. Les organisations peuvent également contrôler les
utilisateurs invités pouvant accéder aux applications locales. Ces droits d’accès peuvent ensuite être révisés
régulièrement par le biais de révisions d’accès Azure AD récurrentes.
À l’avenir
Dans les environnements hybrides, la stratégie de Microsoft consiste à permettre les déploiements où le cloud
est le plan de contrôle de l’identité et les répertoires locaux et autres systèmes d’identité, tels qu’Active
Directory et autres applications locales, sont la cible de l’attribution des utilisateurs disposant d’un accès. Cette
stratégie continuera de garantir les droits, identités et accès dans les applications et les charges de travail qui
s’appuient sur eux. Le but est que les organisations puissent générer la productivité des utilisateurs finaux
entièrement à partir du cloud.
Étapes suivantes
Pour plus d’informations sur ce processus, consultez les plans de déploiement Azure AD, situés ici :
https://aka.ms/deploymentplans. Ces plans fournissent des instructions de bout en bout sur la façon de
déployer certaines fonctionnalités Azure Active Directory (Azure AD). Chaque plan aborde les notions de base
(valeur commerciale, planification, conception et procédures opérationnelles) nécessaires pour réussir le
lancement des fonctionnalités Azure AD les plus courantes. Microsoft met constamment à jour les plans de
déploiement en y ajoutant les bonnes pratiques rassemblées grâce aux commentaires qui nous sont envoyés
dans le cadre de la publication des nouvelles fonctionnalités de gestion à partir du cloud dans Azure AD.
Une base d’identité solide en quatre étapes avec
Azure Active Directory
La gestion de l’accès aux données et aux applications ne peut plus reposer sur les stratégies de limite de sécurité
réseau traditionnelles telles que les réseaux de périmètre et les pare-feux en raison du déplacement rapide des
applications dans le cloud. Les organisations doivent désormais faire confiance à leur solution d’identité pour
contrôler qui a accès et à quelles applications et données de l’organisation. De plus en plus d’organisations
autorisent leurs employés à utiliser leurs propres appareils au travail et depuis n’importe quel endroit où ils
peuvent se connecter à Internet. Veiller à ce que ces appareils soient conformes et sécurisé est devenu un facteur
important de la solution d’identité qu’une organisation décide d’implémenter. Dans l’environnement de travail
numérique d’aujourd’hui, l’identité est le principal plan de contrôle de toute organisation migrant vers le cloud.
En adoptant une solution d’identité hybride Azure Active Directory (Azure AD), les organisations peuvent
accéder à des fonctionnalités premium qui libèrent la productivité grâce aux fonctionnalités d’automatisation, de
délégation, de libre-service et d’authentification unique. Elle permet à vos employés d’accéder aux ressources
d’entreprise là où ils doivent effectuer leur travail tout en permettant à votre équipe informatique de contrôler
cet accès en s’assurant que les bonnes personnes disposent d’un accès approprié aux ressources appropriées
pour garantir une productivité en toute sécurité.
Sur les connaissances que nous avons acquises, cette liste de contrôle des meilleures pratiques vous permettra
de déployer rapidement les actions recommandées pour générer une base d’identité solide dans votre
organisation :
Se connecter facilement aux applications
Définir automatiquement une identité pour chaque utilisateur
Responsabiliser vos utilisateurs en toute sécurité
Rendre vos informations opérationnelles
Étape 1 - Se connecter facilement aux applications

En vous connectant à vos applications avec Azure AD, vous pouvez améliorer la productivité et la sécurité de
l’utilisateur final en activant l’authentification unique (SSO) et en approvisionnant des utilisateurs. Grâce à la
gestion centralisée de vos applications, dans Azure AD, vous pouvez réduire la charge administrative et obtenir
un point de contrôle unique de vos stratégies de sécurité et de conformité.
Cette section décrit vos options de gestion de l’accès utilisateur aux applications, d’activation d’un accès à
distance sécurisé aux applications internes et les avantages de la migration de vos applications vers Azure AD.
Mettre des applications à disposition de vos utilisateurs en toute transparence
Azure AD permet aux administrateurs d’ajouter des applications à la galerie d’applications d’entreprise dans le
portail Azure. L’ajout d’applications à la galerie d’applications d’entreprise vous permet de configurer plus
facilement les applications pour qu’elles utilisent Azure AD comme fournisseur d’identité. Cela permet
également de gérer l’accès utilisateur à l’application avec des stratégies d’accès conditionnel et de configurer
l’authentification unique (SSO) sur les applications afin que les utilisateurs ne soient pas obligés d’entrer à
chaque fois leur mot de passe et qu’ils soient automatiquement connectés aux applications locales et cloud.
Lorsque des applications sont ajoutées à la galerie Azure AD, les utilisateurs peuvent voir les applications qui
leur sont attribuées, et rechercher et demander d’autres applications si nécessaire. Azure AD propose aux
utilisateurs plusieurs méthodes d’accès à leurs applications :
Panneau d’accès/Mes applications
Lanceur d’applications Microsoft 365
Authentification directe pour les applications fédérées
Liens d’authentification directe
Pour en savoir plus sur l’accès utilisateur aux applications, consultez Étape 3 - Responsabiliser vos
utilisateurs dans cet article.
Migrer des applications des services de fédération Active Directory vers Azure AD
La migration de la configuration de l’authentification unique entre les services de fédération Active Directory
(AD FS) et Azure AD offre des fonctionnalités de sécurité supplémentaires, une facilité de gestion plus cohérente
et la collaboration. Pour obtenir des résultats optimaux, nous vous recommandons de migrer vos applications
d’AD FS vers Azure AD. La migration de l’authentification et l’autorisation de votre application vers Azure AD
vous offrent les avantages suivants :
Gestion des coûts
Gestion des risques
Optimisation de la productivité
Respect de la conformité et de la gouvernance
Pour en savoir plus, consultez le livre blanc Migration de vos applications vers Azure Active Directory.
Activer l’accès à distance sécurisé aux applications
Le proxy d’application Azure AD fournit une solution simple permettant aux organisations de publier des
applications locales sur le cloud pour les utilisateurs distants qui doivent accéder aux applications internes de
manière sécurisée. Après une authentification unique à Azure AD, les utilisateurs peuvent accéder aux
applications cloud et locales par le biais d’une URL externe ou d’un portail d’applications interne.
Le proxy d’application Azure AD offre les avantages suivants :
L’extension d’Azure AD à des ressources locales
La protection et la sécurité à l’échelle du cloud
Des fonctionnalités comme l’accès conditionnel et l’authentification multifacteur, faciles à activer
Aucun composant dans le réseau de périmètre tel que des solutions de VPN et de proxy inversé
traditionnelles
Aucune connexion entrante nécessaire
Authentification unique (SSO) sur les appareils, ressources et applications dans le cloud et localement
Permet aux utilisateurs finaux d’être productifs à tout moment et en tout lieu
Découvrir Shadow IT avec Microsoft Defender for Cloud Apps
Dans les entreprises modernes, les services informatiques n’ont souvent pas connaissance de toutes les
applications cloud utilisées par les utilisateurs pour effectuer leur travail. Lorsque l’on demande aux
administrateurs informatiques quel nombre d’applications les employés utilisent, selon eux, ils répondent
généralement 30 ou 40. En réalité, plus de 1 000 applications distinctes sont en moyenne utilisées par les
employés de votre organisation. 80 % des employés utilisent des applications non approuvées que personne n’a
révisées et qui peuvent ne pas être conformes à vos stratégies de sécurité et de conformité.
Microsoft Defender for Cloud Apps peut vous aider à identifier les applications utiles et couramment utilisées
par les utilisateurs que l’équipe informatique pourrait approuver et ajouter à la galerie des applications
d’entreprise pour que les utilisateurs bénéficient de fonctionnalités comme l’authentification unique et l’accès
conditionnel.
« Defender for Cloud Apps nous permet de nous assurer que nos collaborateurs utilisent correctement nos
applications cloud et SaaS, d’une manière conforme aux stratégies de sécurité fondamentales qui permettent de
protéger Accenture. » --- John Blasi, Directeur général, Sécurité des informations, Accenture
Outre la détection de l’informatique fantôme, Defender for Cloud Apps peut également déterminer le niveau de
risque des applications, empêcher tout accès non autorisé aux données d’entreprise, les fuites de données
possibles et autres risques de sécurité inhérents aux applications.
Étape 2 - Définir automatiquement une identité pour chaque

utilisateur
Le regroupement des annuaires locaux et basés sur le cloud dans une solution d’identité hybride Azure AD vous
permettra de réutiliser votre investissement Active Directory local en approvisionnant vos identités existantes
dans le cloud. La solution synchronise les identités locales avec Azure AD alors que l’équipe informatique gère
l’exécution locale d’Active Directory à l’aide des solutions de gouvernance existantes comme principale source
approuvée d’identités. La solution d’identité hybride Azure AD de Microsoft regroupe des fonctionnalités, locales
et cloud, de création d’une identité d’utilisateur commune pour l’authentification et l’autorisation d’accès à
toutes les ressources, indépendamment de leur emplacement.
L’intégration de vos annuaires locaux à Azure AD améliore la productivité de vos utilisateurs et les empêche
d’utiliser plusieurs comptes entre applications et services en leur fournissant une identité commune pour
accéder aux ressources cloud et locales. L’utilisation de plusieurs comptes est une problématique pour les
utilisateurs finaux et l’équipe informatique. Du point de vue de l’utilisateur final, disposer de plusieurs comptes
implique de devoir mémoriser plusieurs mots de passe. Pour éviter ce problème, nombre d’utilisateurs
réutilisent le même mot de passe pour chaque compte, ce qui n’est pas correct en termes de sécurité. Du point
de vue de l’équipement informatique, la réutilisation entraîne généralement un plus grand nombre de
réinitialisations des mots de passe, des coûts de support supérieurs et plus de réclamations d’utilisateur final.
Azure AD Connect est l’outil utilisé pour synchroniser vos identités locales avec Azure AD, qui peuvent ensuite
être utilisées pour accéder aux applications cloud. Une fois que les identités se trouvent dans Azure AD, elles
peuvent être approvisionnées pour des applications SaaS telles que Salesforce ou Concur.
Dans cette section, nous présentons les suggestions de fourniture de la haute disponibilité, de l’authentification
moderne pour le cloud et de réduction de votre empreinte locale.
NOTE
Si vous souhaitez en savoir plus sur Azure AD Connect, consultez Qu’est-ce que la synchronisation d’Azure AD Connect ?
Configurer un serveur intermédiaire pour Azure AD Connect et le maintenir à jour

Azure AD Connect joue un rôle clé dans le processus d’approvisionnement. Si le serveur de synchronisation est
déconnecté pour une quelconque raison, les modifications apportées en local ne sont mises à jour dans le cloud
et entraînent des problèmes d’accès pour les utilisateurs. Il est important de définir une stratégie de
basculement qui permet aux administrateurs de reprendre rapidement la synchronisation lorsque le serveur de
synchronisation est déconnecté.
Pour fournir la haute disponibilité en cas de déconnexion de votre serveur Azure AD Connect principal, il est
recommandé de déployer un serveur intermédiaire distinct pour Azure AD Connect. Le déploiement d’un
serveur permet à l’administrateur de « promouvoir » le serveur intermédiaire en production d’un simple
changement de configuration. Disposer d’un serveur de secours configuré en mode intermédiaire vous permet
également de tester et de déployer de nouvelles modifications de configuration et d’introduire un nouveau
serveur si l’ancien est mis hors service.
TIP
Azure AD Connect est régulièrement mis à jour. Par conséquent, il est vivement recommandé de maintenir le serveur
intermédiaire à jour pour pouvoir bénéficier des améliorations de performances, des correctifs de bogues et des nouvelles
fonctionnalités fournies par chaque nouvelle version.
Activer l’authentification cloud

Les organisations disposant d’Active Directory en local doivent étendre leur annuaire à Azure AD à l’aide d’Azure
AD Connect et configurer la méthode d’authentification appropriée. La choix de la méthode d’authentification
appropriée pour votre organisation est la première étape dans votre processus de déplacement d’applications
vers le cloud. Il s’agit d’un composant critique car il contrôle l’accès à l’ensemble des données et des ressources
du cloud.
La méthode la plus simple et recommandée d’activation de l’authentification cloud pour les objets d’annuaire
local dans Azure AD consiste à activer la synchronisation de hachage du mot de passe. Certaines organisations
peuvent également envisager d’activer l’authentification directe.
Que vous choisissiez la synchronisation de hachage du mot de passe ou l’authentification directe, n’oubliez pas
d’activer l’authentification unique transparente pour permettre aux utilisateurs d’accéder aux applications cloud
sans saisir constamment leurs nom d’utilisateur et mot de passe dans l’application lorsqu’ils utilisent des
appareils Windows 7 et 8 sur votre réseau d’entreprise. Sans l’authentification unique, les utilisateurs doivent
mémoriser des mots de passe spécifiques aux applications et se connecter à chaque application. L’équipe
informatique doit également créer et mettre à jour les comptes d’utilisateur pour chaque application, comme
Microsoft 365, Box et Salesforce. Les utilisateurs doivent mémoriser leurs mots de passe et passer du temps à se
connecter à chaque application. La fourniture d’un mécanisme d’authentification unique standardisé à l’échelle
de l’entreprise est essentielle pour une meilleure expérience utilisateur, réduire les risques, la possibilité de
signaler et la gouvernance.
Pour les organisations qui utilisent déjà AD FS ou un autre fournisseur d’authentification local, le basculement
vers Azure AD comme fournisseur d’identité peut réduire la complexité et améliorer la disponibilité. Sauf si vous
rencontrez des cas d’usage spécifiques de fédération, nous vous recommandons de migrer de l’authentification
fédérée vers la synchronisation de hachage du mot de passe ou l’authentification directe et l’authentification
unique transparente ou l’authentification directe et l’authentification unique transparente pour tirer profit des
avantages d’empreinte locale réduite et de la flexibilité du cloud avec de meilleures expériences utilisateurs. Pour
plus d’informations, consultez Migrer de la fédération à la synchronisation de hachage de mot de passe pour
Azure Active Directory.
Activer le déprovisionnement automatique de comptes
L’activation de l’approvisionnement et du déprovisionnement automatisés sur vos applications est la meilleure
stratégie de contrôle du cycle de vie des identités sur plusieurs systèmes. Azure AD prend en charge
l’approvisionnement et le déprovisionnement basés sur des stratégies automatisés de comptes d’utilisateur sur
diverses applications SaaS populaires telles que ServiceNow et Salesforce, et d’autres qui implémentent le
protocole SCIM 2.0. Contrairement aux solutions d’approvisionnement traditionnelles, qui nécessitent du code
personnalisé ou le chargement manuel de fichiers CSV, le service d’approvisionnement est hébergé dans le
cloud et inclut des connecteurs pré-intégrés pouvant être configurés et gérés à l’aide du portail Azure. Un
avantage clé du déprovisionnement automatique est qu’il permet de sécuriser votre organisation en supprimant
instantanément les identités des utilisateurs des applications SaaS lorsqu’ils quittent l’organisation.
Pour en savoir plus sur l’approvisionnement automatique de comptes d’utilisateur, consultez Automatisation de
l’approvisionnement et de l’annulation de l’approvisionnement des utilisateurs pour les applications SaaS avec
Étape 3 - Responsabiliser vos utilisateurs en toute sécurité

Dans l’environnement de travail numérique d’aujourd’hui, il est important de trouver un équilibre entre sécurité
et productivité. Cependant, les utilisateurs finaux contournent souvent les mesures de sécurité qui ralentissent
leur productivité et leur accès aux applications cloud. Pour résoudre ce problème, Azure AD fournit des
fonctionnalités en libre-service qui permettent aux utilisateurs de rester productifs tout en réduisant la charge
administrative.
Cette section présente les suggestions d’élimination des frictions pour votre organisation en responsabilisant
vos utilisateurs tout en restant vigilant.
Activer la réinitialisation du mot de passe en libre -service pour tous les utilisateurs
La réinitialisation du mot de passe en libre-service (SSPR) d’Azure offre aux administrateurs informatiques un
moyen simple pour permettre aux utilisateurs de réinitialiser et de déverrouiller leurs comptes ou leurs mots de
passe, sans intervention de l’administrateur. Le système inclut des rapports détaillés de suivi d’accès au système,
ainsi que des notifications pour vous prévenir de toute utilisation malveillante ou de tout abus.
Par défaut, Azure AD déverrouille les comptes quand il effectue une réinitialisation de mot de passe. Cependant,
lorsque vous activez l’intégration locale d’Azure AD Connect, vous pouvez également différencier ces deux
opérations, permettant ainsi aux utilisateurs de déverrouiller leur compte sans devoir réinitialiser le mot de
passe.
S’assurer que tous les utilisateurs sont inscrits pour l’authentification multifacteur (MFA ) et la réinitialisation
de mot de passe en libre -service (SSPR )
Azure fournit des rapports qui peuvent être utilisés par vous et votre organisation pour s’assurer que les
utilisateurs sont inscrits pour l’authentification multifacteur (MFA) et la réinitialisation de mot de passe en libre-
service (SSPR) Les utilisateurs qui ne sont pas inscrits devront peut-être être formés sur le processus.
Le rapport de connexions d’authentification multifacteur inclut des informations sur l’utilisation de
l’authentification multifacteur (MFA) et sur son fonctionnement dans votre organisation. Avoir accès à l’activité
de connexion (et aux audits et détections des risques) pour Azure AD est essentiel pour la résolution des
problèmes, l’analyse de l’utilisation et les investigations d’analyse.
De même, le rapport de gestion des mots de passe en libre-service peut être utilisé pour déterminer qui est (ou
n’est pas) inscrit pour la réinitialisation de mot de passe en libre-service (SSPR).
Gestion des applications en libre -service
Pour permettre à vos utilisateurs de découvrir eux-mêmes des applications depuis leur panneau d’accès, vous
devez activer l’option d’accès aux applications en libre-service pour toutes les applications pour lesquelles vous
souhaitez autoriser les utilisateurs à les découvrir eux-mêmes et en demander l’accès. L’accès aux applications
en libre-service est un excellent moyen pour permettre aux utilisateurs de découvrir eux-mêmes des
applications et éventuellement de permettre au groupe d’entreprise d’approuver l’accès à ces applications. Vous
pouvez autoriser le groupe d’entreprise à gérer les informations d’identification affectées à ces utilisateurs dans
le cadre d’une authentification unique par mot de passe, directement depuis leurs panneaux d’accès.
Gestion des groupes en libre service
L’attribution d’utilisateurs à des applications est plus précise à l’aide de groupes, car ceux-ci offre une grande
flexibilité et une possibilité de gestion à l’échelle :
Basé sur des attributs utilisant l’appartenance à un groupe dynamique
Délégation aux propriétaires d’application
Azure AD fournit la possibilité de gérer l’accès aux ressources à l’aide de groupes de sécurité et de groupes
Microsoft 365. Ces groupes peuvent être gérés par un propriétaire du groupe qui peut approuver ou refuser des
requêtes d’appartenance et déléguer le contrôle de l’appartenance au groupe. Également appelée gestion de
groupes en libre-service, cette fonctionnalité permet de gagner du temps en permettant aux propriétaires de
groupe qui n’ont pas un rôle d’administrateur de créer et gérer des groupes sans avoir à demander aux
administrateurs de gérer leurs requêtes.
Étape 4 - Rendre vos informations opérationnelles
L’audit et la journalisation des événements liés à la sécurité et des alertes connexes sont des composants
essentiels d’une stratégie efficace pour s’assurer que les utilisateurs restent productifs et que votre organisation
est sécurisée. Les journaux et rapports de sécurité peuvent vous aider à répondre à des questions telles que :
Utilisez-vous ce pour quoi que payez ?
Des événements suspects ou malveillants se produisent-ils dans mon locataire ?
Qui a été affecté pendant un incident de sécurité ?
Les journaux d’activité et les rapports de sécurité vous fournissent un enregistrement électronique des activités
suspectes et vous aident à détecter les motifs pouvant indiquer une tentative d’intrusion ou une intrusion
externe effective sur le réseau, ainsi que des attaques internes. Vous pouvez avoir recours aux audits pour
surveiller les activités des utilisateurs, documenter la conformité aux exigences réglementaires, effectuer des
analyses d’investigation, etc. Les alertes fournissent des notifications des événements de sécurité.
Attribuer des rôles administrateur moins privilégiés pour les opérations
Dans votre approche des opérations, prenez en compte deux niveaux d’administration. Dans le premier niveau,
les tâches fastidieuses d’administration sont confiées à votre ou vos administrateurs généraux. Toujours utiliser
le rôle Administrateur général peut convenir aux petites entreprises. Mais pour les grandes organisations dans
lesquelles le personnel du support technique et les administrateurs sont responsables de tâches spécifiques,
l’attribution du rôle d’administrateur général peut poser un risque de sécurité car il permet à ces personnes de
gérer des tâches au-dessus et au-delà de ce qu’ils sont capables de faire.
Dans ce cas, vous devez envisager le niveau d’administration suivant. À l’aide d’Azure AD, vous pouvez désigner
des utilisateurs finaux comme des « administrateurs limités » qui peuvent gérer des tâches dans des rôles moins
privilégiés. Par exemple, vous pouvez attribuer à votre personnel du support technique le rôle Lecteur Sécurité
pour lui permettre de gérer des fonctionnalités liées à la sécurité avec un accès en lecture seule. Il peut
également être judicieux d’attribuer le rôle Administrateur d’authentification à des personnes pour leur
permettre de réinitialiser des informations d’identification autres qu’un mot de passe, ou de consulter et de
configurer Azure Service Health.
Pour en savoir plus, consultez Autorisations des rôles d’administrateur dans Azure Active Directory.
Surveiller des composants hybrides (synchronisation d’Azure AD Connect, AD FS ) avec Azure AD Connect
Health
Azure AD Connect et AD FS sont des composants critiques qui peuvent éventuellement interrompre la gestion
du cycle de vie et l’authentification, et ainsi entraîner des pannes. Par conséquent, vous devez déployer Azure AD
Connect Health pour surveiller et générer des rapports de ces composants.
Pour en savoir plus, lisez Surveiller AD FS avec Azure AD Connect Health.
Utiliser Azure Monitor pour collecter des journaux de données pour analyse
Azure Monitor est un portail de surveillance unifié pour tous les journaux d’Azure AD qui fournit des
informations détaillées, des analyses avancées et le Machine Learning intelligent. Avec Azure Monitor, vous
pouvez utiliser des métriques et des journaux dans le portail et via des API pour obtenir plus de visibilité sur
l’état et les performances de vos ressources. Il offre une expérience transparente sur le portail tout en
permettant l’intégration d’un large éventail d’intégrations de produits via des API et des options d’exportation
données prenant en charge des systèmes SIEM tiers traditionnels. Azure Monitor vous permet également de
configurer des règles d’alerte afin d’être informé ou d’appliquer des mesures automatisées sur les problèmes
affectant vos ressources.
Créer des tableaux de bord personnalisés pour votre équipe de direction et votre travail quotidien
Les organisations n’ayant pas de solution SIEM peuvent télécharger le Pack de contenu Power BI pour Azure AD.
Le pack de contenu Power BI contient des rapports prédéfinis conçus pour vous aider à comprendre comment
vos utilisateurs adoptent et utilisent les fonctionnalités Azure AD, vous permettant ainsi d’obtenir des
informations sur toutes les activités au sein de votre annuaire. Vous pouvez également créer votre propre
tableau de bord personnalisé et le partager avec votre équipe de direction pour rapporter les activités
quotidiennes. Les tableaux de bord sont un excellent moyen pour surveiller votre activité et voir vos métriques
les plus importantes d’un clin d’œil. Les visualisations sur un tableau de bord peuvent provenir d’un ou
plusieurs jeux de données sous-jacents et d’un ou plusieurs rapports. Un tableau de bord combine des données
locales et cloud, fournissant ainsi une vue consolidée, quel que soit l’endroit où les données résident.
Comprendre vos pilotes d’appel au support

Lorsque vous implémentez une solution d’identité hybride comme indiqué dans cet article, vous remarquerez
finalement une réduction de vos appels au support. Les problèmes courants tels que les mots de passe oubliés
et les verrouillages de compte sont atténués grâce à l’implémentation de la réinitialisation de mot de passe
libre-service d’Azure, alors que l’activation de l’accès aux applications en libre-service permet aux utilisateurs de
découvrir eux-mêmes et de demander l’accès aux applications sans devoir passer par le service informatique.
Si vous ne constatez une réduction des appels au support, nous vous recommandons d’analyser vos pilotes
d’appel au support pour vérifier si la réinitialisation de mot de passe en libre-service (SSPR) ou l’accès aux
applications en libre-service a été correctement configuré ou si de nouveaux problèmes pouvant être
systématiquement résolus se posent.
« Pour notre transformation numérique, nous avions besoin d’un fournisseur d’identité et de gestion des accès
fiable pour faciliter l’intégration transparente déjà présente entre nous, nos partenaires et fournisseurs de
services cloud, pour obtenir un écosystème efficace. Azure AD a été la meilleure option en nous fournissant les
fonctionnalités et la visibilité nécessaires qui nous a permis de détecter et de répondre aux risques. » --- Yazan
Almasri, Directeur de la sécurité des informations globales, Aramex
Surveiller votre utilisation des applications pour obtenir des informations
Outre la découverte de l’informatique fantôme, la surveillance de l’utilisation des applications à l’échelle de
votre organisation à l’aide de Microsoft Defender for Cloud Apps peut aider le processus de migration de votre
organisation à tirer pleinement parti des applications cloud. Elle peut vous permettre de garder le contrôle sur
vos ressources grâce à une meilleure visibilité de l’activité et de renforcer la protection des données critiques
entre les applications cloud. La surveillance de l’utilisation des applications dans votre organisation à l’aide de
Defender for Cloud Apps peut vous aider à répondre aux questions suivantes :
Quelles applications non approuvées les employés utilisent-ils pour stocker des données ?
Où et quand des données sensibles sont stockées dans le cloud ?
Qui a accès à des données sensibles dans le cloud ?
« Avec Defender for Cloud Apps, nous pouvons repérer rapidement les anomalies et prendre des mesures. » ---
Eric LePenske, Cadre senior, Sécurité des informations, Accenture
Résumé
L’implémentation d’une solution d’identité hybride implique de nombreux aspects, mais cette liste de contrôle
en quatre étapes vous aidera à créer rapidement une infrastructure d’identité qui permettra aux utilisateurs
d’être plus productifs et sécurisés.
Se connecter facilement aux applications
Définir automatiquement une identité pour chaque utilisateur
Responsabiliser vos utilisateurs en toute sécurité
Rendre vos informations opérationnelles
Nous espérons que ce document sera de feuille de route utile au développement d’une base d’identité solide
pour votre organisation.
Liste de contrôle d’identité

Nous vous recommandons d’imprimer la liste de contrôle suivante pour référence dans le processus d’adoption
d’une base d’identité plus solide dans votre organisation.
Aujourd’hui
VO US AVEZ T ERM IN É ? ÉL ÉM EN T
Piloter la réinitialisation de mot de passe en libre-service

(SSPR) pour un groupe
Surveiller des composants hybrides avec Azure AD Connect

Health
Attribuer des rôles administrateur moins privilégiés pour les

opérations
Découvrir Shadow IT avec Microsoft Defender for Cloud

Apps
Utiliser Azure Monitor pour collecter des journaux de

données pour analyse
Deux prochaines semaines

Mettre une application à disposition de vos utilisateurs
Piloter l’approvisionnement Azure AD pour l’application SaaS

de votre choix
Configurer un serveur intermédiaire pour Azure AD Connect

et le maintenir à jour
Démarrer la migration d’applications d’AD FS vers Azure AD
Créer des tableaux de bord personnalisés pour votre équipe

de direction et votre travail quotidien
Mois prochain
Surveiller votre utilisation des applications pour obtenir des

informations
Piloter l’accès à distance sécurisé aux applications
S’assurer que tous les utilisateurs sont inscrits pour

l’authentification multifacteur (MFA) et la réinitialisation de
mot de passe en libre-service (SSPR)
Activer l’authentification cloud
Trois prochains mois

Activer la gestion des applications en libre-service
Activer la gestion des groupes en libre-service
Surveiller votre utilisation des applications pour obtenir des

informations
Comprendre vos pilotes d’appel au support

Étapes suivantes
Découvrez comment vous pouvez augmenter votre sécurité à l’aide des fonctionnalités d’Azure Active Directory
et de cette liste de contrôle en cinq étapes, Cinq étapes pour sécuriser votre infrastructure d’identité.
Découvrez comment les fonctionnalités d’identité dans Azure AD peuvent vous aider à accélérer votre migration
vers une gestion gouvernée par le cloud en fournissant les solutions et fonctionnalités qui permettent aux
organisations d’adopter rapidement et de migrer davantage leur gestion des identités entre des systèmes locaux
traditionnels et Azure AD, Comment Azure AD offre une gestion gouvernée par le cloud pour les charges de
travail locales.
Choisir la méthode d’authentification adaptée à
votre solution d’identité hybride Azure Active
Directory
La première étape pour les organisations souhaitant migrer leurs applications vers le cloud est de choisir une
méthode d’authentification appropriée. Cette décision ne doit pas être prise à la légère, et ce pour les raisons
suivantes :
1. Il s’agit de la première décision que doit prendre une organisation souhaitant migrer vers le cloud.
2. La méthode d’authentification est un composant essentiel de la présence d’une organisation dans le
cloud. Elle contrôle l’accès à l’ensemble des données et des ressources du cloud.
3. Elle constitue le fondement sur lequel reposent toutes les autres fonctionnalités avancées en matière de
sécurité et d’expérience utilisateur dans Azure AD.
L’identité constitue le nouveau plan de contrôle en matière de sécurité informatique et, dès lors,
l’authentification permet aux organisations de gérer les accès au cloud. Les organisations ont besoin d’un plan
de contrôle d’identité qui renforce leur sécurité et protège leurs applications cloud contre les intrus.
NOTE
Modifier votre méthode d’authentification implique une planification, des tests et de possibles temps d’arrêt. Le
déploiement intermédiaire constitue un excellent moyen de tester la migration des utilisateurs de l’authentification de la
fédération à l’authentification cloud.
Hors propos
Les organisations qui ne présentent aucune empreinte d’un annuaire local existant ne sont pas concernées par
cet article. En général, ces entreprises créent uniquement des identités résidant dans le cloud, ce qui n’exige pas
une solution d’identité hybride. Les identités résidant uniquement dans le cloud ne sont pas associées à des
identités locales correspondantes.
Méthodes d’authentification
En choisissant la solution d’identité hybride Azure AD comme nouveau plan de contrôle, l’authentification
constitue la base de l’accès au cloud. Le choix de la méthode d’authentification est une première décision
essentielle dans la configuration d’une solution d’identité hybride Azure AD. L’implémentation de la méthode
d’authentification est configurée à l’aide d’Azure AD Connect, qui provisionne également les utilisateurs dans le
cloud.
Pour choisir une méthode d’authentification, vous devez prendre en compte l’infrastructure existante, le temps
nécessaire à l’implémentation, sa complexité et les coûts associés. Ces facteurs sont différents pour chaque
organisation et peuvent varier au fil du temps.
Azure AD prend en charge les méthodes d’authentification suivantes pour les solutions d’identité hybride.
Authentification cloud
Quand vous choisissez cette méthode d’authentification, Azure AD gère le processus de connexion des
utilisateurs. Si vous l’associez à une authentification unique (SSO) fluide, les utilisateurs peuvent se connectent
aux applications cloud sans avoir à retaper leurs informations d’identification. L’authentification cloud propose
deux options :
Synchronisation de hachage de mot de passe Azure AD . Il s’agit du moyen le plus simple d’activer
l’authentification pour les objets d’annuaire locaux dans Azure AD. Elle permet aux utilisateurs d’utiliser les
mêmes nom d’utilisateur et mot de passe qu’ils utilisent localement sans avoir à déployer une infrastructure
supplémentaire. Certaines fonctionnalités Premium d’Azure AD, comme Identity Protection et Azure Active
Directory Domain Services, nécessitent la synchronisation de hachage du mot de passe, quelle que soit la
méthode d’authentification choisie.
NOTE
Les mots de passe ne sont jamais stockés en texte clair ni chiffrés avec un algorithme réversible dans Azure AD. Pour plus
d’informations sur le processus réel de la synchronisation de hachage du mot de passe, consultez Implémenter la
synchronisation de hachage du mot de passe avec la synchronisation Azure AD Connect.
Authentification directe Azure AD . Fournit une validation de mot de passe simple pour les services
d’authentification Azure AD à l’aide d’un agent logiciel qui s’exécute sur un ou plusieurs serveurs locaux. Les
serveurs valident les utilisateurs directement avec votre Active Directory local, ce qui garantit que la validation
du mot de passe ne se produit pas dans le cloud.
Cette méthode d’authentification convient pour les entreprises qui, pour des raisons de sécurité, requièrent
l’application immédiate d’heures d’ouverture de session, de stratégies de mot de passe et d’états des comptes
d’utilisateur locaux. Pour plus d’informations sur le processus réel de l’authentification directe, consultez
Connexion de l’utilisateur avec l’authentification directe Azure AD.
Authentification fédérée
Quand vous choisissez cette méthode d’authentification, Azure AD délègue le processus d’authentification à un
système d’authentification approuvée distinct, par exemple les services de fédération Active Directory (AD FS),
pour valider le mot de passe de l’utilisateur.
Le système d’authentification peut fournir des conditions d’authentification supplémentaires, comme
l’authentification par carte à puce ou une authentification multifacteur tierce. Pour plus d’informations, consultez
Déploiement des services de fédération Active Directory (AD FS).
L’arbre de décision présenté dans la section suivante vous aide à déterminer la méthode d’authentification
adaptée à vos besoins. Vous pouvez ainsi décider si vous devez déployer une authentification cloud ou une
authentification fédérée pour votre solution d’identité hybride Azure AD.
Arbre de décision
Détails relatifs aux questions de décision :
1. Azure AD peut gérer la connexion des utilisateurs sans s’appuyer sur des composants locaux pour vérifier les
mots de passe.
2. Azure AD peut transférer la connexion des utilisateurs à un fournisseur d’authentification approuvé tel qu’AD
FS de Microsoft.
3. Si vous devez appliquer des stratégies de sécurité Active Directory au niveau utilisateur, telles que l’expiration
de compte, la désactivation de compte, l’expiration de mot de passe, le verrouillage de compte et les heures
de connexion à chaque connexion d’utilisateur, Azure AD requiert certains composants locaux.
4. Fonctionnalités de connexion non prises en charge en mode natif par Azure AD :
Connexion à l’aide de cartes à puce ou de certificats.
Connexion à l’aide d’un serveur MFA local.
Connexion à l’aide d’une solution d’authentification tierce.
Solution d’authentification locale multisite.
5. Quelle que soit la méthode de connexion choisie, pour générer le rapport Utilisateurs avec des informations
d’identification divulguées, Azure AD Identity Protection nécessite une synchronisation du hachage de mot
de passe. Les organisations peuvent basculer vers une synchronisation du hachage de mot de passe si leur
méthode de connexion principale échoue alors qu’elle a été configurée avant l’événement d’échec.
NOTE
Azure AD Identity Protection nécessite des licences Azure AD Premium P2.
Considérations détaillées
Authentification cloud : Synchronisation de hachage de mot de passe
Effor t . La synchronisation de hachage du mot de passe nécessite le moins d’effort en matière de
déploiement, de maintenance et d’infrastructure. Ce niveau d’effort s’applique généralement aux
organisations dont les utilisateurs se connectent uniquement à Microsoft 365, à des applications SaaS et
à d’autres ressources Azure AD basées sur Active Directory. Une fois activée, la synchronisation de
hachage du mot de passe fait partie du processus de synchronisation Azure AD Connect et s’exécute
toutes les deux minutes.
Expérience utilisateur . Pour améliorer l’expérience de connexion des utilisateurs, déployez
l’authentification unique transparente avec synchronisation de hachage du mot de passe.
L’authentification unique transparente élimine les invites inutiles quand les utilisateurs sont connectés.
Scénarios avancés . Les organisations peuvent choisir d’utiliser les insights des identités avec les
rapports Azure AD Identity Protection avec Azure AD Premium P2, par exemple le rapport sur les
informations d’identification divulguées. Windows Hello Entreprise a des exigences spécifiques quand
vous utilisez la synchronisation de hachage du mot de passe. Azure Active Directory Domain Services
nécessite la synchronisation de hachage de mot de passe pour fournir aux utilisateurs leurs informations
d’identification dans le domaine managé.
Les organisations qui exigent une authentification multifacteur avec synchronisation du hachage de mot
de passe doivent utiliser Azure AD Multi-Factor Authentication ou les contrôles personnalisés d'accès
conditionnel. Elles ne peuvent pas utiliser des méthodes d’authentification multifacteur tierces ou locales
qui reposent sur la fédération.
NOTE
L’accès conditionnel Azure AD requiert des licences Azure AD Premium P1.
Continuité des activités . La synchronisation de hachage du mot de passe avec authentification cloud
est un service cloud hautement disponible qui s’adapte à tous les centres de données Microsoft. Pour
vous assurer que la synchronisation de hachage du mot de passe ne baisse pas pendant de longues
périodes, déployez un second serveur Azure AD Connect en mode préproduction dans une configuration
de secours.
Considérations . À l’heure actuelle, la synchronisation de hachage du mot de passe n’applique pas
immédiatement les changements aux états des comptes locaux. Cela signifie qu’un utilisateur a accès aux
applications cloud jusqu’à ce que l’état du compte utilisateur soit synchronisé avec Azure AD. Pour
contourner cette limitation, les organisations peuvent exécuter un nouveau cycle de synchronisation
après les mises à jour en bloc effectuées par les administrateurs sur les états des comptes locaux, par
exemple la désactivation de comptes.
NOTE
Les états indiquant un mot de passe expiré et un compte verrouillé ne sont pas synchronisés avec Azure AD à l’aide
d’Azure AD Connect. Lorsque vous modifiez le mot de passe d’un utilisateur et configurez l’indicateur L’utilisateur doit
changer de mot de passe à la prochaine ouverture de session, le hachage de mot de passe n’est pas synchronisé avec
Azure AD et Azure AD Connect, tant que l’utilisateur n’aura pas modifié son mot de passe.
Pour obtenir les étapes de déploiement, consultez Implémentation de la synchronisation de hachage du mot de
passe.
Authentification cloud : Authentification directe
Effor t . L’authentification directe nécessite l’installation d’un ou plusieurs agents légers (trois sont
recommandés) sur des serveurs existants. Ces agents doivent avoir accès à vos services AD DS (Active
Directory Domain Services) locaux et à vos contrôleurs de domaine AD locaux. Ils doivent disposer d’un
accès sortant à Internet et à vos contrôleurs de domaine. Le déploiement des agents dans un réseau de
périmètre n’est donc pas pris en charge.
L’authentification directe nécessite un accès réseau sans contrainte aux contrôleurs de domaine. Tout le
trafic réseau est chiffré et limité aux demandes d’authentification. Pour plus d’informations sur ce
processus, consultez l’immersion dans la sécurité sur l’authentification directe.
l’authentification unique transparente avec l’authentification directe. L’authentification unique
transparente élimine les invites inutiles quand les utilisateurs sont connectés.
Scénarios avancés . L’authentification directe applique la stratégie de compte local au moment de la
connexion. Par exemple, l’accès est refusé lorsque l’état d’un compte d’utilisateur local indique que le
compte est désactivé, verrouillé, que le mot de passe a expiré ou que les heures de connexion associées
au compte ne correspondent pas aux heures d’ouverture de session autorisées de l’utilisateur.
Les organisations qui exigent une authentification multifacteur avec authentification directe doivent
utiliser Azure AD Multi-Factor Authentication (MFA) ou les contrôles personnalisés d'accès conditionnel.
Ces organisations ne peuvent pas utiliser des méthodes d’authentification multifacteur tierces ou locales
qui reposent sur la fédération. Les fonctionnalités avancées nécessitent le déploiement de la
synchronisation de hachage du mot de passe (que vous choisissiez l’authentification directe ou non). C’est
le cas notamment du rapport sur la fuite des informations d’identification généré par Identity Protection.
Continuité des activités . Nous vous recommandons de déployer deux agents d’authentification directe
supplémentaires. Ces agents complètent le premier agent sur le serveur Azure AD Connect. Ce
déploiement supplémentaire garantit la haute disponibilité des demandes d’authentification. Quand trois
agents sont déployés et que l’un d’eux est hors service pour maintenance, l’échec d’un agent n’a aucune
incidence.
Outre l’authentification directe, le déploiement de la synchronisation de hachage du mot de passe offre
un autre avantage. Il sert de méthode d’authentification de secours lorsque la méthode d’authentification
principale n’est plus disponible.
Considérations . Vous pouvez utiliser la synchronisation de hachage de mot de passe comme une
méthode d’authentification de secours pour l’authentification directe, et les agents ne peuvent pas valider
les informations d’identification d’un utilisateur en raison d’un incident local. Le basculement vers la
synchronisation de hachage du mot de passe ne se produit pas automatiquement et vous devez utiliser
Azure AD Connect pour basculer manuellement la méthode de connexion.
Pour découvrir d’autres considérations sur l’authentification directe, notamment la prise en charge d’ID
de connexion de substitution, consultez le forum aux questions.
Pour obtenir les étapes de déploiement à suivre, consultez Implémentation de l’authentification directe.
Effor t . L’utilisation d’un système d’authentification fédérée s’appuie sur un système externe de confiance
pour authentifier les utilisateurs. Certaines entreprises souhaitent rentabiliser leur investissement et
réutiliser leur système fédéré existant avec leur solution d’identité hybride Azure AD. La maintenance et la
gestion du système fédéré ne relèvent pas d’Azure AD. Il appartient à l’organisation d’utiliser le système
fédéré pour vérifier qu’il est déployé de manière sécurisée et qu’il peut gérer la charge de
l’authentification.
Expérience utilisateur . L’expérience utilisateur de l’authentification fédérée dépend de l’implémentation
de fonctionnalités, de la topologie et de la configuration de la batterie de serveurs de fédération.
Certaines organisations ont besoin de cette souplesse pour configurer l’accès à la batterie de serveurs de
fédération en fonction de leurs exigences en matière de sécurité. Par exemple, il est possible de configurer
en interne des utilisateurs connectés et des appareils capables de connecter automatiquement les
utilisateurs. Aucune information d’identification n’est donc demandée aux utilisateurs. Cette configuration
fonctionne car ils sont déjà connectés à leur appareil. Si nécessaire, certaines fonctionnalités de sécurité
avancées compliquent le processus de connexion des utilisateurs.
Scénarios avancés . Une solution d’authentification fédérée est requise lorsque les clients ont une
exigence d’authentification non prise en charge par Azure AD en mode natif. Affichez des informations
détaillées pour vous aider à choisir l’option de connexion adaptée. Examinez les exigences courantes
suivantes :
Authentification nécessitant des cartes à puce ou des certificats.
Les serveurs MFA locaux ou fournisseurs d’authentification multifacteur tiers nécessitent un
fournisseur d’identité fédéré.
Authentification à l’aide de solutions d’authentification tierces. Consultez la liste de compatibilité de
fédération Azure AD.
Connexion nécessitant un sAMAccountName, par exemple DOMAINE\nomutilisateur, et non avec un
nom d’utilisateur principal (UPN) comme user@domain.com.
Continuité des activités . Les systèmes fédérés nécessitent généralement un groupe de serveurs à
charge équilibrée, également appelé « batterie de serveurs ». Cette batterie est configurée dans une
topologie de réseau interne et de réseau de périmètre pour garantir la haute disponibilité des demandes
d’authentification.
Déployez une synchronisation de hachage du mot de passe conjointement avec l’authentification fédérée
comme méthode d’authentification de secours quand la méthode d’authentification principale n’est plus
disponible, par exemple en cas d’indisponibilité des serveurs locaux. Certaines grandes entreprises
exigent une solution de fédération pour prendre en charge plusieurs points d’entrée Internet configurés
avec géo-DNS pour les demandes d’authentification à faible latence.
Considérations . Les systèmes fédérés nécessitent généralement un investissement plus important dans
l’infrastructure locale. La plupart des organisations choisissent cette option si elles disposent déjà d’une
solution de fédération locale et qu’elles sont contraintes d’utiliser un fournisseur d’identité unique pour
des raisons commerciales. La fédération est plus difficile à utiliser et à dépanner que les solutions
d’authentification cloud.
Avec un domaine non routable qui ne peut pas être vérifié dans Azure AD, l’implémentation d’une connexion
d’ID utilisateur nécessite une configuration supplémentaire. Cette exigence est connue sous le nom de « prise en
charge des ID de connexion de substitution ». Pour connaître les limitations et les exigences, consultez
Configuration d’un ID de connexion de substitution. Si vous choisissez d’utiliser un fournisseur
d’authentification multifacteur tiers avec la fédération, vérifiez qu’il prend en charge WS-Trust pour autoriser les
appareils à rejoindre Azure AD.
Pour accéder aux étapes de déploiement, consultez Déploiement des serveurs de fédération.
NOTE
Quand vous déployez votre solution d’identité hybride Azure AD, vous devez veiller à implémenter l’une des topologies
prises en charge d’Azure AD Connect. Pour découvrir les configurations prises en charge et celles qui ne le sont pas,
consultezTopologies pour Azure AD Connect.
Diagrammes d’architecture
Les diagrammes suivants présentent les composants architecturaux de haut niveau nécessaires pour chaque
méthode d’authentification que vous pouvez utiliser avec votre solution d’identité hybride Azure AD. Ils vous
offrent une vue d’ensemble pour vous aider à comparer les différences entre les solutions.
Simplicité d’une solution de synchronisation de hachage du mot de passe :
Configuration requise de l’agent d’authentification directe, à l’aide de deux agents pour la redondance :
Composants obligatoires pour la fédération dans le réseau interne et le réseau de périmètre de votre
organisation :
Comparaison des méthodes
SY N C H RO N ISAT IO N DE
H A C H A GE DU M OT DE A UT H EN T IF IC AT IO N
PA SSE + DIREC T E +
A UT H EN T IF IC AT IO N A UT H EN T IF IC AT IO N
C O N SIDÉRAT IO N UN IQ UE T RA N SPA REN T E UN IQ UE T RA N SPA REN T E F ÉDÉRAT IO N AVEC A D F S
Où l’authentification se Dans le cloud Dans le cloud, après un Local

produit-elle ? échange de vérification de
mot de passe sécurisé avec
l’agent d’authentification
local
Quelles sont les exigences None Un serveur par agent Deux ou plusieurs serveurs
pour le serveur local au- d’authentification AD FS
delà du système de supplémentaire
provisionnement : Azure AD Deux ou plusieurs serveurs
Connect ? WAP dans le réseau de
périmètre/DMZ
Quelles sont les exigences None Accès Internet sortant à Accès Internet entrant pour
Internet et réseau locales partir des serveurs les serveurs WAP dans le
au-delà du système de exécutant des agents périmètre
provisionnement ? d’authentification
Accès réseau entrant aux
serveurs AD FS à partir des
serveurs WAP dans le
périmètre
Équilibrage de charge
réseau
Y a-t-il une exigence de Non Non Oui

certificat TLS/SSL ?
Existe-t-il une solution de Non requis État de l’agent fourni par le Azure AD Connect Health
supervision de l’intégrité ? Centre d’administration
Les utilisateurs obtiennent- Oui avec authentification Oui avec authentification Oui
ils une authentification unique fluide unique fluide
unique auprès des
ressources cloud à partir
d’appareils joints au
domaine au sein du réseau
d’entreprise ?
Quels types de connexion UserPrincipalName + mot UserPrincipalName + mot UserPrincipalName + mot

sont pris en charge ? de passe de passe de passe
Authentification Windows Authentification Windows sAMAccountName + mot

intégrée avec intégrée avec de passe
authentification unique authentification unique
transparente transparente Authentification Windows
intégrée
ID de connexion de ID de connexion de
substitution substitution Authentification par
certificat et carte à puce
ID de connexion de
substitution
Windows Hello Entreprise Modèle de confiance de clé Modèle de confiance de clé Modèle de confiance de clé
est-il pris en charge ? Nécessite le niveau
fonctionnel de domaine Modèle de certificat de
Windows Server 2016 confiance
Quelles sont les options Azure AD MFA Azure AD MFA Azure AD MFA
multifacteur ? Contrôles personnalisés Contrôles personnalisés Serveur Azure MFA
avec accès conditionnel* avec accès conditionnel*
MFA tiers
Contrôles personnalisés
avec accès conditionnel*
Quels sont les états de Comptes désactivés Comptes désactivés Comptes désactivés
compte d’utilisateur pris en (délai pouvant atteindre 30
charge ? minutes) Compte verrouillé Compte verrouillé
Compte expiré Compte expiré
Mot de passe expiré Mot de passe expiré
Heures de connexion Heures de connexion
Quelles sont les options Accès conditionnel Azure Accès conditionnel Azure Accès conditionnel Azure
d’accès conditionnel ? AD, avec Azure AD AD, avec Azure AD AD, avec Azure AD
Premium Premium Premium
Règles de revendication AD
FS
Le blocage des protocoles Oui Oui Oui

hérités est-il pris en charge
?
Pouvez-vous personnaliser Oui, avec Azure AD Oui, avec Azure AD Oui

le logo, l’image et la Premium Premium
description sur les pages de
connexion ?
Quels sont les scénarios Verrouillage de mot de Verrouillage de mot de Système d’authentification
avancés pris en charge ? passe intelligent passe intelligent multisite à faible latence
Rapports des informations Verrouillage extranet AD FS

d’identification divulguées,
avec Azure AD Premium P2 Intégration aux systèmes
d’identité tiers
NOTE
Contrôles personnalisés dans Azure AD. L’accès conditionnel ne prend actuellement pas en charge l’inscription d’appareil.
Recommandations
Votre système d’identité garantit à vos utilisateurs l’accès aux applications cloud et aux applications métier que
vous migrez et rendez accessibles dans le cloud. Pour assurer la productivité des utilisateurs autorisés et
protéger les données sensibles de votre organisation contre les intrus, k’authentification contrôle l’accès aux
applications.
Utilisez ou activez la synchronisation de hachage du mot de passe, quelle que soit la méthode d’authentification
choisie, et ce pour les raisons suivantes :
1. Haute disponibilité et récupération d’urgence . L’authentification directe et la fédération s’appuient
sur une infrastructure locale. Pour l’authentification directe, l’empreinte locale inclut le matériel de serveur
et la mise en réseau requis par les agents d’authentification directe. Pour la fédération, l’empreinte locale
est encore plus importante. Elle nécessite des serveurs dans votre réseau de périmètre pour rediriger par
l’intermédiaire d’un proxy les demandes d’authentification et les serveurs de fédération interne.
Pour éviter des points de défaillance uniques, déployez des serveurs redondants. Cette méthode garantit
le traitement des requêtes d’authentification en cas d’échec d’un composant. Du point de vue de
l’authentification directe comme de la fédération, il est aussi attendu que les contrôleurs de domaine
répondent aux demandes d’authentification, qui peuvent également échouer. L’intégrité de nombreux
composants passe par des opérations de maintenance. Si celles-ci ne sont pas planifiées et implémentées
correctement, le risque de panne est plus élevé. La synchronisation de hachage du mot de passe permet
d’éviter les pannes, car le service d’authentification cloud Azure AD de Microsoft est mis à l’échelle
globalement et toujours disponible.
2. Sur vie à une panne locale . Les conséquences d’une panne locale à la suite d’une cyberattaque ou d’un
sinistre peuvent être considérables, de l’atteinte à l’image de marque à la paralysie de l’organisation si
celle-ci ne parvient pas à gérer l’attaque. Récemment, de nombreuses organisations ont été victimes
d’attaques menées par des programmes malveillants, notamment des ransomwares (rançongiciels), qui
ont provoqué la mise hors service de leurs serveurs locaux. Lorsque Microsoft aide les clients à gérer ces
types d’attaques, deux catégories d’organisations se dégagent :
Les organisations qui utilisaient précédemment la synchronisation de hachage de mot de passe en
plus de l’authentification fédérée ou directe ont modifié leur méthode d’authentification principale
pour utiliser la synchronisation de hachage de mot de passe. Ils étaient de nouveau en ligne après
quelques heures. En accédant aux e-mails par le biais de Microsoft 365, elles ont pu résoudre les
problèmes et accéder à d’autres charges de travail sur le cloud.
Les organisations n’ayant pas auparavant activé la synchronisation de hachage du mot de passe
ont dû faire appel à des systèmes de messagerie externes non fiables pour la communication et la
résolution des problèmes. Dans ce cas, il leur a fallu des semaines pour restaurer leur
infrastructure d’identité locale, avant que les utilisateurs ne puissent se connecter à nouveau aux
applications basées sur le Cloud.
3. Protection des identités . Azure AD Identity Protection avec Azure AD Premium P2 est un des meilleurs
moyens de protéger les utilisateurs dans le cloud. Microsoft analyse en permanence Internet à la
recherche de listes d’utilisateurs et de mots de passe vendues et mises à disposition sur le « dark web »
par des utilisateurs malveillants. Azure AD peut utiliser ces informations pour vérifier si les noms
d’utilisateur et les mots de passe de votre organisation sont compromis. Dès lors, il est primordial
d’activer la synchronisation de hachage du mot de passe, et ce quelle que soit la méthode
d’authentification vous utilisez (fédérée ou directe). Les informations d’identification divulguées sont
présentées sous forme de rapport. Utilisez ces informations pour bloquer ou forcer les utilisateurs à
modifier leurs mots de passe lorsqu’ils tentent de se connecter avec des mots de passe divulgués.
Conclusion
Cet article présente les différentes options d’authentification que les organisations peuvent configurer et
déployer pour prendre en charge l’accès aux applications cloud. Face à des exigences professionnelles,
sécuritaires et techniques variées, les organisations ont le choix entre la synchronisation de hachage du mot de
passe, l’authentification directe et la fédération.
Examinez chaque méthode d’authentification. L’effort visant à déployer la solution et l’expérience utilisateur du
processus de connexion répondent-ils aux besoins de votre entreprise ? Déterminez également si votre
organisation a besoin des scénarios avancés et des fonctionnalités de continuité d’activité de chaque méthode
d’authentification. Enfin, vous devez évaluer les considérations relatives à chaque méthode d’authentification
pour voir si l’une d’elles empêche l’implémentation de votre choix.
Étapes suivantes
Aujourd’hui, les menaces sont présentes 24 heures sur 24 et proviennent de partout. L’implémentation d’une
méthode d’authentification appropriée permet d’atténuer les risques en matière de sécurité et de protéger vos
identités.
Démarrez avec Azure AD et déployez la solution d’authentification adaptée à votre organisation.
Si vous envisagez de passer de l’authentification fédérée à l’authentification cloud, découvrez plus en détail
comment changer la méthode de connexion. Pour vous aider à planifier et à implémenter la migration, utilisez
ces plans de déploiement de projet ou envisagez d’utiliser la nouvelle fonctionnalité de Déploiement
intermédiaire pour migrer les utilisateurs fédérés vers à l’aide de l’authentification cloud dans une approche
intermédiaire.
Qu’est-ce qu’Azure AD Connect ?
L’outil Microsoft Azure AD Connect a été conçu pour vous permettre d’atteindre et de remplir vos objectifs en
matière d’identité hybride. Elle fournit les fonctionnalités suivantes :
Synchronisation de hachage de mot de passe : méthode d’authentification qui synchronise un hachage du
mot de passe AD local d’un utilisateur avec Azure AD.
Authentification directe : méthode d’authentification qui permet aux utilisateurs d’utiliser le même mot de
passe localement et dans le cloud, mais sans nécessiter l’infrastructure supplémentaire d’un environnement
fédéré.
Intégration de fédération : la fédération est une partie facultative d’Azure AD Connect qui peut servir à
configurer un environnement hybride à l’aide d’une infrastructure AD FS locale. Elle offre également des
fonctionnalités de gestion AD FS telles que le renouvellement de certificat et les déploiements de serveurs
AD FS supplémentaires.
Synchronisation : ce composant est chargé de créer des utilisateurs, des groupes et d’autres objets, et
également de s’assurer que les informations d’identité relatives aux utilisateurs et aux groupes dans votre
environnement local correspondent à celles qui se trouvent dans le cloud. Cette synchronisation inclut
également des hachages de mot de passe.
Analyse du fonctionnement : Azure AD Connect Health peut assurer une supervision robuste et offrir un
emplacement central dans le Portail Azure pour la visualisation de cette activité.
Qu’est-ce qu’Azure AD Connect Health ?

Azure Active Directory (Azure AD) Connect Health fournit une supervision robuste de votre infrastructure
d’identité locale. Il vous permet de conserver une connexion fiable à Microsoft 365 et aux services en ligne
Microsoft. Cette fiabilité est obtenue en fournissant des fonctionnalités de supervision pour vos composants
d’identités clés. De plus, il rend les points de données clés relatifs à ces composants facilement accessibles.
Ces informations sont toutes présentées dans le portail Azure AD Connect Health. Utilisez le portail Azure AD
Connect Health pour voir les alertes, la supervision des performances, l’analytique des utilisations et d’autres
informations. Azure AD Connect Health prend en compte l’intégrité des composants d’identité clé, le tout à un
seul endroit.
Pourquoi utiliser Azure AD Connect ?

L’intégration de vos annuaires locaux avec Azure AD améliore la productivité de vos utilisateurs en leur
fournissant une identité commune pour accéder aux ressources cloud et locales. Les utilisateurs et les
organisations bénéficient des avantages suivants :
Les utilisateurs peuvent utiliser une identité unique pour accéder aux applications locales et aux services
cloud comme Microsoft 365.
Outil unique offrant une expérience de déploiement simple pour la synchronisation et la connexion.
Fournit les fonctionnalités les plus récentes pour vos scénarios. Azure AD Connect remplace les versions
antérieures des outils d’intégration d’identité tels que DirSync et Azure AD Sync. Pour plus d’informations,
consultez Identité hybride : Comparaison des outils d’intégration d’annuaire.
Pourquoi utiliser Azure AD Connect Health ?

Lorsqu’ils l’authentifient auprès d’Azure AD, vos utilisateurs gagnent en productivité car ils disposent d’une
identité commune pour accéder à la fois aux ressources cloud et locales. Garantir la fiabilité de l’environnement
afin que les utilisateurs puissent accéder à ces ressources devient un défi. Azure AD Connect Health vous aide à
superviser et à obtenir des insights concernant votre infrastructure d’identité locale, garantissant ainsi la fiabilité
de cet environnement. Son installation est aussi simple que celle d’un agent sur chacun de vos serveurs
d’identité local.
Azure AD Connect Health pour AD FS prend en charge AD FS 2.0 sur Windows Server 2008 R2, Windows
Server 2012, Windows Server 2012 R2 et Windows Server 2016. Cette prise en charge inclut également la
surveillance de tous les serveurs proxy AD FS ou serveurs proxy d’application web qui prennent en charge
l’authentification pour l’accès extranet. Avec une installation simple et rapide du programme Health Agent, Azure
AD Connect Health pour AD FS vous offre un ensemble de fonctionnalités clés.
Avantages clés et bonnes pratiques :
P RIN C IPA UX AVA N TA GES B O N N ES P RAT IQ UES
Sécurité améliorée Tendances de verrouillage extranet

Rapport sur les échecs de connexions
Conformité aux réglementations relatives à la confidentialité
Obtention d’alertes pour tous les problèmes critiques liés au Configuration et disponibilité de serveur
système ADFS Performances et connectivité
Maintenance régulière
Facilité de déploiement et de gestion Installation d’agent rapide

Mise à niveau automatique d’agent vers la dernière version
Données disponibles dans le portail en quelques minutes
Métriques d’utilisation enrichies Utilisation des principales applications

Emplacements réseau et connexion TCP
Demandes de jetons par serveur
Meilleure expérience utilisateur Présentation sous forme de tableaux de bord du Portail

Azure
Alertes par e-mail
Licences requises pour Azure AD Connect

Licences requises pour Azure AD Connect Health

L'utilisation de cette fonctionnalité nécessite une licence Azure AD Premium P1. Pour trouver la licence
appropriée à vos besoins, consultez Comparaison des fonctionnalités mises à la disposition générale des
éditions gratuite, de base et Premium.
Étapes suivantes
Paramètres Express
Installation des agents Azure AD Connect Health
Présentation d’Azure AD Connect v 2.0
Azure AD Connect a été publié il y a plusieurs années. Depuis lors, plusieurs des composants utilisés par
Azure AD Connect ont été déconseillés et mis à jour vers des versions plus récentes. Tenter de mettre à jour tous
ces composants individuellement demanderait du temps et de la planification.
Pour remédier à ce problème, nous avons voulu regrouper un maximum de ces nouveaux composants dans une
nouvelle version unique, de sorte que vous ne devez effectuer qu’une seule mise à jour. Cette version sera
Azure AD Connect v2.0. Il s’agit d’une nouvelle version du même logiciel utilisé pour atteindre vos objectifs en
matière d’identité hybride et qui est construite à l’aide des composants fondamentaux les plus récents.
Quelles sont les principales modifications apportées ?

SQL Server 2019 Base de données locale
Les versions précédentes d’Azure AD Connect étaient livrées avec SQL Server 2012 Base de données locale. La
version 2.0 est livrée avec SQL Server 2019 Base de données locale, qui promet une stabilité et des
performances accrues et comporte plusieurs correctifs de bogues liés à la sécurité. SQL Server 2012 ne fera
plus l’objet d’un support étendu en juillet 2022. Pour plus d’informations, consultez Microsoft SQL 2019.
Bibliothèque d’authentification MSAL
Les versions précédentes d’Azure AD Connect étaient livrées avec la bibliothèque d’authentification ADAL. Cette
bibliothèque sera dépréciée en juin 2022. La version 2.0 est livrée avec la bibliothèque MSAL, plus récente. Pour
plus d’informations, consultez Vue d’ensemble de la bibliothèque MSAL.
Visual C++ Redist 14
SQL Server 2019 requiert le runtime Visual C++ Redist 14. Nous mettons donc à jour la bibliothèque du
runtime C++ pour utiliser cette version. Celle-ci sera installée avec le package Azure AD Connect v2.0. Vous
n’avez donc aucune action à entreprendre pour la mise à jour du runtime C++.
TLS 1.2
TLS 1.0 et TLS 1.1 sont des protocoles jugés peu sûrs et sont déconseillés par Microsoft. Cette version
d’Azure AD Connect prend en charge uniquement TLS 1.2. Toutes les versions de Windows Server qui sont
prises en charge pour Azure AD Connect V2.0 utilisent déjà le protocole TLS 1.2 par défaut. Si votre serveur ne
prend pas en charge TLS 1.2, vous devez l’activer avant de pouvoir déployer Azure AD Connect v2.0. Pour plus
d’informations, consultez Application de TLS 1.2 pour Azure AD Connect.
Tous les binaires signés avec SHA -2
Nous avons remarqué que certains composants avaient des binaires signés SHA-1. Nous ne prenons plus en
charge SHA-1 pour les binaires téléchargeables et nous avons mis à niveau tous les binaires avec la signature
SHA-2. Les signatures numériques sont utilisées pour garantir que les mises à jour proviennent directement de
Microsoft et qu’elles n’ont pas été falsifiées pendant la livraison. En raison des faiblesses de l’algorithme SHA-1
et pour nous aligner sur les normes du secteur, nous avons modifié la signature des mises à jour de Windows
pour utiliser l’algorithme SHA-2, plus sûr.
Aucune action n’est nécessaire de votre part.
Windows Server 2012 et Windows Server 2012 R2 ne sont plus pris en charge
SQL Server 2019 requiert Windows Server 2016 ou une version plus récente comme système d’exploitation de
serveur. Dans la mesure où AAD Connect v2 contient des composants SQL Server 2019, nous ne pouvons plus
prendre en charge les versions antérieures de Windows Server.
Vous ne pouvez pas installer cette version sur une version antérieure de Windows Server. Nous vous suggérons
de mettre à niveau votre serveur Azure AD Connect vers Windows Server 2019, qui est la version la plus
récente du système d’exploitation Windows Server.
Cet article décrit la mise à niveau de versions antérieures de Windows Server vers Windows Server 2019.
PowerShell 5.0
Cette version d’Azure AD Connect contient plusieurs cmdlets qui nécessitent PowerShell 5.0. Cette exigence est
donc un nouveau prérequis pour Azure AD Connect.
Vous trouverez plus d’informations sur les prérequis de PowerShell ici.
NOTE
PowerShell 5 fait déjà partie de Windows Server 2016. Vous n’avez donc probablement pas besoin d’agir tant que vous
utilisez une version récente de Window Server.
Que dois-je savoir d’autre ?

Pourquoi cette mise à niveau est-elle impor tante pour moi ?
L’année prochaine, plusieurs des composants de vos installations actuelles de serveurs Azure AD Connect ne
seront plus pris en charge. Si vous utilisez des produits non pris en charge, il sera plus difficile pour notre équipe
de support de vous fournir l’expérience de support dont votre organisation a besoin. Nous recommandons donc
à tous les clients de mettre à niveau vers cette version plus récente dès que possible.
Cette mise à niveau est d’autant plus importante que nous avons dû mettre à jour nos prérequis pour
Azure AD Connect et que vous aurez peut-être besoin de plus de temps pour planifier et mettre à jour vos
serveurs vers les versions plus récentes de ces prérequis.
Existe-t-il des nouvelles fonctionnalités que je dois connaître ?
Non, cette version ne contient aucune nouvelle fonctionnalité. Cette version contient uniquement des mises à
jour de certains composants fondamentaux d’Azure AD Connect.
Puis-je effectuer une mise à niveau de n’impor te quelle version précédente vers la version 2.0 ?
Oui, les mises à niveau d’une version précédente d’Azure AD Connect vers Azure AD Connect 2.0 sont prises en
charge. Suivez l’aide fournie dans cet article pour déterminer quelle est la meilleure stratégie de mise à niveau
pour vous.
Puis-je expor ter la configuration de mon ser veur actuel et l’impor ter dans
Azure AD Connect v2.0 ?
Oui, c’est possible et c’est un excellent moyen de migrer vers Azure AD Connect v2.0, en particulier si vous
effectuez également une mise à niveau vers une nouvelle version du système d’exploitation. Pour plus
d’informations sur la fonctionnalité Importer/exporter la configuration et sur son utilisation, consultez cet
article.
J’ai activé la mise à niveau automatique pour Azure AD Connect. Vais-je recevoir
automatiquement cette nouvelle version ?
Non, Azure AD Connect v2.0 n’est pas disponible pour la mise à niveau automatique pour l’instant.
Je ne suis pas encore prêt à effectuer la mise à niveau. De combien de temps est-ce que je
dispose ?
Vous devez effectuer la mise à niveau vers Azure AD Connect v2.0 dès que possible. Toutes les versions
Azure AD Connect V1 seront supprimées le 31 août 2022. Pour le moment, nous continuons à prendre
en charge les versions antérieures d’Azure AD Connect, mais il peut s’avérer difficile de fournir une bonne
expérience de support si certains des composants d’Azure AD Connect ne sont plus pris en charge. Cette mise à
niveau est particulièrement importante pour ADAL et TLS 1.0/1.1, car ces services peuvent cesser de fonctionner
de manière inattendue après leur dépréciation.
J’utilise une base de données SQL externe et n’utilise pas SQL Ser ver 2012 Base de données
locale. Dois-je quand même effectuer la mise à niveau ?
Oui, vous devez effectuer la mise à niveau pour conserver un état pris en charge, même si vous n’utilisez pas
SQL Server 2012, en raison de la dépréciation de TLS 1.0/1.1 et d’ADAL. Notez que SQL Server 2012 peut
toujours être utilisé comme base de données SQL externe avec Azure AD Connect V2.0 - les pilotes SQL 2019
dans Azure AD Connect V2.0 sont compatibles avec SQL Server 2012.
Après la mise à niveau de mon instance Azure AD Connect vers V2.0, les composants SQL 2012
sont-ils automatiquement désinstallés ?
Non, la mise à niveau vers SQL 2019 ne supprime aucun composant SQL 2012 de votre serveur. Si vous n’avez
plus besoin de ces composants, vous devez suivre les instructions de désinstallation de SQL Server.
Que se passe-t-il si je ne fais pas la mise à niveau ?
Jusqu’à ce que l’un des composants en cours de mise hors service devienne réellement déconseillé, vous ne
verrez aucun impact. Azure AD Connect continuera à fonctionner.
Nous prévoyons que TLS 1.0/1.1 sera déconseillé en janvier 2022. Vous devez vous assurer de ne plus utiliser
ces protocoles avant cette date, car votre service pourrait cesser de fonctionner de manière inattendue. Vous
pouvez cependant configurer manuellement votre serveur pour TLS 1.2, ce qui ne nécessite pas de mise à jour
d’Azure AD Connect vers la version 2.0.
En juin 2022, la bibliothèque ADAL ne sera plus prise en charge. Lorsque ADAL ne sera plus prise en charge,
l’authentification pourra cesser de fonctionner de manière inattendue, ce qui empêchera le serveur
Azure AD Connect de fonctionner correctement. Nous vous conseillons vivement d’effectuer la mise à niveau
vers Azure AD Connect v2.0 avant juin 2022. Vous ne pouvez pas effectuer de mise à niveau vers une
bibliothèque d’authentification prise en charge avec votre version actuelle d’Azure AD Connect.
Après la mise à niveau vers la version 2.0, les cmdlets PowerShell ADSync ne fonctionnent pas ?
Il s’agit d’un problème connu. Pour le résoudre, redémarrez votre session PowerShell après l’installation ou la
mise à niveau vers la version 2.0, puis réimportez le module. Suivez les instructions suivantes pour importer le
module.
1. Ouvrez Windows PowerShell avec des privilèges d’administrateur.
2. Tapez ou collez le code suivant :
powershell Import-module -Name "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync"
Licences requises pour Azure AD Connect v2.0

Licences requises pour Azure AD Connect Health

L'utilisation de cette fonctionnalité nécessite une licence Azure AD Premium P1. Pour trouver la licence
appropriée à vos besoins, consultez Comparaison des fonctionnalités mises à la disposition générale des
éditions gratuite, de base et Premium.
Étapes suivantes
Paramètres Express
Cet article décrit la mise à niveau de versions antérieures de Windows Server vers Windows Server 2019.
Choisir la méthode d’authentification adaptée à
votre solution d’identité hybride Azure Active
Directory
La première étape pour les organisations souhaitant migrer leurs applications vers le cloud est de choisir une
méthode d’authentification appropriée. Cette décision ne doit pas être prise à la légère, et ce pour les raisons
suivantes :
1. Il s’agit de la première décision que doit prendre une organisation souhaitant migrer vers le cloud.
2. La méthode d’authentification est un composant essentiel de la présence d’une organisation dans le
cloud. Elle contrôle l’accès à l’ensemble des données et des ressources du cloud.
3. Elle constitue le fondement sur lequel reposent toutes les autres fonctionnalités avancées en matière de
sécurité et d’expérience utilisateur dans Azure AD.
L’identité constitue le nouveau plan de contrôle en matière de sécurité informatique et, dès lors,
l’authentification permet aux organisations de gérer les accès au cloud. Les organisations ont besoin d’un plan
de contrôle d’identité qui renforce leur sécurité et protège leurs applications cloud contre les intrus.
NOTE
Modifier votre méthode d’authentification implique une planification, des tests et de possibles temps d’arrêt. Le
déploiement intermédiaire constitue un excellent moyen de tester la migration des utilisateurs de l’authentification de la
fédération à l’authentification cloud.
Hors propos
Les organisations qui ne présentent aucune empreinte d’un annuaire local existant ne sont pas concernées par
cet article. En général, ces entreprises créent uniquement des identités résidant dans le cloud, ce qui n’exige pas
une solution d’identité hybride. Les identités résidant uniquement dans le cloud ne sont pas associées à des
identités locales correspondantes.
Méthodes d’authentification
En choisissant la solution d’identité hybride Azure AD comme nouveau plan de contrôle, l’authentification
constitue la base de l’accès au cloud. Le choix de la méthode d’authentification est une première décision
essentielle dans la configuration d’une solution d’identité hybride Azure AD. L’implémentation de la méthode
d’authentification est configurée à l’aide d’Azure AD Connect, qui provisionne également les utilisateurs dans le
cloud.
Pour choisir une méthode d’authentification, vous devez prendre en compte l’infrastructure existante, le temps
nécessaire à l’implémentation, sa complexité et les coûts associés. Ces facteurs sont différents pour chaque
organisation et peuvent varier au fil du temps.
Azure AD prend en charge les méthodes d’authentification suivantes pour les solutions d’identité hybride.
Authentification cloud
Quand vous choisissez cette méthode d’authentification, Azure AD gère le processus de connexion des
utilisateurs. Si vous l’associez à une authentification unique (SSO) fluide, les utilisateurs peuvent se connectent
aux applications cloud sans avoir à retaper leurs informations d’identification. L’authentification cloud propose
deux options :
Synchronisation de hachage de mot de passe Azure AD . Il s’agit du moyen le plus simple d’activer
l’authentification pour les objets d’annuaire locaux dans Azure AD. Elle permet aux utilisateurs d’utiliser les
mêmes nom d’utilisateur et mot de passe qu’ils utilisent localement sans avoir à déployer une infrastructure
supplémentaire. Certaines fonctionnalités Premium d’Azure AD, comme Identity Protection et Azure Active
Directory Domain Services, nécessitent la synchronisation de hachage du mot de passe, quelle que soit la
méthode d’authentification choisie.
NOTE
Les mots de passe ne sont jamais stockés en texte clair ni chiffrés avec un algorithme réversible dans Azure AD. Pour plus
d’informations sur le processus réel de la synchronisation de hachage du mot de passe, consultez Implémenter la
synchronisation de hachage du mot de passe avec la synchronisation Azure AD Connect.
Authentification directe Azure AD . Fournit une validation de mot de passe simple pour les services
d’authentification Azure AD à l’aide d’un agent logiciel qui s’exécute sur un ou plusieurs serveurs locaux. Les
serveurs valident les utilisateurs directement avec votre Active Directory local, ce qui garantit que la validation
du mot de passe ne se produit pas dans le cloud.
Cette méthode d’authentification convient pour les entreprises qui, pour des raisons de sécurité, requièrent
l’application immédiate d’heures d’ouverture de session, de stratégies de mot de passe et d’états des comptes
d’utilisateur locaux. Pour plus d’informations sur le processus réel de l’authentification directe, consultez
Connexion de l’utilisateur avec l’authentification directe Azure AD.
Quand vous choisissez cette méthode d’authentification, Azure AD délègue le processus d’authentification à un
système d’authentification approuvée distinct, par exemple les services de fédération Active Directory (AD FS),
pour valider le mot de passe de l’utilisateur.
Le système d’authentification peut fournir des conditions d’authentification supplémentaires, comme
l’authentification par carte à puce ou une authentification multifacteur tierce. Pour plus d’informations, consultez
Déploiement des services de fédération Active Directory (AD FS).
L’arbre de décision présenté dans la section suivante vous aide à déterminer la méthode d’authentification
adaptée à vos besoins. Vous pouvez ainsi décider si vous devez déployer une authentification cloud ou une
authentification fédérée pour votre solution d’identité hybride Azure AD.
Arbre de décision
Détails relatifs aux questions de décision :
1. Azure AD peut gérer la connexion des utilisateurs sans s’appuyer sur des composants locaux pour vérifier les
mots de passe.
2. Azure AD peut transférer la connexion des utilisateurs à un fournisseur d’authentification approuvé tel qu’AD
FS de Microsoft.
3. Si vous devez appliquer des stratégies de sécurité Active Directory au niveau utilisateur, telles que l’expiration
de compte, la désactivation de compte, l’expiration de mot de passe, le verrouillage de compte et les heures
de connexion à chaque connexion d’utilisateur, Azure AD requiert certains composants locaux.
4. Fonctionnalités de connexion non prises en charge en mode natif par Azure AD :
Connexion à l’aide de cartes à puce ou de certificats.
Connexion à l’aide d’un serveur MFA local.
Connexion à l’aide d’une solution d’authentification tierce.
Solution d’authentification locale multisite.
5. Quelle que soit la méthode de connexion choisie, pour générer le rapport Utilisateurs avec des informations
d’identification divulguées, Azure AD Identity Protection nécessite une synchronisation du hachage de mot
de passe. Les organisations peuvent basculer vers une synchronisation du hachage de mot de passe si leur
méthode de connexion principale échoue alors qu’elle a été configurée avant l’événement d’échec.
NOTE
Azure AD Identity Protection nécessite des licences Azure AD Premium P2.
Considérations détaillées
Authentification cloud : Synchronisation de hachage de mot de passe
Effor t . La synchronisation de hachage du mot de passe nécessite le moins d’effort en matière de
déploiement, de maintenance et d’infrastructure. Ce niveau d’effort s’applique généralement aux
organisations dont les utilisateurs se connectent uniquement à Microsoft 365, à des applications SaaS et
à d’autres ressources Azure AD basées sur Active Directory. Une fois activée, la synchronisation de
hachage du mot de passe fait partie du processus de synchronisation Azure AD Connect et s’exécute
toutes les deux minutes.
l’authentification unique transparente avec synchronisation de hachage du mot de passe.
L’authentification unique transparente élimine les invites inutiles quand les utilisateurs sont connectés.
Scénarios avancés . Les organisations peuvent choisir d’utiliser les insights des identités avec les
rapports Azure AD Identity Protection avec Azure AD Premium P2, par exemple le rapport sur les
informations d’identification divulguées. Windows Hello Entreprise a des exigences spécifiques quand
vous utilisez la synchronisation de hachage du mot de passe. Azure Active Directory Domain Services
nécessite la synchronisation de hachage de mot de passe pour fournir aux utilisateurs leurs informations
d’identification dans le domaine managé.
Les organisations qui exigent une authentification multifacteur avec synchronisation du hachage de mot
de passe doivent utiliser Azure AD Multi-Factor Authentication ou les contrôles personnalisés d'accès
conditionnel. Elles ne peuvent pas utiliser des méthodes d’authentification multifacteur tierces ou locales
qui reposent sur la fédération.
NOTE
L’accès conditionnel Azure AD requiert des licences Azure AD Premium P1.
Continuité des activités . La synchronisation de hachage du mot de passe avec authentification cloud
est un service cloud hautement disponible qui s’adapte à tous les centres de données Microsoft. Pour
vous assurer que la synchronisation de hachage du mot de passe ne baisse pas pendant de longues
périodes, déployez un second serveur Azure AD Connect en mode préproduction dans une configuration
de secours.
Considérations . À l’heure actuelle, la synchronisation de hachage du mot de passe n’applique pas
immédiatement les changements aux états des comptes locaux. Cela signifie qu’un utilisateur a accès aux
applications cloud jusqu’à ce que l’état du compte utilisateur soit synchronisé avec Azure AD. Pour
contourner cette limitation, les organisations peuvent exécuter un nouveau cycle de synchronisation
après les mises à jour en bloc effectuées par les administrateurs sur les états des comptes locaux, par
exemple la désactivation de comptes.
NOTE
Les états indiquant un mot de passe expiré et un compte verrouillé ne sont pas synchronisés avec Azure AD à l’aide
d’Azure AD Connect. Lorsque vous modifiez le mot de passe d’un utilisateur et configurez l’indicateur L’utilisateur doit
changer de mot de passe à la prochaine ouverture de session, le hachage de mot de passe n’est pas synchronisé avec
Azure AD et Azure AD Connect, tant que l’utilisateur n’aura pas modifié son mot de passe.
Pour obtenir les étapes de déploiement, consultez Implémentation de la synchronisation de hachage du mot de
passe.
Authentification cloud : Authentification directe
Effor t . L’authentification directe nécessite l’installation d’un ou plusieurs agents légers (trois sont
recommandés) sur des serveurs existants. Ces agents doivent avoir accès à vos services AD DS (Active
Directory Domain Services) locaux et à vos contrôleurs de domaine AD locaux. Ils doivent disposer d’un
accès sortant à Internet et à vos contrôleurs de domaine. Le déploiement des agents dans un réseau de
périmètre n’est donc pas pris en charge.
L’authentification directe nécessite un accès réseau sans contrainte aux contrôleurs de domaine. Tout le
trafic réseau est chiffré et limité aux demandes d’authentification. Pour plus d’informations sur ce
processus, consultez l’immersion dans la sécurité sur l’authentification directe.
l’authentification unique transparente avec l’authentification directe. L’authentification unique
transparente élimine les invites inutiles quand les utilisateurs sont connectés.
Scénarios avancés . L’authentification directe applique la stratégie de compte local au moment de la
connexion. Par exemple, l’accès est refusé lorsque l’état d’un compte d’utilisateur local indique que le
compte est désactivé, verrouillé, que le mot de passe a expiré ou que les heures de connexion associées
au compte ne correspondent pas aux heures d’ouverture de session autorisées de l’utilisateur.
Les organisations qui exigent une authentification multifacteur avec authentification directe doivent
utiliser Azure AD Multi-Factor Authentication (MFA) ou les contrôles personnalisés d'accès conditionnel.
Ces organisations ne peuvent pas utiliser des méthodes d’authentification multifacteur tierces ou locales
qui reposent sur la fédération. Les fonctionnalités avancées nécessitent le déploiement de la
synchronisation de hachage du mot de passe (que vous choisissiez l’authentification directe ou non). C’est
le cas notamment du rapport sur la fuite des informations d’identification généré par Identity Protection.
Continuité des activités . Nous vous recommandons de déployer deux agents d’authentification directe
supplémentaires. Ces agents complètent le premier agent sur le serveur Azure AD Connect. Ce
déploiement supplémentaire garantit la haute disponibilité des demandes d’authentification. Quand trois
agents sont déployés et que l’un d’eux est hors service pour maintenance, l’échec d’un agent n’a aucune
incidence.
Outre l’authentification directe, le déploiement de la synchronisation de hachage du mot de passe offre
un autre avantage. Il sert de méthode d’authentification de secours lorsque la méthode d’authentification
principale n’est plus disponible.
Considérations . Vous pouvez utiliser la synchronisation de hachage de mot de passe comme une
méthode d’authentification de secours pour l’authentification directe, et les agents ne peuvent pas valider
les informations d’identification d’un utilisateur en raison d’un incident local. Le basculement vers la
synchronisation de hachage du mot de passe ne se produit pas automatiquement et vous devez utiliser
Azure AD Connect pour basculer manuellement la méthode de connexion.
Pour découvrir d’autres considérations sur l’authentification directe, notamment la prise en charge d’ID
de connexion de substitution, consultez le forum aux questions.
Pour obtenir les étapes de déploiement à suivre, consultez Implémentation de l’authentification directe.
Effor t . L’utilisation d’un système d’authentification fédérée s’appuie sur un système externe de confiance
pour authentifier les utilisateurs. Certaines entreprises souhaitent rentabiliser leur investissement et
réutiliser leur système fédéré existant avec leur solution d’identité hybride Azure AD. La maintenance et la
gestion du système fédéré ne relèvent pas d’Azure AD. Il appartient à l’organisation d’utiliser le système
fédéré pour vérifier qu’il est déployé de manière sécurisée et qu’il peut gérer la charge de
l’authentification.
Expérience utilisateur . L’expérience utilisateur de l’authentification fédérée dépend de l’implémentation
de fonctionnalités, de la topologie et de la configuration de la batterie de serveurs de fédération.
Certaines organisations ont besoin de cette souplesse pour configurer l’accès à la batterie de serveurs de
fédération en fonction de leurs exigences en matière de sécurité. Par exemple, il est possible de configurer
en interne des utilisateurs connectés et des appareils capables de connecter automatiquement les
utilisateurs. Aucune information d’identification n’est donc demandée aux utilisateurs. Cette configuration
fonctionne car ils sont déjà connectés à leur appareil. Si nécessaire, certaines fonctionnalités de sécurité
avancées compliquent le processus de connexion des utilisateurs.
Scénarios avancés . Une solution d’authentification fédérée est requise lorsque les clients ont une
exigence d’authentification non prise en charge par Azure AD en mode natif. Affichez des informations
détaillées pour vous aider à choisir l’option de connexion adaptée. Examinez les exigences courantes
suivantes :
Authentification nécessitant des cartes à puce ou des certificats.
Les serveurs MFA locaux ou fournisseurs d’authentification multifacteur tiers nécessitent un
fournisseur d’identité fédéré.
Authentification à l’aide de solutions d’authentification tierces. Consultez la liste de compatibilité de
fédération Azure AD.
Connexion nécessitant un sAMAccountName, par exemple DOMAINE\nomutilisateur, et non avec un
nom d’utilisateur principal (UPN) comme user@domain.com.
Continuité des activités . Les systèmes fédérés nécessitent généralement un groupe de serveurs à
charge équilibrée, également appelé « batterie de serveurs ». Cette batterie est configurée dans une
topologie de réseau interne et de réseau de périmètre pour garantir la haute disponibilité des demandes
d’authentification.
Déployez une synchronisation de hachage du mot de passe conjointement avec l’authentification fédérée
comme méthode d’authentification de secours quand la méthode d’authentification principale n’est plus
disponible, par exemple en cas d’indisponibilité des serveurs locaux. Certaines grandes entreprises
exigent une solution de fédération pour prendre en charge plusieurs points d’entrée Internet configurés
avec géo-DNS pour les demandes d’authentification à faible latence.
Considérations . Les systèmes fédérés nécessitent généralement un investissement plus important dans
l’infrastructure locale. La plupart des organisations choisissent cette option si elles disposent déjà d’une
solution de fédération locale et qu’elles sont contraintes d’utiliser un fournisseur d’identité unique pour
des raisons commerciales. La fédération est plus difficile à utiliser et à dépanner que les solutions
d’authentification cloud.
Avec un domaine non routable qui ne peut pas être vérifié dans Azure AD, l’implémentation d’une connexion
d’ID utilisateur nécessite une configuration supplémentaire. Cette exigence est connue sous le nom de « prise en
charge des ID de connexion de substitution ». Pour connaître les limitations et les exigences, consultez
Configuration d’un ID de connexion de substitution. Si vous choisissez d’utiliser un fournisseur
d’authentification multifacteur tiers avec la fédération, vérifiez qu’il prend en charge WS-Trust pour autoriser les
appareils à rejoindre Azure AD.
Pour accéder aux étapes de déploiement, consultez Déploiement des serveurs de fédération.
NOTE
Quand vous déployez votre solution d’identité hybride Azure AD, vous devez veiller à implémenter l’une des topologies
prises en charge d’Azure AD Connect. Pour découvrir les configurations prises en charge et celles qui ne le sont pas,
consultezTopologies pour Azure AD Connect.
Diagrammes d’architecture
Les diagrammes suivants présentent les composants architecturaux de haut niveau nécessaires pour chaque
méthode d’authentification que vous pouvez utiliser avec votre solution d’identité hybride Azure AD. Ils vous
offrent une vue d’ensemble pour vous aider à comparer les différences entre les solutions.
Simplicité d’une solution de synchronisation de hachage du mot de passe :
Configuration requise de l’agent d’authentification directe, à l’aide de deux agents pour la redondance :
Composants obligatoires pour la fédération dans le réseau interne et le réseau de périmètre de votre
organisation :
Comparaison des méthodes
Où l’authentification se Dans le cloud Dans le cloud, après un Local

produit-elle ? échange de vérification de
mot de passe sécurisé avec
l’agent d’authentification
local
Quelles sont les exigences None Un serveur par agent Deux ou plusieurs serveurs
pour le serveur local au- d’authentification AD FS
delà du système de supplémentaire
provisionnement : Azure AD Deux ou plusieurs serveurs
Connect ? WAP dans le réseau de
périmètre/DMZ
Quelles sont les exigences None Accès Internet sortant à Accès Internet entrant pour
Internet et réseau locales partir des serveurs les serveurs WAP dans le
au-delà du système de exécutant des agents périmètre
provisionnement ? d’authentification
Accès réseau entrant aux
serveurs AD FS à partir des
serveurs WAP dans le
périmètre
Équilibrage de charge
réseau
Y a-t-il une exigence de Non Non Oui

certificat TLS/SSL ?
Existe-t-il une solution de Non requis État de l’agent fourni par le Azure AD Connect Health
supervision de l’intégrité ? Centre d’administration
Les utilisateurs obtiennent- Oui avec authentification Oui avec authentification Oui
ils une authentification unique fluide unique fluide
unique auprès des
ressources cloud à partir
d’appareils joints au
domaine au sein du réseau
d’entreprise ?
Quels types de connexion UserPrincipalName + mot UserPrincipalName + mot UserPrincipalName + mot

sont pris en charge ? de passe de passe de passe
Authentification Windows Authentification Windows sAMAccountName + mot

intégrée avec intégrée avec de passe
authentification unique authentification unique
transparente transparente Authentification Windows
intégrée
ID de connexion de ID de connexion de
substitution substitution Authentification par
certificat et carte à puce
ID de connexion de
substitution
Windows Hello Entreprise Modèle de confiance de clé Modèle de confiance de clé Modèle de confiance de clé
est-il pris en charge ? Nécessite le niveau
fonctionnel de domaine Modèle de certificat de
Windows Server 2016 confiance
Quelles sont les options Azure AD MFA Azure AD MFA Azure AD MFA
multifacteur ? Contrôles personnalisés Contrôles personnalisés Serveur Azure MFA
avec accès conditionnel* avec accès conditionnel*
MFA tiers
Contrôles personnalisés
avec accès conditionnel*
Quels sont les états de Comptes désactivés Comptes désactivés Comptes désactivés
compte d’utilisateur pris en (délai pouvant atteindre 30
charge ? minutes) Compte verrouillé Compte verrouillé
Compte expiré Compte expiré
Mot de passe expiré Mot de passe expiré
Heures de connexion Heures de connexion
Quelles sont les options Accès conditionnel Azure Accès conditionnel Azure Accès conditionnel Azure
d’accès conditionnel ? AD, avec Azure AD AD, avec Azure AD AD, avec Azure AD
Premium Premium Premium
Règles de revendication AD
FS
Le blocage des protocoles Oui Oui Oui

hérités est-il pris en charge
?
Pouvez-vous personnaliser Oui, avec Azure AD Oui, avec Azure AD Oui

le logo, l’image et la Premium Premium
description sur les pages de
connexion ?
Quels sont les scénarios Verrouillage de mot de Verrouillage de mot de Système d’authentification
avancés pris en charge ? passe intelligent passe intelligent multisite à faible latence
Rapports des informations Verrouillage extranet AD FS

d’identification divulguées,
avec Azure AD Premium P2 Intégration aux systèmes
d’identité tiers
NOTE
Contrôles personnalisés dans Azure AD. L’accès conditionnel ne prend actuellement pas en charge l’inscription d’appareil.
Recommandations
Votre système d’identité garantit à vos utilisateurs l’accès aux applications cloud et aux applications métier que
vous migrez et rendez accessibles dans le cloud. Pour assurer la productivité des utilisateurs autorisés et
protéger les données sensibles de votre organisation contre les intrus, k’authentification contrôle l’accès aux
applications.
Utilisez ou activez la synchronisation de hachage du mot de passe, quelle que soit la méthode d’authentification
choisie, et ce pour les raisons suivantes :
1. Haute disponibilité et récupération d’urgence . L’authentification directe et la fédération s’appuient
sur une infrastructure locale. Pour l’authentification directe, l’empreinte locale inclut le matériel de serveur
et la mise en réseau requis par les agents d’authentification directe. Pour la fédération, l’empreinte locale
est encore plus importante. Elle nécessite des serveurs dans votre réseau de périmètre pour rediriger par
l’intermédiaire d’un proxy les demandes d’authentification et les serveurs de fédération interne.
Pour éviter des points de défaillance uniques, déployez des serveurs redondants. Cette méthode garantit
le traitement des requêtes d’authentification en cas d’échec d’un composant. Du point de vue de
l’authentification directe comme de la fédération, il est aussi attendu que les contrôleurs de domaine
répondent aux demandes d’authentification, qui peuvent également échouer. L’intégrité de nombreux
composants passe par des opérations de maintenance. Si celles-ci ne sont pas planifiées et implémentées
correctement, le risque de panne est plus élevé. La synchronisation de hachage du mot de passe permet
d’éviter les pannes, car le service d’authentification cloud Azure AD de Microsoft est mis à l’échelle
globalement et toujours disponible.
2. Sur vie à une panne locale . Les conséquences d’une panne locale à la suite d’une cyberattaque ou d’un
sinistre peuvent être considérables, de l’atteinte à l’image de marque à la paralysie de l’organisation si
celle-ci ne parvient pas à gérer l’attaque. Récemment, de nombreuses organisations ont été victimes
d’attaques menées par des programmes malveillants, notamment des ransomwares (rançongiciels), qui
ont provoqué la mise hors service de leurs serveurs locaux. Lorsque Microsoft aide les clients à gérer ces
types d’attaques, deux catégories d’organisations se dégagent :
Les organisations qui utilisaient précédemment la synchronisation de hachage de mot de passe en
plus de l’authentification fédérée ou directe ont modifié leur méthode d’authentification principale
pour utiliser la synchronisation de hachage de mot de passe. Ils étaient de nouveau en ligne après
quelques heures. En accédant aux e-mails par le biais de Microsoft 365, elles ont pu résoudre les
problèmes et accéder à d’autres charges de travail sur le cloud.
Les organisations n’ayant pas auparavant activé la synchronisation de hachage du mot de passe
ont dû faire appel à des systèmes de messagerie externes non fiables pour la communication et la
résolution des problèmes. Dans ce cas, il leur a fallu des semaines pour restaurer leur
infrastructure d’identité locale, avant que les utilisateurs ne puissent se connecter à nouveau aux
applications basées sur le Cloud.
3. Protection des identités . Azure AD Identity Protection avec Azure AD Premium P2 est un des meilleurs
moyens de protéger les utilisateurs dans le cloud. Microsoft analyse en permanence Internet à la
recherche de listes d’utilisateurs et de mots de passe vendues et mises à disposition sur le « dark web »
par des utilisateurs malveillants. Azure AD peut utiliser ces informations pour vérifier si les noms
d’utilisateur et les mots de passe de votre organisation sont compromis. Dès lors, il est primordial
d’activer la synchronisation de hachage du mot de passe, et ce quelle que soit la méthode
d’authentification vous utilisez (fédérée ou directe). Les informations d’identification divulguées sont
présentées sous forme de rapport. Utilisez ces informations pour bloquer ou forcer les utilisateurs à
modifier leurs mots de passe lorsqu’ils tentent de se connecter avec des mots de passe divulgués.
Conclusion
Cet article présente les différentes options d’authentification que les organisations peuvent configurer et
déployer pour prendre en charge l’accès aux applications cloud. Face à des exigences professionnelles,
sécuritaires et techniques variées, les organisations ont le choix entre la synchronisation de hachage du mot de
passe, l’authentification directe et la fédération.
Examinez chaque méthode d’authentification. L’effort visant à déployer la solution et l’expérience utilisateur du
processus de connexion répondent-ils aux besoins de votre entreprise ? Déterminez également si votre
organisation a besoin des scénarios avancés et des fonctionnalités de continuité d’activité de chaque méthode
d’authentification. Enfin, vous devez évaluer les considérations relatives à chaque méthode d’authentification
pour voir si l’une d’elles empêche l’implémentation de votre choix.
Étapes suivantes
Aujourd’hui, les menaces sont présentes 24 heures sur 24 et proviennent de partout. L’implémentation d’une
méthode d’authentification appropriée permet d’atténuer les risques en matière de sécurité et de protéger vos
identités.
Démarrez avec Azure AD et déployez la solution d’authentification adaptée à votre organisation.
Si vous envisagez de passer de l’authentification fédérée à l’authentification cloud, découvrez plus en détail
comment changer la méthode de connexion. Pour vous aider à planifier et à implémenter la migration, utilisez
ces plans de déploiement de projet ou envisagez d’utiliser la nouvelle fonctionnalité de Déploiement
intermédiaire pour migrer les utilisateurs fédérés vers à l’aide de l’authentification cloud dans une approche
intermédiaire.
Synchronisation des identités et résilience d’attribut
en double
La résilience d’attribut en double est une fonctionnalité d’Azure Active Directory qui élimine les problèmes liés
aux conflits entre les valeurs UserPrincipalName et ProxyAddress SMTP lors de l’exécution de l’un des outils
de synchronisation de Microsoft.
Ces deux attributs doivent généralement être uniques pour tous les objets Utilisateur , Groupe , ou Contact
dans un client Azure Active Directory donné.
NOTE
Seuls les Utilisateurs peuvent avoir des noms UPN.
Cette fonctionnalité active un nouveau comportement qui se trouve dans la partie cloud du pipeline de
synchronisation. Par conséquent, cette fonctionnalité convient à tout type de client et pour tout produit de
synchronisation Microsoft, y compris Azure AD Connect, DirSync et MIM + Connector. Le terme générique «
client de synchronisation » désigne ces produits dans le présent document.
Comportement actuel
En cas de tentative d’approvisionnement d’un nouvel objet avec une valeur UPN ou ProxyAddress qui enfreint
cette contrainte d’unicité, Azure Active Directory bloque la création de l’objet. De même, si un objet est mis à
jour avec une valeur UPN ou ProxyAddress qui n’est pas unique, la mise à jour échoue. Le client de
synchronisation refait la tentative d’approvisionnement ou la mise à jour à chaque cycle d’exportation ; il échoue
à chaque fois jusqu’à la résolution du conflit. Chaque tentative infructueuse génère un e-mail contenant un
rapport d’erreur, et une erreur est consignée par le client de synchronisation.
Comportement avec une résilience d’attribut en double

Au lieu de rejeter l’approvisionnement ou la mise à jour d’un objet comportant un attribut en double, Azure
Active Directory met en « quarantaine » l’attribut en double qui enfreint la contrainte d’unicité. Si cet attribut est
requis pour l’approvisionnement, comme pour UserPrincipalName, le service affecte une valeur d’espace
réservé. Le format de ces valeurs temporaires est
<OriginalPrefix>+<4DigitNumber>@<InitialTenantDomain>.onmicrosoft.com .
Le processus de résilience d’attribut gère uniquement les valeurs ProxyAddress UPN et SMTP.
Si l’attribut n’est pas obligatoire, comme ProxyAddress , Azure Active Directory met simplement en quarantaine
l’attribut à l’origine du conflit et poursuit la création ou la mise à jour de l’objet.
Lorsque l’attribut est mis en quarantaine, des informations sur le conflit sont envoyées dans le même e-mail de
rapport d’erreur utilisé avec l’ancien comportement. Toutefois, ces informations n’apparaissent qu’une fois dans
le rapport d’erreurs (lors de la mise en quarantaine) ; elles ne sont pas consignées dans les e-mails suivants. En
outre, étant donné que l’exportation de cet objet a réussi, le client de synchronisation ne consigne pas d’erreur et
ne retente pas la création/la mise à jour lors des cycles de synchronisation suivants.
Pour prendre en charge ce comportement, un nouvel attribut a été ajouté aux classes d’objets Utilisateur, Groupe
et Contact :
DirSyncProvisioningErrors
Il s’agit d’un attribut à valeurs multiples utilisé pour stocker les attributs en conflit qui enfreindraient la
contrainte d’unicité s’ils étaient ajoutés normalement. Une tâche du minuteur d’arrière-plan a été activée dans
Azure Active Directory. Celle-ci s’exécute toutes les heures pour rechercher des conflits d’attributs en double
ayant été résolus, puis supprime automatiquement les attributs en question de la quarantaine.
Activer la résilience d’attribut en double
La résilience d’attribut en double sera le nouveau comportement par défaut sur tous les locataires Azure Active
Directory. Elle sera activée par défaut pour tous les clients qui ont activé la synchronisation pour la première fois
le 22 août 2016 ou plus tard. Les clients qui ont activé la synchronisation avant cette date verront cette
fonctionnalité activée par lots. Ce déploiement a commencé en septembre 2016, et une notification par courrier
électronique sera envoyée au contact de notification technique de chaque client la date d’activation de la
fonctionnalité.
NOTE
Une fois que la résilience des attributs en double a été activée, elle ne peut pas être désactivée.
Vous pouvez vérifier si cette fonctionnalité est activée sur votre client en téléchargeant la dernière version du
module Azure Active Directory PowerShell, puis en exécutant ce qui suit :
Get-MsolDirSyncFeatures -Feature DuplicateUPNResiliency
Get-MsolDirSyncFeatures -Feature DuplicateProxyAddressResiliency
NOTE
Vous pouvez n’est plus utiliser l’applet de commande Set-MsolDirSyncFeature pour activer de manière proactive la
fonctionnalité de résilience des attributs en double avant qu’elle ne soit activée pour votre locataire. Pour pouvoir tester la
fonctionnalité, vous devez créer un nouveau locataire Azure Active Directory.
Identification des objets avec DirSyncProvisioningErrors

Il existe actuellement deux méthodes pour identifier les objets qui comportent ces erreurs en raison de conflits
de propriété dupliquée : Azure Active Directory PowerShell et le centre d’administration Microsoft 365. Il est
prévu d’augmenter la capacité de génération de rapports dans le portail.
Azure Active Directory PowerShell
Pour les applets de commande PowerShell dans cette rubrique, les conditions suivantes sont vérifiées :
Toutes les applets de commande suivantes sont sensibles à la casse.
L’indicateur –ErrorCategor y Proper tyConflict doit toujours être inclus. Il n’existe actuellement pas
d’autres types de ErrorCategor y , mais cela pourrait changer.
Commencez par exécuter Connect-MsolSer vice et entrer les informations d’identification d’un administrateur
client.
Utilisez ensuite les applets de commande et les opérateurs suivants pour afficher les erreurs de différentes
manières :
1. Afficher tout
2. Par type de propriété
3. Par valeur en conflit
4. À l’aide d’une recherche de chaîne
5. Triées
6. Par quantité limitée ou l’ensemble des erreurs
Afficher tout
Une fois connecté, exécutez ce qui suit pour voir une liste générale d’erreurs d’approvisionnement d’attribut du
client :
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict
Le résultat ressemble à ce qui suit :
Par type de propriété

Pour voir les erreurs par type de propriété, ajoutez l’indicateur -Proper tyName à l’argument
UserPrincipalName ou ProxyAddresses :
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName UserPrincipalName
ou
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName ProxyAddresses
Par valeur en conflit

Pour afficher les erreurs concernant une propriété spécifique, ajoutez l’indicateur -Proper tyValue ( -
Proper tyName doit également être utilisé avec cet indicateur) :
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyValue User@domain.com -PropertyName
UserPrincipalName
À l’aide d’une recherche de chaîne

Pour effectuer une recherche de chaîne élargie, utilisez l’indicateur -SearchString . Il peut s’utiliser
indépendamment des autres indicateurs ci-dessus, à l’exception de -ErrorCategor y Proper tyConflict , qui est
toujours requis :
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -SearchString User
Par quantité limitée ou l’ensemble des erreurs

1. MaxResults <Int> peut être utilisé pour limiter la requête à un nombre spécifique de valeurs.
2. All permet de vérifier que tous les résultats sont récupérés, notamment si le nombre d’erreurs est élevé.
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -MaxResults 5
Centre d’administration Microsoft 365

Vous pouvez afficher les erreurs de synchronisation d’annuaires dans le Centre d’administration Microsoft 365.
Le rapport dans le centre d’administration Microsoft 365 n’affiche que les objets Utilisateur qui présentent ces
erreurs. Il n’indique pas d’informations sur les conflits entre Groupes et Contacts .
Pour obtenir des instructions sur l’affichage des erreurs de synchronisation d’annuaires dans le Centre
d’administration Microsoft 365, consultez Identifier les erreurs de synchronisation d’annuaires dans Microsoft
365.
Rapport d’erreur de synchronisation d’identité
Lorsqu’un objet présentant un conflit d’attribut en double est traité avec ce nouveau comportement, une
notification afférente est incluse dans l’e-mail standard contenant le rapport d’erreur de synchronisation
d’identité. Ce dernier est envoyé au contact du client en charge des notifications techniques. Toutefois, ce
comportement présente un changement majeur. Auparavant, les informations de conflit d’attribut en double
apparaissaient dans chaque rapport d’erreurs généré jusqu’à la résolution du conflit. Avec ce nouveau
comportement, la notification d’erreur pour un conflit donné n’apparaît qu’une fois : au moment où l’attribut en
conflit est mis en quarantaine.
Voici un exemple de notification par e-mail d’un conflit ProxyAddress :
Résolution des conflits

Les stratégies et tactiques de résolution des problèmes pour ces erreurs ne doivent pas différer de la façon dont
les erreurs d’attribut en double ont été traitées par le passé. La seule différence est que la tâche du minuteur
effectue un balayage du client côté serveur afin d’ajouter automatiquement l’attribut en question à l’objet
concerné lorsque le conflit est résolu.
L’article suivant décrit les différentes stratégies de dépannage et de résolution : Les attributs en double ou non
valides empêchent la synchronisation d’annuaires dans Office 365.
Problèmes connus
Aucun de ces problèmes connus n’entraîne une dégradation du service ou une perte des données. Plusieurs
d’entre eux relèvent de l’esthétisme ; d’autres génèrent des erreurs d’attribut en double («pré-résilience»), au lieu
de mettre en quarantaine l’attribut à l’origine du conflit ; un dernier requiert un travail de correction manuelle
supplémentaire pour certaines erreurs.
Compor tement de base :
1. Les objets ayant une configuration d’attribut spécifique continuent à recevoir des erreurs d’exportation ;
les attributs dupliqués ne sont pas mis en quarantaine.
Par exemple :
a. Un nouvel utilisateur est créé dans AD avec un UPN Joe@contoso.com et une ProxyAddress
smtp:Joe@contoso.com
b. Les propriétés de cet objet sont en conflit avec un Groupe existant, où ProxyAddress est
SMTP:Joe@contoso.com .
c. Lors de l’exportation, une erreur de conflit ProxyAddress est générée au lieu de la mise en
quarantaine des attributs à l’origine du conflit. L’opération est retentée à chaque cycle de synchronisation,
comme cela était le cas avant l’activation de la fonction de résilience.
2. Si deux Groupes sont créés en local avec la même adresse SMTP, l’approvisionnement de l’un d’entre eux
échoue à la première tentative, ce qui génère une erreur standard d’attribut ProxyAddress en double.
Toutefois, la valeur en double est bien mise en quarantaine lors du prochain cycle de synchronisation.
Rappor t du por tail Office :
1. Le message d’erreur détaillé pour deux objets dans un ensemble de conflit UPN est le même. Cela indique
que l’UPN des deux objets a changé/été mis en quarantaine, alors que seules les données de l’un d’entre
eux ont changé.
2. Le message d’erreur détaillé d’un conflit UPN affiche une propriété displayName incorrecte pour un
utilisateur dont l’UPN a changé/été mis en quarantaine. Par exemple :
a. L’utilisateur A est d’abord synchronisé avec UPN = User@contoso.com .
b. L’utilisateur B fait ensuite l’objet d’une tentative de synchronisation avec UPN =
User@contoso.com .
c. L’UPN de l’utilisateur B est remplacée par User1234@contoso.onmicrosoft.com et
User@contoso.com est ajouté à DirSyncProvisioningErrors .
d. Le message d’erreur de l’utilisateur B doit indiquer que l’utilisateur A a déjà User@contoso.com
comme UPN, mais il affiche le paramètre displayName de l’utilisateur B .
Rappor t d’erreur de synchronisation d’identité :
Le lien pour la procédure à suivre pour résoudre ce problème est incorrect :
Il doit pointer vers https://aka.ms/duplicateattributeresiliency.
Voir aussi
Intégration des identités locales dans Azure Active Directory
Identifier les erreurs de synchronisation d’annuaires dans Microsoft 365
Qu’est-ce que la synchronisation de hachage de mot
de passe avec Azure AD ?
La synchronisation de hachage de mot de passe est l’une des méthodes de connexion utilisées pour accomplir
l’identité hybride. Azure AD Connect synchronise le hachage du mot de passe d’un utilisateur entre une instance
Active Directory locale et une instance Azure AD basée sur le cloud.
La synchronisation de hachage de mot de passe est une extension de la fonctionnalité de synchronisation
d’annuaires implémentée par la synchronisation Azure AD Connect. Vous pouvez utiliser cette fonctionnalité
pour vous connecter à des services Azure AD comme Microsoft 365. Vous vous connectez au service à l’aide du
mot de passe que vous utilisez pour vous connecter à votre instance locale d’Active Directory.
La synchronisation de hachage de mot de passe est utile car elle réduit à un seul le nombre de mots de passe
que vos utilisateurs doivent tenir à jour. La synchronisation de hachage de mot de passe peut :
Améliorer la productivité de vos utilisateurs.
Réduire vos coûts de support technique.
La synchronisation du hachage de mot de passe permet également la détection des informations d’identification
ayant fuité pour vos comptes hybrides. Microsoft travaille en collaboration avec les chercheurs sur le
«dark web » et les autorités policières pour trouver les paires nom d’utilisateur/mot de passe disponibles
publiquement. Si l’une de ces paires correspond à celles de nos utilisateurs, le compte associé est passé au
niveau de risque élevé.
NOTE
Seules les nouvelles informations d’identification ayant fuité détectées après l’activation de la synchronisation du hachage
de mot de passe (PHS) sont traitées pour votre locataire. La vérification par rapport aux paires d’informations
d’identification précédemment détectées n’est pas effectuée.
Si vous le souhaitez, vous pouvez configurer la synchronisation de hachage de mot de passe en tant que
dispositif de secours si vous choisissez d’utiliser la Fédération avec Active Directory Federation Services (AD FS)
comme méthode de connexion.
Pour utiliser la synchronisation de hachage de mot de passe dans votre environnement, vous devez :
Installer Azure AD Connect.
Configurez la synchronisation d’annuaire entre votre instance Active Directory locale et votre instance Azure
Active Directory.
Activer la synchronisation de hachage de mot de passe.
Pour plus d’informations, consultez Qu’est-ce que l’identité hybride ?.
Étapes suivantes
Qu’est-ce que l’identité hybride ?
Qu’est-ce que l’authentification directe (PTA) ?
Implémenter la synchronisation de hachage de mot
de passe avec la synchronisation Azure AD Connect
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.

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. 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 l’authentification
unique invisible qui connecte automatiquement les utilisateurs utilisant des appareils d’entreprise connectés au
réseau de l’entreprise.
NOTE
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.
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é.
NOTE
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.
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.
NOTE
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.
En fo r c e C l o u d P a ssw o r d P o l i c y F o r P a ssw o r d Sy n c e d U se r s
S’il existe des utilisateurs synchronisés qui interagissent uniquement avec des services intégrés Azure AD et
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é
EnforceCloudPasswordPolicyForPasswordSyncedUsers.
Quand EnforceCloudPasswordPolicyForPasswordSyncedUsers est désactivée (ce qui est le paramètre par
défaut), Azure AD Connect affecte la valeur « DisablePasswordExpiration » à l’attribut PasswordPolicies. 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-AzureADUser -objectID <User Object ID>).passwordpolicies
Pour activer la fonctionnalité EnforceCloudPasswordPolicyForPasswordSyncedUsers, exécutez la commande

suivante en utilisant le module MSOnline PowerShell, comme illustré ci-dessous. Vous devez taper Oui pour le
paramètre Activer, comme illustré ci-dessous :
Set-MsolDirSyncFeature -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers

cmdlet Set-MsolDirSyncFeature at command pipeline position 1
Supply values for the following parameters:
Enable: yes
Confirm
Continue with this operation?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
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.
Nous vous recommandons d’activer EnforceCloudPasswordPolicyForPasswordSyncedUsers avant d’activer la
synchronisation du hachage de mot de passe, afin 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. Toutefois, 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 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.
Set-AzureADUser -ObjectID <User Object ID> -PasswordPolicies "DisablePasswordExpiration"
NOTE
La commande PowerShell Set-MsolPasswordPolicy ne fonctionne 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
NOTE
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.
Cau t i on
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
recommandons, si le compte a expiré, qu’une action de workflow déclenche un script PowerShell qui désactive
le compte Azure AD de l’utilisateur (via l’applet de commande Set-AzureADUser). Inversement, lorsque le
compte est activé, l’instance Azure AD doit être activée.
Remplacement des mots de passe synchronisés
Un administrateur peut réinitialiser manuellement votre mot de passe à l’aide de Windows PowerShell.
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.
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.
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
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.
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 procédez à une migration depuis AD FS (ou d’autres technologies de fédération) vers la synchronisation de
hachage du mot de passe, nous vous recommandons vivement de vous référer à notre guide de déploiement détaillé,
publié ici.
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.
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
Obtenir un plan de déploiement étape par étape pour la migration à partir des services AD FS vers la
synchronisation de hachage de mot de passe
Configuration de la synchronisation sélective du
hachage de mot de passe pour Azure AD Connect
La synchronisation sélective du hachage de mot de passe est l’une des méthodes de connexion utilisées pour
accomplir l’identité hybride. Azure AD Connect synchronise le hachage du mot de passe d’un utilisateur entre
une instance Active Directory locale et une instance Azure AD basée sur le cloud. Par défaut, une fois qu’elle a été
configurée, la synchronisation du hachage de mot de passe aura lieu sur tous les utilisateurs que vous
synchronisez.
Si vous souhaitez exclure un sous-ensemble d'utilisateurs de la synchronisation du hachage de leurs mots de
passe sur Azure AD, vous pouvez configurer la synchronisation sélective du hachage de mot de passe en suivant
les étapes guidées fournies dans cet article.
IMPORTANT
Microsoft ne prend pas en charge la modification ou l’utilisation de la synchronisation Azure AD Connect en dehors des
configurations ou des actions documentées de façon formelle. Ces configurations ou actions peuvent entraîner un état de
synchronisation Azure AD Connect incohérent ou non pris en charge. Par conséquent, Microsoft ne peut pas garantir que
l’équipe du support technique sera en mesure de fournir un support efficace pour de tels déploiements.
Réfléchir à votre implémentation

Pour réduire l’effort administratif de la configuration, vous devez d’abord prendre en compte le nombre d’objets
utilisateur que vous souhaitez exclure de la synchronisation du hachage de mot de passe. Vérifiez lequel des
scénarios ci-dessous, qui s’excluent mutuellement, correspond à vos besoins afin de sélectionner l’option de
configuration qui vous convient.
Si le nombre d’utilisateurs à exclure est inférieur au nombre d’utilisateurs à inclure , suivez les étapes de
cette section.
Si le nombre d’utilisateurs à exclure est supérieur au nombre d’utilisateurs à inclure , suivez les étapes de
cette section.
IMPORTANT
Quelle que soit l’option de configuration choisie, une synchronisation initiale obligatoire (synchronisation complète) pour
appliquer les modifications est effectuée automatiquement lors du cycle de synchronisation suivant.
IMPORTANT
La configuration de la synchronisation sélective du hachage de mot de passe influence directement la réécriture du mot
de passe. Les modifications de mot de passe ou les réinitialisations de mot de passe lancées dans Azure Active Directory
sont réécrites dans Active Directory local uniquement si l’utilisateur est dans l’étendue de la synchronisation de hachage
de mot de passe.
Attribut adminDescription
Les deux scénarios s’appuient sur la définition de l’attribut adminDescription des utilisateurs sur une valeur
spécifique. Cela permet d’appliquer les règles et c’est ce qui permet à la synchronisation sélective du hachage de
mot de passe de fonctionner.
SC ÉN A RIO VA L EUR A DM IN DESC RIP T IO N
Moins d’utilisateurs exclus que d’utilisateurs inclus PHSFiltered
Plus d’utilisateurs exclus que d’utilisateurs inclus PHSIncluded
Cet attribut peut être défini :

à l’aide de l’interface utilisateur Utilisateurs et ordinateurs Active Directory
à l’aide de la cmdlet PowerShell Set-ADUser Pour plus d’informations, consultez Set-ADUser.
Désactiver le planificateur de synchronisation
Avant de commencer l’un ou l’autre scénario, vous devez désactiver le planificateur de synchronisation tout en
modifiant les règles de synchronisation.
1. Démarrez Windows PowerShell et entrez.
set-adsyncscheduler-synccycleenabled$false
2. Vérifiez que le planificateur est désactivé en exécutant la cmdlet suivante :

get-adsyncscheduler
Pour plus d’informations sur le planificateur, consultez Planificateur de synchronisation Azure AD Connect.
Moins d’utilisateurs exclus que d’utilisateurs inclus

La section suivante décrit comment activer la synchronisation sélective du hachage de mot de passe lorsque le
nombre d’utilisateurs à exclure est inférieur au nombre d’utilisateurs à inclure .
IMPORTANT
Avant de continuer, vérifiez que le planificateur de synchronisation est désactivé comme indiqué ci-dessus.
Créez une copie modifiable de l’entrée Entrant depuis AD – Utilisateur AccountEnabled avec l’option
Activer la synchronisation de hachage du mot de passe désélectionnée et définissez son filtre
d’étendue.
Créez une autre copie modifiable de la valeur par défaut Entrant depuis AD – Utilisateur
AccountEnabled avec l’option Activer la synchronisation de hachage du mot de passe sélectionnée
et définissez son filtre d’étendue.
Réactivez le planificateur de synchronisation.
Dans Active Directory, définissez la valeur de l’attribut qui a été défini comme attribut d’étendue sur les
utilisateurs que vous souhaitez autoriser dans la synchronisation du hachage de mot de passe.
IMPORTANT
Les étapes fournies pour configurer la synchronisation sélective du hachage de mot de passe ne concernent que les objets
utilisateur dont l’attribut adminDescription est renseigné dans Active Directory avec la valeur PHSFiltered . Si cet
attribut n’est pas renseigné ou si la valeur est différente de PHSFiltered , ces règles ne seront pas appliquées aux objets
utilisateur.
Configurer les règles de synchronisation nécessaires :

1. Démarrez l’éditeur de règles de synchronisation et définissez les filtres Synchronisation des mots de
passe sur Activé et Type de règle sur Standard .
2. Sélectionnez la règle Entrant depuis AD – Utilisateur AccountEnabled pour le connecteur de forêt

Active Directory sur lequel vous souhaitez configurer la synchronisation sélective du hachage de mot de
passe, puis cliquez sur Modifier . Sélectionnez Oui dans la boîte de dialogue suivante pour créer une copie
modifiable de la règle d’origine.
3. La première règle désactivera la synchronisation du hachage de mot de passe. Donnez le nom suivant à la
nouvelle règle personnalisée : Entrant depuis AD – Utilisateur AccountEnabled – Filtrer les
utilisateurs par PHS . Remplacez la valeur de précédence par un nombre inférieur à 100 (par exemple 90
ou la valeur la plus basse disponible dans votre environnement). Assurez-vous que les cases à cocher
Activer la synchronisation de mot de passe et Désactivé sont décochées. Cliquez sur Suivant .
4. Dans Filtre d’étendue , cliquez sur Ajouter une clause . Sélectionnez adminDescription dans la colonne
d’attribut et EQUAL dans la colonne Opérateur, puis entrez PHSFiltered comme valeur.
5. Aucune autre modification n’est nécessaire. Les règles de jointure et les transformations doivent être
laissées avec les paramètres copiés par défaut ; vous pouvez donc maintenant cliquer sur Enregistrer .
Cliquez sur OK dans la boîte de dialogue d’avertissement indiquant qu’une synchronisation complète sera
exécutée lors du prochain cycle de synchronisation du connecteur.
6. Ensuite, créez une autre règle personnalisée avec la synchronisation du hachage de mot de passe activée.
Sélectionnez de nouveau la règle par défaut Entrant depuis AD – Utilisateur AccountEnabled pour la
forêt Active Directory sur laquelle vous souhaitez configurer la synchronisation sélective du hachage de mot
de passe, puis cliquez sur Modifier . Sélectionnez Oui dans la boîte de dialogue suivante pour créer une
copie modifiable de la règle d’origine.
7. Donnez le nom suivant à la nouvelle règle personnalisée : Entrant depuis AD – Utilisateur
AccountEnabled – Utilisateurs inclus pour la PHS . Remplacez la valeur de précédence par un nombre
inférieur à celui de la règle créée précédemment (dans cet exemple, ce sera 89 ). Vérifiez que la case Activer
la synchronisation de mot de passe est cochée et que celle pour Désactivé est décochée. Cliquez sur
Suivant .
d’attribut et NOTEQUAL dans la colonne Opérateur, puis entrez PHSFiltered comme valeur.
10. Confirmez la création des règles. Supprimez les filtres Synchronisation du mot de passe : Activée et
Type de règle : Standard . Vous devriez voir les deux nouvelles règles que vous venez de créer.
Réactiver le planificateur de synchronisation :
Une fois que vous avez terminé les étapes de configuration des règles de synchronisation nécessaires, réactivez
le planificateur de synchronisation en procédant comme suit :
1. Dans Windows PowerShell, exécutez :
set-adsyncscheduler-synccycleenabled$true
2. Vérifiez ensuite qu’il a été correctement activé en exécutant :

get-adsyncscheduler
Modifier l’attribut adminDescription des utilisateurs :
Une fois toutes les configurations terminées, vous devez modifier l’attribut adminDescription de tous les
utilisateurs que vous souhaitez exclure de la synchronisation du hachage de mot de passe dans Active
Directory et ajouter la chaîne utilisée dans le filtre d’étendue : PHSFiltered .
Vous pouvez également utiliser la commande PowerShell suivante pour modifier l’attribut adminDescription
d’un utilisateur :
set-adusermyuser-replace@{adminDescription="PHSFiltered"}
Plus d’utilisateurs exclus que d’utilisateurs inclus

La section suivante décrit comment activer la synchronisation sélective du hachage de mot de passe lorsque le
nombre d’utilisateurs à exclure est supérieur au nombre d’utilisateurs à inclure .
IMPORTANT
Avant de continuer, vérifiez que le planificateur de synchronisation est désactivé comme indiqué ci-dessus.
Voici un résumé des actions qui seront effectuées dans les étapes ci-dessous :
Créez une copie modifiable de l’entrée Entrant depuis AD – Utilisateur AccountEnabled avec l’option
Activer la synchronisation de hachage du mot de passe désélectionnée et définissez son filtre
d’étendue.
Créez une autre copie modifiable de la valeur par défaut Entrant depuis AD – Utilisateur
AccountEnabled avec l’option Activer la synchronisation de hachage du mot de passe sélectionnée
et définissez son filtre d’étendue.
Réactivez le planificateur de synchronisation.
Dans Active Directory, définissez la valeur de l’attribut qui a été défini comme attribut d’étendue sur les
utilisateurs que vous souhaitez autoriser dans la synchronisation du hachage de mot de passe.
IMPORTANT
Les étapes fournies pour configurer la synchronisation sélective du hachage de mot de passe ne concernent que les objets
utilisateur dont l’attribut adminDescription est renseigné dans Active Directory avec la valeur PHSIncluded . Si cet
attribut n’est pas renseigné ou si la valeur est différente de PHSIncluded , ces règles ne seront pas appliquées aux objets
utilisateur.
Configurer les règles de synchronisation nécessaires :

1. Démarrez l’éditeur de règles de synchronisation et définissez les filtres Synchronisation des mots de
passe sur Activé et Type de règle sur Standard .
2. Sélectionnez la règle Entrant depuis AD – Utilisateur AccountEnabled pour la forêt Active Directory sur
laquelle vous souhaitez configurer la synchronisation sélective du hachage de mot de passe, puis cliquez sur
Modifier . Sélectionnez Oui dans la boîte de dialogue suivante pour créer une copie modifiable de la règle
d’origine.
3. La première règle désactivera la synchronisation du hachage de mot de passe. Donnez le nom suivant à la
nouvelle règle personnalisée : Entrant depuis AD – Utilisateur AccountEnabled – Filtrer les
utilisateurs par PHS . Remplacez la valeur de précédence par un nombre inférieur à 100 (par exemple 90
ou la valeur la plus basse disponible dans votre environnement). Assurez-vous que les cases à cocher
Activer la synchronisation de mot de passe et Désactivé sont décochées. Cliquez sur Suivant .
d’attribut et NOTEQUAL dans la colonne Opérateur, puis entrez PHSIncluded comme valeur.
6. Ensuite, créez une autre règle personnalisée avec la synchronisation du hachage de mot de passe activée.
Sélectionnez de nouveau la règle par défaut Entrant depuis AD – Utilisateur AccountEnabled pour la
forêt Active Directory sur laquelle vous souhaitez configurer la synchronisation sélective du hachage de mot
de passe, puis cliquez sur Modifier . Sélectionnez Oui dans la boîte de dialogue suivante pour créer une
copie modifiable de la règle d’origine.
7. Donnez le nom suivant à la nouvelle règle personnalisée : Entrant depuis AD – Utilisateur
AccountEnabled – Utilisateurs inclus pour la PHS . Remplacez la valeur de précédence par un nombre
inférieur à celui de la règle créée précédemment (dans cet exemple, ce sera 89 ). Vérifiez que la case Activer
la synchronisation de mot de passe est cochée et que celle pour Désactivé est décochée. Cliquez sur
Suivant .
d’attribut et EQUAL dans la colonne Opérateur, puis entrez PHSIncluded comme valeur.
10. Confirmez la création des règles. Supprimez les filtres Synchronisation du mot de passe : Activée et
Type de règle : Standard . Vous devriez voir les deux nouvelles règles que vous venez de créer.
Réactiver le planificateur de synchronisation :

Une fois que vous avez terminé les étapes de configuration des règles de synchronisation nécessaires, réactivez
le planificateur de synchronisation en procédant comme suit :
1. Dans Windows PowerShell, exécutez :
set-adsyncscheduler-synccycleenabled$true
2. Vérifiez ensuite qu’il a été correctement activé en exécutant :

get-adsyncscheduler
Modifier l’attribut adminDescription des utilisateurs :
Une fois toutes les configurations terminées, vous devez modifier l’attribut adminDescription pour tous les
utilisateurs que vous souhaitez inclure pour la synchronisation du hachage de mot de passe dans Active
Directory et ajouter la chaîne utilisée dans le filtre d’étendue : PHSIncluded .
Vous pouvez également utiliser la commande PowerShell suivante pour modifier l’attribut adminDescription
d’un utilisateur :
Set-ADUser myuser -Replace @{adminDescription="PHSIncluded"}
Étapes suivantes
Connexion de l’utilisateur avec l’authentification
directe Azure Active Directory
Qu’est-ce que l’authentification directe Azure Active Directory ?

L’authentification directe Azure Active Directory (Azure AD) permet à vos utilisateurs de se connecter aux
applications locales et aux applications cloud à l’aide des mêmes mots de passe. Cette fonctionnalité offre aux
utilisateurs une meilleure expérience : moins de mots de passe à mémoriser et réduction des coûts de support
technique informatique, car les utilisateurs sont moins susceptibles d’oublier comment se connecter. Lorsque les
utilisateurs se connectent à l’aide d’Azure AD, cette fonctionnalité valide les mots de passe utilisateurs
directement à partir d’Active Directory local.
Cette fonctionnalité est une alternative à Synchronisation du hachage de mot de passe Azure AD, qui offre les
mêmes fonctionnalités d’authentification sur le cloud aux organisations. Toutefois, certaines organisations
souhaitant appliquer leurs stratégies de mot de passe et de sécurité Active Directory locales, peuvent choisir
d’utiliser l’authentification directe à la place. Consultez ce guide pour voir une comparaison entre les différentes
méthodes de connexion Azure AD, et savoir comment choisir la méthode de connexion appropriée pour votre
organisation.
Vous pouvez combiner l’authentification directe avec la fonctionnalité Authentification unique transparente. De
cette façon, lorsque vos utilisateurs accèdent à leurs ordinateurs d’entreprise au sein de votre réseau
d’entreprise, ils n’ont pas besoin de saisir leurs mots de passe pour se connecter.
Avantages clés de utilisation de l’authentification directe Azure AD

Une meilleure expérience utilisateur
Les utilisateurs utilisent les mêmes mots de passe pour se connecter aux applications locales et sur le
cloud.
Les utilisateurs passent moins de temps à communiquer avec le service d’assistance informatique
pour résoudre les problèmes de mot de passe.
Les utilisateurs peuvent effectuer les tâches de gestion de mot de passe en libre-service dans le cloud.
Facile à déployer et à gérer
Des déploiements locaux ou une configuration réseau complexes ne sont pas nécessaires.
Seul un agent léger doit être installé localement.
Aucun frais de gestion. L’agent reçoit automatiquement des améliorations et correctifs de bogues.
Sécurisé
Les mots de passe locaux ne sont jamais stockés dans le cloud sous quelque forme que ce soit.
Il protège vos comptes utilisateur en toute transparence avec les stratégies d’accès conditionnel
d’Azure AD, y compris l’authentification multifacteur (MFA), en bloquant l’authentification héritée et en
filtrant des attaques de mot de passe par recherche exhaustive.
L’agent établit uniquement les connexions sortantes depuis votre réseau. Il n’est donc pas nécessaire
d’installer l’agent dans un réseau de périmètre, également appelé DMZ.
La communication entre les agents et Azure AD est sécurisée à l’aide de l’authentification basée sur les
certificats. Ces certificats sont renouvelés automatiquement tous les quelques mois par Azure AD.
Hautement disponible
Il est possible d’installer des agents supplémentaires sur plusieurs serveurs locaux pour assurer la
haute disponibilité des requêtes de connexion.
Présentation des fonctionnalités

Prend en charge la connexion de l’utilisateur dans toutes les applications basées sur un navigateur web et
dans les applications clientes Microsoft Office qui utilisent l’authentification moderne.
Les noms d’utilisateur de connexion peuvent être soit un nom d’utilisateur local par défaut (
userPrincipalName ), soit un autre attribut configuré dans Azure AD Connect (appelé Alternate ID ).
Elle s’utilise très facilement avec les fonctionnalités d’accès conditionnel (telles que l’authentification
multifacteur) pour la sécurisation de vos utilisateurs.
Elle est intégrée à la gestion des mots de passe libre-service sur le cloud, y compris la réécriture des mots de
passe dans l’annuaire Active Directory local et la protection par mot de passe en interdisant l’emploi de mots
de passe courants.
Les environnements à plusieurs forêts sont pris en charge s’il existe des approbations de forêts entre les
forêts AD et si le routage du suffixe de leurs noms est configuré correctement.
Cette fonctionnalité est gratuite et il est inutile de disposer des éditions payantes d’Azure AD pour l’utiliser.
Elle peut être activée via Azure AD Connect.
Elle utilise un agent local léger qui écoute et répond aux requêtes de validation du mot de passe.
L’installation de plusieurs agents fournit une haute disponibilité des requêtes de connexion.
Elle permet de protéger vos comptes locaux contre les attaques de mot de passe par recherche exhaustive
dans le cloud.
Étapes suivantes
Démarrage rapide : commencez à utiliser l’authentification directe Azure AD.
Migrer à partir d’AD FS vers l’authentification directe : guide détaillé de la migration d’AD FS (ou d’autres
technologies de fédération) vers l’authentification directe.
Verrouillage intelligent : configurez la fonctionnalité Verrouillage intelligent sur votre locataire pour protéger
les comptes d’utilisateur.
Limitations actuelles : découvrez les scénarios pris en charge et ceux qui ne le sont pas.
Immersion technique : découvrez comment fonctionne cette fonctionnalité.
Questions fréquentes (FAQ) : réponses aux questions fréquentes.
Résolution des problèmes : découvrez comment résoudre les problèmes courants susceptibles de survenir
avec cette fonctionnalité.
Immersion dans la sécurité : informations techniques supplémentaires sur la fonctionnalité.
Authentification unique transparente Azure AD : explorez en détail cette fonctionnalité complémentaire.
UserVoice : pour le dépôt de nouvelles demandes de fonctionnalités.
Authentification directe Azure Active Directory :
Présentation technique approfondie
Cet article propose une vue d’ensemble du fonctionnement de l’authentification directe Azure Active directory
(Azure AD). Pour en savoir plus sur la sécurité et accéder à d’autres détails techniques, consultez l’article
Présentation approfondie des fonctions de sécurité.
Comment l’authentification directe Azure Active Directory

fonctionne-t-elle ?
NOTE
Pour que l’authentification directe fonctionne, les utilisateurs doivent être approvisionnés dans Azure AD à partir d’une
instance Active Directory locale à l’aide d’Azure AD Connect. La fonctionnalité Authentification directe ne s’applique pas
aux utilisateurs « cloud uniquement ».
Quand un utilisateur tente de se connecter à une application sécurisée par Azure AD et que l’authentification
directe est activée sur le client, les étapes suivantes se produisent :
1. L'utilisateur tente d’accéder à une application, par exemple, Outlook Web App.
2. Si l’utilisateur n’est pas déjà connecté, il est redirigé vers la page Connexion de l'utilisateur Azure AD.
3. L’utilisateur entre son nom d’utilisateur dans la page de connexion Azure AD, puis sélectionne le bouton
Suivant .
4. L’utilisateur entre son mot de passe dans la page de connexion Azure AD, puis sélectionne le bouton Se
connecter .
5. Lors de la réception de la demande de connexion, Azure AD place le nom d’utilisateur et le mot de passe
(chiffré à l’aide de la clé publique des agents d’authentification) dans une file d’attente.
6. Un agent d’authentification local récupère le nom d’utilisateur et le mot de passe chiffré à partir de la file
d’attente. Notez que l’agent n’interroge pas fréquemment les requêtes à partir de la file d’attente, mais qu’il
les récupère via une connexion permanente établie au préalable.
7. L’agent déchiffre le mot de passe à l’aide de sa clé privée.
8. L’agent valide le nom d’utilisateur et le mot de passe par rapport à votre annuaire Active Directory à l’aide
des API Windows standard, un mécanisme similaire à celui utilisé par les services de fédération Active
Directory (AD FS). Le nom d’utilisateur peut être soit le nom d’utilisateur sur site par défaut, généralement
userPrincipalName , soit un autre attribut (appelé Alternate ID ) configuré dans Azure AD Connect.
9. Le contrôleur de domaine Active Directory sur site évalue la demande et retourne la réponse appropriée
(succès, échec, mot de passe expiré ou utilisateur verrouillé) à l’agent.
10. L’agent d’authentification retourne à son tour cette réponse à Azure AD.
11. Azure AD évalue la réponse et répond à l’utilisateur comme il convient. Par exemple, Azure AD connecte
immédiatement l’utilisateur ou demande une authentification Azure AD Multi-Factor Authentication.
12. Si l’utilisateur parvient à se connecter, il peut accéder à l’application.
Le schéma suivant illustre tous les composants et les étapes impliquées dans ce processus :
Étapes suivantes
Limitations actuelles : Découvrez les scénarios pris en charge et ceux qui ne le sont pas.
Démarrage rapide : soyez opérationnel sur l’authentification directe Azure AD.
Forum aux questions : obtenez des réponses aux questions fréquemment posées.
Résoudre les problèmes : apprenez à résoudre les problèmes courants liés à la fonctionnalité
d’authentification directe.
Présentation approfondie de la sécurité : obtenez des informations techniques détaillées sur la fonctionnalité
Authentification unique fluide Azure AD : explorez en détail cette fonctionnalité complémentaire.
UserVoice : utilisez le Forum Azure Active Directory pour consigner de nouvelles demandes de
fonctionnalités.
Limites actuelles
Scénarios pris en charge

Les scénarios suivants sont pris en charge :
L’utilisateur se connecte à des applications s’appuyant sur un navigateur web.
L’utilisateur se connecte aux clients Outlook à l’aide des protocoles hérités, comme Exchange ActiveSync, EAS,
SMTP, POP et IMAP.
L’utilisateur se connecte aux applications clientes Office héritées et aux applications Office prenant en charge
l’authentification moderne : Versions 2013 et 2016 d'Office.
L’utilisateur se connecte à des applications de protocole héritées, telles que PowerShell version 1.0, etc.
Jonctions Azure AD pour les appareils Windows 10.
Mots de passe d'application pour l’authentification multifacteur.
Scénarios non pris en charge

Les scénarios suivants ne sont pas pris en charge :
Détection des utilisateurs avec des informations d’identification volées.
Azure AD Domain Services a besoin que la synchronisation du hachage de mot de passe soit activée sur le
locataire. Ainsi, les locataires qui utilisent l’authentification directe uniquement ne fonctionnent pas pour les
scénarios qui ont besoin d’Azure AD Domain Services.
L’authentification directe n’est pas intégrée à Azure AD Connect Health.
La connexion à des appareils joints Azure AD (AADJ) avec un mot de passe temporaire ou arrivé à expiration
n’est pas prise en charge pour les utilisateurs de l’authentification directe. L’erreur « La méthode de connexion
que vous essayez d’utiliser n’est pas autorisée » s’affiche. Ces utilisateurs doivent se connecter à un
navigateur pour mettre à jour leur mot de passe temporaire.
IMPORTANT
Comme solution de contournement uniquement pour les scénarios non pris en charge (à l’exception de l’intégration
d’Azure AD Connect Health), activez la synchronisation de hachage du mot de passe dans la page Fonctionnalités
facultatives de l’Assistant Azure AD Connect.
NOTE
L’activation de la synchronisation de hachage du mot de passe vous donne la possibilité de basculer l’authentification en
cas d’interruption de votre infrastructure locale. Ce basculement de l’authentification directe vers la synchronisation de
hachage du mot de passe n’est pas automatique. Vous devrez basculer la méthode de connexion manuellement avec
Azure AD Connect. Si le serveur exécutant Azure AD Connect tombe en panne, vous devrez demander de l’aide au
Support Microsoft pour désactiver l’authentification directe.
Étapes suivantes
Démarrage rapide : soyez opérationnel avec l’authentification directe Azure AD.
Verrouillage intelligent : apprenez à configurer la fonctionnalité Verrouillage intelligent sur votre locataire
pour protéger les comptes d'utilisateur.
Présentation technique approfondie : découvrez comment fonctionne la fonctionnalité d'authentification
directe.
Forum Aux Questions : trouvez des réponses aux questions fréquemment posées sur la fonctionnalité
Authentification directe.
Présentation approfondie de sécurité : obtenez des informations techniques détaillées sur la fonctionnalité
fonctionnalités.
Immersion dans la sécurité de l’authentification
Cet article décrit plus en détail le fonctionnement de l’authentification directe Azure Active Directory (Azure AD).
Il se concentre sur les aspects de la fonctionnalité relevant de la sécurité. Cet article est destiné aux
administrateurs de la sécurité et informatiques, aux personnes en charge de la conformité et de la sécurité et aux
autres professionnels de l’informatique qui sont responsables de la sécurité et de la conformité informatiques
dans les PME et dans les grandes entreprises.
Les sujets abordés sont les suivants :
informations techniques détaillées sur l’installation et l’inscription des agents d’authentification ;
informations techniques détaillées sur le chiffrement des mots de passe lors de la connexion de l’utilisateur ;
sécurité des canaux entre les agents d’authentification locale et Azure AD ;
informations techniques détaillées sur la façon de maintenir la sécurité des agents d’authentification ;
autres rubriques relatives à la sécurité.
Principales fonctionnalités de sécurité

Voici les aspects clés de cette fonctionnalité relevant de la sécurité :
Elle repose sur une architecture mutualisée sécurisée qui assure l’isolation des demandes de connexion entre
les locataires.
Les mots de passe locaux ne sont jamais stockés dans le cloud sous quelque forme que ce soit.
Les agents d’authentification locale, qui écoutent et répondent aux demandes de validation de mot de passe,
établissent uniquement des connexions sortantes à partir de votre réseau. Il n’est pas nécessaire d’installer
ces agents d’authentification dans un réseau de périmètre (DMZ). En tant que bonne pratique, traitez tous les
serveurs exécutant des agents d’authentification comme des systèmes de niveau 0 (voir référence).
Seuls les ports standard (80 et 443) permettent d’établir une communication sortante des agents
d’authentification à Azure AD. Vous n’avez pas besoin d’ouvrir des ports d’entrée sur votre pare-feu.
Le port 443 est utilisé pour toutes les communications sortantes authentifiées.
Le port 80 est utilisé uniquement pour télécharger les listes de révocation de certificats (CRL) pour
s’assurer que les certificats utilisés par cette fonctionnalité n’ont pas été révoqués.
Pour connaître la configuration réseau complète requise, consultez Authentification directe Azure
Active Directory : Démarrage rapide.
Les mots de passe fournis par les utilisateurs pendant la connexion sont chiffrés dans le cloud avant que les
agents d’authentification locale ne l’est acceptent pour être validés dans l’annuaire Active Directory.
Le canal HTTPS entre Azure AD et l’agent d’authentification locale est sécurisé à l’aide de l’authentification
mutuelle.
Il protège vos comptes utilisateur en toute transparence avec les stratégies d’accès conditionnel d’Azure AD, y
compris l’authentification multifacteur (MFA), en bloquant l’authentification héritée et en filtrant des attaques
de mot de passe par recherche exhaustive.
Composants impliqués
Pour plus d’informations générales sur la sécurité opérationnelle et la sécurité des données et des services
Azure AD, consultez le Centre de gestion de la confidentialité. Les composants suivants sont impliqués lorsque
vous utilisez l’authentification directe pour la connexion de l’utilisateur :
Azure AD STS : service d’émission de jeton de sécurité (STS) sans état qui traite les demandes de connexion
et émet des jetons de sécurité pour les navigateurs, les clients ou les services des utilisateurs en fonction des
besoins.
Azure Ser vice Bus : offre une communication cloud avec une messagerie d’entreprise et une
communication relayée qui vous aide à connecter des solutions locales au cloud.
Agent d’authentification Azure AD Connect : Un composant local qui écoute et répond aux requêtes de
validation de mot de passe.
Azure SQL Database : contient des informations sur les agents d’authentification de votre locataire, y
compris ses métadonnées et clés de chiffrement.
Active Director y : annuaire Active Directory local, où sont stockés vos comptes d’utilisateurs et leurs mots
de passe.
Installation et inscription des agents d’authentification

Les agents d’authentification sont installés et inscrits auprès d’Azure AD lorsque vous effectuez les tâches
suivantes :
Activer l’authentification directe via Azure AD Connect
Ajouter d’autres agents d’authentification pour garantir la haute disponibilité des demandes de connexion
Le fonctionnement d’un agent d’authentification implique trois phases principales :
1. Installation de l’agent d’authentification
2. Inscription de l’agent d’authentification
3. Initialisation de l’agent d’authentification
Les sections suivantes décrivent ces étapes de manière détaillée.
Installation de l’agent d’authentification
Seuls les administrateurs généraux peuvent installer un agent d’authentification (à l’aide d’Azure AD Connect ou
de façon autonome) sur un serveur local. Cette installation ajoute deux nouvelles entrées dans la liste Panneau
de configuration > Programmes > Programmes et fonctionnalités :
L’application de l’agent d’authentification proprement dite. Cette application s’exécute avec des privilèges
NetworkService.
L’application de mise à jour qui est utilisée pour mettre à jour automatiquement l’agent d’authentification.
Cette application s’exécute avec des privilèges LocalSystem.
IMPORTANT
Du point de vue de la sécurité, les administrateurs doivent traiter le serveur exécutant l’agent PTA comme s’il s’agissait
d’un contrôleur de domaine. Les serveurs d’agent PTA doivent être renforcés de la même manière que décrit dans
Sécurisation des contrôleurs de domaine contre les attaques
Inscription de l’agent d’authentification

Une fois l’agent d’authentification installé, il doit être inscrit auprès d’Azure AD. Azure AD affecte à chaque agent
d’authentification un certificat d’identité numérique unique qu’il peut utiliser pour sécuriser la communication
avec Azure AD.
La procédure d’inscription lie également l’agent d’authentification à votre locataire. Azure AD sait ainsi que cet
agent d’authentification spécifique est le seul autorisé à gérer les demandes de validation de mot de passe de
votre locataire. Cette procédure est répétée pour chaque nouvel agent d’authentification que vous inscrivez.
Les agents d’authentification suivent la procédure ci-dessous pour s’inscrire auprès d’Azure AD :
1. Azure AD demande tout d’abord à un administrateur général de se connecter à Azure AD avec ses
informations d’identification. Pendant la connexion, l’agent d’authentification acquiert un jeton d’accès qu’il
peut utiliser pour le compte de l’administrateur général.
2. L’agent d’authentification génère ensuite une paire de clés : une clé publique et une clé privée.
Cette paire de clés est générée à l’aide du chiffrement standard RSA 2 048 bits.
La clé privée reste sur le serveur local sur lequel l’agent d’authentification se trouve.
3. L’agent d’authentification effectue une demande d’inscription auprès d’Azure AD via le protocole HTTPS, les
composants suivants étant inclus dans la demande :
Le jeton d’accès obtenu à l’étape 1.
La clé publique générée à l’étape 2.
Une demande de signature de certificat (CSR ou demande de certificat). Cette demande s’applique à
un certificat d’identité numérique, avec Azure AD comme autorité de certification (AC).
4. Azure AD valide le jeton d’accès dans la demande d’inscription et vérifie que la demande provient d’un
administrateur général.
5. Azure AD signe ensuite et renvoie un certificat d’identité numérique à l’agent d’authentification.
L’autorité de certification racine dans Azure AD est utilisée pour signer le certificat.
NOTE
Cette autorité de certification ne figure pas dans le magasin des autorités de certification racine reconnues
approuvées Windows.
L’autorité de certification est utilisée uniquement par la fonctionnalité d’authentification directe.

L’autorité de certification est utilisée uniquement pour signer les CSR lors de l’inscription de
l’agent d’authentification.
Aucun des autres services Azure AD n’utilise cette autorité de certification.
L’objet du certificat (Nom unique ou DN) est défini sur votre ID de locataire. Ce DN est un GUID qui
identifie de manière unique votre locataire. Avec ce DN, le certificat ne peut donc être utilisé
qu’avec votre locataire.
6. Azure AD stocke la clé publique de l’agent d’authentification dans une base de données dans Azure SQL
Database, qui est accessible uniquement à Azure AD.
7. Le certificat (émis à l’étape 5) est stocké sur le serveur local dans le magasin de certificats Windows (plus
précisément à l’emplacement CERT_SYSTEM_STORE_LOCAL_MACHINE). Il est utilisé par l’agent
d’authentification et les applications du programme de mise à jour.
Initialisation de l’agent d’authentification
Lorsque l’agent d’authentification démarre, pour la première fois après son inscription ou après le redémarrage
d’un serveur, il recherche un moyen de communiquer en toute sécurité avec le service Azure AD et accepte les
demandes de validation de mot de passe.
Voici comment les agents d’authentification sont initialisés :

1. L’agent d’authentification adresse une demande de démarrage sortante à Azure AD.
Cette demande est effectuée sur le port 443 et sur un canal HTTPS mutuellement authentifié. La
demande utilise le même certificat que celui émis lors de l’inscription de l’agent d’authentification.
2. Azure AD répond à la demande en fournissant une clé d’accès à une file d’attente Azure Service Bus qui est
propre à votre locataire et qui est identifiée par votre ID de locataire.
3. L’agent d’authentification établit une connexion HTTPS sortante persistante (sur le port 443) avec la file
d’attente.
L’agent d’authentification est maintenant prêt à récupérer et à gérer les demandes de validation de
mot de passe.
Si vous avez inscrit plusieurs agents d’authentification sur votre locataire, la procédure d’initialisation permet de
s’assurer que chacun d’eux se connecte à la même file d’attente Service Bus.
Traiter les demandes de connexion

Le diagramme suivant montre comment l’authentification directe traite les demandes de connexion de
l’utilisateur.
L’authentification directe traite une demande de connexion de l’utilisateur comme suit :
1. Un utilisateur tente d’accéder à une application, par exemple, Outlook Web App.
2. Si l’utilisateur n’est pas déjà connecté, l’application redirige le navigateur vers la page de connexion
d’Azure AD.
3. Le service Azure AD STS répond avec la page Connexion utilisateur .
4. L’utilisateur entre son nom d’utilisateur dans la page Connexion utilisateur , puis sélectionne le bouton
Suivant .
5. L’utilisateur entre son mot de passe dans la page Connexion utilisateur , puis sélectionne le bouton Se
connecter .
6. Le nom d’utilisateur et le mot de passe sont envoyés à Azure AD STS dans une requête POST HTTPS.
7. Azure AD STS récupère les clés publiques de tous les agents d’authentification inscrits sur votre locataire à
partir d’Azure SQL Database et les utilise pour chiffrer le mot de passe.
Azure AD STS produit « N » valeurs de mot de passe chiffré pour « N » agents d’authentification
inscrits sur votre locataire.
8. Azure AD STS place la demande de validation de mot de passe (qui inclut le nom d’utilisateur et les valeurs
de mot de passe chiffré) dans la file d’attente Service Bus propre à votre locataire.
9. Étant donné que les agents d’authentification initialisés sont connectés en permanence à la file d’attente
Service Bus, l’un des agents d’authentification disponibles récupère la demande de validation de mot de
passe.
10. L’agent d’authentification localise la valeur de mot de passe chiffré propre à sa clé publique, à l’aide d’un
identificateur, et la déchiffre à l’aide de sa clé privée.
11. L’agent d’authentification tente de valider le nom d’utilisateur et le mot de passe dans l’annuaire
Active Directory local à l’aide de l’API LogonUser Win32 avec le paramètre dwLogonType défini sur
LOGON32_LOGON_NETWORK .
Cette API est la même que celle utilisée par les services de fédération Active Directory (AD FS) pour
connecter les utilisateurs dans un scénario de connexion fédérée.
Cette API sur le processus de résolution standard de Windows Server pour localiser le contrôleur de
domaine.
12. L’agent d’authentification reçoit le résultat depuis Active Directory, tel que réussite, nom d’utilisateur ou mot
de passe incorrect, ou mot de passe expiré.
NOTE
Si l’agent d’authentification échoue lors du processus de connexion, la requête de connexion toute entière est supprimée.
Les requêtes de connexion d'un agent d'authentification ne sont pas transférées vers un autre agent d'authentification
local. Ces agents communiquent uniquement avec le cloud, et non entre eux.
13. L’agent d’authentification retransmet le résultat à Azure AD STS via un canal HTTPS mutuellement authentifié
sortant sur le port 443. L’authentification mutuelle utilise le certificat précédemment émis pour l’agent
d’authentification lors de l’inscription.
14. Azure AD STS vérifie que ce résultat est mis en corrélation avec la demande de connexion spécifique sur
votre locataire.
15. Azure AD STS poursuit avec la procédure de connexion configurée. Par exemple, si la validation du mot de
passe aboutit, l’utilisateur peut devoir s’authentifier via Multi-Factor Authentication ou être redirigé vers
l’application.
Sécurité opérationnelle des agents d’authentification

Pour vous assurer que l’authentification directe reste sécurisée sur le plan opérationnel, Azure AD renouvelle
régulièrement les certificats des agents d’authentification. Azure AD déclenche les renouvellements. Les
renouvellements ne sont pas régis par les agents d’authentification proprement dits.
Pour renouveler la relation d’approbation d’un agent d’authentification avec Azure AD :

1. L’agent d’authentification effectue régulièrement un test ping dans Azure AD (toutes les heures) pour
vérifier s’il est temps de renouveler son certificat. Le certificat est renouvelé 30 jours avant son expiration.
Cette vérification est effectuée via un canal HTTPS mutuellement authentifié et utilise le même
certificat que celui émis lors de l’inscription.
2. Si le service indique qu’il est temps de procéder au renouvellement, l’agent d’authentification génère une
nouvelle paire de clés : une clé publique et une clé privée.
Ces clés sont générées à l’aide du chiffrement standard RSA 2 048 bits.
La clé privée ne quitte jamais le serveur local.
3. L’agent d’authentification effectue ensuite une demande de renouvellement de certificat auprès
d’Azure AD via le protocole HTTPS, les composants suivants étant inclus dans la demande :
Le certificat existant qui est récupéré à partir de l’emplacement
CERT_SYSTEM_STORE_LOCAL_MACHINE dans le magasin de certificats Windows. Comme aucun
administrateur général n’est impliqué dans cette procédure, aucun jeton d’accès n’est nécessaire pour
le compte de l’administrateur général.
La clé publique générée à l’étape 2.
Une demande de signature de certificat (CSR ou demande de certificat). Cette demande s’applique à
un nouveau certificat d’identité numérique, avec Azure AD comme autorité de certification.
4. Azure AD valide le certificat existant dans la demande de renouvellement de certificat. Il vérifie ensuite
que la demande provient d’un agent d’authentification inscrit sur votre locataire.
5. Si le certificat existant est toujours valide, Azure AD signe un nouveau certificat d’identité numérique et le
délivre à l’agent d’authentification.
6. Si le certificat existant est arrivé à expiration, Azure AD supprime l’agent d’authentification dans la liste
des agents d’authentification inscrits de votre locataire. Un administrateur général doit alors installer et
inscrire un nouvel agent d’authentification manuellement.
Utilisez l’autorité de certification racine Azure AD pour signer le certificat.
Définissez l’objet du certificat (Nom unique ou DN) sur votre ID de locataire, qui est un GUID qui
identifie de manière unique votre locataire. Avec le DN, le certificat ne peut être utilisé qu’avec votre
locataire.
7. Azure AD stocke la nouvelle clé publique de l’agent d’authentification dans une base de données dans
Azure SQL Database, qui accessible uniquement à Azure AD. Il invalide également l’ancienne clé publique
associée à l’agent d’authentification.
8. Le nouveau certificat (émis à l’étape 5) est ensuite stocké sur le serveur dans le magasin de certificats
Windows (plus précisément à l’emplacement CERT_SYSTEM_STORE_CURRENT_USER).
Étant donné que la procédure de renouvellement d’approbation se produit de manière non interactive
(sans la présence de l’administrateur général), l’agent d’authentification n’a plus accès pour mettre à
jour le certificat existant à l’emplacement CERT_SYSTEM_STORE_LOCAL_MACHINE.
NOTE
Ce procédure ne supprime pas le certificat proprement dit de l’emplacement
CERT_SYSTEM_STORE_LOCAL_MACHINE.
9. Le nouveau certificat est utilisé dorénavant pour l’authentification. Tous les renouvellements ultérieurs du
certificat remplacent le certificat dans CERT_SYSTEM_STORE_LOCAL_MACHINE.
Mise à jour automatique des agents d’authentification

L’application de mise à jour met automatiquement à jour l’agent d’authentification lors de la sortie d’une
nouvelle version (avec résolution des bogues ou amélioration des performances). L’application de mise à jour ne
traite pas les requêtes de validation de mot de passe de votre locataire.
Azure AD héberge la nouvelle version du logiciel en tant que package Windows Installer (MSI) signé. Le
package MSI est signé à l’aide de Microsoft Authenticode avec l’algorithme de chiffrement SHA256.
Pour mettre à jour automatiquement un agent d’authentification :
1. L’application du programme de mise à jour effectue un test ping dans Azure AD toutes les heures pour
vérifier si une nouvelle version de l’agent d’authentification est disponible.
Cette vérification est effectuée via un canal HTTPS mutuellement authentifié à l’aide du même
certificat que celui émis lors de l’inscription. L’agent d’authentification et le programme de mise à jour
partagent le certificat stocké sur le serveur.
2. Si une nouvelle version est disponible, Azure AD retourne le MSI signé au programme de mise à jour.
3. Le programme de mise à jour vérifie que le MSI est signé par Microsoft.
4. Le programme de mise à jour exécute le MSI. Cette action implique les étapes suivantes :
NOTE
Le programme de mise à jour s’exécute avec les privilèges Système Local.
Arrête le service Agent d’authentification

Installe la nouvelle version de l’agent d’authentification sur le serveur
Redémarre le service Agent d’authentification
NOTE
Si vous avez inscrit plusieurs agents d’authentification sur votre locataire, Azure AD ne renouvelle pas leurs certificats ou
ne les met pas à jour en même temps. Azure AD effectue ces procédures une par une pour s’assurer de la haute
disponibilité des requêtes de connexion.
Étapes suivantes
Limitations actuelles : Découvrez les scénarios pris en charge et ceux qui ne le sont pas.
Démarrage rapide : soyez opérationnel sur l’authentification directe Azure AD.
Fonctionnement : découvrez les principes de fonctionnement de l’authentification directe Azure AD.
Forum Aux Questions : obtenez des réponses aux questions fréquemment posées.
Confidentialité des utilisateurs et authentification
NOTE
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.
Vue d’ensemble
L’authentification directe Azure AD crée les types de journaux suivants, qui peuvent contenir des données
personnelles :
Fichiers journaux des traces Azure AD Connect
Fichiers journaux des traces de l’Agent d’authentification
Fichiers journaux des événements Windows
Améliorez la confidentialité des utilisateurs pour l’authentification directe de deux manières :
1. Sur demande, en extrayant les données d’une personne, puis en supprimant ces données des installations
2. En garantissant qu’aucune donnée n’est conservée plus de 48 heures
Nous recommandons vivement la deuxième option, car elle est plus facile à implémenter et à gérer. Voici les
instructions pour chaque type de journal :
Supprimer les fichiers journaux des traces Azure AD Connect
Vérifiez le contenu du dossier %ProgramData%\AADConnect et supprimez le contenu des journaux de traces
(fichiers trace -*.log ) de ce dossier dans les 48 heures suivant l’installation ou la mise à niveau d’Azure AD
Connect ou la modification de la configuration de l’authentification directe, car cette action peut créer des
données couvertes par la réglementation RGPD.
IMPORTANT
Ne supprimez pas le fichier PersistedState.xml de ce dossier, car il est sert à conserver l’état de l’installation précédente
d’Azure AD Connect et est utilisé quand une mise à niveau est effectuée. Ce fichier ne contiendra jamais de données
relatives à un individu et ne doit jamais être supprimé.
Vous pouvez passer en revue et supprimer ces fichiers journaux des traces à l’aide de l’Explorateur Windows, ou
vous pouvez utiliser le script PowerShell suivant pour effectuer les actions nécessaires :
$Files = ((Get-Item -Path "$env:programdata\aadconnect\trace-*.log").VersionInfo).FileName
Foreach ($file in $Files) {

{Remove-Item -Path $File -Force}
}
Enregistrez le script dans un fichier avec l’extension « .PS1 ». Exécutez ce script selon les besoins.
Pour en savoir plus sur les exigences RGPD relatives à Azure AD Connect, consultez cet article.
Supprimer les journaux des événements de l’Agent d’authentification
Ce produit peut également créer des Journaux des événements Windows . Pour plus d’informations,
consultez cet article.
Pour afficher les journaux d’activité relatifs à l’agent d’authentification directe, ouvrez l’application Obser vateur
d’événements sur le serveur et cherchez dans Application and Ser vice
Logs\Microsoft\AzureAdConnect\AuthenticationAgent\Admin .
Supprimer les fichiers journaux des traces de l’Agent d’authentification
Vous devez régulièrement vérifier le contenu de *%ProgramData%\Microsoft\Azure AD Connect Authentication
Agent\Trace* et supprimer le contenu de ce dossier toutes les 48 heures.
IMPORTANT
Si le service Agent d’authentification est en cours d’exécution, vous ne pourrez pas supprimer le fichier journal actuel dans
le dossier. Arrêtez le service avant de réessayer. Pour éviter les échecs de connexion de l’utilisateur, vous devez déjà avoir
configuré l’authentification directe pour une haute disponibilité.
Vous pouvez passer en revue et supprimer ces fichiers à l’aide de l’Explorateur Windows, ou vous pouvez utiliser
le script qui suit pour effectuer les actions nécessaires :
$Files = ((Get-childitem -Path "$env:programdata\microsoft\azure ad connect authentication agent\trace" -

Recurse).VersionInfo).FileName
Foreach ($file in $files) {

}
Pour planifier une exécution de ce script toutes les 48 heures, effectuez les étapes ci-dessous :
1. Enregistrez le script dans un fichier avec l’extension « .PS1 ».
2. Ouvrez le Panneau de configuration , puis cliquez sur Système et sécurité .
3. Sous le titre Outils d’administration , cliquez sur Tâches planifiées .
4. Dans le Planificateur de tâches , cliquez avec le bouton droit sur Bibliothèque du Planificateur de
tâches , puis cliquez sur Créer une tâche de base .
5. Entrez le nom de la nouvelle tâche, puis cliquez sur Suivant .
6. Sélectionnez Tous les jours pour le Déclencheur de tâche , puis cliquez sur Suivant .
7. Choisissez de répéter tous les deux jours, puis cliquez sur Suivant .
8. Sélectionnez Démarrer un programme comme action, puis cliquez sur Suivant .
9. Tapez PowerShell dans le champ Programme/script. Ensuite, dans le champ Ajouter des arguments
(facultatif ) , entrez le chemin complet du script que vous avez créé précédemment, puis cliquez sur
Suivant .
10. L’écran suivant montre un récapitulatif de la tâche que vous êtes sur le point de créer. Vérifiez les valeurs,
puis cliquez sur Terminer pour créer la tâche :
Remarque concernant les journaux d’activité des contrôleurs de domaine
Si l’enregistrement d’audit est activé, ce produit peut générer des journaux d’activité de sécurité pour vos
contrôleurs de domaine. Pour en savoir plus sur la configuration des stratégies d’audit, consultez cet article.
Étapes suivantes
Lire la politique de confidentialité Microsoft sur le Centre de confidentialité
Résolution des problèmes : découvrez comment résoudre les problèmes courants susceptibles de
survenir avec cette fonctionnalité.
Qu’est-ce que la fédération avec Azure AD ?
La fédération est une collection de domaines pour lesquels une confiance est établie. Le niveau de confiance
peut varier, mais il inclut généralement l’authentification et presque toujours l’autorisation. Une fédération
classique peut inclure plusieurs organisations qui ont établi une confiance pour un accès partagé à un ensemble
de ressources.
Vous pouvez fédérer votre environnement local avec Azure AD et utiliser cette fédération pour l’authentification
et l’autorisation. Cette méthode de connexion garantit que toutes les opérations d’authentification de l’utilisateur
se produisent localement. Cette méthode permet aux administrateurs d’implémenter des niveaux de contrôle
d’accès plus stricts. La fédération est disponible avec AD FS et PingFederate.
TIP
Si vous choisissez d’utiliser la Fédération avec Active Directory Federation Services (AD FS), vous avez la possibilité de
configurer la synchronisation de hachage de mot de passe en tant que dispositif de secours en cas de défaillance de votre
infrastructure AD FS.
Étapes suivantes
Qu’est-ce que l’identité hybride ?
Fonctionnement de la fédération
Fédération avec PingFederate
Azure Active Directory (Azure AD) Connect vous permet de configurer la fédération avec Active Directory
Federation Services (AD FS) et Azure AD au niveau local. Avec l’authentification de fédération, vous pouvez
autoriser les utilisateurs à se connecter aux services Azure AD avec leurs mots de passe locaux sans avoir à les
saisir de nouveau, et ce, alors qu’ils sont sur le réseau d’entreprise. En utilisant l’option de fédération AD FS, vous
pouvez déployer un nouveau service AD FS ou spécifier une installation existante dans une batterie de serveurs
Windows Server 2012 R2.
Cette rubrique présente les fonctions associées à la fédération pour Azure AD Connect. Elle répertorie les liens
vers toutes les autres rubriques qui lui sont associées. Pour consulter les liens vers Azure AD Connect, voir
Intégration de vos identités locales avec Azure Active Directory.
Azure AD Connect : rubriques sur la fédération

RUB RIQ UE SUJET Q U’EL L E A B O RDE ET Q UA N D L A C O N SULT ER
Options de connexion de l’utilisateur via Azure AD

Connect
Présentation des options de connexion de l’utilisateur Découvrez les options de connexion de l’utilisateur et leur
impact sur l’expérience de connexion à Azure.
Installation d’AD FS avec Azure AD Connect
Composants requis Consultez les conditions préalables à l’installation d’AD FS via

Azure AD Connect
Configurer une batterie de serveurs AD FS Installation d’une nouvelle batterie de serveurs AD FS avec
Azure AD Connect
Fédérer avec Azure AD à l’aide d’un ID de connexion de Configurer la fédération à l’aide d’un ID de connexion de
substitution substitution
Modifier la configuration AD FS
Réparation de l’approbation Rétablir l’approbation actuelle entre AD FS et

Microsoft 365/Azure au niveau local.
Ajouter un nouveau serveur AD FS Extension d’une batterie de serveurs AD FS avec l’ajout d’un
serveur AD FS après l’installation initiale
Ajouter un nouveau serveur de proxy d’application web AD Extension d’une batterie de serveurs AD FS avec l’ajout d’un
FS serveur proxy d’application web après l’installation initiale.
Ajouter un nouveau domaine fédéré Ajoutez un domaine à fédérer avec Azure AD.
Mettre à jour le certificat TLS/SSL Mise à jour du certificat TLS/SSL pour une batterie de
serveurs AD FS.
Renouveler des certificats de fédération pour Microsoft 365 Renouvelez votre certificat O365 avec Azure AD.
et Azure AD
Autre configuration de fédération
Fédérer plusieurs instances d’Azure AD avec une seule Fédérer plusieurs instances d’Azure AD avec une seule
instance AD FS batterie de serveurs AD FS
Ajouter un logo/une illustration personnalisée de la société Modifiez l’expérience de connexion en spécifiant le logo
personnalisé qui apparaît sur la page de connexion AD FS.
Ajout d’une description de connexion Modifiez la description de la connexion sur la page de

connexion AD FS.
Modification des règles de revendication AD FS Modifiez ou ajoutez des règles de revendication dans AD FS
pour configurer la synchronisation Azure AD Connect.
Ressources supplémentaires
Fédérer deux Azure AD avec un seul AD FS
Déploiement des services AD FS dans Azure
Déploiement des services AD FS haute disponibilité par-delà les frontières dans Azure avec Azure Traffic
Manager
Azure Active Directory fournit l’authentification unique et une sécurité de l’accès aux applications améliorée
pour Microsoft 365 et d’autres ressources de Microsoft Online Services pour des implémentations hybrides et
uniquement dans le cloud, sans nécessiter de solution tierce. À l’instar de la plupart des services Microsoft
Online, Microsoft 365 est intégré à Azure Active Directory pour les services d’annuaire, l’authentification et
l’autorisation. En outre, Azure Active Directory fournit l’authentification unique à des milliers d’applications SaaS
et à des applications web locales. Consultez la galerie d’applications Azure Active Directory pour connaître les
applications SaaS prises en charge.
Validation IDP
Si votre organisation utilise une solution de fédération tierce, vous pouvez configurer l’authentification unique
pour vos utilisateurs Active Directory locaux avec les services Microsoft Online, tels que Microsoft 365, à
condition que la solution de fédération tierce soit compatible avec Azure Active Directory. Pour toute question
concernant la compatibilité, contactez votre fournisseur d’identité. Si vous souhaitez afficher la liste des
fournisseurs d’identité dont la compatibilité avec Azure AD a déjà été testée par Microsoft, consultez la
documentation sur la compatibilité des fournisseurs d’identité Azure AD.
NOTE
Microsoft ne propose plus de tests de validation de la compatibilité avec Azure Active Directory aux fournisseurs d’identité
indépendants. Si vous souhaitez tester l’interopérabilité de votre produit, suivez ces recommandations.
Étapes suivantes
Intégrer vos répertoires locaux à Azure Active Directory
Authentification unique transparente Azure Active
Directory
Qu’est-ce que l’authentification unique transparente Azure Active

Directory ?
L’authentification unique transparente Azure Active Directory connecte automatiquement les utilisateurs lorsque
leurs appareils d’entreprise sont connectés au réseau de l’entreprise. Lorsque cette fonctionnalité est activée, les
utilisateurs n’ont plus besoin de taper leur mot de passe pour se connecter à Azure AD ni même, dans la plupart
des cas, leur nom d’utilisateur. Cette fonctionnalité offre à vos utilisateurs un accès facilité à vos applications
cloud sans nécessiter de composants locaux supplémentaires.
L’authentification unique transparente peut être combinée avec la synchronisation de hachage de mot de passe
et l’authentification directe. L’authentification unique transparente n’est pas applicable aux services de fédération
Active Directory (AD FS).
Authentification unique à l’aide d’un jeton d’actualisation principal ou

authentification unique fluide
Pour Windows 10, Windows Server 2016 et les versions ultérieures, il est recommandé d’utiliser
l’authentification unique à l’aide d’un jeton d’actualisation principal (PRT). Pour Windows 7 et Windows 8.1, il est
recommandé d’utiliser l’authentification unique transparente. L’authentification unique fluide a besoin que
l’appareil de l’utilisateur soit joint à un domaine, mais cette propriété n’est pas utilisée sur les appareils
Windows 10 avec jointure Azure AD ou jointure hybride Azure AD. L’authentification unique sur des appareils
avec jointure Azure AD, avec jointure hybride Azure AD et inscrits dans Azure AD fonctionne selon le jeton
d’actualisation principal (PRT)
L’authentification unique via PRT fonctionne une fois que les appareils sont inscrits auprès d’Azure AD pour les
appareils Azure AD avec jointure hybride, les appareils avec jointure Azure AD ou les appareils personnels
inscrits via Ajouter un compte professionnel ou scolaire. Pour plus d’informations sur le fonctionnement de
l’authentification unique avec Windows 10 à l’aide de PRT, consultez : Jeton d’actualisation principal (PRT) et
Azure AD
Principaux avantages
Une meilleure expérience utilisateur
Les utilisateurs sont automatiquement connectés aux applications cloud et locales.
Les utilisateurs n’ont pas à saisir leur mot de passe plusieurs fois.
Facile à déployer et à gérer
Aucun composant local supplémentaire n’est nécessaire pour que cela fonctionne.
Fonctionne avec n’importe quelle méthode d’authentification cloud - Synchronisation de hachage de
mot de passe ou Authentification directe.
Peut être déployée pour certains utilisateurs ou pour l’ensemble de vos utilisateurs à l’aide d’une
stratégie de groupe.
Inscrivez des appareils non-Windows 10 auprès d’Azure AD sans avoir besoin d’une infrastructure AD
FS. Cette fonctionnalité exige que vous utilisiez la version 2.1 ou supérieure du client workplace-join.
Présentation des fonctionnalités

Le nom d’utilisateur peut être soit le nom d’utilisateur local par défaut ( userPrincipalName ), soit un autre
attribut configuré dans Azure AD Connect ( Alternate ID ). Les deux cas d’utilisation fonctionnent car
l’authentification unique transparente utilise la revendication securityIdentifier dans le ticket Kerberos
pour rechercher l’objet utilisateur correspondant dans Azure AD.
L’authentification unique transparente est une fonctionnalité opportuniste. Si elle échoue pour une raison
quelconque, l’expérience de connexion utilisateur retrouve son comportement normal (l’utilisateur doit alors
entrer son mot de passe dans la page de connexion).
Si une application (par exemple, https://myapps.microsoft.com/contoso.com ) transfère un paramètre
domain_hint (OpenID Connect) ou whr (SAML), correspondant à votre locataire, ou encore un paramètre
login_hint , correspondant à l’utilisateur, dans sa requête de connexion Azure AD, les utilisateurs sont
automatiquement connectés, sans qu’ils n’aient à entrer leurs nom d’utilisateur et mot de passe.
Les utilisateurs obtiennent également une expérience de connexion silencieuse si une application (par
exemple, https://contoso.sharepoint.com ) envoie des demandes de connexion aux points de terminaison
d'Azure AD définis en tant que locataires ; c'est-à-dire, https://login.microsoftonline.com/contoso.com/<..>
ou https://login.microsoftonline.com/<tenant_ID>/<..> au lieu du point de terminaison commun d’Azure AD
; c'est-à-dire, https://login.microsoftonline.com/common/<...> .
La déconnexion est prise en charge. Cela permet aux utilisateurs de choisir le compte Azure AD auquel se
connecter, au lieu d’être connecté automatiquement à l’aide de l’authentification unique transparente.
Les clients Win32 Microsoft 365 (Outlook, Word, Excel, etc.) dotés des versions 16.0.8730.xxxx et ultérieures
sont pris en charge au moyen d’un flux non interactif. En ce qui concerne OneDrive, vous devez activer la
fonctionnalité de configuration silencieuse OneDrive pour une utilisation de l’authentification sans assistance.
L’authentification unique transparente peut être activée par le biais d’Azure AD Connect.
Cette fonctionnalité est gratuite et il est inutile de disposer des éditions payantes d’Azure AD pour l’utiliser.
L’authentification unique est prise en charge par les clients basés sur le navigateur web et les clients Office
qui prennent en charge l’authentification moderne sur les plateformes et navigateurs compatibles avec
l’authentification Kerberos :
SY ST ÈM E
D’EXP LO ITAT IO N IN T ERN ET M IC RO SO F T GO O GL E M O Z IL L A F IREF O
\ N AVIGAT EUR EXP LO RER EDGE**** C H RO M E X SA FA RI
Windows 10 Oui* Oui Oui Oui*** N/A
Windows 8.1 Oui* Oui**** Oui Oui*** N/A

SY ST ÈM E
D’EXP LO ITAT IO N IN T ERN ET M IC RO SO F T GO O GL E M O Z IL L A F IREF O
\ N AVIGAT EUR EXP LO RER EDGE**** C H RO M E X SA FA RI
Windows 8 Oui* N/A Oui Oui*** N/A
Windows Server Oui** N/A Oui Oui*** N/A

2012 R2 ou
version
ultérieure
Mac OS X N/A N/A Oui*** Oui*** Oui***
NOTE
Microsoft Edge (hérité) n’est plus pris en charge.
*Requiert Internet Explorer version 11 ou ultérieure. (À compter du 17 août 2021, les applications et services
Microsoft 365 ne prendront pas en charge IE 11.)
**Requiert Internet Explorer version 11 ou ultérieure. Désactivez le mode protégé amélioré.
***Nécessite une configuration supplémentaire.
****Microsoft Edge basé sur Chromium
Étapes suivantes
Démarrage rapide : découvrez l’authentification unique transparente Azure AD.
Plan de déploiement : plan de déploiement étape par étape.
Immersion technique : découvrez comment fonctionne cette fonctionnalité.
Authentification unique transparente Azure Active
Directory : Présentation technique approfondie
Cet article vous fournit des détails techniques sur le fonctionnement de la fonctionnalité d’authentification
unique (SSO) transparente d’Azure Active Directory.
Fonctionnement de l’authentification unique transparente (SSO)

Cette section est composée de trois parties :
1. Configuration de la fonctionnalité d’authentification unique transparente.
2. Fonctionnement d’une transaction de connexion mono-utilisateur dans un navigateur web avec
l’authentification unique transparente
3. Fonctionnement d’une transaction de connexion mono-utilisateur sur un client natif avec l’authentification
unique transparente
Comment la configuration s’opère -t-elle ?
L’authentification unique transparente s’active via Azure AD Connect comme indiqué ici. Voici ce qu’il se passe
pendant l’activation de la fonctionnalité :
Un compte d’ordinateur ( AZUREADSSOACC ) est créé dans votre Active Directory (AD) local dans chaque forêt
AD que vous synchronisez sur Azure AD (à l’aide d’Azure AD Connect).
Par ailleurs, des noms de principaux du service Kerberos (SPN) sont créés pour être utilisés pendant le
processus de connexion à Azure AD.
La clé de déchiffrement Kerberos du compte d’ordinateur est partagée en toute sécurité avec Azure AD. S’il
existe plusieurs forêts Active Directory, chaque compte d’ordinateur a sa propre clé de déchiffrement
Kerberos unique.
IMPORTANT
Pour des raisons de sécurité, le compte d’ordinateur AZUREADSSOACC doit être fortement protégé. Seuls des
administrateurs de domaine doivent être en mesure de gérer le compte d’ordinateur. Vérifiez que la délégation Kerberos
sur le compte d’ordinateur est désactivée et qu’aucun autre compte dans Active Directory ne dispose d’autorisations de
délégation sur le compte d’ordinateur AZUREADSSOACC . Stockez le compte d’ordinateur dans une unité d’organisation
(UO) où il sera protégé contre les suppressions accidentelles et à laquelle seuls des administrateurs de domaine ont accès.
La clé de déchiffrement Kerberos sur le compte d’ordinateur doit également être traitée comme sensible. Il est fortement
recommandé que vous substituiez la clé de déchiffrement Kerberos du AZUREADSSOACC compte d’ordinateur au moins
tous les 30 jours.
IMPORTANT
L’authentification unique transparente prend en charge les types de chiffrement AES256_HMAC_SHA1 , AES128_HMAC_SHA1
et RC4_HMAC_MD5 pour Kerberos. Il est recommandé de définir le type de chiffrement du compte AzureADSSOAcc$ sur
AES256_HMAC_SHA1 ou un des types AES contre RC4 pour obtenir une sécurité accrue. Le type de chiffrement est stocké
dans l’attribut msDS-SupportedEncryptionTypes du compte de votre Active Directory. Si le AzureADSSOAcc$ type de
chiffrement du compte est défini sur RC4_HMAC_MD5 et que vous voulez le remplacer par l’un des types de chiffrement
AES, veillez d’abord à remplacer la clé de déchiffrement Kerberos du compte AzureADSSOAcc$ comme expliqué dans le
document FAQ, sous la question concernée, sans quoi l’authentification unique transparente ne se produira pas.
Une fois la configuration terminée, l’authentification unique transparente fonctionne de la même façon que
n’importe quelle autre connexion utilisant l’authentification Windows intégrée (IWA).
Fonctionnement des connexions dans un navigateur web avec l’authentification unique transparente
Le flux de connexion dans un navigateur web est le suivant :
1. Un utilisateur tente d’accéder à une application web (par exemple, Outlook Web App -
https://outlook.office365.com/owa/) ) à partir d’un appareil d’entreprise joint à un domaine du réseau de
l’entreprise.
2. Si l’utilisateur n’est pas déjà connecté, il est redirigé vers la page de connexion Azure AD.
3. L’utilisateur tape son nom d’utilisateur dans la page de connexion Azure AD.
NOTE
Pour certaines applications, les étapes 2 et 3 ne sont pas nécessaires.
4. En utilisant JavaScript en arrière-plan, Azure AD demande au client, via une réponse 401 Non autorisé, de
fournir un ticket Kerberos.
5. À son tour, le navigateur demande un ticket à Active Directory pour le compte d’ordinateur
AZUREADSSOACC (qui représente Azure AD).
6. Active Directory localise le compte d’ordinateur et retourne un ticket Kerberos au navigateur chiffré avec
le secret du compte d’ordinateur.
7. Le navigateur transfère le ticket Kerberos reçu de la part d’Active Directory à Azure AD.
8. Azure AD déchiffre le ticket Kerberos, qui comprend l’identité de l’utilisateur connecté à l’appareil
d’entreprise, en utilisant la clé partagée précédemment.
9. À l’issue de l’évaluation, Azure AD retourne un jeton à l’application ou bien demande à l’utilisateur de
fournir des preuves supplémentaires, telles qu’une authentification multifacteur.
10. Si l’utilisateur parvient à se connecter, il peut accéder à l’application.
Le schéma suivant illustre tous les composants et les étapes impliquées dans ce processus.
L’authentification unique transparente est opportuniste, ce qui signifie que si elle échoue, l’expérience de
connexion reprend son comportement normal (l’utilisateur doit entrer son mot de passe pour se connecter).
Fonctionnement des connexions sur un client natif avec l’authentification unique transparente
Le flux de connexion sur un client natif est le suivant :
1. Un utilisateur tente d’accéder à une application native (par exemple, le client Outlook) à partir d’un appareil
d’entreprise joint à un domaine du réseau de l’entreprise.
2. Si l’utilisateur n’est pas déjà connecté, l’application native récupère le nom d’utilisateur de l’utilisateur à partir
de la session Windows de l’appareil.
3. L’application envoie le nom d’utilisateur à Azure AD et récupère le point de terminaison WS-Trust MEX de
votre locataire. Ce point de terminaison WS-Trust est exclusivement utilisé par la fonctionnalité
d'authentification unique transparente et il ne s'agit pas d'une implémentation générale du protocole WS-
Trust sur Azure AD.
4. L’application interroge ensuite le point de terminaison WS-Trust MEX pour savoir si le point de terminaison
d’authentification intégrée est disponible. Le point de terminaison d'authentification intégré est
exclusivement utilisé par la fonctionnalité d'authentification unique transparente.
5. Si l’étape 4 a réussi, une demande d’authentification Kerberos est émise.
6. Si l’application est en mesure de récupérer le ticket Kerberos, il le transfère au point de terminaison
d’authentification intégrée d’Azure AD.
7. Azure AD déchiffre le ticket Kerberos, puis le valide.
8. Azure AD connecte l’utilisateur et émet un jeton SAML pour l’application.
9. L’application envoie ensuite le jeton SAML au point de terminaison du jeton OAuth2 d’Azure AD.
10. Azure AD valide le jeton SAML et envoie un jeton d’accès et un jeton d’actualisation à l’application pour la
ressource spécifiée, ainsi qu’un jeton d’ID.
11. L’utilisateur peut alors accéder aux ressources de l’application.
Le schéma suivant illustre tous les composants et les étapes impliquées dans ce processus.
Étapes suivantes
Démarrage rapide : découvrez l’authentification unique transparente Azure AD.
Confidentialité des utilisateurs et authentification
unique fluide Azure AD
NOTE
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.
Vue d’ensemble
L’authentification unique transparente Azure AD crée le type de journal suivant, pouvant contenir des Données
personnelles :
Fichiers journaux des traces Azure AD Connect
Améliore la confidentialité de l'utilisateur pour l’authentification unique transparente de deux façons :
1. Sur demande, en extrayant les données d’une personne, puis en supprimant ces données des installations
2. En garantissant qu’aucune donnée n’est conservée plus de 48 heures
Nous recommandons vivement la deuxième option, car elle est plus facile à implémenter et à gérer. Voici les
instructions pour chaque type de journal :
Supprimer les fichiers journaux des traces Azure AD Connect
Vérifiez le contenu du dossier %ProgramData%\AADConnect et supprimez le contenu des journaux de traces
(fichiers trace -*.log ) de ce dossier dans les 48 heures suivant l’installation ou la mise à niveau d’Azure AD
Connect ou la modification de la configuration de l’authentification unique fluide, car cette action peut créer des
données couvertes par la réglementation RGPD.
IMPORTANT
Ne supprimez pas le fichier PersistedState.xml de ce dossier, car il est sert à conserver l’état de l’installation précédente
d’Azure AD Connect et est utilisé quand une mise à niveau est effectuée. Ce fichier ne contiendra jamais de données
relatives à un individu et ne doit jamais être supprimé.
Vous pouvez passer en revue et supprimer ces fichiers journaux des traces à l’aide de l’Explorateur Windows, ou
vous pouvez utiliser le script PowerShell suivant pour effectuer les actions nécessaires :
$Files = ((Get-Item -Path "$env:programdata\aadconnect\trace-*.log").VersionInfo).FileName
Foreach ($file in $Files) {

}
Enregistrez le script dans un fichier avec l’extension « .PS1 ». Exécutez ce script selon les besoins.
Pour en savoir plus sur les exigences RGPD relatives à Azure AD Connect, consultez cet article.
Remarque concernant les journaux d’activité des contrôleurs de domaine
Si l’enregistrement d’audit est activé, ce produit peut générer des journaux d’activité de sécurité pour vos
contrôleurs de domaine. Pour en savoir plus sur la configuration des stratégies d’audit, consultez cet article.
Étapes suivantes
Lire la politique de confidentialité Microsoft sur le Centre de confidentialité
Synchronisation d’Azure AD Connect : Comprendre
et personnaliser la synchronisation
Les services de synchronisation Azure Active Directory Connect (synchronisation Azure AD Connect) sont un
composant clé d’Azure AD Connect. Ils se chargent de toutes les opérations liées à la synchronisation des
données d’identité entre votre environnement local et Azure AD. Le logiciel Azure AD Connect Sync est le
successeur de DirSync, de Microsoft Azure AD Sync et de Forefront Identity Manager, avec le connecteur
Azure Active Directory configuré.
Cette rubrique présente le composant Azure AD Connect Sync (également appelé moteur de
synchronisation ) et répertorie les liens vers toutes les autres rubriques qui lui sont associées. Pour consulter
les liens vers Azure AD Connect, voir Intégration de vos identités locales avec Azure Active Directory.
Le service de synchronisation se compose de deux composants, le composant local Azure AD Connect sync et
le composant côté service dans Azure AD, appelé ser vice de synchronisation Azure AD Connect .
Rubriques de synchronisation Azure AD Connect

Principes de base d’Azure AD Connect Sync
Présentation de l’architecture Pour ceux qui découvrent le moteur de synchronisation et

veulent en savoir plus sur l’architecture et les termes utilisés.
Concepts techniques Le sujet de l’architecture est brièvement abordé et les termes

utilisés sont expliqués de manière succincte.
Topologies pour Azure AD Connect Décrit les différents scénarios et topologies pris en charge
par le moteur de synchronisation.
Configuration personnalisée
Exécuter à nouveau l’Assistant Installation Explique les options à votre disposition si vous réexécutez
l’Assistant Installation d’Azure AD Connect.
Comprendre l’approvisionnement déclaratif Décrit le modèle de configuration appelé Approvisionnement

déclaratif.
Comprendre les expressions d’approvisionnement déclaratif Décrit la syntaxe du langage d’expression utilisé dans
l’approvisionnement déclaratif.
Présentation de la configuration par défaut Décrit les règles prêtes à l’emploi et la configuration par
défaut. Explique également comment les règles fonctionnent
en parallèle pour assurer la réussite des scénarios prêts à
l’emploi.
Présentation des utilisateurs et des contacts Suite de la rubrique précédente qui explique comment les
configurations associées aux utilisateurs et contacts se
complètent, en particulier dans un environnement à forêts
multiples.
Comment modifier la configuration par défaut Vous montre comment modifier une configuration commune
pour les flux d’attributs.
Meilleures pratiques pour la modification de la configuration Prend en charge les limitations imposées à la configuration
par défaut fournie par défaut et l’insertion de modifications.
Configurer le filtrage Décrit les différentes options permettant de limiter le

nombre d’objets en cours de synchronisation vers Azure AD
et explique comment les configurer, étape par étape.
Fonctionnalités et scénarios
prévention des suppressions accidentelles Décrit la fonctionnalité de prévention des suppressions

accidentelles et explique comment la configurer.
Scheduler Décrit le planificateur intégré qui importe, synchronise et

exporte les données.
Implémenter la synchronisation de hachage du mot de passe Décrit le fonctionnement de la synchronisation de mot de

passe, en indiquant comment l’implémenter, comment
l’utiliser et comment résoudre les problèmes associés.
Écriture différée des appareils Décrit le fonctionnement de l’écriture différée des appareils
dans Azure AD Connect.
Extensions d’annuaire Explique comment étendre le schéma Azure AD avec vos

propres attributs personnalisés.
Microsoft 365 PreferredDataLocation Décrit comment placer les ressources Microsoft 365 de
l’utilisateur dans la même région que l’utilisateur.
Ser vice de synchronisation
Fonctionnalités du service de synchronisation Azure AD Décrit le service synchronisation et comment modifier les
Connect paramètres de synchronisation dans Azure AD.
Résilience d’attribut en double Décrit comment activer et utiliser la résilience des valeurs
d’attribut en double userPrincipalName et
proxyAddresses .
Opérations et interface utilisateur
Synchronization Service Manager Décrit l’interface utilisateur de Synchronization Service

Manager, notamment les onglets Opérations, Connecteurs,
Metaverse Designer (Concepteur métaverse) et Metaverse
Search (Recherche métaverse).
Considérations et tâches opérationnelles Décrit les problèmes liés au fonctionnement, tels que la
récupération d’urgence.
Procédure
Réinitialiser le compte Azure AD Décrit la réinitialisation des informations d’identification du

compte de service utilisé pour se connecter à Azure AD à
partir de la synchronisation d’Azure AD Connect.
Plus d’informations et de références
Ports Répertorie les ports que vous devez ouvrir entre le moteur
de synchronisation, vos répertoires locaux et Azure AD.
Attributs synchronisés avec Azure Active Directory Répertorie tous les attributs en cours de synchronisation
entre le système AD local et Azure AD.
Référence des fonctions Répertorie toutes les fonctions disponibles dans

l’approvisionnement déclaratif.
Compte de service ADSync
Azure AD Connect installe un service local qui orchestre la synchronisation entre Active Directory et Azure
Active Directory. Le service de synchronisation Microsoft Azure AD Sync (ADSync) s’exécute sur un serveur de
votre environnement local. Les informations d’identification du service sont définies par défaut dans les
installations Express, mais peuvent être personnalisées pour répondre aux exigences de sécurité de votre
organisation. Ces informations d’identification ne sont pas utilisées pour se connecter à vos forêts locales ou à
En termes de planification, il est important de choisir le compte le service ADSync avant d'installer Azure AD
Connect. Toute tentative de modification des informations d'identification après l'installation entraînera un échec
de démarrage du service, une perte d'accès à la base de synchronisation et un échec d'authentification avec vos
répertoires connectés (Azure et AD DS). Aucune synchronisation ne sera possible avant la restauration des
informations d'identification d'origine.
Le service de synchronisation peut s’exécuter sous des comptes différents. Il peut s’exécuter sous un Compte de
service virtuel (VSA), un Compte de service géré (gMSA/sMSA), ou un compte d’utilisateur normal. Les options
prises en charge ont été modifiées avec la version d’avril 2017 et la version de mars 2021 d’Azure AD Connect,
lorsque vous effectuez une nouvelle installation. Si vous mettez à niveau depuis une version antérieure d’Azure
AD Connect, ces options supplémentaires ne sont pas disponibles.
T Y P E DE C O M P T E O P T IO N D’IN STA L L AT IO N DESC RIP T IO N
compte de service virtuel Rapide et personnalisée, avril 2017 et Un compte de service virtuel est utilisé
versions ultérieures pour toutes les installations rapides, à
l’exception des installations sur un
contrôleur de domaine. Pour
l’installation personnalisée, il s’agit de
l’option par défaut, sauf si une autre
option est utilisée.
Compte de service administré Installation personnalisée, avril 2017 et Si vous utilisez un serveur SQL distant,
versions ultérieures nous recommandons d’utiliser un
compte de service administré de
groupe.
Compte de service administré Installation rapide et personnalisée, Un compte de service administré

mars 2021 et versions ultérieures autonome préfixé avec ADSyncMSA_
est créé lors de l’installation pour les
installations rapides lorsqu’il est installé
sur un contrôleur de domaine. Pour
l’installation personnalisée, il s’agit de
l’option par défaut, sauf si une autre
Compte d’utilisateur Rapide et personnalisée, avril 2017 à Un compte d’utilisateur préfixé avec
mars 2021 AAD_ est créé lors de l’installation pour
les installations rapides lorsqu’il est
installé sur un contrôleur de domaine.
Pour l’installation personnalisée, il s’agit
de l’option par défaut, sauf si une autre
T Y P E DE C O M P T E O P T IO N D’IN STA L L AT IO N DESC RIP T IO N
Compte d’utilisateur Installation rapide et personnalisée, Un compte d’utilisateur préfixé avec

mars 2017 et versions antérieures AAD_ est créé lors de l’installation pour
les installations rapides. Lorsque vous
utilisez l’installation personnalisée,
vous pouvez spécifier un autre compte.
IMPORTANT
Si vous utilisez Connect avec une version de mars 2017 ou antérieure, vous ne devez pas réinitialiser le mot de passe du
compte de service, sinon Windows détruit les clés de chiffrement pour des raisons de sécurité. Vous ne pouvez pas
modifier le compte sur un autre compte sans réinstaller Azure AD Connect. Si vous mettez à niveau vers la version d’avril
2017 ou une version ultérieure, il est possible de modifier le mot de passe du compte de service, mais vous ne pouvez pas
modifier le compte utilisé.
IMPORTANT
Vous pouvez uniquement définir le compte de service lors de la première installation. Il n’est pas possible de modifier le
compte de service une fois l’installation terminée. Si vous avez besoin de modifier le mot de passe du compte de service,
cela est pris en charge et les instructions sont disponibles ici.
Le tableau suivant présente les options par défaut, recommandées et prises en charge pour le compte de service
de synchronisation.
Légende :
Le texte Gras indique l’option par défaut et, dans la plupart des cas, l’option recommandée.
Le texte Italique indique l’option recommandée lorsqu’il ne s’agit pas de l’option par défaut.
Non gras - Option prise en charge
Compte local - Compte d’utilisateur local sur le serveur
Compte de domaine - Compte d’utilisateur de domaine
sMSA - Compte de service géré autonome
gMSA - Compte de service géré de groupe
LO C A L DB LO C A L DB / LO C A L SQ L REM OT E SQ L
T Y P E DE M A C H IN E RA P IDE P ERSO N N A L ISÉE P ERSO N N A L ISÉE
ordinateur joint à un VSA VSA gMSA

domaine sMSA Compte du domaine
gMSA
Compte local
Compte du domaine
Contrôleur de domaine sMSA sMSA gMSA

gMSA Compte du domaine
Compte du domaine
compte de service virtuel

Un compte de service virtuel est un type spécial de compte local géré qui ne dispose pas d’un mot de passe et
qui est automatiquement géré par Windows.
Le compte de service virtuel est destiné à être utilisé dans les scénarios où le moteur de synchronisation et SQL
sont sur le même serveur. Si vous utilisez un serveur SQL distant, nous recommandons d’utiliser un compte de
service géré de groupe à la place.
Le compte de service virtuel ne peut pas être utilisé sur un contrôleur de domaine en raison de problèmes avec
l’API de protection des données Windows (DPAPI).
Compte de service administré

Si vous utilisez un serveur SQL distant, nous recommandons d’utiliser un compte de service administré de
groupe. Pour plus d’informations sur la préparation de votre annuaire Active Directory pour le compte de
service géré de groupe, consultez Présentation des comptes de service géré de groupe.
Pour utiliser cette option, sur la page Installer les composants requis, sélectionnez Utiliser un compte de
ser vice existant , puis sélectionnez Compte de ser vice administré .
Il est également possible d’utiliser un Compte de service géré autonome. Toutefois, dans la mesure où vous
pouvez uniquement les utiliser sur l’ordinateur local, il n’existe aucun avantage à les utiliser à la place du compte
de service virtuel par défaut.
Compte de service géré autonome généré automatiquement
Si vous installez Azure AD Connect sur un contrôleur de domaine, un compte de service administré autonome
est créé par l’assistant d’installation (sauf si vous spécifiez le compte à utiliser dans les paramètres
personnalisés). Le compte a pour préfixe ADSyncMSA_ et est associé au service de synchronisation à utiliser.
Ce compte est un compte de domaine géré qui n’a pas de mot de passe et est automatiquement géré par
Windows.
Ce compte est destiné à être utilisé dans les scénarios où le moteur de synchronisation et SQL sont sur le même
contrôleur de domaine.
Compte d’utilisateur
Un compte de service local est créé par l’Assistant d’installation (sauf si vous spécifiez le compte à utiliser dans
les paramètres personnalisés). Le compte a pour préfixe AAD_ et est associé au service de synchronisation à
utiliser. Si vous installez Azure AD Connect sur un contrôleur de domaine, le compte est créé dans le domaine. Le
compte de service AAD_ doit se trouver dans le domaine si :
Vous utilisez un serveur distant exécutant SQL Server.
Vous utilisez un proxy qui nécessite une authentification.
Le compte est créé avec un mot de passe long et complexe qui n’expire pas.
Ce compte permet de stocker les mots de passe des autres comptes de manière sécurisée. Ces autres mots de
passe de compte sont stockés dans la base de données. Les clés privées pour les clés de chiffrement sont
protégées par le chiffrement à clé secrète des services de chiffrement avec l’API de protection des données
(DPAPI) Windows.
Si vous utilisez un serveur SQL Server complet, le compte de service est le propriétaire de la base de données
créée pour le moteur de synchronisation. Le service ne fonctionne pas comme prévu avec d’autres autorisations.
Une connexion SQL est également créée.
En outre, le compte se voit octroyer des autorisations sur les fichiers, les clés de Registre et autres objets liés au
moteur de synchronisation.
Étapes suivantes
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Fonctionnalités de service de synchronisation
d’Azure AD Connect
La fonctionnalité de synchronisation d’Azure AD Connect comprend deux composants :

Le composant local nommé Azure AD Connect sync , également appelé moteur de synchronisation .
Le service résidant dans Azure AD, également appelé ser vice de synchronisation Azure AD Connect
Cette rubrique explique comment les fonctionnalités suivantes du ser vice de synchronisation Azure AD
Connect opèrent et comment les configurer à l’aide de Windows PowerShell.
Ces paramètres sont configurés à partir du module Azure Active Directory pour Windows PowerShell.
Téléchargez et installez-le séparément à partir d’Azure AD Connect. Les applets de commande documentées
dans cette rubrique ont été introduites dans la version de mars 2016 (build 9031.1). Si vous n’avez pas les
applets de commande documentées dans cette rubrique, ou que vous n’obtenez pas le même résultat, vérifiez
que vous exécutez la version la plus récente.
Pour afficher la configuration de votre répertoire Azure AD, exécutez Get-MsolDirSyncFeatures .
Plusieurs de ces paramètres peuvent uniquement être modifiés par Azure AD Connect.
Les paramètres suivants peuvent être configurés par Set-MsolDirSyncFeature :
DIRSY N C F EAT URE C O M M EN TA IRE
EnableSoftMatchOnUpn Permet aux objets d’être joints sur userPrincipalName en

plus de l’adresse SMTP principale.
SynchronizeUpnForManagedUsers Permet au moteur de synchronisation de mettre à jour

l’attribut userPrincipalName pour les utilisateurs
gérés/licenciés(non fédérés).
Lorsqu’une fonctionnalité a été activée, vous ne pouvez plus la désactiver.
NOTE
Depuis le 24 août 2016, la fonctionnalité Résilience d’attribut en double est activée par défaut pour les nouveaux
répertoires Azure AD. Cette fonctionnalité sera également déployée et activée sur les répertoires créés avant cette date.
Vous recevrez une notification par courrier électronique lorsque l’activation de cette fonctionnalité pour votre répertoire
sera imminente .
Les paramètres suivants sont configurés par Azure AD Connect et ne peuvent pas être modifiés par
Set-MsolDirSyncFeature :
DIRSY N C F EAT URE C O M M EN TA IRE
DeviceWriteback Azure AD Connect : Activation de la réécriture d’appareil
DirectoryExtensions Synchronisation Azure AD Connect : Extensions d’annuaire
DuplicateProxyAddressResiliency Permet à un attribut d’être mis en quarantaine lorsqu’il est

DuplicateUPNResiliency un doublon d’un autre objet, plutôt que mettre en échec
l’objet entier lors de l’exportation.
Synchronisation de hachage de mot de passe Implémenter la synchronisation du hachage de mot de passe

avec Azure AD Connect Sync
Authentification directe Connexion de l’utilisateur avec l’authentification directe

UnifiedGroupWriteback Écriture différée de groupe
UserWriteback Non pris en charge actuellement.
Résilience d’attribut en double

Au lieu de rencontrer des problèmes lors de l’approvisionnement des UPN/proxyAddresses en double, l’attribut
en double est « mis en quarantaine » et une valeur temporaire lui est attribuée. Lorsque le conflit est résolu,
l’UPN temporaire est automatiquement converti dans la valeur correcte. Pour plus d’informations, voir
Synchronisation des identités et résilience d’attribut en double.
Correspondance souple UserPrincipalName

Lorsque cette fonctionnalité est activée, la correspondance souple est activée pour l’UPN ainsi que pour l’
adresse SMTP principale, qui est toujours activée. La correspondance souple est utilisée pour faire correspondre
les utilisateurs existants du cloud dans Azure AD avec les utilisateurs locaux.
Cette fonctionnalité est utile lorsque vous mettez en correspondance des comptes AD locaux avec des comptes
existants créés dans le cloud, et que vous n’utilisez pas Exchange Online. Dans ce scénario, vous n’avez
généralement pas de raison pour définir l’attribut SMTP dans le cloud.
Cette fonctionnalité est activée par défaut pour les répertoires Azure AD nouvellement créés. Vous pouvez voir
si cette fonctionnalité est activée en exécutant :
Get-MsolDirSyncFeatures -Feature EnableSoftMatchOnUpn
Si cette fonctionnalité n’est pas activée pour votre répertoire Azure AD, vous pouvez l’activer en exécutant :
Set-MsolDirSyncFeature -Feature EnableSoftMatchOnUpn -Enable $true
BlockSoftMatch
Quand cette fonctionnalité est activée, elle bloque la fonctionnalité de correspondance souple. Les clients sont
encouragés à activer cette fonctionnalité et à la garder activée jusqu’à ce que la correspondance souple soit de
nouveau nécessaire pour leur location. Cet indicateur doit être réactivé une fois que la correspondance souple
est terminée et n’est plus nécessaire.
Exemple : pour bloquer la correspondance souple dans votre locataire, exécutez cette cmdlet :
PS C:\> Set-MsolDirSyncFeature -Feature BlockSoftMatch -Enable $True
Synchroniser les mises à jour userPrincipalName

Historiquement, les mises à jour de l’attribut UserPrincipalName à l’aide du service de synchronisation du site
ont été bloquées, sauf si les deux conditions suivantes étaient remplies :
L’utilisateur est géré (non fédéré).
Aucune licence n’a été attribuée à l’utilisateur.
NOTE
À compter de mars 2019, la synchronisation des modifications d’UPN pour les comptes d’utilisateur fédérés est autorisée.
L’activation de cette fonctionnalité permet au moteur de synchronisation de mettre à jour l’attribut

userPrincipalName quand il est modifié en local et que vous utilisez la synchronisation de hachage de mot de
passe pu l’authentification directe.
Cette fonctionnalité est activée par défaut pour les répertoires Azure AD nouvellement créés. Vous pouvez voir
si cette fonctionnalité est activée en exécutant :
Get-MsolDirSyncFeatures -Feature SynchronizeUpnForManagedUsers
Si cette fonctionnalité n’est pas activée pour votre répertoire Azure AD, vous pouvez l’activer en exécutant :
Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $true
Après avoir activé cette fonctionnalité, les valeurs existantes userPrincipalName demeurent telles quelles. Lors
de la prochaine modification de l’attribut userPrincipalName en local, la synchronisation delta normale sur les
utilisateurs met à jour l’UPN.
Voir aussi
Présentation de l’interface utilisateur de
Synchronization Service Manager d’Azure AD
Connect
L’interface utilisateur de Synchronization Ser vice Manager est utilisée pour configurer des aspects plus
complexes du moteur de synchronisation et pour constater les aspects opérationnels du service.
Vous démarrez l’interface utilisateur de Synchronization Ser vice Manager à partir du menu Démarrer. Elle
se nomme Synchronization Ser vice et se trouve dans le groupe Azure Connect AD .
Étapes suivantes
Découvrez l’interface utilisateur de Synchronization Service Manager, notamment les onglets Opérations,
Connecteurs, Metaverse Designer (Concepteur métaverse) et Metaverse Search (Recherche métaverse).
En savoir plus sur la configuration de la synchronisation Azure AD Connect .
Synchronisation d’Azure AD Connect : Concepts
techniques
Cet article est un résumé de la rubrique Présentation de l’architecture.

Azure AD Connect Sync repose sur une plateforme de synchronisation de méta-annuaire solide. Les sections
suivantes présentent les concepts liés à la synchronisation de méta-annuaire. S’appuyant sur MIIS (Microsoft
Identity Integration Server), ILM (Identity Lifecycle Manager) et FIM (Forefront Identity Manager), les services
Azure Active Directory Sync fournissent la plateforme de nouvelle génération pour la connexion aux sources de
données. Ils synchronisent les données entre des sources de données et assurent l’approvisionnement et le
désapprovisionnement des identités.
Les sections suivantes fournissent plus de détails sur les aspects suivants du service de synchronisation FIM :
Connecteur
Flux d’attributs
Espace de connecteur
Métaverse
Approvisionnement
Connecteur
Les modules de code utilisés pour communiquer avec un annuaire connecté sont appelés connecteurs
(anciennement agents de gestion).
Ils sont installés sur l’ordinateur exécutant Azure AD Connect Sync. Les connecteurs permettent de converser
sans agent à l’aide de protocoles système distants, au lieu de reposer sur le déploiement d’agents spécialisés.
Cela se traduit par une réduction des risques et de la durée de déploiement, en particulier quand il s’agit de
systèmes et d’applications critiques.
Dans l’illustration ci-dessus, le connecteur est synonyme de l’espace de connecteur mais il englobe toutes les
communications avec le système externe.
Le connecteur est responsable de toutes les fonctionnalités d’importation et d’exportation vers le système et il
évite aux développeurs de devoir comprendre comment se connecter à chaque système en mode natif lors de
l’utilisation de l’approvisionnement déclaratif pour personnaliser les transformations de données.
Les importations et exportations ont lieu uniquement quand elles sont planifiées, ce qui offre une isolation
supplémentaire par rapport aux modifications qui se produisent dans le système, dans la mesure où les
modifications ne se propagent pas automatiquement à la source de données connectée. En outre, les
développeurs peuvent également créer leurs propres connecteurs pour se connecter à pratiquement n'importe
quelle source de données.
Flux d’attributs
Le métaverse est l’affichage consolidé de toutes les identités jointes des espaces de connecteur voisins. Dans la
figure ci-dessus, le flux des attributs est représenté par des lignes comportant des flèches pour les flux entrant et
sortant. Le flux des attributs est le processus de copie ou de transformation de données d'un système vers un
autre et vers tous les flux d’attributs (entrants ou sortants).
Le flux d’attributs se produit entre l’espace de connecteur et le métaverse de manière bidirectionnelle quand
l’exécution d’opérations de synchronisation (complète ou delta) est planifiée.
Le flux d’attributs se produit uniquement quand ces synchronisations sont exécutées. Les flux d’attributs sont
définis dans des règles de synchronisation. Ces règles peuvent être entrantes (ISR dans l’image ci-dessus) ou
sortantes (OSR dans l’image ci-dessus).
Système connecté
Système connecté (également appelé annuaire connecté) fait référence au système distant auquel Azure AD
Connect Sync s'est connecté et vers lequel et à partir duquel il lit et écrit des données d'identité.
Espace de connecteur
Chaque source de données connectée est représentée comme un sous-ensemble filtré des objets et des attributs
dans l’espace de connecteur. Cela permet au service de synchronisation de s’exécuter localement sans qu’il soit
nécessaire de contacter le système distant lors de la synchronisation des objets et cela limite l’interaction aux
importations et exportations.
Quand la source de données et le connecteur peuvent fournir une liste de modifications (une importation delta),
l’efficacité opérationnelle augmente considérablement car seules les modifications apportées depuis le dernier
cycle d’interrogation sont échangées. L’espace de connecteur isole la source de données connectée des
modifications qui se propagent automatiquement en exigeant que le connecteur planifie les importations et les
exportations. Cette assurance supplémentaire vous procure une tranquillité d’esprit lors des tests, de l’examen
ou de la confirmation de la mise à jour suivante.
Métaverse
Le métaverse est l’affichage consolidé de toutes les identités jointes des espaces de connecteur voisins.
À mesure que des identités sont liées et que l’autorité est attribuée pour différents attributs via des mappages
de flux d’importation, l’objet de métaverse central commence à regrouper les informations provenant de
plusieurs systèmes. À partir de ce flux d’attributs d’objets, des mappages transmettent des informations aux
systèmes sortants.
Des objets sont créés quand un système faisant autorité les projette dans le métaverse. Dès que toutes les
connexions sont supprimées, l’objet de métaverse est supprimé.
Impossible de modifier directement les objets de métaverse. Toutes les données de l'objet doivent être fournies
via le flux des attributs. Le métaverse conserve les connecteurs permanents avec chaque espace de connecteur.
Ces connecteurs ne nécessitent pas de réévaluation pour chaque exécution de la synchronisation. Cela signifie
qu'Azure AD Connect Sync n'a pas à localiser à chaque fois l'objet distant correspondant. On n'a donc pas besoin
d'agents onéreux pour empêcher des modifications des attributs qui seraient normalement responsables de la
mise en corrélation des objets.
Lors de la découverte de nouvelles sources de données pouvant contenir des objets à gérer, Azure AD Connect
Sync utilise un processus appelé règle de jointure pour évaluer les candidats potentiels avec lesquels établir un
lien. Une fois le lien établi, cette évaluation ne se reproduit pas et le flux d’attributs normal peut se produire
entre la source de données connectée et le métaverse.
Approvisionnement
Quand une source faisant autorité projette un nouvel objet dans le métaverse, un nouvel objet d’espace de
connecteur peut être créé dans un autre connecteur représentant une source de données connectée en aval.
Cela établit intrinsèquement un lien, et le flux d’attributs peut se produire de manière bidirectionnelle.
Chaque fois qu’une règle détermine qu’un nouvel objet d’espace de connecteur doit être créé, on emploie le
terme d’« approvisionnement ». Toutefois, étant donné que cette opération n’a lieu que dans l’espace de
connecteur, elle n’est reportée dans la source de données connectée qu’une fois qu’une exportation est
effectuée.
Synchronisation d’Azure AD Connect : Présentation
de l’architecture
Cette rubrique décrit l’architecture de base pour Azure AD Connect Sync. Celle-ci est similaire à ses
prédécesseurs MIIS 2003, ILM 2007 et FIM 2010 et ce, sur plusieurs plans. Azure AD Connect Sync représente
l’évolution de ces technologies. Si vous connaissez ces technologies plus anciennes, le contenu de cette rubrique
vous sera également familier. Si vous ne connaissez pas la synchronisation, cette rubrique est pour vous. Il n’est
toutefois pas nécessaire de connaître les détails de cette rubrique pour effectuer des personnalisations de
Microsoft Azure AD Connect Sync (appelé « moteur de synchronisation » dans cette rubrique).
Architecture
Le moteur de synchronisation crée une vue intégrée des objets qui sont stockés dans plusieurs sources de
données connectées et gère les informations d’identité dans ces dernières. Cette vue intégrée est déterminée
par les informations d’identité, issues de sources de données connectées, et un ensemble de règles qui
déterminent la manière de traiter ces informations.
Sources de données connectées et connecteurs
Le moteur de synchronisation traite les informations d’identité à partir de différents référentiels de données tels
qu’Active Directory ou une base de données SQL Server. Chaque référentiel de données qui organise ses
données dans un format de type base de données et qui fournit des méthodes d’accès aux données standard est
une source de données potentielle pour le moteur de synchronisation. Les référentiels de données qui sont
synchronisés par le moteur de synchronisation sont appelés sources de données connectées ou annuaires
connectés .
Le moteur de synchronisation encapsule l’interaction avec une source de données connectée au sein d’un
module appelé connecteur . À chaque type de source de données connectée correspond un connecteur
spécifique. Le connecteur traduit une opération requise dans un format que la source de données connectée
peut comprendre.
Les connecteurs effectuent des appels d’API pour échanger des informations d’identité (en lecture et en écriture)
avec une source de données connectée. Il est également possible d’ajouter un connecteur personnalisé à l’aide
de l’infrastructure de connectivité extensible. L’illustration suivante indique comment un connecteur relie une
source de données connectée au moteur de synchronisation.
Les données peuvent circuler dans les deux sens, mais pas simultanément. En d’autres termes, un connecteur
peut être configuré pour autoriser les données à circuler de la source de données connectée au moteur de
synchronisation ou du moteur de synchronisation à la source de données connectée, mais il est uniquement
possible d’effectuer l’une de ces opérations à la fois pour un objet et un attribut. La direction peut être différente
pour divers objets et attributs.
Pour configurer un connecteur, vous spécifiez les types d’objets que vous souhaitez synchroniser. Le fait de
spécifier les types d’objet permet d’avoir une vue globale sur les objets qui sont inclus dans le processus de
synchronisation. L’étape suivante consiste à sélectionner les attributs à synchroniser dans une liste, connue sous
le nom de liste d’inclusion d’attributs. Ces paramètres peuvent être modifiés à tout moment suite aux
modifications apportées aux règles d’entreprise. Ces paramètres sont configurés pour vous lorsque vous utilisez
l’assistant d’installation de Microsoft Azure AD Connect.
Pour exporter des objets vers une source de données connectée, la liste d’inclusion d’attributs doit inclure au
moins le nombre minimal d’attributs requis pour créer un type d’objet spécifique dans une source de données
connectée. Par exemple, l’attribut sAMAccountName doit être inclus dans la liste d’inclusion d’attributs pour
exporter un objet utilisateur dans Active Directory. En effet, un attribut sAMAccountName doit être défini pour
tous les objets utilisateur dans Active Directory. Là encore, l’assistant d’installation effectue cette configuration
pour vous.
Si la source de données connectée utilise des composants structurels, tels que des partitions ou des conteneurs,
pour organiser les objets, vous pouvez limiter les zones de la source de données connectée qui sont utilisées
pour une solution donnée.
Structure interne de l’espace de noms du moteur de synchronisation
La totalité de l’espace de noms du moteur de synchronisation se compose de deux espaces de noms, qui
stockent les informations d’identité. Ces deux espaces sont les suivants :
L’espace connecteur
Le métaverse (MV)
L’ espace connecteur est une zone de transit contenant les représentations des objets désignés à partir d’une
source de données connectée, ainsi que des attributs spécifiés dans la liste d’inclusion d’attributs. Le moteur de
synchronisation utilise l’espace connecteur pour identifier les éléments modifiés dans la source de données
connectée et pour préparer les modifications entrantes. Le moteur de synchronisation utilise également l’espace
connecteur pour préparer les modifications sortantes à des fins d’exportation vers la source de données
connectée. Le moteur de synchronisation gère un espace connecteur distinct en tant que zone de transit pour
chaque connecteur.
Grâce à la zone de transit, le moteur de synchronisation reste indépendant des sources de données connectées
et n’est pas affecté par leur disponibilité et leur accessibilité. Par conséquent, vous pouvez traiter les
informations d’identité à tout moment en utilisant les données de la zone de transit. Le moteur de
synchronisation peut uniquement demander les modifications apportées à l’intérieur de la source de données
connectée depuis l’arrêt de la dernière session de communication, ou émettre uniquement les modifications
apportées aux informations d’identité que la source de données connectée n’a pas encore reçues, ce qui réduit le
trafic réseau entre le moteur de synchronisation et la source de données connectée.
En outre, le moteur de synchronisation stocke les informations d’état sur tous les objets qu’il prépare dans
l’espace connecteur. Lors de la réception de nouvelles données, le moteur de synchronisation évalue toujours si
celles-ci ont déjà été synchronisées.
Le métaverse est une zone de stockage qui contient les informations d’identité agrégées à partir de plusieurs
sources de données connectées, fournissant ainsi une vue globale et intégrée unique de tous les objets
combinés. Les objets métaverse sont créés sur la base des informations d’identité récupérées à partir de sources
de données connectées et d’un ensemble de règles qui vous permettent de personnaliser le processus de
synchronisation.
L’illustration suivante représente l’espace de noms de l’espace connecteur ainsi que l’espace de noms du
métaverse dans le moteur de synchronisation.
Objets d’identité du moteur de synchronisation
Les objets du moteur de synchronisation sont des représentations des objets dans la source de données
connectée, ou de la vue intégrée de ces objets dont dispose le moteur de synchronisation. Chaque objet du
moteur de synchronisation doit avoir un GUID. Les GUID garantissent l’intégrité des données et expriment les
relations entre les objets.
Objets de l’espace connecteur
Lorsque le moteur de synchronisation communique avec une source de données connectée, il lit les
informations d’identité dans cette dernière et utilise ces informations pour créer une représentation de l’objet
d’identité dans l’espace connecteur. Il est impossible de créer ou de supprimer ces objets individuellement.
Cependant, vous pouvez supprimer manuellement tous les objets dans un espace connecteur.
Tous les objets de l’espace connecteur présentent deux attributs :
Un GUID
Un nom unique
Si la source de données connectée affecte un attribut unique à l’objet, les objets de l’espace connecteur peuvent
également présenter un attribut d’ancre. L’attribut d’ancre identifie un objet de manière unique dans la source de
données connectée. Le moteur de synchronisation utilise l’ancre pour localiser la représentation correspondante
de cet objet dans la source de données connectée. Le moteur de synchronisation suppose que l’ancre d’un objet
ne change jamais pendant toute la durée de vie de l’objet.
Plusieurs connecteurs utilisent un identificateur unique connu pour générer automatiquement une ancre pour
chaque objet lors de son importation. Par exemple, le connecteur Active Directory utilise l’attribut objectGUID à
titre d’ancre. Pour les sources de données connectées qui ne fournissent pas un identificateur unique clairement
défini, vous pouvez spécifier la génération d’une ancre dans le cadre de la configuration du connecteur.
Dans ce cas, l’ancre est construite à partir d’un ou de plusieurs attributs uniques d’un type d’objet. Aucun de ces
derniers n’est modifié, ce qui permet d’identifier l’objet de manière unique dans l’espace connecteur (par
exemple, un numéro d’employé ou un ID d’utilisateur).
Un objet d’espace connecteur peut être :
Un objet intermédiaire
Un espace réservé
Objets intermédiaires
Un objet intermédiaire représente une instance des types d’objet désignés de la source de données connectée.
Outre le GUID et le nom unique, un objet intermédiaire présente toujours une valeur qui indique le type d’objet.
Les objets intermédiaires importés présentent toujours une valeur pour l’attribut d’ancre. Les objets
intermédiaires récemment configurés par le moteur de synchronisation et en cours de création dans la source
de données connectée ne présentent aucune valeur pour l’attribut d’ancre.
Les objets intermédiaires comportent aussi des valeurs actuelles pour les attributs d’entreprise ainsi que des
informations opérationnelles nécessaires au moteur pour exécuter le processus de synchronisation. Les
informations opérationnelles comprennent des indicateurs qui désignent le type des mises à jour préparées sur
l’objet intermédiaire. Si un objet intermédiaire a reçu de nouvelles informations d’identité, qui proviennent de la
source de données connectée et qui n’ont pas encore été traitées, l’objet est marqué d’un indicateur «
Impor tation en attente ». Si un objet intermédiaire contient de nouvelles informations d’identité qui n’ont pas
encore été exportées vers la source de données connectée, l’objet est marqué d’un indicateur « En attente
d’expor tation » .
Un objet intermédiaire peut être un objet d’importation ou d’exportation. Le moteur de synchronisation crée un
objet d’importation à l’aide des informations relatives aux objets envoyées par la source de données connectée.
Lorsque le moteur de synchronisation reçoit des informations sur l’existence d’un nouvel objet qui correspond à
l’un des types d’objet sélectionnés dans le connecteur, il crée un objet d’importation dans l’espace connecteur en
tant que représentation de l’objet dans la source de données connectée.
L’illustration suivante montre un objet d’importation représentant un objet dans la source de données
connectée.
Le moteur de synchronisation crée un objet d’exportation à l’aide des informations relatives aux objets dans le
métaverse. Les objets d’exportation sont exportés vers la source de données connectée lors de la session de
communication suivante. Du point de vue du moteur de synchronisation, les objets d’exportation n’existent pas
encore dans la source de données connectée. Par conséquent, l’attribut d’ancre d’un objet d’exportation n’est pas
disponible. Après avoir reçu l’objet du moteur de synchronisation, la source de données connectée crée une
valeur unique pour l’attribut d’ancre de l’objet.
L’illustration suivante illustre la création d’un objet d’exportation à l’aide des informations d’identité dans le
métaverse.
Le moteur de synchronisation confirme l’exportation de l’objet en le réimportant depuis la source de données
connectée. Les objets d’exportation deviennent des objets d’importation lorsque le moteur de synchronisation
les reçoit à la prochaine importation depuis cette source de données connectée.
Espaces réservés
Le moteur de synchronisation utilise un espace de noms plat pour stocker des objets. Toutefois, certaines
sources de données connectées, telles qu’Active Directory, utilisent un espace de noms hiérarchique. Pour
transformer les informations d’un espace de noms hiérarchique dans un espace de noms plat, le moteur de
synchronisation utilise des espaces réservés, afin de conserver la hiérarchie.
Chaque espace réservé représente un composant (par exemple, une unité d’organisation) d’un nom
hiérarchique d’objet qui n’a pas été importé dans le moteur de synchronisation, mais qui est requis pour
construire le nom hiérarchique. Ces éléments comblent les vides créés par des références, dans la source de
données connectée, à des objets qui ne sont pas des objets intermédiaires dans l’espace connecteur.
Le moteur de synchronisation utilise également des espaces réservés pour stocker les objets référencés qui
n’ont pas encore été importés. Par exemple, si la synchronisation est configurée pour inclure l’attribut manager
pour l’objet Abbie Spencer et si la valeur reçue est un objet qui n’a pas été importé, tel que CN=Lee
Sperry,CN=Users,DC=fabrikam,DC=com, les informations de l’élément manager sont stockées en tant
qu’espaces réservés dans l’espace connecteur. Si l’objet manager est ensuite importé, l’objet de l’espace réservé
est remplacé par l’objet intermédiaire qui représente le gestionnaire.
Objets métaverse
Un objet métaverse contient la vue agrégée dont dispose le moteur de synchronisation sur les objets
intermédiaires dans l’espace connecteur. Le moteur de synchronisation crée des objets métaverse à l’aide des
informations contenues dans les objets importés. Plusieurs objets CS (Connector Space) peuvent être liés à un
objet métaverse unique, mais un objet CS (Connector Space) ne peut pas être lié à plusieurs objets métaverse.
Les objets métaverse ne peuvent pas être créés ou supprimés manuellement. Le moteur de synchronisation
supprime automatiquement les objets métaverse qui n’ont pas de lien vers un objet d’espace connecteur
quelconque dans l’espace connecteur.
Pour mapper des objets dans une source de données connectée vers un type d’objet correspondant dans le
métaverse, le moteur de synchronisation fournit un schéma extensible avec un ensemble prédéfini de types
d’objets et attributs associés. Vous pouvez créer des attributs et des types d’objets pour les objets métaverse. Les
attributs peuvent être à valeur unique ou à plusieurs valeurs et les types d’attribut peuvent correspondre à des
chaînes, des références, des chiffres et des valeurs booléennes.
Relations entre les objets intermédiaires et les objets métaverse
Dans l’espace de noms du moteur de synchronisation, le flux de données est activé par la relation entre les
objets intermédiaires et les objets métaverse. Un objet intermédiaire lié à un objet métaverse est appelé objet
joint (ou objet connecteur ). Un objet intermédiaire non lié à un objet métaverse est appelé objet disjoint
(ou objet déconnecteur ). L’utilisation des termes « joint » et « disjoint » est préférable, afin de ne pas les
confondre avec les connecteurs responsables de l’importation et de l’exportation de données à partir d’un
annuaire connecté.
Les espaces réservés ne sont jamais liés à un objet métaverse
Un objet joint comprend un objet intermédiaire et sa relation liée à un objet métaverse unique. Les objets joints
sont utilisés pour synchroniser les valeurs d’attribut entre un objet CS (Connector Space) et un objet métaverse.
Lorsqu’un objet intermédiaire devient un objet joint au cours de la synchronisation, les attributs peuvent circuler
entre l’objet intermédiaire et l’objet métaverse. Le flux d’attributs est bidirectionnel ; il est configuré à l’aide de
règles d’attribut d’importation et d’exportation.
Un objet CS (Connector Space) unique peut être lié à un seul objet métaverse. Toutefois, chaque objet métaverse
peut être lié à plusieurs objets CS (Connector Space) dans le même espace connecteur ou dans des espaces
connecteur différents, comme indiqué dans l’illustration suivante.
La relation entre l’objet intermédiaire et un objet métaverse est persistante et ne peut être supprimée que par les
règles que vous spécifiez.
Un objet disjoint est un objet intermédiaire non lié à un objet métaverse. Les valeurs d’attribut d’un objet
disjoint ne sont pas traitées davantage dans le métaverse. Les valeurs d’attribut de l’objet correspondant dans la
source de données connectée ne sont pas mises à jour par le moteur de synchronisation.
À l’aide des objets disjoints, vous pouvez stocker des informations d’identité dans le moteur de synchronisation
et les traiter ultérieurement. Le fait de conserver un objet intermédiaire sous forme d’objet disjoint dans l’espace
connecteur présente de nombreux avantages. Étant donné que le système a déjà préparé les informations
requises concernant cet objet, il n’est pas nécessaire de créer une représentation de ce dernier lors de
l’importation suivante à partir de la source de données connectée. De cette façon, le moteur de synchronisation
a toujours un aperçu complet de la source de données connectée, même s’il n’existe aucune connexion active à
la source de données connectée. Les objets disjoints peuvent être convertis en objets joints (et vice versa) en
fonction des règles que vous spécifiez.
Un objet d’importation est créé en tant qu’objet disjoint. Un objet d’exportation doit être un objet joint. La
logique du système applique cette règle et supprime chaque objet d’exportation qui n’est pas un objet joint.
Processus de gestion des identités du moteur de synchronisation

Le processus de gestion des identités détermine de quelle manière les informations d’identité sont mises à jour
entre les différentes sources de données connectées. La gestion des identités s’effectue en trois phases :
Importer
Synchronization
Exporter
Pendant le processus d’importation, le moteur de synchronisation évalue les informations d’identité entrantes à
partir d’une source de données connectée. Lorsque des modifications sont détectées, il crée des objets
intermédiaires ou met à jour les objets intermédiaires existants dans l’espace connecteur, à des fins de
synchronisation.
Pendant le processus de synchronisation, le moteur de synchronisation met à jour le métaverse afin de refléter
les modifications qui se sont produites dans l’espace connecteur, actualisant l’espace connecteur pour refléter les
modifications apportées dans le métaverse.
Pendant le processus d’exportation, le moteur de synchronisation envoie les modifications préparées sur les
objets intermédiaires et marquées d’un indicateur signalant l’attente d’une exportation.
L’illustration suivante montre où chaque processus se produit lorsque les informations d’identité circulent d’une
source de données à une autre.
Processus d’importation
Lors du processus d’importation, le moteur de synchronisation évalue les mises à jour des informations
d’identité. Le moteur de synchronisation compare les informations d’identité provenant de la source de données
connectée avec celles d’un objet intermédiaire et détermine si l’objet intermédiaire nécessite des mises à jour.
S’il est nécessaire de mettre à jour l’objet intermédiaire avec les nouvelles données, ce dernier est marqué d’un
indicateur signalant une attente d’importation.
En configurant avec étape intermédiaire les objets dans l’espace connecteur avant la synchronisation, le moteur
de synchronisation peut traiter uniquement les informations d’identité qui ont changé. Ce processus permet de
bénéficier des avantages suivants :
Une synchronisation efficace . La quantité de données traitées pendant la synchronisation est réduite au
minimum.
Une resynchronisation efficace . Vous pouvez modifier le mode de traitement des informations d’identité
par le moteur de synchronisation sans reconnecter la source de données à ce dernier.
La possibilité d’afficher un aperçu de la synchronisation . Vous pouvez afficher un aperçu de la
synchronisation pour vérifier que vos hypothèses sur le processus de gestion d’identité sont correctes.
Pour chaque objet spécifié dans le connecteur, le moteur de synchronisation essaie tout d’abord de localiser une
représentation de l’objet dans l’espace connecteur du connecteur. Le moteur de synchronisation examine tous les
objets intermédiaires dans l’espace connecteur et tente de trouver un objet intermédiaire qui possède un attribut
d’ancre correspondant. Si aucun objet intermédiaire existant ne présente d’attribut d’ancre correspondant, le
moteur de synchronisation essaie de trouver un objet intermédiaire correspondant portant le même nom
unique.
Lorsque le moteur de synchronisation détecte un objet intermédiaire dont le nom unique correspond, mais non
l’ancre, il adopte le comportement spécifique suivant :
Si l’objet situé dans l’espace connecteur n’a aucune ancre, le moteur de synchronisation supprime cet objet de
l’espace connecteur et indique sur l’objet métaverse avec lequel il est lié le message suivant : « refaire une
tentative d’approvisionnement lors de l’exécution de la synchronisation suivante ». Il crée ensuite
un objet d’importation.
Si l’objet situé dans l’espace connecteur a une ancre, le moteur de synchronisation suppose que cet objet a
été renommé ou supprimé dans l’annuaire connecté. Il assigne un nouveau nom unique temporaire à
l’objet CS (Connector Space) afin de pouvoir préparer l’objet entrant. L’ancien objet devient alors
temporaire ; il attend que le connecteur importe l’objet renommé ou supprimé pour résoudre le problème.
Si le moteur de synchronisation localise un objet intermédiaire qui correspond aux objets spécifiés dans le
connecteur, il détermine le type de modifications à appliquer. Le moteur de synchronisation peut, par exemple,
renommer ou supprimer l’objet dans la source de données connectée, ou seulement mettre à jour les valeurs
d’attribut de l’objet.
Les objets intermédiaires avec des données mises à jour sont marqués comme étant en attente d’importation.
Plusieurs types d’importation en attente sont disponibles. Selon le résultat du processus d’importation, un objet
intermédiaire dans l’espace connecteur présente l’un des types d’importations en attente suivants :
Aucun . Aucune modification des attributs de l’objet intermédiaire n’est disponible. Le moteur de
synchronisation ne marque pas ce type d’un indicateur d’attente d’importation.
Ajouter . L’objet intermédiaire est un nouvel objet d’importation dans l’espace connecteur. Le moteur de
synchronisation marque ce type d’un indicateur d’attente d’importation à des fins de traitement
supplémentaire dans le métaverse.
Mettre à jour . Le moteur de synchronisation recherche un objet intermédiaire correspondant dans l’espace
connecteur et marque ce type d’un indicateur d’attente d’importation, afin que les mises à jour des attributs
puissent être traitées dans le métaverse. Les mises à jour comprennent la modification des noms d’objets.
Supprimer . Le moteur de synchronisation recherche un objet intermédiaire correspondant dans l’espace
connecteur et marque ce type d’un indicateur d’attente d’importation afin de pouvoir supprimer l’objet joint.
Supprimer/Ajouter . Le moteur de synchronisation recherche un objet intermédiaire correspondant dans
l’espace connecteur, mais les types d’objet ne correspondent pas. Dans ce cas, une modification de type
suppression-ajout est préparée. Une modification de type suppression-ajout indique au moteur de
synchronisation qu’une resynchronisation complète de cet objet doit être effectuée, car un ensemble de
règles différentes est appliqué à cet objet lorsque le type de ce dernier change.
En définissant un objet intermédiaire comme étant en attente d’importation, vous pouvez réduire
considérablement la quantité de données traitées pendant la synchronisation. Cela permet au système de traiter
uniquement les objets dont les données sont mises à jour.
Processus de synchronisation
La synchronisation consiste en deux processus connexes :
la synchronisation entrante, lorsque le contenu du métaverse est mis à jour via les données de l’espace
connecteur ;
la synchronisation sortante, lorsque le contenu de l’espace connecteur est mis à jour à l’aide des données du
métaverse.
En utilisant les informations préparées dans l’espace connecteur, le processus de synchronisation entrante crée,
dans le métaverse, une vue intégrée des données stockées dans les sources de données connectées. Tous les
objets intermédiaires, ou ceux qui sont en attente d’importation seulement, sont regroupés, selon le mode de
configuration des règles.
Le processus de synchronisation sortante met à jour les objets d’exportation lorsque les objets métaverse sont
modifiés.
La synchronisation entrante crée, dans le métaverse, la vue intégrée des informations d’identité provenant des
sources de données connectées. Le moteur de synchronisation peut traiter les informations d’identité à tout
moment, en utilisant les dernières informations d’identité qu’il a reçues de la source de données connectée.
Synchronisation entrante
La synchronisation entrante comprend les processus suivants :
Configuration (également appelée Projection s’il s’avère nécessaire de distinguer ce processus de
l’approvisionnement de synchronisation sortante). Le moteur de synchronisation crée un objet métaverse
basé sur un objet intermédiaire et les lie l’un à l’autre. La configuration est une opération de niveau objet.
Jointure . Le moteur de synchronisation lie un objet intermédiaire à un objet de métaverse existant.
L’opération de jointure s’effectue au niveau de l’objet.
Flux d’attributs d’impor tation . Le moteur de synchronisation met à jour les valeurs d’attribut de l’objet,
appelées flux de valeur d’attribut, dans le métaverse. Le flux de valeur d’attribut d’importation est une
opération au niveau de l’attribut, qui nécessite un lien entre un objet intermédiaire et un objet de métaverse.
La configuration est le seul processus qui crée des objets dans le métaverse. La configuration affecte
uniquement les objets d’importation qui correspondent à des objets disjoints. Pendant la configuration, le
moteur de synchronisation crée un objet métaverse qui correspond au type de l’objet d’importation et établit un
lien entre les deux objets, créant ainsi un objet joint.
Le processus de jointure établit également un lien entre des objets d’importation et un objet métaverse. Il existe
une différence entre la jointure et l’approvisionnement : le processus de jointure nécessite que l’objet
d’importation soit lié à un objet métaverse existant, tandis que le processus d’approvisionnement crée un objet
métaverse.
Le moteur de synchronisation tente de joindre un objet d’importation à un objet métaverse à l’aide des critères
spécifiés dans la configuration de la règle de synchronisation.
Durant les processus d’approvisionnement et de jointure, le moteur de synchronisation lie un objet disjoint à un
objet métaverse, les joignant. Une fois ces opérations de niveau objet terminées, le moteur de synchronisation
peut mettre à jour les valeurs d’attribut de l’objet métaverse associé. Ce processus est appelé flux de valeur
d’attribut d’importation.
Le flux de valeur d’attribut d’importation se produit sur tous les objets d’importation qui comportent de
nouvelles données et sont liés à un objet métaverse.
Synchronisation sor tante
La synchronisation sortante met à jour les objets d’exportation lorsqu’un objet métaverse est modifié sans être
supprimé. L’objectif de la synchronisation sortante consiste à évaluer si les modifications apportées aux objets
métaverse nécessitent des mises à jour des objets intermédiaires dans les espaces connecteur. Dans certains cas,
les modifications peuvent exiger que les objets intermédiaires dans tous les espaces connecteur soient mis à
jour. Les objets intermédiaires modifiés sont marqués d’un indicateur d’attente d’exportation, ce qui fait d’eux
des objets d’exportation. Ces objets d’exportation sont ensuite transmis à la source de données connectée
pendant le processus d’exportation.
La synchronisation sortante s’effectue en trois phases :
Approvisionnement
Annulation de l’approvisionnement
Flux de valeur d’attribut d’expor tation.
L’approvisionnement et l’annulation de l’approvisionnement sont des opérations de niveau objet. L’annulation
de l’approvisionnement est fonction de l’approvisionnement, car ce dernier est le seul à pouvoir l’initier.
L’annulation est déclenchée lorsque l’approvisionnement supprime le lien entre un objet métaverse et un objet
d’exportation.
L’approvisionnement se déclenche toujours lorsque des modifications sont appliquées aux objets dans le
métaverse. Lorsque des modifications sont apportées aux objets métaverse, le moteur de synchronisation peut
effectuer les tâches suivantes dans le cadre du processus d’approvisionnement :
La création d’objets joints, lors de laquelle un objet métaverse est lié à un objet d’exportation nouvellement
créé.
Le changement de nom d’un objet joint.
La séparation des liens entre un objet métaverse et des objets intermédiaires, créant un objet disjoint.
Si l’approvisionnement nécessite que le moteur de synchronisation crée un objet connecteur, l’objet
intermédiaire auquel est lié l’objet métaverse est toujours un objet d’exportation, car l’objet n’existe pas encore
dans la source de données connectée.
Si l’approvisionnement nécessite que le moteur de synchronisation sépare un objet joint, créant un objet
disjoint, l’annulation de l’approvisionnement est déclenchée. Ce processus d’annulation supprime l’objet.
Lors de cette annulation, la suppression d’un objet d’exportation ne supprime pas physiquement l’objet. L’objet
est marqué d’un indicateur supprimé , ce qui signifie que l’opération de suppression est préparée sur l’objet.
Le flux de valeur d’attribut d’exportation se produit également lors du processus de synchronisation sortante, de
la même manière que le flux de valeur d’attribut d’importation se produit pendant la synchronisation entrante.
Le flux de valeur d’attribut d’exportation se produit uniquement entre les objets métaverse et les objets
d’exportation qui sont joints.
Processus d’exportation
Pendant le processus d’exportation, le moteur de synchronisation examine tous les objets d’exportation qui sont
marqués d’un indicateur d’attente d’exportation dans l’espace connecteur, puis envoie des mises à jour à la
source de données connectée.
Le moteur de synchronisation peut indiquer la réussite d’une exportation, mais ne peut pas déterminer avec
précision si le processus de gestion des identités est terminé. Les objets de la source de données connectée
peuvent toujours être modifiés par d’autres processus. Étant donné que le moteur de synchronisation ne
dispose pas d’une connexion permanente à la source de données connectée, il ne suffit pas d’émettre des
hypothèses sur les propriétés d’un objet dans la source de données connectée sur la seule base d’une
notification d’exportation réussie.
Par exemple, un processus dans la source de données connectée peut basculer les attributs de l’objet vers leurs
valeurs d’origine (autrement dit, la source de données connectée peut remplacer les valeurs immédiatement
après l’envoi des données par le moteur de synchronisation et leur application réussie dans la source de
données connectée).
Le moteur de synchronisation stocke les informations d’état de l’exportation et de l’importation de chaque objet
intermédiaire. Si les valeurs des attributs indiqués dans la liste d’inclusion d’attributs ont changé depuis la
dernière exportation, le stockage des informations d’état de l’exportation et de l’importation permet au moteur
de synchronisation de réagir en conséquence. Le moteur de synchronisation utilise le processus d’importation
pour vérifier les valeurs d’attribut qui ont été exportées vers la source de données connectée. Une comparaison
entre les informations importées et exportées, comme indiqué dans l’illustration suivante, permet au moteur de
synchronisation de déterminer si l’exportation a réussi ou si elle doit être répétée.
Par exemple, si le moteur de synchronisation exporte l’attribut C, qui a la valeur 5, vers une source de données
connectée, il stocke la valeur C=5 dans sa mémoire de statut d’exportation. Chaque exportation supplémentaire
de cet objet entraîne une nouvelle tentative d’exportation de la valeur C=5 vers la source de données connectée,
car le moteur de synchronisation suppose que cette valeur n’a pas été appliquée à l’objet de manière continue
(sauf si une valeur différente a été importée récemment à partir de la source de données connectée). La
mémoire d’exportation est désactivée en cas de réception de la valeur C=5 au cours d’une opération
d’importation sur l’objet.
Étapes suivantes
Azure AD Connect Sync : présentation de
l’approvisionnement déclaratif
Cette rubrique présente le modèle de configuration dans Azure AD Connect. Ce modèle est appelé «
approvisionnement déclaratif » et vous permet de modifier la configuration en toute simplicité. De nombreux
éléments décrits dans cette rubrique sont des éléments avancés, non indispensables pour la plupart des
scénarios clients.
Vue d’ensemble
L’approvisionnement déclaratif correspond au traitement des objets provenant d’un répertoire source connecté.
Il détermine comment l’objet et les attributs doivent être transformés à partir d’une source vers une cible. Les
objets sont traités dans un pipeline de synchronisation identique pour les règles de trafic entrant et sortant. Les
règles de trafic entrant vont d’un espace de connecteur au métaverse et les règles de trafic sortant vont du
métaverse vers un espace de connecteur.
Le pipeline a plusieurs modules. Chacun d’eux est responsable d’un concept de synchronisation des objets.
Source, l’objet source

Scope, recherche toutes les règles de synchronisation dans la portée
Join, détermine la relation entre l’espace de connecteur et le métaverse
Transform, calcule comment les attributs doivent être transformés et circuler
Precedence, résout les contributions d’attribut conflictuelles
Target, l’objet cible
Étendue
Le module Scope évalue un objet et détermine les règles qui sont dans la portée et doivent être incluses lors du
traitement. En fonction des valeurs d’attributs de l’objet, différentes règles de synchronisation sont évaluées
pour être dans la portée. Par exemple, un utilisateur désactivé sans boîte aux lettres Exchange possède des
règles différentes d’un utilisateur activé avec une boîte aux lettres.
La portée est définie selon des groupes et des clauses. Les clauses sont à l’intérieur des groupes. Un opérateur
logique AND est utilisé entre toutes les clauses d’un groupe. Par exemple, (department = IT AND country =
Denmark). Un opérateur logique OR est utilisé entre les groupes.
La portée de cette image doit être lue comme (department = IT AND country = Denmark) OR (country =
Sweden). Si le groupe 1 ou le groupe 2 est évalué comme true, la règle est dans la portée.
Le module Scope prend en charge les opérations suivantes.
O P ÉRAT IO N DESC RIP T IO N
EQUAL, NOTEQUAL Comparaison de chaînes qui évalue si la valeur est égale à la

valeur de l’attribut. Pour les attributs à valeurs multiples,
consultez ISIN et ISNOTIN.
LESSTHAN, LESSTHAN_OR_EQUAL Comparaison de chaînes qui évalue si la valeur est inférieure

à la valeur de l’attribut.
CONTAINS, NOTCONTAINS Comparaison de chaînes qui évalue si la valeur se trouve

dans la valeur de l’attribut.
STARTSWITH, NOTSTARTSWITH Comparaison de chaînes qui évalue si la valeur est au début

de la valeur de l’attribut.
ENDSWITH, NOTENDSWITH Comparaison de chaînes qui évalue si la valeur est à la fin de

la valeur de l’attribut.
GREATERTHAN, GREATERTHAN_OR_EQUAL Comparaison de chaînes qui évalue si la valeur est

supérieure à la valeur de l’attribut.
ISNULL, ISNOTNULL Évalue si l’attribut est absent de l’objet. Si l’attribut n’est pas
présent et par conséquent « null », la règle est dans la
portée.
ISIN, ISNOTIN Évalue si la valeur est présente dans l’attribut défini. Cette
opération est la variation à valeurs multiples des opérations
EQUAL et NOTEQUAL. L’attribut est censé être un attribut à
valeurs multiples et si la valeur se trouve dans une des
valeurs d’attribut, alors la règle est dans la portée.
ISBITSET, ISNOTBITSET Évalue si un bit particulier est défini. Peut par exemple être
utilisé pour évaluer les bits dans userAccountControl pour
voir si un utilisateur est activé ou désactivé.
ISMEMBEROF, ISNOTMEMBEROF La valeur doit contenir un nom unique vers un groupe dans
l’espace de connecteur. Si l’objet est membre du groupe
spécifié, la règle est dans la portée.
Join
Le module Join dans le pipeline de synchronisation est chargé de rechercher la relation entre l’objet de la source
et un objet dans la cible. Sur une règle de trafic entrant, cette relation serait un objet dans un espace de
connecteur ayant une relation avec un objet dans le métaverse.
L’objectif est de voir si une relation doit être établie avec un objet créé par un autre connecteur et se trouvant
déjà dans le métaverse. Par exemple, dans une forêt de ressources de comptes, l’utilisateur de la forêt de
comptes doit être associé à l’utilisateur de la forêt de ressources.
Les jointures sont principalement utilisées sur les règles de trafic entrant, pour joindre les objets d’espace de
connecteur au même objet dans le métaverse.
Les jointures sont définies comme un ou plusieurs groupes. À l’intérieur d’un groupe, il existe des clauses. Un
opérateur logique AND est utilisé entre toutes les clauses d’un groupe. Un opérateur logique OR est utilisé entre
les groupes. Les groupes sont traités de haut en bas. Lorsqu’un groupe a trouvé une correspondance exacte
avec un objet dans la cible, aucune autre règle de jointure n’est évaluée. Si aucun ou plus d’un objet est trouvé, le
traitement continue pour le groupe de règles suivant. Pour cette raison, les règles doivent être créées dans
l’ordre, de la plus explicite à la moins explicite.
Les jointures dans cette image sont traitées de haut en bas. Le pipeline de synchronisation détecte d’abord si
une correspondance sur employeeID existe. Si ce n’est pas le cas, la deuxième règle détecte si le nom du compte
peut être utilisé pour joindre les objets. Si aucune correspondance n’est trouvée, la troisième et dernière règle
utilise le nom d’utilisateur pour trouver une correspondance moins stricte.
Si toutes les règles de jointure ont été évaluées et qu’il n’existe aucune correspondance exacte, le type de lien
indiqué dans la page de description est utilisé. Si cette option a la valeur Provision , un nouvel objet est créé
dans la cible.
Un objet doit avoir une seule règle de synchronisation avec des règles de jointure dans la portée. S’il existe
plusieurs règles de synchronisation dans lesquelles la jointure est définie, une erreur se produit. La précédence
n’est pas utilisée pour résoudre les conflits de jointure. Un objet doit avoir une règle de jointure dans la portée
des attributs pour que la circulation se fasse dans le même sens en entrée et en sortie. Si vous avez besoin de
faire circuler les attributs en entrée et en sortie sur le même objet, vous devez disposer à la fois d’une règle de
synchronisation de trafic entrant et de trafic sortant avec une jointure.
La jointure en sortie a un comportement spécial lorsqu’elle tente d’approvisionner un objet sur un espace de
connecteur cible. L’attribut de nom unique est utilisé pour essayer en premier lieu une jointure inverse. Si
l’espace de connecteur cible contient déjà un objet portant le même nom unique, les objets sont joints.
Le module Join est évalué une seule fois lorsqu’une nouvelle règle de synchronisation arrive dans l’étendue.
Lorsqu’un objet est joint, il n’est pas séparé, même si le critère de jointure n’est plus rempli. Si vous souhaitez
séparer un objet, la règle de synchronisation qui joint les objets doit être hors de portée.
Suppression du métaverse
Un objet de métaverse demeure tant qu’une règle de synchronisation reste dans la portée, avec le type de lien
défini sur Provision ou StickyJoin . Le type StickyJoin est utilisé lorsqu’un connecteur n’est pas autorisé à
approvisionner un nouvel objet dans le métaverse, mais lorsqu’il est joint, il doit être supprimé de la source
avant la suppression de l’objet du métaverse.
Lorsqu’un objet de métaverse est supprimé, tous les objets associés à une règle de synchronisation de trafic
sortant marquée Provision sont marqués pour suppression.
Transformations
Les transformations sont utilisées pour définir le flux d’attributs de la source vers la cible. Les flux peuvent être
des types suivants : Direct, Constant ou Expression. Un flux direct envoie la valeur de l’attribut telle quelle, sans
transformation supplémentaire. Un flux constant définit la valeur spécifiée. Une expression utilise le langage
d’expression d’approvisionnement déclaratif pour exprimer la manière dont la transformation doit avoir lieu.
Vous trouverez des informations sur le langage d’expression dans la rubrique Comprendre le langage
d’expression d’approvisionnement déclaratif .
La case Appliquer une fois indique si l’attribut doit être défini uniquement lors de la création initiale de l’objet.
Par exemple, cette configuration peut être utilisée pour définir un mot de passe initial pour un nouvel objet
utilisateur.
Fusion de valeurs d’attribut
Dans les flux d’attributs, il existe un paramètre permettant de déterminer si les attributs à valeurs multiples
doivent être fusionnés à partir de plusieurs connecteurs différents. La valeur par défaut est Mettre à jour , ce
qui indique que la règle de synchronisation avec la priorité la plus élevée prévaut.
Il existe également une option Fusionner et MergeCaseInsensitive (Fusion non sensible à la casse). Ces
options permettent de fusionner des valeurs issues de différentes sources. Par exemple, elles peuvent être
utilisées pour fusionner le membre ou l’attribut proxyAddresses de plusieurs forêts différentes. Lorsque vous
utilisez cette option, toutes les règles de synchronisation dans l’étendue d’un objet doivent utiliser le même type
de fusion. Vous ne pouvez pas définir Mettre à jour à partir d’un connecteur et Fusionner à partir d’un autre
connecteur. Si vous essayez, vous recevrez une erreur.
La différence entre Fusionner et MergeCaseInsensitive (Fusion non sensible à la casse) est le traitement des
valeurs d’attribut en double. Le moteur de synchronisation s’assure qu’aucun doublon n’est inséré dans l’attribut
cible. Avec MergeCaseInsensitive (Fusion non sensible à la casse), les doublons présentant uniquement une
différence de casse ne sont pas inclus. Par exemple, vous ne verrez pas à la fois « SMTP:bob@contoso.com » et «
smtp:bob@contoso.com » dans l’attribut cible. Fusionner examine uniquement les valeurs exactes et plusieurs
valeurs présentant uniquement une différence de casse peuvent être présentes.
L’option Remplacer est identique à Mettre à jour , mais elle n’est pas utilisée.
Contrôler le processus de flux d’attributs
Lorsque plusieurs règles de synchronisation entrantes sont configurées pour contribuer au même attribut du
métaverse, un principe de priorité est utilisé pour déterminer celle qui sera appliquée. La règle de
synchronisation ayant la priorité la plus élevée (la valeur numérique la plus basse) transmettra sa valeur. Le
même principe s’applique pour les règles sortantes. La règle de synchronisation ayant la priorité la plus élevée
l’emporte et transmet sa valeur au répertoire connecté.
Dans certains cas, plutôt que de transmettre une valeur, la règle de synchronisation doit déterminer le
comportement des autres règles. Certains littéraux particuliers sont utilisés dans ce cas.
Pour les règles de synchronisation entrantes, le littéral NULL peut être utilisé pour indiquer que le flux n’a
aucune valeur à transmettre. Une autre règle avec une priorité inférieure peut transmettre sa valeur. Si aucune
règle n’a contribué de valeur, l’attribut du métaverse est supprimé. Pour une règle sortante, si NULL est la valeur
finale obtenue une fois toutes les règles de synchronisation traitées, la valeur est alors supprimée du répertoire
connecté.
Le littéral AuthoritativeNull est similaire à NULL , à ceci près qu’aucune des règles de priorité inférieure ne
peut transmettre une valeur.
Un flux d’attributs peut également utiliser le littéral IgnoreThisFlow . Celui-ci est similaire à la valeur NULL en
ce sens qu’il indique qu’il n’a rien à transmettre. En revanche, il ne supprime aucune valeur déjà existante dans la
cible. Il agit comme si le flux d’attributs n’avait jamais existé.
Voici un exemple :
Dans Out to AD - User Exchange hybrid, vous trouverez le flux suivant :
IIF([cloudSOAExchMailbox] = True,[cloudMSExchSafeSendersHash],IgnoreThisFlow)
Cette expression doit être lue de la manière suivante : si la boîte aux lettres de l’utilisateur se trouve dans Azure
AD, transmettre l’attribut d’Azure AD à Active Directory. Si ce n’est pas le cas, ne rien transmettre en retour à
Active Directory. Dans ce cas, la valeur existante dans AD est conservée.
ImportedValue
La fonction ImportedValue est différente de toutes les autres fonctions, car le nom d’attribut doit être placé entre
guillemets doubles plutôt qu’entre crochets :
ImportedValue("proxyAddresses") .
Généralement, lors de la synchronisation, un attribut utilise la valeur attendue, même s’il n’a pas encore été
exporté ou si une erreur a été reçue pendant l’exportation (« top of the tower »). Une synchronisation entrante
part du principe qu’un attribut qui n’a pas encore atteint un annuaire connecté finira par l’atteindre. Dans
certains cas, il est important de synchroniser uniquement une valeur qui a été confirmée par l’annuaire connecté
(« hologram and delta import tower »).
Vous trouverez un exemple de cette fonction dans la règle de synchronisation par défaut In from AD – User
Common from Exchange. Dans Exchange hybride, la valeur ajoutée par Exchange Online doit uniquement être
synchronisée après avoir confirmé que la valeur a bien été exportée :
proxyAddresses <- RemoveDuplicates(Trim(ImportedValue("proxyAddresses")))
Priorité
Lorsque plusieurs règles de synchronisation essaient de transmettre la même valeur d’attribut à la cible, la
valeur de précédence est utilisée pour déterminer la valeur prioritaire. La règle ayant la priorité la plus élevée (la
valeur numérique la plus basse) transmettra l’attribut.
Cette commande permet de définir plus précisément les flux d’attributs pour un petit sous-ensemble d’objets.
Par exemple, les règles out-of-box permettent de s’assurer que les attributs d’un compte activé (User
AccountEnabled ) ont la priorité sur d’autres comptes.
La précédence peut être définie entre les connecteurs. Cela permet aux connecteurs avec de meilleures données
de transmettre leurs valeurs en premier.
Plusieurs objets du même espace de connecteur
Si vous avez plusieurs objets dans le même espace de connecteur joints au même objet de métaverse, vous
devez ajuster la précédence. Si plusieurs objets sont dans la portée de la même règle de synchronisation, le
moteur de synchronisation n’est pas en mesure de déterminer la précédence. Il demeure une incertitude quant à
l’objet source qui doit transmettre la valeur au métaverse. Cette configuration est signalée comme ambiguë
même si les attributs de la source ont la même valeur.
Pour ce scénario, vous devez modifier la portée des règles de synchronisation, de façon à ce que les objets
sources aient des règles de synchronisation différentes dans la portée. Cela vous permet de définir une
précédence différente.
Étapes suivantes
En savoir plus sur le langage d’expression dans Comprendre les expressions d’approvisionnement déclaratif.
Apprendre comment l’approvisionnement déclaratif est utilisé out-of-box dans Présentation de la
configuration par défaut.
Apprendre à effectuer une modification pratique à l’aide de l’approvisionnement déclaratif dans Comment
modifier la configuration par défaut.
Continuer à lire le fonctionnement des utilisateurs et des contacts dans Présentation des utilisateurs et des
Contacts.
Rubriques de présentation
Synchronisation Azure AD Connect : Comprendre et personnaliser la synchronisation
Rubriques de référence
Azure AD Connect Sync : Référence aux fonctions
Azure AD Connect Sync : présentation des
expressions d’approvisionnement déclaratif
Azure AD Connect sync s’appuie sur l’approvisionnement déclaratif introduit pour la première fois dans
Forefront Identity Manager 2010. Il vous permet d’implémenter toute votre logique métier d’intégration des
identités sans avoir à écrire de code compilé.
Le langage d’expression utilisé dans les flux d’attributs constitue une partie essentielle de l’approvisionnement
déclaratif. Le langage utilisé est un sous-ensemble de Microsoft® Visual Basic® pour Applications (VBA). Ce
langage est utilisé dans Microsoft Office et les utilisateurs qui ont une certaine expérience de VBScript le
reconnaîtront également. Le langage d’expression de l’approvisionnement déclaratif utilise uniquement des
fonctions. Il ne s’agit pas d’un langage structuré. Il ne contient ni méthodes ni instructions. Les fonctions sont
imbriquées pour exprimer le déroulement du programme.
Pour plus d’informations, consultez Bienvenue dans la référence linguistique Visual Basic pour Applications pour
Office 2013.
Les attributs sont fortement typés. Une fonction accepte uniquement les attributs de type correct. Elle respecte
également la casse. Les noms des fonctions et les noms des attributs doivent avoir une casse appropriée, sinon
une erreur est levée.
Définitions linguistiques et identificateurs

Les fonctions ont un nom suivi d’arguments entre parenthèses : NomFonction (argument 1, argument N).
Les attributs sont identifiés par des crochets : [NomAttribut]
Les paramètres sont identifiés par des signes de pourcentage : %NomParamètre%
Les constantes de chaîne sont placées entre guillemets : par exemple, "Contoso" (Remarque : vous devez
utiliser des guillemets droits "" et non pas des guillemets courbes “”)
Les valeurs numériques sont exprimées sans guillemets et les valeurs attendues sont décimales. Les valeurs
hexadécimales sont précédées de &H. Par exemple, 98052, &HFF
Les valeurs booléennes sont exprimées avec des constantes : True, False.
Les constantes intégrées et les littéraux sont exprimés uniquement par leur nom : NULL, CRLF,
IgnoreThisFlow
Fonctions
L’approvisionnement déclaratif utilise de nombreuses fonctions pour permettre de transformer les valeurs
d’attribut. Elles peuvent être imbriquées. Le résultat d’une fonction est alors transmis à une autre fonction.
Function1(Function2(Function3()))
Vous trouverez la liste complète des fonctions dans la référence de fonction.

Paramètres
Un paramètre est défini par un connecteur ou par un administrateur à l’aide de PowerShell. Les paramètres
contiennent généralement des valeurs qui diffèrent d’un système à un autre, par exemple le nom du domaine
où se trouve l’utilisateur. Vous pouvez les utiliser dans des flux d’attributs.
Le connecteur Active Directory fournissait les paramètres suivants pour les règles de synchronisation entrantes :
N O M DU PA RA M ÈT RE C O M M EN TA IRE
Domain.Netbios Format NetBIOS du domaine en cours d'importation, par

exemple, FABRIKAMSALES
Domain.FQDN Format FQDN du domaine en cours d’importation, par

exemple, sales.fabrikam.com
Domain.LDAP Format LDAP du domaine en cours d’importation, par

exemple, DC=sales,DC=fabrikam,DC=com
Forest.Netbios Format NetBIOS du nom de forêt en cours d’importation,

par exemple, FABRIKAMCORP
Forest.FQDN Format FQDN du nom de forêt en cours d’importation, par

exemple, fabrikam.com
Forest.LDAP Format LDAP du nom de forêt en cours d’importation, par

exemple, DC=fabrikam,DC=com
Le système fournit le paramètre suivant, qui est utilisé pour obtenir l'identificateur du connecteur en cours
d'exécution :
Connector.ID
Voici un exemple qui remplira le domaine d’attribut du métaverse avec le nom netbios du domaine où se trouve
l’utilisateur :
domain <- %Domain.Netbios%
Opérateurs
Vous pouvez utiliser les opérateurs suivants :
Opérateurs de comparaison : <, <=, <>, =, >, >=
Mathématiques : +, -, *, -
Chaîne : & (concaténation)
Logiques : && (et), || (ou)
Ordre d’évaluation : ( )
Les opérateurs sont évalués de la gauche vers la droite et ont la même priorité d'évaluation. Par exemple, le *
(signe multiplicateur) n’est pas évalué avant - (soustraction). 2*(5+3) n’est pas la même chose que 2*5+3. Les
parenthèses ( ) sont utilisées pour modifier l’ordre d’évaluation lorsqu’un ordre d’évaluation de la gauche vers la
droite n’est pas approprié.
Attributs à valeurs multiples

Les fonctions peuvent fonctionner sur des attributs à valeur unique et à valeurs multiples. Pour les attributs à
valeurs multiples, la fonction fonctionne sur toutes les valeurs et applique la même fonction à chaque valeur.
Par exemple :
Trim([proxyAddresses]) supprime les espaces de gauche à droite dans chaque valeur de l’attribut proxyAddress.
Word([proxyAddresses],1,"@") & "@contoso.com" Pour chaque valeur comportant un signe @-sign, remplacez le
domaine par @contoso.com.
IIF(InStr([proxyAddresses],"SIP:")=1,NULL,[proxyAddresses]) Recherchez l’adresse SIP et supprimez-la des
valeurs.
Étapes suivantes
En savoir plus sur le modèle de configuration dans Comprendre l’approvisionnement déclaratif.
Apprendre comment l’approvisionnement déclaratif est utilisé out-of-box dans Présentation de la
configuration par défaut.
Rubriques de référence
Azure AD Connect Sync : Référence aux fonctions
de la configuration par défaut
Cet article présente les règles de configuration out-of-box. Il décrit les règles et l’impact que celles-ci ont sur la
configuration. Il vous guide également tout au long de la configuration par défaut de la synchronisation Azure
AD Connect. L’objectif est que le lecteur comprenne comment fonctionne le modèle de configuration, nommé
approvisionnement déclaratif, dans un exemple réel. Cet article suppose que vous avez déjà installé et configuré
la synchronisation Azure AD Connect à l’aide de l’Assistant d’installation.
Pour comprendre les détails du modèle de configuration, lisez Comprendre l’approvisionnement déclaratif.
Règles out-of-box du local vers Azure AD

Les expressions suivantes se trouvent dans la configuration out-of-box.
Règles out-of-box d’utilisateur
Ces règles s’appliquent également au type d’objet iNetOrgPerson.
Un objet utilisateur doit remplir les conditions suivantes pour être synchronisé :
Il doit disposer d’un sourceAnchor.
Une fois que l’objet a été créé dans Azure AD, le sourceAnchor ne peut pas être modifié. Si la valeur est
modifiée en local, l’objet arrête la synchronisation jusqu’à ce que l’attribut sourceAnchor récupère sa valeur
précédente.
L’attribut accountEnabled (userAccountControl) dont il dispose doit être renseigné. Avec un Active Directory
local, cet attribut est toujours présent et renseigné.
Les objets utilisateur suivants ne sont pas synchronisés avec Azure AD :
IsPresent([isCriticalSystemObject]) . Vérifiez que la plupart des objets out-of-box dans Active Directory, tels
que le compte administrateur intégré, ne sont pas synchronisés.
IsPresent([sAMAccountName]) = False . Assurez-vous que les objets utilisateur sans l'attribut
sAMAccountName ne sont pas synchronisés. Ce cas se produit pratiquement uniquement dans un domaine
mis à niveau à partir d’un système NT4.
Left([sAMAccountName], 4) = "AAD_" , Left([sAMAccountName], 5) = "MSOL_" . Ne synchronisez pas le compte
de service utilisé par la synchronisation d’Azure AD Connect et de ses versions précédentes.
Ne synchronisez pas les comptes Exchange qui pourraient ne pas fonctionner dans Exchange Online.
[sAMAccountName] = "SUPPORT_388945a0"
Left([mailNickname], 14) = "SystemMailbox{"
(Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0))
(Left([sAMAccountName], 4) = "CAS_" && (InStr([sAMAccountName], "}")> 0))
Ne synchronisez pas les objets qui pourraient ne pas fonctionner dans Exchange Online.
CBool(IIF(IsPresent([msExchRecipientTypeDetails]),BitAnd([msExchRecipientTypeDetails],&H21C07000) >
0,NULL))
Ce masque de bits (&H21C07000) pourrait exclure les objets suivants :
Dossier public à extension messagerie (en préversion à partir de la version 1.1.524.0)
Boîte aux lettres de surveillance du système
Boîte aux lettres de base de données de boîtes aux lettres (Boîte aux lettres système)
Groupe de sécurité universel (ne s'applique pas à un utilisateur, mais est présent pour des raisons
d'héritage)
Groupe non universel (ne s'applique pas à un utilisateur, mais est présent pour des raisons d'héritage)
Plan de boîte aux lettres
Boîte aux lettres de découverte
CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0) . Ne synchronisez aucun objet victime de réplication.
Les règles d’attribut suivantes s’appliquent :

sourceAnchor <- IIF([msExchRecipientTypeDetails]=2,NULL,..) . L’attribut sourceAnchor n’est pas partagé à
partir d’une boîte aux lettres liée. On part du principe que si une boîte aux lettres liée a été trouvée, le compte
actuel sera associé ultérieurement.
Les attributs liés à Exchange sont uniquement synchronisés si l'attribut mailNickName a une valeur.
Lorsqu’il existe plusieurs forêts, les attributs sont consommés dans l’ordre suivant :
1. Les attributs liés à l’authentification (par exemple, userPrincipalName) sont obtenus à partir de la forêt
avec un compte activé.
2. Les attributs qui se trouvent dans la LAG (liste d’adresses globale) Exchange sont synchronisés à partir
de la forêt avec la boîte aux lettres Exchange.
3. Si aucune boîte aux lettres ne peut être trouvée, ces attributs peuvent provenir de n'importe quelle
forêt.
4. Les attributs liés à Exchange (attributs techniques non visibles dans la liste d’adresses globale) sont
fournis à partir de la forêt où mailNickname ISNOTNULL .
5. S’il existe plusieurs forêts qui répondent à une de ces règles, alors l’ordre de création (date/heure) des
connecteurs (forêts) est utilisé pour déterminer quelle forêt fournit les attributs. La première forêt
connectée sera la première forêt à être synchronisée.
Règles out-of-box de contact
Un objet contact doit remplir les conditions suivantes pour être synchronisé :
Le contact doit être à extension messagerie. Il est vérifié par les règles suivantes :
IsPresent([proxyAddresses]) = True) . L'attribut proxyAddresses doit être renseigné.
L'attribut proxyAddresses ou l'attribut de messagerie peuvent comporter une adresse de messagerie
principale. La présence d’un @ est utilisée pour vérifier que le contenu est une adresse de messagerie.
L’une de ces deux règles doit prendre la valeur True.
(Contains([proxyAddresses], "SMTP:") > 0) && (InStr(Item([proxyAddresses],
Contains([proxyAddresses], "SMTP:")), "@") > 0))
. Existe-t-il une entrée avec « SMTP: », et si tel est le cas, est-il possible de trouver un @ dans la
chaîne ?
(IsPresent([mail]) = True && (InStr([mail], "@") > 0) . L’attribut de messagerie est-il
renseigné, et si tel est le cas, est-il possible de trouver un @ dans la chaîne ?
Les objets contact suivants ne sont pas synchronisés avec Azure AD :
IsPresent([isCriticalSystemObject]) . Vérifiez qu’aucun objet contact marqué comme critique n’est
synchronisé. Cet objet ne devrait pas avoir de configuration par défaut.
((InStr([displayName], "(MSOL)") > 0) && (CBool([msExchHideFromAddressLists]))) .
(Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0)) . Ces objets ne fonctionneraient pas
avec Exchange Online.
Règles out-of-box de groupe

Un objet groupe doit remplir les conditions suivantes pour être synchronisé :
Il doit compter moins de 50 000 membres. Ce chiffre correspond au nombre de membres du groupe local.
S’il compte plus de membres avant sa toute première synchronisation, le groupe n’est pas
synchronisé.
Si le nombre de membres augmente à partir du moment où il a été créé, alors sa synchronisation est
interrompue lorsqu’il atteint 50 000 membres, jusqu’à ce que le nombre redevienne inférieur à 50
000 membres.
Remarque : La limite de 50 000 membres s’applique également avec Azure AD. Vous ne pouvez pas
synchroniser les groupes d’un nombre de membres supérieur même si vous modifiez ou supprimez
cette règle.
Si le groupe est un groupe de distribution , il doit alors également être activé pour la messagerie.
Consultez la page Règles out-of-box de contact pour l’application de cette règle.
Les objets groupe suivants ne sont pas synchronisés avec Azure AD :
IsPresent([isCriticalSystemObject]) . Vérifiez que la plupart des objets out-of-box dans Active Directory, tels
que le groupe administrateur intégré, ne sont pas synchronisés.
[sAMAccountName] = "MSOL_AD_Sync_RichCoexistence" . Groupe hérité utilisé par DirSync.
BitAnd([msExchRecipientTypeDetails],&H40000000) . Groupe de rôles.
Règles out-of-box ForeignSecurityPrincipal

Les FSP sont joints à « tout » (*) objet dans le métaverse. En réalité, cela se produit uniquement pour les
utilisateurs et les groupes de sécurité. Cette configuration garantit que les appartenances inter-forêts sont
correctement résolues et représentées dans Azure AD.
Règles out-of-box d’ordinateur
Un objet ordinateur doit remplir les conditions suivantes pour être synchronisé :
userCertificate ISNOTNULL . Seuls les objets ordinateur Windows 10 renseignent cet attribut. Tous les objets
ordinateur avec une valeur de cet attribut sont synchronisés.
Présentation du scénario de règles out-of-box

Dans cet exemple, nous utilisons un déploiement comportant une forêt de comptes (A), une forêt de ressources
(R) et un répertoire Azure AD.
Dans cette configuration, il est supposé exister un compte activé dans la forêt de comptes et un compte
désactivé dans la forêt de ressources avec une boîte aux lettres liée.
Nos objectifs avec la configuration par défaut sont les suivants :
Les attributs liés à la connexion sont synchronisés à partir de la forêt avec le compte activé.
Les attributs qui se trouvent dans la LAG (liste d’adresses globale) sont synchronisés à partir de la forêt avec
la boîte aux lettres. Si aucune boîte aux lettres n’est trouvée, toute autre forêt est utilisée.
Si une boîte aux lettres liée est trouvée, le compte activé lié doit être trouvé pour l’objet à exporter vers
Azure AD.
Éditeur de règles de synchronisation
La configuration peut être affichée et modifiée avec l’outil Éditeur de règles de synchronisation (SRE), dont le
raccourci se trouve dans le menu Démarrer.
Le SRE est un outil du kit de ressources installé avec la synchronisation Azure AD Connect. Pour être en mesure
de le démarrer, vous devez être membre du groupe ADSyncAdmins. Lorsqu’il démarre, vous voyez quelque
chose comme suit :
Dans ce volet, vous voyez toutes les règles de synchronisation créées pour votre configuration. Chaque ligne du
tableau correspond à une règle de synchronisation. À gauche, sous Types de règles, deux types sont présentés :
Entrante et Sortante. Les termes entrante et sortante sont à prendre du point de vue du métaverse. Vous allez
principalement vous concentrer sur les règles de trafic entrant dans cette vue d’ensemble. La liste actuelle des
règles de synchronisation dépend du schéma détecté dans Active Directory. Dans l’image ci-dessus, la forêt de
comptes (fabrikamonline.com) ne dispose d’aucun service (par exemple, Exchange ou Lync), et aucune règle de
synchronisation n’a été créée pour ces services. Toutefois, dans la forêt de ressources (res.fabrikamonline.com),
vous trouvez des règles de synchronisation pour ces services. Le contenu des règles diffère selon la version
détectée. Par exemple, dans un déploiement avec Exchange 2013, plus de flux d’attributs sont configurés que
dans Exchange 2010/2007.
Règle de synchronisation
Une règle de synchronisation est un objet de configuration avec un jeu d’attributs qui circule quand une
condition est remplie. Elle sert aussi à décrire la relation entre un objet dans un espace de connecteur et un objet
dans le métaverse, relation appelée jointure ou correspondance . Les règles de synchronisation ont une valeur
de précédence qui indique leurs relations les unes par rapport aux autres. Une règle de synchronisation avec
une valeur plus basse possède une précédence plus élevée et, dans un conflit de flux d’attributs, c’est la
précédence la plus élevée qui l’emporte.
En guise d’exemple, examinez la règle de synchronisation Entrant depuis AD – Utilisateur AccountEnabled .
Marquez cette ligne dans l’outil SRE et sélectionnez Modifier .
Dans la mesure où il s’agit d’une règle out-of-box, vous recevez un avertissement à l’ouverture de la règle. Vous
ne devez pas apporter de modifications aux règles out-of-boxvous êtes donc invité à indiquer vos intentions.
Dans ce cas, vous souhaitez uniquement afficher la règle. Sélectionnez Non .
Une règle de synchronisation comporte quatre sections de configuration : Description, Filtre d’étendue, Règles
de jointure et Transformations.
Description
La première section fournit des informations de base telles que le nom et la description.
Vous y trouverez également des informations concernant le système connecté associé à cette règle, le type
d’objet dans le système connecté auquel il s’applique et le type d’objet de métaverse. Le type d’objet du
métaverse est toujours « person », que le type d’objet source soit un utilisateur, iNetOrgPerson ou un contact.
Comme il ne doit jamais changer, il est créé en tant que type générique. Le type de lien peut être Join, StickyJoin
ou Provision. Ce paramètre fonctionne avec la section Règles de jointure et il est traité plus loin dans ce
document.
Vous pouvez également voir que cette règle de synchronisation est utilisée pour la synchronisation de mot de
passe. Si un utilisateur est dans la portée pour cette règle de synchronisation, le mot de passe est synchronisé
du local vers le cloud (en supposant que vous avez activé la fonctionnalité de synchronisation de mot de passe).
Filtre d’étendue
La section Filtre d’étendue sert à configurer à quel moment une règle de synchronisation doit s’appliquer.
Comme le nom de la règle de synchronisation que vous examinez indique qu’elle ne doit être appliquée qu’aux
utilisateurs activés, l’étendue est configurée de sorte que l’attribut AD userAccountControl ne doive pas avoir
le bit 2 défini. Lorsque le moteur de synchronisation détecte un utilisateur dans Active Directory, il applique la
synchronisation lorsque userAccountControl est défini sur la valeur décimale 512 (utilisateur normal activé). Il
n’applique pas la règle lorsque l’utilisateur a userAccountControl défini sur 514 (utilisateur normal désactivé).
Le filtre d’étendue possède des groupes et des clauses qui peuvent être imbriqués. Toutes les clauses à
l’intérieur d’un groupe doivent être satisfaites pour qu’une règle de synchronisation s’applique. Quand plusieurs
groupes sont définis, au moins l’un d’entre eux doit être satisfait pour que la règle s’applique. C’est-à-dire qu’une
opération OR logique est évaluée entre les groupes et qu’une opération AND logique est évaluée à l’intérieur
d’un groupe. On trouve un exemple de cette configuration dans la règle de synchronisation sortante Sor tant
vers AAD – Group Join , indiquée ci-dessous. Il existe plusieurs groupes de filtres de synchronisation, par
exemple, un pour les groupes de sécurité ( securityEnabled EQUAL True ) et un autre pour les groupes de
distribution ( securityEnabled EQUAL False ).
Cette règle sert à définir les groupes qui doivent être approvisionnés dans Azure AD. Les groupes de distribution
doivent être activés pour la messagerie électronique pour pouvoir être synchronisés avec Azure AD, mais pour
les groupes de sécurité aucune adresse de messagerie n’est nécessaire.
Règles de jointure
La troisième section sert à configurer la relation entre les objets dans l’espace de connecteur et les objets dans le
métaverse. La règle que vous avez examinée plus haut n’ayant aucune configuration pour Join Rules, vous allez
plutôt examiner Entrant depuis AD – User Join .
Le contenu de la règle de jointure dépend de l’option de correspondance sélectionnée dans l’Assistant

Installation. Pour une règle entrante, l’évaluation commence avec un objet dans l’espace de connecteur source et
chaque groupe dans les règles de jointure est évalué de manière séquentielle. Si un objet source évalué
correspond exactement à un objet dans le métaverse selon l’une des règles de jointure, les deux objets sont
joints. Si toutes les règles ont été évaluées et qu’il n’existe aucune correspondance, le type de lien indiqué dans
la page de description est utilisé. Si cette configuration est définie sur Provisionner , un nouvel objet est créé
dans la cible, le métaverse, si au moins un attribut dans les critères de jonction est présent (a une valeur).
L’approvisionnement d’un nouvel objet dans le métaverse porte également le nom de projection .
Les règles de jointure ne sont évaluées qu’une seule fois. Quand un objet d’espace de connecteur et un objet de
métaverse sont joints, ils le restent tant que l’étendue de la règle de synchronisation est encore satisfaite.
Lors de l’évaluation de plusieurs règles de synchronisation, une seule d’entre elles avec des règles de jointure
définies doit être dans l’étendue. Si plusieurs règles de synchronisation avec des règles de jointure sont
détectées pour un objet, une erreur est levée. Pour cette raison, la meilleure pratique consiste à n’avoir qu’une
seule règle de synchronisation avec jointure définie quand plusieurs règles de synchronisation sont dans
l’étendue pour un objet. Dans la configuration par défaut de la synchronisation d’Azure AD Connect, vous
pouvez identifier facilement ces règles, car leur nom se termine par le mot Join . Une règle de synchronisation
sans aucune règle de jointure définie applique les flux d’attributs lorsqu’une autre règle de synchronisation a
joint les objets ensemble ou a approvisionné un nouvel objet dans la cible.
Si vous examinez l’illustration ci-dessus, vous pouvez voir que la règle essaie de joindre objectSID avec
msExchMasterAccountSid (Exchange) et msRTCSIP-OriginatorSid (Lync), ce qui est le résultat que nous
attendons dans une topologie de forêt de comptes/ressources. Vous trouverez la même règle sur toutes les
forêts. L’hypothèse est que chaque forêt peut être une forêt de comptes ou de ressources. Cette configuration
fonctionne également si vous disposez de comptes qui résident dans une forêt unique et n’ont pas à être joints.
Transformations
La section Transformation définit tous les flux d’attributs qui s’appliquent à l’objet cible quand les objets sont
joints et quand le filtre d’étendue est satisfait. Si vous revenez à la règle de synchronisation Entrant depuis AD
– Utilisateur AccountEnabled , vous trouvez les transformations suivantes :
Pour mettre cette configuration en contexte, dans un déploiement de forêt Account-Resource, il devrait y avoir
un compte activé dans la forêt de comptes et un compte désactivé dans la forêt de ressources avec des
paramètres Exchange et Lync. La règle de synchronisation que vous examinez contient les attributs nécessaires
pour la connexion et ceux-ci devraient circuler à partir de la forêt dans laquelle se trouve un compte activé. Tous
ces flux d’attributs sont regroupés dans une règle de synchronisation.
Une transformation peut avoir différents types : Constant, Direct et Expression.
Un flux constant transmet toujours une valeur codée en dur. Dans le cas ci-dessus, il définit toujours la valeur
True dans l’attribut du métaverse nommé accountEnabled .
Un flux direct transmet toujours la valeur de l’attribut source telle quelle vers l’attribut cible.
Le troisième type de flux, Expression, permet d’effectuer des configurations avancées.
Le langage d’expression étant VBA (Visual Basic pour Applications), les utilisateurs ayant une expérience de
Microsoft Office ou VBScript reconnaîtront le format. Les attributs sont placés entre crochets : [nom_attribut].
Les noms des attributs et des fonctions respectent la casse, mais l’Éditeur de règles de synchronisation évalue
les expressions et affiche un avertissement si elles ne sont pas valides. Toutes les expressions sont placées sur
une seule ligne avec les fonctions imbriquées. Pour illustrer toute la puissance du langage de configuration, voici
le flux pour pwdLastSet, mais avec des commentaires supplémentaires insérés :
// If-then-else
IIF(
// (The evaluation for IIF) Is the attribute pwdLastSet present in AD?
IsPresent([pwdLastSet]),
// (The True part of IIF) If it is, then from right to left, convert the AD time format to a .NET datetime,
change it to the time format used by Azure AD, and finally convert it to a string.
CStr(FormatDateTime(DateFromNum([pwdLastSet]),"yyyyMMddHHmmss.0Z")),
// (The False part of IIF) Nothing to contribute
NULL
)
Pour plus d’informations sur le langage d’expression pour les flux d’attributs, consultez Présentation des
expressions de l’approvisionnement déclaratif .
Priorité
Vous avez maintenant vu certaines règles de synchronisation individuelles, mais les règles fonctionnent de
concert dans la configuration. Dans certains cas, une valeur d’attribut est partagée à partir de plusieurs règles
de synchronisation vers le même attribut cible. Dans ce cas, la précédence d’attribut est utilisée pour déterminer
quel attribut l’emporte. Par exemple, examinez l’attribut sourceAnchor. Cet attribut est important pour pouvoir se
connecter à Azure AD. Vous pouvez trouver un flux d’attributs pour cet attribut dans deux règles de
synchronisation différentes : Entrant depuis AD – Utilisateur AccountEnabled et Entrant depuis AD –
Utilisateur Common . En raison de la précédence de la règle de synchronisation, l’attribut sourceAnchor est
partagé à partir de la forêt avec un compte activé en premier lieu lorsqu’il existe plusieurs objets joints à l’objet
métaverse. S’il n’y a aucun compte activé, le moteur de synchronisation utilise la règle de synchronisation
fourre-tout Entrant depuis AD – Utilisateur Common . Cette configuration garantit que même pour les
comptes qui sont désactivés, il existe toujours un sourceAnchor.
La précédence des règles de synchronisation est définie dans les groupes par l’Assistant d’installation. Toutes les
règles d’un groupe ont le même nom, mais elles sont connectées à différents répertoires connectés. L’Assistant
d’installation donne à la règle Entrant depuis AD – User Join la précédence la plus élevée et effectue une
itération sur tous les répertoires AD connectés. Il continue ensuite avec les groupes de règles suivants dans un
ordre prédéfini. À l’intérieur d’un groupe, les règles sont ajoutées dans l’ordre dans lequel les connecteurs ont
été ajoutés à l’Assistant. Si un autre connecteur est ajouté via l’Assistant, les règles de synchronisation sont
réordonnées et les règles du nouveau connecteur sont insérées en dernier dans chaque groupe.
Exemple complet
Nous en savons maintenant assez sur les règles de synchronisation pour comprendre le fonctionnement de la
configuration avec les différentes règles de synchronisation. Si vous regardez un utilisateur et les attributs qui
sont partagés avec le métaverse, les règles sont appliquées dans l’ordre suivant :
NOM C O M M EN TA IRE
Entrant depuis AD – User Join Règle pour joindre les objets de l’espace de connecteur avec
métaverse.
Entrant depuis AD – Utilisateur AccountEnabled Attributs requis pour la connexion à Azure AD et

Microsoft 365. Nous voulons ces attributs à partir du
compte activé.
Entrant depuis AD – Utilisateur Common à partir d’Exchange Attributs trouvés dans la liste d’adresses globale. Nous
supposons que la qualité des données est meilleure dans la
forêt où nous avons trouvé la boîte aux lettres de
l’utilisateur.
Entrant depuis AD – Utilisateur Common Attributs trouvés dans la liste d’adresses globale. Dans le cas
où nous ne trouvons pas de boîte aux lettres, tout autre
objet joint peut contribuer à la valeur d’attribut.
Entrant depuis AD – Utilisateur Exchange Existe seulement si Exchange a été détecté. Transfère tous les
attributs Exchange d’infrastructure.
NOM C O M M EN TA IRE
Entrant depuis AD – Utilisateur Lync Existe seulement si Lync a été détecté. Transfère tous les
attributs Lync d’infrastructure.
Étapes suivantes
En savoir plus sur le modèle de configuration dans Comprendre l’approvisionnement déclaratif.
En savoir plus sur le langage d’expression dans Comprendre les expressions d’approvisionnement déclaratif.
Poursuivre la lecture sur le fonctionnement de la configuration out-of-box dans Présentation des utilisateurs
et des contacts
des utilisateurs, des groupes et des contacts
Il existe plusieurs raisons pour lesquelles vous pouvez avoir plusieurs forêts Active Directory et il existe
plusieurs topologies de déploiement différentes. Parmi les modèles courants, citons les déploiements de
ressources de comptes et les forêts avec liste d’adresses globale synchronisées après fusion et acquisition. Mais
même s’il existe des modèles pures, les modèles hybrides sont également courants. La configuration par défaut
du service de synchronisation Azure AD Connect ne suppose pas l’existence d’un modèle particulier, mais des
comportements différents peuvent être observés en fonction de la façon dont la correspondance utilisateur a
été sélectionnée dans le guide d’installation.
Dans cette rubrique, nous allons voir comment se comporte la configuration par défaut dans certaines
topologies. Nous allons examiner la configuration et voir comment utiliser l’éditeur de règles de synchronisation
pour vérifier la configuration.
Il existe quelques règles générales que la configuration considère comme étant respectées :
Quel que soit l’ordre dans lequel nous importons des données depuis les annuaires Active Directory sources,
le résultat final doit toujours être le même.
Un compte actif fournira toujours des informations de connexion, y compris userPrincipalName et
sourceAnchor .
Un compte désactivé fournira userPrincipalName et sourceAnchor, sauf s’il s’agit d’une boîte aux lettres liée
si aucun compte actif n’est trouvé.
Un compte avec une boîte aux lettres liée ne sera jamais utilisé pour userPrincipalName et sourceAnchor. On
part du principe qu’un compte actif sera trouvé ultérieurement.
Un objet de contact peut être approvisionné pour Azure AD en tant que contact ou utilisateur. Vous ne saurez
s’il s’agit de l’un ou de l’autre qu’une fois que toutes les forêts Active Directory sources auront été traitées.
Groupes
Points importants à prendre en compte pendant la synchronisation de groupes depuis Active Directory vers
Azure AD :
Azure AD Connect exclut les groupes de sécurité intégrés de la synchronisation d’annuaires.
Azure AD Connect ne prend pas en charge la synchronisation des appartenances de groupe principal
avec Azure AD.
Azure AD Connect ne prend pas en charge la synchronisation des appartenances de groupe de
distribution dynamique avec Azure AD.
Pour synchroniser un groupe Active Directory avec Azure AD en tant que groupe à extension messagerie :
Si l’attribut proxyAddress du groupe est vide, son attribut mail doit comporter une valeur
Si l’attribut proxyAddress du groupe n’est pas vide, il doit au moins comporter une valeur
d’adresse de proxy SMTP. Voici quelques exemples :
Un groupe Active Directory dont l’attribut proxyAddress a la valeur
{"X500:/0=contoso.com/ou=users/cn=testgroup"} n’est pas à extension messagerie dans
Azure AD. Il n’a pas d’adresse SMTP.
Un groupe Active Directory dont l’attribut proxyAddress a les valeurs
{"X500:/0=contoso.com/ou=users/cn=testgroup","SMTP:johndoe@contoso.com"} est à
extension messagerie dans Azure AD.
Un groupe Active Directory dont l’attribut proxyAddress possède les valeurs
{"X500:/0=contoso.com/ou=users/cn=testgroup", "smtp:johndoe@contoso.com"} est aussi
à extension messagerie dans Azure AD.
Contacts
Avoir des contacts représentant un utilisateur dans une autre forêt est courant après une fusion et acquisition où
une solution GALSync joue le rôle de pont entre plusieurs forêts Exchange. L’objet de contact est toujours joint
de l’espace de connecteur au métaverse à l’aide de l’attribut de messagerie. S’il existe déjà un objet contact ou un
objet utilisateur avec la même adresse de messagerie, les objets sont joints. Ce comportement est configuré
dans la règle In from AD – Contact Join . Il existe également une règle nommée In from AD – Contact
Common avec un flux d’attribut vers l’attribut de métaverse sourceObjectType avec la constante Contact .
Cette règle a une priorité très faible. Ainsi, si un objet utilisateur est joint au même objet Metaverse, la règle In
from AD – User Common fournit la valeur User à cet attribut. Avec cette règle, cet attribut a la valeur Contact
si aucun utilisateur n’a été joint et la valeur User si au moins un utilisateur a été trouvé.
Pour l’approvisionnement d’un objet dans Azure AD, la règle sortante Out to AAD – Contact Join crée un
objet contact si l’attribut de métaverse sourceObjectType a la valeur Contact . Si cet attribut a la valeur User ,
la règle Out to AAD – User Join crée plutôt un objet utilisateur. Il est possible qu’un objet soit promu de
Contact en User quand davantage d’annuaires Active Directory sources sont importés et synchronisés.
Par exemple, dans une topologie GALSync, nous trouverons des objets contacts pour tous les membres de la
deuxième forêt quand nous importerons la première forêt. De nouveaux objets contacts seront ainsi créés dans
le connecteur AAD. Quand plus tard nous importerons et synchroniserons la deuxième forêt, nous trouverons
les utilisateurs réels et nous les joindrons aux objets de métaverse existants. Nous supprimerons ensuite l’objet
contact dans AAD et nous créerons un objet utilisateur à la place.
Si vous disposez d’une topologie dans laquelle les utilisateurs sont représentés en tant que contacts, veillez à
sélectionner la mise en correspondance des utilisateurs sur l’attribut de messagerie dans le guide d’installation.
Si vous sélectionnez une autre option, vous aurez une configuration dépendant de l’ordre. Les objets contacts
seront toujours joints sur l’attribut de messagerie, mais les objets utilisateurs seront joints sur l’attribut de
messagerie uniquement si cette option a été sélectionnée dans le guide d’installation. Vous pourriez alors vous
retrouver avec deux objets différents dans le métaverse avec le même attribut de messagerie si l’objet contact a
été importé avant l’objet utilisateur. Lors de l’exportation vers Azure AD, une erreur sera levée. Ce comportement
est normal et indique que des données sont incorrectes ou que la topologie n’a pas été identifiée correctement
lors de l’installation.
Comptes désactivés
Les comptes désactivés sont aussi synchronisés vers Azure AD. Les comptes désactivés représentent
couramment des ressources dans Exchange, par exemple des salles de conférence. L’exception concerne les
utilisateurs avec une boîte aux lettres liée ; comme mentionné précédemment, ces utilisateurs ne configureront
jamais un compte dans Azure AD.
L’hypothèse est que si un compte d’utilisateur désactivé est détecté, nous ne trouverons pas ultérieurement
d’autre compte actif et l’objet est approvisionné dans Azure AD avec les attributs userPrincipalName et
sourceAnchor trouvés. Dans le cas où un autre compte actif joindrait le même objet de métaverse, ses attributs
userPrincipalName et sourceAnchor seraient utilisés.
Changement de l’attribut sourceAnchor

Quand un objet a été exporté vers Azure AD, il n’est plus autorisé à modifier l’attribut sourceAnchor. Quand
l’objet a été exporté, l’attribut de métaverse cloudSourceAnchor est défini avec la valeur sourceAnchor
acceptée par Azure AD. Si sourceAnchor est modifié et ne correspond pas à cloudSourceAnchor , la règle
Out to AAD – User Join génère l’erreur L’attribut sourceAnchor a changé . Dans ce cas, la configuration ou
les données doivent être corrigées pour que le même sourceAnchor soit présent dans le métaverse et que l’objet
puisse être de nouveau synchronisé.
Attributs de clichés instantanés du service de
synchronisation Azure AD Connect
La plupart des attributs sont représentés de la même façon dans Azure AD qu’ils le sont dans votre Active
Directory local. Toutefois, certains attributs ont une gestion spéciale, et la valeur d’attribut dans Azure AD peut
être différente de ce qu’Azure AD Connect synchronise.
Présentation des attributs des clichés instantanés

Certains attributs ont deux représentations dans Azure AD. La valeur locale et une valeur calculée sont stockées.
Ces attributs supplémentaires sont appelés attributs de clichés instantanés. Les deux attributs les plus courants
pour lesquels vous voyez ce comportement sont userPrincipalName et proxyAddress . La modification des
valeurs d’attribut se produit lorsque des valeurs de ces attributs représentent des domaines non vérifiés. Mais le
moteur de synchronisation de Connect lit la valeur de l’attribut de cliché instantané. Ainsi, de son point de vue,
l’attribut a été confirmé par Azure AD.
Vous ne voyez pas les attributs de cliché instantané en utilisant le portail Azure ou avec PowerShell. Mais
comprendre le concept vous aide à corriger certains scénarios où l’attribut a des valeurs différentes en local et
dans le cloud.
Pour mieux comprendre le comportement, observez cet exemple de Fabrikam :
Ils ont plusieurs suffixes UPN dans leur Active Directory local, mais ils n’en ont vérifié qu’un.
userPrincipalName
Un utilisateur possède les valeurs d’attribut suivantes dans un domaine non vérifié :
AT T RIB UT VA L EUR
userPrincipalName local lee.sperry@fabrikam.com
shadowUserPrincipalName dans Azure AD lee.sperry@fabrikam.com
userPrincipalName dans Azure AD lee.sperry@fabrikam.onmicrosoft.com
L’attribut userPrincipalName est la valeur que vous voyez lors de l’utilisation de PowerShell.
Étant donné que la valeur d’attribut locale réelle est stockée dans Azure AD, lorsque vous vérifiez le domaine
fabrikam.com, Azure AD met à jour l’attribut userPrincipalName avec la valeur de shadowUserPrincipalName.
Vous n’avez pas à synchroniser les modifications apportées à Azure AD Connect pour que ces valeurs soient
mises à jour.
proxyAddresses
Le même processus pour inclure uniquement les domaines vérifiés se produit également pour proxyAddresses,
mais avec une logique supplémentaire. La confirmation des domaines vérifiés se produit uniquement pour les
utilisateurs de boîtes aux lettres. Un utilisateur ou un contact utilisant une boîte aux lettres représente un
utilisateur dans une autre organisation Exchange, et vous pouvez ajouter toute valeur présente dans
proxyAddresses à ces objets.
Pour un utilisateur de boîte aux lettres, en local ou dans Exchange Online, seules les valeurs pour les domaines
vérifiés s’affichent. Vous devriez voir quelque chose de semblable à ceci :
AT T RIB UT VA L EUR
proxyAddresses local SMTP:abbie.spencer@fabrikamonline.com

smtp:abbie.spencer@fabrikam.com
smtp:abbie@fabrikamonline.com
proxyAddresses dans Exchange Online SMTP:abbie.spencer@fabrikamonline.com

smtp:abbie@fabrikamonline.com
SIP:abbie.spencer@fabrikamonline.com
Dans ce cas smtp:abbie.spencer@fabrikam.com a été supprimé, car ce domaine n’a pas été vérifié. Mais
Exchange a également ajouté SIP:abbie.spencer@fabrikamonline.com . Fabrikam n’a pas utilisé Lync/Skype
en local, mais Azure AD et Exchange Online s’y préparent.
Cette logique pour proxyAddresses est appelée ProxyCalc . ProxyCalc est appelé à chaque modification d’un
utilisateur lorsque :
L’utilisateur s’est vu attribuer à un plan de service qui inclut Exchange Online, même s’il n’avait pas de licence
pour Exchange. Par exemple, si l’utilisateur est affecté à la référence (SKU) Office E3, mais s’est seulement vu
attribuer SharePoint Online. Cette condition est vraie même si votre boîte aux lettres est toujours locale.
L’attribut msExchRecipientTypeDetails a une valeur.
Vous apportez une modification à proxyAddresses ou userPrincipalName.
ProxyCalc nettoie une adresse si ShadowProxyAddresses contient un domaine non vérifié et que l’utilisateur
cloud a l’une des propriétés suivantes configurées.
L’utilisateur dispose d’une licence avec un plan de type de service EXO activé (à l’exception de MyAnalytics)
L’utilisateur a un ensemble de MSExchRemoteRecipientType (non null)
L’utilisateur est considéré comme une ressource partagée
Pour être considéré comme une ressource partagée, l’utilisateur cloud aura l’une des valeurs suivantes définies
dans CloudMSExchRecipientDisplayType
T Y P E D’A F F IC H A GE DE L’O B JET VA L EUR ( F O RM AT DÉC IM A L )
MailboxUser 0
DistributionGroup 1
Dossier public 2
DynamicDistributionGroup 3
Organisation 4
PrivateDistributionList 5
RemoteMailUser 6
ConferenceRoomMailbox 7
EquipmentMailbox 8
ArbitrationMailbox 10
MailboxPlan 11
LinkedUser 12
RoomList 15
SyncedMailboxUser -2147483642
SyncedUDGasUDG -2147483391
SyncedUDGasContact -2147483386
SyncedPublicFolder -2147483130
SyncedDynamicDistributionGroup -2147482874
SyncedRemoteMailUser -2147482106
SyncedConferenceRoomMailbox -2147481850
SyncedEquipmentMailbox -2147481594
SyncedUSGasUDG -2147481343
SyncedUSGasContact -2147481338
ACLableSyncedMailboxUser -1073741818
ACLableSyncedRemoteMailUser -1073740282
ACLableSyncedUSGasContact -1073739514
SyncedUSGasUSG -1073739511
SecurityDistributionGroup 1043741833
SyncedUSGasUSG 1073739511
ACLableSyncedUSGasContact 1073739514
Groupe de rôles RBAC 1073741824
ACLableMailboxUser 1073741824
ACLableRemoteMailUser 1073741830
NOTE
CloudMSExchRecipientDisplayType n’est pas visible du côté Azure AD et ne peut être affiché qu’en utilisant quelque chose
comme la cmdlet Exchange Online Get-Recipient.
Exemple :
Get-Recipient admin | fl *type*
ProxyCalc peut avoir besoin d’un certain temps pour traiter une modification sur un utilisateur et n’est pas
synchrone avec le processus d’exportation d’Azure AD Connect.
NOTE
La logique de ProxyCalc a des comportements supplémentaires pour des scénarios avancés qui ne sont pas documentés
dans cette rubrique. Cette rubrique est fournie pour vous aider à comprendre le comportement et non pour détailler
l’ensemble de la logique interne.
Valeurs d’attribut en quarantaine

Les attributs de clichés instantanés sont également utilisés lorsque des valeurs d’attribut sont en double. Pour
plus d’informations, consultez Résilience d’attribut en double.
Voir aussi
Feuille de route pour l’installation d’Azure AD
Connect et d’Azure AD Connect Health
Installer Azure AD Connect

IMPORTANT
actions qui sont documentées de façon formelle. Ces actions peuvent entraîner un état de synchronisation Azure AD
Connect incohérent ou non pris en charge. Par conséquent, Microsoft ne peut pas fournir de support technique pour ces
déploiements.
Vous pouvez trouver le téléchargement d’Azure AD Connect sur le Centre de téléchargement Microsoft.
SO L UT IO N SC ÉN A RIO
Avant de commencer : Matériel et conditions préalables Étapes à suivre avant de commencer à installer Azure AD
Connect.
Paramètres Express Si vous ne disposez que d’une seule forêt Active Directory,
cette option est recommandée.
Connexion de l’utilisateur avec le même mot de passe à
l’aide de la synchronisation du mot de passe.
Paramètres personnalisés Utilisés lorsque vous disposez de plusieurs forêts. Prise en

charge de nombreuses topologies locales.
Personnalisez votre option de connexion, par exemple
l’authentification directe, ADFS pour la fédération, ou utilisez
un fournisseur d’identité tiers.
Personnalisez les fonctionnalités de synchronisation, telles
que le filtrage et l’écriture différée.
Mise à niveau à partir de DirSync Utilisé lorsque vous disposez d’un serveur DirSync existant
déjà en cours d’exécution.
Mise à niveau à partir d’Azure AD Sync ou Il existe plusieurs méthodes différentes, en fonction de vos
d’Azure AD Connect préférences.
Après l’installation , vous devez vérifier que tout fonctionne comme prévu et affecter des licences aux
utilisateurs.
Étapes suivantes pour installer Azure AD Connect
RUB RIQ UE L IEN
Téléchargez Azure AD Connect Téléchargez Azure AD Connect
Installation à l’aide des paramètres Express Installation rapide pour Azure AD Connect
Installation à l’aide des paramètres personnalisés Installation personnalisée d’Azure AD Connect

RUB RIQ UE L IEN
Effectuer une mise à niveau à partir de DirSync Effectuer une mise à niveau à partir de l’outil de
synchronisation Azure AD (DirSync)
Après l’installation Vérification de l’installation et affectation des licences
En savoir plus sur l’installation d’Azure AD Connect

Il peut également être judicieux de se préparer aux préoccupations opérationnelles . Vous pouvez souhaiter
disposer d’un serveur de secours afin de pouvoir facilement basculer en cas de sinistre. Si vous envisagez
d’effectuer des modifications de configuration fréquentes, vous devriez planifier un serveur en mode
intermédiaire .
RUB RIQ UE L IEN
Topologies prises en charge Topologies pour Azure AD Connect
Principes de conception Principes de conception Azure AD Connect
Comptes utilisés pour l’installation Autorisations et informations d’identification Azure AD

Connect
Planification opérationnelle Synchronisation Azure AD Connect : tâches opérationnelles

et examen
Options de connexion utilisateur Options de connexion de l’utilisateur via Azure AD Connect
Configuration des fonctionnalités de synchronisation

Azure AD Connect est doté de plusieurs fonctionnalités que vous pouvez activer ou qui sont activées par défaut.
Certaines fonctionnalités peuvent parfois nécessiter une configuration supplémentaire dans des topologies et
scénarios spécifiques.
filtrage est utilisé lorsque vous souhaitez limiter le nombre d’objets synchronisés sur Azure AD. Par défaut, tous
les utilisateurs, contacts, groupes et ordinateurs Windows 10 sont synchronisés. Vous pouvez modifier le filtrage
en fonction des domaines, des unités d’organisation ou des attributs.
La synchronisation de hachage du mot de passe synchronise le hachage du mot de passe dans Active Directory
sur Azure AD. Cela permet à l’utilisateur final d’utiliser le même mot de passe en local et dans le cloud, mais
uniquement de le gérer dans un seul emplacement. Dans la mesure où cela utilise votre Active Directory local en
tant qu’autorité, vous pourrez également utiliser votre propre stratégie de mot de passe.
écriture différée du mot de passe permettra à vos utilisateurs de modifier et de réinitialiser leurs mots de passe
dans le cloud et d’appliquer votre stratégie de mot de passe locale.
La réécriture d’appareil autorise un appareil inscrit dans Azure AD à bénéficier de la réécriture dans Active
Directory en local afin de pouvoir être utilisé pour l’accès conditionnel.
La fonctionnalité de prévention des suppressions accidentelles est activée par défaut et protège votre répertoire
du cloud d’un grand nombre de suppressions en même temps. Par défaut, elle permet 500 suppressions par
exécution. Vous pouvez modifier ce paramètre en fonction de la taille de votre organisation.
La mise à niveau automatique est activée par défaut pour une installation rapide des paramètres. Elle garantit
qu’Azure AD Connect est toujours à jour avec la dernière version.
Étapes suivantes pour configurer des fonctionnalités de synchronisation
RUB RIQ UE L IEN
Configurer le filtrage Synchronisation Azure AD Connect : Configurer le filtrage
Synchronisation de hachage de mot de passe Synchronisation de hachage de mot de passe
Authentification directe Authentification directe
Réécriture du mot de passe Prise en main de la gestion de mot de passe
Écriture différée des appareils Activation de l’écriture différée des appareils dans
Azure AD Connect
prévention des suppressions accidentelles Synchronisation Azure AD Connect : prévention des

suppressions accidentelles
Mise à jour automatique Azure AD Connect : mise à niveau automatique
Personnaliser Azure AD Connect Sync

Azure Connect AD Sync est doté d’une configuration par défaut qui est destinée à fonctionner pour la plupart
des clients et des topologies. Toutefois, il existe toujours des situations dans lesquelles la configuration par
défaut ne fonctionne pas et doit être ajustée. Il est possible d’apporter les modifications documentées dans cette
section, ainsi que dans les rubriques connexes.
Si vous n’avez jamais travaillé avec une topologie de synchronisation auparavant, vous devriez commencer par
assimiler les notions de base et les termes utilisés décrits dans les concepts techniques. Azure AD Connect est
l’évolution de MIIS2003, ILM2007 et FIM2010. Bien que certains éléments soient identiques, beaucoup de
choses ont changé.
La configuration par défaut suppose la présence possible de plusieurs forêts. Dans ces topologies, un objet
utilisateur peut être représenté comme un contact dans une autre forêt. L’utilisateur peut également disposer
d’une boîte aux lettres liée dans une autre forêt de ressources. Le comportement de la configuration par défaut
est décrit dans Utilisateurs et contacts.
Le modèle de configuration dans la synchronisation est appelé Approvisionnement déclaratif. Les flux des
attributs avancés utilisent des fonctions pour exprimer les transformations des attributs. Vous pouvez afficher et
examiner l’intégralité de la configuration à l’aide des outils fournis avec Azure AD Connect. Si vous devez
apporter des modifications à la configuration, assurez-vous de suivre les meilleures pratiques afin que les
nouvelles versions soient plus faciles à adopter.
Étapes suivantes pour personnaliser Azure AD Connect Sync
RUB RIQ UE L IEN
Tous les articles sur la synchronisation Azure AD Connect Synchronisation d’Azure AD Connect
Concepts techniques Synchronisation Azure AD Connect : concepts techniques
Présentation de la configuration par défaut Synchronisation Azure AD Connect : comprendre la

configuration par défaut
RUB RIQ UE L IEN
Présentation des utilisateurs et des contacts Synchronisation Azure AD Connect : présentation des
utilisateurs et des contacts
Approvisionnement déclaratif Synchronisation Azure AD Connect : comprendre les

expressions de provisionnement déclaratif
Modifier la configuration par défaut Meilleures pratiques pour la modification de la configuration

par défaut
Configuration de fonctionnalités de fédération

Azure AD Connect fournit plusieurs fonctionnalités qui simplifient la fédération avec Azure AD à l’aide d’AD FS,
ainsi que la gestion de l’approbation de fédération. Azure AD Connect prends en charge AD FS sur Windows
Server 2012R2 et les versions ultérieures.
Mettez à jour le certificat TLS/SSL de la batterie de serveurs AD FS, même si vous n’utilisez pas Azure AD
Connect pour gérer l’approbation de votre fédération.
Ajoutez un serveur AD FS à votre batterie de serveurs pour l’étendre selon vos besoins.
Réparez l’approbation avec Azure AD en quelques clics.
ADFS peut être configuré de manière à prendre en charge plusieurs domaines. Par exemple, vous pouvez avoir
plusieurs domaines principaux que vous devez utiliser pour la fédération.
Si votre serveur ADFS n’a pas été configuré pour mettre à jour automatiquement les certificats Azure AD ou si
vous utilisez une solution non ADFS, vous recevrez une notification lorsque vous devrez mettre à jour des
certificats.
Étapes suivantes pour configurer des fonctionnalités de fédération
RUB RIQ UE L IEN
Tous les articles AD FS Fédération avec Azure AD Connect
Configuration d’ADFS avec des sous-domaines Prise en charge de plusieurs domaines pour la fédération
avec Azure AD
Gérer la batterie AD FS Gestion AD FS et personnalisation avec Azure AD Connect
Mise à jour manuelle des certificats de fédération Renouvellement des certificats de fédération pour
Microsoft 365 et Azure AD
Démarrer avec Azure AD Connect Health

Pour vous familiariser avec Azure AD Connect Health, procédez comme suit :
1. Accédez à Obtenir Azure AD Premium ou Démarrer une version d’évaluation.
2. Téléchargez et installez les agents Azure AD Connect Health sur vos serveurs d’identité.
3. Affichez le tableau de bord Azure AD Connect Health disponible à l’adresse https://aka.ms/aadconnecthealth.
NOTE
Avant de pouvoir consulter des données sur votre tableau de bord Azure AD Connect Health, il vous faudra installer les
agents Azure AD Connect Health sur vos serveurs cibles.
Téléchargement et installation de l’agent Azure AD Connect Health

Vérifiez que vous disposez de la configuration requise pour Azure AD Connect Health.
Prise en main d’Azure AD Connect Health pour AD FS
Téléchargez l’agent Azure AD Connect Health pour AD FS.
Consultez les instructions d’installation.
Prise en main d’Azure AD Connect Health pour la synchronisation
Téléchargez et installez la dernière version d’Azure AD Connect. L’agent d’intégrité pour la
synchronisation sera ajouté dans le cadre de l’installation d’Azure AD Connect (version 1.0.9125.0 ou
ultérieure).
Prise en main d’Azure AD Connect Health pour AD DS
Téléchargez l’agent Azure AD Connect Health pour AD DS.
Portail Azure AD Connect Health

Ce portail vous permet d’afficher des alertes, de surveiller les performances et d’analyser les utilisations. L’URL
https://aka.ms/aadconnecthealth vous permet d’accéder au panneau principal d’Azure AD Connect Health.
Considérez les panneaux comme des fenêtres. Dans le panneau principal, vous pouvez voir Démarrage rapide ,
les services offerts dans Azure AD Connect Health et d’autres options de configuration. Consultez la capture
d’écran suivante et la brève explication qui l’accompagne. Après le déploiement des agents, le service de
contrôle d’intégrité s’identifie automatiquement pour les services qu’Azure AD Connect Health analyse.
NOTE
Pour plus d’informations sur les licences, consultez la FAQ Azure AD Connect Health ou la page de tarification d’Azure AD.
Démarrage rapide : quand vous sélectionnez cette option, le panneau Démarrage rapide s’ouvre.
Vous pouvez télécharger l’agent Azure AD Connect Health en sélectionnant Obtenir les outils . Vous
pouvez également accéder à la documentation et fournir des commentaires.
Azure Active Director y Connect (synchronisation) : cette option affiche les serveurs Azure AD
Connect actuellement supervisés par Azure AD Connect Health. L’entrée Erreurs de synchronisation
affiche les erreurs de synchronisation de base de votre premier service de synchronisation intégré par
catégories. Quand vous sélectionnez l’entrée Ser vices de synchronisation , le panneau qui s’ouvre
affiche des informations sur vos serveurs Azure AD Connect. Pour en savoir plus sur les fonctionnalités,
consultez Utilisation d’Azure AD Connect Health pour la synchronisation.
Active Director y Federation Ser vices : cette option affiche tous les services AD FS supervisés par
Azure AD Connect Health. Lorsque vous sélectionnez une instance, le panneau qui s’ouvre fournit des
informations sur cette instance de service. Il comporte une vue d’ensemble, les propriétés, les alertes, les
données de surveillance et une analyse de l’utilisation. Pour en savoir plus sur les fonctionnalités,
consultez Utilisation d’Azure AD Connect Health avec AD FS.
Active Director y Domain Ser vices : cette option affiche toutes les forêts AD DS supervisées par Azure
AD Connect Health. Lorsque vous sélectionnez une forêt, le panneau qui s’ouvre fournit des informations
sur cette forêt. Ces informations incluent une vue d’ensemble des informations essentielles, le tableau de
bord des contrôleurs de domaine, le tableau de bord d’état de réplication, des alertes et la surveillance.
Pour en savoir plus sur les fonctionnalités, consultez Utilisation d’Azure AD Connect Health avec AD DS.
Configurer : cette section inclut des options permettant d’activer ou de désactiver les éléments suivants :
La mise à jour automatique de l’agent Azure AD Connect Health vers la dernière version : l’agent
Azure AD Connect Health est automatiquement mis à jour dès que de nouvelles versions sont
disponibles. Cette option est activée par défaut.
Accès aux données à partir de l’intégrité de l’annuaire Azure AD par Microsoft uniquement à des
fins de dépannage : si cette option est activée, Microsoft peut accéder aux mêmes données que
l’utilisateur. Ces informations peuvent être utiles pour la résolution des problèmes et pour fournir
l’assistance nécessaire. Cette option est désactivée par défaut
Contrôle d’accès en fonction du rôle (IAM) est la section permettant de gérer l’accès aux données
Connect Health en fonction du rôle.
Étapes suivantes
Paramètres Express
Synchronisation de hachage de mot de passe|
Conditions préalables pour Azure AD Connect
Cet article décrit les conditions préalables et la configuration matérielle requise pour Azure Active Directory
(Azure AD) Connect.
Avant d’installer Azure AD Connect

Avant d’installer Azure AD Connect, voici ce dont vous avez besoin.
Azure AD
Vous avez besoin d’un locataire Azure AD. Vous pouvez en obtenir un avec un essai gratuit Azure. Vous
pouvez utiliser un des portails suivants pour gérer Azure AD Connect :
Le portail Azure.
Le portail Office.
Ajoutez et vérifiez le domaine que vous prévoyez d’utiliser dans Azure AD. Par exemple, si vous envisagez
d’utiliser contoso.com pour vos utilisateurs, assurez-vous que ce domaine a été vérifié et que vous n’utilisez
pas uniquement le domaine par défaut contoso.onmicrosoft.com.
Un locataire Azure AD prend en charge 50 000 objets par défaut. Lorsque vous vérifiez votre domaine, la
limite passe à 300 000 objets. Si vous avez besoin de davantage d’objets dans Azure AD, ouvrez une
demande de support pour que la limite soit augmentée en conséquence. Si vous avez besoin de plus de
500 000 objets, il vous faut une licence telle que Microsoft 365, Azure AD Premium ou Enterprise
Mobility + Security.
Préparez vos données locales
Utilisez IdFix pour identifier les erreurs comme les doublons et les problèmes de mise en forme dans votre
répertoire avant d’effectuer la synchronisation avec Azure AD et Microsoft 365.
Vérifiez les fonctionnalités de synchronisation facultatives que vous pouvez activer dans Azure AD et évaluez
quelles fonctionnalités vous devez activer.
Active Directory local
La version de schéma Active Directory et le niveau fonctionnel de forêt doivent être Windows Server 2003
ou version ultérieure. Les contrôleurs de domaine peuvent exécuter n’importe quelle version aussi
longtemps que les exigences relatives à la version de schéma et au niveau de forêt sont remplies.
Si vous prévoyez d’utiliser la fonctionnalité Réécriture du mot de passe, les contrôleurs de domaine doivent
être exécutés dans Windows Server 2016 ou une version ultérieure.
Le contrôleur de domaine utilisé par Azure AD doit être accessible en écriture. L’utilisation d’un contrôleur de
domaine en lecture seule (RODC) n’est pas prise en charge et Azure AD Connect ne suivra pas les
redirections d’écriture.
L’utilisation de forêts ou de domaines locaux utilisant des noms NetBIOS avec point (le nom contient un
point « . ») n’est pas prise en charge.
Nous vous recommandons d’activer la corbeille d’Active Directory.
Stratégie d'exécution de PowerShell
Azure Active Directory Connect exécute les scripts PowerShell signés dans le cadre de l’installation. Assurez-
vous que la stratégie d’exécution de PowerShell autorise l’exécution de scripts.
La stratégie d’exécution recommandée lors de l’installation est « RemoteSigned ».
Pour plus d’informations sur la définition de la stratégie d’exécution de PowerShell, consultez Set-
ExecutionPolicy.
Serveur Azure AD Connect
Le serveur Azure AD Connect contient des données d’identité critiques. Il est important que l’accès administratif
à ce serveur soit correctement sécurisé. Suivez les instructions de l’article Sécurisation de l’accès privilégié.
Le serveur Azure AD Connect doit être traité comme un composant de niveau 0, comme expliqué dans le
modèle de niveau administratif Active Directory.
Pour en savoir plus sur la sécurisation de votre environnement Active Directory, consultez Meilleures pratiques
pour la sécurisation d’Active Directory.
Prérequis pour l’installation
Azure AD Connect doit être installé sur un serveur Windows Server 2016 joint à un domaine ou sur une
version ultérieure.
Vous ne pouvez pas installer Azure AD Connect sur des serveurs Small Business Server ou Windows Server
Essentials dont la version est antérieure à 2019 (Windows Server Essentials 2019 est pris en charge). Le
serveur doit utiliser Windows Server Standard ou une version supérieure.
Le serveur Azure AD Connect doit disposer d’une interface utilisateur graphique complète. L’installation
d’Azure AD Connect sur Windows Server Core n’est pas prise en charge.
La stratégie de groupe de transcription PowerShell ne doit pas être activée sur le serveur Azure AD Connect
si vous utilisez l’Assistant Azure AD Connect pour gérer la configuration des services de fédération Active
Directory (AD FS). Vous pouvez activer la transcription PowerShell si vous utilisez l’Assistant Azure AD
Connect pour gérer la configuration de la synchronisation.
Si AD FS est déployé :
Les serveurs sur lesquels AD FS ou le proxy d’application web sont installés doivent être des serveurs
Windows Server 2012 R2 ou version ultérieure. La gestion à distance de Windows doit être activée
sur ces serveurs pour l’installation à distance.
Vous devez configurer des certificats TLS/SSL. Pour plus d’informations, consultez Gestion des
protocoles SSL/TLS et des suites de chiffrement pour AD FS et Gestion des certificats SSL dans AD FS.
Vous devez configurer la résolution de noms.
Le fractionnement et l’analyse du trafic entre Azure AD Connect et Azure AD ne sont pas pris en charge. Cela
pourrait perturber le service.
Si l’authentification multifacteur est activée pour vos administrateurs généraux, l’URL
https://secure.aadcdn.microsoftonline-p.com doit figurer dans la liste des sites de confiance. Vous êtes invité
à ajouter ce site à la liste des sites de confiance lorsque vous êtes invité à passer un test d’authentification
multifacteur et qu’il n’a pas encore été ajouté. Vous pouvez utiliser Internet Explorer pour l’ajouter à vos sites
de confiance.
Si vous envisagez d'utiliser Azure AD Connect Health pour la synchronisation, assurez-vous que les
conditions préalables d'Azure AD Connect Health sont également remplies. Pour plus d'informations,
consultez Installation de l'agent Azure AD Connect Health.
Renforcer votre serveur Azure AD Connect
Nous vous recommandons de renforcer votre serveur Azure AD Connect afin de réduire la surface d’attaque de
sécurité de ce composant essentiel de votre environnement informatique. En suivant ces recommandations,
vous contribuez à atténuer certains risques de sécurité pour votre organisation.
Traitez Azure AD Connect de la même manière qu’un contrôleur de domaine et que d’autres ressources de
niveau 0. Pour plus d’informations, consultez Modèle de niveau d’administration Active Directory.
Limitez l’accès administrateur au serveur Azure AD Connect aux seuls administrateurs de domaine ou autres
groupes de sécurité étroitement contrôlés.
Créez un compte dédié pour tous les membres du personnel disposant d’un accès privilégié. Les
administrateurs ne doivent pas naviguer sur Internet, consulter leur e-mails ni effectuer des tâches de
productivité quotidiennes avec des comptes à privilèges élevés.
Suivez les instructions fournies dans Sécurisation de l’accès privilégié.
Refuser l’utilisation de l’authentification NTLM avec le serveur AADConnect. Voici quelques façons de
procéder : Restriction de NTLM sur le serveur AADConnect et Restriction de NTLM sur un domaine
Assurez-vous que chaque ordinateur dispose d’un mot de passe d’administrateur local unique. Pour plus
d’informations, consultez l’avis de sécurité Microsoft relatif à une solution de mot de passe administrateur
local (LAPS). Une LAPS peut configurer des mots de passe aléatoires uniques sur chaque station de travail et
les stocker sur serveur dans Active Directory, protégé par une liste de contrôle d’accès (ACL, access-control
list). Seuls les utilisateurs autorisés éligibles peuvent lire ou demander la réinitialisation de ces mots de passe
de compte d’administrateur local. Vous pouvez obtenir LAPS afin de l’utiliser pour les stations de travail à
partir du Centre de téléchargement Microsoft. Vous trouverez des conseils supplémentaires sur le
fonctionnement d’un environnement avec une LAPS et des stations de travail à accès privilégié (PAW) dans
Normes opérationnelles basées sur le principe de source propre.
Implémentez des stations de travail à accès privilégié dédiées pour tous les membres du personnel disposant
d’un accès privilégié aux systèmes informatiques de votre organisation.
Suivez ces instructions supplémentaires pour réduire la surface d’attaque de votre environnement Active
Directory.
Si vous souhaitez configurer des alertes pour superviser les modifications apportées à l’approbation établie
entre votre Idp et Azure AD, lisez Superviser les modifications apportées à la configuration de fédération.
Activez l’Authentification multifacteur (MFA) pour tous les utilisateurs disposant d’un accès privilégié dans
Azure AD ou le répertoire actif. L’un des problèmes de sécurité liés à l’utilisation de AADConnect est que si
une personne malveillante arrive à contrôler le serveur Azure AD Connect, elle peut également manipuler les
utilisateurs dans Azure AD. Pour empêcher une personne malveillante d’utiliser ces fonctionnalités afin de
contrôler des comptes Azure AD, MFA offre des protections de sorte que même si une personne malveillante
gère le mot de passe d’un utilisateur à l’aide d’Azure AD Connect, elle ne pourra toujours pas contourner le
second facteur.
SQL Server utilisé par Azure AD Connect
Azure AD Connect nécessite une base de données SQL Server pour stocker les données d’identité. Par défaut,
une base de données locale SQL Server 2019 Express (version légère de SQL Server Express) est installée.
SQL Server Express a une limite de 10 Go qui vous permet de gérer environ 100 000 objets. Si vous avez
besoin de gérer un volume plus important d’objets annuaire, pointez l’Assistant d’installation vers une autre
installation de SQL Server. Le type d’installation de SQL Server peut impacter les performances d’Azure AD
Connect.
Si vous utilisez une installation différente de SQL Server, ces conditions s’appliquent :
Azure AD Connect prend en charge toutes les versions de SQL Server à partir de la version 2012 (avec
le dernier Service Pack) et jusqu’à SQL Server 2019. Azure SQL Database n’est pas pris en charge en
tant que base de données.
Vous devez utiliser un classement SQL qui ne respecte pas la casse. Ces classements sont identifiés
par un _CI_ dans leur nom. L’utilisation d’un classement qui respecte la casse, identifié par _CS_ dans
le nom, n’est pas prise en charge.
Vous ne pouvez avoir qu’un seul moteur de synchronisation par instance SQL. Le partage d’une
instance SQL avec FIM/MIM Sync, DirSync ou Azure AD Sync n’est pas pris en charge.
Comptes
Vous devez disposer d’un compte Administrateur global Azure AD pour le locataire Azure AD que vous
souhaitez intégrer. Ce compte doit être un compte scolaire ou d’organisation et non un compte Microsoft.
Si vous utilisez la configuration rapide ou effectuez une mise à niveau depuis DirSync, vous devez disposer
d’un compte Administrateur d’entreprise pour votre annuaire Active Directory local.
Si vous utilisez le chemin d’installation des paramètres personnalisés, vous avez plus d’options. Pour plus
d’informations, consultez Paramètres d’installation personnalisée.
Connectivité
Le serveur Azure AD Connect nécessite une résolution DNS Intranet et Internet. Le serveur DNS doit
pouvoir résoudre des noms sur votre domaine Active Directory local et sur les points de terminaison
Azure AD.
Azure AD Connect nécessite une connectivité réseau à tous les domaines configurés
Si vous disposez de pare-feu sur votre Intranet et que vous devez ouvrir des ports entre les serveurs
Azure AD Connect et vos contrôleurs de domaine, consultez l’article Ports Azure AD Connect pour en
savoir plus.
Si votre proxy ou pare-feu limite les URL accessibles, les URL répertoriées dans URL et plages
d’adresses IP Office 365 doivent être ouvertes. Voir aussi Mettre sur liste fiable les URL du portail Azure
sur votre pare-feu ou serveur proxy.
Si vous utilisez le cloud Microsoft en Allemagne ou le cloud Microsoft Azure Government, consultez
Considérations relatives aux instances de service Azure AD Connect Sync à propos des URL.
Azure AD Connect (version 1.1.614.0 et ultérieures) utilise TLS 1.2 par défaut pour le chiffrement de la
communication entre le moteur de synchronisation et Azure AD. Si TLS 1.2 n’est pas disponible sur le
système d’exploitation sous-jacent, Azure AD Connect revient de façon incrémentielle aux protocoles plus
anciens (TLS 1.1 et TLS 1.0). À partir d’Azure AD Connect version 2.0. Les protocoles TLS 1.0 et 1.1 ne sont
plus pris en charge et l’installation échoue si TLS 1.2 n’est pas disponible.
Avant la version 1.1.614.0, Azure AD Connect utilise TLS 1.0 par défaut pour le chiffrement de la
communication entre le moteur de synchronisation et Azure AD. Pour utiliser TLS 1.2, suivez les étapes de
l’article Activer TLS 1.2 pour Azure AD Connect.
Si vous utilisez un proxy sortant pour vous connecter à Internet, le paramètre suivant dans le fichier
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config doit être ajouté
pour que l’Assistant d’installation et Azure AD Connect Sync puissent se connecter à Internet et à Azure
AD. Ce texte doit être entré en bas du fichier. Dans ce code, <PROXYADDRESS> représente l’adresse IP ou
le nom d’hôte réels du proxy.
<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
Si votre serveur proxy requiert une authentification, le compte de service doit se trouver dans le
domaine. Utilisez le chemin d’installation des paramètres personnalisés pour spécifier un compte de
service personnalisé. Vous devez également modifier le fichier machine.config. Cette modification dans le
fichier machine.config permet à l’Assistant d’installation et au moteur de synchronisation de répondre aux
demandes d’authentification du serveur proxy. Dans toutes les pages de l’Assistant d’installation, à
l’exclusion de la page Configurer , les informations d’identification de l’utilisateur sont utilisées. Dans la
page Configurer à la fin de l’Assistant d’installation, le contexte bascule vers le compte de service que
vous avez créé. La section machine.config doit se présenter comme suit :
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
usesystemdefault="true"
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
Si la configuration du proxy s’effectue dans une configuration existante, le ser vice Microsoft Azure AD
Sync doit être redémarré une fois pour qu’Azure AD Connect puisse lire la configuration du proxy et
mettre à jour le comportement.
Lorsque Azure Connect AD envoie une requête web à Azure AD dans le cadre de la synchronisation
d’annuaires, Azure AD peut mettre jusqu'à 5 minutes pour répondre. Il est courant qu’un délai d’inactivité
de la connexion soit configuré sur les serveurs proxy. Vérifiez que la configuration est définie sur au
moins 6 minutes, voire plus.
Consultez MSDN pour plus d’informations sur l’élément proxy par défaut. Pour plus d’informations lorsque
vous avez des problèmes de connectivité, consultez Résoudre les problèmes de connectivité liés à Azure AD
Connect.
Autres
Facultatif : Utilisez un compte d’utilisateur test pour vérifier la synchronisation.
Configuration requise pour les composants

PowerShell et .NET Framework
Azure AD Connect repose sur Microsoft PowerShell 5.0 et le .NET Framework 4.5.1. Cette version ou une version
ultérieure doit être installée sur votre serveur.
Activer TLS 1.2 pour Azure AD Connect
Avant la version 1.1.614.0, Azure AD Connect utilise TLS 1.0 par défaut pour le chiffrement de la communication
entre le serveur de moteur de synchronisation et Azure AD. Vous pouvez configurer les applications .NET pour
qu’elles utilisent TLS 1.2 par défaut sur le serveur. Pour plus d’informations sur TLS 1.2, consultez l’avis de
sécurité Microsoft 2960358.
1. Vérifiez que le correctif .NET 4.5.1 est installé pour votre système d’exploitation. Pour plus d’informations,
consultez l’avis de sécurité Microsoft 2960358. Il est possible que cette version du correctif ou une
version ultérieure soit déjà installée sur votre serveur.
2. Pour tous les systèmes d’exploitation, définissez cette clé de Registre et redémarrez le serveur.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
3. Si vous souhaitez également activer TLS 1.2 entre le serveur de moteur de synchronisation et un
serveur SQL distant, vérifiez que vous disposez des versions requises pour la prise en charge de TLS 1.2
pour Microsoft SQL Server.
Prérequis DCOM sur le serveur de synchronisation
Pendant l’installation du service de synchronisation, Azure AD Connect vérifie la présence de la clé de Registre
suivante :
HKEY_LOCAL_MACHINE : Software\Microsoft\Ole
Sous cette clé de Registre, Azure AD Connect vérifiera si les valeurs suivantes sont présentes et
non corrompues :
MachineAccessRestriction
MachineLaunchRestriction
DefaultLaunchPermission
Configuration requise pour l'installation et la configuration de la

fédération
gestion à distance de Windows
Lorsque vous utilisez Azure AD Connect pour déployer AD FS ou le proxy d’application web (WAP), vérifiez les
conditions requises suivantes :
Si le serveur cible est joint à un domaine, assurez-vous que la gestion à distance Windows est activée.
Dans une fenêtre de commandes PowerShell avec élévation de privilèges, utilisez la commande
Enable-PSRemoting –force .
Si le serveur cible n’est pas un ordinateur WAP joint à un domaine, il existe quelques conditions requises
supplémentaires :
Sur l'ordinateur cible (ordinateur WAP) :
Vérifiez que le service Windows Remote Management/WS-Management (WinRM) s’exécute via
le composant logiciel enfichable Services.
Enable-PSRemoting –force .
Sur l’ordinateur sur lequel s’exécute l’Assistant (si l’ordinateur cible n’est pas joint à un domaine ou s’il
s’agit d’un domaine non approuvé) :
Set-Item.WSMan:\localhost\Client\TrustedHosts –Value <DMZServerFQDN> -Force –Concatenate .
Dans le gestionnaire de serveur :
Ajoutez un hôte WAP DMZ à un pool de machines. Dans le gestionnaire de serveur,
sélectionnez Gérer > Ajouter des ser veurs , puis utilisez l’onglet DNS .
Sous l’onglet Tous les ser veurs de Gestionnaire de serveur, cliquez avec le bouton
droit sur le serveur WAP, puis sélectionnez Gérer en tant que . Entrez les informations
d’identification locales (et non de domaine) pour l’ordinateur WAP.
Pour valider la connectivité PowerShell distante, dans l’onglet Tous les ser veurs de
Gestionnaire de serveur, cliquez avec le bouton droit sur le serveur WAP et sélectionnez
Windows PowerShell . Une session PowerShell distante doit s’ouvrir pour garantir le
fait que des sessions PowerShell distantes peuvent être établies.
Configuration requise des certificats TLS/SSL
Nous vous recommandons d’utiliser le même certificat TLS/SSL sur tous les nœuds de votre batterie de
serveurs AD FS, ainsi que sur tous les serveurs de proxy d’application web.
Il doit s’agir d’un certificat X509.
Vous pouvez utiliser un certificat auto-signé sur les serveurs de fédération dans un environnement de
laboratoire de test. Pour un environnement de production, nous vous recommandons d’obtenir le certificat
auprès d’une autorité de certification publique.
Si vous utilisez un certificat qui n’est pas approuvé publiquement, assurez-vous que le certificat
installé sur chaque serveur de proxy d’application web est approuvé sur le serveur local et sur tous les
serveurs de fédération.
L’identité du certificat doit correspondre au nom du service de fédération (par exemple, sts.contoso.com).
L’identité est soit une extension « autre nom de l’objet » (SAN) de type dNSName, soit, à défaut
d’entrée SAN, le nom d’objet spécifié comme nom commun.
Le certificat peut contenir plusieurs entrées SAN, pour autant que l’une d’elles corresponde au nom
des services de fédération.
Si vous envisagez d’utiliser Workplace Join, une autre extension SAN est nécessaire avec la valeur
enterpriseregistration. suivie du suffixe de nom d’utilisateur principal de votre organisation, par
exemple, enterpriseregistration.contoso.com.
Les certificats basés sur les clés CNG (CryptoAPI Next Generation) et les fournisseurs de stockage de clés
(KSP) ne sont pas pris en charge. Par conséquent, vous devez utiliser un certificat basé sur un fournisseur de
services de chiffrement (CSP) et sur non un KSP.
Les certificats utilisant des caractères génériques sont pris en charge.
Résolution de noms pour les serveurs de fédération
Configurez les enregistrements DNS pour le nom AD FS (par exemple, sts.contoso.com) pour l’Intranet (votre
serveur DNS interne) et l’extranet (le DNS public via votre registre de nom de domaine). Pour
l’enregistrement DNS intranet, vérifiez que vous utilisez des enregistrements A et non des enregistrements
CNAME. L’utilisation d’enregistrements A est requis pour le bon fonctionnement de l’authentification
Windows à partir de votre ordinateur joint à un domaine.
Si vous déployez plusieurs serveurs AD FS ou serveurs de proxy d’application web, vérifiez que vous avez
configuré votre équilibreur de charge et que les enregistrements DNS pour le nom AD FS (p. ex.,
sts.contoso.com) pointent vers l’équilibreur de charge.
Pour que l’authentification intégrée Windows fonctionne avec les applications de navigateur utilisant Internet
Explorer dans votre Intranet, vérifiez que le nom AD FS (par exemple, sts.contoso.com) est ajouté à la zone
Intranet dans Internet Explorer. Cette exigence peut être contrôlée par le biais de la stratégie de groupe et
déployée sur tous les ordinateurs joints au domaine.
Composants de prise en charge d’Azure AD Connect

Azure AD Connect installe les composants suivants sur le serveur sur lequel il est installé. Cette liste est destinée
à une installation Express de base. Si vous choisissez d’utiliser un autre serveur SQL dans la page Installer des
ser vices de synchronisation , SQL Express LocalDB n’est pas installée localement.
Azure AD Connect Health
Utilitaires de ligne de commande Microsoft SQL Server 2019
Base de données locale Microsoft SQL Server 2019 Express
Client natif Microsoft SQL Server 2019
Package de redistribution Microsoft Visual C++ 14
Configuration matérielle requise pour Azure AD Connect

Le tableau suivant présente la configuration minimale requise pour l’ordinateur Azure AD Connect Sync.
N O M B RE D’O B JET S DA N S
A C T IVE DIREC TO RY UC M ÉM O IRE TA IL L E DU DISQ UE DUR
Moins de 10 000 1,6 GHz 4 Go 70 Go
Entre 10 000 et 50 000 1,6 GHz 4 Go 70 Go
Entre 50 000 et 100 000 1,6 GHz 16 Go 100 Go

N O M B RE D’O B JET S DA N S
A C T IVE DIREC TO RY UC M ÉM O IRE TA IL L E DU DISQ UE DUR
À partir de 100 000 objets,

la version complète de
SQL Server est requise.
Pour des raisons de
performance, il est
préférable de l’installer
localement.
Entre 100 000 et 300 000 1,6 GHz 32 Go 300 Go
Entre 300 000 et 600 000 1,6 GHz 32 Go 450 Go
Plus de 600 000 1,6 GHz 32 Go 500 Go
La configuration minimale requise pour les ordinateurs exécutant AD FS ou les serveurs de proxy d’applications
web est la suivante :
Processeur : double cœur 1,6 GHz ou supérieur
Mémoire : 2 Go ou plus
Machine virtuelle Azure : configuration A2 ou supérieure
Étapes suivantes
Sélectionner le type d’installation à utiliser pour
Azure AD Connect
Pour toute nouvelle installation, Azure AD Connect propose deux options : l'installation Express ou l'installation
personnalisée. Cette rubrique vous aide à choisir l’option à utiliser lors de l’installation.
Express
Express est l’option la plus courante et est utilisée dans environ 90 % des nouvelles installations. Elle a été
conçue pour fournir une configuration qui fonctionne dans la plupart des scénarios des clients.
Elle suppose que :
Vous avez une seule forêt Active Directory locale.
Vous avez un compte administrateur d’entreprise que vous pouvez utiliser pour l’installation.
Vous avez moins de 100 000 objets dans votre annuaire Active Directory local.
Vous obtenez :
La synchronisation de hachage du mot de passe du système local vers Azure AD pour l’authentification
unique.
Une configuration qui synchronise les utilisateurs, les groupes, les contacts et les ordinateurs Windows 10.
La synchronisation de tous les objets éligibles dans tous les domaines et toutes les unités d’organisation.
La mise à niveau automatique est activée pour garantir que vous utilisez toujours la dernière version
disponible.
Cas où vous pouvez toujours utiliser Express :
Si vous ne voulez pas synchroniser toutes les UO, vous pouvez néanmoins utiliser Express et, sur la dernière
page, désélectionner Démarrer le processus de synchronisation...*. Réexécutez ensuite l’Assistant
Installation, changez les unités d’organisation dans les options de configuration et activez la synchronisation
planifiée.
Vous voulez activer une des fonctionnalités dans Azure AD Premium, comme la réécriture du mot de passe.
Choisissez d’abord Express pour effectuer l’installation initiale. Réexécutez ensuite l’Assistant Installation et
changez les options de configuration.
Custom
L’installation personnalisée offre beaucoup plus d’options que l’installation Express. Elle doit être utilisée dans
tous les cas où la configuration décrite dans la section précédente pour Express n’est pas représentative de votre
organisation.
Utilisez-la quand :
Vous n’avez pas accès à un compte administrateur d’entreprise dans Active Directory.
Vous avez plusieurs forêts ou vous prévoyez de synchroniser plusieurs forêts à l’avenir.
Vous avez des domaines dans votre forêt qui ne sont pas accessibles à partir du serveur Connect.
Vous prévoyez d’utiliser la fédération ou l’authentification directe pour la connexion des utilisateurs.
Vous avez plus de 100 000 objets et vous devez utiliser un serveur SQL Server complet.
Vous prévoyez d’utiliser le filtrage par groupe, et pas seulement le filtrage par domaine ou par unité
d’organisation.
Effectuer une mise à niveau à partir de DirSync

Si vous utilisez actuellement DirSync, suivez les étapes de Mise à niveau à partir de DirSync pour mettre à
niveau votre configuration existante. Il existe deux scénarios différents de mise à niveau :
Mise à niveau sur place pour installer Connect sur le même serveur.
Déploiement en parallèle pour installer Connect sur un nouveau serveur, alors que le serveur DirSync
existant est toujours opérationnel.
Mise à niveau à partir d’Azure AD Sync

Si vous utilisez actuellement Azure AD Sync, vous pouvez suivre les mêmes étapes que celle de la mise à niveau
d’une version de Connect vers une version plus récente. Il existe deux scénarios différents de mise à niveau :
Mise à niveau sur place pour installer Connect sur le même serveur.
Migration via une instance distincte pour installer Connect sur un nouveau serveur, alors que le serveur
Azure AD Sync existant est toujours opérationnel.
Migrer depuis FIM2010 ou MIM2016

Si vous utilisez actuellement Forefront Identity Manager 2010 ou Microsoft Identity Manager 2016 avec le
connecteur Azure AD, votre seule option est une migration. Suivez les étapes décrites dans Migration via une
instance distincte. Dans les étapes, remplacez les mentions d’Azure AD Sync par FIM2010/MIM2016.
Étapes suivantes
Selon l’option que vous avez choisie, utilisez la table des matières à gauche pour trouver votre article avec les
étapes détaillées.
Prise en main d’Azure AD Connect à l’aide de
paramètres express
La configuration rapide d’Azure AD Connect est utilisée lorsque vous disposez d’une topologie à une forêt
unique et quand la synchronisation de hachage du mot de passe est utilisée pour l’authentification.
configuration rapide est l’option par défaut et s’applique à la plupart des scénarios de déploiement.
L’extension de votre répertoire local dans le cloud n’est plus qu’à quelques clics.
Avant de commencer l’installation d’Azure AD Connect, veillez à télécharger Azure AD Connect et effectuer les
étapes préalables décrites dans Azure AD Connect : matériel et prérequis.
Si la configuration rapide ne correspond pas à votre topologie, consultez la documentation connexe pour
d’autres scénarios.
Installation rapide pour Azure AD Connect

Vous pouvez voir ces étapes en action dans la section vidéos .
1. Connectez-vous en tant qu’administrateur local au serveur sur lequel vous souhaitez installer Azure AD
Connect. Il doit s’agir du serveur que vous choisissez comme serveur de synchronisation.
Continuer .
4. Sur l'écran Paramètres Express, cliquez sur Utiliser les paramètres Express .
5. Sur l’écran Connexion à Azure AD, entrez le nom d’utilisateur et un mot de passe d’administrateur général
pour votre instance Azure AD. Cliquez sur Suivant .
Si vous recevez une erreur et que vous avez des problèmes de connectivité, consultez Résoudre les
problèmes de connectivité liés à Azure AD Connect.
6. Sur l’écran Connexion à AD DS, entrez le nom d’utilisateur et le mot de passe d’un compte d’administrateur
d’entreprise. Vous pouvez saisir la partie domaine au format NetBios ou nom de domaine complet, c’est-à-
dire FABRIKAM\administrator ou fabrikam.com\administrator. Cliquez sur Suivant .
7. La page Configuration de connexion Azure AD s’affiche uniquement si vous n’avez pas effectué l’étape
de vérification de vos noms de domaines dans les conditions préalables.
Si vous voyez cette page, passez en revue chaque domaine marqué Non ajouté et Non vérifié . Assurez-
vous que les domaines que vous utilisez ont été vérifiés dans Azure AD. Cliquez sur le symbole
d’actualisation dès que vous avez vérifié vos domaines.
Dans la page Prêt à configurer, vous pouvez éventuellement décocher la case Démarrer le
processus de synchronisation dès que la configuration est terminée . Vous devez décocher
cette case si vous souhaitez effectuer une configuration supplémentaire, tel que le filtrage. Si vous
désélectionnez cette option, l’Assistant configure la synchronisation, mais laisse le planificateur
désactivé. Il n’est pas exécuté jusqu’à ce que vous l’activiez manuellement en exécutant de nouveau
l’Assistant d’installation.
En laissant la case Démarrer le processus de synchronisation dès que la configuration est
terminée cochée, cela déclenche immédiatement une synchronisation complète sur Azure AD de tous
les utilisateurs, groupes et contacts.
Si Exchange est présent dans votre répertoire Active Directory local, vous avez également la possibilité
d’activer le déploiement Exchange hybride . Activez cette option si vous envisagez de disposer
simultanément de boîtes aux lettres Exchange dans le cloud et en local.
10. Une fois l’installation terminée, déconnectez-vous puis reconnectez-vous à Windows avant d’utiliser le
gestionnaire Synchronization Service Manager ou l’éditeur de règles de synchronisation.
Videos
Pour une vidéo sur l’utilisation de l’installation rapide, voir :
Étapes suivantes
Azure AD Connect étant installé, vous pouvez passer à Vérification de l’installation et affectation des licences.
Pour en savoir plus sur ces fonctionnalités activées lors de l’installation, consultez les pages : Mise à niveau
automatique, Prévention des suppressions accidentelles et Azure AD Connect Health.
Pour en savoir plus sur ces sujets courants, consultez l’article Planificateur Azure AD Connect Sync.
documentation connexe
RUB RIQ UE L IEN
Présentation d’Azure AD Connect Intégrer vos répertoires locaux à Azure Active Directory
Installation à l’aide des paramètres personnalisés Installation personnalisée d’Azure AD Connect
Effectuer une mise à niveau à partir de DirSync Effectuer une mise à niveau à partir de l’outil de
synchronisation Azure AD (DirSync)
RUB RIQ UE L IEN
Comptes utilisés pour l’installation Autorisations et informations d’identification Azure AD

Connect
Installation personnalisée d’Azure Active Directory
Connect
Utilisez les paramètres personnalisés dans Azure Active Directory (Azure AD) lorsque vous souhaitez davantage
d’options d’installation. Utilisez ces paramètres, par exemple, si vous avez plusieurs forêts ou si vous souhaitez
configurer des fonctionnalités facultatives. Utilisez les paramètres personnalisés dans tous les cas où l’option
d’installation rapide ne convient pas à vos besoins de déploiement ou de topologie.
Configuration requise :
Téléchargez Azure AD Connect.
Effectuez les étapes préalables dans Azure AD Connect : matériel et prérequis.
Assurez-vous de disposer des comptes comme décrit dans Autorisations et comptes Azure AD Connect.
Paramètres de l’installation personnalisée

Pour configurer une installation personnalisée pour Azure AD Connect, consultez les pages de l’Assistant
décrites dans les sections suivantes.
Paramètres Express
Dans la page Paramètres Express , sélectionnez Personnaliser pour démarrer une installation des paramètres
personnalisés. Le reste de cet article vous guide tout au long du processus d’installation personnalisée. Utilisez
les liens suivants pour accéder rapidement aux informations d’une page particulière :
Composants requis
Connexion utilisateur
Connexion à Azure AD
Synchronisation
Installation des composants requis
Lorsque vous installez les services de synchronisation, vous pouvez laisser la section de configuration facultative
de côté. Azure AD Connect configure toutes les options automatiquement. Il configure une instance de base de
données locale SQL Server 2019 Express, crée les groupes appropriés et attribue des autorisations. Si vous
souhaitez modifier les valeurs par défaut, désactivez les cases appropriées. Le tableau ci-dessous résume ces
options et fournit des liens vers des informations supplémentaires.
C O N F IGURAT IO N FA C ULTAT IVE DESC RIP T IO N
Spécifier un emplacement d’installation personnalisé Vous permet de modifier le chemin d’installation par défaut
d’Azure AD Connect.
Utiliser un serveur SQL Server existant Permet de spécifier le nom du serveur SQL et le nom de
l’instance. Choisissez cette option si vous souhaitez utiliser
un serveur de base de données existant. Saisissez le nom de
l’instance dans la zone Nom de l’instance , suivi d’une
virgule et du numéro de port, si la navigation n’est pas
activée sur votre serveur SQL Server. Ensuite, spécifiez le
nom de la base de données Azure AD Connect. Vos
privilèges SQL déterminent si une base de données peut être
créée ou si votre administrateur SQL doit créer la base de
données à l’avance. Si vous disposez d’autorisations
d’administrateur de SQL Server, consultez Installer Azure AD
Connect à l’aide d’une base de données existante. Si vous
avez reçu des autorisations déléguées (DBO), consultez
Installer Azure AD Connect à l’aide d’autorisations
administrateur déléguées SQL.
C O N F IGURAT IO N FA C ULTAT IVE DESC RIP T IO N
Utiliser un compte de service existant Par défaut, Azure AD Connect fournit un compte de service
virtuel pour les services de synchronisation. Si vous utilisez
une instance SQL Server distante ou un proxy qui exige une
authentification, vous pouvez utiliser un compte de service
administré ou un compte de service protégé par mot de
passe au sein du domaine. Dans ce cas, entrez le compte que
vous souhaitez utiliser. Pour exécuter l’installation, vous
devez être un administrateur système dans SQL afin de
pouvoir créer des informations d’identification de connexion
pour le compte de service. Pour en savoir plus, consultez la
page Autorisations et comptes Azure AD Connect.
À l’aide de la version la plus récente, l’administrateur SQL

peut désormais approvisionner la base de données hors
bande. L’administrateur Azure AD Connect peut alors
l’installer avec les droits de propriétaire de la base de
données. Pour plus d’informations, consultez la page Installer
Azure AD Connect à l’aide d’autorisations administrateur
déléguées SQL.
Spécifier des groupes de synchronisation personnalisés Par défaut, lorsque les services de synchronisation sont
installés, Azure AD Connect crée quatre groupes locaux sur
le serveur. Ces groupes sont les Administrateurs, les
Opérateurs, Parcourir et Réinitialisation de mot de passe.
Vous pouvez spécifier vos propres groupes ici. Les groupes
doivent être locaux sur le serveur. Ils ne peuvent pas se
situer dans le domaine.
Importer les paramètres de synchronisation (préversion) Vous permet d’importer des paramètres à partir d’une autre
version d’Azure AD Connect. Pour plus d’informations,
consultez Importer et exporter des paramètres de
configuration Azure AD Connect.
Connexion de l’utilisateur
Après avoir installé les composants requis, sélectionnez la méthode d’authentification unique de vos utilisateurs.
Le tableau suivant décrit brièvement les options disponibles. Pour une description complète des méthodes de
connexion, consultez Connexion de l’utilisateur.
O P T IO N D’A UT H EN T IF IC AT IO N UN IQ UE DESC RIP T IO N
Synchronisation de hachage de mot de passe Les utilisateurs peuvent se connecter aux services cloud
Microsoft, comme Microsoft 365, à l’aide du mot de passe
qu’ils utilisent dans leur réseau local. Les mots de passe
utilisateur sont synchronisés avec Azure AD sous la forme
d’un hachage de mot de passe. L’authentification a lieu dans
le Cloud. Pour plus d’informations, consultez Synchronisation
de hachage de mot de passe.
Authentification directe Les utilisateurs peuvent se connecter aux services cloud

qu’ils utilisent dans leur réseau local. Les mots de passe de
l’utilisateur sont validés en les transmettant vers le
contrôleur de domaine Active Directory local.
Fédération avec AD FS Les utilisateurs peuvent se connecter aux services cloud

qu’ils utilisent dans leur réseau local. Les utilisateurs sont
redirigés vers leur instance ADFS locale pour
l’authentification. L’authentification a lieu localement.
Fédération avec PingFederate Les utilisateurs peuvent se connecter aux services cloud
qu’ils utilisent dans leur réseau local. Ils sont redirigés vers
leur instance PingFederate locale pour la connexion.
L’authentification a lieu localement.
Ne pas configurer Aucune fonctionnalité de connexion utilisateur n’est installée

ou configurée. Choisissez cette option si vous disposez déjà
d’un serveur de fédération tiers ou d’une autre solution.
O P T IO N D’A UT H EN T IF IC AT IO N UN IQ UE DESC RIP T IO N
Activer l’authentification unique Cette option est disponible avec la synchronisation de

hachage de mot de passe et l’authentification directe. Elle
offre une expérience d’authentification unique pour les
utilisateurs de bureau sur des réseaux d’entreprise. Pour plus
d’informations, consultez Authentification unique.
Remarque : Cette option n’est pas disponible pour les

clients AD FS. AD FS offre déjà le même niveau
d’authentification unique.
Se connecter à Azure AD
Sur la page Connexion à Azure AD , entrez un compte et un mot de passe d’administrateur général. Si vous
avez sélectionné l’option Fédération avec AD FS sur la page précédente, ne vous connectez pas avec un
compte dans un domaine que vous envisagez d’activer pour la fédération.
Vous souhaiterez peut-être utiliser un compte du domaine onmicrosoft.com par défaut, qui est fourni avec votre
locataire Azure AD. Ce compte est utilisé uniquement pour créer un compte de service dans Azure AD. Il n’est
pas utilisé une fois l’installation terminée.
Si l’authentification multifacteur est activée sur votre compte d’administrateur général, vous fournissez à
nouveau le mot de passe dans la fenêtre de connexion, et vous devez effectuer le test d’authentification
multifacteur. Ce test peut consister en un code de vérification ou à passer un appel téléphonique.
Privileged Identity Management peut aussi être activé sur le compte d’administrateur global.
Si vous recevez une erreur ou que vous avez des problèmes de connectivité, consultez Résoudre les problèmes
de connectivité liés à Azure AD Connect.
Synchroniser les pages

Les sections suivantes décrivent les pages de la section Sync .
Connexion de vos annuaires
Pour vous connecter aux services de domaine Active Directory (Azure AD DS), Azure AD Connect a besoin du
nom de la forêt et des informations d’identification d’un compte doté d’autorisations suffisantes.
Une fois que vous avez entré le nom de la forêt et sélectionné Ajouter un réper toire , une fenêtre s’affiche. Le
tableau ci-dessous décrit vos options disponibles.
O P T IO N DESC RIP T IO N
Créer un compte Créez le compte Azure AD DS dont Azure AD Connect a

besoin pour se connecter à la forêt Active Directory lors de
la synchronisation d’annuaires. Une fois cette option
sélectionnée, entrez le nom d’utilisateur et le mot de passe
d’un compte d’administrateur d’entreprise. Le compte
d’administrateur d’entreprise fourni est utilisé par Azure AD
Connect pour créer le compte Azure AD DS requis. Vous
pouvez entrer la partie domaine au format NetBIOS ou au
format FQDN. Autrement dit, entrez
FABRIKAM\administrator ou fabrikam.com\administrator.
Utiliser un compte existant Fournissez le compte Azure AD DS existant qu’Azure AD

Connect peut utiliser pour se connecter à la forêt Active
Directory lors de la synchronisation d’annuaires. Vous
pouvez entrer la partie domaine au format NetBIOS ou au
format FQDN. Autrement dit, entrez FABRIKAM\syncuser ou
fabrikam.com\syncuser. Ce compte peut être un compte
d’utilisateur normal, car seules des autorisations de lecture
par défaut sont nécessaires. Toutefois, selon votre scénario,
vous pouvez avoir besoin d’autorisations supplémentaires.
Pour en savoir plus, consultez la page Autorisations et
comptes Azure AD Connect.
NOTE
À partir de la build 1.4.18.0, vous ne pouvez plus utiliser un compte administrateur d’entreprise ou un compte
administrateur de domaine comme compte de connecteur Azure AD DS. Lorsque vous sélectionnez Utiliser un compte
existant , si vous essayez d’entrer un compte d’administrateur d’entreprise ou un compte d’administrateur de domaine,
l’erreur suivante s’affiche : « Using an Enterprise or Domain administrator account for your AD forest account is not
allowed. Let Azure AD Connect create the account for you or specify a synchronization account with the correct
permissions. »
Configuration de connexion AD Azure

Sur la page Configuration de connexion Azure AD , examinez les domaines UPN (User Principal Name) dans
l’Azure AD DS local. Ces domaines UPN ont été vérifiés dans Azure AD. Cette page vous permet également de
configurer l’attribut à utiliser pour userPrincipalName.
Passez en revue chaque domaine marqué comme Non ajouté ou Non vérifié . Assurez-vous que les domaines
que vous utilisez ont été vérifiés dans Azure AD. Une fois vos domaines vérifiés, sélectionnez l’icône
d’actualisation circulaire. Pour plus d’informations, consultez Ajouter et vérifier le domaine.
L'attribut userPrincipalName est utilisé par les utilisateurs lorsqu'ils se connectent à Azure AD et Microsoft 365.
Azure AD doit vérifier les domaines (également nommés « Suffixe UPN ») avant la synchronisation des
utilisateurs. Microsoft vous recommande de conserver la valeur d’attribut userPrincipalName par défaut.
Si l’attribut userPrincipalName n’est pas routable et ne peut pas être vérifié, vous pouvez sélectionner un autre
attribut. Par exemple, vous pouvez choisir une adresse de messagerie électronique comme attribut contenant
l’ID de connexion. Lorsque vous utilisez un attribut autre que userPrincipalName, il s’agit d’un ID secondaire.
La valeur de l’attribut ID secondaire doit suivre la norme RFC 822. Vous pouvez utiliser un ID secondaire avec la
synchronisation de hachage de mot de passe, l’authentification directe et la fédération. Dans Active Directory,
l’attribut ne peut pas être défini en tant que valeurs multiples, même s’il ne possède qu’une seule valeur. Pour
plus d’informations sur l’ID secondaire, consultez Authentification directe : questions fréquentes.
NOTE
Lorsque vous activez l’authentification directe, vous devez disposer d’au moins un domaine vérifié pour pouvoir continuer
l’assistant d’installation personnalisée.
WARNING
Les ID secondaires ne sont pas compatibles avec certaines charges de travail Microsoft 365. Pour plus d’informations,
consultez Configuration d’ID secondaires de connexion.
Filtrage domaine et unité organisationnelle

Par défaut, tous les domaines et unités d’organisation (UO) sont synchronisés. Si vous ne souhaitez pas
synchroniser certains domaines ou UO pour Azure AD, vous pouvez effacer les sélections appropriées.
Cette page configure le filtrage basé sur le domaine et sur les unités d'organisation. Si vous envisagez
d’apporter des modifications, consultez les pages Filtrage par domaine et Filtrage par unité d’organisation.
Certaines unités d’organisation étant essentielles aux fonctionnalités, vous devez les conserver sélectionnées.
Si vous utilisez le filtrage par unité d’organisation avec une version d’Azure AD Connect antérieure à la
version 1.1.524.0, les nouvelles unités d’organisation sont synchronisées par défaut. Si vous ne souhaitez pas
que les nouvelles unités d’organisation soient synchronisées, vous pouvez ajuster le comportement par défaut
après l’étape Filtrage par unité d’organisation. Pour Azure AD Connect 1.1.524.0 ou supérieure, vous pouvez
indiquer si les nouvelles unités d’organisation doivent être synchronisées.
Si vous prévoyez d’utiliser le filtrage basé sur le groupe, assurez-vous que l’unité d’organisation avec le groupe
est incluse, et non filtrée à l’aide du filtrage par unité d’organisation. Le filtrage par unité d’organisation est
évalué avant le filtrage basé sur le groupe.
Il est également possible que certains domaines ne soient pas accessibles en raison de restrictions de pare-feu.
Ces domaines sont désélectionnés par défaut et présentent un avertissement.
S’il s’affiche, vérifiez que ces domaines sont effectivement inaccessibles et que ce message est normal.
Identification unique de vos utilisateurs
Sur la page Identification des utilisateurs , choisissez comment identifier les utilisateurs dans vos annuaires
locaux et comment les identifier à l’aide de l’attribut sourceAnchor.
Sélectionnez la façon dont les utilisateurs doivent être identifiés dans vos répertoires locaux
La fonctionnalité Correspondance entre les forêts vous permet de définir la méthode de représentation des
utilisateurs de vos forêts Azure AD DS dans Azure AD. Il est possible de représenter seulement une fois chaque
utilisateur entre toutes les forêts, ou de présenter une combinaison des comptes activés et désactivés.
L’utilisateur peut également être représenté en tant que contact dans certaines forêts.
PA RA M ÈT RE DESC RIP T IO N
Les utilisateurs ne sont représentés qu’une seule fois à Tous les utilisateurs sont créés en tant qu’objets individuels
travers toutes les forêts dans Azure AD. Les objets ne sont pas associés dans le
métaverse.
Attribut de messagerie Cette option associe des utilisateurs et des contacts si

l’attribut de messagerie a la même valeur dans des forêts
différentes. Utilisez cette option si vos contacts ont été créés
avec GALSync. Si cette option est choisie, les objets
utilisateur dont l’attribut de messagerie n’est pas rempli ne
sont pas synchronisés avec Azure AD.
Attributs ObjectSID et msExchangeMasterAccountSID/ Cette option associe un utilisateur activé dans une forêt de
msRTCSIP-OriginatorSID comptes à un utilisateur désactivé dans une forêt de
ressources. Dans Exchange, cette configuration est connue
en tant que « boîte aux lettres liée ». Vous pouvez utiliser
cette option si vous utilisez uniquement Lync et si Exchange
n’est pas présent dans la forêt de ressources.
Attributs SAMAccountName et MailNickName Cette option associe des attributs où l’ID de connexion est
requis pour rechercher l’utilisateur.
Choisir un attribut spécifique Cette option vous permet de sélectionner votre propre
attribut. Si cette option est choisie, les objets utilisateur dont
l’attribut (sélectionné) n’est pas rempli ne sont pas
synchronisés avec Azure AD. Limitation : Seuls les attributs
qui se trouvent déjà dans le métaverse sont disponibles pour
cette option.
Sélectionnez la façon dont les utilisateurs doivent être identifiés à l’aide d’une ancre source
L’attribut sourceAnchor ne varie pas pendant la durée de vie d’un objet utilisateur. Il s’agit de la clé primaire liant
l’utilisateur local avec l’utilisateur dans Azure AD.
Laisser Azure gérer l'ancre source Sélectionnez cette option si vous souhaitez qu’Azure AD
sélectionne l’attribut pour vous. Si vous sélectionnez cette
option, Azure AD Connect applique la logique de sélection
d’attribut sourceAnchor décrite dans l’article Utilisation de
msDS-ConsistencyGuid en tant que sourceAnchor. Une fois
l’installation personnalisée terminée, vous voyez l’attribut qui
a été sélectionné en tant qu’attribut sourceAnchor.
Choisir un attribut spécifique Sélectionnez cette option si vous souhaitez spécifier un

attribut AD existant comme attribut sourceAnchor.
Étant donné que l’attribut sourceAnchor ne peut pas être modifié, vous devez choisir un attribut approprié. Pour
cela, nous vous recommandons objectGUID. Cet attribut ne change pas, sauf si le compte d’utilisateur est
déplacé entre les forêts ou les domaines. Ne choisissez pas les attributs susceptibles de changer si une personne
se marie ou si son affectation est modifiée.
Vous ne pouvez pas utiliser d’attributs incluant un arobase (@), vous ne pouvez donc pas utiliser l’email et
userPrincipalName. Par ailleurs, l’attribut respecte la casse ; si vous déplacez un objet entre des forêts, veillez à
conserver ses minuscules et majuscules. Les attributs binaires sont codés en base 64, mais les autres types
d’attributs restent à l’état non codé.
Dans les scénarios de fédération et dans certaines interfaces Azure AD, l’attribut sourceAnchor est également
appelé immutableID.
Vous trouverez plus d’informations sur l’ancre source dans l’article Principes de conception.
Filtrage de synchronisation basé sur les groupes
Le filtrage sur la fonctionnalité de groupes vous permet de synchroniser uniquement un petit sous-ensemble
d’objets pour un pilote. Pour pouvoir utiliser cette fonctionnalité, créez un groupe à cette fin dans votre instance
locale d’Active Directory. Ensuite, ajoutez les utilisateurs et groupes qui doivent être synchronisés sur Azure AD
en tant que membres directs. Vous pouvez ajouter et supprimer ultérieurement des utilisateurs à ce groupe
pour tenir à jour la liste des objets présents dans Azure AD.
Les objets que vous voulez synchroniser doivent tous être des membres directs du groupe. Les utilisateurs, les
groupes, les contacts ou les ordinateurs/appareils doivent tous être des membres directs. L’appartenance à un
groupe imbriqué n’est pas résolue. Lorsque vous ajoutez un groupe en tant que membre, seul le groupe est
ajouté. Ses membres ne le sont pas.
WARNING
Cette fonctionnalité est uniquement destinée à prendre en charge un déploiement pilote. Ne l’utilisez pas dans un
environnement de production complet.
Dans un déploiement de production complet, il serait difficile de maintenir un seul groupe et tous les objets à
synchroniser. À la place de la fonctionnalité de filtrage par groupe, utilisez l’une des méthodes décrites dans
Configurer le filtrage.
Fonctionnalités facultatives
Sur la page suivante, vous pouvez sélectionner des fonctionnalités facultatives pour votre scénario.
WARNING
Les versions d’Azure AD Connect 1.0.8641.0 et antérieures s’appuient sur Azure Access Control Service pour la réécriture
du mot de passe. Ce service a été supprimé le 7 novembre 2018. Si vous utilisez l’une de ces versions d’Azure AD Connect
et que vous avez activé la réécriture du mot de passe, il est possible que les utilisateurs ne puissent plus modifier ou
réinitialiser leurs mots de passe une fois le service supprimé. Ces versions d’Azure AD Connect ne prennent pas en charge
la réécriture du mot de passe.
Pour plus d’informations, consultez Migrer à partir d’Azure Access Control Service.
Si vous souhaitez utiliser la réécriture du mot de passe, téléchargez la dernière version d’Azure AD Connect.
WARNING
Si Azure AD Sync ou la synchronisation directe (DirSync) est activé, n’activez pas les fonctionnalités de réécriture dans
Azure AD Connect.
F O N C T IO N N A L IT ÉS FA C ULTAT IVES DESC RIP T IO N
Déploiement Exchange hybride La fonctionnalité de déploiement Exchange hybride permet

la coexistence de boîtes aux lettres Exchange en local et dans
Microsoft 365. Azure AD Connect synchronise un ensemble
spécifique d’attributs d’Azure AD dans votre annuaire local.
Dossiers publics de messagerie Exchange La fonctionnalité Dossiers publics de messagerie Exchange

vous permet de synchroniser les objets Dossier public à
extension messagerie de votre instance Active Directory
locale avec Azure AD.
Application Azure AD et filtrage des attributs En activant le filtrage des attributs et l’application Azure AD,
vous pouvez adapter l’ensemble des attributs synchronisés.
Cette option ajoute deux autres pages de configuration dans
l’Assistant. Pour en savoir plus, voir Application Azure AD et
filtrage des attributs.
F O N C T IO N N A L IT ÉS FA C ULTAT IVES DESC RIP T IO N
Synchronisation de hachage de mot de passe Si vous avez sélectionné la fédération comme solution de
connexion, vous pouvez activer la synchronisation de
hachage de mot de passe. Vous pouvez ensuite l’utiliser
comme option de sauvegarde.
Si vous avez sélectionné l’authentification directe, vous

pouvez activer cette option pour assurer la prise en charge
pour les clients hérités et permettre une sauvegarde.
Pour plus d’informations, consultez Synchronisation de

hachage de mot de passe.
Réécriture du mot de passe Utilisez cette option pour vous assurer que les modifications
de mot de passe provenant d’Azure AD sont réécrites dans
votre répertoire local. Pour en savoir plus, voir Prise en main
de la gestion de mot de passe.
Écriture différée de groupe Si vous utilisez des groupes de Microsoft 365, vous pouvez
représenter des groupes dans votre instance locale de Active
Directory. Cette option est disponible uniquement si
Exchange est présent dans votre instance Active Directory
locale. Pour plus d’informations, consultez Réécriture de
groupe Azure AD Connect.
Écriture différée des appareils Permet d’écrire de façon différée des objets d’appareil dans
Azure AD, au sein de l’instance Active Directory locale, dans
le cadre de scénarios à accès conditionnel. Pour en savoir
plus, voir Azure AD Connect : Activation de l’écriture différée
des appareils.
Synchronisation des attributs des extensions d’annuaire Sélectionnez cette option pour synchroniser les attributs
spécifiés avec Azure AD. Pour en savoir plus, voir Extensions
d’annuaire.
Application Azure AD et filtrage des attributs

Si vous souhaitez limiter les attributs à synchroniser dans Azure AD, commencez par sélectionner les services
que vous utilisez. Si vous modifiez les sélections dans cette page, vous devez sélectionner explicitement un
nouveau service en réexécutant l’assistant d’installation.
Selon les services sélectionnés à l’étape précédente, cette page affiche tous les attributs synchronisés. Cette liste
est une combinaison de tous les types d’objet en cours de synchronisation. Si vous avez besoin que certains
attributs ne soient pas synchronisés, vous pouvez effacer leur sélection.
WARNING
La suppression d’attributs peut affecter la fonctionnalité. Pour consulter des recommandations et meilleures pratiques, voir
Attributs à synchroniser.
Synchronisation des attributs des extensions d’annuaire

Vous pouvez étendre le schéma dans Azure AD en utilisant des attributs personnalisés ajoutés par votre
organisation ou d’autres attributs dans Active Directory. Pour utiliser cette fonctionnalité, sélectionnez
Synchronisation des attributs des extensions d’annuaire dans la page Fonctionnalités facultatives .
Sur la page Extensions d’annuaire , vous pouvez sélectionner d’autres attributs à synchroniser.
NOTE
La zone Attributs disponibles respecte la casse.
Pour en savoir plus, voir Extensions d’annuaire.

Activation de l'authentification unique
Sur la page Authentification unique , vous configurez l’authentification unique pour une utilisation avec la
synchronisation de mot de passe ou l’authentification directe. Vous effectuez cette étape une fois pour chaque
forêt synchronisée avec Azure AD. La configuration implique deux étapes :
1. création du compte d’ordinateur nécessaire dans votre instance Active Directory locale.
2. configuration de la zone intranet des ordinateurs clients pour prendre en charge l’authentification unique.
Créer le compte d’ordinateur dans Active Directory
Pour chaque forêt ajoutée à l’aide d’Azure AD Connect, vous devez fournir les informations d’identification de
l’administrateur de domaine afin que le compte d’ordinateur puisse être créé dans chaque forêt. Les
informations d'identification sont uniquement utilisées pour créer le compte. Elles ne sont pas stockées ou
utilisées pour une autre opération. Ajoutez les informations d’identification sur la page Activer
l’authentification unique , comme le montre l’image suivante.
NOTE
Vous pouvez ignorer les forêts pour lesquelles vous ne souhaitez pas utiliser l’authentification unique.
Configurer la zone intranet pour les ordinateurs clients

Pour que le client se connecte automatiquement dans la zone intranet, vérifiez que l’URL fait partie de celle-ci.
Cela garantit que l’ordinateur joint au domaine envoie automatiquement un ticket Kerberos à Azure AD lorsqu’il
est connecté au réseau d’entreprise.
Sur un ordinateur qui possède les outils de gestion de stratégie de groupe :
1. Ouvrez les outils de gestion de stratégie de groupe.
2. Modifiez la stratégie de groupe qui sera appliquée à tous les utilisateurs. Par exemple, la stratégie de
domaine par défaut.
3. Accédez à Configuration utilisateur > Modèles d'administration > Composants Windows >
Internet Explorer > Panneau de configuration Internet > Page Sécurité . Puis sélectionnez Liste
des attributions de sites aux zones .
4. Activez la stratégie. Puis dans la boîte de dialogue, entrez le nom de valeur de
https://autologon.microsoftazuread-sso.com et la valeur de 1 . Votre configuration doit ressembler à
l’image suivante.
5. Sélectionnez OK deux fois.
Configuration de la fédération avec AD FS

Vous pouvez configurer AD FS avec Azure AD Connect en quelques clics. Avant de commencer, vous devez :
Windows Server 2012 R2 ou une version ultérieure pour le serveur de fédération. La gestion à distance doit
être activée.
Windows Server 2012 R2 ou une version ultérieure pour le serveur proxy d’application web. La gestion à
distance doit être activée.
Un certificat TLS/SSL pour le nom de service de fédération que vous prévoyez d’utiliser (par exemple,
sts.contoso.com).
NOTE
Vous pouvez mettre à jour le certificat TLS/SSL de la batterie de serveurs AD FS à l’aide du logiciel Azure AD Connect et
ce, même si vous ne l’utilisez pas pour gérer l’approbation de votre fédération.
Conditions préalables à la configuration AD FS

Pour configurer votre batterie AD FS avec Azure AD Connect, vérifiez que WinRM est activé sur les serveurs
distants. Vérifiez que vous avez effectué les autres tâches dans les conditions préalables de la fédération. Veillez
également à suivre les exigences des ports répertoriées dans le tableau Azure AD Connect et serveurs de
Fédération/WAP.
Création d’une batterie de serveurs AD FS ou utilisation d’une batterie de serveurs AD FS existante
Vous pouvez utiliser une batterie de serveurs AD FS ou en créer une nouvelle. Si vous choisissez de créer une
batterie de serveurs, vous devez fournir le certificat TLS/SSL. Si ce dernier est protégé par un mot de passe, vous
êtes invité à entrer ce mot de passe.
Si vous choisissez d’utiliser une batterie de serveurs AD FS existante, vous voyez la page sur laquelle vous
pouvez configurer la relation d’approbation entre AD FS et Azure AD.
NOTE
Vous pouvez utiliser Azure AD Connect pour gérer une seule batterie de serveurs AD FS. Si vous disposez d’une
approbation de fédération où Azure AD est configuré sur la batterie de serveurs AD FS sélectionnée, Azure AD Connect
recrée l’approbation à partir de zéro.
Spécification des serveurs AD FS

Spécifiez les serveurs sur lesquels vous souhaitez installer AD FS. Vous pouvez ajouter un ou plusieurs serveurs
selon vos besoins de capacité. Avant la configuration, joignez tous les serveurs AD FS à Active Directory. Cette
étape n’est pas requise pour les serveurs proxy d’application Web.
Microsoft recommande d’installer un seul serveur AD FS pour les déploiements de test et pilote. Ensuite, ajoutez
et déployez d’autres serveurs pour répondre à vos besoins de mise à l’échelle en réexécutant Azure AD Connect
après la configuration initiale.
NOTE
Avant d’effectuer cette configuration, assurez-vous que tous les serveurs sont joints à un domaine Active Directory.
Spécification des serveurs proxy d’application web
Spécifiez vos serveurs proxy d’application web. Le serveur proxy d’application Web est déployé dans votre
réseau de périmètre, face à l’extranet. Il prend en charge les demandes d’authentification provenant de l’extranet.
Vous pouvez ajouter un ou plusieurs serveurs selon vos besoins de capacité.
Microsoft recommande d’installer un serveur proxy d’application web unique pour un déploiement de test ou
pilote. Ensuite, ajoutez et déployez d’autres serveurs pour répondre à vos besoins de mise à l’échelle en
réexécutant Azure AD Connect après la configuration initiale. Nous vous recommandons de prévoir un nombre
suffisant de serveurs proxy pour répondre aux demandes d’authentification à partir de l’intranet.
NOTE
Si le compte que vous utilisez n’est pas un compte d’administrateur local sur les serveurs proxy d'application web, vous
êtes invité à saisir les informations d’identification de l’administrateur.
Vérifiez la connectivité HTTP/HTTPS entre le serveur Azure AD Connect et le serveur proxy d’application web avant de
spécifier les serveurs proxy d'application web.
Assurez-vous qu’il existe une connectivité HTTP/HTTPS entre le serveur d’applications web et le serveur AD FS pour
autoriser les transmissions de demandes d’authentification.
Vous êtes invité à saisir des informations d’identification afin que le serveur d’application web puisse établir une
connexion sécurisée avec le serveur AD FS. Ces informations d’identification doivent être destinées à un compte
d’administrateur local sur le serveur AD FS.
Spécification du compte de service pour le service AD FS

Le service AD FS requiert un compte de service de domaine pour authentifier les utilisateurs et rechercher les
informations utilisateur dans Active Directory. Il prend en charge 2 types de compte de service :
Compte de ser vice géré de groupe : Ce type de compte a été introduit dans AD DS par Windows Server
2012. Ce type de compte fournit des services tels que AD FS. Il s’agit d’un compte unique dans lequel vous
n’avez pas besoin de mettre à jour le mot de passe régulièrement. Utilisez cette option s’il existe déjà des
contrôleurs de domaine Windows Server 2012 dans le domaine auquel appartiennent vos serveurs AD FS.
Compte d’utilisateur de domaine : Ce type de compte vous oblige à fournir un mot de passe et à le
mettre à jour régulièrement lorsqu’il expire. Utilisez cette option uniquement s’il n’y a aucun contrôleur de
domaine Windows Server 2012 dans le domaine auquel appartiennent vos serveurs AD FS.
Si vous avez sélectionné Créer un compte de ser vice géré de groupe et que cette fonctionnalité n’a jamais
été utilisée dans Active Directory, saisissez des informations d’identification d’administrateur d’entreprise. Ces
informations serviront à initialiser le magasin de clés et à activer la fonctionnalité dans Active Directory.
NOTE
Azure AD Connect vérifie si le service AD FS est déjà inscrit en tant que nom du principal de service (SPN) dans le
domaine. Azure AD DS n’autorise pas l’inscription de SPN en double en même temps. Si un SPN en double est trouvé,
vous ne pouvez pas poursuivre l’opération avant de l’avoir supprimé.
Sélection du domaine Azure AD à fédérer

Utilisez la page Domaine Azure AD pour configurer la relation de fédération entre AD FS et Azure AD. Ici, vous
configurez AD FS pour fournir des jetons de sécurité à Azure AD. Vous configurez également Azure AD pour
approuver les jetons de cette instance de AD FS.
Cette page vous permet de configurer un seul domaine durant l’installation initiale. Vous pouvez configurer
ultérieurement des domaines supplémentaires en réexécutant Azure AD Connect.
Vérification du domaine Azure AD sélectionné pour la fédération
Lorsque vous sélectionnez le domaine que vous souhaitez fédérer, Azure AD Connect vous fournit les
informations que vous pouvez utiliser pour vérifier un domaine non vérifié. Pour plus d’informations, consultez
Ajouter et vérifier le domaine.
NOTE
Azure AD Connect tente de vérifier le domaine pendant l’étape de configuration. Si vous n’ajoutez pas les enregistrements
DNS (Domain Name System) nécessaires, la configuration ne peut pas être effectuée.
Configuration de la fédération avec PingFederate

Vous pouvez configurer PingFederate avec Azure AD Connect en quelques clics. Les prérequis suivants sont
obligatoires :
PingFederate 8.4 ou version ultérieure. Pour plus d’informations, consultez Intégration de PingFederate à
Azure Active Directory et Microsoft 365.
Un certificat TLS/SSL pour le nom de service de fédération que vous prévoyez d’utiliser (par exemple,
sts.contoso.com).
Vérifier le domaine
Après avoir choisi de configurer la fédération avec PingFederate, vous êtes invité à vérifier le domaine que vous
voulez fédérer. Sélectionnez le domaine dans le menu déroulant.
Exporter les paramètres PingFederate

Configurez PingFederate en tant que serveur de fédération pour chaque domaine Azure fédéré. Sélectionnez
Paramètres d’expor tation pour partager ces informations avec votre administrateur PingFederate.
L’administrateur du serveur de fédération met à jour la configuration, puis fournit l’URL et le numéro de port du
serveur PingFederate pour qu’Azure AD Connect puisse vérifier les paramètres de métadonnées.
Contactez votre administrateur PingFederate pour résoudre les éventuels problèmes de validation. Voici une
image montrant des informations concernant un serveur PingFederate qui n’a pas de relation d’approbation
valide avec Azure.
Vérifier la connectivité de fédération

Azure AD Connect tente de valider les points de terminaison d’authentification récupérés à partir des
métadonnées PingFederate de l’étape précédente. Azure AD Connect tente d’abord de résoudre les points de
terminaison à l’aide de vos serveurs DNS locaux. Ensuite, une tentative de résolution des points de terminaison
à l’aide d’un fournisseur DNS externe est effectuée. Contactez votre administrateur PingFederate pour résoudre
les éventuels problèmes de validation.
Vérifiez la connexion de fédération

Enfin, vous pouvez vérifier le flux de connexion fédérée tout juste configuré en vous connectant au domaine
fédéré. Si votre connexion réussit, la fédération avec PingFederate est correctement configurée.
Pages de configuration et de vérification
La configuration se produit sur la page Configurer .
NOTE
Avant de poursuivre l’installation, si vous avez configuré la fédération, vérifiez que vous avez configuré la Résolution de
noms pour les serveurs de fédération.
Utiliser le mode intermédiaire

Vous pouvez configurer un nouveau serveur de synchronisation en parallèle avec le mode intermédiaire. Si vous
souhaitez utiliser ce programme d’installation, un seul serveur de synchronisation peut s’exporter vers un
répertoire dans le cloud. Mais si vous voulez procéder à un déplacement à partir d’un autre serveur (par
exemple, un serveur exécutant DirSync), vous pouvez activer Azure AD Connect en mode intermédiaire.
Lorsque vous activez le programme d’installation intermédiaire, le moteur de synchronisation importe et
synchronise les données normalement. Mais il n’exporte aucune donnée vers Azure AD ou Active Directory. En
mode intermédiaire, les fonctionnalités de synchronisation/de réécriture du mot de passe sont désactivées.
En mode intermédiaire, vous pouvez modifier le moteur de synchronisation selon vos besoins et examiner ce
qui doit être exporté. Lorsque la configuration vous convient, réexécutez l’Assistant Installation et désactivez le
mode intermédiaire.
Les données sont désormais exportées vers Azure AD à partir de ce serveur. Veillez à désactiver l’autre serveur
en même temps, pour qu’un seul serveur puisse exporter de manière active.
Pour en savoir plus, voir Mode intermédiaire.
Vérification de votre configuration de fédération
Lorsque vous cliquez sur le bouton Vérifier , Azure AD Connect vérifie la configuration DNS. Les paramètres
suivants sont vérifiés :
Connectivité intranet
Résoudre le nom de domaine complet de fédération : Azure AD Connect vérifie si le nom de domaine
complet de fédération peut être résolu par DNS pour garantir la connectivité. Si Azure AD Connect ne
peut pas résoudre le nom de domaine complet, la vérification échoue. Vérifiez qu’un enregistrement
DNS est présent pour le nom de domaine complet du service de fédération, afin que la vérification
puisse être menée à bien.
Enregistrement A DNS : Azure AD Connect vérifie s’il existe un enregistrement A pour votre service de
fédération. En l’absence d’enregistrement A, la vérification échoue. Créez un enregistrement A plutôt
qu’un enregistrement CNAME pour votre nom de domaine complet de fédération afin de mener à
bien la vérification.
Connectivité extranet
Résoudre le nom de domaine complet de fédération : Azure AD Connect vérifie si le nom de
domaine complet de fédération peut être résolu par DNS pour garantir la connectivité.
Pour valider l’authentification de bout en bout, vous devez effectuer manuellement un ou plusieurs des tests
suivants :
Une fois la synchronisation terminée, dans Azure AD Connect, utilisez la tâche supplémentaire Vérifier la
connexion fédérée pour vérifier l’authentification d’un compte d’utilisateur local de votre choix.
Vérifiez que vous pouvez vous connecter avec un navigateur à partir d’une machine jointe au domaine sur
l’intranet. Se connecter à https://myapps.microsoft.com. Utilisez ensuite votre compte connecté pour vérifier
la connexion. Le compte d’administrateur Azure AD DS intégré n’est pas synchronisé et ne peut pas être
utilisé pour la vérification.
Vérifiez que vous pouvez vous connecter à partir d’un appareil, depuis l’extranet. Sur un ordinateur personnel
ou un appareil mobile, connectez-vous à https://myapps.microsoft.com. Fournissez ensuite vos informations
d’identification.
Valider la connexion à un client complet. Se connecter à https://testconnectivity.microsoft.com. Ensuite,
sélectionnez Office 365 > Test d’authentification unique Office 365 .
Dépanner
Cette section contient des informations de dépannage que vous pouvez utiliser si vous rencontrez un problème
lors de l’installation d’Azure AD Connect.
Lorsque vous personnalisez une installation d’Azure AD Connect, sur la page Installer les composants
requis , vous pouvez sélectionner Utiliser un ser veur SQL existant . L’erreur suivante peut s’afficher : « The
ADSync database already contains data and cannot be overwritten » (La base de données ADSync contient déjà
des données et ne peut pas être écrasée). Please remove the existing database and try again. (La base de
données ADSync contient déjà des données et ne peut pas être écrasée. Veuillez supprimer la base de données
existante et réessayer.) »
Vous voyez cette erreur, car une base de données nommée ADSync existe déjà sur l’instance SQL du serveur
SQL que vous avez spécifiée.
Cette erreur survient généralement après avoir désinstallé Azure AD Connect. La base de données n’est pas
supprimée de l’ordinateur qui exécute le serveur SQL lorsque vous désinstallez Azure AD Connect.
Pour corriger ce problème :
1. Vérifiez la base de données ADSync utilisée par Azure AD Connect avant sa désinstallation. Assurez-vous
que la base de données n’est plus utilisée.
2. Sauvegardez la base de données.
3. Supprimer la base de données :
a. Utilisez Microsoft SQL Ser ver Management Studio pour vous connecter à une instance SQL.
b. Recherchez la base de données ADSync et cliquez dessus avec le bouton droit.
c. Dans le menu contextuel, sélectionnez Supprimer .
d. Sélectionnez OK pour supprimer la base de données.
Après avoir supprimé la base de données ADSync, sélectionnez Installer pour tenter à nouveau l’installation.
Étapes suivantes
Une fois l’installation terminée, déconnectez-vous de Windows. Reconnectez-vous à Windows avant d’utiliser le
gestionnaire Synchronization Service Manager ou l’éditeur de règles de synchronisation.
Pour plus d’informations sur les fonctionnalités que vous avez activées pendant l’installation, consultez Prévenir
les suppressions accidentelles et Azure AD Connect Health.
Pour plus d’informations sur les autres rubriques courantes, consultez Azure AD Connect Sync : Scheduler et
Intégrer vos identités locales à Azure AD.
Importer et exporter des paramètres de
configuration Azure AD Connect
Les déploiements Azure Active Directory (Azure AD) Connect varient d’une installation de forêt unique en mode
Express à des déploiements complexes qui se synchronisent sur plusieurs forêts à l’aide de règles de
synchronisation personnalisées. En raison du grand nombre d’options et de mécanismes de configuration, il
apparaît essentiel de comprendre les paramètres actifs et de pouvoir déployer rapidement un serveur avec une
configuration identique. Cette fonctionnalité introduit la possibilité de cataloguer la configuration d’un serveur
de synchronisation donné et d’importer les paramètres dans un nouveau déploiement. Différents instantanés de
paramètres de synchronisation peuvent être comparés afin de visualiser facilement les différences entre deux
serveurs ou le même serveur au fil du temps.
Chaque fois que la configuration est modifiée à partir de l’Assistant Azure AD Connect, un nouveau fichier de
paramètres JSON horodaté est automatiquement exporté vers %ProgramData%\AADConnect . Le nom de
fichier des paramètres se présente sous la forme Applied-SynchronizationPolicy-*.JSON où la dernière
partie de ce nom correspond à un timestamp.
IMPORTANT
Seules les modifications apportées par Azure AD Connect sont automatiquement exportées. Toutes les modifications
apportées à l’aide de PowerShell, de Synchronization Service Manager ou de l’éditeur de règles de synchronisation doivent
être exportées à la demande, si nécessaire, pour conserver une copie à jour. L’exportation à la demande peut également
être utilisée pour placer une copie des paramètres dans un emplacement sécurisé à des fins de récupération d’urgence.
Exporter les paramètres d'Azure AD Connect

Pour afficher un résumé de vos paramètres de configuration, ouvrez l’outil Azure AD Connect et sélectionnez la
tâche supplémentaire nommée Afficher ou Expor ter la configuration actuelle . Un résumé rapide de vos
paramètres s’affiche, de même que la possibilité d’exporter la configuration complète de votre serveur.
Par défaut, les paramètres sont exportés vers %ProgramData%\AADConnect . Vous pouvez également choisir
d’enregistrer les paramètres dans un emplacement protégé pour garantir la disponibilité en cas de sinistre. Les
paramètres sont exportés à l’aide du format de fichier JSON et ne doivent pas être créés ou modifiés à des fins
de cohérence logique. L’importation d’un fichier créé à la main ou modifié n’est pas prise en charge et peut
entraîner des résultats inattendus.
Importer les paramètres d'Azure AD Connect

Pour importer des paramètres précédemment exportés :
1. Installez Azure AD Connect sur un nouveau serveur.
2. Sélectionnez l’option Personnaliser après la page d’Accueil .
3. Cliquez sur Impor ter les paramètres de synchronisation . Recherchez le fichier de paramètres JSON
précédemment exporté.
4. Sélectionnez Installer .
NOTE
Remplacez les paramètres de cette page, comme l’utilisation de SQL Server plutôt que la base de données locale ou
l’utilisation d’un compte de service existant plutôt que l’attribut VSA par défaut. Ces paramètres ne sont pas importés à
partir du fichier de paramètres de configuration. Ils sont destinés à des fins de comparaison et d’information.
NOTE
Il n’est pas possible de modifier le fichier JSON exporté pour modifier la configuration.
Expérience d’importation de l’installation

L’expérience d’importation de l’installation est intentionnellement simple avec des entrées minimales de
l’utilisateur afin de facilement reproduire un serveur existant.
Voici les seules modifications qui peuvent être apportées lors de l’expérience d’installation. Toutes les autres
modifications peuvent être apportées après l’installation à partir de l’Assistant Azure AD Connect :
Informations d’identification Azure Active Director y : Le nom de compte de l’administrateur général
Azure utilisé pour configurer le serveur d’origine est suggéré par défaut. Il doitêtre modifié si vous souhaitez
synchroniser les informations dans un nouveau répertoire.
Connexion utilisateur : Les options de connexion configurées pour votre serveur d’origine sont
sélectionnées par défaut et demandent automatiquement les informations d’identification ou d’autres
informations requises lors de la configuration. Dans de rares cas, il peut s’avérer nécessaire de configurer un
serveur avec différentes options pour ne pas modifier le comportement du serveur actif. Sinon, appuyez
simplement sur Suivant pour utiliser les mêmes paramètres.
Informations d’identification du réper toire local : Pour chaque répertoire local inclus dans vos
paramètres de synchronisation, vous devez fournir des informations d’identification afin de créer un compte
de synchronisation ou fournir un compte de synchronisation personnalisé créé préalablement. Cette
procédure est identique à l’expérience de nouvelle installation à cette exception près : vous ne pouvez pas
ajouter ou supprimer de répertoires.
Options de configuration : Comme pour une nouvelle installation, vous pouvez choisir de configurer les
paramètres initiaux pour déterminer s’il faut démarrer la synchronisation automatique ou activer le mode de
préproduction. La principale différence réside dans le fait que le mode de préproduction est
intentionnellement activé par défaut pour permettre la comparaison des résultats de configuration et de
synchronisation avant d’exporter activement les résultats vers Azure.
NOTE
Un seul serveur de synchronisation peut remplir le rôle principal et exporter activement les modifications de configuration
vers Azure. Tous les autres serveurs doivent être placés en mode de préproduction.
Migrer les paramètres à partir d'un serveur existant

Si un serveur existant ne prend pas en charge la gestion des paramètres, vous pouvez choisir de mettre à niveau
le serveur sur place ou de migrer les paramètres à utiliser vers un nouveau serveur de préproduction.
La migration requiert l’exécution d’un script PowerShell qui extrait les paramètres existants à utiliser dans une
nouvelle installation.Cette méthode est recommandée pour cataloguer les paramètres de votre serveur existant,
puis les appliquer à un serveur de préproduction nouvellement installé.La comparaison des paramètres du
serveur d’origine avec le serveur nouvellement créé permet de visualiser rapidement les modifications entre les
serveurs.Comme toujours, suivez le processus de certification de votre organisation pour vous assurer
qu’aucune configuration supplémentaire ne s’impose.
Processus de migration
Pour migrer les paramètres :
1. Lancez AzureADConnect.msi sur le nouveau serveur intermédiaire et arrêtez-vous sur la page
d’accueil d’Azure AD Connect.
2. Copiez MigrateSettings.ps1 à partir du répertoire Microsoft Azure AD Connect\Tools vers un
emplacement du serveur existant. Un exemple est C:\setup, où setup correspond à un répertoire créé sur
le serveur existant.
NOTE
Si le message suivant s’affiche : « Impossible de trouver un paramètre positionnel qui accepte l’argument True . » :
Modifiez
ensuite le fichier MigrateSettings.ps1 et supprimez $true , puis exécutez le script :
3. Exécutez le script comme indiqué ci-dessous et enregistrez l’intégralité du répertoire de configuration de

serveur de niveau inférieur. Copiez ce répertoire sur le nouveau serveur de préproduction. Notez que
vous devez copier l’intégralité du dossier Expor ted-Ser verConfiguration- * sur le nouveau serveur.
4. Lancez Azure AD Connect en double-cliquant sur l’icône du bureau. Acceptez les termes du contrat de
licence logiciel Microsoft, puis sur la page suivante, sélectionnez Personnaliser .
5. Cliquez sur la case à cocher Impor ter les paramètres de synchronisation . Sélectionnez Parcourir
pour parcourir le dossier Exported-ServerConfiguration-* copié. Sélectionnez le MigratedPolicy. json pour
importer les paramètres migrés.
Vérification après l’installation
La comparaison du fichier de paramètres initialement importés avec le fichier de paramètres exportés du
serveur nouvellement déployé est une étape essentielle pour comprendre les différences entre le déploiement
prévu et le déploiement obtenu. L’utilisation de votre application de comparaison de texte favorite côte à côte
offre une visualisation instantanée qui met rapidement en évidence les modifications souhaitées ou
accidentelles.
Si de nombreuses étapes de configuration manuelles sont désormais évitées, vous devez systématiquement
suivre le processus de certification de votre organisation pour vous assurer qu’aucune configuration
supplémentaire ne s’impose. Une telle configuration peut intervenir si vous utilisez des paramètres avancés non
capturés dans cette mise en production de la gestion des paramètres.
Voici quelques limitations connues :
Règles de synchronisation : La priorité d’une règle personnalisée doit être comprise dans la plage
réservée 0 pour éviter les conflits avec les règles standard de Microsoft. Le placement d’une règle
personnalisée en dehors de la plage réservée peut se traduire par un décalage de votre règle personnalisée
au fur et à mesure que des règles standard sont ajoutées à la configuration. Un problème similaire se produit
si votre configuration contient des règles standard modifiées. La modification d’une règle standard est
vivement déconseillée et l’emplacement de la règle est susceptible d’être incorrect.
Réécriture d’appareil : Ces paramètres sont catalogués. Ils ne sont actuellement pas appliqués pendant la
configuration. Si la réécriture d'appareil a été activée pour votre serveur d’origine, vous devez configurer
manuellement cette fonctionnalité sur le serveur nouvellement déployé.
Types d’objets synchronisés : Bien qu’il soit possible de limiter la liste des types d’objets synchronisés
(utilisateurs, contacts, groupes, etc.) à l’aide de Synchronization Service Manager, cette fonctionnalité n’est
actuellement pas prise en charge via les paramètres de synchronisation. Une fois l’installation terminée, vous
devez réappliquer manuellement la configuration avancée.
Profils d'exécution personnalisés : Ben qu’il soit possible de modifier l’ensemble des profils d’exécution
par défaut à l’aide de Synchronization Service Manager, cette fonctionnalité n’est actuellement pas prise en
charge via les paramètres de synchronisation. Une fois l’installation terminée, vous devez réappliquer
manuellement la configuration avancée.
Configurer la hiérarchie de l’approvisionnement : Cette fonctionnalité avancée du Synchronization
Service Manager n’est pas prise en charge via les paramètres de synchronisation. Elle doit être reconfigurée
manuellement une fois le déploiement initial terminé.
Authentification SSRS à l'aide des ser vices de fédération Active Director y (AD FS) et
PingFederate : Les méthodes de connexion associées à ces fonctionnalités d’authentification sont
automatiquement présélectionnées. Vous devez fournir de manière interactive tous les autres paramètres de
configuration requis.
Une règle de synchronisation personnalisée désactivée sera impor tée comme activée : Une règle
de synchronisation personnalisée désactivée sera importée comme activée. Veillez à la désactiver également
sur le nouveau serveur.
Étapes suivantes
Paramètres Express
Démarrage rapide
Déployer l’authentification directe Azure AD

L’authentification directe Azure Active Directory (Azure AD) permet à vos utilisateurs de se connecter aux
applications sur site et aux applications cloud à l’aide des mêmes mots de passe. L'authentification directe
connecte les utilisateurs en validant leurs mots de passe directement par rapport à l'annuaire Active Directory
sur site.
IMPORTANT
Si vous procédez à une migration depuis AD FS (ou d’autres technologies de fédération) vers l’authentification directe,
nous vous recommandons vivement de vous référer à notre guide de déploiement détaillé, publié ici.
NOTE
Si vous déployez l’authentification directe avec le cloud Azure Government, consultez Considérations sur les identités
hybrides pour Azure Government.
Suivez ces instructions pour déployer l’authentification directe sur votre locataire :
Étape 1 : Vérifier les prérequis

Vérifiez que les prérequis suivants sont remplis.
IMPORTANT
Du point de vue de la sécurité, les administrateurs doivent traiter le serveur exécutant l’agent PTA comme s’il s’agissait
d’un contrôleur de domaine. Les serveurs d’agent PTA doivent être renforcés de la même manière que décrit dans
Sécurisation des contrôleurs de domaine contre les attaques
Dans le Centre d’administration Azure Active Directory

1. Créez un compte d’administrateur général « cloud uniquement » dans votre locataire Azure AD. De cette
façon, vous pouvez gérer la configuration de votre locataire si vos services locaux venaient à échouer ou ne
plus être disponibles. Découvrez comment ajouter un compte d’administrateur général de type cloud
uniquement. Cette étape est essentielle si vous voulez éviter de vous retrouver en dehors de votre locataire.
2. Ajoutez un ou plusieurs noms de domaine personnalisés à votre locataire Azure AD. Vos utilisateurs peuvent
se connecter à l’aide de l’un de ces noms de domaine.
Dans votre environnement local
1. Identifiez un serveur Windows Server 2016 ou ultérieur sur lequel exécuter Azure AD Connect. Le cas
échéant, activez TLS 1.2 sur le serveur. Ajoutez ce serveur à la même forêt Active Directory que celle des
utilisateurs dont vous devez valider les mots de passe. Notez que l’installation de l’agent
d’authentification directe sur les versions Windows Server Core n’est pas prise en charge.
2. Installez la version la plus récente d’Azure AD Connect sur le serveur identifié à l’étape précédente. Si
vous exécutez déjà Azure AD Connect, vérifiez qu’il s’agit de la version 1.1.750.0 ou d’une version
ultérieure.
NOTE
Les versions 1.1.557.0, 1.1.558.0, 1.1.561.0 et 1.1.614.0 d’Azure AD Connect comportent un problème lié à la
synchronisation de hachage de mot de passe. Si vous ne prévoyez pas d’utiliser la synchronisation de hachage de
mot de passe en même temps que l’authentification directe, lisez les Notes de publication Azure AD Connect.
3. Identifiez un ou plusieurs serveurs supplémentaires (exécutant Windows Server 2016 ou version

ultérieure, avec TLS 1.2 activé) sur lesquels vous pouvez exécuter des agents d’authentification
autonomes. Ces serveurs supplémentaires sont nécessaires pour garantir une haute disponibilité des
requêtes de connexion. Ajoutez ces serveurs à la même forêt Active Directory que celle des utilisateurs
dont vous devez valider les mots de passe.
IMPORTANT
Dans les environnements de production, nous vous recommandons l’utilisation d’au moins 3 agents
d’authentification s’exécutant sur votre locataire. Il existe une limite système de 40 agents d’authentification par
client. En tant que bonne pratique, traitez tous les serveurs exécutant des agents d’authentification comme des
systèmes de niveau 0 (voir référence).
4. S’il existe un pare-feu entre vos serveurs et Azure AD, configurez les éléments suivants :
Assurez-vous que les agents d’authentification peuvent effectuer des requêtes sortantes vers
Azure AD sur les ports suivants :
N UM ÉRO DE P O RT UT IL ISAT IO N
80 Télécharge les listes de révocation de certificats lors

de la validation du certificat TLS/SSL
443 Gère toutes les communications sortantes avec le

service
8080 (facultatif) Les agents d’authentification signalent leur état

toutes les dix minutes sur le port 8080 (si le port
443 n’est pas disponible). Cet état est affiché sur le
portail Azure AD. Le port 8080 n’est pas utilisé pour
les connexions utilisateur.
Si votre pare-feu applique les règles en fonction des utilisateurs d’origine, ouvrez ces ports au
trafic provenant des services Windows exécutés en tant que service réseau.
Si votre pare-feu ou proxy vous permet d’ajouter des entrées DNS à une liste d’autorisation,
ajoutez des connexions à *.msappproxy.net et *.ser vicebus.windows.net . Dans le cas
contraire, autorisez l’accès aux plages d’adresses IP du centre de données Azure, qui sont mises à
jour chaque semaine.
Évitez toute forme d’inspection et de terminaison inlined sur les communications TLS sortantes
entre l’agent Azure Passthrough et Point de terminaison Azure.
Si vous avez un proxy HTTP sortant, assurez-vous que cette URL, autologon.microsoftazuread-
sso.com, figure dans la liste d’autorisation. Vous devez spécifier cette URL explicitement, car les
caractères génériques peuvent ne pas être acceptés.
Vos agents d’authentification doivent accéder à login.windows.net et à
login.microsoftonline.net pour l’inscription initiale. Par conséquent, ouvrez également votre
pare-feu pour ces URL.
Pour la validation des certificats, débloquez les URL suivantes : crl3.digicer t.com:80 ,
crl4.digicer t.com:80 , ocsp.digicer t.com:80 , www.d-trust.net:80 , root-c3-ca2-
2009.ocsp.d-trust.net:80 , crl.microsoft.com:80 , oneocsp.microsoft.com:80 et
ocsp.msocsp.com:80 . Ces URL étant utilisées pour la validation de certificat avec d’autres
produits Microsoft, elles sont peut-être déjà débloquées.
Cloud Azure Government - Prérequis
Avant d'activer l'authentification directe via Azure AD Connect à l'étape 2, téléchargez la dernière version de
l'agent PTA à partir du portail Azure. Vous devez vous assurer que vous disposez de la version 1.5.1742.0. ou
version ultérieure. Pour vérifier votre agent, consultez Mettre à niveau les agents d'authentification.
Après avoir téléchargé la dernière version de l'agent, suivez les instructions ci-dessous pour configurer
l'authentification directe via Azure AD Connect.
Étape 2 : Activer la fonctionnalité

Activez l’authentification directe via Azure AD Connect.
IMPORTANT
Vous pouvez activer l’authentification directe sur le serveur principal ou sur un serveur intermédiaire Azure AD Connect.
Nous vous recommandons vivement de l’activer à partir du serveur principal. Si vous installez un serveur intermédiaire
Azure AD Connect plus tard, vous devez continuer à choisir l’authentification directe comme option de connexion. Le
choix d’une autre option désactivera l’authentification directe sur le client et remplacera le paramètre dans le serveur
principal.
Si vous installez Azure AD Connect pour la première fois, choisissez le chemin d’installation personnalisé. Dans
la page Connexion utilisateur , choisissez Authentification directe comme méthode d’authentification .
Si l’opération réussit, un agent d’authentification directe est installé sur le même serveur qu’Azure AD Connect.
La fonctionnalité d’authentification directe est également activée sur votre locataire.
Si vous avez déjà installé Azure AD Connect à l’aide du chemin d’installation rapide ou d’installation
personnalisée, sélectionnez la tâche Modifier la connexion utilisateur dans Azure AD Connect, puis cliquez
sur Suivant . Ensuite, sélectionnez Authentification directe comme mode d’authentification. Si l’opération
réussit, un agent d’authentification directe est installé sur le même serveur qu’Azure AD Connect et la
fonctionnalité est activée sur votre locataire.
IMPORTANT
L’authentification directe est une fonctionnalité au niveau du locataire. Son activation affecte la connexion des utilisateurs
dans tous les domaines gérés dans votre locataire. Si vous passez d'Active Directory Federation Services (ADFS) à
l'authentification directe, vous devez attendre au moins 12 heures avant de fermer votre infrastructure AD FS. Ce délai
d'attente permet aux utilisateurs de continuer à se connecter à Exchange ActiveSync pendant la transition. Pour obtenir
plus d’informations sur la migration d’AD FS vers l’authentification directe, consultez notre plan de déploiement détaillé
publié ici.
Étape 3 : Tester la fonctionnalité

Suivez ces instructions pour vérifier que vous avez activé correctement l’authentification directe :
1. Connectez-vous au Centre d’administration Azure Active Directory à l’aide des informations d’identification
d’administrateur général de votre locataire.
2. Sélectionnez Active Director y dans le volet de gauche.
3. Sélectionnez ensuite Azure AD Connect .
4. Vérifiez que la fonctionnalité Authentification directe est activée .
5. Sélectionnez Authentification directe . Le volet Authentification directe répertorie les serveurs sur
lesquels vos agents d’authentification sont installés.
À ce stade, les utilisateurs de tous les domaines gérés de votre locataire peuvent se connecter à l’aide de
l’authentification directe. Toutefois, les utilisateurs des domaines fédérés continuent à se connecter à l’aide d'AD
FS ou d’un autre fournisseur de fédération précédemment configuré. Si vous convertissez un domaine fédéré en
domaine géré, tous les utilisateurs de ce domaine se connectent alors automatiquement à l’aide de
l’authentification directe. La fonctionnalité Authentification directe n’a pas d’incidence sur les utilisateurs cloud
uniquement.
Étape 4 : Garantir une haute disponibilité

Si vous envisagez de déployer l’authentification directe dans un environnement de production, vous devez
installer des agents d’authentification autonomes supplémentaires. Installez ces agents d’authentification sur des
serveurs autres que celui qui exécute Azure AD Connect. Cette configuration fournit une haute disponibilité pour
les requêtes de connexion des utilisateurs.
IMPORTANT
Dans les environnements de production, nous vous recommandons l’utilisation d’au moins 3 agents d’authentification
s’exécutant sur votre locataire. Il existe une limite système de 40 agents d’authentification par client. En tant que bonne
pratique, traitez tous les serveurs exécutant des agents d’authentification comme des systèmes de niveau 0 (voir
référence).
L’installation de plusieurs agents d’authentification directe assure une haute disponibilité, mais pas d’équilibrage
de charge entre les agents d’authentification. Pour savoir combien d’agents d’authentification sont nécessaires
pour votre client, tenez compte des pics et de la charge moyenne des demandes de connexion que vous
attendez sur votre client. À titre de référence, un seul agent d’authentification peut gérer entre 300 et 400
authentifications par seconde sur un serveur doté d’un CPU à 4 cœurs et de 16 Go de RAM.
Pour estimer le trafic réseau, suivez les instructions de dimensionnement suivantes :
La taille de la charge utile de chaque requête est de (0,5 K + 1 K x num_of_agents) octets. Cela correspond
aux données envoyées entre Azure AD et l'agent d'authentification. Ici, « num_of_agents » indique le nombre
d’agents d’authentification inscrit sur votre abonné.
La taille de la charge utile de chaque réponse est de 1 kilooctet. Cela correspond aux données envoyées entre
l'agent d'authentification et Azure AD.
Pour la plupart des clients, trois agents d’authentification au total suffisent à offrir la haute disponibilité et
suffisamment de capacité. Vous devriez installer des agents d’authentification près de vos contrôleurs de
domaine pour améliorer la latence de connexion.
Pour commencer, suivez ces instructions pour télécharger l’agent d’authentification :
1. Pour télécharger la dernière version de l’agent d’authentification (version 1.5.193.0 ou ultérieure), connectez-
vous au Centre d’administration Azure Active Directory avec les droits d’administrateur général de votre
locataire.
2. Sélectionnez Active Director y dans le volet de gauche.
3. Sélectionnez Azure AD Connect , Authentification directe , puis Télécharger l'agent .
4. Cliquez sur le bouton Accepter les conditions et télécharger .
NOTE
Vous pouvez aussi directement télécharger le logiciel de l’agent d’authentification. Passez en revue et acceptez les
conditions de service de l’agent d’authentification avant de l’installer.
Il existe deux méthodes pour déployer un agent d’authentification autonome :

Tout d’abord, vous pouvez le faire interactivement en exécutant le fichier exécutable de l’agent d’authentification
téléchargé et en fournissant les informations d’identification d’administrateur général de votre locataire lorsque
vous y êtes invité.
La deuxième solution consiste à créer et à exécuter un script de déploiement sans assistance. C’est utile lorsque
vous souhaitez déployer plusieurs agents d’authentification à la fois, ou installer des agents d’authentification
sur des serveurs Windows qui ne disposent pas d’une interface utilisateur, ou auxquels vous ne pouvez pas
accéder avec le Bureau à distance. Voici des instructions pour utiliser cette méthode :
1. Exécutez la commande suivante pour installer un agent d’authentification :
AADConnectAuthAgentSetup.exe REGISTERCONNECTOR="false" /q .
2. Vous pouvez inscrire l’agent d’authentification auprès de notre service à l’aide de Windows PowerShell. Créez
un objet d’informations d’identification PowerShell $cred qui contient un nom d’utilisateur et un mot de
passe d’administrateur général pour votre locataire. Exécutez la commande suivante, en remplaçant
<username> et <password> :
$User = "<username>"
$PlainPassword = '<password>'
$SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $SecurePassword
3. Accédez à C:\Program Files\Microsoft Azure AD Connect Authentication Agent et exécutez le script

suivant en utilisant l’objet $cred que vous venez de créer :
RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft Azure AD Connect Authentication

Agent\Modules\" -moduleName "PassthroughAuthPSModule" -Authenticationmode Credentials -Usercredentials $cred
-Feature PassthroughAuthentication
IMPORTANT
Si un agent d’authentification est installé sur une machine virtuelle, vous ne pouvez pas cloner cette machine virtuelle
pour installer un autre agent d’authentification. Cette méthode n’est pas prise en charge .
Étape 5 : Configurer la fonctionnalité de verrouillage intelligent

Le verrouillage intelligent empêche les personnes malveillantes de deviner vos mots de passe ou d’utiliser des
méthodes de force brute pour rentrer dans vos systèmes. En configurant les paramètres de verrouillage
intelligent dans Azure AD et/ou les paramètres de verrouillage appropriés dans l’Active Directory local, les
attaques peuvent être filtrées avant qu’elles n’atteignent Active Directory. Lisez cet article pour en savoir plus sur
la configuration des paramètres de verrouillage intelligent sur votre locataire pour protéger vos comptes
d’utilisateur.
Étapes suivantes
Verrouillage intelligent : apprenez à configurer la fonctionnalité Verrouillage intelligent sur votre locataire
pour protéger les comptes d'utilisateur.
Limitations actuelles : découvrez les scénarios pris en charge et non pris en charge avec l'authentification
directe.
Présentation technique approfondie : découvrez comment fonctionne la fonctionnalité d'authentification
directe.
Forum Aux Questions : obtenez des réponses aux questions fréquemment posées.
Présentation approfondie de sécurité : obtenez des informations techniques sur la fonctionnalité
d'authentification directe.
fonctionnalités.
Installation de l’agent Azure AD Connect Health
Dans cet article, vous allez apprendre à installer et à configurer les agents Azure Active Directory (Azure AD)
Connect Health. Pour télécharger les agents, consultez ces instructions.
Spécifications
Le tableau suivant répertorie les conditions requises pour l’utilisation d’Azure AD Connect Health.
C O N DIT IO N REQ UISE DESC RIP T IO N
Il existe un abonnement Azure AD Premium (P1 ou P2). Azure AD Connect Health est une fonctionnalité d'Azure AD
Premium (P1 ou P2). Pour plus d’informations, consultez
Inscription à Azure AD Premium.
Pour démarrer une période d’évaluation gratuite de 30 jours,

consultez Démarrer l’essai gratuit.
Vous êtes administrateur général dans Azure AD. Par défaut, seuls les administrateurs généraux peuvent
installer et configurer les agents d’intégrité, accéder au
portail et exécuter des opérations au sein d’Azure AD
Connect Health. Pour plus d’informations, consultez l’article
Administration de votre annuaire Azure AD.
En utilisant le contrôle d’accès en fonction du rôle Azure

(Azure RBAC), vous pouvez autoriser d’autres utilisateurs de
votre organisation à accéder à Azure AD Connect Health.
Pour plus d’informations, consultez Azure RBAC pour Azure
AD Connect Health.
Impor tant ! Utilisez un compte professionnel ou scolaire

pour installer les agents. Vous ne pouvez pas utiliser un
compte Microsoft. Pour plus d’informations, consultez
Inscription à Azure en tant qu’organisation.
L’agent Azure AD Connect Health est installé sur chaque Les agents d’intégrité doivent être installés et configurés sur
serveur cible. des serveurs ciblés pour pouvoir recevoir des données et
fournir des capacités de surveillance et d’analytique.
Par exemple, pour obtenir des données de votre

infrastructure de services de fédération Active Directory
(AD FS), vous devez installer l’agent sur le serveur AD FS et
le serveur proxy d’application web. De même, pour récupérer
des données de votre infrastructure Azure AD Domain
Services (Azure AD DS) locale, vous devez installer l’agent sur
les contrôleurs de domaine.
Les points de terminaison de service Azure ont une Pendant l’installation et l’exécution, l’agent nécessite une
connectivité sortante. connectivité vers les points de terminaison de service Azure
AD Connect Health. Si les pare-feu bloquent la connectivité
sortante, ajoutez les points de terminaison de connectivité
sortante à la liste autorisée.
C O N DIT IO N REQ UISE DESC RIP T IO N
La connectivité sortante est basée sur les adresses IP. Pour plus d’informations sur le filtrage de pare-feu basé sur
des adresses IP, consultez Plages d’adresses IP Azure.
L’inspection TLS pour le trafic sortant est filtrée ou L’étape d’inscription de l’agent ou les étapes de chargement
désactivée. de données peuvent échouer en cas d’inspection ou d’arrêt
du protocole TLS pour le trafic sortant sur la couche réseau.
Pour plus d’informations, consultez Configurer
l’inspection TLS.
Les ports de pare-feu sur le serveur exécutent l’agent. L’agent requiert que les ports de pare-feu suivants soient
ouverts pour pouvoir communiquer avec les points de
terminaison du service Azure AD Connect Health :
Port TCP 443
Port TCP 5671
La version la plus récente de l’agent ne requiert pas le

port 5671. Procédez à une mise à niveau vers la dernière
version pour que seul le port 443 soit requis. Pour plus
d’informations, consultez Ports et protocoles nécessaires à
l’identité hybride.
Si la sécurité renforcée d’Internet Explorer est activée, Si la sécurité renforcée d’Internet Explorer est activée,
autorisez les sites web spécifiés. autorisez les sites web suivants sur le serveur sur lequel vous
installez l’agent :
https://login.microsoftonline.com
https://secure.aadcdn.microsoftonline-p.com
https://login.windows.net
https://aadcdn.msftauth.net
Le serveur de fédération de votre organisation approuvé
par Azure AD (par exemple, https://sts.contoso.com)
Pour plus d’informations, consultez Guide pratique pour

configurer Internet Explorer. Si vous avez un proxy dans
votre réseau, consultez la remarque qui figure à la fin de ce
tableau.
La version 5.0 ou ultérieure de PowerShell est installée. Le serveur Windows 2016 comprend la version 5.0 de
PowerShell.
Les normes FIPS (Federal Information Processing Standard) Les agents Azure AD Connect Health ne prennent pas en
sont désactivées. charge les normes FIPS (Federal Information Processing
Standard).
IMPORTANT
Windows Server Core ne prend pas en charge l’installation de l’agent Azure AD Connect Health.
NOTE
Si vous disposez d’un environnement hautement verrouillé et restreint, vous devez ajouter plus d’URL que celles que le
tableau énumère pour la sécurité renforcée d’Internet Explorer. Ajoutez également les URL qui sont répertoriées dans le
tableau de la section suivante.
Connectivité sortante vers les points de terminaison de service Azure

Pendant l’installation et l’exécution, l’agent nécessite une connectivité vers les points de terminaison de service
Azure AD Connect Health. Si les pare-feu bloquent la connectivité sortante, assurez-vous que les URL du tableau
suivant ne sont pas bloquées par défaut.
Ne désactivez pas la supervision ou l’inspection de sécurité de ces URL. Autorisez-les plutôt comme vous le
feriez pour un autre trafic Internet.
Ces URL permettent la communication avec les points de terminaison de service Azure AD Connect Health. Plus
loin dans cet article, vous apprendrez à vérifier la connectivité sortante à l’aide de
Test-AzureADConnectHealthConnectivity .
EN VIRO N N EM EN T DE DO M A IN E P O IN T S DE T ERM IN A ISO N DE SERVIC E A Z URE N ÉC ESSA IRES
Grand public *.blob.core.windows.net

*.aadconnecthealth.azure.com
*.servicebus.windows.net - Port: 5671 (Ce point de
terminaison n’est pas requis dans la version la plus récente
de l’agent.)
*.adhybridhealth.azure.com/
https://management.azure.com
https://policykeyservice.dc.ad.msft.net/
https://login.windows.net
https://login.microsoftonline.com
https://www.office.com (Ce point de terminaison est utilisé
uniquement à des fins de détection pendant l’inscription.)
https://aadcdn.msauth.net
Azure Germany *.blob.core.cloudapi.de

*.servicebus.cloudapi.de
*.aadconnecthealth.microsoftazure.de
https://management.microsoftazure.de
https://policykeyservice.aadcdi.microsoftazure.de
https://login.microsoftonline.de
https://secure.aadcdn.microsoftonline-p.de
https://www.office.de (Ce point de terminaison est utilisé
Azure Government *.blob.core.usgovcloudapi.net

*.servicebus.usgovcloudapi.net
*.aadconnecthealth.microsoftazure.us
https://management.usgovcloudapi.net
https://policykeyservice.aadcdi.azure.us
https://login.microsoftonline.us
https://www.office.com (Ce point de terminaison est utilisé
Installer l’agent
Pour télécharger et installer l’agent Azure AD Connect Health :
Vérifiez que vous disposez de la configuration requise pour Azure AD Connect Health.
Prise en main d’Azure AD Connect Health pour AD FS :
Téléchargez l’agent Azure AD Connect Health pour AD FS.
Prise en main d’Azure AD Connect Health pour la synchronisation :
Téléchargez et installez la dernière version d’Azure AD Connect. L’agent d’intégrité pour la
synchronisation sera ajouté dans le cadre de l’installation d’Azure AD Connect (version 1.0.9125.0 ou
ultérieure).
Prise en main d’Azure AD Connect Health pour Azure AD DS :
Téléchargez l’agent Azure AD Connect Health pour Azure AD DS.
Installer l’agent pour AD FS

NOTE
Votre serveur AD FS doit être différent de votre serveur de synchronisation. N’installez pas l’agent AD FS sur votre
serveur de synchronisation.
Avant d’installer l’agent, assurez-vous que le nom d’hôte de votre serveur AD FS est unique et qu’il n’existe pas
dans le service AD FS. Pour démarrer l’installation de l’agent, double-cliquez sur le fichier .exe que vous avez
téléchargé. Dans la première fenêtre, sélectionnez Installer .
Une fois l’installation terminée, sélectionnez Configurer .
Une fenêtre PowerShell s’ouvre pour démarrer le processus d’inscription de l’agent. Lorsque vous y êtes invité,
connectez-vous à l’aide d’un compte Azure AD disposant des autorisations nécessaires pour inscrire l’agent. Par
défaut, le compte d’administrateur général dispose des autorisations.
Une fois que vous êtes connecté, PowerShell continue. Une fois l’opération terminée, vous pouvez fermer
PowerShell. La configuration est terminée.
À ce stade, les services de l’agent doivent démarrer automatiquement pour permettre à l’agent de charger en
toute sécurité les données requises pour le service cloud.
Si vous n’avez pas respecté toutes les conditions préalables, des avertissements s’affichent dans la fenêtre
PowerShell. Assurez-vous que vous disposez de la configuration requise avant d’installer l’agent. La capture
d’écran suivante présente un exemple de ces avertissements.
Pour vérifier que l’agent a été installé, recherchez les services suivants sur le serveur. Si vous avez terminé la
configuration, ils doivent déjà être en cours d’exécution. Dans le cas contraire, ils sont arrêtés tant que la
configuration n’est pas terminée.
Azure AD Connect Health AD FS Diagnostics Service
Azure AD Connect Health AD FS Insights Service
Azure AD Connect Health AD FS Monitoring Service
Activer l’audit pour AD FS
NOTE
Cette section s’applique uniquement aux serveurs AD FS. Il est inutile de suivre ces étapes sur les serveurs proxy
d’application web.
La fonctionnalité Analyse de l’utilisation doit collecter et analyser les données. Ainsi, l’agent Azure AD Connect
Health a besoin des informations contenues dans les journaux d’audit AD FS. Ces journaux ne sont pas activés
par défaut. Utilisez les procédures suivantes pour activer l’audit AD FS et localiser les journaux d’audit AD FS sur
vos serveurs AD FS.
Pour activer l’audit pour AD FS sur Windows Server 2012 R2
1. Dans l’écran de démarrage, ouvrez Gestionnaire de ser veur , puis ouvrez Stratégie de sécurité
locale . Ou, dans la barre des tâches, ouvrez Gestionnaire de ser veur et sélectionnez Outils/Stratégie
de sécurité locale .
2. Accédez au dossier Paramètres de sécurité\Stratégies locales\Attribution des droits utilisateur. Double-
cliquez ensuite sur Générer des audits de sécurité .
3. Sous l’onglet Paramètre de sécurité locale , vérifiez que le compte de service AD FS est répertorié. S’il
n’est pas répertorié, sélectionnez Ajouter un utilisateur ou un groupe et ajoutez-le à la liste.
Sélectionnez ensuite OK .
4. Pour activer l’audit, ouvrez une fenêtre d’invite de commandes avec des privilèges élevés. Exécutez
ensuite la commande suivante :
auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:enable /success:enable
5. Fermez Stratégie de sécurité locale .

IMPORTANT
Les étapes suivantes sont requises uniquement pour les serveurs AD FS principaux.
6. Fermez le composant logiciel enfichable Gestion AD FS . (Dans Gestionnaire de ser veur , sélectionnez
Outils > Gestion d’AD FS .)
7. Dans le volet Actions , sélectionnez Modifier les propriétés du ser vice de fédération .
8. Dans la boîte de dialogue Propriétés du ser vice de fédération , sélectionnez l’onglet Événements .
9. Cochez les cases Audits des succès et Audits des échecs , puis sélectionnez OK .
10. Pour activer la journalisation commentée par le biais de PowerShell, utilisez la commande suivante :
Set-AdfsProperties -LOGLevel Verbose
Pour activer l’audit pour AD FS sur Windows Server 2016

1. Dans l’écran de démarrage, ouvrez Gestionnaire de ser veur , puis ouvrez Stratégie de sécurité
locale . Ou, dans la barre des tâches, ouvrez Gestionnaire de ser veur et sélectionnez Outils/Stratégie
de sécurité locale .
2. Accédez au dossier Paramètres de sécurité\Stratégies locales\Attribution des droits utilisateur, puis
double-cliquez sur Générer des audits de sécurité .
3. Sous l’onglet Paramètre de sécurité locale , vérifiez que le compte de service AD FS est répertorié. S’il
n’est pas répertorié, sélectionnez Ajouter un utilisateur ou un groupe et ajoutez le compte de service
AD FS à la liste. Sélectionnez ensuite OK .
4. Pour activer l’audit, ouvrez une fenêtre d’invite de commandes avec des privilèges élevés. Exécutez
ensuite la commande suivante :
auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:enable /success:enable
5. Fermez Stratégie de sécurité locale .
IMPORTANT
Les étapes suivantes sont requises uniquement pour les serveurs AD FS principaux.
6. Fermez le composant logiciel enfichable Gestion AD FS . (Dans Gestionnaire de ser veur , sélectionnez
Outils > Gestion d’AD FS .)
7. Dans le volet Actions , sélectionnez Modifier les propriétés du ser vice de fédération .
8. Dans la boîte de dialogue Propriétés du ser vice de fédération , sélectionnez l’onglet Événements .
9. Cochez les cases Audits des succès et Audits des échecs , puis sélectionnez OK . Les audits des succès
et les audits des échecs doivent être activés par défaut.
10. Ouvrez une fenêtre PowerShell et exécutez la commande suivante :
Set-AdfsProperties -AuditLevel Verbose
Le niveau d’audit « de base » est activé par défaut. Pour plus d’informations, consultez Amélioration de l’audit
AD FS dans Windows Server 2016.
Pour localiser les journaux d’audit AD FS
1. Ouvrez l’ Obser vateur d’événements .
2. Accédez à Journaux Windows , puis sélectionnez Sécurité .
3. Sur la droite, sélectionnez Filtrer les journaux d’activité actuels .
4. Dans Sources d’événement , sélectionnez Audit AD FS .
Pour plus d’informations sur les journaux d’audit, consultez les questions relatives aux opérations.
WARNING
Une stratégie de groupe peut désactiver l’audit AD FS. Si l’audit AD FS est désactivé, l’analyse de l’utilisation sur les
activités de connexion n’est pas disponible. Vérifiez que vous n’avez pas de stratégie de groupe qui désactive l’audit AD FS.
Installer l’agent pour la synchronisation

L’agent Azure AD Connect Health pour la synchronisation est installé automatiquement dans la version la plus
récente d’Azure AD Connect. Pour utiliser Azure AD Connect pour la synchronisation, téléchargez la version la
plus récente d’Azure AD Connect et installez-la.
Pour vérifier que l’agent a été installé, recherchez les services suivants sur le serveur. Si vous avez terminé la
configuration, les services doivent déjà être en cours d’exécution. Dans le cas contraire, ils sont arrêtés tant que
la configuration n’est pas terminée.
Azure AD Connect Health Sync Insights Service
Azure AD Connect Health Sync Monitoring Service
NOTE
N'oubliez pas que vous devez disposer d'Azure AD Premium (P1 ou P2) pour utiliser Azure AD Connect Health. Si vous ne
disposez pas d’Azure AD Premium, vous ne pouvez pas terminer la configuration dans le portail Azure. Pour plus
d’informations, consultez la configuration requise.
Inscrire manuellement Azure AD Connect Health pour la

synchronisation
Si l’inscription de l’agent Azure AD Connect Health pour la synchronisation échoue après avoir correctement
installé Azure AD Connect, vous pouvez utiliser une commande PowerShell pour inscrire l’agent manuellement.
IMPORTANT
Utilisez cette commande PowerShell uniquement si l’inscription de l’agent échoue après l’installation d’Azure AD Connect.
Inscrivez manuellement l’agent Azure AD Connect Health pour la synchronisation à l’aide de la commande
PowerShell suivante. Les services Azure AD Connect Health démarreront une fois l’agent correctement
enregistré.
Register-AzureADConnectHealthSyncAgent -AttributeFiltering $true -StagingMode $false
La commande prend les paramètres qui suivent :

AttributeFiltering : $true (par défaut), si Azure AD Connect ne synchronise pas le jeu d’attributs par défaut
et a été personnalisé pour utiliser un jeu d’attributs filtré. Sinon, utilisez $false .
StagingMode : $false (par défaut), si le serveur Azure AD Connect n’est pas en mode intermédiaire. Si le
serveur est configuré pour être en mode intermédiaire, utilisez $true .
Lorsque vous êtes invité à vous authentifier, utilisez le même compte d’administrateur général (par exemple
admin@domain.onmicrosoft.com) que celui que vous avez utilisé pour configurer Azure AD Connect.
Installer l’agent pour Azure AD DS

Pour démarrer l’installation de l’agent, double-cliquez sur le fichier .exe que vous avez téléchargé. Dans la
première fenêtre, sélectionnez Installer .
Une fois l’installation terminée, sélectionnez Configurer .

Une fenêtre d’invite de commandes s’ouvre. PowerShell exécute Register-AzureADConnectHealthADDSAgent .
Lorsque vous y êtes invité, connectez-vous à Azure.
Une fois que vous êtes connecté, PowerShell continue. Une fois l’opération terminée, vous pouvez fermer
PowerShell. La configuration est terminée.
À ce stade, les services doivent être démarrés automatiquement, permettant à l’agent de surveiller et de
collecter les données. Si vous n’avez pas satisfait la configuration requise décrite dans les sections précédentes,
des avertissements s’affichent dans la fenêtre PowerShell. Assurez-vous que vous disposez de la configuration
requise avant d’installer l’agent. La capture d’écran suivante présente un exemple de ces avertissements.
Pour vérifier que l’agent a été installé, recherchez les services suivants sur le contrôleur de domaine :
Azure AD Connect Health AD DS Insights Service
Azure AD Connect Health AD DS Monitoring Service
Si vous avez terminé la configuration, ces services doivent déjà être en cours d’exécution. Dans le cas contraire,
ils sont arrêtés jusqu’à la fin de la configuration.
Installer rapidement l’agent sur plusieurs serveurs

1. Créez un compte d’utilisateur dans Azure AD. Sécurisez-le à l’aide d’un mot de passe.
2. Attribuez le rôle Propriétaire à ce compte Azure AD local dans Azure AD Connect Health à l’aide du
portail. Procédez comme suit. Affectez le rôle à toutes les instances de services.
3. Téléchargez le fichier MSI .exe dans le contrôleur de domaine local pour l’installation.
4. Exécutez le script suivant. Remplacez les paramètres par votre nouveau compte d’utilisateur et son mot
de passe.
AdHealthAddsAgentSetup.exe /quiet
Start-Sleep 30
$userName = "NEWUSER@DOMAIN"
$secpasswd = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force
$myCreds = New-Object System.Management.Automation.PSCredential ($userName, $secpasswd)
import-module "C:\Program Files\Azure Ad Connect Health Adds Agent\PowerShell\AdHealthAdds"
Register-AzureADConnectHealthADDSAgent -Credential $myCreds
Lorsque vous avez terminé, vous pouvez supprimer l’accès du compte local en effectuant une ou plusieurs des
tâches suivantes :
Supprimer l’attribution de rôle au compte local pour Azure AD Connect Health.
retournez le mot de passe du compte local ;
Désactiver le compte local Azure AD.
Supprimer le compte local Azure AD.
Inscrire l’agent à l’aide de PowerShell

Après avoir installé le fichier setup.exe de l’agent approprié, vous pouvez inscrire l’agent à l’aide des commandes
PowerShell suivantes, en fonction du rôle. Ouvrez une fenêtre PowerShell et exécutez la commande appropriée :
Register-AzureADConnectHealthADFSAgent
Register-AzureADConnectHealthADDSAgent
Register-AzureADConnectHealthSyncAgent
NOTE
Pour vous inscrire auprès de clouds souverains, utilisez les lignes de commande suivantes :
Register-AzureADConnectHealthADFSAgent -UserPrincipalName upn-of-the-user

Register-AzureADConnectHealthADDSAgent -UserPrincipalName upn-of-the-user
Register-AzureADConnectHealthSyncAgent -UserPrincipalName upn-of-the-user
Ces commandes acceptent Credential en tant que paramètre pour terminer l’inscription de manière non
interactive ou pour terminer l’inscription sur un ordinateur qui exécute Server Core. N’oubliez pas les points
suivants :
Vous pouvez capturer Credential dans une variable PowerShell qui est transmise en tant que paramètre.
Vous pouvez fournir n’importe quelle identité Azure AD qui dispose des autorisations nécessaires pour
inscrire les agents et pour laquelle l’authentification multifacteur n’est pas activée.
Par défaut, les administrateurs généraux sont autorisés à inscrire les agents. Vous pouvez également
autoriser des identités moins privilégiées à effectuer cette étape. Pour plus d’informations, consultez Azure
RBAC.
$cred = Get-Credential
Register-AzureADConnectHealthADFSAgent -Credential $cred
Configuration des agents Azure AD Connect Health pour utiliser le

proxy HTTP
Vous pouvez configurer des agents Azure AD Connect Health pour utiliser un proxy HTTP.
NOTE
Netsh WinHttp set ProxyServerAddress n’est pas pris en charge. L’agent utilise System.Net au lieu des services
HTTP Windows pour effectuer des requêtes web.
L’adresse de proxy HTTP configurée sert à transmettre des messages HTTPS chiffrés.
Les serveurs proxy authentifiés (à l’aide de HTTPBasic) ne sont pas pris en charge.
Modifier la configuration de l’agent proxy

Pour configurer l’agent Azure AD Connect Health pour qu’il utilise un proxy HTTP, vous pouvez :
Importer les paramètres de proxy existants.
Spécifier les adresses du proxy manuellement.
Effacer la configuration de proxy existante.
NOTE
Pour mettre à jour les paramètres de proxy, vous devez redémarrer tous les services de l’agent Azure AD Connect Health.
Exécutez la commande suivante :
Restart-Service AzureADConnectHealth*
Importer les paramètres de proxy existants

Vous pouvez importer les paramètres du proxy HTTP d’Internet Explorer afin que les agents Azure AD Connect
Health puissent les utiliser. Sur chacun des serveurs qui exécutent l’agent d’intégrité, exécutez la commande
PowerShell suivante :
Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings
Vous pouvez importer les paramètres du proxy WinHTTP afin que les agents Azure AD Connect Health puissent
les utiliser. Sur chacun des serveurs qui exécutent l’agent d’intégrité, exécutez la commande PowerShell
suivante :
Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp
Spécifier les adresses du proxy manuellement

Vous pouvez spécifier manuellement un serveur proxy. Sur chacun des serveurs qui exécutent l’agent d’intégrité,
exécutez la commande PowerShell suivante :
Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress address:port
Voici un exemple :
Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress myproxyserver: 443
Dans cet exemple :

Le paramètre address peut être un nom de serveur DNS pouvant être résolu ou une adresse IPv4.
Vous pouvez omettre port . Si vous le faites, le port 443 est le port par défaut.
Effacer la configuration de proxy existante
Vous pouvez effacer la configuration du proxy en exécutant la commande suivante :
Set-AzureAdConnectHealthProxySettings -NoProxy
Lecture des paramètres de proxy actuels

Vous pouvez lire les paramètres de proxy actuels en exécutant la commande suivante :
Get-AzureAdConnectHealthProxySettings
Tester la connectivité au service Azure AD Connect Health

Parfois, l’agent Azure AD Connect Health peut perdre la connectivité avec le service Azure AD Connect Health.
Les causes de cette perte de connectivité peuvent inclure des problèmes de réseau, des problèmes
d’autorisation et divers autres problèmes.
Si l’agent ne peut pas envoyer de données au service Azure AD Connect Health pendant plus de deux heures,
l’alerte suivante s’affiche dans le portail : « Les données du service de contrôle d’intégrité ne sont pas à jour. »
Vous pouvez savoir si l’agent Azure AD Connect Health concerné peut charger des données vers le service Azure
AD Connect Health en exécutant la commande PowerShell suivante :
Test-AzureADConnectHealthConnectivity -Role ADFS
Le paramètre de rôle peut avoir les valeurs suivantes :

ADFS
Synchronisation
AJOUTE
NOTE
Pour utiliser l’outil de connectivité, vous devez d’abord inscrire l’agent. Si vous ne pouvez pas terminer l’inscription de
l’agent, assurez-vous d’avoir rempli toutes les conditions requises pour Azure AD Connect Health. La connectivité est
testée par défaut lors de l’inscription de l’agent.
Étapes suivantes
Consultez les articles connexes suivants :
Azure AD Connect Health
Opérations Azure AD Connect Health
Utilisation d’Azure AD Connect Health avec AD FS
Utilisation d’Azure AD Connect Health pour la synchronisation
Utilisation d’Azure AD Connect Health avec Azure AD DS
Forum Aux Questions (FAQ) Azure AD Connect Health
Historique des versions d’Azure AD Connect Health
Azure AD Connect : Mise à jour automatique
La mise à jour automatique Azure AD Connect est une fonctionnalité qui recherche régulièrement des versions
plus récentes d’Azure AD Connect. Si votre serveur est activé pour la mise à niveau automatique et qu’une
version plus récente est trouvée, pour laquelle votre serveur est éligible, il effectue une mise à niveau
automatique vers cette version plus récente. Notez que, pour des raisons de sécurité, l’agent qui effectue la mise
à niveau automatique valide la nouvelle version d’Azure AD Connect en fonction de la signature numérique de la
version téléchargée.
Vue d’ensemble
Grâce à la fonctionnalité de mise à niveau automatique , vous pouvez facilement vous assurer que votre
installation Azure AD Connect est à jour. Cette fonctionnalité est activée par défaut pour les installations
expresses et les mises à niveau de DirSync. Quand une nouvelle version est publiée, votre installation est mise à
niveau automatiquement. La mise à niveau automatique est activée par défaut pour les éléments suivants :
Installation de la configuration rapide et mises à niveau de DirSync.
SQL Express LocalDB, toujours utilisée par la configuration rapide. DirSync avec SQL Express utilise
également LocalDB.
Le compte AD est le compte MSOL_ par défaut créé par la configuration rapide et DirSync.
Avoir moins de 100 000 objets dans le métaverse.
L’état actuel de la mise à niveau automatique peut être affiché avec l’applet de commande PowerShell
Get-ADSyncAutoUpgrade . Elle peut avoir les états suivants :
STAT E C O M M EN TA IRE
activé La mise à niveau automatique est activée.
Interrompu Défini par le système uniquement. Actuellement, le

système n’est pas autorisé à recevoir des mises à
niveau automatiques.
Désactivé La mise à niveau automatique est désactivée.
Vous pouvez passer de Activé à Désactivé avec Set-ADSyncAutoUpgrade . Seul le système doit définir l’état
Interrompu . Avant la version 1.1.750.0, l’applet de commande Set-ADSyncAutoUpgrade bloquait la mise à
niveau automatique lorsqu’elle était dans l’état Suspendu. Cette fonctionnalité a été modifiée pour éviter de
bloquer la mise à niveau automatique.
La mise à niveau automatique utilise Azure AD Connect Health pour l’infrastructure de mise à niveau. Pour
qu’une mise à niveau automatique fonctionne, assurez-vous d’avoir ouvert les URLs dans votre serveur proxy
pour Azure AD Connect Health comme indiqué dans la rubrique URL et plages d’adresses IP Office 365.
Si l’interface utilisateur du Synchronization Ser vice Manager est en cours d’exécution sur le serveur, la mise
à niveau est suspendue jusqu’à la fermeture de l’interface utilisateur.
NOTE
La mise à niveau automatique ne concerne pas toutes les versions d’Azure AD Connect. L’état de la version indique si une
version est disponible en mise à niveau automatique ou en téléchargement uniquement. Si la mise à niveau automatique
a été activée sur votre serveur Azure AD Connect, celui-ci sera automatiquement mis à niveau vers la dernière version
d’Azure AD Connect pour la mise à niveau automatique si votre configuration est éligible pour une mise à niveau
automatique. Pour plus d’informations, consultez l’article Azure AD Connect : historique de la version.
Éligibilité à la mise à niveau automatique

Pour pouvoir bénéficier d’une mise à niveau automatique, vous ne devez répondre à aucune des conditions
suivantes :
M ESSA GE DE RÉSULTAT DESC RIP T IO N
UpgradeNotSupportedCustomizedSyncRules Vous avez ajouté vos propres règles de personnalisation à la

configuration.
UpgradeNotSupportedInvalidPersistedState L’installation n’est pas une configuration rapide ou une mise

à niveau DirSync.
UpgradeNotSupportedNonLocalDbInstall Vous n’utilisez pas une base de données LocalDB SQL Server
Express.
UpgradeNotSupportedLocalDbSizeExceeded La taille de la base de données locale est supérieure ou égale

à 8 Go
UpgradeNotSupportedAADHealthUploadDisabled Les chargements de données d’intégrité ont été désactivés à

partir du portail
Dépannage
Si votre installation Connect ne se met pas elle-même à niveau comme prévu, procédez comme suit pour savoir
d’où vient le problème.
Tout d'abord, ne vous attendez pas à ce qu’il y ait déjà une tentative de mise à niveau automatique le jour du
lancement d’une nouvelle version. Toute tentative de mise à niveau a un caractère aléatoire intentionnel. Ne
vous inquiétez pas si votre installation n'est pas mise à niveau immédiatement.
Si vous pensez que quelque chose ne convient pas, commencez par exécuter Get-ADSyncAutoUpgrade pour
garantir l’activation de la mise à niveau automatique.
Si l’état est interrompu, vous pouvez utiliser Get-ADSyncAutoUpgrade -Detail pour afficher le motif. La raison de
l’interruption peut contenir une valeur de chaîne quelconque, mais elle contient généralement la valeur de
chaîne UpgradeResult, autrement dit, UpgradeNotSupportedNonLocalDbInstall ou UpgradeAbortedAdSyncExeInUse .
Une valeur composée peut également être retournée, par exemple
UpgradeFailedRollbackSuccess-GetPasswordHashSyncStateFailed .
Il est également possible d’obtenir un résultat qui n’est pas un UpgradeResult, c.-à-d.
« AADHealthEndpointNotDefined » ou « DirSyncInPlaceUpgradeNonLocalDb ».
Assurez-vous ensuite que vous avez ouvert les URL requises dans votre proxy ou pare-feu. La mise à jour
automatique utilise Azure AD Connect Health comme décrit dans la présentation. Si vous utilisez un proxy,
vérifiez que Health a été configuré pour utiliser un serveur proxy. Testez également la connectivité de Health à
Azure AD.
Une fois que vous avez vérifié la connectivité à Azure AD, passez aux journaux d’événements. Démarrez
l’Observateur d’événements et consultez le journal des événements Application . Ajoutez un filtre de journal
des événements pour la mise à niveau d’Azure AD Connect source et la plage d’ID d’événements 300-399 .
Les journaux des événements associés à l’état de mise à niveau automatique s’affichent alors.
Le code de résultat a un préfixe avec une vue d’ensemble de l’état.
P RÉF IXE DU C O DE DE RÉSULTAT DESC RIP T IO N
Succès La mise à niveau de l’installation a réussi.
UpgradeAborted Un problème temporaire a arrêté la mise à niveau. Une

nouvelle tentative va être effectuée. Celle-ci devrait réussir à
un stade ultérieur.
UpgradeNotSupported La configuration du système entraîne le blocage de sa mise à

niveau automatique. Elle sera tentée à nouveau pour voir si
l'état est modifié, mais l'on s’attend à ce que le système
doive être mis à niveau manuellement.
Voici une liste de messages les plus courants. Elle n’est pas exhaustive, mais le message de résultat doit exposer
clairement la nature du problème.
UpgradeAbor ted
UpgradeAbortedCouldNotSetUpgradeMarker Impossible d’écrire dans le Registre.

UpgradeAbortedInsufficientDatabasePermissions Le groupe Administrateurs intégré ne dispose pas des

autorisations d’accès à la base de données. Effectuez une
mise à niveau manuelle vers la dernière version d’Azure AD
Connect pour résoudre ce problème.
UpgradeAbortedInsufficientDiskSpace Il n'y a pas suffisamment d'espace disque pour prendre en

charge une mise à niveau.
UpgradeAbortedSecurityGroupsNotPresent Impossible de trouver et de résoudre tous les groupes de

sécurité utilisés par le moteur de synchronisation.
UpgradeAbortedServiceCanNotBeStarted Échec du démarrage du service NT Microsoft Azure AD

Sync .
UpgradeAbortedServiceCanNotBeStopped Échec de l’arrêt du service NT Microsoft Azure AD Sync .
UpgradeAbortedServiceIsNotRunning Le service NT Microsoft Azure AD Sync n’est pas en

cours d’exécution.
UpgradeAbortedSyncCycleDisabled L’option SyncCycle du Scheduler a été désactivée.
UpgradeAbortedSyncExeInUse L’ interface utilisateur du gestionnaire des services de

synchronisation est ouverte sur le serveur.
UpgradeAbortedSyncOrConfigurationInProgress L'Assistant Installation est en cours d'exécution ou une

synchronisation a été planifiée à l'extérieur du planificateur.
UpgradeNotSuppor ted
UpgradeNotSupportedCustomizedSyncRules Vous avez ajouté vos propres règles de personnalisation à la

configuration.
UpgradeNotSupportedInvalidPersistedState L’installation n’est pas une configuration rapide ou une mise

à niveau DirSync.
UpgradeNotSupportedNonLocalDbInstall Vous n’utilisez pas une base de données LocalDB SQL Server
Express.
UpgradeNotSupportedLocalDbSizeExceeded La taille de la base de données locale est supérieure ou égale

à 8 Go
UpgradeNotSupportedAADHealthUploadDisabled Les chargements de données d’intégrité ont été désactivés à

partir du portail
Étapes suivantes
Azure AD Connect Sync : exécuter l’Assistant
Installation une deuxième fois
La première fois que vous exécutez l’Assistant Installation d’Azure AD Connect, il vous guide dans la procédure
de configuration de votre installation. Si vous réexécutez l’Assistant Installation, il vous propose des options de
maintenance.
IMPORTANT
N’oubliez pas que vous ne pouvez pas exécuter l’Assistant Installation pendant qu’une synchronisation est en cours. Avant
de lancer l’Assistant, vérifiez qu’aucune synchronisation n’est en cours d’exécution.
Vous trouverez l’Assistant Installation dans le menu Démarrer sous le nom Azure Connect AD .
Lorsque vous démarrez l’Assistant Installation, une page s’affiche avec ces options :
Si vous avez installé AD FS avec Azure AD Connect, vous avez davantage d’options. Les options supplémentaires
que vous avez pour AD FS sont documentées dans Gestion AD FS.
Sélectionnez l’une des tâches et cliquez sur Suivant pour continuer.
IMPORTANT
Tant que l’Assistant Installation est ouvert, toutes les opérations du moteur de synchronisation sont suspendues. Prenez
soin de fermer l’Assistant Installation dès que vous avez terminé vos modifications de configuration.
Afficher la configuration actuelle

Cette option vous donne un aperçu rapide de vos options actuellement configurées.
Cliquez sur Précédent pour revenir en arrière. Si vous sélectionnez Quitter , vous fermez l’Assistant Installation.
Personnaliser les options de synchronisation

Cette option est utilisée pour apporter des modifications à la configuration de la synchronisation. Vous voyez un
sous-ensemble d’options provenant du chemin d’installation de la configuration personnalisée. Et ce, même si
vous avez initialement utilisé l’installation rapide.
Ajouter d’autres annuaires. Pour supprimer un annuaire, consultez Supprimer un connecteur.
Modifier le filtrage par domaine ou unité d’organisation.
Supprimer le filtrage de groupe.
Modifier les fonctionnalités facultatives.
Les autres options provenant de l’installation initiale ne peuvent pas être modifiées et ne sont pas disponibles.
Ces options sont :
Modifier l’attribut à utiliser pour userPrincipalName et sourceAnchor.
Modifier la méthode de jointure d’objets provenant de différentes forêts.
Activer le filtrage de groupe.
Actualiser le schéma d’annuaire
Cette option est utilisée si vous avez modifié le schéma dans l’une de vos forêts AD DS locales. Par exemple,
vous pouvez avoir installé Exchange ou effectué une mise à niveau vers un schéma Windows Server 2012 avec
des objets de périphérique. Dans ce cas, vous devez demander à Azure AD Connect de relire le schéma AD DS et
de mettre à jour son cache. Cette action régénère également les règles de synchronisation. Si vous ajoutez le
schéma Exchange, par exemple, les règles de synchronisation d’Exchange sont ajoutées à la configuration.
Lorsque vous sélectionnez cette option, tous les annuaires de votre configuration sont répertoriés. Vous pouvez
conserver le paramètre par défaut et actualiser toutes les forêts ou désélectionner certaines d’entre elles.
Configurer le mode de préproduction

Cette option permet d’activer et de désactiver le mode de préproduction sur le serveur. Vous trouverez plus
d’informations sur le mode de préproduction et son utilisation dans Opérations.
L’option s’affiche si la préproduction est actuellement activée ou désactivée :
Pour modifier l’état, sélectionnez cette option et cochez ou décochez la case.
Modifier la connexion de l’utilisateur

Cette option permet de définir la méthode de connexion utilisateur sur la synchronisation de hachage de mot de
passe, l’authentification directe ou la fédération. Vous ne pouvez pas passer à ne pas configurer .
Pour plus d’informations sur cette option, consultez connexion de l’utilisateur.
Étapes suivantes
En savoir plus sur le modèle de configuration utilisé par la synchronisation d’Azure AD Connect dans
Comprendre l’approvisionnement déclaratif.
Azure AD Connect : Effectuer une mise à niveau
depuis une version précédente vers la dernière
Cette rubrique décrit les différentes méthodes que vous pouvez utiliser pour mettre à niveau votre installation
Azure Active Directory (Azure AD) Connect vers la dernière version. Vous pouvez également suivre les étapes
décrites dans la section Migration « swing » lorsque vous appliquez une modification importante à la
configuration.
NOTE
Il est important de garder vos serveurs à jour avec les dernières versions d’Azure AD Connect. Nous effectuons
constamment des mises à niveau vers AADConnect, et ces mises à niveau incluent des correctifs pour les problèmes de
sécurité et les bogues, ainsi que des améliorations de la maintenance, des performances et de l’évolutivité. Pour voir la
version la plus récente et savoir quelles modifications ont été apportées entre les versions, consultez l’historique des
versions
NOTE
Il est actuellement pris en charge pour la mise à niveau de n’importe quelle version d’Azure AD Connect vers la version
actuelle. Les mises à niveau en place de DirSync ou ADSync ne sont pas prises en charge et une migration swing est
nécessaire. Si vous souhaitez effectuer une mise à niveau à partir de DirSync, consultez Effectuer une mise à niveau à
partir de l’outil de synchronisation Azure AD (DirSync) ou la section Migration « swing ».
Dans la pratique, les clients qui utilisent des versions extrêmement anciennes peuvent rencontrer des problèmes qui ne
sont pas directement liés à Azure AD Connect. Les serveurs qui ont été en production pendant plusieurs années, ont
généralement eu plusieurs correctifs qui leur ont été appliqués et qui ne peuvent pas tous être comptabilisés. En général,
les clients qui n’ont pas effectué de mise à niveau au bout de 12 à 18 mois devraient plutôt envisager une mise à niveau
rapide, car c’est l’option la plus prudente et la moins risquée.
Si vous souhaitez effectuer une mise à niveau à partir de DirSync, consultez plutôt Effectuer une mise à niveau à
partir de l’outil de synchronisation Azure AD (DirSync) .
Il existe plusieurs stratégies que vous pouvez utiliser pour mettre à niveau Azure AD Connect.
M ÉT H O DE DESC RIP T IO N
Mise à niveau automatique Pour les clients avec une installation rapide, il s’agit de la
méthode la plus simple.
Mise à niveau sur place Si vous avez un seul serveur, vous pouvez mettre à niveau
l’installation sur place sur le même serveur.
Migration « swing » Avec deux serveurs, vous pouvez en préparer un avec la

nouvelle version ou configuration, et changer de serveur
actif quand vous êtes prêt.
Pour plus d’informations sur les autorisations, reportez-vous aux autorisations requises pour une mise à niveau.
NOTE
Une fois que vous avez activé votre nouveau serveur Azure AD Connect pour démarrer la synchronisation des
modifications avec Azure AD, vous ne devez pas revenir à l’utilisation de DirSync ou Azure AD Sync. La rétrogradation à
partir d’Azure AD Connect vers des clients hérités, notamment DirSync et Azure AD Sync, n’est pas prise en charge et peut
entraîner des problèmes tels que la perte de données dans Azure AD.
Mise à niveau sur place

Une mise à niveau sur place fonctionne à partir d’Azure AD Sync ou d’Azure AD Connect, Elle ne fonctionne pas
pour la migration à partir de DirSync ou pour une solution avec Forefront Identity Manager (FIM) + connecteur
Azure AD.
Nous vous recommandons cette méthode si vous avez un seul serveur et moins de 100 000 objets environ.
Après la mise à niveau, une importation et une synchronisation complètes se produisent si des modifications
ont été apportées aux règles de synchronisation out-of-box, pour que la nouvelle configuration s’applique à tous
les objets existants dans le système. Cette opération peut prendre plusieurs heures selon le nombre d’objets
figurant dans l’étendue du moteur de synchronisation. La synchronisation différentielle normale planifiée (par
défaut toutes les 30 minutes) est suspendue, mais la synchronisation des mots de passe continue. Vous pouvez
envisager une mise à niveau sur place pendant le week-end. S’il n’y a aucune modification de la configuration
par défaut avec la nouvelle version d’Azure AD Connect, une importation/synchronisation différentielle normale
démarre à la place.
Si vous avez apporté des modifications aux règles de synchronisation par défaut, celles-ci retrouvent leur
configuration par défaut au moment de la mise à niveau. Pour conserver votre configuration d’une mise à
niveau à l’autre, vérifiez que les modifications sont effectuées conformément aux meilleures pratiques pour
Pendant la mise à niveau sur place, des modifications introduites peuvent nécessiter l’exécution d’activités de
synchronisation spécifiques (notamment les étapes d’importation complète et de synchronisation complète)
une fois la mise à niveau terminée. Pour différer ces activités, consultez la section Comment différer la
synchronisation complète après la mise à niveau.
Si vous utilisez Azure AD Connect avec un connecteur non standard (par exemple, le connecteur LDAP
générique ou le connecteur SQL générique), vous devez actualiser la configuration du connecteur en question
dans Synchronization Service Manager après la mise à niveau sur place. Pour savoir comment actualiser la
configuration du connecteur, reportez-vous à la section Résolution des problèmes de l’article Historique de
publication des versions du connecteur. Si vous n’actualisez pas la configuration, les étapes d’importation et
d’exportation ne fonctionneront pas correctement pour le connecteur. Vous recevrez le message d’erreur suivant
dans le journal des événements de l’application : « Assembly version in AAD Connector configuration
("X.X.XXX.X") is earlier than the actual version ("X.X.XXX.X") of "C:\Program Files\Microsoft Azure AD
Sync\Extensions\Microsoft.IAM.Connector.GenericLdap.dll". » (La version de l’assembly dans la configuration du
connecteur AAD (« X.X.XXX.X ») est antérieure à la version réelle (« X.X.XXX.X ») de « C:\Program Files\Microsoft
Azure AD Sync\Extensions\Microsoft.IAM.Connector.GenericLdap.dll ».).
Migration « swing »
Si votre déploiement est complexe, si vous disposez d’un grand nombre d’objets ou si vous devez mettre à
niveau le système d’exploitation Windows Server, il peut être difficile d’effectuer une mise à niveau sur place sur
le système actif. Pour certains clients, ce processus peut prendre plusieurs jours pendant lesquels aucune
modification différentielle n’est traitée. Vous pouvez également utiliser cette méthode lorsque vous envisagez
d’apporter des modifications importantes à votre configuration et que vous souhaitez les tester avant de les
envoyer dans le cloud.
La méthode recommandée pour ces scénarios consiste à utiliser une migration « swing ». Vous devez avoir (au
moins) deux serveurs : un serveur actif et un serveur intermédiaire. Le serveur actif (représenté par des lignes
bleues continues dans l’image ci-dessous) est responsable de la charge de production active. Le serveur
intermédiaire (représenté par des lignes violettes en pointillé) est préparé avec la nouvelle version ou
configuration. Lorsqu’il est prêt, ce serveur devient actif. Le serveur actif précédent, sur lequel est désormais
installée l’ancienne version ou configuration, devient le serveur intermédiaire et est mis à niveau.
Les deux serveurs peuvent utiliser différentes versions. Par exemple, le serveur actif que vous projetez de
désactiver peut utiliser Azure AD Sync et le nouveau serveur intermédiaire peut utiliser Azure AD Connect. Si
vous utilisez la migration « swing » pour développer une nouvelle configuration, il est judicieux d’installer les
mêmes versions sur les deux serveurs.
NOTE
Certains clients préfèrent avoir trois ou quatre serveurs pour ce scénario. Pendant la mise à niveau du serveur
intermédiaire, vous n’avez pas de serveur de sauvegarde pour la récupération d’urgence. Avec trois ou quatre serveurs,
vous pouvez préparer un ensemble de serveurs principaux/de secours disposant de la nouvelle version. Ainsi, un serveur
intermédiaire est toujours prêt à prendre le relais.
Ces étapes fonctionnent également pour la migration à partir d’Azure AD Sync ou d’une solution avec FIM +
connecteur Azure AD. En revanche, elles ne fonctionnent pas pour DirSync, mais on trouve cette même méthode
de migration « swing » (également appelée déploiement parallèle) pour DirSync dans Azure AD Connect : Mise à
niveau à partir de DirSync.
Utiliser une migration « swing » pour effectuer la mise à niveau
1. Si vous utilisez Azure AD Connect sur les deux serveurs et que vous prévoyez uniquement de modifier la
configuration, assurez-vous que votre serveur actif et votre serveur intermédiaire utilisent tous deux la
même version. Il sera plus facile de comparer ensuite les différences. Si vous effectuez une mise à niveau à
partir d’Azure AD Sync, ces serveurs auront des versions différentes. Si vous effectuez une mise à niveau à
partir d’une ancienne version d’Azure AD Connect, il est judicieux, mais pas obligatoire, de commencer avec
les deux serveurs qui utilisent la même version.
2. Si vous avez effectué une configuration personnalisée et que votre serveur intermédiaire ne l’a pas, suivez les
étapes décrites dans Déplacer une configuration personnalisée depuis le serveur actif vers le serveur
intermédiaire.
3. Si vous mettez à niveau depuis une version antérieure d’Azure AD Connect, mettez à niveau le serveur
intermédiaire vers la dernière version. Si vous migrez à partir d’Azure AD Sync, installez Azure AD Connect
sur votre serveur intermédiaire.
4. Laissez le moteur de synchronisation effectuer une importation et une synchronisation complètes sur votre
serveur intermédiaire.
5. Vérifiez que la nouvelle configuration n’a pas entraîné de modifications inattendues à l’aide de la procédure
indiquée sous « Vérifier » dans Vérifiez la configuration d’un serveur. Si quelque chose n’est pas comme
prévu, corrigez le problème, exécutez l’importation et la synchronisation et vérifiez les données jusqu’à ce
qu’elles vous conviennent en suivant les étapes.
6. Convertissez le serveur de test en serveur actif. C’est la dernière étape, « Changer de serveur actif », de la
procédure Vérifiez la configuration d’un serveur.
7. Si vous mettez à niveau Azure AD Connect, mettez à niveau le serveur actuellement en mode intermédiaire
vers la dernière version. Suivez la même procédure pour mettre à niveau les données et la configuration. Si
vous avez effectué une mise à niveau à partir d’Azure AD Sync, vous pouvez maintenant désactiver et retirer
votre ancien serveur.
Déplacer une configuration personnalisée depuis le serveur actif vers le serveur intermédiaire
Si vous avez apporté des modifications à la configuration du serveur actif, vous devez vérifier que les mêmes
modifications sont appliquées au serveur intermédiaire. Pour faciliter ce déplacement, vous pouvez utiliser la
documentation de configuration d’Azure AD Connect.
Vous pouvez migrer les règles de synchronisation personnalisées que vous avez créées à l’aide de PowerShell.
Vous devez appliquer d’autres modifications de la même manière sur les deux systèmes, et vous ne pouvez pas
migrer les modifications. La documentation de configuration peut vous aider à comparer les deux systèmes
pour vérifier qu’ils sont identiques. L’outil peut également vous aider à automatiser les étapes indiquées dans
cette section.
Vous devez configurer ce qui suit de la même façon sur les deux serveurs :
Connexion aux mêmes forêts
Tout filtrage de domaine et d’unité organisationnelle
Fonctionnalités facultatives identiques, telles que la synchronisation de mot de passe et la réécriture du mot
de passe
Migrer les règles de synchronisation personnalisées
Pour déplacer des règles de synchronisation personnalisées, procédez comme suit :
1. Ouvrez l’ Éditeur de règles de synchronisation sur votre serveur actif.
2. Sélectionnez une règle personnalisée. Cliquez sur Expor ter . Une fenêtre Bloc-notes apparaît. Enregistrez le
fichier temporaire avec une extension PS1. Le fichier devient un script PowerShell. Copiez le fichier PS1 sur le
serveur intermédiaire.
3. Le GUID du connecteur est différent sur le serveur intermédiaire et doit être modifié. Pour obtenir le GUID,
démarrez l’Éditeur de règles de synchronisation , sélectionnez une des règles par défaut représentant le
même système connecté, puis cliquez sur Expor ter . Remplacez le GUID dans votre fichier PS1 par le GUID se
trouvant sur le serveur de test.
4. Dans une invite de PowerShell, exécutez le fichier PS1. Cette action crée la règle de synchronisation
personnalisée sur le serveur intermédiaire.
5. Répétez cette procédure pour toutes vos règles personnalisées.
Comment différer la synchronisation complète après la mise à niveau

Pendant la mise à niveau sur place, des modifications introduites peuvent nécessiter l’exécution d’activités de
synchronisation spécifiques (notamment les étapes d’importation complète et de synchronisation complète). Par
exemple, les modifications du schéma de connecteur nécessitent l’exécution de l’étape Impor tation complète ,
et les modifications des règles de synchronisation par défaut nécessitent l’exécution de l’étape
Synchronisation complète sur les connecteurs affectés. Pendant la mise à niveau, Azure AD Connect
détermine les activités de synchronisation requises et les enregistre en tant qu’actions prioritaires. Dans le cycle
de synchronisation suivant, le planificateur de synchronisation récupère ces actions prioritaires et les exécute.
Dès qu’une action prioritaire a été exécutée avec succès, elle est supprimée.
Il peut arriver que vous ne souhaitiez pas que ces actions prioritaires aient lieu immédiatement après la mise à
niveau. Par exemple, vous avez de nombreux objets synchronisés et vous souhaitez que ces étapes de
synchronisation aient lieu après les heures de bureau. Pour supprimer ces actions prioritaires :
1. Pendant la mise à niveau, désactivez l’option Démarrez le processus de synchronisation une fois
la configuration terminée . Cela désactive le planificateur de synchronisation et empêche l’exécution
automatique du cycle de synchronisation avant la suppression des actions prioritaires.
2. Une fois la mise à niveau terminée, exécutez l’applet de commande suivante pour connaître les actions
prioritaires qui ont été ajoutées : Get-ADSyncSchedulerConnectorOverride | fl
NOTE
Les actions prioritaires sont propres au connecteur. Dans l’exemple suivant, les étapes d’importation complète et
de synchronisation complète ont été ajoutées au connecteur Active Directory et au connecteur Azure AD locaux.
3. Prenez note des actions prioritaires existantes qui ont été ajoutées.
4. Pour supprimer les actions prioritaires pour l’importation complète et la synchronisation complète sur un
connecteur arbitraire, exécutez l’applet de commande suivante :
Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier <Guid-of-ConnectorIdentifier> -
FullImportRequired $false -FullSyncRequired $false
Pour supprimer les actions prioritaires sur tous les connecteurs, exécutez le script PowerShell suivant :
foreach ($connectorOverride in Get-ADSyncSchedulerConnectorOverride)

{
Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier
$connectorOverride.ConnectorIdentifier.Guid -FullSyncRequired $false -FullImportRequired $false
}
5. Pour redémarrer le planificateur, exécutez l’applet de commande suivante :
Set-ADSyncScheduler -SyncCycleEnabled $true
IMPORTANT
N’oubliez pas d’exécuter les étapes de synchronisation requises dès que vous le pourrez. Vous pouvez exécuter ces
étapes manuellement à l’aide de Synchronization Service Manager ou rajouter les actions prioritaires à l’aide de
l’applet de commande Set-ADSyncSchedulerConnectorOverride.
Pour ajouter les actions prioritaires pour l’importation complète et la synchronisation complète sur un
connecteur arbitraire, exécutez l’applet de commande suivante :
Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier <Guid> -FullImportRequired $true -FullSyncRequired
$true
Mise à niveau du système d’exploitation serveur

Si vous devez mettre à niveau le système d’exploitation de votre serveur Azure AD Connect, n’effectuez pas une
mise à niveau sur place du système d’exploitation. Au lieu de cela, préparez un nouveau serveur avec le système
d’exploitation souhaité et effectuez une migration de type « swing ».
Dépannage
La section suivante contient des informations et des solutions de dépannage que vous pouvez utiliser si vous
rencontrez des difficultés lors de la mise à niveau d’Azure AD Connect.
Erreur de connecteur Azure Active Directory manquant au cours de la mise à niveau d’Azure AD Connect
Lorsque vous mettez à niveau Azure AD Connect à partir d’une version antérieure, vous risquez de rencontrer
l’erreur suivante au début de la mise à niveau
Cette erreur se produit, car le connecteur Azure Active Directory avec l’identificateur b891884f-051e-4a83-95af-
2544101c9083 n’existe pas dans la configuration d’Azure AD Connect actuelle. Pour le vérifier, ouvrez une
fenêtre PowerShell et exécutez l’applet de commande
Get-ADSyncConnector -Identifier b891884f-051e-4a83-95af-2544101c9083
PS C:\> Get-ADSyncConnector -Identifier b891884f-051e-4a83-95af-2544101c9083
Get-ADSyncConnector : Operation failed because the specified MA could not be found.
At line:1 char:1
+ Get-ADSyncConnector -Identifier b891884f-051e-4a83-95af-2544101c9083
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ReadError: (Microsoft.Ident...ConnectorCmdlet:GetADSyncConnectorCmdlet) [Get-
ADSyncConne
ctor], ConnectorNotFoundException
+ FullyQualifiedErrorId : Operation failed because the specified MA could not be
found.,Microsoft.IdentityManageme
nt.PowerShell.Cmdlet.GetADSyncConnectorCmdlet
L’applet de commande PowerShell signale l’erreur selon laquelle le MA spécifié est introuvable .
Le fait que la configuration d’Azure AD Connect actuelle ne soit pas prise en charge pour la mise à niveau en est
la raison.
Si vous voulez installer une nouvelle version d’Azure AD Connect : fermez l’Assistant Azure AD Connect,
désinstallez la version Azure AD Connect existante et procédez à une nouvelle installation avec une version plus
récente.
Étapes suivantes
En savoir plus sur l’intégration de vos identités locales avec Azure Active Directory.
Azure AD Connect : Effectuer une mise à niveau à
partir de DirSync
Azure AD Connect est le successeur de DirSync. Cette rubrique explique les différentes façons de procéder à une
mise à niveau à partir de DirSync. Ces étapes ne fonctionnent pas pour la mise à niveau à partir d’une autre
version d’Azure AD Connect ou d’Azure AD Sync.
DirSync et Azure AD Sync ne sont pas pris en charge et ne fonctionneront plus. Si vous les utilisez encore, vous
devez procéder à une mise à niveau vers AADConnect pour reprendre votre processus de synchronisation.
Avant de commencer l’installation d’Azure AD Connect, veillez à télécharger Azure AD Connect et effectuer les
étapes préalables décrites dans Azure AD Connect : matériel et prérequis. En particulier, il est recommandé de se
renseigner sur les éléments suivants, dans la mesure où ces zones sont différentes de celles de DirSync :
version requise de .Net et de PowerShell. Les versions plus récentes doivent être sur le serveur dont DirSync
a besoin.
La configuration du serveur proxy. Si vous utilisez un serveur proxy pour accéder à internet, ce paramètre
doit être configuré avant d’effectuer la mise à niveau. DirSync a toujours utilisé le serveur proxy configuré
pour l’utilisateur qui effectue l’installation, alors qu’Azure AD Connect utilise les paramètres de l’ordinateur.
Les URL doivent être ouvertes dans le serveur proxy. Pour les scénarios de base, qui sont également pris en
charge par DirSync, les exigences sont les mêmes. Si vous souhaitez utiliser une des nouvelles fonctionnalités
d’Azure AD Connect, certaines nouvelles URL doivent être ouvertes.
NOTE
Une fois que vous avez activé votre nouveau serveur Azure AD Connect pour démarrer la synchronisation des
modifications à Azure AD, vous ne devez pas restaurer à l’aide de DirSync ou Azure AD Sync. La rétrogradation à partir
d’Azure AD Connect pour les clients hérités, notamment DirSync et Azure AD Sync n’est pas prise en charge et peut
entraîner des problèmes tels que la perte de données dans Azure AD.
Si vous n’effectuez pas une mise à niveau à partir de DirSync, consultez la section Documentation connexe pour
d’autres scénarios.
Effectuer une mise à niveau à partir de DirSync

Selon votre déploiement DirSync actuel, il existe différentes options pour la mise à niveau. Si la durée de mise à
niveau attendue est inférieure à 3 heures, nous vous recommandons de l’effectuer sur place. Si elle est
supérieure à 3 heures, nous vous recommandons d’effectuer un déploiement en parallèle sur un autre serveur.
Nos estimations montrent que, si vous avez plus de 50 000 objets, la mise à niveau prendra plus de 3 heures.
SC ÉN A RIO
Déploiement en parallèle
NOTE
Lorsque vous envisagez de mettre à niveau à partir de DirSync vers Azure AD Connect, ne désinstallez pas DirSync vous-
même avant la mise à niveau. Azure AD Connect lit et migre la configuration de DirSync et procède à la désinstallation
après l'inspection du serveur.

L’Assistant affiche la durée estimée de l’opération. Cette estimation est basée sur l’hypothèse qu’il faut 3 heures
pour mettre à niveau une base de données contenant 50 000 objets (utilisateurs, contacts et groupes). Azure AD
Connect recommande une mise à niveau sur place si votre base de données contient moins de 50 000 objets. Si
vous décidez de continuer, vos paramètres actuels sont appliqués automatiquement au cours de la mise à
niveau et votre serveur rétablit automatiquement la synchronisation active.
Si vous souhaitez effectuer une migration de la configuration et un déploiement en parallèle, vous pouvez ne
pas effectuer la mise à niveau sur place. Vous pouvez, par exemple, prendre l'opportunité d'actualiser le matériel
et le système d'exploitation. Pour plus d’informations, consultez la section Déploiement en parallèle.
Un déploiement en parallèle est recommandé si vous avez plus de 50 000 objets. Ce déploiement permet
d’éviter les retards opérationnels rencontrés par vos utilisateurs. L’installation d’Azure AD Connect tente
d’estimer le temps d’arrêt associé à la mise à niveau, mais si vous avez déjà mis à niveau DirSync, votre propre
expérience est sans doute plus fiable.
Configurations de DirSync prises en charge à mettre à niveau
Les modifications de configuration suivantes sont prises en charge avec la mise à niveau de DirSync :
Filtrage domaine et unité organisationnelle
Autre ID (UPN)
Synchronisation de mot de passe et paramètres hybrides d'Exchange
Vos paramètres domaine/forêt et Azure AD
Filtrage basé sur les attributs de l'utilisateur
La modification suivante ne peut pas être mise à niveau. Si vous avez cette configuration, la mise à niveau est
bloquée :
Modifications de DirSync non prises en charge, par exemple : attributs supprimés et utilisation d’une DLL
d’extension personnalisée
Dans ces cas, il est recommandé d’installer un nouveau serveur Azure AD Connect en mode de préproduction et
de vérifier l’ancienne configuration de DirSync et la nouvelle configuration d’Azure AD Connect. Appliquez de
nouveau les éventuelles modifications à l’aide de la configuration personnalisée, comme décrit dans Azure AD
Connect Sync : configuration personnalisée.
Les mots de passe utilisés par DirSync pour les comptes de service ne peuvent pas être récupérés et ne sont pas
migrés. Ces mots de passe sont réinitialisés lors de la mise à niveau.
Étapes générales pour la mise à niveau à partir de DirSync vers Azure AD Connect
1. Bienvenue dans Azure AD Connect
2. Analyse de la configuration DirSync actuelle
3. Collecte du mot de passe administrateur global Azure AD
4. Collecte des informations d’identification pour le compte d’administrateur entreprise (utilisé uniquement lors
de l’installation d’Azure AD Connect)
5. Installation d'Azure AD Connect
Désinstaller DirSync (ou le désactiver temporairement)
Installer Azure AD Connect
Synchronisation, si nécessaire
Des étapes supplémentaires sont nécessaires dans les cas suivants :
Vous utilisez actuellement un serveur SQL complet, local ou distant
Vous avez plus de 50 000 objets à synchroniser

1. Lancez le programme d'installation d'Azure AD Connect (MSI).
2. Lisez et acceptez les termes du contrat de licence et la déclaration de confidentialité.
3. Cliquez sur le bouton Suivant pour analyser votre installation DirSync existante.
4. Une fois l’analyse terminée, nous proposons des recommandations sur la marche à suivre.
Si vous utilisez SQL Server Express et que vous avez moins de 50 000 objets, l'écran suivant s'affiche :
Si vous utilisez une instance SQL Server complète pour DirSync, vous voyez cette page à la place :
Les informations concernant le serveur de base de données SQL Server utilisé par DirSync s’affichent.
Apportez des modifications, si nécessaire. Cliquez sur Suivant pour continuer l'installation.
Si vous avez plus de 50 000 objets, vous voyez cet écran à la place :
Pour procéder à une mise à niveau sur place, cochez la case en regard du message : Continuez à
mettre à niveau DirSync sur cet ordinateur. Pour effectuer un parallel deployment , exportez les
paramètres de configuration de DirSync et copiez-les sur le nouveau serveur.
5. Indiquez le mot de passe du compte que vous utilisez actuellement pour vous connecter à Azure AD. Il doit
s’agir du compte actuellement utilisé par DirSync.
Si vous recevez une erreur et que vous avez des problèmes de connectivité, consultez Résoudre les
problèmes de connectivité liés à Azure AD Connect.
6. Indiquez un compte d'administrateur d'entreprise pour Active Directory.
7. Vous êtes prêt à passer à la configuration. Lorsque vous cliquez sur Mettre à niveau , DirSync est
désinstallé, puis Azure AD Connect est configuré et lance la synchronisation.
gestionnaire Synchronization Service Manager, l’éditeur de règles de synchronisation ou de tenter d’apporter
d’autres modifications à la configuration.
Exportation de la configuration de DirSync
Déploiement en parallèle avec plus de 50 000 objets
Si vous avez plus de 50 000 objets, l’installation d’Azure AD Connect recommande un déploiement en parallèle.
Un écran semblable à celui-ci s’affiche :
Pour effectuer un déploiement en parallèle, vous devez effectuer les opérations suivantes :
Cliquez sur le bouton Paramètres d'expor tation . Lorsque vous installez Azure AD Connect sur un autre
serveur, ces paramètres sont migrés de votre installation DirSync vers votre nouvelle installation Azure AD
Connect.
Une fois vos paramètres exportés, vous pouvez quitter l’Assistant Azure AD Connect sur le serveur de
synchronisation d’annuaires. Passez à l’étape suivante pour installer Azure AD Connect sur un serveur distinct.
Déploiement en parallèle avec moins de 50 000 objets
Si vous avez moins de 50 000 objets mais que vous souhaitez effectuer un déploiement en parallèle, procédez
comme suit :
1. Lancez le programme d’installation d’Azure AD Connect (MSI).
2. Lorsque l'écran Bienvenue à Azure AD Connect s'affiche, quittez l'Assistant d'installation en cliquant sur
le X en haut à droite de la fenêtre.
3. Ouvrez une invite de commandes.
4. À partir de l’emplacement d’installation d’Azure AD Connect (par défaut : C:\Program Files\Microsoft Azure
Active Directory Connect), exécutez la commande suivante : AzureADConnect.exe /ForceExport .
5. Cliquez sur le bouton Paramètres d'expor tation . Lorsque vous installez Azure AD Connect sur un autre
serveur, ces paramètres sont migrés de votre installation DirSync vers votre nouvelle installation Azure AD
Connect.
Une fois vos paramètres exportés, vous pouvez quitter l’Assistant Azure AD Connect sur le serveur de
synchronisation d’annuaires. Passez à l’étape suivante pour installer Azure AD Connect sur un serveur distinct.
Installation d'Azure AD Connect sur un serveur distinct
Lorsque vous installez Azure AD Connect sur un nouveau serveur, le système présuppose que vous voulez
effectuer une nouvelle installation d’Azure AD Connect. Comme vous souhaitez utiliser la configuration de
DirSync, quelques étapes supplémentaires sont nécessaires :
1. Lancez le programme d’installation d’Azure AD Connect (MSI).
2. Lorsque l'écran Bienvenue à Azure AD Connect s'affiche, quittez l'Assistant d'installation en cliquant sur
le X en haut à droite de la fenêtre.
3. Ouvrez une invite de commandes.
4. À partir de l’emplacement d’installation d’Azure AD Connect (par défaut : C:\Program Files\Microsoft Azure
Active Directory Connect), exécutez la commande suivante : AzureADConnect.exe /migrate . L’Assistant
d’installation d’Azure AD Connect démarre et affiche l’écran suivant :
5. Sélectionnez le fichier de paramètres exportés à partir de votre installation de la synchronisation d’annuaires.
6. Configurez les options avancées :
Un emplacement d'installation personnalisé pour Azure AD Connect.
Une instance existante de SQL Server (par défaut : Azure AD Connect installe SQL Server 2019
Express). N'utilisez pas la même instance de base de données que celle de votre serveur DirSync.
Un compte de service utilisé pour la connexion à SQL Server (si votre base de données SQL Server est
distante, ce compte doit être un compte de service du domaine). Ces options s'affichent dans cet écran
:

8. Sur la page Prêt pour la configuration , laissez la case Démarrer le processus de synchronisation
dès que la configuration est terminée cochée. Le serveur étant maintenant en mode de préproduction ,
les modifications ne sont pas exportées vers Azure AD.
9. Cliquez sur Installer .
gestionnaire Synchronization Service Manager, l’éditeur de règles de synchronisation ou de tenter d’apporter
d’autres modifications à la configuration.
NOTE
La synchronisation entre Windows Server Active Directory et Azure Active Directory commence, mais aucune modification
n’est exportée vers Azure AD. Les modifications ne peuvent être exportées activement que par un seul outil de
synchronisation à la fois. Cet état est appelé mode de préproduction.
Vérifiez qu'Azure AD Connect est prêt à commencer la synchronisation

Pour vérifier qu’Azure AD Connect est prêt à remplacer DirSync, vous devrez ouvrir le Synchronization
Ser vice Manager dans le groupe Azure AD Connect à l’aide du menu Démarrer.
Dans l’application, cliquez sur l’onglet Operations . Dans cet onglet, vérifiez que les opérations suivantes ont
abouti :
Importation sur le connecteur Active Directory
Importation sur le connecteur Azure Active Directory
Synchronisation complète sur le connecteur Active Directory
Synchronisation complète sur le connecteur Azure Active Directory
Examinez le résultat de ces opérations et vérifiez qu'il n'y a aucune erreur.

Si vous souhaitez afficher et examiner les modifications qui sont sur le point d’être exportées vers Azure AD,
lisez comment vérifier la configuration en mode de préproduction. Apportez les modifications de la
configuration requises jusqu'à ce que tout soit correct.
Vous êtes prêt à passer de DirSync à Azure AD lorsque vous avez effectué ces étapes et que vous êtes satisfait
du résultat.
Désinstallation de DirSync (ancien serveur)
Dans Programmes et fonctionnalités , recherchez Outil de synchronisation Windows Azure Active
Director y
Désinstallez Outil de synchronisation Windows Azure Active Director y
La désinstallation peut prendre jusqu’à 15 minutes.
Si vous préférez désinstaller DirSync ultérieurement, vous pouvez également arrêter le serveur ou désactiver le
service. Si une erreur survient, cette méthode vous permet de le réactiver. Toutefois, comme il est peu probable
que l’étape suivante échoue, cette opération ne devrait pas être nécessaire.
Une fois DirSync désinstallé ou désactivé, aucun serveur actif n’effectue d’exportations vers Azure AD. L’étape
suivante consistant à activer Azure AD Connect, doit aboutir pour que les modifications dans votre Active
Directory local restent synchronisées avec Azure AD.
Activation d'Azure AD Connect (nouveau serveur)
Après l’installation, lorsque vous rouvrez Azure AD Connect, vous aurez la possibilité d’apporter des
modifications supplémentaires à la configuration. Démarrez Azure AD Connect depuis le menu Démarrer ou à
partir du raccourci sur le bureau. Assurez-vous que vous n'essayez pas d'exécuter à nouveau le programme MSI
d'installation.
Les éléments suivants doivent s’afficher :
Sélectionnez Configuration du mode de préproduction .

Désactivez le mode de préproduction en désactivant la case à cocher Mode de préproduction activé .
Cliquez sur le bouton Suivant .
Dans la page Confirmation, cliquez sur le bouton Installer .
Azure AD Connect est maintenant votre serveur actif et vous ne devez pas revenir vers votre serveur DirSync
existant.
Étapes suivantes
Pour en savoir plus sur ces nouvelles fonctionnalités, activées lors de l’installation, consultez les pages : Mise à
niveau automatique, Prévention des suppressions accidentelles et Azure AD Connect Health.
Installer Azure AD Connect à l’aide d’une base de
données ADSync existante
Azure AD Connect nécessite une base de données SQL Server pour stocker les données. Vous pouvez utiliser la
Base de données locale (LocalDB) par défaut de SQL Server 2012 Express installée avec Azure AD Connect ou
utiliser votre propre version complète de SQL. Auparavant, quand vous installiez Azure AD Connect, une
nouvelle base de données nommée ADSync était toujours créée. Avec Azure AD Connect version 1.1.613.0 (ou
ultérieure), vous pouvez installer Azure AD Connect en le pointant sur une base de données ADSync existante.
Avantages offerts par l’utilisation d’une base de données ADSync

existante
Quand vous pointez sur une base de données ADSync existante :
Sauf pour les informations d’identification, la configuration de la synchronisation dans la base de données
ADSync (notamment les règles de synchronisation personnalisées, les connecteurs, le filtrage et la
configuration des fonctionnalités facultatives) est automatiquement récupérée et utilisée pendant
l’installation. Les informations d’identification utilisées par Azure AD Connect pour synchroniser les
modifications avec AD local et Azure AD sont chiffrées et accessibles uniquement par le serveur Azure AD
Connect précédent.
Toutes les données d’identité (associées au métaverse et aux espaces du connecteur) et les cookies de
synchronisation stockés dans la base de données ADSync sont également récupérés. Le serveur Azure AD
Connect nouvellement installé peut continuer à synchroniser à partir de là où le serveur Azure AD Connect
précédent s’est arrêté, sans avoir à effectuer une synchronisation complète.
Scénarios où l’utilisation de la base de données ADSync existante est

avantageuse
Ces avantages sont utiles dans les scénarios suivants :
Vous avez un déploiement existant d’Azure AD Connect. Votre serveur Azure AD Connect existant ne
fonctionne plus, mais le serveur SQL contenant la base de données ADSync fonctionne toujours. Vous
pouvez installer un nouveau serveur Azure AD Connect et le faire pointer sur la base de données ADSync
existante.
Vous avez un déploiement existant d’Azure AD Connect. Votre serveur SQL contenant la base de données
ADSync ne fonctionne plus. Toutefois, vous disposez d’une sauvegarde récente de la base de données. Vous
pouvez tout d’abord restaurer la base de données ADSync sur un nouveau serveur SQL. Après cela, vous
pouvez installer un nouveau serveur Azure AD Connect et le faire pointer sur la base de données ADSync
restaurée.
Vous avez un déploiement existant d’Azure AD Connect qui utilise Base de données locale. En raison de la
limite de 10 Go imposée par Base de données locale, vous souhaitez migrer vers la version complète de SQL.
Vous pouvez sauvegarder la base de données ADSync à partir de Base de données locale et la restaurer sur
un serveur SQL. Après cela, vous pouvez réinstaller un nouveau serveur Azure AD Connect et le faire pointer
sur la base de données ADSync restaurée.
Vous essayez de configurer un serveur intermédiaire et souhaitez vous assurer que sa configuration
correspond à celle du serveur actif actuel. Vous pouvez sauvegarder la base de données ADSync et la
restaurer sur un autre serveur SQL. Après cela, vous pouvez réinstaller un nouveau serveur Azure AD
Connect et le faire pointer sur la base de données ADSync restaurée.
Informations relatives aux prérequis

Remarques importantes avant de continuer :
Veillez à examiner les prérequis pour l’installation d’Azure AD Connect dans Matériel et prérequis, ainsi que
les comptes et les autorisations requises pour l’installation d’Azure AD Connect. Les autorisations requises
pour l’installation d’Azure AD Connect à l’aide du mode « Utiliser une base de données existante » sont
identiques à celles d’une installation « Personnalisée ».
Le déploiement d’Azure AD Connect parallèlement à une base de données ADSync existante est uniquement
pris en charge avec la version complète de SQL. Il n’est pas pris en charge avec Base de données locale SQL
Express. Si vous souhaitez utiliser une base de données ADSync existante de Base de données locale, vous
devez tout d’abord sauvegarder la base de données ADSync (Base de données locale) et la restaurer vers la
version complète de SQL. Vous pourrez alors déployer Azure AD Connect parallèlement à la base de données
restaurée à l’aide de cette méthode.
La version d’Azure AD Connect utilisée pour l’installation doit remplir les critères suivants :
Version 1.1.613.0 ou ultérieure, ET
Identique ou ultérieure à la dernière version d’Azure AD Connect utilisée avec la base de données
ADSync. Si la version d’Azure AD Connect utilisée pour l’installation est ultérieure à celle utilisée en
dernier avec la base de données ADSync, une synchronisation complète peut être requise. Une
synchronisation complète est nécessaire s’il y a des modifications de règle de synchronisation ou de
schéma entre les deux versions.
La base de données ADSync utilisée doit contenir un état de synchronisation relativement récent. La dernière
activité de synchronisation avec la base de données ADSync existante doit avoir eu lieu durant les trois
dernières semaines.
Quand vous installez Azure AD Connect à l’aide du mode « Utiliser une base de données existante », la
méthode d’authentification configurée sur le serveur Azure AD Connect précédent n’est pas conservée. De
plus, vous ne pouvez pas configurer la méthode de connexion pendant l’installation. Vous pouvez
uniquement configurer la méthode de connexion une fois l’installation terminée.
Vous ne pouvez avoir plusieurs serveurs Azure AD Connect qui partagent la même base de données ADSync.
Le mode « Utiliser une base de données existante » vous permet de réutiliser une base de données ADSync
existante avec un nouveau serveur Azure AD Connect. Il ne prend pas en charge le partage.
Étapes d’installation d’Azure AD Connect avec le mode « Utiliser une

base de données existante »
1. Téléchargez le programme d’installation d’Azure AD Connect (AzureADConnect.MSI) sur le serveur Windows.
Double-cliquez sur le programme d’installation d’Azure AD Connect pour démarrer l’installation d’Azure AD
Connect.
2. Une fois l’installation du fichier MSI terminée, l’Assistant Azure AD Connect démarre le programme
d’installation en mode Express. Fermez la fenêtre en cliquant sur l’icône Quitter.
3. Démarrez une nouvelle invite de commandes ou session PowerShell. Accédez au dossier « C:\Program
Files\Microsoft Azure Active Directory Connect ». Exécutez la commande .\AzureADConnect.exe
/useexistingdatabase pour démarrer l’Assistant Azure AD Connect en mode d’installation « Utiliser une base
de données existante ».
NOTE
Utilisez le commutateur /UseExistingDatabase uniquement lorsque la base de données contient déjà des données
issues d'une précédente installation d'Azure AD Connect. Par exemple, lorsque vous migrez d'une base de données locale
vers une base de données SQL Server ou lorsque le serveur Azure AD Connect a été reconstruit et que vous avez
restauré une sauvegarde SQL de la base de données ADSync à partir d’une précédente installation d’Azure AD Connect. Si
la base de données est vide, c'est-à-dire, si elle ne contient aucune donnée d'une installation précédente d'Azure AD
Connect, ignorez cette étape.
1. L’écran d’accueil d’Azure AD Connect s’affiche. Après avoir accepté les termes du contrat de licence et la
déclaration de confidentialité, cliquez sur Continuer .
2. Dans l’écran Installer les composants nécessaires , l’option Utiliser un SQL Ser ver existant est
activée. Spécifiez le nom du serveur SQL qui héberge la base de données ADSync. Si l’instance du moteur
SQL utilisée pour héberger la base de données ADSync n’est pas l’instance par défaut sur le serveur SQL,
vous devez spécifier le nom de l’instance du moteur SQL. De plus, si l’exploration SQL n’est pas activée,
vous devez également spécifier le numéro de port de l’instance du moteur SQL. Par exemple :
3. Dans l’écran Se connecter à Azure AD , vous devez fournir les informations d’identification d’un
administrateur général de votre annuaire Azure AD. Nous vous recommandons d’utiliser un compte du
domaine onmicrosoft.com par défaut. Ce compte est uniquement utilisé pour créer un compte de service
dans Azure AD et n’est plus utilisé une fois l’assistant terminé.
4. Dans l’écran Connexion de vos annuaires , une icône de croix rouge est affichée en regard de la forêt
AD existante configurée pour la synchronisation d’annuaire. Pour synchroniser les modifications à partir
d’une forêt AD locale, un compte de domaine AD DS est nécessaire. L’Assistant Azure AD Connect ne peut
pas récupérer les informations d’identification du compte AD DS stockées dans la base de données
ADSync, car elles sont chiffrées et peuvent uniquement être déchiffrées par le serveur Azure AD Connect
précédent. Cliquez sur Modifier les informations d’identification pour spécifier le compte AD DS
pour la forêt AD.
5. Dans la boîte de dialogue contextuelle, vous pouvez (i) entrer les informations d’identification d’un
administrateur d’entreprise et laisser Azure AD Connect créer le compte AD DS pour vous, ou (ii) créer
vous-même le compte AD DS et fournir ses informations d’identification à Azure AD Connect. Une fois
que vous avez sélectionné une option et fourni les informations d’identification nécessaires, cliquez sur
OK pour fermer la boîte de dialogue contextuelle.
6. Une fois les informations d’identification fournies, la croix rouge est remplacée par une coche verte.
Cliquez sur Suivant .
7. Dans l’écran Prêt à configurer , cliquez sur Installer .

8. Une fois l’installation terminée, le serveur Azure AD Connect est automatiquement activé pour le Mode
de préproduction. Nous vous recommandons de vérifier la présence de modifications inattendues dans la
configuration du serveur et les exportations en attente avant de désactiver le Mode de préproduction.
Tâches postérieures à l’installation

Lorsque vous restaurez une sauvegarde de base de données créée par une version d’Azure AD Connect
préalable à 1.2.65.0, le serveur de processus de site sélectionne automatiquement la méthode de connexion
sans configuration . Les préférences en matière de synchronisation du hachage de mot de passe et de
réécriture du mot de passe seront restaurées, mais vous devrez modifier la méthode de connexion pour faire
correspondre les autres stratégies en vigueur pour votre serveur de synchronisation actif. Si vous ne le faites
pas, les utilisateurs ne pourront peut-être pas se connecter en cas d’activation de ce serveur.
Le tableau ci-dessous vous permet de vérifier les étapes supplémentaires éventuellement requises.
F O N C T IO N N A L IT É ÉTA P ES
Synchronisation du hachage de mot de passe La synchronisation du hachage de mot de passe et les

paramètres de réécriture du mot de passe sont entièrement
restaurés pour Azure AD Connect versions 1.2.65.0 et
ultérieures. Si vous restaurez le système depuis une version
plus ancienne d’Azure AD Connect, parcourez les paramètres
relatifs aux options de synchronisation associés à ces
fonctions, afin de vous assurer qu’ils correspondent au
serveur de synchronisation actif. Aucune autre étape de
configuration n’est nécessaire.
F O N C T IO N N A L IT É ÉTA P ES
Fédération avec AD FS Les authentifications Azure continuent à utiliser la stratégie

AD FS configurée pour votre serveur de synchronisation
actif. Si vous utilisez Azure AD Connect pour gérer votre
batterie AD FS, vous pouvez modifier la méthode de
connexion à la fédération AD FS, afin de préparer la
conversion du serveur de secours en instance de
synchronisation active. Si les options de l’appareil sont
activées sur le serveur de synchronisation actif, configurez
ces options sur ce serveur en exécutant la tâche de
configuration des options de l’appareil.
Authentification de transmission directe et authentification Mettez à jour la méthode de connexion afin qu’elle
unique de bureau correspond à la configuration sur votre serveur de
synchronisation actif. Si vous ne le faites pas avant la
promotion du serveur en tant que serveur principal,
l’authentification directe ainsi que l’authentification unique
transparente seront désactivées. De plus, votre locataire
risque d’être bloqué si la synchronisation du hachage de mot
de passe n’est pas sélectionnée en tant qu’option de
connexion de secours. Notez également que lorsque vous
activez l’authentification directe en mode de processus de
site, un nouvel agent d’authentification est installé et
enregistré, et s’exécute comme un agent de haute
disponibilité qui accepte les demandes de connexion.
Fédération avec PingFederate L’authentification Azure continue à utiliser la stratégie

PingFederate configurée pour votre serveur de
synchronisation actif. Vous pouvez éventuellement modifier
la méthode de connexion à PingFederate, afin de préparer la
conversion du serveur de secours en instance de
synchronisation active. Cependant, cette étape peut attendre
la nécessité de fédérer des domaines supplémentaires avec
PingFederate.
Étapes suivantes
Pour en savoir plus sur ces fonctionnalités activées lors de l’installation, consultez les pages : Prévenir les
suppressions accidentelles et Azure AD Connect Health.
Installer Azure AD Connect à l’aide d’autorisations
administrateur déléguées SQL
Avant la dernière version d’Azure AD Connect, la délégation administrative n’était pas prise en charge lors du
déploiement de configurations nécessitant SQL. Les utilisateurs qui souhaitent installer Azure AD Connect
devaient disposer d’autorisations d’administrateur de serveur sur le serveur SQL.
Avec la version la plus récente d’Azure AD Connect, le provisionnement de la base de données peut désormais
être exécuté hors bande par l’administrateur SQL. L’installation s’effectue ensuite par l’administrateur Azure AD
Connect disposant de droits de propriétaire de base de données.
Avant de commencer
Pour utiliser cette fonctionnalité, vous devez savoir qu’il existe plusieurs éléments, et que chacun d’eux peut
impliquer un administrateur différent. Le tableau suivant récapitule les rôle et leurs fonctions respectives lors du
déploiement d’Azure AD Connect avec cette fonctionnalité.
RO L E DESC RIP T IO N
Administrateur AD de domaine ou de forêt Crée le compte de service au niveau du domaine, qui est
utilisé par Azure AD Connect pour exécuter le service de
synchronisation. Pour plus d’informations, consultez
Comptes et autorisations.
Administrateur SQL Crée la base de données ADSync et accorde l’accès

Connexion + Propriétaire de base de données à
l’administrateur Azure AD Connect et au compte de service
créé par l’administrateur du domaine ou de la forêt.
Administrateur Azure AD Connect Installe Azure AD Connect et spécifie le compte de service

pendant l’installation personnalisée.
Étapes d’installation d’Azure AD Connect à l’aide d’autorisations

déléguées SQL
Pour provisionner la base de données hors bande et installer Azure AD Connect avec des autorisations de
propriétaire de base de données, suivez les étapes ci-dessous.
NOTE
Même si cela n’est pas obligatoire, il est for tement recommandé de sélectionner le classement Latin1_General_CI_AS
lorsque vous créez une base de données.
1. Demandez à l’administrateur SQL de créer la base de données ADSync avec une séquence de classement
insensible à la casse (Latin1_General_CI_AS) . Le mode de récupération, le niveau de compatibilité et le
type de relation contenant-contenu sont mis à jour avec les valeurs appropriées lors de l’installation
d’Azure AD Connect. Toutefois, la séquence de classement doit être définie correctement par
l’administrateur SQL. Dans le cas contraire, Azure AD Connect va bloquer l’installation. Pour effectuer une
récupération, l’administrateur de base de données doit supprimer et recréer la base de données.
2. Accordez les autorisations suivantes à l’administrateur Azure AD Connect et au compte de service de

domaine :
Connexion SQL
Droits de propriétaire de base de données (dbo)
NOTE
Azure AD Connect ne prend pas en charge les informations de connexion liées à une appartenance imbriquée.
Cela signifie que votre compte de service de domaine et votre compte administrateur Azure AD Connect doivent
être liés à des informations de connexion disposant de droits de propriétaire de base de données. Il ne peut pas
simplement s'agir du membre d'un groupe affecté à des informations de connexion disposant de droits de
propriétaire de base de données.
3. Envoyez un e-mail à l’administrateur Azure AD Connect en indiquant le serveur SQL et le nom de

l’instance qui doivent être utilisés lors de l’installation d’Azure AD Connect.
Informations supplémentaires
Une fois que la base de données est provisionnée, l’administrateur Azure AD Connect peut installer et configurer
la synchronisation localement, à sa convenance.
Si l'administrateur SQL a restauré la base de données ADSync à partir d'une précédente sauvegarde d'Azure AD
Connect, vous devez installer le nouveau serveur Azure AD Connect à l'aide d'une base de données existante.
Pour plus d'informations sur l'installation d'Azure AD Connect avec une base de données existante, consultez
Installer Azure AD Connect à l'aide d'une base de données ADSync existante.
Étapes suivantes
Prise en main d’Azure AD Connect à l’aide de paramètres express
Installation personnalisée d’Azure AD Connect
Installer Azure AD Connect à l’aide d’une base de données ADSync existante
Préversion de la mise à niveau des agents
d'authentification
Vue d’ensemble
Cet article est destiné aux clients utilisant l’authentification directe Azure AD directe via l’aperçu. Nous avons
récemment mis à niveau le logiciel de l’agent d’authentification (tout en changeant son nom). Vous devez
procéder à la mise à niveau manuelle de la version préliminaire des agents d’authentification sur vos serveurs
locaux. Cette mise à niveau manuelle s’effectue une seule fois. Toutes les futures mises à jour des agents
d’authentification sont automatiques. Vous pouvez effectuer la mise à niveau pour les raisons suivantes :
La version préliminaire des agents d’authentification ne sera plus sécurisée ou ne recevra plus les correctifs
de bogues.
La version préliminaire des agents d’authentification ne peut être installée sur des serveurs supplémentaires
pour une haute disponibilité.
Vérifiez les versions de vos agents d’authentification

Étape 1 : vérifier l'emplacement d'installation de vos agents d'authentification
Suivez les étapes ci-après pour vérifier l’emplacement de l’installation de vos agents d’authentification :
1. Connectez-vous au Centre d’administration Azure Active Directory à l’aide des informations d’identification
d’administrateur général de votre locataire.
2. Sélectionnez Azure Active Director y dans le volet de navigation gauche.
4. Sélectionnez Authentification directe . Ce panneau répertorie les serveurs sur lesquels vos agents
d’authentification sont installés.
Étape 2 : vérifier les versions de vos agents d'authentification

Pour vérifier les versions de vos Agents d’authentification sur chaque serveur identifié à l’étape précédente,
suivez ces instructions :
1. Accédez à panneau de configuration -> Programmes -> Programmes et fonctionnalités sur le
serveur local.
2. S’il existe une entrée pour «Agent d’authentification Microsoft Azure AD Connect », vous n’avez pas
besoin d’entamer une action sur ce serveur.
3. S’il existe une entrée pour « Microsoft Azure AD Application Proxy Connector » (Connecteur de proxy
d’application Microsoft Azure AD), vous devez effectuer une mise à niveau manuelle sur ce serveur.
Meilleures pratiques à suivre avant de commencer la mise à niveau

Avant la mise à niveau, vérifiez que les éléments suivants sont en place :
1. Créer un compte d'administrateur général réser vé au cloud : ne procédez à aucune mise à niveau
avant de disposer d'un compte d'administrateur général réservé au cloud et à utiliser en cas d'urgence
lorsque vos agents d'authentification directe ne fonctionnent pas correctement. Découvrez comment ajouter
un compte d’administrateur général de type cloud uniquement. Cette étape est essentielle pour éviter que
votre locataire ne soit verrouillé.
2. Garantir une haute disponibilité : si ce n'est pas déjà fait, installez un deuxième agent d'authentification
autonome pour assurer la haute disponibilité des demandes de connexion, en utilisant ces instructions.
Mise à niveau de l’agent d’authentification sur votre serveur Azure AD

Connect
La mise à niveau d’Azure AD Connect doit précéder celle de l’agent d’authentification sur le même serveur. Sur
votre serveur principal et intermédiaire Azure AD Connect, procédez comme suit :
1. Procédez à la mise à niveau d'Azure AD Connect : suivez cet article pour obtenir la version la plus
récente d'Azure AD Connect.
2. Désinstallez la préversion de l'agent d'authentification : téléchargez ce script PowerShell et exécutez-
le en tant qu'administrateur sur le serveur.
3. Téléchargez la dernière version de l'agent d'authentification (version 1.5.389.0 ou ultérieure) :
connectez-vous au Centre d'administration Azure Active Directory à l'aide des informations d'identification
de l'administrateur général de votre locataire. Sélectionnez Azure Active Director y -> Azure AD
Connect -> authentification directe -> agent de téléchargement . Acceptez les conditions d’utilisation
et téléchargez la dernière version de l’agent d’authentification. Vous pouvez également télécharger l’agent
d’authentification ici.
4. Installez la dernière version de l'agent d'authentification : exécutez le fichier exécutable téléchargé à
l'étape 3. Fournissez les informations d’identification de l’administrateur général de votre locataire lorsque
5. Vérifiez que la version la plus récente a été installée : comme indiqué précédemment, accédez à
Panneau de configuration -> Programmes -> Programmes et fonctionnalités et vérifiez qu'il existe
une entrée « Agent d'authentification Microsoft Azure AD Connect ».
NOTE
Si vous consultez le panneau Authentification directe dans le Centre d’administration Azure Active Directory une fois les
étapes précédentes effectuées, vous pouvez voir deux entrées Agent d’authentification par serveur : une entrée indiquant
que l’agent d’authentification est actif et une autre indiquant qu’il est inactif . Ceci est normal. L’entrée indiquant inactif
est automatiquement supprimée après quelques jours.
Mise à niveau de l’agent d’authentification sur d’autres serveurs

Procédez comme suit pour mettre à niveau les agents d’authentification sur d’autres serveurs (lorsqu’Azure AD
Connect n’est pas installé) :
1. Désinstallez la préversion de l'agent d'authentification : téléchargez ce script PowerShell et exécutez-
le en tant qu'administrateur sur le serveur.
2. Téléchargez la dernière version de l'agent d'authentification (version 1.5.389.0 ou ultérieure) :
connectez-vous au Centre d'administration Azure Active Directory à l'aide des informations d'identification
de l'administrateur général de votre locataire. Sélectionnez Azure Active Director y -> Azure AD
Connect -> authentification directe -> agent de téléchargement . Acceptez les conditions d’utilisation
et téléchargez la dernière version.
3. Installez la dernière version de l'agent d'authentification : exécutez le fichier exécutable téléchargé à
l'étape 2. Fournissez les informations d’identification de l’administrateur général de votre locataire lorsque
4. Vérifiez que la version la plus récente a été installée : comme indiqué précédemment, accédez à
Panneau de configuration -> Programmes -> Programmes et fonctionnalités et vérifiez qu'il existe
une entrée intitulée « Agent d'authentification Microsoft Azure AD Connect ».
NOTE
Si vous consultez le panneau Authentification directe dans le Centre d’administration Azure Active Directory une fois les
étapes précédentes effectuées, vous pouvez voir deux entrées Agent d’authentification par serveur : une entrée indiquant
que l’agent d’authentification est actif et une autre indiquant qu’il est inactif . Ceci est normal. L’entrée indiquant inactif
est automatiquement supprimée après quelques jours.
Étapes suivantes
Déplacer la base de données Azure AD Connect de
SQL Server Express vers SQL Server
Ce document décrit comment déplacer la base de données Azure AD Connect du serveur local SQL Server
Express vers un serveur distant SQL Server. Vous pouvez utiliser les procédures suivantes pour réaliser cette
tâche.
À propos du scénario
Voici quelques informations sur le scénario. Dans ce scénario, la version (1.1.819.0) d’Azure AD Connect est
installée sur un contrôleur de domaine unique Windows Server 2016. Il utilise l’édition SQL Server 2012
Express comme base de données. La base de données sera déplacée vers un serveur SQL Server 2017.
Déplacer la base de données Azure AD Connect

Suivez les étapes suivantes pour déplacer la base de données Azure AD Connect vers un serveur SQL distant.
1. Sur le serveur Azure AD Connect, allez à Ser vices et arrêtez le service Microsoft Azure AD .
2. Localisez le dossier %ProgramFiles%\Microsoft Azure AD Sync\Data et copiez les fichiers
ADSync.mdf et ADSync_log.ldf dans le serveur SQL Server distant.
3. Redémarrez le service Microsoft Azure AD Sync sur le serveur Azure AD Connect.
4. Pour désinstaller Azure AD Connect, allez dans le Panneau de configuration - - Programmes -
Programmes et fonctionnalités. Sélectionnez Microsoft Azure AD Connect et cliquez sur Désinstaller dans
le coin supérieur.
5. Sur le serveur SQL distant, ouvrez SQL Server Management Studio.
6. Dans Bases de données, cliquez avec le bouton droit et sélectionnez Joindre.
7. À l’écran Joindre des bases de données , cliquez sur Ajouter et accédez au fichier ADSync.mdf.
Cliquez sur OK .
8. Une fois la base de données jointe, retournez sur le serveur Azure AD Connect et installez Azure AD
Connect.
9. Une fois l’installation du fichier MSI terminée, l’Assistant Azure AD Connect démarre le programme
d’installation en mode Express. Fermez la fenêtre en cliquant sur l’icône Quitter.
10. Démarrez une nouvelle invite de commandes ou session PowerShell. Accédez au dossier
<drive>\program files\Microsoft Azure AD Connect. Exécutez la commande .\AzureADConnect.exe
/useexistingdatabase pour démarrer l’Assistant Azure AD Connect en mode d’installation « Utiliser une
base de données existante ».
11. L’écran d’accueil d’Azure AD Connect s’affiche. Après avoir accepté les termes du contrat de licence et la
déclaration de confidentialité, cliquez sur Continuer .
12. Dans l’écran Installer les composants nécessaires , l’option Utiliser un SQL Ser ver existant est
activée. Spécifiez le nom du serveur SQL qui héberge la base de données ADSync. Si l’instance du moteur
SQL utilisée pour héberger la base de données ADSync n’est pas l’instance par défaut sur le serveur SQL,
vous devez spécifier le nom de l’instance du moteur SQL. De plus, si l’exploration SQL n’est pas activée,
vous devez également spécifier le numéro de port de l’instance du moteur SQL. Par exemple :
13. Dans l’écran Se connecter à Azure AD , vous devez fournir les informations d’identification d’un
administrateur général de votre annuaire Azure AD. Nous vous recommandons d’utiliser un compte du
domaine onmicrosoft.com par défaut. Ce compte est uniquement utilisé pour créer un compte de service
dans Azure AD et n’est plus utilisé une fois l’assistant terminé.
14. Dans l’écran Connexion de vos annuaires , une icône de croix rouge est affichée en regard de la forêt
AD existante configurée pour la synchronisation d’annuaire. Pour synchroniser les modifications à partir
d’une forêt AD locale, un compte de domaine AD DS est nécessaire. L’Assistant Azure AD Connect ne peut
pas récupérer les informations d’identification du compte AD DS stockées dans la base de données
ADSync, car elles sont chiffrées et peuvent uniquement être déchiffrées par le serveur Azure AD Connect
précédent. Cliquez sur Modifier les informations d’identification pour spécifier le compte AD DS
pour la forêt AD.
15. Dans la boîte de dialogue contextuelle, vous pouvez (i) entrer les informations d’identification d’un
administrateur d’entreprise et laisser Azure AD Connect créer le compte AD DS pour vous, ou (ii) créer
vous-même le compte AD DS et fournir ses informations d’identification à Azure AD Connect. Une fois
que vous avez sélectionné une option et fourni les informations d’identification nécessaires, cliquez sur
OK pour fermer la boîte de dialogue contextuelle.
16. Une fois les informations d’identification fournies, la croix rouge est remplacée par une coche verte.
Cliquez sur Suivant .
17. Dans l’écran Prêt à configurer , cliquez sur Installer .

18. Une fois l’installation terminée, le serveur Azure AD Connect est automatiquement activé pour le Mode
de préproduction. Nous vous recommandons de vérifier la présence de modifications inattendues dans la
configuration du serveur et les exportations en attente avant de désactiver le Mode de préproduction.
Étapes suivantes
Installer Azure AD Connect à l’aide d’autorisations administrateur déléguées SQL
Azure AD Connect : Quand vous avez un locataire
existant
La plupart des rubriques sur l’utilisation d’Azure AD Connect suppose que vous démarrez avec un nouveau
client Azure AD qui ne contient aucun utilisateur ni autres objets. Mais si vous avez démarré avec un client Azure
AD, auquel vous avez ajouté des utilisateurs et d’autres objets, et que vous souhaitez désormais utiliser Connect,
alors cette rubrique est faite pour vous.
Concepts de base
Un objet dans Azure AD est soit contrôlé dans le cloud (Azure AD), soit local. Pour un objet unique, vous ne
pouvez pas gérer certains attributs en local et d’autres attributs dans Azure AD. Chaque objet dispose d’un
indicateur qui indique où l’objet est géré.
Vous pouvez gérer certains utilisateurs en local et d’autres dans le cloud. Un scénario courant pour cette
configuration est une organisation qui regroupe des comptables et des commerciaux. Les comptables ont un
compte AD local, mais les commerciaux n’en ont pas. Ils disposent d’un compte dans Azure AD. Vous devez alors
gérer certains utilisateurs en local et d’autres dans Azure AD.
Si vous avez commencé à gérer des utilisateurs dans Azure AD qui se trouvent également dans un répertoire AD
local et que vous souhaitez ultérieurement utiliser Connect, il existe des considérations supplémentaires que
vous devez prendre en compte.
Synchroniser avec les utilisateurs existants dans Azure AD

Lorsque vous installez Azure AD Connect et démarrez la synchronisation, le service de synchronisation Azure
AD (dans Azure AD) effectue une vérification de chaque nouvel objet et essaie de trouver un objet existant
correspondant. Il existe trois attributs utilisés pour ce processus : userPrincipalName , proxyAddresses et
sourceAnchor /immutableID . Une correspondance avec userPrincipalName et avec proxyAddresses est
appelée une correspondance souple . Une correspondance avec sourceAnchor est appelée une
correspondance exacte . Pour l’attribut proxyAddresses , seule la valeur avec SMTP : , c’est-à-dire l’adresse e-
mail principale, est utilisée pour l’évaluation.
La correspondance est évaluée uniquement pour les nouveaux objets provenant de Connect. Si vous modifiez
un objet existant afin qu’il corresponde à l’un de ces attributs, une erreur s’affiche à la place.
Si AD Azure détecte un objet dans lequel les valeurs d’attribut sont les mêmes pour un objet provenant de
Connect et qui est déjà présent dans Azure AD, alors l’objet dans Azure AD est pris en charge par Connect. L’objet
précédemment géré dans le cloud est indiqué comme étant géré en local. Tous les attributs dans Azure AD avec
une valeur dans le répertoire AD local sont remplacés par la valeur locale.
WARNING
Étant donné que tous les attributs dans Azure AD vont être remplacés par la valeur locale, assurez-vous que vous
disposez de bonnes données locales. Par exemple, si vous avez uniquement une adresse e-mail gérée dans Microsoft 365
et que vous ne l’avez pas conservée à jour dans AD DS en local, alors vous perdrez toutes les valeurs dans Azure
AD/Microsoft 365 qui ne figurent pas dans AD DS.
IMPORTANT
Si vous utilisez la synchronisation de mot de passe, qui est toujours utilisée par la configuration rapide, alors le mot de
passe dans Azure AD est remplacé par le mot de passe dans le répertoire AD local. Si vos utilisateurs sont habitués à
gérer des mots de passe différents, vous devez alors les informer qu’ils doivent utiliser le mot de passe local une fois
Connect installé.
La section précédente et l’avertissement qu’elle contient doivent être pris en compte lors de la planification. Si
vous avez effectué de nombreuses modifications dans Azure AD qui ne sont pas reflétées dans AD DS en local,
vous devez alors planifier comment renseigner AD DS avec les valeurs mises à jour avant de synchroniser vos
objets avec Azure AD Connect.
Si vous avez exécuté la correspondance de vos objets avec une correspondance souple, l’attribut sourceAnchor
est ajouté à l’objet dans Azure AD afin qu’une correspondance exacte soit utilisée ultérieurement.
IMPORTANT
Microsoft déconseille fortement de synchroniser des comptes locaux avec des comptes d’administration préexistants dans
Correspondance exacte et correspondance souple

Pour une nouvelle installation de Connect, il n’existe aucune différence pratique entre une correspondance
souple et une correspondance exacte. La différence réside dans une situation de récupération d’urgence. Si votre
serveur avec Azure AD Connect a connu une défaillance, vous pouvez réinstaller une nouvelle instance sans
perdre de données. Un objet avec un attribut sourceAnchor est envoyé à Connect lors de l’installation initiale. La
correspondance peut ensuite être évaluée par le client (Azure AD Connect), ce qui est beaucoup plus rapide que
de faire la même chose dans Azure AD. Une correspondance exacte est évaluée à la fois par Connect et par
Azure AD. Une correspondance souple n’est évaluée que par Azure AD.
Nous avons ajouté une option de configuration pour désactiver la fonctionnalité de correspondance souple dans
Azure AD Connect. Nous conseillons aux clients de désactiver la correspondance souple, sauf s’ils en ont besoin
pour prendre en charge des comptes Cloud uniquement. Cet article montre comment désactiver la
correspondance souple.
Objets autres que des utilisateurs
Pour les groupes et les contacts activés pour le courrier, vous pouvez établir une correspondance souple en
fonction de proxyAddresses. La correspondance exacte n’est pas applicable dans la mesure où vous pouvez
seulement mettre à jour sourceAnchor/immutableID (à l’aide de PowerShell) sur les utilisateurs uniquement.
Pour les groupes qui ne sont pas activés pour le courrier, il n’existe actuellement aucune prise en charge pour la
correspondance souple ou la correspondance exacte.
Considérations relatives au rôle d’administrateur
Pour empêcher les utilisateurs locaux non approuvés d’établir une correspondance avec un utilisateur cloud qui
a un rôle d’administrateur, Azure AD Connect ne met pas en correspondance des objets utilisateur locaux avec
des objets qui ont un rôle d’administrateur. Il s’agit du comportement par défaut. Pour contourner ce
comportement, vous pouvez procéder comme suit :
1. Supprimez les rôles d’annuaire de l’objet utilisateur cloud uniquement.
2. En cas d’échec d’une tentative de synchronisation des utilisateurs, supprimez définitivement l’objet mis en
quarantaine dans le cloud.
3. Déclenchez une synchronisation.
4. Rétablissez éventuellement les rôles d’annuaire dans l’objet utilisateur cloud une fois que la mise en
correspondance s’est produite.
Créer un nouveau répertoire Active Directory local à partir des
données dans Azure AD
Certains clients démarrent avec une solution cloud uniquement avec Azure AD et ils ne disposent pas d’un
répertoire AD local. Ensuite, ils souhaitent consommer des ressources locales et créer un répertoire AD local
basé sur les données d’Azure AD. Azure AD Connect ne peut pas vous aider dans ce scénario. Il ne crée pas
d’utilisateurs locaux et il ne peut pas définir le mot de passe local pour qu’il soit le même que dans Azure AD.
Si la seule raison pour laquelle vous souhaitez ajouter un répertoire AD local est pour la prise en charge
d’applications métier, vous devrez peut-être envisager d’utiliser les services de domaine Azure AD à la place.
Étapes suivantes
Étapes suivantes et gestion d’Azure AD Connect
Utilisez les procédures opérationnelles dans cet article pour personnaliser Azure Active Directory (Azure AD)
Connect pour l’adapter aux besoins et aux spécifications de votre organisation.
Ajout d’administrateurs de synchronisation supplémentaires

Par défaut, seul l’utilisateur qui a effectué l’installation et les administrateurs locaux est en mesure de gérer le
moteur de synchronisation installé. Pour que d’autres personnes puissent accéder au moteur de synchronisation
et en assurer la gestion, localisez le groupe nommé ADSyncAdmins sur le serveur local et ajoutez ces personnes
à ce groupe.
Attribution des licences aux utilisateurs Azure AD Premium et

Enterprise Mobility Suite
Maintenant que vos utilisateurs ont été synchronisés avec le cloud, vous devez leur attribuer une licence afin
qu'ils puissent utiliser des applications cloud telles que Microsoft 365.
Pour l’attribution d’une licence Azure AD Premium ou Enterprise Mobility Suite
1. Connectez-vous au portail Azure en tant qu’administrateur.
2. Sélectionnez Active Director y à gauche.
3. Sur la page Active Director y , double-cliquez sur le répertoire qui contient les utilisateurs que vous
souhaitez configurer.
4. En haut de la page du répertoire, sélectionnez Licences .
5. Sur la page Licences , sélectionnez Active Director y Premium ou Enterprise Mobility Suite , puis
cliquez sur Attribuer .
6. Dans la boîte de dialogue, sélectionnez les utilisateurs auxquels vous souhaitez attribuer des licences, puis
cliquez sur l'icône de coche pour enregistrer les modifications.
Vérification de la tâche de synchronisation planifiée

Utilisez le portail Azure pour vérifier l’état d’une synchronisation.
Pour la vérification de la tâche de synchronisation planifiée
1. Connectez-vous au portail Azure en tant qu’administrateur.
2. Sélectionnez Active Director y à gauche.
3. Sélectionnez Azure AD Connect à gauche
4. En haut de la page, notez la dernière synchronisation.
Lancement d’une tâche de synchronisation planifiée

Si vous devez exécuter une tâche de synchronisation, effectuez les opérations suivantes :
1. Double-cliquez sur le raccourci Bureau Azure AD Connect pour démarrer l’Assistant.
3. Dans l’écran des tâches, sélectionnez Personnaliser les options de synchronisation , puis cliquez sur
Suivant
4. Entrez vos informations d’identification Azure AD.
5. Cliquez sur Suivant . Cliquez sur Suivant . Cliquez sur Suivant .
6. Dans l’écran Prêt à configurer , vérifiez que la case Démarrez le processus de synchronisation une
fois la configuration terminée est cochée.
Pour plus d’informations sur le planificateur de synchronisation Azure AD Connect, consultez Planificateur Azure
AD Connect.
Tâches supplémentaires disponibles dans Azure AD Connect

Après l’installation initiale d’Azure AD Connect, vous pouvez toujours redémarrer l’Assistant depuis la page de
démarrage ou le raccourci du bureau Azure AD Connect. Vous remarquerez qu’en passant à nouveau par
l’Assistant de nouvelles options apparaissent sous forme de tâches supplémentaires.
Le tableau suivant fournit un résumé de ces tâches et une brève description de chacune d’elles.
TÂ C H E SUP P L ÉM EN TA IRE DESC RIP T IO N
Paramètres de confidentialité Afficher les données de télémétrie qui sont partagées avec
Microsoft.
TÂ C H E SUP P L ÉM EN TA IRE DESC RIP T IO N
Afficher la configuration actuelle Afficher votre solution Azure AD Connect actuelle. Cela inclut
les paramètres généraux, les répertoires synchronisés et les
paramètres de synchronisation.
Personnalisation des options de synchronisation Modifier la configuration actuelle, notamment par l’ajout de
forêts Active Directory supplémentaires à la configuration ou
l’activation d’options de synchronisation telles que
l’utilisateur, le groupe, l’appareil ou le mot de passe en
écriture différée.
Tâche Configurer les options de l’appareil Options de l’appareil disponibles pour la synchronisation
Actualiser le schéma d’annuaire Vous permet d’ajouter de nouveaux objets d’annuaire en

local pour la synchronisation
Configurer le mode de préproduction Réalisez un déploiement intermédiaire des informations qui

ne sont pas immédiatement synchronisées et ne sont pas
exportées vers Azure AD ou l’Active Directory local. Cette
fonctionnalité vous permet d’afficher un aperçu des
synchronisations avant qu’elles ne s’effectuent.
Modifier la connexion de l’utilisateur Modifier la méthode d’authentification que les utilisateurs

emploient pour se connecter
Gérer la fédération Gérer votre infrastructure AD FS, renouveler les certificats et

ajouter des serveurs AD FS
Résolution des problèmes Aide pour la résolution des problèmes liés à Azure AD
Connect
Étapes suivantes
Désinstaller Azure AD Connect
Ce document explique comment désinstaller Azure AD Connect.
Désinstallation d’Azure AD Connect du serveur

La première chose à faire est de supprimer Azure AD Connect du serveur sur lequel il s’exécute. Utiliser les
étapes suivantes :
1. Sur le serveur sur lequel s’exécute Azure AD Connect, accédez à Panneau de configuration .
2. Cliquez sur Désinstaller un programme
4. Cliquez sur Oui dans l’invite pour confirmer.

5. L’écran Azure AD Connect s’affiche. Cliquez sur Supprimer .
6. Une fois cette action terminée, cliquez sur Quitter .
7.
8. Dans le Panneau de configuration , cliquez sur Actualiser . Tous les composants doivent avoir été
supprimés.
Étapes suivantes
Installer Azure AD Connect à l’aide d’autorisations administrateur déléguées SQL
Principes de conception Azure AD Connect
L’objectif de ce document est de décrire les domaines qui doivent être pris en compte lors de la configuration
d’Azure AD Connect. Il s’agit d’une exploration approfondie de certains aspects. Ces concepts sont également
décrits brièvement dans d’autres documents.
sourceAnchor
L’attribut sourceAnchor est défini en tant qu’ attribut immuable pendant la durée de vie d’un objet. Il identifie de
façon univoque un objet comme étant le même objet local et dans Azure AD. L’attribut est également appelé
immutableId et les deux noms sont interchangeables.
Le mot « immuable », signifiant « qui ne peut pas être changé », est important dans ce document. Étant donné
que la valeur de cet attribut ne peut pas être changée une fois qu’elle a été définie, il est important de choisir une
conception qui prend en charge votre scénario.
L’attribut est utilisé pour les scénarios suivants :
Quand un nouveau serveur de moteur de synchronisation est créé ou recréé après un scénario de
récupération d’urgence, cet attribut lie les objets existants dans Azure AD à des objets locaux.
Si vous passez d’une identité de cloud uniquement à un modèle d’identité synchronisé, alors cet attribut
permet une correspondance exacte et concrète des objets existants dans Azure AD avec des objets locaux.
Si vous utilisez la fédération, alors cet attribut est utilisé avec userPrincipalName dans la revendication
pour identifier un utilisateur de façon univoque.
Cette rubrique traite de sourceAnchor seulement par rapport aux utilisateurs. Les mêmes règles s’appliquent à
tous les types d’objets, mais le problème ne se pose généralement que pour des utilisateurs.
Sélection d’un attribut sourceAnchor approprié
La valeur de l’attribut doit respecter les règles suivantes :
sa longueur doit être inférieure à 60 caractères
les caractères autres que a-z, A-Z ou 0-9 sont codés et comptabilisés comme 3 caractères
elle ne doit pas contenir les caractères spéciaux suivants : \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ' ; : , [ ] " @ _
elle doit être globalement unique
elle doit être une chaîne, un entier ou une valeur binaire
elle ne doit pas être basée sur le nom de l’utilisateur, car celui-ci est susceptible de changer
elle ne doit pas respecter la casse et doit éviter les valeurs qui peuvent varier selon la casse
elle doit être assignée lorsque l’objet est créé.
Si le sourceAnchor sélectionné n’est pas de type chaîne, alors Azure AD Connect encode la valeur de l’attribut en
base 64 pour garantir qu’aucun caractère spécial n’apparaît. Si vous utilisez un serveur de fédération autre
qu’ADFS, assurez-vous que votre serveur a également la capacité d’encoder la valeur de l’attribut en base 64.
L’attribut sourceAnchor respecte la casse. La valeur « JohnDoe » n’est pas le même que « johndoe ». Mais vous
ne devez pas avoir deux objets différents avec uniquement une différence de casse.
Si vous avez une seule forêt locale, alors l’attribut que vous devez utiliser est objectGUID . C’est également
l’attribut utilisé quand vous utilisez la configuration rapide dans Azure AD Connect, ainsi que l’attribut utilisé par
DirSync.
Si vous avez plusieurs forêts et que vous ne déplacez pas d’utilisateurs entre les forêts et les domaines , alors
objectGUID est un attribut approprié à utiliser même dans ce cas.
Si vous déplacez des utilisateurs entre des forêts et des domaines, alors vous devez trouver un attribut qui ne
change pas ou qui peut être déplacé en même temps que les utilisateurs. Une approche recommandée est
d'introduire un attribut synthétique. Un attribut qui peut contenir quelque chose qui ressemble à un GUID serait
approprié. Lors de la création d’un objet, un nouveau GUID est créé et affecté à l’utilisateur. Une règle de
synchronisation personnalisée peut être créée dans le serveur du moteur de synchronisation pour générer cette
valeur selon objectGUID et mettre à jour l’attribut sélectionné dans ADDS. Quand vous déplacez l’objet, veillez
à copier également le contenu de cette valeur.
Une autre solution consiste à choisir un attribut existant, dont vous êtes sûr qu’il ne changera pas. employeeID
est un des attributs couramment utilisés. Si vous envisagez d’opter pour un attribut contenant des lettres,
assurez-vous qu’il n’y a aucun risque de changement de la casse (majuscule ou minuscule) pour la valeur de
l’attribut. Des attributs inappropriés qui ne doivent pas être utilisés sont notamment ceux qui ont le nom de
l’utilisateur. En cas de mariage ou de divorce, le nom risque de changer, ce qui n’est pas autorisé pour cet
attribut. C'est également une raison pour laquelle il n'est même pas possible de sélectionner des attributs
comme userPrincipalName , mail et targetAddress dans l'Assistant Installation d'Azure AD Connect. Ces
attributs contiennent également le caractère « @ », qui n’est pas autorisé dans sourceAnchor.
Changement de l’attribut sourceAnchor
La valeur de l’attribut sourceAnchor ne peut pas être changée une fois que l’objet a été créé dans Azure AD et
que l’identité est synchronisée.
Pour cette raison, les restrictions suivantes s’appliquent à Azure AD Connect :
L’attribut sourceAnchor peut être défini seulement lors de l’installation initiale. Si vous exécutez une nouvelle
fois l’Assistant Installation, cette option est en lecture seule. Si vous devez changer ce paramètre, alors vous
devez effectuer une désinstallation et une réinstallation.
Si vous installez un autre serveur Azure AD Connect, vous devez sélectionner le même attribut sourceAnchor
que celui qui a été précédemment utilisé. Si vous avez précédemment utilisé DirSync et que vous passez à
Azure AD Connect, vous devez utiliser objectGUID , car il s'agit de l’attribut utilisé par DirSync.
Si la valeur de sourceAnchor est changée après que l’objet a été exporté vers Azure AD, alors Azure AD
Connect Sync génère une erreur et n’autorise plus de modifications sur cet objet avant que le problème ait
été résolu et que sourceAnchor soit replacé à sa valeur précédente dans le répertoire source.
Utilisation de ms-DS-ConsistencyGuid en tant qu’attribut

sourceAnchor
Par défaut, Azure AD Connect (version 1.1.486.0 ou antérieure) utilise objectGUID comme attribut sourceAnchor.
ObjectGUID est généré par le système. Vous ne pouvez pas spécifier sa valeur lors de la création d’objets Active
Directory locaux. Comme expliqué dans la section sourceAnchor, il existe des scénarios où vous devez spécifier
la valeur sourceAnchor. Si les scénarios ne s’appliquent pas à vous, vous devez utiliser un attribut AD
configurable (par exemple, msDS-ConsistencyGuid) en tant qu’attribut sourceAnchor.
Azure AD Connect (version 1.1.524.0 ou ultérieure) facilite l’utilisation de l’attribut ms-DS-ConsistencyGuid en
tant qu’attribut sourceAnchor. Lorsque vous utilisez cette fonctionnalité, Azure AD Connect configure
automatiquement les règles de synchronisation pour :
1. Utiliser ms-DS-ConsistencyGuid en tant qu’attribut sourceAnchor pour les objets utilisateur. ObjectGUID
est utilisé pour d’autres types d’objets.
2. Pour tout objet utilisateur AD local dont l’attribut ms-DS-ConsistencyGuid n’est pas spécifié, Azure AD
Connect réécrit sa valeur objectGUID dans l’attribut ms-DS-ConsistencyGuid dans l’annuaire Active
Directory local. Une fois l’attribut ms-DS-ConsistencyGuid spécifié, Azure AD Connect exporte l’objet vers
Azure AD.
NOTE
Une fois qu’un objet Active Directory local est importé dans Azure AD Connect (c’est-à-dire, importé dans l’espace de
connecteur AD et projeté dans le Metaverse), vous ne pouvez plus modifier sa valeur sourceAnchor. Pour spécifier la
valeur sourceAnchor pour un objet AD local donné, configurez son attribut ms-DS-ConsistencyGuid avant son
importation dans Azure AD Connect.
Autorisation requise
Pour que cette fonctionnalité opère, le compte AD DS utilisé pour effectuer la synchronisation avec l’annuaire
Active Directory local doit disposer d’une autorisation en écriture sur l’attribut ms-DS-ConsistencyGuid dans
l’annuaire Active Directory local.
Comment activer la fonctionnalité ConsistencyGuid - nouvelle installation
Vous pouvez activer l’utilisation de ConsistencyGuid en tant que sourceAnchor pendant une nouvelle
installation. Cette section décrit en détail l’installation rapide et l’installation personnalisée.
NOTE
Seules les versions plus récentes d’Azure AD Connect (1.1.524.0 et ultérieures) prennent en charge l’utilisation de
ConsistencyGuid en tant que sourceAnchor lors d’une nouvelle installation.
Comment activer la fonctionnalité ConsistencyGuid

Installation rapide
Lorsque vous installez Azure AD Connect en mode Express, l’Assistant Azure AD Connect détermine
automatiquement l’attribut AD le plus approprié à utiliser en tant qu’attribut sourceAnchor à l’aide de la logique
suivante :
Tout d’abord, l’Assistant Azure AD Connect interroge votre client Azure AD pour extraire l’attribut Active
Directory utilisé comme attribut sourceAnchor lors de la précédente installation d’Azure AD Connect (le
cas échéant). Si cette information est disponible, Azure AD Connect utilise le même attribut AD.
NOTE
Seules les versions plus récentes d’Azure AD Connect (1.1.524.0 et ultérieures) stockent des informations dans
votre locataire Azure AD concernant l’attribut sourceAnchor utilisé pendant l’installation. Les versions antérieures
d’Azure AD Connect ne le font pas.
Si aucune information n’est disponible sur l’attribut sourceAnchor utilisé, l’Assistant vérifie l’état de
l’attribut ms-DS-ConsistencyGuid dans votre annuaire Active Directory local. Si l’attribut n’est configuré
sur aucun objet dans l’annuaire, l’Assistant utilise l’attribut ms-DS-ConsistencyGuid en tant qu’attribut
sourceAnchor. Si l’attribut est configuré sur un ou plusieurs objets dans l’annuaire, l’Assistant en déduit
que l’attribut est utilisé par d’autres applications et n’est pas adapté en tant qu’attribut sourceAnchor...
Dans ce cas, l’Assistant revient à l’utilisation d’objectGUID comme attribut sourceAnchor.
Une fois l’attribut sourceAnchor choisi, l’Assistant stocke les informations dans votre client Azure AD. Les
informations seront utilisées dans le cadre d’une installation future d’Azure AD Connect.
Une fois l’installation rapide terminée, l’Assistant vous informe concernant l’attribut sélectionné comme attribut
sourceAnchor.
Installation personnalisée
Lorsque vous installez Azure AD Connect en mode personnalisé, l’Assistant Azure AD Connect fournit deux
options lorsque vous configurez l’attribut sourceAnchor :
Let Azure manage the source anchor for me (Laisser Azure Sélectionnez cette option si vous souhaitez qu’Azure AD
gérer l’ancre source pour moi) sélectionne l’attribut pour vous. Si vous sélectionnez cette
option, l’Assistant Azure AD Connect applique la même
logique de sélection de l’attribut sourceAnchor que celle
utilisée lors de l’installation rapide. Comme pour l’installation
rapide, L’Assistant vous indique quel attribut a été
sélectionné comme attribut sourcAnchor une fois
l’installation personnalisée terminée.
Un attribut spécifique Sélectionnez cette option si vous souhaitez spécifier un

attribut AD existant comme attribut sourceAnchor.
Comment activer la fonctionnalité ConsistencyGuid - déploiement existant

Si vous avez un déploiement Azure AD Connect existant qui utilise objectGUID comme attribut Source Anchor,
vous pouvez faire en sorte qu’il utilise ConsistencyGuid à la place.
NOTE
Seules les versions plus récentes d’Azure AD Connect (1.1.552.0 et ultérieures) prennent en charge le passage
d’ObjectGuid à ConsistencyGuid en tant qu’attribut Ancre source.
Pour passer d’objectGUID à ConsistencyGuid en tant qu’attribut Ancre source :

1. Démarrez l’Assistant Azure AD Connect et cliquez sur Configurer pour accéder à l’écran Tâches.
2. Sélectionnez l’option de tâche Configurer l’ancre source et cliquez sur Suivant .
3. Entrez vos informations d’identification d’administrateur Azure AD et cliquez sur Suivant .

4. L’Assistant Azure AD Connect vérifie l’état de l’attribut ms-DS-ConsistencyGuid dans votre annuaire
Active Directory local. Si l’attribut n’est configuré sur aucun objet de l’annuaire, Azure AD Connect conclut
qu’aucune autre application n’utilise actuellement l’attribut et qu’il peut être utilisé comme attribut Ancre
Source en toute sécurité. Cliquez sur Suivant pour continuer.
5. Dans l’écran Prêt à configurer , cliquez sur Configurer pour modifier la configuration.
6. Une fois la configuration terminée, l’Assistant indique que ms-DS-ConsistencyGuid est maintenant utilisé
en tant qu’attribut sourceAnchor.
Pendant l’analyse (étape 4), si l’attribut est configuré sur un ou plusieurs objets de l’annuaire, l’Assistant en
déduit que l’attribut est utilisé par une autre application et retourne une erreur, comme illustré dans le
diagramme ci-dessous. Cette erreur peut également se produire quand vous avez déjà activé la fonctionnalité
ConsistencyGuid sur votre serveur principal Azure AD Connect et que vous essayez de faire de même sur votre
serveur de préproduction.
Si vous êtes certain que l'attribut n'est pas utilisé par d'autres applications, vous pouvez éviter cette erreur en
redémarrant l'Assistant Azure AD Connect avec le commutateur /SkipLdapSearch spécifié. Pour cela, exécutez
la commande suivante dans l’invite de commandes :
"c:\Program Files\Microsoft Azure Active Directory Connect\AzureADConnect.exe" /SkipLdapSearch
Impact sur AD FS d’une configuration de fédération tierce

Si vous utilisez Azure AD Connect pour gérer un déploiement d’AD FS local, Azure AD Connect met
automatiquement à jour les règles de revendication pour utiliser le même attribut AD en tant qu’attribut
sourceAnchor. Cela garantit que la revendication ImmutableID générée par ADFS est cohérente avec les valeurs
de sourceAnchor exportées vers Azure AD.
Si vous gérez AD FS en dehors d’Azure AD Connect ou si vous utilisez des serveurs de fédération tiers pour
l’authentification, vous devez mettre à jour manuellement les règles de revendication pour que la revendication
ImmutableID soit cohérente avec les valeurs de sourceAnchor exportées vers Azure AD, comme décrit dans la
section Modifier les règles de revendication AD FS de l’article. Une fois l’installation terminée, L’Assistant renvoie
l’avertissement suivant :
Ajout d’annuaires à un déploiement existant

Supposons que vous avez déployé Azure AD Connect avec la fonctionnalité ConsistencyGuid activée, et que
vous souhaitez ajouter un annuaire au déploiement. Lorsque vous tentez d’ajouter l’annuaire, l’Assistant Azure
AD Connect vérifie l’état de l’attribut ms-DS-ConsistencyGuid dans l’annuaire. Si l’attribut est configuré sur un
ou plusieurs objets dans l’annuaire, l’Assistant en déduit que l’attribut est utilisé par d’autres applications et
retourne une erreur, comme illustré dans la diagramme ci-dessous. Si vous êtes certain que l'attribut n'est pas
utilisé par d'autres applications, vous pouvez éviter cette erreur en redémarrant l'Assistant Azure AD Connect
avec le commutateur /SkipLdapSearch spécifié, comme décrit ci-dessus, ou en contactant le support pour plus
d'informations.
Authentification dans Azure AD
Lorsque vous intégrez votre annuaire local à Azure AD, il est important de bien comprendre comment les
paramètres de synchronisation peuvent affecter la manière dont les utilisateurs s’authentifient. Azure AD utilise
userPrincipalName (UPN) pour authentifier l’utilisateur. Toutefois, lorsque vous synchronisez vos utilisateurs,
vous devez choisir avec soin l’attribut à utiliser pour la valeur de userPrincipalName.
Choix de l’attribut de userPrincipalName
Lorsque vous sélectionnez l’attribut fournissant la valeur d’UPN à utiliser dans Azure, vous devez vous assurer
que :
Les valeurs de l’attribut sont conformes à la syntaxe UPN (RFC 822), c’est-à-dire au format
nom_utilisateur@domaine.
Le suffixe des valeurs correspond à l’un des domaines personnalisés vérifiés dans Azure AD
Dans la configuration rapide, le choix supposé de l’attribut est userPrincipalName. Si l’attribut
userPrincipalName ne contient pas la valeur que vous souhaitez que vos utilisateurs utilisent pour se connecter
à Azure, alors choisissez Installation personnalisée .
État du domaine personnalisé et UPN
Il est important de s’assurer qu’il existe un domaine vérifié pour le suffixe UPN.
John est un utilisateur de contoso.com. Vous souhaitez que John utilise l’UPN local john@contoso.com pour se
connecter à Azure une fois que vous avez synchronisé les utilisateurs vers votre annuaire Azure AD
contoso.onmicrosoft.com. Pour ce faire, vous devez ajouter et vérifier contoso.com comme domaine
personnalisé dans Azure AD avant de commencer la synchronisation des utilisateurs. Si le suffixe UPN de John,
par exemple contoso.com, ne correspond pas à un domaine vérifié dans Azure AD, alors Azure AD remplace le
suffixe UPN par contoso.onmicrosoft.com.
Domaines locaux non routables et UPN pour Azure AD
Certaines organisations ont des domaines non routables, comme contoso.local, ou de simples domaines à
étiquette unique, comme contoso. Dans Azure AD, vous n’êtes pas en mesure de vérifier un domaine non
routable. Azure AD Connect peut uniquement se synchroniser sur un domaine vérifié dans Azure AD. Lorsque
vous créez un répertoire Azure AD, il crée un domaine routable qui devient le domaine par défaut de votre
Azure AD, par exemple contoso.onmicrosoft.com. Par conséquent, il devient nécessaire de vérifier tous les autres
domaines routables dans un scénario de ce type, si vous ne souhaitez pas effectuer de synchronisation avec le
domaine par défaut onmicrosoft.com.
Pour plus d’informations sur l’ajout et la vérification de domaines, consultez Ajouter un nom de domaine
personnalisé à Azure Active Directory .
Azure AD Connect détecte si vous exécutez un environnement de domaine non routable et vous avertit en
temps utile si vous tentez de poursuivre la configuration rapide. Si votre domaine n’est pas routable, il est
probable que les UPN des utilisateurs aient également des suffixes non routables. Par exemple, si votre domaine
est contoso.local, Azure AD Connect vous propose d’utiliser des paramètres personnalisés plutôt que la
configuration rapide. Avec les paramètres personnalisés, vous êtes en mesure de spécifier l’attribut à utiliser
comme UPN pour la connexion à Azure une fois les utilisateurs synchronisés avec Azure AD.
Étapes suivantes
Topologies pour Azure AD Connect
Cet article décrit diverses topologies locales et Azure Active Directory (Azure AD) qui utilisent Azure AD Connect
Sync comme solution d’intégration clé. Cet article inclut les configurations prises en charge et celles qui ne le
sont pas.
Voici la légende des images de l’article :
DESC RIP T IO N SY M B O L E
Forêt Active Directory locale
Active Directory local avec importation filtrée
Serveur Azure AD Connect Sync
« Mode intermédiaire » du serveur Azure AD Connect Sync
GALSync avec Forefront Identity Manager (FIM) 2010 ou

Microsoft Identity Manager (MIM) 2016
Serveur Azure AD Connect Sync, détaillé
Azure AD
Scénario non pris en charge
IMPORTANT
configurations ou des actions documentées de façon formelle. Ces configurations ou actions peuvent entraîner un état de
synchronisation Azure AD Connect incohérent ou non pris en charge. Par conséquent, Microsoft ne peut pas fournir de
support technique pour ces déploiements.
Une seule forêt, un seul client Azure AD

La topologie la plus courante est une forêt locale unique, avec un ou plusieurs domaines, et un locataire Azure
AD unique. L’authentification Azure AD est effectuée avec la synchronisation du hachage de mot de passe. Il
s’agit de la seule topologie prise en charge par l’installation rapide d’Azure AD Connect.
Une seule forêt, plusieurs serveurs de synchronisation connectés à un client Azure AD
Le fait de disposer de plusieurs serveurs Azure AD Connect Sync connectés à un même locataire Azure AD n’est
pas pris en charge (à l’exception d’un serveur intermédiaire). Ceci n’est pas pris en charge, même si ces serveurs
sont configurés pour se synchroniser avec un ensemble d’objets mutuellement exclusifs. Vous avez peut-être
considéré cette topologie si vous ne parvenez pas à atteindre l’ensemble des domaines d’une forêt à partir d’un
seul serveur ou si vous souhaitez répartir une charge entre plusieurs serveurs.
Plusieurs forêts, un seul client Azure AD
De nombreuses organisations possèdent des environnements comportant plusieurs forêts Active Directory
locales. Il existe plusieurs raisons de déployer plus d’une forêt Active Directory locale. Par exemple : des modèles
avec des forêts de ressources de comptes et la conséquence d’une fusion ou d’une acquisition.
Lorsque vous avez plusieurs forêts, toutes les forêts doivent être accessibles par un même serveur Azure AD
Connect Sync. Le serveur doit être joint à un domaine. Si nécessaire pour atteindre toutes les forêts, vous
pouvez placer le serveur dans un réseau de périmètre (également appelé DMZ, zone démilitarisée et sous-
réseau filtré).
L’Assistant d’installation d’Azure AD Connect offre plusieurs options différentes pour consolider les utilisateurs
qui sont représentés dans plusieurs forêts. L’objectif est de représenter un utilisateur une seule fois dans Azure
AD. Il existe certaines topologies courantes que vous pouvez configurer dans le chemin d’installation
personnalisé de l’Assistant d’installation. Sur la page Identification unique de vos utilisateurs , sélectionnez
l’option correspondante qui représente votre topologie. La consolidation est configurée uniquement pour les
utilisateurs. Les groupes en doublon ne sont pas consolidés avec la configuration par défaut.
Des topologies courantes sont présentées dans les sections sur les topologies distinctes, le maillage complet et
la topologie de ressources de comptes.
La configuration par défaut d’Azure AD Connect Sync suppose que :
Chaque utilisateur n’a qu’un seul compte activé et la forêt où se trouve ce compte est utilisée pour
authentifier l’utilisateur. Cette hypothèse s’applique à la synchronisation du hachage de mot de passe,
l’authentification directe et la fédération. UserPrincipalName et sourceAnchor/immutableID proviennent de
cette forêt.
Chaque utilisateur n’a qu’une seule boîte aux lettres.
la forêt qui héberge la boîte aux lettres d’un utilisateur a la meilleure qualité de données pour les attributs
visibles dans la liste d’adresses globale Exchange. Si aucune boîte aux lettres n’est associée à l’utilisateur,
n’importe quelle forêt peut être utilisée pour fournir ces valeurs d’attributs.
Si vous avez une boîte aux lettres liée, il existe également un compte dans une forêt différente de celle
utilisée pour la connexion.
Si votre environnement ne correspond pas à ces hypothèses, voici ce qui se produit :
Si vous avez plusieurs comptes actifs ou plusieurs boîtes aux lettres, le moteur de synchronisation en choisit
un et ignore les autres.
Une boîte aux lettres liée sans aucun autre compte actif n’est pas exportée vers Azure AD. Le compte
d’utilisateur n’est pas représenté en tant que membre d’un groupe quelconque. Dans DirSync, une boîte aux
lettres liée est toujours représentée comme une boîte aux lettres normale. Il s’agit d’un comportement
intentionnellement différent pour mieux prendre en charge les scénarios avec plusieurs forêts.
Pour plus de détails, consultez la page Présentation de la configuration par défaut.
Plusieurs forêts, plusieurs serveurs de synchronisation connectés à un client Azure AD
Le fait de disposer de plusieurs serveurs Azure AD Connect Sync à un locataire Azure AD unique n’est pas pris
en charge. L’exception est l’utilisation d’un serveur intermédiaire.
Cette topologie diffère de celle ci-dessous par le fait qu’elle ne permet pas de connecter plusieurs ser veurs de
synchronisation à un locataire Azure AD unique.
Plusieurs forêts, un seul serveur de synchronisation et des utilisateurs sont représentés dans un seul annuaire
Dans cet environnement, toutes les forêts locales sont traitées comme des entités distinctes. Aucun utilisateur
n’est présent dans une autre forêt. Chaque forêt a sa propre organisation Exchange et il n’existe pas de GALSync
entre les forêts. Cette topologie peut se présenter suite à une fusion/acquisition ou dans une organisation où
chaque division fonctionne indépendamment. Dans Azure AD, ces forêts sont dans la même organisation et
s’affichent avec une liste d’adresses globale unifiée. Dans l’image précédente, chaque objet de chaque forêt est
représenté une seule fois dans le métaverse et agrégé dans le locataire Azure AD cible.
Plusieurs forêts : utilisateurs en correspondance
Dans tous ces scénarios figurent des groupes de distribution et de sécurité, qui peuvent contenir une
combinaison d’utilisateurs, de contacts et d’entités de sécurité externes. Les entités de sécurité externes sont
utilisées dans Active Directory Domain Services (AD DS) pour représenter des membres d’autres forêts dans un
groupe de sécurité. Toutes les entités de sécurité externes sont résolues en leur objet réel dans Azure AD.
Plusieurs forêts : maillage complet avec GALSync facultative
Une topologie de maillage complet permet aux utilisateurs et aux ressources de se trouver dans n’importe
quelle forêt. En général, il existe des approbations bidirectionnelles entre les forêts.
Si Exchange est présent dans plusieurs forêts, il peut (éventuellement) y avoir une solution GALSync locale.
Chaque utilisateur est ensuite représenté en tant que contact dans toutes les autres forêts. GALSync est
fréquemment implémentée via FIM 2010 ou MIM 2016. Azure AD Connect ne peut pas être utilisé pour une
GALSync locale.
Dans ce scénario, les objets d’identité sont joints via l’attribut de messagerie. Un utilisateur qui a une boîte aux
lettres dans une forêt est joint aux contacts dans les autres forêts.
Plusieurs forêts : forêt de ressources de comptes
Dans une topologie de forêt de ressources de comptes, vous avez une ou plusieurs forêts de comptes avec des
comptes d’utilisateurs actifs. Une ou plusieurs forêts de ressources comportent également des comptes
désactivés.
Dans ce scénario, une (ou plusieurs) forêt de ressources approuve toutes les forêts de comptes. Cette forêt de
ressources a généralement un schéma Active Directory étendu avec Exchange et Lync. Tous les services
Exchange et Lync, et d’autres services partagés, sont situés dans cette forêt. Les utilisateurs ont un compte
d’utilisateur désactivé dans cette forêt et la boîte aux lettres est liée à la forêt de comptes.
Considérations sur Microsoft 365 et la topologie

Certaines charges de travail Microsoft 365 imposent des restrictions aux topologies prises en charge :
C H A RGE DE T RAVA IL REST RIC T IO N S
Exchange Online Pour plus d’informations sur les topologies hybrides prises
en charge par Exchange Online, consultez Déploiements
hybrides avec plusieurs forêts Active Directory.
Skype Entreprise Lorsque vous utilisez plusieurs forêts locales, seule la

topologie de forêt de ressources de comptes est prise en
charge. Pour plus d’informations, consultez la rubrique
Configuration environnementale pour Skype for Business
Server 2015.
Si vous êtes une plus grande organisation, vous devez envisager d’utiliser la fonctionnalité Microsoft 365
PreferredDataLocation. Elle vous permet de définir la région de centre de données dans laquelle se trouvent les
ressources de l’utilisateur.
Serveur de test
Azure AD Connect prend en charge l’installation d’un second serveur en mode intermédiaire. Un serveur dans
ce mode lit les données de tous les annuaires connectés, sans rien y écrire. Il utilise le cycle de synchronisation
normale et possède donc une copie des données d’identité à jour.
En cas d’échec du serveur principal (lors d’un sinistre), vous pouvez basculer sur le serveur intermédiaire. Pour
cela, utilisez l’Assistant Azure AD Connect. Ce second serveur peut se trouver dans un autre centre de données,
car aucune infrastructure n’est partagée avec le serveur principal. Toute modification de configuration apportée
au serveur principal doit être copiée manuellement sur le second serveur.
Vous pouvez utiliser un serveur intermédiaire pour tester une nouvelle configuration personnalisée et l’effet
qu’elle aura sur vos données. Vous pouvez prévisualiser les modifications et ajuster la configuration. Lorsque
vous êtes satisfait de la nouvelle configuration, vous pouvez faire du serveur intermédiaire le serveur actif et
placer l’ancien serveur actif en mode intermédiaire.
Vous pouvez également utiliser cette méthode pour remplacer le serveur de synchronisation actif. Préparez le
nouveau serveur et configurez-le en mode intermédiaire. Assurez-vous qu’il est en bon état, désactivez le mode
intermédiaire (rendant ainsi le serveur actif), puis arrêtez le serveur actif actuel.
Il est possible d’avoir plusieurs serveurs intermédiaires si vous voulez disposer de plusieurs sauvegardes dans
différents centres de données.
Plusieurs clients Azure AD

Nous recommandons d’avoir un seul locataire dans Azure AD pour une organisation. Avant d’envisager d’utiliser
plusieurs clients Azure AD, consultez l’article Gestion des unités administratives dans Azure AD. Il couvre les
scénarios courants dans lesquels vous pouvez utiliser un locataire unique.
Il existe une relation 1:1 entre un serveur Azure AD Connect Sync et un locataire Azure AD. Pour chaque client
Azure AD, vous avez besoin d’une installation d’un serveur de synchronisation Azure AD Connect. De par leur
conception, les instances de locataire Azure AD sont isolées. Ainsi, les utilisateurs dans un locataire ne peuvent
pas voir les utilisateurs dans l’autre locataire. Si vous souhaitez cette séparation, cette configuration est prise en
charge. Dans le cas contraire, vous devez utiliser le modèle de locataire Azure AD unique.
Chaque objet une seule fois dans un client Azure AD
Dans cette topologie, un seul serveur de synchronisation Azure AD Connect est connecté à chaque client Azure
AD. Les serveurs Azure AD Connect Sync doivent être configurés pour le filtrage afin d’avoir chacun un
ensemble d’objets mutuellement exclusifs. Vous pouvez, par exemple, délimiter l’étendue de chaque serveur à
un domaine ou à une unité d’organisation spécifique.
Un domaine DNS peut être inscrit dans un seul locataire Azure AD. L’UPN (nom d’utilisateur principal) des
utilisateurs dans l’instance Active Directory locale doit également être composé d’espaces de noms distincts. Par
exemple, dans l’image précédente, trois suffixes d’UPN distincts sont inscrits dans l’instance Active Directory
locale : contoso.com, fabrikam.com et wingtiptoys.com. Les utilisateurs dans chaque domaine Active Directory
local utilisent un espace de noms différent.
NOTE
La synchronisation de la liste d’adresses globale (GalSync) n’est pas effectuée automatiquement dans cette topologie et
nécessite une implémentation MIM personnalisée supplémentaire pour vérifier que chaque locataire dispose d’une liste
d’adresses globale (LAG) complète dans Exchange Online et Skype Entreprise Online.
Cette topologie comprend les restrictions suivantes pour les scénarios sinon pris en charge :
Un maximum de 5 locataires Azure Active Directory peuvent avoir Exchange hybride avec l’instance Active
Directory locale. Ce scénario est décrit dans la Mise à jour de l’assistant de configuration hybride de
septembre 2020.
L’assistant de configuration hybride Exchange Server doit être à la version 2016 CU18 ou 2019 CU7 ou une
version ultérieure.
Chaque instance Azure AD Connect doit être exécutée sur une machine jointe à un domaine.
Azure AD Connect doit être configuré à l’aide de l’option de filtrage de domaine/d’UO pour filtrer les
utilisateurs de votre annuaire local. L’utilisation de cette option permet de s’assurer que les utilisateurs
apparaissent uniquement dans un seul client Exchange en ligne.
Les appareils Windows 10 ne peuvent être associés qu’à un seul locataire Azure AD.
L’option d’authentification unique (SSO) pour la synchronisation du hachage de mot de passe et
l’authentification directe ne peut être utilisée qu’avec un seul locataire Azure AD.
La condition requise d’un ensemble d’objets mutuellement exclusifs s’applique également à l’écriture différée.
Certaines fonctionnalités d’écriture différée ne sont pas prises en charge avec cette topologie, car elles
supposent une seule configuration locale. Voici quelques fonctionnalités :
Écriture différée des groupes avec la configuration par défaut.
Écriture différée des appareils.
Chaque objet plusieurs fois dans un client Azure AD
Les tâches suivantes ne sont pas prises en charge :

Synchronisation d’un même utilisateur vers plusieurs locataires Azure AD.
Modification d’une configuration pour faire en sorte que les utilisateurs dans un locataire Azure AD
apparaissent comme contacts dans un autre locataire Azure AD.
Modification d’Azure AD Connect Sync pour qu’il se connecte à plusieurs locataires Azure AD.
GALSync à l’aide de l’écriture différée
Les locataires Azure AD sont isolés de par leur conception. Les tâches suivantes ne sont pas prises en charge :
Modification de la configuration d’Azure AD Connect Sync pour lire des données à partir d’un autre locataire
Azure AD.
Exportation d’utilisateurs comme contacts vers une autre instance Active Directory locale avec Azure AD
Connect Sync.
GALSync avec le serveur de synchronisation local
Vous pouvez utiliser FIM 2010 ou MIM 2016 local pour synchroniser les utilisateurs (via GALSync) entre deux
organisations Exchange. Les utilisateurs d’une organisation apparaissent alors comme des utilisateurs/contacts
externes dans l’autre organisation. Ces différentes instances Active Directory locales peuvent ensuite être
synchronisées vers leurs propres locataires Azure AD.
Utilisation de clients non autorisés pour accéder au serveur principal d’Azure AD Connect
Le serveur Azure Active Directory Connect communique avec Azure Active Directory via le serveur principal
d’Azure Active Directory Connect. Azure Active Directory Connect est le seul logiciel qui peut être utilisé pour
communiquer avec ce serveur principal. Il n’est pas possible de communiquer avec le serveur principal d’Azure
Active Directory Connect en utilisant un autre logiciel ou une autre méthode.
Étapes suivantes
Pour savoir comment installer Azure AD Connect pour ces scénarios, consultez Installation personnalisée
d’Azure AD Connect.
Facteurs affectant les performances d’Azure AD
Connect
Azure AD Connect gère la synchronisation entre Active Directory et Azure AD. Ce serveur est un composant
essentiel de la migration des identités d’utilisateur vers le cloud. Le tableau suivant répertorie les principaux
facteurs qui impactent les performances d’Azure AD Connect :
FA C T EUR DE C O N C EP T IO N DÉF IN IT IO N
Topologie Distribution des points de terminaison et des composants

qu’Azure AD Connect doit manager sur le réseau.
Scale Nombre d’objets, tels que les utilisateurs, les groupes et les
unités d’organisation, qui seront managés par Azure AD
Connect.
Matériel Matériel (physique ou virtuel) utilisé pour Azure AD Connect

et chaque composant matériel dont la capacité impacte les
performances, notamment l’UC, la mémoire, le réseau et la
configuration du disque dur.
Configuration Mode de traitement des annuaires et des informations par

Azure AD Connect.
Load Fréquence des modifications d’objets. Les charges peuvent

varier au cours d’une heure, d’un jour ou d’une semaine. En
fonction du composant, vous devrez peut-être prévoir des
pics de charge ou une charge moyenne.
L’objectif de ce document est de décrire les facteurs qui impactent les performances du moteur de
provisionnement Azure AD Connect. Les organisations complexes ou de grande taille (celles devant
provisionner plus de 100 000 objets) peuvent suivre les suggestions pour optimiser leur implémentation
d’Azure AD Connect, en particulier si elles rencontrent certains problèmes de performances décrits dans ce
document. Les autres composants d’Azure AD Connect, comme Azure AD Connect Health et les agents ne sont
pas abordés ici.
IMPORTANT
Microsoft ne prend pas en charge la modification ou l’utilisation d’Azure AD Connect en dehors des actions qui sont
documentées de façon formelle. Ces actions peuvent entraîner un état de synchronisation Azure AD Connect incohérent
ou non pris en charge. Par conséquent, Microsoft ne peut pas fournir de support technique pour ces déploiements.
Facteurs impactant les composants d’Azure AD Connect

Le diagramme ci-dessous illustre l’architecture générale d’un moteur de provisionnement connecté à une seule
forêt, mais la connexion à plusieurs forêts est également prise en charge. Cette architecture montre les
interactions entre les divers composants.
Le moteur de provisionnement se connecte à chaque forêt Active Directory et à Azure AD. Importer est le
processus consistant à obtenir des informations de chaque annuaire. Exporter fait référence à la mise à jour des
annuaires à partir du moteur de provisionnement. Synchroniser est l’opération qui évalue les règles de transfert
des objets au sein du moteur de provisionnement. Pour approfondir vos connaissances, consultez Azure AD
Connect Sync : présentation de l'architecture.
Azure AD Connect utilise les zones de transit, les règles et les processus suivants pour effectuer la
synchronisation entre Active Directory et Azure AD :
Espace connecteur (CS) : les objets de chaque annuaire connecté (CD), les annuaires réels, sont d’abord
mis en transit dans cet espace en attendant d’être traités par le moteur de provisionnement. Azure AD a son
propre espace connecteur, tout comme chaque forêt à laquelle vous vous connectez.
Métaverse (MV) : les objets à synchroniser sont créés ici selon les règles de synchronisation définies. Les
objets doivent avoir été créés dans le métaverse afin de pouvoir ensuite remplir des objets et des attributs
dans les autres annuaires connectés. Il y a un seul métaverse.
Règles de synchronisation : elles déterminent quels objets seront créés (projetés) ou quels objets seront
connectés ( joints) aux objets dans le métaverse. Les règles de synchronisation déterminent également
quelles valeurs d’attribut seront copiées ou transformées vers et depuis les annuaires.
Profils d’exécution : ils regroupent les étapes du processus de copie des objets et de leurs valeurs
d’attribut, selon les règles de synchronisation définies, entre les zones de transit et les annuaires connectés.
Il existe plusieurs profils d’exécution pour optimiser les performances du moteur de provisionnement. La plupart
des organisations utilisent les planifications et profils d’exécution par défaut pour les opérations habituelles.
Toutefois, certaines organisations peuvent avoir besoin de modifier la planification ou de déclencher d’autres
profils d’exécution pour faire face à des situations particulières. Les profils d’exécution suivants sont disponibles :
Profil de synchronisation initiale
Le profil de synchronisation initiale est le processus consistant à obtenir les informations des annuaires
connectés (comme une forêt Active Directory) pour la première fois. Il effectue ensuite une analyse de toutes les
entrées dans la base de données du moteur de synchronisation. Le cycle initial crée des objets dans Azure AD ; il
prend plus de temps si vos forêts Active Directory sont de grande taille. La synchronisation initiale comprend les
étapes suivantes :
1. Importation complète sur tous les connecteurs
2. Synchronisation complète sur tous les connecteurs
3. Exportation sur tous les connecteurs
Profil de synchronisation différentielle
Pour accélérer le processus de synchronisation, ce profil d’exécution traite uniquement les modifications
(créations, suppressions et mises à jour) ayant été apportées aux objets dans les annuaires connectés depuis la
dernière synchronisation. Par défaut, le profil de synchronisation différentielle s’exécute toutes les 30 minutes.
Les organisations doivent s’efforcer de maintenir la durée d’exécution à moins de 30 minutes afin de tenir Azure
AD toujours à jour. Pour superviser l’intégrité d’Azure AD Connect, utilisez l’agent de supervision de l’intégrité,
qui vous aide à détecter les éventuels problèmes avec le processus. Le profil de synchronisation différentielle
comprend les étapes suivantes :
1. Importation différentielle sur tous les connecteurs
2. Synchronisation différentielle sur tous les connecteurs
Voici un scénario de synchronisation différentielle standard dans une entreprise :
Environ 1 % des objets sont supprimés
Environ 1 % des objets sont créés
Environ 5 % des objets sont modifiés
Le taux de modification peut varier selon la fréquence à laquelle votre organisation met à jour les utilisateurs
dans Active Directory. Par exemple, le taux de modification peut être plus élevé durant les périodes de forte
augmentation ou réduction du personnel.
Profil de synchronisation complète
Un cycle de synchronisation complète est nécessaire si vous avez effectué une ou plusieurs des modifications de
configuration suivantes :
Vous avez élargi l’étendue des objets ou des attributs à importer des annuaires connectés. Par exemple, vous
avez ajouté un domaine ou une unité d’organisation à l’étendue d’importation.
Vous avez changé les règles de synchronisation. Par exemple, vous avez créé une règle supplémentaire pour
remplir la fonction des utilisateurs dans Azure AD avec l’attribut extension_attribute3 défini dans Active
Directory. Pour appliquer ce changement, le moteur de provisionnement doit réexaminer tous les utilisateurs
existants pour mettre à jour leurs fonctions.
Le profil de synchronisation complète comprend les étapes suivantes :
1. Importation complète sur tous les connecteurs
2. Synchronisation complète/différentielle sur tous les connecteurs
NOTE
Une planification soigneuse est nécessaire quand vous modifiez en bloc de nombreux objets dans Active Directory ou
Azure AD. Après une mise à jour en bloc, l’importation par le processus de synchronisation différentielle prend plus de
temps dans la mesure où beaucoup d’objets ont été modifiés. Des importations longues peuvent avoir lieu même si la
mise à jour en bloc n’influe pas sur le processus de synchronisation. Par exemple, l’attribution de licences à de nombreux
utilisateurs dans Azure AD déclenche un long cycle d’importation depuis Azure AD, sans entraîner de modifications
d’attributs dans Active Directory.
Synchronization
L’exécution du processus de synchronisation présente les caractéristiques de performances suivantes :
La synchronisation est à thread unique, ce qui signifie que le moteur de provisionnement ne traite pas en
parallèle les profils d’exécution des différents annuaires, objets ou attributs connectés.
La durée de l’importation augmente de manière linéaire en fonction du nombre d’objets à synchroniser. Par
exemple, si l’importation de 10 000 objets prend 10 minutes, l’importation de 20 000 objets prendra environ
20 minutes sur le même serveur.
L’exportation suit également un schéma linéaire.
La synchronisation augmente de manière exponentielle en fonction du nombre d’objets référençant d’autres
objets. Les appartenances aux groupes et les groupes imbriqués ont le plus fort impact sur les performances,
car leurs membres référencent des objets utilisateur ou d’autres groupes. Ces références doivent être
définies et référencer des objets réels dans le métaverse pour permettre le cycle de synchronisation.
Filtrage
La taille de la topologie Active Directory à importer est le facteur qui impacte le plus les performances et la
durée d’exécution des composants internes du moteur de provisionnement.
Utilisez le filtrage pour réduire le nombre d’objets à synchroniser. Vous éviterez ainsi que des objets soient
inutilement traités et exportés vers Azure AD. Dans l’ordre de préférence, voici les méthodes de filtrage à votre
disposition :
Filtrage par domaine : utilisez cette option pour sélectionner des domaines spécifiques à synchroniser
dans Azure AD. Vous devez ajouter et supprimer des domaines au niveau de la configuration du moteur de
synchronisation lorsque vous apportez des modifications à votre infrastructure locale après avoir installé la
synchronisation Azure AD Connect.
Filtrage par unité d’organisation : utilisez des unités d’organisation pour cibler des objets spécifiques
dans les domaines Active Directory en vue de leur provisionnement dans Azure AD. Le filtrage par unité
d’organisation est la deuxième méthode de filtrage recommandée, car elle utilise des requêtes d’étendue
LDAP simples pour importer un sous-ensemble plus petit d’objets à partir d’Active Directory.
Filtrage d’attributs par objet : utilisez les valeurs d’attribut des objets pour déterminer quels objets
spécifiques dans Active Directory doivent être provisionnés dans Azure AD. Le filtrage des attributs permet
de définir des filtres plus précis, quand le filtrage par domaine ou par unité d’organisation ne répond pas à
vos besoins. Le filtrage des attributs n’accélère pas l’importation, mais peut réduire les durées d’exportation
et de synchronisation.
Filtrage par groupe : utilisez l’appartenance au groupe pour déterminer quels objets doivent être
provisionnés dans Azure AD. Le filtrage par groupe convient aux environnements de test uniquement, mais
n’est pas recommandé pour les environnements de production. En effet, cette méthode donne lieu à une
charge supplémentaire pour vérifier l’appartenance au groupe durant le cycle de synchronisation.
La présence d’un grand nombre d’objets déconnecteurs persistants dans votre espace connecteur Active
Directory risque d’augmenter les temps de synchronisation, car le moteur de provisionnement doit réévaluer
chaque objet déconnecteur pour permettre la reconnexion durant le cycle de synchronisation. Pour résoudre ce
problème, envisagez l’une des suggestions suivantes :
Retirez les objets déconnecteurs de l’étendue d’importation à l’aide du filtrage par domaine ou unité
d’organisation.
Projetez/joignez les objets dans le métaverse et définissez l’attribut cloudFiltered sur True pour empêcher le
provisionnement de ces objets dans l’espace connecteur Azure AD.
NOTE
Le filtrage d’un trop grand nombre d’objets peut être complexe pour les utilisateurs ou entraîner des problèmes
d’autorisations d’application. Par exemple, dans une implémentation Exchange hybride Online, les utilisateurs ayant des
boîtes aux lettres locales verront davantage d’utilisateurs dans leur liste d’adresses globale que les utilisateurs de boîtes
aux lettres Exchange Online. Dans d’autres cas, un utilisateur pourra vouloir accorder l’accès à une application cloud à un
autre utilisateur qui n’est pas inclus dans l’étendue des objets filtrés.
Flux de valeurs d’attribut

Les flux de valeurs d’attribut désignent le processus de copie ou de transformation des valeurs d’attribut des
objets d’un annuaire connecté dans un autre annuaire connecté. Ils sont définis dans les règles de
synchronisation. Par exemple, quand le numéro de téléphone d’un utilisateur est changé dans votre annuaire
Active Directory, ce numéro de téléphone est également mis à jour dans Azure AD. Les organisations peuvent
modifier les flux de valeurs d’attribut selon leurs besoins. Il est recommandé de faire une copie des flux de
valeurs d’attribut existants avant de les modifier.
Les redirections simples, comme passer une valeur d’attribut à un autre attribut, n’impactent pas les
performances matérielles. Un exemple de redirection est le transfert d’un numéro de téléphone mobile dans
Active Directory vers le numéro de téléphone fixe dans Azure AD.
La transformation des valeurs d’attribut peut avoir un impact sur les performances au moment du processus de
synchronisation. Transformer des valeurs d’attribut inclut la modification, le reformatage, la concaténation ou la
soustraction de valeurs d’attribut.
Les organisations peuvent empêcher le transfert de certains attributs vers Azure AD, mais cela n’impacte pas les
performances du moteur de provisionnement.
NOTE
Ne supprimez pas les flux de valeurs d’attribut inutiles dans vos règles de synchronisation. Il est préférable de les
désactiver, étant donné que les règles supprimées sont recréées lors des mises à niveau d’Azure AD Connect.
Facteurs de dépendance pour Azure AD Connect

Les performances d’Azure AD Connect sont dépendantes des performances des annuaires connectés importés
et exportés. Par exemple, elles dépendent de la taille de l’importation Active Directory ou de la latence du réseau
pour accéder au service Azure AD. La base de données SQL utilisée par le moteur de provisionnement a
également un impact sur les performances globales du cycle de synchronisation.
Facteurs liés à Active Directory
Comme nous l’avons mentionné précédemment, le nombre d’objets à importer impacte considérablement les
performances. L’article Conditions préalables pour Azure AD Connect présente la configuration matérielle
requise en fonction de la taille du déploiement. Azure AD Connect prend uniquement en charge les topologies
spécifiques décrites dans Topologies pour Azure AD Connect. Nous ne proposons pas de solutions ni de
suggestions d’optimisation des performances pour les topologies non prises en charge.
Assurez-vous que le serveur Azure AD Connect est conforme à la configuration matérielle requise pour la taille
de votre importation Active Directory. Le processus d’importation peut être ralenti si la connectivité réseau est
lente ou mauvaise entre le serveur Azure AD Connect et vos contrôleurs de domaine Active Directory.
Facteurs liés à Azure AD
Azure AD applique la limitation de requêtes pour protéger le service cloud contre les attaques par déni de
service (DoS). Actuellement, Azure AD a une limite de 7 000 requêtes d’écriture toutes les 5 minutes (84 000 par
heure). Par exemple, les opérations suivantes peuvent être limitées :
Exportations d’Azure AD Connect vers Azure AD.
Mises à jour par des applications ou scripts PowerShell directement dans Azure AD, y compris en arrière-
plan, comme les appartenances de groupe dynamiques.
Mises à jour par les utilisateurs de leurs propres enregistrements d’identité, comme l’inscription auprès du
service MFA (authentification multifacteur) ou SSPR (réinitialisation du mot de passe libre-service).
Opérations au sein de l’interface graphique utilisateur.
Planifiez les tâches de déploiement et de maintenance pour vous assurer que la limitation des requêtes
n’impacte pas le cycle de synchronisation Azure AD Connect. Par exemple, si votre organisation connaît une
forte période de recrutement qui nécessite la création de milliers d’identités d’utilisateur, cela peut entraîner de
nombreuses mises à jour des appartenances de groupe dynamiques, des attributions de licences et des
inscriptions au service de réinitialisation de mot de passe libre-service. Il est alors préférable d’échelonner ces
écritures sur plusieurs heures voire quelques jours.
Facteurs liés à la base de données SQL
La taille de votre topologie Active Directory source impacte les performances de votre base de données SQL.
Respectez la configuration matérielle requise pour le serveur de la base de données SQL et prenez en compte
les suggestions suivantes :
Les organisations de plus de 100 000 utilisateurs peuvent réduire les latences du réseau en installant la base
de données SQL et le moteur de provisionnement sur le même serveur.
En raison de la grande quantité d’entrées et de sorties (E/S) nécessaires pour le processus de
synchronisation, utilisez des disques SSD pour la base de données SQL du moteur de provisionnement afin
d’avoir des résultats optimaux. Si cela n’est pas possible, utilisez des disques RAID 0 ou RAID 1.
Ne lancez pas de synchronisation complète de façon préventive, car cela entraîne une surcharge inutile et
augmente les temps de réponse.
Conclusion
Pour optimiser les performances de votre implémentation d’Azure AD Connect, tenez compte des suggestions
suivantes :
Respectez la configuration matérielle recommandée pour le serveur Azure AD Connect en fonction de la
taille de votre implémentation.
Quand vous effectuez une mise à niveau d’Azure AD Connect dans des déploiements à grande échelle,
utilisez la méthode de migration « swing » pour garantir un temps d’arrêt minimum et une fiabilité optimale.
Utilisez un disque SSD pour la base de données SQL afin d’optimiser les performances d’écriture.
Filtrez l’étendue Active Directory pour inclure uniquement les objets nécessitant d’être provisionnés dans
Azure AD, à l’aide du filtrage par domaine ou unité d’organisation, ou du filtrage des attributs.
Si vous devez modifier les règles de flux de valeurs d’attribut par défaut, copiez la règle, modifiez la copie et
désactivez la règle d’origine. N’oubliez pas de réexécuter une synchronisation complète.
Prévoyez suffisamment de temps pour le profil d’exécution de la synchronisation complète initiale.
Efforcez-vous de planifier un cycle de synchronisation différentielle de moins de 30 minutes. Si le profil de
synchronisation différentielle s’exécute en plus de 30 minutes, changez la fréquence de synchronisation par
défaut pour inclure un cycle complet de synchronisation différentielle.
Supervisez l’agent Azure AD Connect Health pour la synchronisation dans Azure AD.
Étapes suivantes
Options de connexion de l’utilisateur via Azure AD
Connect
Azure Active Directory (Azure AD) Connect permet à vos utilisateurs de se connecter aux ressources cloud et
locales à l’aide des mêmes mots de passe. Cet article décrit les concepts clés pour chaque modèle d’identité afin
de vous aider à choisir l’identité que vous souhaitez utiliser pour vous connecter à Azure AD.
Si vous connaissez déjà le modèle d’identité Azure AD et que vous souhaitez en savoir plus sur une méthode
spécifique, cliquez sur le lien adéquat :
Synchronisation de hachage de mot de passe avec authentification unique transparente (SSO)
Synchronisation directe avec authentification unique transparente (SSO)
Authentification unique fédérée (avec Active Directory Federation Services (AD FS))
NOTE
Il est important de vous rappeler qu’en configurant la fédération pour Azure AD, vous établissez l’approbation entre votre
client Azure AD et vos domaines fédérés. Avec ce domaine d’approbation fédéré, les utilisateurs auront accès aux
ressources cloud d’Azure AD au sein du client.
Choix de la méthode de connexion utilisateur pour votre organisation

La première décision concernant l’implémentation d’Azure AD Connect est le choix de la méthode
d’authentification qui sera utilisée par vos utilisateurs pour se connecter. Il est important de choisir la méthode
appropriée répondant aux exigences de sécurité et avancées de votre organisation. L’authentification est
essentielle, car elle validera les identités de l’utilisateur pour accéder aux applications et aux données dans le
cloud. Pour choisir la méthode d’authentification correcte, vous devez prendre en compte l’infrastructure
existante, le temps nécessaire à l’implémentation, sa complexité et les coûts associés. Ces facteurs sont différents
pour chaque organisation et peuvent varier au fil du temps.
Azure AD prend en charge les méthodes d’authentification suivantes :
Authentification cloud : quand vous choisissez cette méthode d’authentification, Azure AD gère le
processus d’authentification pour la connexion des utilisateurs. L’authentification cloud propose deux options
:
Synchronisation de hachage du mot de passe : la synchronisation de hachage du mot de passe
permet aux utilisateurs d’utiliser les mêmes nom d’utilisateur et mot de passe qu’ils utilisent
localement sans avoir à déployer une infrastructure supplémentaire en plus d’Azure AD Connect.
Authentification directe (PTA) : cette option est similaire à la synchronisation de hachage de mot
de passe, mais elle permet une validation simple du mot de passe à l’aide d’agents de logiciel sur site
pour les organisations disposant de stratégies de conformité et de sécurité renforcées.
Authentification fédérée : quand vous choisissez cette méthode d’authentification, Azure AD délègue le
processus d’authentification à un système d’authentification approuvée distinct, par exemple AD FS ou un
système de fédération tiers, pour valider la connexion de l’utilisateur.
Pour la plupart des organisations qui souhaitent simplement permettre aux utilisateurs de se connecter à
Microsoft 365, aux applications SaaS et à d'autres ressources basées sur Azure AD, nous recommandons
l'option de synchronisation de hachage de mot de passe par défaut.
Pour plus d’informations sur le choix d’une méthode d’authentification, consultez Choisir la méthode
d’authentification adaptée à votre solution d’identité hybride Azure Active Directory.
Avec la synchronisation de hachage de mot de passe, les hachages des mots de passe utilisateur sont
synchronisés de votre annuaire Active Directory local vers Azure AD. Lorsque les mots de passe sont modifiés
ou réinitialisés localement, les hachages des nouveaux mots de passe sont immédiatement synchronisés avec
Azure AD afin que vos utilisateurs puissent toujours utiliser le même mot de passe pour les ressources cloud
comme pour les ressources locales. Les mots de passe ne sont jamais envoyés à Azure AD ni stockés dans
Azure AD sous forme de texte clair. Vous pouvez utiliser la synchronisation de hachage de mot de passe avec la
réécriture de mot de passe pour permettre la réinitialisation de mot de passe libre-service dans Azure AD.
De plus, vous pouvez activer l’authentification unique transparente (SSO) pour des utilisateurs sur des machines
jointes à un domaine qui se trouvent sur le réseau d’entreprise. Avec l’authentification unique, les utilisateurs
activés doivent seulement entrer un nom d’utilisateur pour accéder en toute sécurité aux ressources cloud.
Pour plus d’informations, consultez l’article sur la synchronisation de hachage de mot de passe.
Avec l’authentification directe, le mot de passe de l’utilisateur est validé par rapport au contrôleur Active
Directory local. Le mot de passe n’a pas besoin d’être présent dans Azure AD sous quelque forme que ce soit.
Ceci permet d’évaluer les stratégies locales au cours de l’authentification auprès des services cloud, comme
pour les restrictions sur les heures d’ouverture de session.
L’authentification directe utilise un agent simple sur un ordinateur Windows Server 2012 R2 joint à un domaine
dans l’environnement local. Cet agent écoute les requêtes de validation de mot de passe. Il ne nécessite pas que
des ports entrants soient ouverts sur Internet.
En outre, vous pouvez activer également l’authentification unique pour des utilisateurs sur des ordinateurs joints
à un domaine qui se trouvent sur le réseau d’entreprise. Avec l’authentification unique, les utilisateurs activés
doivent seulement entrer un nom d’utilisateur pour accéder en toute sécurité aux ressources cloud.
Pour plus d'informations, consultez les pages suivantes :

Fédération utilisant des services AD FS nouveaux ou existants dans la batterie de serveurs Windows
Server 2012 R2
Avec l’authentification fédérée, vos utilisateurs peuvent se connecter aux services basés sur Azure AD avec leurs
mots de passe locaux. Lorsqu’ils sont sur le réseau d’entreprise, ils n’ont même pas besoin d’entrer leurs mots de
passe. En utilisant l’option de fédération avec les services de fédération d’Azure Directory (AD FS), vous pouvez
déployer un nouveau service AD FS dans la batterie de serveurs Windows Server 2012 R2 ou en spécifier un
existant. Si vous choisissez de spécifier une batterie existante, Azure AD Connect configure l’approbation entre
votre batterie et Azure AD de manière à ce que vos utilisateurs puissent s’authentifier.
Déploiement d’une fédération avec AD FS dans Windows Server 2012 R2
Si vous déployez une nouvelle batterie, il vous faut :
Un serveur Windows Server 2012 R2 pour le serveur de fédération.
Un serveur Windows Server 2012 R2 pour le proxy d’application web.
Un fichier .pfx avec un certificat TLS/SSL unique pour le nom de votre service de fédération. Par exemple :
fs.contoso.com.
Si vous déployez une nouvelle batterie ou si vous utilisez une batterie existante, il vous faut :
Les informations d’identification de l’administrateur local de vos serveurs de fédération.
Les informations d’identification de l’administrateur local des serveurs des groupes de travail (ne faisant pas
partie d’un domaine) sur lesquels vous avez l’intention de déployer le rôle de proxy d’application web.
La machine sur laquelle vous exécutez l’Assistant doit être en mesure de se connecter à n’importe quel autre
appareil sur lequel vous souhaitez installer AD FS ou un proxy d’application web en utilisant Windows
Remote Management.
Pour plus d’informations, consultez Configuration de l’authentification unique avec ADFS.
Avec l’authentification fédérée, vos utilisateurs peuvent se connecter aux services basés sur Azure AD avec leurs
mots de passe locaux. Lorsqu’ils sont sur le réseau d’entreprise, ils n’ont même pas besoin d’entrer leurs mots de
passe.
Pour plus d’informations sur la configuration de PingFederate pour une utilisation avec Azure Active Directory,
consultez Intégration de PingFederate à Azure Active Directory et Office 365
Pour plus d’informations sur la configuration d’Azure AD Connect à l’aide de PingFederate, consultez Installation
personnalisée d’Azure AD Connect
Authentification à l’aide d’une version antérieure d’AD FS ou d’une solution tierce
Si vous avez déjà configuré l’authentification cloud à l’aide d’une version antérieure d’AD FS (par exemple,
AD FS 2.0) ou à l’aide d’un fournisseur de fédération tiers, vous pouvez choisir d’ignorer la configuration de la
connexion utilisateur via Azure AD Connect. Cela vous permet d’obtenir la dernière synchronisation et d’autres
fonctionnalités d’Azure AD Connect tout en utilisant toujours votre solution d’authentification existante.
Pour plus d’informations, consultez la Liste de compatibilité des fournisseurs de fédération tiers Azure AD.
Connexion de l’utilisateur et nom d’utilisateur principal

Présentation du nom d’utilisateur principal
Dans Active Directory, le suffixe du nom de principal de l’utilisateur (UPN) par défaut est le nom DNS du
domaine dans lequel le compte d’utilisateur a été créé. Dans la plupart des cas, il s’agit du nom de domaine
enregistré en tant que domaine d’entreprise sur Internet. Toutefois, vous pouvez ajouter d’autres suffixes UPN
avec les domaines et approbations Active Directory.
L’UPN de l’utilisateur est au format username@domain. Par exemple, pour un domaine Active Directory nommé
« contoso.com », un utilisateur nommé John peut avoir l’UPN suivant : « john@contoso.com ». L’UPN de
l’utilisateur se base sur RFC 822. Bien que l’UPN et la messagerie partagent le même format, la valeur du nom
UPN d’un utilisateur n’est pas forcément identique à l’adresse de messagerie de l’utilisateur.
Nom d’utilisateur principal dans Azure AD
L’Assistant Azure AD Connect utilise l’attribut userPrincipalName ou vous laisse spécifier l’attribut (dans une
installation personnalisée) à utiliser en local en tant que nom d’utilisateur principal dans Azure AD. Il s’agit de la
valeur qui est utilisée pour la connexion à Azure AD. Si la valeur de l’attribut du nom principal d’utilisateur ne
correspond pas à un domaine vérifié dans Azure AD, Azure AD la remplacera par une valeur .onmicrosoft.com
par défaut.
Dans Azure Active Directory, chaque annuaire est fourni avec un nom de domaine intégré se présentant sous la
forme contoso.onmicrosoft.com qui vous permet de commencer à utiliser Azure ou d’autres services Microsoft.
Vous pouvez améliorer et simplifier l’expérience de connexion avec les domaines personnalisés. Pour plus
d’informations sur les noms de domaine personnalisés dans Azure AD et sur la vérification des domaines,
consultez Ajouter votre nom de domaine personnalisé à Azure Active Directory.
Configuration de connexion AD Azure

Configuration de connexion AD Azure avec Azure AD Connect
L’expérience de connexion Azure AD dépend de la capacité d’Azure AD à faire correspondre le suffixe de nom
principal d’un utilisateur en cours de synchronisation à l’un des domaines personnalisés vérifiés dans l’annuaire
Azure AD. Azure AD Connect fournit une aide lors de la configuration des paramètres de connexion Azure AD,
afin que l’expérience de connexion utilisateur sur le cloud soit similaire à l’expérience locale.
Azure AD Connect répertorie les suffixes UPN qui sont définis pour les domaines et essaie de les mettre en
correspondance avec un domaine personnalisé dans Azure AD. Il vous aide ensuite avec l’action appropriée à
entreprendre. La page de connexion AD Azure répertorie les suffixes UPN définis pour Active Directory local et
affiche l’état correspondant à chaque suffixe. L’état peut avoir une des valeurs suivantes :
STAT E DESC RIP T IO N A C T IO N REQ UISE
Verified Azure AD Connect a trouvé un Aucune action n'est nécessaire.

domaine vérifié correspondant dans
Azure AD. Tous les utilisateurs de ce
domaine peuvent se connecter en
utilisant leurs informations
d’identification locales.
STAT E DESC RIP T IO N A C T IO N REQ UISE
Non vérifié Azure AD Connect a trouvé un Vérifiez le domaine personnalisé dans

domaine personnalisé correspondant Azure AD.
dans Azure AD mais il n’est pas vérifié.
Si le domaine n’est pas vérifié, le suffixe
UPN des utilisateurs de ce domaine
sera remplacé par le suffixe
.onmicrosoft.com par défaut après la
synchronisation.
Non ajouté Azure AD Connect n’a pas trouvé de Ajouter et vérifier un domaine
domaine personnalisé correspondant personnalisé correspondant au suffixe
au suffixe UPN. Si le domaine n’est pas UPN.
ajouté et vérifié dans Azure, le suffixe
UPN des utilisateurs de ce domaine
sera remplacé par le suffixe
.onmicrosoft.com.
La page de connexion AD Azure répertorie le(s) suffixe(s) UPN défini(s) pour Active Directory local et le domaine
personnalisé correspondant dans Azure AD avec l’état actuel de la vérification. Dans une installation
personnalisée, vous pouvez maintenant sélectionner l’attribut du nom d’utilisateur principal sur la page
Connexion à Azure AD .
Vous pouvez cliquer sur le bouton Actualiser pour extraire à nouveau le dernier état des domaines personnalisés
à partir d’Azure AD.
Sélection d’un attribut pour le nom d’utilisateur principal dans Azure AD
L'attribut userPrincipalName est utilisé par les utilisateurs lorsqu'ils se connectent à Azure AD et Microsoft 365.
Vous devez vérifier les domaines (également nommés « Suffixe UPN ») utilisés dans Azure AD avant la
synchronisation des utilisateurs.
Nous vous recommandons fortement de conserver l’userPrincipalName de l’attribut par défaut. Si cet attribut
ne peut pas être acheminé ni vérifié, vous pouvez sélectionner un autre attribut (par exemple une adresse de
messagerie électronique) comme attribut contenant l’ID de connexion. Il s’agit de l’ID secondaire. La valeur de
l’attribut ID secondaire doit suivre la norme RFC 822. Vous pouvez utiliser un ID secondaire avec
l’authentification unique par mot de passe et avec l’authentification unique de fédération comme solution de
connexion.
NOTE
L'utilisation d'un ID secondaire n'est pas compatible avec certaines charges de travail Microsoft 365. Pour plus
d’informations, consultez Configuration d’un ID secondaire de connexion.
Différents états de domaine personnalisé et leur impact sur l’expérience de connexion Azure
Il est très important de comprendre la relation entre les états de domaine personnalisé dans votre annuaire
Azure AD et les suffixes UPN définis en local. Passons en revue les différentes expériences de connexion Azure
possibles lorsque vous configurez la synchronisation avec Azure AD Connect.
Pour les informations suivantes, supposons que nous nous intéressons au suffixe UPN contoso.com utilisé dans
l’annuaire local dans le nom UPN, par exemple user@contoso.com.
C o n f i g u ra t i o n ra p i d e / Sy n c h ro n i s a t i o n d e h a c h a g e d e mo t d e p a s s e
EF F ET SUR L’EXP ÉRIEN C E DE C O N N EXIO N UT IL ISAT EUR

STAT E A Z URE
Non ajouté Dans ce cas, aucun domaine personnalisé pour contoso.com

n’a été ajouté à l’annuaire Azure AD. Les utilisateurs
possédant un UPN local avec le suffixe @contoso.com ne
pourront pas utiliser leur UPN local pour se connecter à
Azure. Ils devront utiliser un nouvel UPN fourni par Azure
AD en ajoutant le suffixe de l’annuaire Azure AD par défaut.
Par exemple, si vous synchronisez des utilisateurs sur
l’annuaire Azure AD azurecontoso.onmicrosoft.com,
l’utilisateur local user@contoso.com aura un nom UPN
user@azurecontoso.onmicrosoft.com.
Non vérifié Dans ce cas, nous avons un domaine personnalisé

contoso.com ajouté à l’annuaire Azure AD. Toutefois, la
vérification n’est pas encore effectuée. Si vous poursuivez la
synchronisation des utilisateurs sans vérifier le domaine, les
utilisateurs se verront attribuer un nouvel UPN d’Azure AD,
comme dans le scénario « Non ajouté ».
Verified Dans ce cas, nous avons un domaine personnalisé

contoso.com déjà ajouté et vérifié dans Azure AD pour le
suffixe UPN. Les utilisateurs pourront utiliser leur nom
d’utilisateur principal local, par exemple, user@contoso.com,
pour se connecter à Azure une fois qu’ils seront synchronisés
sur Azure AD.
F é d é ra t i o n A D F S
Vous ne pouvez pas créer de fédération avec le domaine .onmicrosoft.com par défaut dans Azure AD ou un
domaine personnalisé non vérifié dans Azure AD. Lorsque vous exécutez l’Assistant Azure AD Connect, si vous
sélectionnez un domaine non vérifié pour créer une fédération, Azure AD Connect vous invitera à créer les
enregistrements nécessaires à l’endroit où est hébergé votre DNS pour le domaine. Pour plus d’informations,
consultez Vérification du domaine Azure AD sélectionné pour la fédération.
Si vous avez sélectionné l’option de connexion utilisateur Fédération avec AD FS , vous devez disposer d’un
domaine personnalisé pour poursuivre la création d’une fédération dans Azure AD. Dans notre cas de figure,
cela signifie que nous devons disposer d’un domaine personnalisé contoso.com ajouté dans l’annuaire Azure
AD.
EF F ET SUR L’EXP ÉRIEN C E DE C O N N EXIO N UT IL ISAT EUR

STAT E A Z URE
Non ajouté Dans ce cas, Azure AD Connect n’a pas trouvé de domaine
personnalisé correspondant au suffixe UPN contoso.com
dans l’annuaire Azure AD. Vous devez ajouter un domaine
personnalisé contoso.com si vous avez besoin que les
utilisateurs se connectent à l’aide d’AD FS avec leur UPN local
(par exemple user@contoso.com).
Non vérifié Dans ce cas, Azure AD Connect vous fournira les

informations appropriées sur les possibilités de vérification
de votre domaine à un stade ultérieur.
Verified Dans ce cas, vous pouvez poursuivre la configuration sans

autre action.
Modification de la méthode de connexion utilisateur

Après la configuration initiale d’Azure AD Connect dans l’Assistant, vous pouvez changer la méthode de
connexion utilisateur de Fédération, Synchronisation de mot de passe ou Authentification directe à l’aide des
tâches disponibles dans Azure AD Connect. Réexécutez l’Assistant Azure AD Connect. La liste des tâches que
vous pouvez effectuer s’affiche. Sélectionnez Modifier la connexion utilisateur dans la liste des tâches.
Sur la page suivante, vous devrez fournir les informations d’identification pour Azure AD.
Dans la page Connexion de l’utilisateur , sélectionnez la connexion d’utilisateur souhaitée.
NOTE
Si vous passez à la synchronisation de hachage de mot de passe de façon temporaire, cochez la case Ne pas conver tir
les comptes utilisateurs . Si vous ne cochez pas l’option, chaque utilisateur devient fédéré, et la conversion peut
prendre plusieurs heures.
Étapes suivantes
En savoir plus sur Azure AD Connect : principes de conception.
Remplissage de UserPrincipalName dans Azure AD
Cet article décrit la façon dont l’attribut UserPrincipalName est rempli dans Azure Active Directory (Azure AD).
La valeur d’attribut UserPrincipalName est le nom d’utilisateur Azure AD des comptes d’utilisateurs.
Terminologie UPN
Cet article emploie la terminologie suivante :
T ERM E DESC RIP T IO N
Domaine initial Domaine par défaut (onmicrosoft.com) dans le locataire

Azure AD. Par exemple, contoso.onmicrosoft.com.
Adresse de routage des e-mails en ligne Microsoft (MOERA) Azure AD calcule l’adresse MOERA à partir de l’attribut Azure
AD MailNickName et du domaine initial Azure AD sous la
forme <MailNickName>@<domaine initial>.
Attribut mailNickName local Attribut dans Active Directory, dont la valeur représente
l’alias d’un utilisateur dans une organisation Exchange.
Attribut mail local Attribut dans Active Directory, dont la valeur représente
l’adresse e-mail d’un utilisateur.
Adresse SMTP principale Adresse e-mail principale d’un objet destinataire Exchange.
Par exemple, SMTP:utilisateur@contoso.com.
ID de connexion de substitution Attribut local autre que UserPrincipalName, par exemple

l’attribut mail, utilisé pour la connexion.
À quoi correspond UserPrincipalName ?

L’attribut UserPrincipalName est un nom de connexion au format Internet d’un utilisateur selon la norme
Internet RFC 822.
Format UPN
Un UPN se compose d’un préfixe UPN (nom de compte d’utilisateur) et d’un suffixe UPN (nom de domaine
DNS). Le préfixe et le suffixe sont liés par le symbole « @ ». Par exemple, « utilisateur@exemple.com ». Un UPN
doit être unique parmi tous les objets principaux de sécurité d’une forêt de répertoires.
UPN dans Azure AD

L’UPN est utilisé par Azure AD pour permettre aux utilisateurs de se connecter. L’UPN utilisable par un utilisateur
est différent selon que le domaine a été vérifié ou non. Si c’est le cas, un utilisateur présentant ce suffixe pourra
se connecter à Azure AD.
L’attribut est synchronisé par Azure AD Connect. Lors de l’installation, vous pouvez voir les domaines qui ont été
vérifiés et ceux qui ne l’ont pas été.
ID de connexion de substitution
Dans certains environnements, les utilisateurs finaux connaissent uniquement leur adresse e-mail, et pas leur
nom d’utilisateur principal. L’utilisation de l’adresse e-mail peut être due à une stratégie d’entreprise ou à une
dépendance d’application métier locale.
Un ID de connexion de substitution permet de configurer une expérience de connexion où les utilisateurs
peuvent se connecter avec un attribut autre que leur UPN, comme leur adresse e-mail.
Aucune configuration supplémentaire n’est nécessaire pour activer l’ID de connexion de remplacement avec
Azure AD dès lors qu’Azure AD Connect est utilisé. L’Assistant permet de configurer directement l’ID de
remplacement. Consultez la configuration de connexion Azure AD de vos utilisateurs sous la section
Synchronisation. Sous la liste déroulante Nom d’utilisateur principal , sélectionnez l’attribut ID de connexion
de remplacement.
Pour plus d’informations, consultez les sections Configurer un ID de connexion de remplacement et
Configuration de connexion Azure AD.
Suffixe UPN non vérifié

Si le suffixe d’ID de connexion de remplacement/attribut UserPrincipalName local n’est pas vérifié par le
locataire Azure AD, la valeur d’attribut UserPrincipalName Azure AD est définie sur l’adresse MOERA. Azure AD
calcule l’adresse MOERA à partir de l’attribut Azure AD MailNickName et du domaine initial Azure AD sous la
forme <MailNickName>@<domaine initial>.
Suffixe UPN vérifié

Si le suffixe d’ID de connexion de remplacement/attribut UserPrincipalName local est vérifié par le locataire
Azure AD, la valeur d’attribut UserPrincipalName Azure AD sera la même que la valeur d’ID de connexion de
remplacement/attribut UserPrincipalName local.
Calcul de la valeur d’attribut MailNickName Azure AD

La valeur d’attribut UserPrincipalName Azure AD pouvant être définie pour l’adresse MOERA, il est important de
comprendre la façon dont est calculée la valeur d’attribut MailNickName Azure AD, qui correspond au préfixe
MOERA.
Lorsqu’un objet utilisateur est synchronisé avec un locataire Azure AD pour la première fois, Azure AD vérifie les
éléments suivants dans l’ordre indiqué et définit la valeur d’attribut MailNickName sur le premier trouvé :
Attribut mailNickName local
Préfixe d’adresse SMTP principale
Préfixe d’attribut mail local
Préfixe d’ID de connexion de remplacement/attribut UserPrincipalName local
Préfixe d’adresse SMTP secondaire
Lorsque les mises à jour d’un objet utilisateur sont synchronisées avec le locataire Azure AD, Azure AD ne met à
jour la valeur d’attribut MailNickName qu’en cas de mise à jour de la valeur d’attribut mailNickName locale.
IMPORTANT
Azure AD ne recalcule la valeur d’attribut UserPrincipalName que dans le cas où une mise à jour de la valeur d’ID de
connexion de remplacement/attribut UserPrincipalName locale est synchronisée avec le client Azure AD.
Chaque fois qu’Azure AD recalcule l’attribut UserPrincipalName, il recalcule également l’adresse MOERA.
Scénarios UPN
Voici quelques exemples de scénarios, ainsi que la façon dont l’UPN est calculé pour chacun d’entre eux.
Scénario 1 : Suffixe UPN non vérifié – synchronisation initiale
Objet utilisateur local :

mailNickName : <non défini>
proxyAddresses : {SMTP:us1@contoso.com}
mail : us2@contoso.com
UserPrincipalName : us3@contoso.com
Synchroniser l’objet utilisateur avec le locataire Azure AD la première fois.
Configurez l’attribut MailNickName d’Azure AD sur le préfixe de l’adresse SMTP principale.
Définir l’adresse MOERA sur <MailNickName>@<domaine initial>.
Définir l’attribut UserPrincipalName Azure AD sur l’adresse MOERA.
Objet utilisateur du locataire Azure AD :
MailNickName : us1
UserPrincipalName : us1@contoso.onmicrosoft.com
Scénario 2 : Suffixe UPN non vérifié – définition de l'attribut mailNickName local
mailNickName : us4
Synchroniser la mise à jour de l’attribut mailNickName local avec le locataire Azure AD.
Mettre à jour l’attribut Azure AD MailNickName Azure AD avec l’attribut mailNickName local.
Étant donné l’absence de mise à jour de l’attribut UserPrincipalName local, l’attribut UserPrincipalName
Azure AD reste inchangé.
MailNickName : us4
Scénario 3 : Suffixe UPN non vérifié – mise à jour de l'attribut UserPrincipalName local

mailNickName : us4
Synchroniser la mise à jour de l’attribut UserPrincipalName local avec le locataire Azure AD.
La mise à jour de l’attribut UserPrincipalName local déclenche le recalcul de l’adresse MOERA et de l’attribut
UserPrincipalName Azure AD.
Définir l’adresse MOERA sur <MailNickName>@<domaine initial>.
Définir l’attribut UserPrincipalName Azure AD sur l’adresse MOERA.
MailNickName : us4
Scénario 4 : Suffixe UPN non vérifié – mise à jour de l'adresse SMTP principale et de l'attribut mail local

mailNickName : us4
Synchroniser la mise à jour de l’attribut mail local et de l’adresse SMTP principale avec le locataire Azure AD
Après la synchronisation initiale de l’objet utilisateur, les mises à jour de l’attribut mail local et de l’adresse
SMTP principale n’affecteront ni l’attribut MailNickName, ni l’attribut UserPrincipalName Azure AD.
MailNickName : us4
Scénario 5 : Suffixe UPN vérifié – mise à jour du suffixe d'attribut UserPrincipalName local
mailNickName : us4
UserPrincipalName : us5@verified.contoso.com
Synchroniser la mise à jour de l’attribut UserPrincipalName local avec le locataire Azure AD.
La mise à jour de l’attribut UserPrincipalName local déclenche le recalcul de l’attribut UserPrincipalName
Azure AD.
Définir l’attribut UserPrincipalName Azure AD sur l’attribut UserPrincipalName local, car le suffixe UPN est
vérifié par le locataire Azure AD.
MailNickName : us4
UserPrincipalName : us5@verified.contoso.com
Étapes suivantes
Intégrer vos répertoires locaux à Azure Active Directory
Installation personnalisée d’Azure AD Connect
Azure AD Connect : Considérations spécifiques
concernant les instances
Azure AD Connect est couramment utilisé avec l’instance mondiale d’Azure AD et Microsoft 365. Mais il existe
également d’autres instances, qui ont des exigences différentes en matière d’URL et autres considérations
spéciales.
Microsoft Cloud Allemagne

Microsoft Cloud Allemagne est un cloud souverain géré par un client allemand approuvé dans le domaine des
données.
URL À O UVRIR DA N S L E SERVEUR P RO XY
*.microsoftonline.de
*.windows.net
+ Listes de révocation de certificat
Quand vous vous connectez à votre locataire Azure AD, vous devez utiliser un compte du domaine
onmicrosoft.de.
Fonctionnalités actuellement absentes de Microsoft Cloud Allemagne :
L’écriture différée de mot de passe est disponible en préversion avec Azure AD Connect
version 1.1.570.0 et ultérieures.
Les autres services Azure AD Premium ne sont pas disponibles.
Microsoft Azure Government

Le cloud Microsoft Azure Government est un cloud du gouvernement des États-Unis.
Ce cloud a été pris en charge par des versions antérieures de DirSync. À partir de la build 1.1.180 d’Azure AD
Connect, la nouvelle génération du cloud est prise en charge. Cette génération utilise des points de terminaison
États-Unis uniquement et a sa propre liste d’URL à ouvrir dans votre serveur proxy.
URL À O UVRIR DA N S L E SERVEUR P RO XY
*.microsoftonline.com
*.microsoftonline.us
*.windows.net (requis pour la détection automatique d'un locataire Azure Government)
*.gov.us.microsoftonline.com
+ Listes de révocation de certificat

NOTE
À compter d'Azure AD Connect version 1.1.647.0, la définition de la valeur AzureInstance dans le Registre n’est plus
nécessaire, à condition que *.windows.net soit ouvert sur vos serveurs proxy. Toutefois, pour les clients n'autorisant pas la
connectivité Internet à partir de leurs serveurs Azure AD Connect, la configuration manuelle suivante peut être utilisée.
Configuration manuelle
La procédure de configuration manuelle suivante est utilisée pour veiller à ce qu'Azure AD Connect utilise des
points de terminaison de synchronisation Azure Government.
1. Lancez l’installation d’Azure AD Connect.
2. Quand vous voyez apparaître la première page où vous êtes censé accepter le CLUF, ne poursuivez pas, mais
laissez l’Assistant Installation en cours d’exécution.
3. Lancez regedit et modifiez la clé de registre de la valeur
HKLM\SOFTWARE\Microsoft\Azure AD Connect\AzureInstance à la valeur 4 .
4. Revenez à l’Assistant Installation d’Azure AD Connect, acceptez le CLUF et continuez. Pendant l’installation,
veillez à utiliser le chemin d’accès d’installation de la configuration personnalisée (et non l’installation
Express), puis poursuivez l'installation normalement.
Étapes suivantes
Passer de la fédération à l’authentification cloud
Dans cet article, vous apprendrez à déployer l’authentification des utilisateurs dans le cloud avec la
Synchronisation du hachage des mots de passe (PHS) ou l’Authentification directe (PTA) Azure Active Directory.
Bien que nous présentions le cas d’utilisation pour le passage d’Active Directory Federation Services (AD FS) à
des méthodes d’authentification cloud, ces conseils s’appliquent également à d’autres systèmes locaux.
Avant de poursuivre, nous vous suggérons de consulter notre guide sur le Choix de la méthode
d’authentification appropriée et de comparer les méthodes les plus adaptées à votre organisation.
Nous vous recommandons d’utiliser PHS pour l’authentification cloud.
Déploiement par étapes

Le lancement intermédiaire est un excellent moyen de tester des groupes d’utilisateurs de manière sélective
avec des fonctionnalités d’authentification cloud comme Azure AD Multi-Factor Authentication (MFA), l’accès
conditionnel, Identity Protection pour les informations d’identification divulguées ou Identity Governance avant
le basculement de vos domaines.
Reportez-vous au plan de mise en œuvre du déploiement par étapes pour comprendre les scénarios pris en
charge et non pris en charge. Nous vous recommandons d’utiliser le déploiement par étapes pour effectuer des
tests avant de découper les domaines.
Pour savoir comment configurer le déploiement par étapes, consultez le Guide interactif du déploiement par
étapes (migration vers l’authentification cloud à l’aide du déploiement par étapes dans Azure AD).
Flux du processus de migration

Configuration requise
Avant de commencer votre migration, assurez-vous que vous respectez ces conditions préalables.
Rôles nécessaires
Pour utiliser le lancement intermédiaire, vous devez être l’administrateur général de votre locataire.
Pour activer l’authentification unique transparente sur une forêt Windows Active Directory particulière, vous
devez être l’administrateur de domaine.
Passer à la version supérieure du serveur Azure AD Connect
Installez Azure Active Directory Connect (Azure AD Connect) ou mettez-le à niveau vers la dernière version.
Lorsque vous passez un serveur Azure AD Connect à une édition supérieure, vous réduisez le temps nécessaire
à la migration d’AD FS vers les méthodes d’authentification cloud de plusieurs heures à quelques minutes.
Documenter les paramètres de fédération actuels
Pour trouver le paramètre de fédération actuel, exécutez l’applet de commande Get-
MsolDomainFederationSettings.
Vérifiez les paramètres qui peuvent avoir été personnalisés pour la conception de votre fédération et la
documentation du déploiement. En particulier, recherchez les personnalisations dans
PreferredAuthenticationProtocol , Suppor tsMfa et PromptLoginBehavior .
Sauvegarder les paramètres de fédération
Bien que ce déploiement ne modifie aucune autre partie de confiance dans votre batterie AD FS, vous pouvez
sauvegarder vos paramètres :
Utilisez l’outil de restauration rapide AD FS de Microsoft pour restaurer une batterie existante ou en créer
une nouvelle.
Exportez l’approbation de la partie de confiance de la plateforme d’identité Microsoft 365 et les règles de
revendication personnalisées associées que vous avez ajoutées à l’aide de l’exemple PowerShell suivant :
(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML

"C:\temp\O365-RelyingPartyTrust.xml"
Planifier le projet
Les échecs de projets informatiques, lorsqu’ils se produisent, proviennent généralement d’une disparité entre
les attentes et l’impact, les responsabilités et les résultats. Pour éviter ces écueils, assurez-vous de faire appel aux
bonnes personnes, et que les rôles des parties prenantes soient bien compris.
Planifier les communications
Après la migration vers l’authentification cloud, l’expérience de connexion de l’utilisateur pour accéder à
Microsoft 365 et à d’autres ressources qui sont authentifiées par Azure AD change. Les utilisateurs qui sont en
dehors du réseau voient seulement la page de connexion Azure AD.
Communiquez de manière proactive avec vos utilisateurs sur ce qui va changer, à quel moment les
changements seront appliqués et comment ils peuvent obtenir de l’aide en cas de problème.
Planifier la fenêtre de maintenance
Après la conversion de domaine, Azure AD peut continuer à envoyer des requêtes d’authentification héritées
d’Exchange Online à vos serveurs AD FS pendant une période maximale de quatre heures. Le retard est dû au
fait que le cache d’Exchange Online pour l’authentification des applications héritées peut prendre jusqu’à 4
heures pour réaliser le passage de la fédération à l’authentification cloud.
Pendant cette période de quatre heures, vous pouvez inviter les utilisateurs à fournir des informations
d’identification à plusieurs reprises lors de la réauthentification à des applications qui utilisent l’authentification
héritée. Bien que l’utilisateur puisse toujours s’authentifier auprès d’AD FS, Azure AD n’accepte plus le jeton émis
de l’utilisateur, car cette approbation de la fédération est maintenant supprimée.
Les clients hérités (Exchange ActiveSync, Outlook 2010/2013) ne sont pas affectés, car Exchange Online
conserve un cache de leurs informations d’identification pour un laps de temps défini. Le cache est utilisé pour
réauthentifier l’utilisateur en mode silencieux. L’utilisateur ne doit pas retourner à AD FS. Les informations
d’identification stockées sur l’appareil pour ces clients sont utilisées pour se réauthentifier eux-mêmes en mode
silencieux une fois le cache effacé. Les utilisateurs ne doivent normalement pas recevoir d’invites demandant un
mot de passe à la suite du processus de conversion de domaine.
Les clients d’authentification moderne (Office 2016 et Office 2013, applications iOS et Android) utilisent un jeton
d’actualisation valide pour obtenir de nouveaux jetons d’accès permettant de continuer à accéder aux ressources
au lieu de retourner à AD FS. Ces clients sont protégés des demandes de mot de passe résultant du processus
de conversion de domaine. Les clients continuent de fonctionner sans configuration supplémentaire.
Plan de restauration
TIP
Envisagez de planifier le basculement des domaines pendant les heures creuses en cas d’exigences de restauration.
Pour planifier la restauration, utilisez les paramètres actuels documentés de la fédération et vérifiez la
documentation sur la conception et le déploiement de la fédération.
Le processus de restauration comprend la conversion des domaines managés en domaines fédérés avec l’applet
de commande Convert-MSOLDomainToFederated. Si nécessaire, configurez des règles de revendications
supplémentaires.
Considérations relatives à la migration

Voici les principaux éléments à prendre en compte lors de la migration.
Planifier les paramètres de personnalisation
Le fichier onload.js ne peut pas être dupliqué dans Azure AD. Si votre instance AD FS est fortement
personnalisée et s’appuie sur des paramètres de personnalisation spécifiques dans le fichier onload.js, vérifiez si
Azure AD peut répondre à vos besoins actuels en matière de personnalisation et planifiez en conséquence.
Communiquez ces modifications à venir à vos utilisateurs.
Expérience de connexion
Vous ne pouvez pas personnaliser l’expérience de connexion Azure AD. Quelle que soit la façon dont vos
utilisateurs se sont connectés précédemment, vous avez besoin d’un nom de domaine complet, comme un nom
d’utilisateur principal (UPN) ou un e-mail pour vous connecter à Azure AD.
Personnalisation de l’organisation
Vous pouvez personnaliser la page de connexion Azure AD. Certaines modifications visuelles sur les pages de
connexion d’AD FS doivent être attendues après la conversion.
NOTE
La personnalisation de l’organisation n’est pas disponible dans les licences Azure AD gratuites, sauf si vous disposez d’une
licence Microsoft 365.
Planifier les stratégies d’accès conditionnel

Évaluez si vous utilisez actuellement l’accès conditionnel pour l’authentification, ou si vous utilisez des stratégies
de contrôle d’accès dans AD FS.
Vous pouvez envisager de remplacer les stratégies de contrôle d’accès AD FS par des stratégies d’accès
conditionnel et des règles d’accès du client Exchange Online d’Azure AD équivalentes. Vous pouvez utiliser des
groupes Azure AD ou locaux pour l’accès conditionnel.
Désactiver l’authentification héritée - En raison du risque accru associé aux protocoles d’authentification
traditionnels, créez une stratégie d’accès conditionnel pour bloquer l’authentification traditionnelle.
Planifier la prise en charge de l’authentification multifacteur
Chaque domaine fédéré dans Azure AD a un indicateur SupportsMFA.
Si l’indicateur Suppor tsMFA a la valeur True , Azure AD redirige les utilisateurs vers AD FS ou d’autres
fournisseurs de fédération pour qu’ils effectuent l’authentification multifacteur. Par exemple, si un utilisateur
accède à une application pour laquelle une stratégie d’accès conditionnel nécessitant l’authentification
multifacteur a été configurée, l’utilisateur est redirigé vers AD FS. L’ajout d’Azure AD MFA comme méthode
d’authentification dans AD FS permet d’appeler Azure AD MFA une fois vos configurations terminées.
Si l’indicateur Suppor tsMFA est défini sur False , il est probable que vous n’utilisez pas l’authentification
multifacteur Azure ; vous utilisez probablement des règles de réclamation sur des parties de confiance d’AD FS
pour déclencher l’authentification multifacteur.
Vous pouvez vérifier l’état de votre indicateur Suppor tsMFA avec la cmdlet Windows PowerShell suivante :
Get-MsolDomainFederationSettings –DomainName yourdomain.com
NOTE
Le serveur Microsoft MFA est proche de la fin de sa durée de vie du support et, si vous l’utilisez, vous devez passer à
Azure AD MFA. Pour plus d’informations, consultez la documentation Migrer de Microsoft MFA Ser ver vers Azure
Multi-factor Authentication . Si vous envisagez d’utiliser Azure AD Multi-Factor Authentication, nous vous
recommandons une inscription combinée à la réinitialisation de mot de passe en libre-ser vice (SSPR) et à
l’authentification multifacteur pour permettre à vos utilisateurs d’inscrire leurs méthodes d’authentification en une
seule fois.
Planifier l’implémentation
Cette section comprend le pré-travail avant que vous basculiez votre méthode de connexion et convertissiez les
domaines.
Créer les groupes nécessaires pour le déploiement par étapes
Si vous n’utilisez pas de déploiement intermédiaire, ignorez cette étape.
Créer des groupes pour le déploiement par étapes. Vous devrez également créer des groupes pour les stratégies
d’accès conditionnel si vous décidez de les ajouter.
Nous vous recommandons d’utiliser un groupe maître dans Azure AD, également appelé groupe cloud
uniquement. Vous pouvez utiliser des groupes de sécurité Azure AD ou des groupes Microsoft 365 pour
déplacer les utilisateurs vers l’authentification multifacteur et pour les stratégies d’accès conditionnel. Pour plus
d’informations, consultez Création d’un groupe de sécurité Azure AD et Vue d’ensemble des groupes Microsoft
365 pour les administrateurs.
Les membres d’un groupe sont automatiquement activés pour le lancement intermédiaire. Les groupes
dynamiques et imbriqués ne sont pas pris en charge pour le lancement intermédiaire.
Pré -travail pour l’authentification unique
La version d’authentification unique que vous utilisez dépend du système d’exploitation de votre appareil et de
l’état de jointure.
Pour Windows 10, Windows Ser ver 2016 et versions ultérieures , il est recommandé d’utiliser
l’authentification unique via le jeton d’actualisation principal (PRT) avec les appareils joints Azure AD, les
appareils joints Azure AD hybrides ou les appareils inscrits dans Azure AD.
Pour les appareils Windows 7 et 8.1 , nous vous recommandons d’utiliser l’authentification unique
fluide avec jointure de domaine pour enregistrer l’ordinateur dans Azure AD. Vous n’avez pas à
synchroniser ces comptes comme pour les appareils Windows 10. Cependant, vous devez effectuer ce
travail préalable pour une authentification unique fluide avec PowerShell.
Pré -travail pour PHS et PTA
Selon le choix de la méthode d’inscription, effectuez le travail préalable pour PHS ou le pour PTA.
Implémenter votre solution

Enfin, vous devez basculer la méthode de connexion sur PHS ou PTA, comme prévu, et convertir les domaines
de la fédération en authentification cloud.
Utilisation du déploiement par étapes
Si vous utilisez le déploiement échelonné, suivez les étapes indiquées dans les liens ci-dessous :
1. Activez le lancement intermédiaire d’une fonctionnalité spécifique sur votre locataire.
2. Une fois les tests terminés, convertissez les domaines de fédérés en managés.
Sans déploiement par étapes
Vous avez deux options pour permettre ce changement :
Option A : Basculer à l’aide d’Azure AD Connect
Disponible si vous avez initialement configuré votre environnement AD FS/fédéré par ping avec Azure
AD Connect.
Option B : Basculer en utilisant Azure AD Connect et PowerShell
Disponible si vous n’avez pas initialement configuré vos domaines fédérés à l’aide d’Azure AD Connect ou
si vous utilisez des services de fédération tiers.
Pour choisir l’une de ces options, vous devez connaître vos paramètres actuels.
Vérifier les paramètres d’Azure AD Connect actuels
Connectez-vous au portail Azure AD, sélectionnez Azure AD Connect et vérifiez les paramètres USER
SIGN_IN comme indiqué dans ce diagramme :
Pour vérifier la configuration de la fédération :

1. Sur votre serveur Azure AD Connect, ouvrez Azure AD Connect et sélectionnez Configurer .
2. Sous Tâches supplémentaires > Gérer la fédération , sélectionnez Voir la configuration de la
fédération .
Si la configuration d’AD FS apparaît dans cette section, vous pouvez considérer qu’AD FS a été
initialement configuré à l’aide d’Azure AD Connect. Consultez l’image ci-dessous comme exemple :
Si AD FS n’est pas listé dans les paramètres actuels, vous devez convertir manuellement vos domaines de
l’identité fédérée à l’identité managée avec PowerShell.
Option A
Passage de la fédération à la nouvelle méthode de connexion à l’aide d’Azure AD Connect
1. Sur votre serveur Azure AD Connect, ouvrez Azure AD Connect et sélectionnez Configurer .
2. Sous la page Tâches supplémentaires , sélectionnez Changer de connexion utilisateur , puis
sélectionnez Suivant .
3. Sur la page Connexion à Azure AD , saisissez vos informations d’identification d’administrateur global.
4. Sur la page Connexion de l’utilisateur :
Si vous sélectionnez le bouton d’option Authentification directe , cochez Activer
l’authentification unique , puis sélectionnez Suivant .
Si vous sélectionnez le bouton d’option Synchronisation de hachage de mot de passe ,
assurez-vous de cocher la case Ne pas conver tir les comptes d’utilisateur . L’option est
dépréciée. Cochez Activer l’authentification unique , puis sélectionnez Suivant .
5. Dans la page Activer l’authentification unique , entrez les informations d’identification d’un compte
d’administrateur de domaine, puis sélectionnez Suivant .
Les informations d’identification du compte d’administrateur de domaine sont nécessaires pour activer
l’authentification unique fluide. Le processus effectue les actions suivantes, qui nécessitent ces
autorisations élevées :
Un compte d’ordinateur nommé AZUREADSSO (qui représente Azure AD) est créé dans votre instance
Active Directory locale.
La clé de déchiffrement Kerberos du compte d’ordinateur est partagée de façon sécurisée avec
Azure AD.
Deux noms de principal du service Kerberos sont créés pour représenter les deux URL utilisées lors de
la connexion à Azure AD.
Les informations d’identification d’administrateur de domaine ne sont pas stockées dans Azure AD
Connect ou Azure AD et sont ignorées une fois le processus terminé. Elles sont utilisées pour activer cette
fonctionnalit�

Langue

Azure Adconnect

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Azure Adconnect

Transféré par

Droits d'auteur :

Formats disponibles

Contents

Documentation des identités hybrides

Scénarios et recommandations courants

J’A I B ESO IN DE : P H S ET SSO 1 P TA ET SSO 2 A D F S3

Configurer mon locataire

Permettre à mes utilisateurs

Activer des solutions

Activer des solutions

Afficher les notifications

1 Synchronisation de hachage de mot de passe avec authentification unique (SSO).

2 Authentification directe et authentification unique.

3 Authentification unique fédérée avec AD FS.

Licences requises pour Azure AD Connect

Création d'une machine virtuelle

#Create New Virtual Machine

#Set the memory to be non-dynamic

#Add DVD Drive to Virtual Machine

#Mount Installation Media

#Configure Virtual Machine to Boot from DVD

Terminer le déploiement du système d’exploitation

Installer les prérequis pour Active Directory

#Set static IP address

# Set the DNS servers

#Rename the computer

#Restart the computer

Créer un environnement Windows Server AD

#Install AD DS, DNS and GPMC

#Create New AD Forest

#Create the user

#Set the password to never expire

Créer un locataire Azure AD

Créer un administrateur général dans Azure AD

Télécharger et installer Azure AD Connect

Vérifier les utilisateurs créés et l’exécution de la synchronisation

Tester la connexion avec un des utilisateurs

Création d'une machine virtuelle

Effectuez les actions suivantes :

#Create New Virtual Machine

#Set the memory to be non-dynamic

#Add DVD Drive to Virtual Machine

#Mount Installation Media

#Configure Virtual Machine to Boot from DVD

Terminer le déploiement du système d’exploitation

Installer les prérequis pour Active Directory

#Set static IP address

# Set the DNS servers

#Rename the computer

#Restart the computer

Créer un environnement Windows Server AD

#Install AD DS, DNS and GPMC

#Create New AD Forest

Créer un utilisateur Windows Server AD

#Create the user

#Set the password to never expire

Créer un locataire Azure AD

Créer un administrateur général dans Azure AD

Ajoutez le nom de domaine personnalisé à votre annuaire.

Télécharger et installer Azure AD Connect

Vérifier les utilisateurs créés et l’exécution de la synchronisation

Tester la connexion avec un des utilisateurs

Création d'une machine virtuelle

Effectuez les actions suivantes :

#Create New Virtual Machine