Vous êtes sur la page 1sur 996

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
Azure AD Connect et Connect Health
Présentation d’Azure AD Connect et Connect Health
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
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
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
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
Migrer depuis la fédération vers PHS
Migrer depuis la fédération vers PTA
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
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
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
Gérer 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
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
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
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
Résolution des problèmes
Présentation de l’agent d’administration Azure AD Connect
En quoi consiste le module PowerShell de ADConnectivityTools ?
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
Synchronisation de hachage de mot de passe
Authentification directe
Authentification unique
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
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 du connecteur
Comptes et autorisations
FAQ Azure AD Connect
Forum Aux Questions (FAQ) Azure AD Connect Health
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
Liste de compatibilité de fédération Azure AD
Application de TLS 1.2
Référence ADSyncConfig
Référence ADSyncTools
Référence de ADConnectivityTools
msExchUserHoldPolicies et cloudMSExchUserHoldPolicies
Comprendre la disparition des appareils Azure AD Connect 1.4.xx.x
Présentation de l’identité hybride avec
Azure Active Directory
17/09/2019 • 4 minutes to read • Edit Online

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’AI BESOIN DE : PHS ET SSO1 PTA ET SSO2 AD FS 3

Synchroniser de
nouveaux comptes
d’utilisateurs, de
contacts et de groupes
créés
automatiquement dans
mon Active Directory
local vers le cloud.

Configurer mon client


pour des scénarios
hybrides Office 365.
J’AI BESOIN DE : PHS ET SSO PTA ET SSO AD FS

Permettre à mes
utilisateurs de se
connecter et d’accéder
aux services cloud à
l’aide de leur mot de
passe local.

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


d’authentification
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
Présentation d’Azure AD Connect et Connect Health
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 la fédération ?
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)
17/09/2019 • 12 minutes to read • Edit Online

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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.
#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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.

#Declare variables
$DatabasePath = "c:\windows\NTDS"
$DomainMode = "WinThreshold"
$DomainName = "contoso.com"
$DomaninNetBIOSName = "CONTOSO"
$ForestMode = "WinThreshold"
$LogPath = "c:\windows\NTDS"
$SysVolPath = "c:\windows\SYSVOL"
$featureLogPath = "c:\poshlog\featurelog.txt"
$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
Get-WindowsFeature | Where installed >>$featureLogPath

#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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.

#Declare variables
$Givenname = "Allie"
$Surname = "McCray"
$Displayname = "Allie McCray"
$Name = "amccray"
$Password = "Pass1w0rd"
$Identity = "CN=ammccray,CN=Users,DC=contoso,DC=com"
$SecureString = ConvertTo-SecureString $Password -AsPlainText -Force

#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 Directory.
3. Dans la liste des résultats, sélectionnez sur Azure Active Directory.
4. Sélectionnez 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.msiet 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.
1. Accédez au portail Azure et connectez-vous avec un compte qui dispose d’un abonnement Azure.
2. À gauche, sélectionnez Azure Active Directory
3. Sous Gérer, sélectionnez Utilisateurs.
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|
Didacticiel : Intégrer une forêt AD unique avec
l’authentification directe (PTA)
17/09/2019 • 15 minutes to read • Edit Online

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
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.
Un abonnement Azure
Une carte réseau externe pour autoriser la machine virtuelle à communiquer avec Internet.
Une copie de Windows Server 2016
Un domaine personnalisé qui peut être vérifié

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.
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 :


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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez Set-ExecutionPolicy remotesigned et répondez Oui à tous les [A]. Appuyez sur Entrée.
3. Exécutez le script suivant.

#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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.
#Declare variables
$DatabasePath = "c:\windows\NTDS"
$DomainMode = "WinThreshold"
$DomainName = "contoso.com"
$DomaninNetBIOSName = "CONTOSO"
$ForestMode = "WinThreshold"
$LogPath = "c:\windows\NTDS"
$SysVolPath = "c:\windows\SYSVOL"
$featureLogPath = "c:\poshlog\featurelog.txt"
$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
Get-WindowsFeature | Where installed >>$featureLogPath

#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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.

#Declare variables
$Givenname = "Allie"
$Surname = "McCray"
$Displayname = "Allie McCray"
$Name = "amccray"
$Password = "Pass1w0rd"
$Identity = "CN=ammccray,CN=Users,DC=contoso,DC=com"
$SecureString = ConvertTo-SecureString $Password -AsPlainText -Force

#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 Directory.
3. Dans la liste des résultats, sélectionnez sur Azure Active Directory.
4. Sélectionnez 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.

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.

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.msiet 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 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 un 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épertoire. 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.
9. Cliquez sur Suivant.
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.
16. Sur l’écran Prêt à configurer, cliquez sur Installer.
17. Une fois l’installation terminée, cliquez sur Quitter.
18. 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.
1. Accédez au portail Azure et connectez-vous avec un compte qui dispose d’un abonnement Azure.
2. À gauche, sélectionnez Azure Active Directory
3. Sous Gérer, sélectionnez Utilisateurs.
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 personnalisés
Authentification directe
Didacticiel : Fédérer un environnement de forêt AD
unique dans le cloud
17/09/2019 • 17 minutes to read • Edit Online

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
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.
Un abonnement Azure
Une carte réseau externe pour autoriser la machine virtuelle à communiquer avec Internet.
Une copie de Windows Server 2016
Un domaine personnalisé qui peut être vérifié

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.

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 :


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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez Set-ExecutionPolicy remotesigned et répondez Oui à tous les [A]. Appuyez sur Entrée.
3. Exécutez le script suivant.

#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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.
#Declare variables
$DatabasePath = "c:\windows\NTDS"
$DomainMode = "WinThreshold"
$DomainName = "contoso.com"
$DomaninNetBIOSName = "CONTOSO"
$ForestMode = "WinThreshold"
$LogPath = "c:\windows\NTDS"
$SysVolPath = "c:\windows\SYSVOL"
$featureLogPath = "c:\poshlog\featurelog.txt"
$Password = "Pass1w0rd"

#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
Get-WindowsFeature | Where installed >>$featureLogPath

#Create New AD Forest


Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath $DatabasePath -DomainMode $DomainMode -DomainName
$DomainName -SafeModeAdministratorPassword $Password -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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.

#Declare variables
$Givenname = "Allie"
$Surname = "McCray"
$Displayname = "Allie McCray"
$Name = "amccray"
$Password = "Pass1w0rd"
$Identity = "CN=ammccray,CN=Users,DC=contoso,DC=com"
$SecureString = ConvertTo-SecureString $Password -AsPlainText -Force

#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 certificat pour AD FS


Nous allons maintenant créer un certificat 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 :
1. Ouvrez PowerShell ISE en tant qu’administrateur.
2. Exécutez le script suivant.
#Declare variables
$DNSname = "adfs.contoso.com"
$Location = "cert:\LocalMachine\My"

#Create certificate
New-SelfSignedCertificate -DnsName $DNSname -CertStoreLocation $Location

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 Directory.
3. Dans la liste des résultats, sélectionnez sur Azure Active Directory.
4. Sélectionnez 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.

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.

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.msiet 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 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épertoire. 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.
9. Cliquez sur Suivant.
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
serveurs AD FS est sélectionné.
17. Sélectionnez Utiliser un certificat installé sur les serveurs 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 certificat, 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.
24. Sur l’écran Prêt à configurer, cliquez sur Installer.
25. Une fois l’installation terminée, cliquez sur Quitter.
26. 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.
1. Accédez au portail Azure et connectez-vous avec un compte qui dispose d’un abonnement Azure.
2. À gauche, sélectionnez Azure Active Directory
3. Sous Gérer, sélectionnez Utilisateurs.
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 personnalisés
Fédération avec Azure AD Connect
Didacticiel : Configurer PHS en tant que sauvegarde
pour AD FS dans Azure AD Connect
17/09/2019 • 9 minutes to read • Edit Online

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.
Effectuez les actions suivantes :
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, puis
cliquez sur Suivant.
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épertoires, 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.

1. Double-cliquez sur l’icône Azure AD Connect créée sur le bureau.


2. Cliquez sur Configurer.
3. Sélectionnez Modifier la connexion utilisateur, puis cliquez sur Suivant.
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 Connexion de l’utilisateur, sélectionnez Synchronisation de hachage de mot de passe et
cochez la case Ne pas convertir 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.
8. Dans l’écran Prêt à configurer, cliquez sur Configurer.
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.

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.

Revenir à la fédération
Nous allons maintenant vous montrer comment revenir à la fédération. Pour cela, effectuez les étapes suivantes :
1. Double-cliquez sur l’icône Azure AD Connect créée sur le bureau.
2. Cliquez sur Configurer.
3. Sélectionnez Modifier la connexion utilisateur, puis cliquez sur Suivant.
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 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.
9. Dans l’écran Prêt à configurer, cliquez sur Configurer.
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.
1. Double-cliquez sur l’icône Azure AD Connect créée sur le bureau.
2. Cliquez sur Configurer.
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, puis
cliquez sur Suivant.
7. Sur l’écran Certificats, cliquez sur Suivant.

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
Comment Azure AD permet une gestion gouvernée
par le cloud pour les charges de travail locales
17/09/2019 • 24 minutes to read • Edit Online

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 Office 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 Office 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 Office 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 Directory
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 Directory 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 l’authentification multifacteur Azure, avec l’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
17/09/2019 • 38 minutes to read • Edit Online

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 vous 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 ) aux applications afin que les utilisateurs ne soient pas obligés de saisir plusieurs
fois leur mot de passe plusieurs fois et qu’ils se connectent automatiquement aux applications locales et basées sur
le 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 Office 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 telles que l’accès conditionnel et Multi-Factor Authentication 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 l’informatique fantôme grâce à Microsoft Cloud App Security
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 Cloud App Security (MCAS ) peut vous aider à identifier les applications utiles qui sont couramment
utilisées par les utilisateurs que l’équipe informatique peut approuver et ajouter à la galerie d’applications
d’entreprise pour que les utilisateurs bénéficient de fonctionnalités telles que l’authentification unique et l’accès
conditionnel.
« Cloud App Security 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, MCAS 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 Office 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
Azure Active Directory.

É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 Office
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 Cloud App Security 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 MCAS 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 ?
« Grâce à Cloud App Security, nous pouvons identifier 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
VOUS AVEZ TERMINÉ ? ITEM

Piloter la réinitialisation de mot de passe en libre-service


(SSPR) pour un groupe
VOUS AVEZ TERMINÉ ? ITEM

Surveiller des composants hybrides avec Azure AD Connect


Health

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


opérations

Découvrir l’informatique fantôme grâce à Microsoft


Cloud App Security

Utiliser Azure Monitor pour collecter des journaux de données


pour analyse

Deux prochaines semaines


VOUS AVEZ TERMINÉ ? ITEM

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
VOUS AVEZ TERMINÉ ? ITEM

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


VOUS AVEZ TERMINÉ ? ITEM

Activer la gestion des applications en libre-service

Activer la gestion des groupes en libre-service


VOUS AVEZ TERMINÉ ? ITEM

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.
Qu’est-ce qu’Azure AD Connect ?
17/09/2019 • 6 minutes to read • Edit Online

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 à Office 365 et Microsoft Online Services. 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 Office 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 ?


Avec Azure AD, vos utilisateurs gagnent en productivité car ils disposent d’une identité commune pour accéder
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 :

PRINCIPAUX AVANTAGES BONNES PRATIQUES

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


L'utilisation de cette fonctionnalité est gratuite et incluse dans votre abonnement Azure.

Étapes suivantes
Matériel et conditions préalables
Paramètres Express
Paramètres personnalisés
Installation des agents Azure AD Connect Health
Synchronisation des identités et résilience d’attribut
en double
17/09/2019 • 15 minutes to read • Edit Online

La résilience d’attribut en double est une fonctionnalité d’Azure Active Directory qui élimine les problèmes liés
aux conflits entre UserPrincipalName et ProxyAddress 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 ».
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 –ErrorCategory PropertyConflict doit toujours être inclus. Il n’existe actuellement pas d’autres
types de ErrorCategory, mais cela pourrait changer.
Commencez par exécuter Connect-MsolService 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 -PropertyName à 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 -PropertyValue ( -
PropertyName 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 -ErrorCategory PropertyConflict, 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 Office 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.
Comportement 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.
Rapport du portail 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.
Rapport 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
Synchronisation d’Azure AD Connect
Intégration des identités locales dans Azure Active Directory
Identifier les erreurs de synchronisation d’annuaires dans Office 365
Qu’est-ce que la synchronisation de hachage de mot
de passe avec Azure AD ?
17/09/2019 • 2 minutes to read • Edit Online

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 Office 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.
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 ?
Présentation d’Azure AD Connect et Connect Health
Qu’est-ce que l’authentification directe ?
Qu’est-ce que la fédération ?
Qu’est-ce que l’authentification unique ?
Fonctionnement de la synchronisation de hachage de mot de passe
Implémenter la synchronisation de hachage de
mot de passe avec la synchronisation Azure AD
Connect
03/10/2019 • 31 minutes to read • Edit Online

Cet article vous fournit les informations nécessaires pour synchroniser vos mots de passe utilisateur à partir
d’une instance Active Directory (AD ) locale vers une instance Azure Active Directory (Azure AD ) dans le
cloud.

Fonctionnement de la synchronisation de hachage de mot de passe


Le service de domaine Active Directory stocke les mots de passe sous forme de valeur de hachage du mot de
passe réel de l’utilisateur. Une valeur de hachage est le résultat d’une fonction mathématique unidirectionnelle
(« algorithme de hachage »). Il n’existe aucune méthode pour retrouver la version en texte brut du mot de
passe à partir du résultat d’une fonction unidirectionnelle.
Pour synchroniser votre mot de passe, Azure AD Connect Sync extrait le hachage de votre mot de passe à
partir de l’instance Active Directory local. Un traitement de sécurité supplémentaire est appliqué au hachage
du mot de passe avant sa synchronisation avec le service d’authentification Azure Active Directory. Les mots
de passe sont synchronisés pour chaque utilisateur et par ordre chronologique.
Le flux de données réel du processus de synchronisation du hachage de mot de passe est similaire à celui de
la synchronisation des données de l’utilisateur. Cependant, les mots de passe sont synchronisés plus
fréquemment que la fenêtre de synchronisation d’annuaire standard pour d’autres attributs. Le processus de
hachage de synchronisation de mot de passe s’exécute toutes les deux minutes. Vous ne pouvez pas modifier
la fréquence de ce processus. Quand vous synchronisez un mot de passe, il remplace le mot de passe cloud
existant.
La première fois que vous activez la fonctionnalité de synchronisation de hachage de mot de passe, elle
effectue une synchronisation initiale des mots de passe de tous les utilisateurs concernés. Vous ne pouvez pas
définir explicitement un sous-ensemble de mots de passe utilisateur à synchroniser.
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 SSL.
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.
P r é v e r si o n p u b l i q u e d e l a fo n c t i o n n a l i t é E n fo r ce Cl o u d P a s s w o r d P o l i cy F o r P a s s w o r d Sy n ce d U s e 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 EnforceCloudPasswordPolicyForPasswordSyncedUsersest 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 à l’aide du module MSOnline PowerShell :
Set-MsolDirSyncFeature-FeatureEnforceCloudPasswordPolicyForPasswordSyncedUsers $true

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 est définie sur None
lors de la synchronisation de mot de passe suivante pour chaque utilisateur la prochaine fois qu’il change son
mot de passe 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
Cette fonctionnalité est actuellement en préversion publique.

Préversion publique de la synchronisation des mots de passe temporaires et « Forcer la modification du mot de passe lors de 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é ForcePasswordResetOnLogonFeature en exécutant la commande
suivante sur votre serveur Azure AD Connect, en remplaçant par le nom du connecteur propre à votre
environnement :
Set-ADSyncAADCompanyFeature-ConnectorName"<AAD Connector name>" -ForcePasswordResetOnLogonFeature$true

Vous pouvez utiliser la commande suivante pour déterminer le nom du connecteur :


(Get-ADSyncConnector | where{$_.ListName -eq "Windows Azure Active Directory (Microsoft)"}).Name

Inconvénient : 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. AD Connect ne récupère pas l’indicateur
« L’utilisateur doit changer le mot de passe à la prochaine ouverture de session » de lui-même. Il vient
s’ajouter au changement du mot de passe détectée qui se produit pendant la synchronisation du hachage de
mot de passe.
Cau t i on

Si vous n’activez pas la réinitialisation de mot de passe en libre-service (SSPR ) dans Azure AD, les utilisateurs
pourront se sentir perdus quand ils réinitialiseront leur mot de passe dans Azure AD puis tenteront de se
connecter à Active Directory avec le nouveau mot de passe parce que ce nouveau mot de passe ne sera pas
valide dans Active Directory. Vous devez utiliser cette fonctionnalité uniquement quand la réinitialisation de
mot de passe en libre-service et la réécriture du mot de passe sont activées sur le locataire.

NOTE
Cette fonctionnalité est actuellement en préversion publique.

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 Keberos, LDAP ou NTLM, certains processus supplémentaires font partie du
flux de travail de synchronisation de 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 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%\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
Intégration des identités locales dans Azure Active Directory
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
Connexion de l’utilisateur avec l’authentification
directe Azure Active Directory
17/09/2019 • 7 minutes to read • Edit Online

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écuriser
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 : apprenez à 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 se
produire avec cette fonctionnalité.
Immersion dans la sécurité : informations techniques approfondies supplémentaires sur la fonctionnalité.
Authentification unique fluide 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
17/09/2019 • 5 minutes to read • Edit Online

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 multifacteur Azure.
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.
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.
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é
d’authentification directe.
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.
Authentification directe Azure Active Directory :
Limitations actuelles
17/09/2019 • 4 minutes to read • Edit Online

IMPORTANT
L’authentification directe Azure Active Directory (Azure AD) est une fonctionnalité gratuite que vous pouvez utiliser sans
avoir besoin d’aucune édition payante d’Azure AD. L’authentification directe est disponible seulement dans l’instance
mondiale d’Azure AD, et pas sur le cloud Microsoft Azure Allemagne ni sur le cloud Microsoft Azure Government.

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.

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.
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 : 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.
Résoudre les problèmes : apprenez à résoudre les problèmes courants liés à la fonctionnalité
d'authentification directe.
Présentation approfondie de sécurité : obtenez des informations techniques détaillées sur la fonctionnalité
d’authentification directe.
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.
Immersion dans la sécurité de l’authentification
directe Azure Active Directory
17/09/2019 • 25 minutes to read • Edit Online

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 Service 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 Directory : 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.
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 Azure SQL
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 de la base de données Azure SQL 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 Azure
SQL 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.
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.
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.
Résoudre les problèmes : apprenez à résoudre les problèmes courants liés à la fonctionnalité
d’authentification directe.
Authentification unique fluide Azure AD : explorez en détail cette fonctionnalité complémentaire.
Confidentialité des utilisateurs et authentification
directe Azure Active Directory
17/09/2019 • 6 minutes to read • Edit Online

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. Si vous recherchez des informations
générales sur le RGPD, consultez la section RGPD du portail 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’applicationObservateur
d’événements sur le serveur et cherchez dans Application and Service
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) {


{Remove-Item -Path $File -Force}
}

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 ?
17/09/2019 • 2 minutes to read • Edit Online

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 ?
Présentation d’Azure AD Connect et Connect Health
Qu’est-ce que la synchronisation de hachage de mot de passe ?
Qu’est-ce que la fédération ?
Qu’est-ce que l’authentification unique ?
Fonctionnement de la fédération
Fédération avec PingFederate
Fédération avec Azure AD Connect
17/09/2019 • 4 minutes to read • Edit Online

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


RUBRIQUE SUJET QU’ELLE ABORDE ET QUAND LA CONSULTER

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établissement de l’approbation actuelle entre AD FS et Office


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 SSL Mettez à jour le certificat SSL d’une batterie de serveurs AD
FS.
RUBRIQUE SUJET QU’ELLE ABORDE ET QUAND LA CONSULTER

Renouvellement des certificats de fédération pour Office 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 d’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
Liste de compatibilité de fédération Azure AD
17/09/2019 • 2 minutes to read • Edit Online

Azure Active Directory fournit l’authentification unique et une sécurité de l’accès aux applications améliorée pour
Office 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, Office 365
est intégré à Azure Active Directory pour les services de répertoire, 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 qu’Office 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, cliquez ici.

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
Fédération avec Azure AD Connect
Authentification unique transparente Azure Active
Directory
17/09/2019 • 6 minutes to read • Edit Online

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 ).

IMPORTANT
L’authentification unique fluide nécessite que l’appareil de l’utilisateur soit joint au domaine, mais n’a pas besoin que
l’appareil soit joint à 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 Office 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 :

SYSTÈME
D’EXPLOITATION INTERNET MICROSOFT
\NAVIGATEUR EXPLORER EDGE GOOGLE CHROME MOZILLA FIREFOX SAFARI

Windows 10 Oui* Non OUI Oui*** N/A

Windows 8.1 Oui* N/A OUI Oui*** N/A

Windows 8 Oui* N/A OUI Oui*** N/A

Windows 7 Oui* N/A OUI Oui*** N/A


SYSTÈME
D’EXPLOITATION INTERNET MICROSOFT
\NAVIGATEUR EXPLORER EDGE GOOGLE CHROME MOZILLA FIREFOX SAFARI

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***

*Requiert Internet Explorer version 10 ou ultérieure


**Requiert Internet Explorer version 10 ou ultérieure. Désactiver le mode protégé amélioré
***Requiert une configuration supplémentaire

NOTE
Concernant Windows 10, il est recommandé d’utiliser Azure AD Join pour une expérience optimale d’authentification
unique dans Azure AD.

É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é.
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é.
UserVoice : pour le dépôt de nouvelles demandes de fonctionnalités.
Authentification unique transparente Azure Active
Directory : Présentation technique approfondie
26/09/2019 • 8 minutes to read • Edit Online

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.

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 : mettez en service l’authentification unique transparente Azure AD.
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é.
UserVoice : pour le dépôt de nouvelles demandes de fonctionnalités.
Confidentialité des utilisateurs et authentification
unique fluide Azure AD
17/09/2019 • 3 minutes to read • Edit Online

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. Si vous recherchez des informations
générales sur le RGPD, consultez la section RGPD du portail 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) {


{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.
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é.
UserVoice : pour le dépôt de nouvelles demandes de fonctionnalités.
Synchronisation d’Azure AD Connect :
Comprendre et personnaliser la synchronisation
17/09/2019 • 6 minutes to read • Edit Online

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é service de synchronisation Azure AD
Connect.

Rubriques de synchronisation Azure AD Connect


RUBRIQUE SUJET QU’ELLE ABORDE ET QUAND LA CONSULTER

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écrit la syntaxe du langage d’expression utilisé dans
déclaratif 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.
RUBRIQUE SUJET QU’ELLE ABORDE ET QUAND LA CONSULTER

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 Prend en charge les limitations imposées à la


configuration par défaut configuration 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 Décrit le fonctionnement de la synchronisation de mot de


passe 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.

Office 365 PreferredDataLocation Décrit comment placer les ressources Office 365 de
l’utilisateur dans la même région que l’utilisateur.

Service 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).
RUBRIQUE SUJET QU’ELLE ABORDE ET QUAND LA CONSULTER

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.

Ressources supplémentaires
Intégration des identités locales dans Azure Active Directory
Compte de service ADSync
17/09/2019 • 7 minutes to read • Edit Online

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 à Azure Active
Directory.
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.

Compte de service ADSync par défaut


Lorsqu'il est exécuté sur un serveur membre, le service AdSync s’exécute dans le contexte d’un compte de service
virtuel (VSA). En raison d'une limitation du produit, un compte de service personnalisé est créé lors d'une
l'installation sur un contrôleur de domaine. Si le compte de service des paramètres Express ne répond pas aux
exigences de sécurité de votre organisation, déployez Azure AD Connect en sélectionnant l'option Personnaliser.
Puis, choisissez l’option de compte de service qui répond aux besoins de votre organisation.

NOTE
Installé sur un contrôleur de domaine, le compte de service par défaut se présente comme suit :
Domain\AAD_InstallationIdentifier. Le mot de passe de ce compte est généré de façon aléatoire, ce qui peut être complexe en
termes de récupération et rotation du mot de passe. Microsoft recommande de personnaliser le compte de service lors de
l'installation initiale sur un contrôleur de domaine pour utiliser un compte de service administré autonome ou en groupe
(sMSA/gMSA)

EMPLACEMENT D'AZURE AD CONNECT COMPTE DE SERVICE CRÉÉ

Serveur membre NT SERVICE\ADSync

Contrôleur de domaine Domain\AAD_74dc30c01e80 (voir la remarque)

Comptes de service ADSync personnalisés


Microsoft recommande l'exécution du service ADSync dans le contexte d'un compte de service virtuel ou d'un
compte de service administré autonome ou en groupe. Votre administrateur de domaine peut également choisir de
créer un compte de service configuré pour répondre aux exigences de sécurité spécifiques de votre organisation.
Pour personnaliser le compte de service utilisé lors de l’installation, sélectionnez l’option Personnaliser sur la page
Paramètres Express ci-dessous. Les options suivantes sont disponibles :
compte par défaut – Azure AD Connect configure le compte de service comme décrit ci-dessus
compte de service administré - utilisez un compte de service administré autonome ou en groupe configuré par
votre administrateur
compte de domaine - utilisez un compte de service de domaine configuré par votre administrateur

Diagnostic des modifications du compte de service ADSync


Modifier les informations d'identification du service ADSync 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 ). L'octroi d'un accès de base de données au nouveau compte de service ADSync ne
suffit pas à résoudre ce problème. Aucune synchronisation ne sera possible avant la restauration des informations
d'identification d'origine.
S'il ne parvient pas à démarrer, le service ADSync génère un message dans le journal des événements. Le contenu
de ce message varie selon l'utilisation de la base de données intégrée (localdb) ou de SQL complet. Vous trouverez
ci-dessous quelques exemples d’entrées du journal des événements.
Exemple 1
Les clés de chiffrement du service AdSync sont introuvables et ont été recréées. La synchronisation n'interviendra
pas tant que ce problème n'aura pas été résolu.
Lors de la résolution de ce problème, les clés de chiffrement Microsoft Azure AD Sync seront inaccessibles en cas
de modification des informations d'identification de connexion au service AdSync. Si les informations
d’identification ont été modifiées, utilisez l’application Services pour rétablir la valeur d'origine du compte
d'ouverture de session (par exemple, NT SERVICE\AdSync) et redémarrez le service. Cela aura pour effet de
rétablir le bon fonctionnement du service AdSync.
Pour plus d’informations, consultez l'article suivant.
Exemple 2
Le service n’a pas pu démarrer en raison de l'impossibilité d'établir une connexion à la base de données locale
(localdb).
Lors de la résolution de ce problème, le service Microsoft Azure AD Sync ne sera plus autorisé à accéder au
fournisseur de base de données locale en cas de modification des informations d'identification de connexion au
service AdSync. Si les informations d’identification ont été modifiées, utilisez l’application Services pour rétablir la
valeur d'origine du compte d'ouverture de session (par exemple, NT SERVICE\AdSync) et redémarrez le service.
Cela aura pour effet de rétablir le bon fonctionnement du service AdSync.
Pour plus d’informations, consultez l'article suivant.
Autres détails Les informations d'erreur suivantes ont été renvoyées par le fournisseur :

OriginalError=0x80004005 OLEDB Provider error(s):


Description = 'Login timeout expired'
Failure Code = 0x80004005
Minor Number = 0
Description = 'A network-related or instance-specific error has occurred while establishing a connection to
SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is
configured to allow remote connections. For more information see SQL Server Books Online.'

É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
17/09/2019 • 7 minutes to read • Edit Online

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é service de synchronisation Azure AD Connect
Cette rubrique explique comment les fonctionnalités suivantes du service 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 :

DIRSYNCFEATURE COMMENTAIRE

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 :
DIRSYNCFEATURE COMMENTAIRE

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 un


DuplicateUPNResiliency 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 Azure


Active Directory

UnifiedGroupWriteback Préversion : Réécriture de groupe

UserWriteback Non pris en charge pour le moment.

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

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 sont remplies :
L’utilisateur est géré (non fédéré).
Aucune licence n’a été attribuée à l’utilisateur.
Pour plus d’informations, voir Les noms d’utilisateur dans Office 365, Azure ou Intune ne correspondent pas à
l’UPN local ou à l’ID de connexion secondaire.
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. Si vous utilisez la fédération, cette fonctionnalité n’est pas prise en charge.
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
Synchronisation d’Azure AD Connect
Intégration de vos identités locales avec Azure Active Directory.
Présentation de l’interface utilisateur de
Synchronization Service Manager d’Azure AD
Connect
17/09/2019 • 2 minutes to read • Edit Online

L’interface utilisateur de Synchronization Service 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 Service Manager à partir du menu Démarrer. Elle se
nomme Synchronization Service 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 .
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Synchronisation d’Azure AD Connect : Concepts
techniques
17/09/2019 • 8 minutes to read • Edit Online

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, ILM et FIM, 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.

Ressources supplémentaires
Synchronisation Azure AD Connect : personnaliser les options de synchronisation
Intégration des identités locales dans Azure Active Directory
Synchronisation d’Azure AD Connect : Présentation
de l’architecture
17/09/2019 • 44 minutes to read • Edit Online

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 « Importation
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’exportation » .
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
Synchronisation
Exportation
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 :
None. 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 la 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’importation. 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 sortante
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’exportation.
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
En savoir plus sur la configuration de la synchronisation Azure AD Connect .
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Synchronisation d’Azure AD Connect : Présentation
de l’approvisionnement déclaratif
17/09/2019 • 22 minutes to read • Edit Online

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.

OPÉRATION DESCRIPTION

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 letype 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 typessuivants : 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")))

Precedence
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
Intégration des identités locales dans Azure Active Directory
Rubriques de référence
Synchronisation Azure AD Connect : Référence des fonctions
Synchronisation d’Azure AD Connect : Comprendre
les expressions d’approvisionnement déclaratif
17/09/2019 • 7 minutes to read • Edit Online

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.


parameters
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 :
NOM DU PARAMÈTRE COMMENTAIRE

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%

Operators
Vous pouvez utiliser les opérateurs suivants :
Opérateurs de comparaison : <, <=, <>, =, >, >=
Mathématiques : +, -, *, -
Chaîne : & (concaténation)
Logiques : &&amp;amp;amp; (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.
Apprendre à effectuer une modification pratique à l’aide de l’approvisionnement déclaratif dans Comment
modifier la configuration par défaut.
Rubriques de présentation
Synchronisation Azure AD Connect : Comprendre et personnaliser la synchronisation
Intégration des identités locales dans Azure Active Directory
Rubriques de référence
Synchronisation Azure AD Connect : Référence des fonctions
Synchronisation d’Azure AD Connect : Présentation
de la configuration par défaut
17/09/2019 • 32 minutes to read • Edit Online

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.
CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0) . Ne synchronisez aucun objet victime de réplication.

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],&amp;H40000000) . Groupe de rôles.
CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0) . Ne synchronisez aucun objet victime de réplication.

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 Sortant
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 a la valeur Provision, un nouvel objet est créé dans la cible,
le métaverse. 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 .
Précédence
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 COMMENTAIRE

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 Office 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 COMMENTAIRE

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
Apprendre à effectuer une modification pratique à l’aide de l’approvisionnement déclaratif dans Comment
modifier la configuration par défaut.
Rubriques de présentation
Synchronisation Azure AD Connect : Comprendre et personnaliser la synchronisation
Intégration des identités locales dans Azure Active Directory
Synchronisation d’Azure AD Connect : Présentation
des utilisateurs, des groupes et des contacts
17/09/2019 • 10 minutes to read • Edit Online

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é.

Ressources supplémentaires
Synchronisation Azure AD Connect : personnaliser les options de synchronisation
Intégration des identités locales dans Azure Active Directory
Attributs de clichés instantanés du service de
synchronisation Azure AD Connect
17/09/2019 • 5 minutes to read • Edit Online

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é :

ATTRIBUT VALEUR

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 :

ATTRIBUT VALEUR

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. Cela est vrai 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 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
Synchronisation d’Azure AD Connect
Intégration de vos identités locales avec Azure Active Directory.
Feuille de route pour l’installation d’Azure AD
Connect et d’Azure AD Connect Health
17/09/2019 • 19 minutes to read • Edit Online

Installer Azure AD Connect


IMPORTANT
Microsoft ne prend pas en charge la modification ou l’utilisation de la synchronisation 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.

Vous pouvez trouver le téléchargement d’Azure AD Connect sur le Centre de téléchargement Microsoft.

SOLUTION SCÉNARIO

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
RUBRIQUE LIEN

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


RUBRIQUE LIEN

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
.

RUBRIQUE LIEN

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
RUBRIQUE LIEN

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

L’écriture différée d’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
RUBRIQUE LIEN

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
RUBRIQUE LIEN

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 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
RUBRIQUE LIEN

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 Office 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.
Consultez les instructions d’installation.

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 Directory 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 Services 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 Directory Federation Services : 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 Directory Domain Services : 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 :
L’entrée Paramètres inclut les configurations de base de vos agents. Le paramètre de mise à niveau
automatique permet de mettre automatiquement à jour l’agent Azure AD Connect Health avec la version
la plus récente : votre système est automatiquement mis à jour avec la dernière version disponible de
l’agent Azure AD Connect Health. Cette option est activée par défaut. Autorisation de l’accès, par
Microsoft, aux données d’intégrité de votre répertoire Azure AD à des fins exclusives de résolution des
problèmes : si cette option est activée, Microsoft peut consulter les données auxquelles vous avez accès.
L’accès à ces informations simplifient la résolution des problèmes. Elle 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
Matériel et conditions préalables
Paramètres Express
Paramètres personnalisés
Synchronisation de hachage de mot de passe|
Authentification directe
Fédération avec Azure AD Connect
Installation des agents Azure AD Connect Health
Synchronisation d’Azure AD Connect
Conditions préalables pour Azure AD Connect
17/09/2019 • 28 minutes to read • Edit Online

Cette rubrique décrit les conditions préalables et la configuration matérielle requise pour Azure AD Connect.

Avant d’installer Azure AD Connect


Avant d’installer Azure AD Connect, voici ce dont vous avez besoin.
Azure AD
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, vérifiez que ce domaine a été vérifié et que vous n’utilisez pas
uniquement le domaine par défaut contoso.onmicrosoft.com.
Un client Azure AD prend en charge 50 000 objets par défaut. Si vous vérifiez votre domaine, la limite
passe à 300 000 objets. Si vous avez besoin de davantage d’objets dans Azure AD, vous devez ouvrir une
demande de support pour que la limite soit relevée en conséquence. Si vous avez besoin de plus de
500 000 objets, si vous avez besoin d’une licence comme Office 365, Azure AD Standard, Azure AD
Premium ou Enterprise Mobility Suite.
Préparez vos données locales
Utilisez IdFix pour identifier les erreurs comme les problèmes de mise en forme dans votre annuaire et
repérer les doublons avant d’effectuer la synchronisation avec Azure AD et Office 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 au schéma et le 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 sous Windows Server 2008 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/domaines locaux utilisant des noms NetBios avec point (le nom contient un point ’.’)
n’est pas prise en charge.
Il est recommandé d’activer la Corbeille Active Directory.
Serveur Azure AD Connect

IMPORTANT
Le serveur Azure AD Connect contient des données d’identité critique et doit être traité comme un composant de niveau
0 comme expliqué dans le modèle de niveau administratif Active Directory.
Vous ne pouvez pas installer Azure AD Connect sur Small Business Server ou Windows Server Essentials
version antérieure à 2019 (Windows Server Essentials 2019 est pris en charge). Le serveur doit utiliser
Windows Server Standard ou une version supérieure.
L’installation d’Azure AD Connect sur un contrôleur de domaine n’est pas recommandée en raison des
pratiques de sécurité et de paramètres plus restrictifs pouvant empêchant Azure AD Connect de s’installer
correctement.
Le serveur Azure AD Connect doit disposer d’une interface utilisateur graphique complète. Il ne peut pas
être installé sur Server Core.

IMPORTANT
L’installation d’Azure AD Connect sur un petit serveur Business, Essentials ou Core n’est pas prise en charge.

Azure Active Directory Connect doit être installé sur Windows Server 2008 R2 ou version ultérieure. Ce
serveur doit être joint à un domaine et peut être un contrôleur de domaine ou un serveur membre.
Si vous installez Azure AD Connect sous Windows Server 2008 R2, veillez à appliquer les derniers
correctifs à partir de Windows Update. L’installation ne pourra pas démarrer sur un serveur non
corrigé.
Si vous prévoyez d’utiliser la fonctionnalité Synchronisation de mot de passe, le serveur
Azure AD Connect doit être exécuté sous Windows Server 2008 R2 SP1 ou une version ultérieure.
Si vous envisagez d’utiliser un compte de service administré de groupe, le serveur Azure AD
Connect doit se trouver sur Windows Server 2012 ou version ultérieure.
.NET Framework 4.5.1 (ou une version ultérieure) et Microsoft PowerShell 3.0 (ou une version
ultérieure) doivent être installés sur le serveur Azure AD Connect.
La stratégie de groupe PowerShell Transcription ne doit pas être activée sur le serveur Azure AD
Connect.
Si les services de fédération Active Directory sont déployés, les serveurs sur lesquels ces services ou le
proxy d’application web sont installés doivent être des serveurs Windows Server 2012 R2 ou version
ultérieure. gestion à distance de Windows doit être activée sur ces serveurs pour l’installation à distance.
Si Active Directory Federation Services est déployé, vous avez besoin de certificats SSL.
Si des services ADFS sont déployés, vous devrez configurer une résolution de noms.
Si l’authentification MFA est activée pour vos administrateurs généraux,
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 MFA et qu’il n’a pas ajouté. Vous pouvez utiliser Internet Explorer pour l’ajouter à vos
sites de confiance.
Microsoft vous recommande 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. L’application des
recommandations ci-après vous permettra de limiter les risques pour la sécurité dans votre
organisation.
Déployez Azure AD Connect sur un serveur joint au domaine et restreignez l’accès administratif aux
administrateurs de domaine ou à d’autres groupes de sécurité étroitement contrôlés.
Pour plus d'informations, consultez les rubriques suivantes :
Securing administrators groups (Sécurisation des groupes d’administrateurs)
Securing built-in administrator accounts (Sécurisation des comptes Administrateur intégrés)
Security improvement and sustainment by reducing attack surfaces (Amélioration et maintien en état de
la sécurité par la réduction des surfaces d’attaque)
Reducing the Active Directory attack surface (Réduction de la surface d’attaque Active Directory)
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 SQL Server 2012 Express LocalDB (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 d’annuaire, vous devez pointer 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 Microsoft SQL Server à partir de 2008 R2
(avec le dernier Service Pack) et jusqu’à SQL Server 2019. Microsoft Azure SQL Database n’est pas
pris en charge comme 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 de
l’instance SQL avec FIM/MIM Sync, DirSync ou Azure AD Sync n’est pas pris en charge.
Comptes
Le compte d’administrateur global Azure AD du locataire Azure AD que vous souhaitez intégrer. Ce compte
doit être un compte scolaire ou d’organisation et non d’un compte Microsoft.
Si vous utilisez la configuration rapide ou effectuez une mise à niveau depuis DirSync, vous devez disposer
d’un compte d’administrateur d’entreprise pour votre annuaire Active Directory local.
Des comptes dans Active Directory si vous utilisez le chemin d’installation des paramètres personnalisés ou
un compte Administrateur d’entreprise pour votre annuaire Active Directory local.
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.
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.
Si vous utilisez Microsoft Cloud en Allemagne ou le cloud Microsoft Azure Government, consultez
Considérations sur les instances de service Sync Azure AD Connect relatives aux 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).
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 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 réelle ou le
nom d’hôte du proxy.

<system.net>
<defaultProxy>
<proxy
usesystemdefault="true"
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>

Si votre serveur proxy nécessite une authentification, le compte de service doit se trouver dans le domaine,
et vous devez utiliser 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 ressembler à ceci.

<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
usesystemdefault="true"
proxyaddress="http://<PROXYADDRESS>:<PROXYPORT>"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>

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 : 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 et le .NET Framework 4.5.1. Cette version ou une version
ultérieure doit être installée sur votre serveur. Selon votre version de Windows Server, procédez comme suit :
Windows Server 2012 R2
Microsoft PowerShell est installé par défaut. Aucune action n’est requise.
Les versions .NET Framework 4.5.1 et ultérieures sont offertes par le biais de Windows Update.
Assurez-vous que vous avez installé les dernières mises à jour de Windows Server dans le Panneau
de configuration.
Windows Server 2008 R2 et Windows Server 2012
La dernière version de Microsoft PowerShell est disponible dans Windows Management
Framework 4.0, dans le Centre de téléchargement Microsoft.
.NET Framework 4.5.1 et les versions ultérieures sont disponibles dans le Centre de téléchargement
Microsoft.
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 modifier ce
comportement en configurant les applications .NET pour qu’elles utilisent TLS 1.2 par défaut sur le serveur.
Vous trouverez plus d’informations sur TLS 1.2 dans l’Avis de sécurité Microsoft 2960358.
1. TLS 1.2 ne peut pas être activé sur les versions Windows Server 2008 R2 ou ultérieures. Vérifiez que le
correctif .NET 4.5.1 est installé pour votre système d’exploitation. 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. Si vous utilisez Windows Server 2008 R2, vérifiez que TLS 1.2 est activé. Sur le serveur Windows Server
2012 et les versions ultérieures, TLS 1.2 doit déjà être activé.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001

3. 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

4. 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.

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 Active Directory Federation Services ou le proxy
d’application Web, vérifiez ces exigences :
Si le serveur cible est joint à un domaine, assurez-vous que la gestion à distance Windows est activée
Dans une fenêtre de commandes PSH 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 winrm (Windows Remote Management/WS -Management) s'exécute
via le composant logiciel enfichable Services.
Dans une fenêtre de commandes PSH avec élévation de privilèges, utilisez la commande
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 est joint à un domaine non fiable) :
Dans une fenêtre de commandes PSH avec élévation de privilèges, utilisez la commande
Set-Item WSMan:\localhost\Client\TrustedHosts –Value <DMZServerFQDN> -Force –Concatenate
Dans le Gestionnaire de serveur :
Ajoutez un hôte WAP DMZ au pool d’ordinateurs (Gestionnaire de serveur -> Gérer ->
Ajouter des serveurs... Onglet Utiliser DNS )
Onglet Gestionnaire de serveur, onglet Tous les serveurs : cliquez avec le bouton droit
sur le serveur WAP et sélectionnez Gérer en tant que..., entrez des informations
d'identification locales (et pas un domaine) pour l'ordinateur WAP.
Pour valider la connectivité à distance PSH, dans le Gestionnaire de serveur, onglet
Tous les serveurs : cliquez avec le bouton droit sur le serveur WAP et choisissez
Windows PowerShell. Une session à distance PSH doit s’ouvrir pour garantir le fait que
des sessions PowerShell distantes peuvent être établies.
Configuration requise des certificats SSL
Il est fortement recommandé d’utiliser le même certificat SSL sur tous les nœuds de votre batterie de
serveurs AD FS, ainsi que sur tous les serveurs 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. Toutefois, 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 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
de service de fédération.
Si vous envisagez d'utiliser une jonction d'espace de travail, un autre nom d’objet supplémentaire 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
ne sont pas pris en charge. Cela signifie que vous devez utiliser un certificat basé sur un fournisseur de
services de chiffrement et non sur un fournisseur de stockage de clés.
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 de service de fédération AD FS (par exemple,
sts.contoso.com) pour l’Intranet (votre serveur DNS interne) et l’extranet (le DNS public via votre bureau
d’enregistrement de domaines). Pour l’enregistrement DNS intranet, vérifiez que vous utilisez des
enregistrements A et non des enregistrements CNAME. Ceci est requis pour le bon fonctionnement de
l’authentification Windows à partir de l’ordinateur associé à votre domaine.
Si vous déployez plusieurs serveurs AD FS ou serveurs proxy d’application web, vérifiez que vous avez
configuré votre équilibreur de charge et que les enregistrements DNS pour le nom de service de fédération
AD FS (par ex., sts.contoso.com) pointent vers l’équilibreur de charge.
Pour que l’authentification Windows intégrée fonctionne avec les applications de navigateur utilisant
Internet Explorer dans votre Intranet, vérifiez que le nom de service de fédération AD FS (par exemple,
sts.contoso.com) est ajouté à la zone Intranet dans Internet Explorer. Vous pouvez vérifier cela par le biais
de la stratégie de groupe, puis procéder au déploiement vers tous les ordinateurs associés à votre domaine.
Composants de prise en charge d’Azure AD Connect
Voici une liste de composants qu’Azure AD Connect installe 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 Server dans
la page d’installation des services de synchronisation, SQL Express LocalDB n’est pas installé localement.
Azure AD Connect Health
Utilitaires de ligne de commande Microsoft SQL Server 2012
Base de données locale Microsoft SQL Server 2012 Express
Client natif Microsoft SQL Server 2012
Package de redistribution Microsoft Visual C++ 2013

Configuration matérielle requise pour Azure AD Connect


Le tableau ci-dessous présente la configuration minimale requise pour l’ordinateur de synchronisation
Azure AD Connect.

NOMBRE D’OBJETS DANS


ACTIVE DIRECTORY UC MÉMOIRE TAILLE DU DISQUE 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

Dans les systèmes


comportant 100 000 objets
ou plus, la version complète
de SQL Server est requise.

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 les services de fédération Active Directory
ou les serveurs 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
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Sélectionner le type d’installation à utiliser pour Azure
AD Connect
17/09/2019 • 5 minutes to read • Edit Online

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.

Personnalisée
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
17/09/2019 • 6 minutes to read • Edit Online

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.
2. Accédez à AzureADConnect.msiet 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 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.
8. Sur l’écran Prêt à configurer, cliquez sur Installer.
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.
9. Une fois l’installation terminée, cliquez sur Quitter.
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.

vidéos
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.
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.

documentation connexe
RUBRIQUE LIEN

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)
RUBRIQUE LIEN

Comptes utilisés pour l’installation Autorisations et informations d’identification Azure AD


Connect
Installation personnalisée d’Azure AD Connect
03/10/2019 • 56 minutes to read • Edit Online

Les paramètres personnalisés Azure AD Connect sont utilisés lorsque vous souhaitez davantage d’options
d’installation. Ils sont utiles si vous disposez de plusieurs forêts ou si vous voulez configurer des
fonctionnalités facultatives que l’installation rapide ne propose pas. Ils sont utilisés dans tous les cas où
l’option d’installation rapide ne convient pas à votre déploiement ou à votre topologie.
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. Assurez-vous également de
disposer des comptes comme décrit dans Autorisations et comptes Azure AD Connect.
Si les paramètres personnalisés ne correspondent pas à votre topologie, pour mettre à niveau DirSync, par
exemple, consultez la documentation connexe pour d’autres scénarios.

Installation des paramètres personnalisés d’Azure AD Connect


Paramètres Express
Dans cette page, cliquez sur Personnaliser pour démarrer une installation des paramètres personnalisés.
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. Ce logiciel configure
une instance de SQL Server 2012 Express LocalDB et crée les groupes appropriés, en attribuant des
autorisations. Si vous souhaitez modifier les valeurs par défaut, vous pouvez utiliser le tableau ci-après pour
comprendre les différentes options de configuration facultatives à votre disposition.
CONFIGURATION FACULTATIVE DESCRIPTION

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. Si la navigation
n’est pas activée sur votre serveur SQL Server, saisissez le
nom de l’instance dans la zone Nom de l’instance , suivi
d’une virgule et du numéro de port. 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 sera
créée ou si votre administrateur SQL doit créer la base de
données à l’avance. Si vous disposez d’autorisations
d’administrateur système SQL, consultez Installer Azure AD
Connect à l’aide d’une base de données ADSync 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.

Utiliser un compte de service existant Par défaut, Azure AD Connect utilise un compte de service
virtuel, que les services de synchronisation doivent utiliser.
Si vous utilisez un serveur SQL Server distant ou un proxy
qui requiert une authentification, vous devez utiliser un
compte de service géré ou un compte de service dans le
domaine et devez connaître le mot de passe. Dans ce cas,
entrez le compte à utiliser. Assurez-vous que l’utilisateur qui
exécute l’installation est une association de sécurité dans
SQL pour qu’il soit possible de créer une session pour le
compte de service. Consultez Autorisations et comptes
Azure AD Connect.
Avec la version la plus récente, l’approvisionnement 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 des droits du
propriétaire de la base de données. Pour plus
d’informations, consultez la section Install Azure AD
Connect using SQL delegated administrator permissions
(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, Azure AD Connect crée quatre groupes locaux
sur le serveur lorsque les services de synchronisation sont
installés. Ces groupes sont Administrateurs, Opérateurs,
Parcourir et Réinitialisation du mot de passe. Vous pouvez
spécifier vos propres groupes ici. Les groupes doivent être
locaux sur le serveur et ne peuvent pas être situés dans le
domaine.

Connexion de l’utilisateur
Après avoir installé les composants requis, vous êtes invité à sélectionner la méthode d’authentification
unique de vos utilisateurs. Le tableau ci-après fournit une brève description des options disponibles. Pour une
description complète des méthodes de connexion, consultez Connexion de l’utilisateur.
OPTION D’AUTHENTIFICATION UNIQUE DESCRIPTION

Synchronisation de hachage de mot de passe Les utilisateurs peuvent se connecter aux services cloud
Microsoft, comme Office 365, à l’aide du mot de passe
qu’ils utilisent dans leur réseau local. Les mots de passe des
utilisateurs sont synchronisés sur Azure, via un hachage de
mot de passe, et l’authentification est effectuée 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


Microsoft, comme Office 365, à l’aide du mot de passe
qu’ils utilisent dans leur réseau local. Le mot de passe de
l’utilisateur est ensuite transmis vers le contrôleur de
domaine Active Directory local à valider.

Fédération avec AD FS Les utilisateurs peuvent se connecter aux services cloud


Microsoft, comme Office 365, à l’aide du mot de passe
qu’ils utilisent dans leur réseau local. Ils sont redirigés vers
leur instance AD FS locale, la connexion et l’authentification
étant effectuées en local.

Fédération avec PingFederate Les utilisateurs peuvent se connecter aux services cloud
Microsoft, comme Office 365, à l’aide du mot de passe
qu’ils utilisent dans leur réseau local. Ils sont redirigés vers
leur instance PingFederate locale, la connexion et
l’authentification étant effectuées en local.

Ne pas configurer Aucune fonctionnalité de connexion utilisateur n’est


installée ni configurée. Choisissez cette option si vous
disposez déjà d’un serveur de fédération tiers ou d’une
autre solution.
OPTION D’AUTHENTIFICATION UNIQUE DESCRIPTION

Activer l'authentification unique Cette option est disponible avec la synchronisation de


hachage de mot de passe et l’authentification directe, et
fournit une expérience d’authentification unique pour les
utilisateurs du réseau d’entreprise. Pour plus d’informations,
consultez Authentification unique.
Notez que pour les clients AD FS, cette option n’est pas
disponible car AD FS offre déjà le même niveau
d’authentification unique.

Se connecter à Azure AD
Sur l’écran 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. Il est recommandé d’utiliser un
compte du domaine onmicrosoft.com par défaut, qui est fourni avec votre locataire Azure AD.
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é.

Si la fonction MFA est activée sur votre compte d’administrateur global, vous devez à nouveau fournir le mot
de passe dans la fenêtre contextuelle de connexion et passer le test MFA. Ce test peut consister à fournir 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 et que vous avez des problèmes de connectivité, consultez Résoudre les problèmes
de connectivité liés à Azure AD Connect.

Pages de la section Synchronisation


Connexion de vos annuaires
Pour vous connecter à votre service de domaine Active Directory, Azure AD Connect a besoin du nom de la
forêt et des informations d’identification d’un compte doté d’autorisations suffisantes.
Après avoir saisi le nom de la forêt et cliqué sur Ajouter un répertoire, une boîte de dialogue contextuelle
contenant les options suivantes s’affiche :

OPTION DESCRIPTION

Créer un compte Sélectionnez cette option si vous souhaitez que l’Assistant


Azure AD Connect crée le compte AD DS dont il a besoin
pour se connecter à la forêt AD pendant la synchronisation
des répertoires. Lorsque cette option est 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 sera utilisé par l’Assistant Azure AD
Connect pour créer le compte AD DS requis. Vous pouvez
saisir la partie domaine au format NetBios ou nom de
domaine complet, c’est-à-dire FABRIKAM\administrator ou
fabrikam.com\administrator.

Utiliser un compte existant Sélectionnez cette option si vous souhaitez qu’Azure AD


Connect utilise un compte AD DS existant pour se
connecter à la forêt AD pendant la synchronisation des
répertoires. Vous pouvez saisir la partie domaine au format
NetBios ou nom de domaine complet, par exemple,
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, voir
Autorisations et comptes Azure AD Connect.
Les comptes Administrateur d’entreprise et Administrateur de domaine ne sont pas pris en charge
À partir de la build 1.4.###.#, il n’est plus possible d’utiliser un compte administrateur d’entreprise ou un
compte administrateur de domaine comme compte de connecteur AD DS. Si vous tentez d’entrer un compte
administrateur d’entreprise ou administrateur de domaine tout en spécifiant utiliser un compte existant,
vous recevrez une erreur.
Configuration de connexion AD Azure
Cette page permet d’examiner les domaines UPN présents dans les services de domaine AD locaux et qui 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é 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. Pour plus d’informations, consultez Ajouter et vérifier le domaine
UserPrincipalName : cet attribut est utilisé par les utilisateurs lorsqu’ils se connectent à Azure AD et Office
365. Les domaines utilisés, également nommés « Suffixe UPN » doivent être vérifiés dans Azure AD avant la
synchronisation des utilisateurs. Microsoft recommande de conserver la valeur d’attribut userPrincipalName
par défaut. Si cet attribut ne peut pas être acheminé ni 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. Tout attribut utilisé à la place de l’élément userPrincipalName est qualifié d’ ID secondaire. La
valeur de l’attribut ID secondaire doit suivre la norme RFC822. Un ID secondaire est utilisable avec la
synchronisation de hachage de mot de passe, l’authentification directe et la fédération. L’attribut ne doit pas
être défini dans Active Directory en tant que valeurs multiples, même s’il ne possède qu’une seule valeur. Pour
plus d’informations sur l’ID de substitution, cliquez ici.

NOTE
Lorsque vous activez l’authentification directe, vous devez disposer d’au moins un domaine vérifié pour pouvoir
continuer l’assistant.

WARNING
L’utilisation d’un ID secondaire n’est pas compatible avec toutes les charges de travail Office 365. Pour plus
d’informations, consultez Configuration d’un ID secondaire de connexion.

Filtrage domaine et unité organisationnelle


Par défaut, tous les domaines et unités d’organisation sont synchronisés. S’il existe des domaines ou des
unités d’organisation que vous ne souhaitez pas synchroniser avec Azure AD, vous pouvez les désélectionner.
Cette page de l’Assistant porte sur la configuration du filtrage par domaine et par unité d’organisation. Si
vous envisagez d’apporter des modifications, consultez les pages Filtrage par domaine et Filtrage par unité
d’organisation au préalable. Certaines unités d’organisation sont essentielles pour les fonctionnalités et ne
doivent pas être désélectionnées.
Si vous utilisez le filtrage basé sur l’unité d’organisation avec une version d’Azure AD Connect antérieure à la
version 1.1.524.0, les nouvelles unités d’organisation ajoutées par la suite sont synchronisées par défaut. Si
vous souhaitez que les nouvelles unités d’organisation ne soient pas synchronisées, vous pouvez configurer la
synchronisation une fois que l’Assistant a terminé le filtrage basé sur l’unité d’organisation. Pour Azure AD
Connect version 1.1.524.0 ou supérieure, vous pouvez indiquer si les nouvelles unités d’organisation doivent
être synchronisées ou non.
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 basé sur l’unité d’organisation. Le filtrage basé sur l’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
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 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.
PARAMÈTRE DESCRIPTION

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 sélectionnée, les
objets utilisateur dont l’attribut de messagerie n’est pas
rempli ne sont pas synchronisés avec Azure AD.

ObjectSID et msExchangeMasterAccountSID/ msRTCSIP- Cette option associe un utilisateur activé dans une forêt de
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 ». Cette option peut
également être utilisée si vous utilisez uniquement Lync et
si Exchange n’est pas présent dans la forêt de ressources.

sAMAccountName et MailNickName Cette option associe des attributs où l’ID de connexion est
requis pour rechercher l’utilisateur.

Un attribut spécifique Cette option vous permet de sélectionner votre propre


attribut. Si cette option est sélectionnée, les objets
utilisateur dont l’attribut de messagerie (sélectionné) n’est
pas rempli ne sont pas synchronisés avec Azure AD.
Limitation : assurez-vous de sélectionner un attribut qui
existe déjà dans le métaverse. Si vous sélectionnez un
attribut personnalisé (non présent dans le métaverse),
l’assistant échoue.

Sélectionnez la façon dont les utilisateurs doivent être identifiés avec Azure AD - 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.

PARAMÈTRE DESCRIPTION

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 logique de
sélection d’attribut sourceAnchor décrite dans l’article Azure
AD Connect : Principes de conception - Utilisation de ms-
DS-ConsistencyGuid en tant qu’attribut sourceAnchor.
L’Assistant vous indique quel attribut a été sélectionné
comme attribut d’ancre source 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.

Comme l’attribut ne peut pas être modifié, vous devez prévoir l’attribut adéquat à utiliser.Pour cela, nous vous
recommandons objectGUID. Cet attribut ne change pas, sauf si le compte d’utilisateur est déplacé entre les
forêts/domaines. Évitez les attributs susceptibles de changer si une personne se marie ou si son affectation est
modifiée. Vous ne pouvez pas utiliser d’attributs avec @-sign, donc les adresses de messagerie et
userPrincipalName ne peuvent pas être utilisés. Par ailleurs, l’attribut respecte la casse ; si vous déplacez un
objet entre des forêts, veillez à conserver ses minuscules/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, cet attribut est également appelé « immutableID ». Vous trouverez plus
d’informations sur l’ancre source dans les 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
répertoire Active Directory local. 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 un membre direct du groupe. Les utilisateurs, les groupes, les contacts et 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 est difficile de maintenir un seul groupe avec tous les objets à
synchroniser. Nous vous recommandons plutôt d’utiliser l’une des méthodes décrites dans la section
Configurer le filtrage.
Fonctionnalités facultatives
Cet écran vous permet de sélectionner des fonctionnalités facultatives pour vos scénarios spécifiques.

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 sera 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é. La réécriture du mot de passe avec ces
versions d’Azure AD Connect ne sera pas prise en charge.
Pour plus d’informations sur Azure Access Control Service, consultez Guide pratique pour effectuer une migration à
partir d’Azure Access Control Service.
Pour télécharger la dernière version d’Azure AD Connect, cliquez ici.
WARNING
Si DirSync ou Azure AD Sync sont actuellement actifs, n’activez aucune des fonctionnalités d’écriture différée dans
Azure AD Connect.

FONCTIONNALITÉS FACULTATIVES DESCRIPTION

Déploiement Exchange hybride La fonctionnalité de déploiement Exchange hybride permet


la coexistence de boîtes aux lettres Exchange en local et
dans Office 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 Active Directory local 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.
FONCTIONNALITÉS FACULTATIVES DESCRIPTION

Synchronisation de hachage de mot de passe Si vous avez sélectionné la fédération comme solution de
connexion, vous pouvez activer cette option. La
synchronisation de hachage du mot de passe peut ensuite
servir d’option de sauvegarde. Pour plus d’informations,
consultez Synchronisation de hachage du mot de passe.
Si vous avez sélectionné l’authentification directe, cette
option peut également être activée pour assurer la prise en
charge pour les clients hérités et servir d’option de
sauvegarde. Pour plus d’informations, consultez
Synchronisation de hachage du mot de passe.

Réécriture du mot de passe Lorsque vous activez l’écriture différée du mot de passe, 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 la fonctionnalité Groupes dans Office 365 ,
ces groupes peuvent être représentés dans votre annuaire
Active Directory local. Cette option n’est disponible que si
Exchange est présent dans votre annuaire Active Directory
local. Pour en savoir plus, voir Écriture différée de groupe.

É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’annuaire Active Directory local, 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 Si vous activez la synchronisation des attributs des
extensions de répertoire, les attributs spécifiés seront
synchronisé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 apportez des modifications de configuration sur cette page, vous devez sélectionner
un nouveau service de manière explicite, en exécutant à nouveau 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 certains attributs ne doivent
pas être synchronisés, vous pouvez les désélectionner.
WARNING
La suppression d’attributs peut affecter la fonctionnalité. Pour consulter des recommandations et meilleures pratiques,
voir Attributs synchronisés.

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 cette page, 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 (SSO )
La configuration de l’authentification unique pour une utilisation avec la synchronisation des mots de passe
ou l’authentification directe est un processus simple que vous n’avez à effectuer qu’une fois par forêt
synchronisée avec Azure AD. La configuration implique les deux étapes suivantes :
1. création du compte d’ordinateur nécessaire dans votre annuaire Active Directory local ;
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 utilisées uniquement pour créer le compte et ne sont pas stockées ni
utilisées pour d’autres opérations. Ajoutez simplement les informations d’identification sur la page Activer
l’authentification unique de l’Assistant Azure AD Connect, comme indiqué ci-dessous :

NOTE
Vous pouvez ignorer une forêt particulière si vous ne souhaitez pas utiliser l’authentification unique avec celle-ci.

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 la zone
intranet. 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. Ouvrir 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 de sécurité et sélectionnez Liste des
attributions de sites aux zones, comme sur l’image ci-dessous.
4. Activez la stratégie, puis entrez l’élément suivant dans la boîte de dialogue.

Value: `https://autologon.microsoftazuread-sso.com`
Data: 1

5. Le résultat doit être semblable à ce qui suit :


6. Cliquez sur OK deux fois.

Configuration de la fédération avec AD FS


La configuration d’AD FS avec Azure AD Connect est simple et s’effectue en quelques clics seulement. Pour
pouvoir procéder à la configuration, vous devez disposer des éléments suivants.
Un serveur Windows Server 2012 R2 ou version ultérieure pour le serveur de fédération avec la gestion
distante activée
Un serveur Windows Server 2012 R2 ou version ultérieure pour le serveur proxy d’application web avec la
gestion distante activée
Un certificat 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 SSL de la batterie de serveurs AD FS à l’aide du logiciel Azure AD Connect et ce,
même si vous le 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. En
outre, passez en revue les exigences en matière de ports répertoriées dans le Tableau 3 : 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 existante ou en créer une. Si vous choisissez de créer une
batterie de serveurs, vous devez fournir le certificat SSL. Si ce dernier est protégé par un mot de passe, vous
devez fournir ce mot de passe.

Si vous choisissez d’utiliser une batterie de serveurs AD FS existante, vous êtes dirigé directement vers l’écran
de configuration de 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 pour laquelle Azure AD est configuré sur la batterie de serveurs AD FS sélectionnée, cette
approbation est recréée de A à Z par Azure AD Connect.

Spécification des serveurs AD FS


Indiquez les serveurs sur lesquels vous souhaitez installer AD FS. Vous pouvez ajouter un ou plusieurs
serveurs selon vos besoins de planification de capacité. Joignez tous les serveurs AD FS (non requis pour les
serveurs WAP ) à Active Directory avant d’effectuer cette configuration. 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
Indiquez les serveurs spécifiques que vous souhaitez utiliser en tant que serveurs proxy d’application web. Les
serveurs proxy d’application web sont déployés dans votre DMZ (accès extranet) et prennent en charge les
demandes d’authentification provenant de l’extranet. Vous pouvez ajouter un ou plusieurs serveurs selon vos
besoins de planification 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 WAP, 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
d’effectuer cette étape.
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. Cette connexion doit utiliser des informations d’identification
de 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 service géré de groupe : il a été introduit dans les services de domaine Active Directory avec
Windows Server 2012. Ce type de compte fournit des services tels qu’AD FS, ainsi qu’un compte unique,
sans qu’il soit nécessaire de mettre régulièrement à jour le mode de passe du compte. 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 requiert un mot de passe, ainsi que des mises à
jour régulières à chaque modification ou expiration du mot de passe. 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é le compte de service géré de groupe et que cette fonctionnalité n’a jamais été utilisée
dans Active Directory, vous êtes invité à saisir 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 effectue une vérification afin de détecter si le service AD FS est déjà inscrit en tant que nom SPN
dans le domaine. AD DS empêche immédiatement l’inscription de noms SPN en double. Si un nom SPN en double est
trouvé, vous ne pouvez pas poursuivre l’opération avant d’avoir supprimé le SPN.

Sélection du domaine Azure AD à fédérer


Cette opération permet de configurer la relation de fédération entre AD FS et Azure AD. Il s’agit de configurer
AD FS pour émettre des jetons de sécurité pour Azure AD et de configurer Azure AD pour approuver les
jetons de cette instance d’AD FS spécifique. Durant l’installation initiale, cette page vous permet de configurer
un seul domaine. 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 à fédérer, Azure AD Connect vous fournit les informations nécessaires
pour vérifier un domaine non vérifié. Pour savoir comment utiliser ces informations, voir Ajouter et vérifier le
domaine .
NOTE
Azure AD Connect tente de vérifier le domaine pendant l’étape de configuration. Si vous poursuivez la configuration
sans ajouter les enregistrements DNS requis, l’Assistant n’est pas en mesure d’effectuer la configuration.

Configuration de la fédération avec PingFederate


La configuration de PingFederate avec Azure AD Connect est simple et s’effectue en quelques clics seulement.
En revanche, les prérequis suivants sont indispensables.
PingFederate 8.4 ou version ultérieure. Pour plus d’informations, consultez Intégration de PingFederate à
Azure Active Directory et Office 365
Un certificat 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 sélectionné la fédération avec PingFederate, vous êtes invité à vérifier le domaine que vous voulez
fédérer. Sélectionnez le domaine dans la liste déroulante.

Exporter les paramètres PingFederate


PingFederate doit être configuré en tant que serveur de fédération pour chaque domaine Azure fédéré.
Cliquez sur le bouton Paramètres d’exportation et partagez 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 un
exemple de 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é. Lorsque cette opération réussit, la fédération avec PingFederate est correctement configurée.
Pages de configuration et de vérification
La configuration se produit sur cette page.

NOTE
Avant de poursuivre l’installation, si vous avez configuré la fédération, vérifiez que vous avez défini la fonction de
résolution de noms pour les serveurs de fédération.

Mode intermédiaire
Vous pouvez configurer un nouveau serveur de synchronisation en parallèle avec le mode intermédiaire. Le
système prend en charge une seule exportation directe de serveur de synchronisation vers un seul annuaire
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. Lorsqu’il est
activé, le moteur de synchronisation importe et synchronise les données comme d’habitude, mais n’exporte
aucune information vers Azure AD ou AD. En mode intermédiaire, les fonctionnalités de
synchronisation/d’écriture différée 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 pour vous.
Vérifications de la 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.
Vérifications de la 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 vérifier que l’authentification de bout en bout réussit, vous devez effectuer manuellement un ou
plusieurs des tests suivants :
Une fois que la synchronisation est terminée, utilisez la tâche supplémentaire Vérifier la connexion fédérée
dans Azure AD Connect pour vérifier l’authentification d’un compte d’utilisateur local de votre choix.
Validez la connexion d’un navigateur à partir d’une machine jointe au domaine sur l’intranet : connectez-
vous à https://myapps.microsoft.com et vérifiez la connexion avec votre compte connecté. Le compte
d’administrateur 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 et fournissez vos
informations d’identification.
Valider la connexion à un client complet. Pour cela, connectez-vous à https://testconnectivity.microsoft.com,
sélectionnez l’onglet Office 365, puis Test d’authentification unique dans Office 365.

Résolution de problèmes
La section suivante contient des informations générales et de dépannage que vous pouvez utiliser si vous
rencontrez un problème lors de l’installation d’Azure AD Connect.
« 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 )
Lorsque vous procédez à une installation personnalisée d’Azure AD Connect et que vous sélectionnez l’option
Use an existing SQL server (Utiliser un serveur SQL existant) sur la page Install required components
(installer les composants requis), vous pouvez rencontrer une erreur indiquant The ADSync database
already contains data and cannot be overwritten. 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.)

Cela provient du fait qu’il existe déjà une base de données nommée ADSync sur l’instance SQL de SQL
server, que vous avez spécifiée dans les zones de texte au-dessus.
Cela se produit généralement après avoir désinstallé Azure AD Connect. La base de données n’est pas
supprimé du serveur SQL Server après désinstallation.
Pour résoudre ce problème, vérifiez d’abord que la base de données ADSync qui a été utilisée par Azure AD
Connect avant d’être désinstallée n’est plus utilisée.
Ensuite, il est recommandé de sauvegarder la base de données avant de la supprimer.
Enfin, vous devez supprimer la base de données. Vous pouvez le faire à l’aide de Microsoft SQL Server
Management Studio et en vous connectant à l’instance SQL. Recherchez la base de données ADSync,
cliquez avec le bouton droit dessus, puis sélectionnez Supprimer dans le menu contextuel. Ensuite, cliquez sur
le bouton OK pour la supprimer.
Après avoir supprimé la base de données ADSync, vous pouvez cliquer sur le bouton Installer pour tenter à
nouveau l’installation.

Étapes suivantes
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.
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 : Prévenir les
suppressions accidentelles et Azure AD Connect Health.
Pour en savoir plus sur ces sujets courants, consultez l’article Planificateur Azure AD Connect Sync.
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Authentification directe Azure Active Directory :
Démarrage rapide
17/09/2019 • 18 minutes to read • Edit Online

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.

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.
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 2012 R2 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.
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 2012 R2 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 :

NUMÉRO DE PORT UTILISATION

80 Télécharge les listes de révocation de certificats lors de


la validation du certificat 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 votre proxy autorise la mise en liste verte de DNS, vous pouvez y placer les
connexions vers *.msappproxy.net et *.servicebus.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.
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 valider le certificat, débloquez les URL suivantes : mscrl.microsoft.com:80,
crl.microsoft.com:80, ocsp.msocsp.com:80 et www.microsoft.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.

É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 Directory 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 :
Chaque requête a une taille de charge utile de (0,5 K + 1 K * num_of_agents) octets. Ceci concerne les données
d’Azure AD vers l’agent d’authentification. Ici, « num_of_agents » indique le nombre d’agents d’authentification
inscrit sur votre abonné.
Chaque réponse a une taille de charge utile de 1 kilooctet. Ceci concerne les données de l’agent
d’authentification vers 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 Directory 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. Lisez 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 "AppProxyPSModule" -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
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 : 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.
Résoudre les problèmes : apprenez à résoudre les problèmes courants liés à la fonctionnalité d'authentification
directe.
Présentation approfondie de sécurité : obtenez des informations techniques sur la fonctionnalité
d'authentification directe.
Authentification unique transparente 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.
Installation de l'agent Azure AD Connect Health
17/09/2019 • 33 minutes to read • Edit Online

Ce document vous guide à travers l’installation et la configuration des agents Azure AD Connect Health. Vous
pouvez télécharger les agents ici:

Configuration requise
Le tableau qui suit est une liste d’exigences d’utilisation d’Azure AD Connect Health.

PRÉREQUIS DESCRIPTION

Azure AD Premium Azure AD Connect Health est une fonctionnalité d’Azure AD


Premium qui nécessite Azure AD Premium.

Pour plus d'informations, consultez la section Prise en main


d’Azure AD Premium
Pour démarrer une période d’évaluation gratuite de 30 jours,
consultez Démarrer l’essai gratuit.

Vous devez être administrateur général de votre instance Par défaut, seuls les administrateurs généraux peuvent
Azure AD pour démarrer Azure AD Connect Health installer et configurer les agents d’intégrité afin de permettre
leur démarrage, 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.

À l’aide du contrôle d’accès en fonction du rôle, vous pouvez


accorder l’accès à Azure AD Connect Health à d’autres
utilisateurs dans votre organisation. Pour plus
d’informations, consultez Contrôle d’accès en fonction du
rôle pour Azure AD Connect Health.

Important : Le compte utilisé lors de l’installation des agents


doit être un compte professionnel ou scolaire. Il ne peut pas
s’agir d’un compte Microsoft. Pour plus d’informations,
consultez Inscription à Azure en tant qu’organisation

L’agent Azure AD Connect Health est installé sur chaque Azure AD Connect Health nécessite que les agents d’intégrité
serveur cible soient installés et configurés sur les serveurs cibles pour
recevoir les données et fournir les fonctionnalités de
surveillance et d’analyse.

Par exemple, pour obtenir les données de votre


infrastructure AD FS, l’agent doit être installé sur les serveurs
AD FS et proxy d’application web. De même, pour obtenir
des données sur votre infrastructure locale AD DS, l’agent
doit être installé sur les contrôleurs de domaine.

Connectivité sortante vers les points de terminaison de Pendant l’installation et l’exécution, l’agent nécessite une
service Azure connectivité vers les points de terminaison de service Azure
AD Connect Health. Si la connectivité sortante est bloquée à
l’aide de pare-feu, assurez-vous d’ajouter les points de
terminaison suivants à la liste autorisée. Consultez les points
de terminaison de connectivité sortante.
PRÉREQUIS DESCRIPTION

Connectivité sortante basée sur des adresses IP Pour le filtrage basé sur des adresses IP sur les pare-feu,
reportez-vous aux plages d’adresses IP Azure.

L’inspection SSL pour le trafic sortant est filtrée ou désactivée L’étape d’inscription de l’agent ou des étapes de
téléchargement de données peuvent échouer en cas
d’inspection SSL ou d’arrêt pour le trafic sortant sur la
couche réseau. En savoir plus sur comment configurer
l’inspection SSL

Ports du pare-feu sur le serveur qui exécute 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 Health.

Port TCP 443


Port TCP 5671

Notez que le port 5671 n'est plus requis pour la dernière


version de l'agent. Procédez à une mise à niveau vers la
dernière version pour que seul le port 443 soit requis. En
savoir plus sur l’activation des ports de pare-feu

Autoriser les sites web suivants en cas d’activation de la Si la sécurité renforcée d’Internet Explorer est activée, les
sécurité renforcée d’IE sites web suivants doivent être autorisés sur le serveur où
l’agent sera installé.

https://login.microsoftonline.com
https://secure.aadcdn.microsoftonline-p.com
https://login.windows.net
https://aadcdn.msftauth.net
Le serveur de fédération pour votre organisation
approuvé par Azure Active Directory. Par exemple :
https://sts.contoso.com
En savoir plus sur comment configurer IE

Vérifier que le logiciel PowerShell 4.0 ou plus est installé Le logiciel Windows Server 2008 R2 est livré avec
PowerShell 2.0, qui est insuffisant pour l’agent. Mettez à jour
PowerShell, comme expliqué ci-dessous sous Installation de
l’agent sur les serveurs Windows Server 2008 R2.
Le logiciel Windows Server 2012 est livré avec
PowerShell 3.0, qui est insuffisant pour l’agent. Mettez à jour
Windows Management Framework.
Le logiciel Windows Server 2012 R2 et les versions
ultérieures sont proposés avec une version suffisamment
récente de PowerShell.

Désactiver FIPS FIPS n’est pas pris en charge par les agents Azure AD
Connect Health.

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 la connectivité sortante est bloquée à l'aide de pare-feu, assurez-vous que les URL
suivantes ne sont pas bloquées par défaut. Ne désactivez pas la surveillance ou l'inspection de la sécurité de ces
URL, mais autorisez-les comme vous le feriez pour tout autre trafic Internet. Celles-ci permettent la
communication avec les points de terminaison de service Azure AD Connect Health. Découvrez comment
vérifier la connectivité sortante avec Test-AzureADConnectHealthConnectivity.
ENVIRONNEMENT DE DOMAINE POINTS DE TERMINAISON DE SERVICE AZURE NÉCESSAIRES

Grand public *.blob.core.windows.net


*.aadconnecthealth.azure.com
*.servicebus.windows.net - Port: 5671
*.adhybridhealth.azure.com/
https://management.azure.com
https://policykeyservice.dc.ad.msft.net/
https://login.windows.net
https://login.microsoftonline.com
https://secure.aadcdn.microsoftonline-p.com
https://www.office.com *Ce point de terminaison est utilisé
uniquement à des fins de détection pendant l’inscription.

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é
uniquement à des fins de détection pendant l’inscription.

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://secure.aadcdn.microsoftonline-p.com
https://www.office.com *Ce point de terminaison est utilisé
uniquement à des fins de détection pendant l’inscription.

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.
Consultez les instructions d’installation.

Installation de l'agent Azure AD Connect Health pour AD FS


NOTE
Le serveur AD FS doit être différent de votre serveur de synchronisation. N’installez pas d’agent AD FS sur votre serveur
de synchronisation.
Avant l’installation, assurez-vous que votre nom d’hôte de serveur AD FS est unique et non présent 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é.
Sur le premier écran, cliquez sur Installer.

Une fois l’installation terminée, cliquez sur Configurer maintenant.

Une fenêtre PowerShell s’ouvre pour démarrer le processus d’inscription de l’agent. Lorsque vous y êtes invité,
connectez-vous avec un compte Azure AD disposant d’un accès pour effectuer l’inscription de l’agent. Par défaut,
l’administrateur général dispose de cet accès.
Une fois que vous êtes connecté, PowerShell continue. À l’issue du processus, vous pouvez fermer PowerShell ;
la configuration est terminée.
À ce stade, les services de l’agent doivent être démarrés automatiquement, permettant ainsi à l’agent de
télécharger de manière sécurisée les données requises pour le service cloud.
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 est un exemple de ces erreurs.
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
Installation de l’agent sur les serveurs Windows Server 2008 R2
Procédure pour les serveurs Windows Server 2008 R2 :
1. Assurez-vous que le serveur est exécuté au Service Pack 1 ou une version supérieure.
2. Désactivez la Configuration de sécurité renforcée pour l’installation de l’agent :
3. Installez Windows PowerShell 4.0 sur chacun des serveurs avant d’installer l’agent AD Health. Pour installer
Windows PowerShell 4.0 :
Installez Microsoft .NET Framework 4.5 en cliquant sur le lien suivant pour télécharger le programme
d’installation hors connexion.
Installer PowerShell ISE (à partir des fonctionnalités de Windows)
Installez Windows Management Framework 4.0.
Installez Internet Explorer version 10 ou supérieure sur le serveur. (Cette installation est requise par le
service Health pour l’authentification avec vos informations d’identification d’administrateur Azure.)
4. Pour plus d’informations sur l’installation de Windows PowerShell 4.0 sur Windows Server 2008 R2,
consultez l’article wiki ici.
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.

Pour que la fonctionnalité d’analyse de l’utilisation puisse collecter et analyser les données, l’agent Azure AD
Connect Health doit avoir les informations à disposition dans les journaux d’activité d’audit AD FS. Ces journaux
d’activité 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 2008 R2
1. Cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis cliquez sur
Stratégie de sécurité locale.
2. Accédez au dossier Security Settings\Local Policies\User Rights Assignment, 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 2.0 est répertorié. S’il
n’est pas présent, cliquez sur Ajouter un utilisateur ou un groupe et ajoutez-le à la liste, puis cliquez sur
OK.
4. Pour activer l’audit, ouvrez une invite de commandes avec des privilèges élevés et exécutez la commande
suivante :
auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:enable /success:enable
5. Fermez Stratégie de sécurité locale.
-- Les étapes suivantes sont requises uniquement pour les serveurs AD FS principaux. --
6. Fermez le composant logiciel enfichable Gestion AD FS. Pour ouvrir le composant logiciel enfichable
Gestion AD FS, cliquez sur Démarrer, pointez sur Programmes, pointez sur Outils d’administration, puis
cliquez sur Gestion AD FS 2.0.
7. Dans le volet Actions, cliquez sur Modifier les propriétés du service de fédération.
8. Dans la boîte de dialogue Propriétés du service de fédération, cliquez sur l’onglet Événements.
9. Cochez les cases Audits des succès et Audits des échecs.
10. Cliquez sur OK.
Pour activer l’audit pour AD FS sur Windows Server 2012 R2
1. Ouvrez Stratégie de sécurité locale en ouvrant Gestionnaire de serveur sur l’écran d’accueil, ou
Gestionnaire de serveur dans la barre des tâches sur le bureau, puis cliquez sur Outils/Stratégie de
sécurité locale.
2. Accédez au dossier Security Settings\Local Policies\User Rights Assignment, 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 présent, cliquez sur Ajouter un utilisateur ou un groupe et ajoutez-le à la liste, puis cliquez sur OK.
4. Pour activer l’audit, ouvrez une invite de commandes avec des privilèges élevés et exécutez la commande
suivante :
auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:enable /success:enable .
5. Fermez Stratégie de sécurité locale.
-- Les étapes suivantes sont requises uniquement pour les serveurs AD FS principaux. --
6. Ouvrez le composant logiciel enfichable Gestion AD FS (dans le Gestionnaire de serveur, cliquez sur Outils,
puis sélectionnez Gestion AD FS ).
7. Dans le volet Actions, cliquez sur Modifier les propriétés du service de fédération.
8. Dans la boîte de dialogue Propriétés du service de fédération, cliquez sur l’onglet Événements.
9. Sélectionnez les cases Audits des succès et Audits des échecs, puis cliquez sur OK.
Pour activer l’audit pour AD FS sur Windows Server 2016
1. Ouvrez Stratégie de sécurité locale en ouvrant Gestionnaire de serveur sur l’écran d’accueil, ou
Gestionnaire de serveur dans la barre des tâches sur le bureau, puis cliquez sur Outils/Stratégie de
sécurité locale.
2. Accédez au dossier Security Settings\Local Policies\User Rights Assignment, 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 présent, cliquez sur Ajouter un utilisateur ou un groupe et ajoutez le compte de service AD FS à la
liste, puis cliquez sur OK.
4. Pour activer l’audit, ouvrez une invite de commandes avec des privilèges élevés et exécutez la commande
suivante :
auditpol.exe /set /subcategory:{0CCE9222-69AE-11D9-BED3-505054503030} /failure:enable /success:enable .
5. Fermez Stratégie de sécurité locale.
-- Les étapes suivantes sont requises uniquement pour les serveurs AD FS principaux. --
6. Ouvrez le composant logiciel enfichable Gestion AD FS (dans le Gestionnaire de serveur, cliquez sur Outils,
puis sélectionnez Gestion AD FS ).
7. Dans le volet Actions, cliquez sur Modifier les propriétés du service de fédération.
8. Dans la boîte de dialogue Propriétés du service de fédération, cliquez sur l’onglet Événements.
9. Sélectionnez les cases Audits des succès et Audits des échecs, puis cliquez sur OK. Ceci doit être activé
par défaut.
10. Ouvrez une fenêtre PowerShell et exécutez la commande suivante : Set-AdfsProperties -AuditLevel Verbose .

Notez que le niveau d’audit « de base » est activé par défaut. En savoir plus sur l’amélioration de l’audit AD FS
dans Windows Server 2016
Pour localiser les journaux d’audit AD FS
1. Ouvrez l’ Observateur d’événements.
2. Accédez à Journaux d’activité Windows et sélectionnez Sécurité.
3. Sur la droite, cliquez sur Filtrer les journaux d’activité actuels.
4. Dans Source de l’événement, sélectionnez Audit AD FS.
Et remarque de FAQ rapide pour les journaux d’audit.

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 ne disposez pas de stratégie de groupe qui désactive l’audit AD FS.

Installation de l'agent Azure AD Connect Health pour la


synchronisation
L'agent Azure AD Connect Health pour la synchronisation est installé automatiquement dans la dernière version
d'Azure AD Connect. Pour utiliser Azure AD Connect pour la synchronisation, vous devez télécharger la dernière
version d’Azure AD Connect et l’installer. Vous pouvez télécharger la dernière version ici.
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 Sync Insights Service
Azure AD Connect Health Sync Monitoring Service

NOTE
N'oubliez pas que l'utilisation d'Azure AD Connect Health requiert Azure AD Premium. Si vous ne disposez pas d’Azure AD
Premium, vous ne pouvez pas effectuer la configuration dans le portail Azure. Pour plus d’informations, consultez la page
relative à la configuration requise.

Enregistrement manuel d’Azure AD Connect Health pour la


synchronisation
Si l’enregistrement de l’agent Azure AD Connect Health pour la synchronisation échoue après avoir
correctement installé Azure AD Connect, vous pouvez utiliser la commande PowerShell suivante pour
enregistrer l’agent manuellement.

IMPORTANT
Cette commande PowerShell est uniquement requise si l’enregistrement de l’agent échoue après l’installation d’Azure AD
Connect.

La commande PowerShell suivante est requise UNIQUEMENT lorsque l’enregistrement de l’Agent d’intégrité
échoue, même après une installation et une configuration réussies d’Azure AD Connect. Les services Azure AD
Connect Health démarreront une fois l’agent correctement enregistré.
Vous pouvez enregistrer manuellement l’agent Azure AD Connect Health pour la synchronisation à l’aide de la
commande PowerShell suivante :
Register-AzureADConnectHealthSyncAgent -AttributeFiltering $false -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é. Dans le cas contraire, c’est le paramètre $false qui
s’applique.
StagingMode : $false (par défaut), si le serveur Azure AD Connect n’est PAS en mode de préproduction, $true
s’applique si le serveur est configuré en mode de préproduction.
Lorsque vous êtes invité à vous authentifier, vous devez utiliser le compte Administrateur général (tel que
admin@domain.onmicrosoft.com) que vous avez utilisé pour la configuration d’Azure AD Connect.

Installation de l’agent Azure AD Connect Health pour AD DS


Installation de l’agent Azure AD Connect Health pour AD DS
Pour démarrer l’installation de l’agent, double-cliquez sur le fichier .exe que vous avez téléchargé. Sur le premier
écran, cliquez sur Installer.

Une fois l’installation terminée, cliquez sur Configurer maintenant.

Une invite de commandes est lancée, suivie par certains éléments PowerShell qui exécutent Register-
AzureADConnectHealthADDSAgent. Lorsque vous y êtes invité, connectez-vous à Azure.
Une fois que vous êtes connecté, PowerShell continue. À l’issue du processus, 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 est un exemple de ces erreurs.

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 tant que la configuration n’est pas terminée.

Installation de l’agent rapide sur plusieurs serveurs


1. Créez un compte d’utilisateur dans Azure AD avec un mot de passe.
2. Affectez le rôle Propriétaire à ce compte AAD local dans Azure AD Connect Health, via le portail. Suivez
cette procédure. 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 pour effectuer l’inscription. Remplacez les paramètres par le 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 -UserPrincipalName $USERNAME -Credential $myCreds

1. Cela fait, vous pouvez supprimer l’accès pour le compte local, en effectuant une ou plusieurs des opérations
suivantes :
supprimez l’attribution de rôle au compte local pour AAD Connect Health ;
retournez le mot de passe du compte local ;
désactiver le compte local AAD ;
supprimez le compte local AAD.

Inscription de l’agent à l’aide de PowerShell


Après avoir installé le fichier setup.exe de l’agent approprié, vous pouvez effectuer l’étape d’inscription de 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

Ces commandes acceptent les « informations d’identification » en tant que paramètre pour terminer l’inscription
de manière non interactive ou sur un ordinateur Serveur-Core.
Les informations d’identification peuvent être insérées dans une variable PowerShell qui est transmise en
tant que paramètre.
Vous pouvez fournir une identité Azure AD disposant d’un accès pour inscrire les agents et dans laquelle la
MFA n’est PAS activée.
Par défaut, les administrateurs généraux disposent d’un accès pour effectuer l’inscription de l’agent. Vous
pouvez également autoriser des identités moins privilégiées à effectuer cette étape. En savoir plus sur le
Contrôle d’accès en fonction du rôle.

$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
L’utilisation de « Netsh WinHttp set ProxyServerAddress » n’est pas prise en charge, car l’agent utilise System.Net pour
effectuer des requêtes web au lieu des services HTTP Microsoft Windows.
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.

Modification de la configuration du proxy d’un agent Health


Vous disposez des options suivantes afin de configurer un agent Azure AD Connect Health pour utiliser un
proxy HTTP.

NOTE
Tous les services de l’agent Azure AD Connect Health doivent être redémarrés pour que la mise à jour des paramètres du
proxy prenne effet. Exécutez la commande suivante :
Restart-Service AzureADConnectHealth*

Importation des paramètres de proxy existants


I m p o r t a t i o n à p a r t i r d ' I n t e r n e t Ex p l o r e r

Les paramètres de proxy HTTP Internet Explorer peuvent être importés pour être utilisés par les agents Azure
AD Connect Health. Sur chacun des serveurs exécutant l’agent Health, exécutez la commande PowerShell
suivante :

Set-AzureAdConnectHealthProxySettings -ImportFromInternetSettings

Im p o r t at i o n à p ar t i r d e W i n HT T P

Les paramètres de proxy WinHTTP peuvent être importés pour être utilisés par les agents Azure AD Connect
Health. Sur chacun des serveurs exécutant l’agent Health, exécutez la commande PowerShell suivante :

Set-AzureAdConnectHealthProxySettings -ImportFromWinHttp

Spécification manuelle des adresses du proxy


Vous pouvez spécifier manuellement un serveur proxy sur chacun des serveurs qui exécute l’agent Health en
exécutant la commande PowerShell suivante :

Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress address:port

Exemple : Set-AzureAdConnectHealthProxySettings -HttpsProxyAddress myproxyserver: 443


« address » peut être un nom de serveur DNS pouvant être résolu ou une adresse IPv4
"port" peut être omis. Dans ce cas, 443 est choisi comme port par défaut.
Effacement de 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 actuellement configurés en exécutant la commande suivante :

Get-AzureAdConnectHealthProxySettings

Tester la connectivité au service Azure AD Connect Health


Des problèmes provoquant la perte de connectivité entre l’agent Azure AD Connect Health et le service Azure
AD Connect Health peuvent survenir. Cela inclut, entre autres, des problèmes réseau et des problèmes
d’autorisation.
Si l’agent ne parvient pas à envoyer des données au service Azure AD Connect Health pendant plus de deux
heures, le message d’alerte suivant s’affiche dans le portail : « Les données du service de contrôle d’intégrité ne
sont pas à jour. » Vous pouvez vérifier si l’agent Azure AD Connect Health affecté peut télé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 effectuer l’inscription de l’agent. Si vous n’êtes pas en mesure de
terminer l’inscription de l’agent, assurez-vous que vous avez respecté la configuration requise pour Azure AD Connect
Health. Ce test de connectivité est effectué par défaut lors de l’inscription de l’agent.
Liens connexes
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 (en Anglais)
Utilisation d’Azure AD Connect Health avec AD DS
Forum Aux Questions (FAQ ) Azure AD Connect Health
Historique de publication des versions d’Azure AD Connect Health
Azure AD Connect : Mise à jour automatique
17/09/2019 • 9 minutes to read • Edit Online

Cette fonctionnalité date de la build 1.1.105.0 (publiée en février 2016). Cette fonctionnalité a été mise à jour
dans la build 1.1.561 et prend désormais en charge des scénarios supplémentaires.

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 :

ÉTAT COMMENTAIRE

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 Service Manager est en cours d’exécution sur le serveur, la mise
à niveau est suspendue jusqu’à la fermeture de l’interface utilisateur.

Résolution de problèmes
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.
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 source mise à niveau d’Azure AD Connect 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.

PRÉFIXE DU CODE DE RÉSULTAT DESCRIPTION

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.
MESSAGE DE RÉSULTAT DESCRIPTION

UpgradeAborted

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.

UpgradeNotSupported

UpgradeNotSupportedAdfsSignInMethod Vous avez sélectionné AD FS en tant que méthode de


connexion.

UpgradeNotSupportedCustomizedSyncRules Vous avez ajouté vos propres règles de personnalisation à la


configuration.

UpgradeNotSupportedDeviceWritebackEnabled Vous avez activé la fonctionnalité Écriture différée des


appareils .

UpgradeNotSupportedGroupWritebackEnabled Vous avez activé la fonctionnalité Écriture différée de groupe


.

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


à niveau DirSync.

UpgradeNotSupportedMetaverseSizeExceeeded Vous avez plus de 100 000 objets dans le métaverse.

UpgradeNotSupportedMultiForestSetup Vous vous connectez à plusieurs forêts. L’installation rapide


se connecte à une seule forêt.
MESSAGE DE RÉSULTAT DESCRIPTION

UpgradeNotSupportedNonLocalDbInstall Vous n’utilisez pas une base de données LocalDB SQL


Server Express.

UpgradeNotSupportedNonMsolAccount Le compte de connecteur AD DS n’est plus le compte


MSOL_ par défaut.

UpgradeNotSupportedNotConfiguredSignInMethod Lorsque vous configurez AAD Connect, vous avez choisi Ne


pas configurer lors de la sélection de la méthode
d’authentification unique.

UpgradeNotSupportedPtaSignInMethod Vous avez sélectionné Authentification directe comme mode


d’authentification.

UpgradeNotSupportedStagingModeEnabled Le serveur est défini pour être en mode intermédiaire.

UpgradeNotSupportedUserWritebackEnabled Vous avez activé la fonctionnalité Écriture différée de


l’utilisateur .

Étapes suivantes
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Synchronisation d’Azure AD Connect : Exécuter
l’Assistant Installation une deuxième fois
02/10/2019 • 5 minutes to read • Edit Online

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.
Rubriques de présentation
Synchronisation Azure AD Connect : Comprendre et personnaliser la synchronisation
Intégration des identités locales dans Azure Active Directory
Azure AD Connect : Effectuer une mise à niveau
depuis une version précédente vers la dernière
17/09/2019 • 22 minutes to read • Edit Online

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. Nous vous recommandons d’utiliser
systématiquement les dernières versions d’Azure AD Connect. Vous pouvez également suivre les étapes décrites
dans la section Migration « swing » lorsque vous appliquez une modification importante à la configuration.

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ÉTHODE DESCRIPTION

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 modifier la
configuration par défaut.
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 vous avez un déploiement complexe ou un nombre d’objets élevé, il peut être difficile d’effectuer une mise à
niveau sur place sur le système réel. 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 l’écriture différée 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 Exporter. 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 Exporter. 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 Importation 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

Résolution de problèmes
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
17/09/2019 • 21 minutes to read • Edit Online

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.
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ÉNARIO

Mise à niveau sur place

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.

Mise à niveau sur place


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.
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

Mise à niveau sur place


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.

8. Une fois l’installation terminée, déconnectez-vous puis reconnectez-vous à Windows avant d’utiliser le
gestionnaire Synchronization Service Manager, l’éditeur de règles de synchronisation ou de tenter
d’apporter d’autres modifications à la configuration.

Déploiement en parallèle
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'exportation . 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'exportation . 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 de SQL Server (par défaut, Azure AD Connect installe SQL Server 2012 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 :

7. Cliquez sur Suivant.


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.
10. Une fois l’installation terminée, déconnectez-vous puis reconnectez-vous à Windows avant d’utiliser le
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
Service 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
Directory
Désinstallez Outil de synchronisation Windows Azure Active Directory
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
Azure AD Connect étant installé, vous pouvez passer à Vérification de l’installation et affectation des licences.
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.
Pour en savoir plus sur ces sujets courants, consultez l’article Planificateur Azure AD Connect Sync.
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Installer Azure AD Connect à l’aide d’une base de
données ADSync existante
17/09/2019 • 18 minutes to read • Edit Online

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 Server 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.


1. 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.


1. Une fois les informations d’identification fournies, la croix rouge est remplacée par une coche verte. Cliquez
sur Suivant.

1. Dans l’écran Prêt à configurer, cliquez sur Installer.


1. 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.

FONCTIONNALITÉ ÉTAPES

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é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 de transmission directe ainsi que
l’authentification unique transparente sont désactivées. 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
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 : Prévenir les
suppressions accidentelles et Azure AD Connect Health.
Pour en savoir plus sur ces sujets courants, consultez l’article Planificateur Azure AD Connect Sync.
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Installer Azure AD Connect à l’aide d’autorisations
administrateur déléguées SQL
17/09/2019 • 5 minutes to read • Edit Online

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é.

RÔLE DESCRIPTION

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 fortement 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 ) . La base de données doit être nommée ADSync. 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
Authentification directe Azure Active Directory :
Préversion de la mise à niveau des agents
d'authentification
17/09/2019 • 8 minutes to read • Edit Online

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 Directory dans le volet de navigation gauche.
3. Sélectionnez ensuite Azure AD Connect.
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éservé 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 Directory -> 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 vous
y êtes invité.
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 Directory -> 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 vous
y êtes invité.
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
Résolution des problèmes : découvrez comment résoudre les problèmes courants susceptibles de survenir
avec cette fonctionnalité.
Déplacer la base de données Azure AD Connect de
SQL Server Express vers SQL Server
17/09/2019 • 7 minutes to read • Edit Online

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 à Services et arrêtez le service Microsoft Azure AD.
2. Localisez le dossier %Program Files%\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 Server 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
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Installer Azure AD Connect à l’aide d’une base de données ADSync existante
Installer Azure AD Connect à l’aide d’autorisations administrateur déléguées SQL
Azure AD Connect : Quand vous avez un locataire
existant
17/09/2019 • 10 minutes to read • Edit Online

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. L’exception est lorsqu’un attribut a une
valeur NULL locale. Dans ce cas, la valeur dans Azure AD est conservée, mais vous pouvez toujours la modifier
uniquement en local.
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 Office 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/Office 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
Azure Active Directory.

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.
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. Déclenchez une synchronisation
3. 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
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Étapes suivantes et gestion d’Azure AD Connect
17/09/2019 • 6 minutes to read • Edit Online

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 dans le cloud, vous devez leur attribuer une licence afin
qu’ils puissent commencer à utiliser les applications cloud telles qu’Office 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 Directoryà gauche.
3. Sur la page Active Directory, 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 Directory 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 Directoryà 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.
2. Cliquez sur Configurer.
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.
7. Cliquez sur Configurer.
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ÂCHE SUPPLÉMENTAIRE DESCRIPTION

Paramètres de confidentialité Afficher les données de télémétrie qui sont partagées avec
Microsoft.
TÂCHE SUPPLÉMENTAIRE DESCRIPTION

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
En savoir plus sur l’intégration de vos identités locales avec Azure Active Directory.
Azure AD Connect : Principes de conception
17/09/2019 • 25 minutes to read • Edit Online

L’objectif de ce document est de décrire les principes qui doivent présider à la conception de l’implémentation
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.
employeeIDest 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 :
PARAMÈTRE DESCRIPTION

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) choisissez 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
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Topologies pour Azure AD Connect
17/09/2019 • 20 minutes to read • Edit Online

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 :

DESCRIPTION SYMBOLE

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
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 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 serveurs 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 Office 365 et la topologie


Certaines charges de travail Office 365 ont certaines restrictions quant aux topologies prises en charge :

CHARGE DE TRAVAIL RESTRICTIONS

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é Office 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 :
Seul un des locataires Azure AD peut activer Exchange hybride avec l’instance Active Directory locale.
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.

Étapes suivantes
Pour savoir comment installer Azure AD Connect pour ces scénarios, consultez Installation personnalisée
d’Azure AD Connect.
En savoir plus sur la configuration de la synchronisation Azure AD Connect .
En savoir plus sur l’intégration de vos identités locales avec Azure Active Directory.
Facteurs affectant les performances d’Azure AD
Connect
17/09/2019 • 25 minutes to read • Edit Online

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 :

FACTEUR DE CONCEPTION DÉFINITION

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.

charger 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
3. Exportation 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
3. Exportation 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.

Synchronisation
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
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Options de connexion de l’utilisateur via Azure AD
Connect
17/09/2019 • 25 minutes to read • Edit Online

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 ))
Fédération avec PingFederate

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 juste activer l’authentification utilisateur pour Office 365, les
applications SaaS et d’autres ressources basées sur Azure AD, l’option de synchronisation de hachage de mot de
passe par défaut est recommandée.
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.
Synchronisation de hachage de mot de passe
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.
Authentification directe
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 :


Authentification directe
Authentification unique
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 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.
Fédération avec PingFederate
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 :

ÉTAT DESCRIPTION ACTION REQUISE

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.
ÉTAT DESCRIPTION ACTION REQUISE

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 Office 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 toutes les charges de travail Office 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

ÉTAT EFFET SUR L’EXPÉRIENCE DE CONNEXION UTILISATEUR AZURE

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.
ÉTAT EFFET SUR L’EXPÉRIENCE DE CONNEXION UTILISATEUR AZURE

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 convertir 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 l’intégration de vos identités locales avec Azure Active Directory.
En savoir plus sur Azure AD Connect : principes de conception.
Remplissage de UserPrincipalName dans Azure AD
17/09/2019 • 11 minutes to read • Edit Online

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 :

TERME DESCRIPTION

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
Objet utilisateur local :
mailNickName : us4
proxyAddresses : {SMTP:us1@contoso.com}
mail : us2@contoso.com
UserPrincipalName : us3@contoso.com
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é.
Objet utilisateur du locataire Azure AD :
MailNickName : us4
UserPrincipalName : us1@contoso.onmicrosoft.com
Scénario 3 : Suffixe UPN non vérifié – mise à jour de l'attribut UserPrincipalName local

Objet utilisateur local :


mailNickName : us4
proxyAddresses : {SMTP:us1@contoso.com}
mail : us2@contoso.com
UserPrincipalName : us5@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’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.
Objet utilisateur du locataire Azure AD :
MailNickName : us4
UserPrincipalName : us4@contoso.onmicrosoft.com
Scénario 4 : Suffixe UPN non vérifié – mise à jour de l'adresse SMTP principale et de l'attribut mail local

Objet utilisateur local :


mailNickName : us4
proxyAddresses : {SMTP:us6@contoso.com}
mail : us7@contoso.com
UserPrincipalName : us5@contoso.com
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.
Objet utilisateur du locataire Azure AD :
MailNickName : us4
UserPrincipalName : us4@contoso.onmicrosoft.com
Scénario 5 : Suffixe UPN vérifié – mise à jour du suffixe d'attribut UserPrincipalName local
Objet utilisateur local :
mailNickName : us4
proxyAddresses : {SMTP:us6@contoso.com}
mail : us7@contoso.com
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.
Objet utilisateur du 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
17/09/2019 • 3 minutes to read • Edit Online

Azure AD Connect est couramment utilisé avec l’instance mondiale d’Azure AD et Office 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 À OUVRIR DANS LE SERVEUR PROXY

*.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 À OUVRIR DANS LE SERVEUR PROXY

*.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
En savoir plus sur l’ intégration de vos identités locales avec Azure Active Directory.
Migrer de la fédération à la synchronisation de
hachage de mot de passe pour Azure Active
Directory
17/09/2019 • 50 minutes to read • Edit Online

Cet article décrit comment faire passer les domaines de votre organisation d’AD FS (Active Directory Federation
Services) à la synchronisation de hachage de mot de passe.
Vous pouvez télécharger cet article.

Prérequis pour la migration vers la synchronisation de hachage de mot


de passe
Les prérequis suivants sont nécessaires pour migrer de l’utilisation d’AD FS vers l’utilisation de la synchronisation
de hachage de mot de passe.
Mettre à jour Azure AD Connect
Pour réaliser correctement les étapes de migration vers la synchronisation de hachage du mot de passe, vous devez
disposer au minimum d’Azure AD Connect version 1.1.819.0. Cette version contient des modifications
significatives au niveau de la conversion de la connexion et réduit le temps global du passage de l’authentification
fédérée à l’authentification cloud de quelques heures à quelques minutes.

IMPORTANT
Vous pouvez lire dans des documentations, des outils et des blogs obsolètes que la conversion de l’utilisateur est nécessaire
quand vous convertissez des domaines de l’identité fédérée à l’identité managée. La conversion des utilisateurs n’est plus
nécessaire. Microsoft s’emploie à mettre à jour la documentation et les outils afin de refléter ce changement.

Pour mettre à jour Azure AD Connect, suivez les étapes de Azure AD Connect : Mettre à niveau vers la version la
plus récente.
Autorisations requises pour la synchronisation du hachage de mot de passe
Vous pouvez configurer Azure AD Connect en utilisant des paramètres express ou une installation personnalisée.
Si vous avez utilisé l’option d’installation personnalisée, les autorisations nécessaires pour la synchronisation de
hachage de mot de passe risquent de ne pas être en place.
Le compte de service AD DS d’Azure AD Connect a besoin des autorisations suivantes pour pouvoir synchroniser
les hachages de mot de passe :
Répliquer les changements d’annuaires
Répliquer les changements d’annuaire Tout
C’est le bon moment pour vérifier que ces autorisations sont en place pour tous les domaines de la forêt.
Planifier la méthode de migration
Vous pouvez choisir entre deux méthodes pour migrer de la gestion fédérée des identités vers la synchronisation
de hachage de mot de passe et l’authentification unique fluide. La méthode utilisée dépend de la configuration
initiale de votre instance AD FS.
Azure AD Connect. Si vous avez configuré à l’origine AD FS avec Azure AD Connect, vous devez passer à
la synchronisation de hachage de mot de passe en utilisant l’Assistant Azure AD Connect.
Azure AD Connect exécute automatiquement l’applet de commande Set-MsolDomainAuthentication
quand vous changez la méthode de connexion des utilisateurs. Azure AD Connect annule automatiquement
la fédération de tous les domaines fédérés vérifiés dans votre locataire Azure AD.

NOTE
Actuellement, si vous avez utilisé à l’origine Azure AD Connect pour configurer AD FS, vous ne pouvez pas éviter
l’annulation de la fédération de tous les domaines de votre locataire quand vous passez à la synchronisation de
hachage de mot de passe pour la connexion des utilisateurs.

Azure AD Connect avec PowerShell. Vous pouvez utiliser cette méthode seulement si vous n’avez pas
configuré à l’origine AD FS avec Azure AD Connect. Pour cette option, vous devez toujours changer la
méthode d’authentification des utilisateurs via l’Assistant Azure AD Connect. La principale différence avec
cette option est que l’Assistant n’exécute pas automatiquement l’applet de commande Set-
MsolDomainAuthentication. Avec cette option, vous avez un contrôle total sur les domaines qui sont
convertis et dans quel ordre.
Pour savoir quelle méthode utiliser, effectuez les étapes des sections suivantes.
Vérifier les paramètres de connexion utilisateur définis actuellement
Pour vérifier les paramètres actuels de connexion des utilisateurs :
1. Connectez-vous au portail Azure en utilisant un compte d’administrateur général.
2. Dans la section Connexion utilisateur, vérifiez les paramètres suivants :
Fédération est défini sur Activé.
Authentification unique fluide est défini sur Désactivé.
Authentification directe est défini sur Désactivé.

Vérifier la configuration d’Azure AD Connect


1. Sur votre serveur Azure AD Connect, ouvrez Azure AD Connect. Sélectionnez Configurer.
2. Dans la page Tâches supplémentaires, sélectionnez Afficher la configuration actuelle, puis
sélectionnez Suivant.
3. Dans la page Vérification de votre solution, notez l’état de Synchronisation de hachage de mot de
passe.
Si Synchronisation de hachage de mot de passe est défini sur Désactivé, effectuez les étapes de cet
article pour l’activer.
Si Synchronisation de hachage de mot de passe est défini sur Activé, vous pouvez ignorer la section
Étape 1 : Activer la synchronisation de hachage de mot de passe de cet article.
4. Dans la page Vérification de votre solutionn faites défiler jusqu’à Services Active Directory
Federation Services (ADFS ) .
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. Vous pouvez convertir vos domaines de l’identité
fédérée en identité managée en utilisant l’option Modifier la connexion utilisateur d’Azure AD
Connect. Le processus est détaillé dans la section Option A : Passer de la fédération à la
synchronisation de hachage de mot de passe avec Azure AD Connect.
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. Pour plus d’informations sur ce processus,
consultez la section Option B : Passer de la fédération à la synchronisation de hachage de mot de
passe avec Azure AD Connect et PowerShell.
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 :

Get-MsolDomainFederationSettings -DomainName YourDomain.extention | fl *

Exemple :

Get-MsolDomainFederationSettings -DomainName Contoso.com | fl *


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, SupportsMfa et PromptLoginBehavior.
Pour plus d’informations, voir les articles suivants :
AD FS prompt=login parameter support
Set-MsolDomainAuthentication

NOTE
Si SupportsMfa est défini sur True, cela signifie que vous utilisez une solution d’authentification multifacteur locale pour
injecter un deuxième facteur dans le flux d’authentification des utilisateurs. Ce programme d’installation ne fonctionne plus
pour les scénarios d’authentification Azure AD après conversion de ce domaine de l’authentification fédérée à l’authentification
gérée. Après la désactivation de la fédération, vous interrompez la relation avec votre fédération en local, y compris les
adaptateurs MFA locaux.
Au lieu de cela, utilisez le service cloud Azure Multi-Factor Authentication pour la même fonction. Évaluez soigneusement vos
besoins d’authentification multifacteur avant de continuer. Avant de convertir vos domaines, veillez à bien comprendre
comment utiliser Azure Multi-Factor Authentication, les implications en matière de gestion des licences et le processus
d’inscription des utilisateurs.

Sauvegarder les paramètres de fédération


Même si aucune modification n’est apportée aux autres parties de confiance de votre batterie AD FS pendant le
processus, nous vous recommandons de disposer d’une sauvegarde de votre batterie de serveurs AD FS valide et
actuelle, à partir de laquelle vous pouvez faire une restauration. Vous pouvez créer une sauvegarde valide actuelle
avec l’outil de restauration rapide d’AD FS gratuit de Microsoft. Vous pouvez utiliser l’outil pour sauvegarder AD
FS, et pour restaurer une batterie de serveurs existante ou pour en créer une.
Si vous choisissez de ne pas utiliser l’outil de restauration rapide d’AD FS, exportez au moins les approbations de
partie de confiance de la plateforme d’identité Microsoft Office 365 et toutes les règles de revendication
personnalisées associées que vous avez ajoutées. Vous pouvez exporter l’approbation de partie de confiance et les
règles de revendication associées en utilisant l’exemple PowerShell suivant :

(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-


RelyingPartyTrust.xml"

Considérations relatives au déploiement et utilisation d’AD FS


Cette section décrit les considérations relatives au déploiement et des détails sur l’utilisation d’AD FS.
Utilisation actuelle d’AD FS
Avant de passer de l’identité fédérée à l’identité managée, examinez attentivement votre utilisation actuelle d’AD
FS pour Azure AD, Office 365 et autres applications (approbations de partie de confiance). En particulier,
considérez les scénarios décrits dans le tableau suivant :

SI ALORS
SI ALORS

Vous prévoyez d’utiliser AD FS avec d’autres applications Après avoir converti vos domaines, vous utiliserez AD FS et
(autres qu’Azure AD et Office 365). Azure AD. Considérez l’expérience utilisateur. Dans certains
scénarios, les utilisateurs doivent peut-être s’authentifier deux
fois : une fois auprès d’Azure AD (où un utilisateur bénéficie
d’un accès avec authentification unique à d’autres applications,
comme Office 365), et une deuxième fois dans les applications
encore liées à AD FS comme approbation de partie de
confiance.

Votre instance d’AD FS est très personnalisée et s’appuie sur Avant de continuer, vous devez vérifier qu’Azure AD peut
des paramètres de personnalisation spécifiques du fichier répondre à vos spécifications de personnalisation actuelles.
onload.js (par exemple si vous avez modifié l’expérience de Pour plus d’informations et des conseils, consultez les sections
connexion afin que les utilisateurs utilisent seulement un relatives à la personnalisation d’AD FS.
format SamAccountName pour leur nom d’utilisateur au lieu
d’un nom d’utilisateur principal (UPN), ou si votre organisation
a fortement personnalisé l’expérience de connexion). Le fichier
onload.js ne peut pas être dupliqué dans Azure AD.

Vous utilisez AD FS pour bloquer des versions antérieures des Vous pouvez remplacer les contrôles d’AD FS qui bloquent les
clients d’authentification. versions antérieures des clients d’authentification en utilisant
une combinaison de contrôles d’accès conditionnel et de règles
d’accès de client Exchange Online.

Vous obligez les utilisateurs à effectuer une authentification Dans un domaine d’identité managée, vous ne pouvez pas
multifacteur via une solution de serveur d’authentification injecter une demande d’authentification multifacteur via la
multifacteur locale quand les utilisateurs s’authentifient auprès solution d’authentification multifacteur locale dans le flux
d’AD FS. d’authentification. Vous pouvez cependant utiliser le service
Azure Multi-Factor Authentication pour l’authentification
multifacteur une fois que le domaine est converti.

Si vos utilisateurs n’utilisent pas actuellement Azure Multi-


Factor Authentication, une étape ponctuelle d’inscription des
utilisateurs est nécessaire. Vous devez préparer et
communiquer l’inscription planifiée à vos utilisateurs.

Vous utilisez actuellement des stratégies de contrôle d’accès Vous pouvez envisager de remplacer les stratégies par des
(règles AuthZ) dans AD FS pour contrôler l’accès à Office 365. stratégies d’accès conditionnel et des règles d’accès du client
Exchange Online d’Azure AD équivalentes.

Personnalisations courantes d’AD FS


Cette section décrit les personnalisations courantes d’AD FS.
Revendication InsideCorporateNetwork
AD FS émet la revendication InsideCorporateNetwork si l’utilisateur qui s’authentifie se trouve dans le réseau
d’entreprise. Cette revendication est ensuite passée à Azure AD. La revendication est utilisée pour contourner
l’authentification multifacteur en fonction de l’emplacement réseau de l’utilisateur. Pour savoir comment déterminer
si cette fonctionnalité est actuellement activée dans AD FS, consultez Adresses IP de confiance pour les utilisateurs
fédérés.
La revendication InsideCorporateNetwork n’est plus disponible une fois que vos domaines sont convertis à la
synchronisation de hachage de mot de passe. Vous pouvez utiliser des emplacements nommés dans Azure AD
pour remplacer cette fonctionnalité.
Une fois que vous avez configuré des emplacements nommés, vous devez mettre à jour toutes les stratégies
d’accès conditionnel configurées de façon à inclure ou à exclure les valeurs Tous les emplacements approuvés
ou Adresses IP approuvées MFA pour refléter les emplacements nommés nouvellement créés.
Pour plus d’informations sur la condition Emplacement dans l’accès conditionnel, consultez Emplacements
d’accès conditionnel Azure Active Directory.
Appareils joints à Azure AD Hybride
Quand vous joignez un appareil à Azure AD, vous pouvez créer des règles d’accès conditionnel qui imposent que
les appareils répondent à vos standards d’accès pour la sécurité et la conformité. De même, les utilisateurs peuvent
se connecter à un appareil en utilisant un compte professionnel ou scolaire d’une organisation au lieu d’un compte
personnel. Quand vous utilisez des appareils joints à Azure AD Hybride, vous pouvez joindre à Azure AD vos
appareils joints à un domaine Active Directory. Votre environnement fédéré peut avoir été configuré pour utiliser
cette fonctionnalité.
Pour garantir le bon fonctionnement de la jonction hybride pour les appareils joints au domaine une fois vos
domaines convertis à la synchronisation de hachage de mot de passe, pour les clients Windows 10, vous devez
utiliser Azure AD Connect pour synchroniser les comptes d’ordinateur Active Directory avec Azure AD.
Pour les comptes d’ordinateur Windows 8 et Windows 7, la jointure hybride utilise l’authentification unique fluide
pour inscrire l’ordinateur dans Azure AD. Vous n’avez pas à synchroniser les comptes d’ordinateur Windows 8 et
Windows 7 comme vous le faites pour les appareils Windows 10. Cependant, vous devez déployer un fichier
workplacejoin.exe mis à jour (via un package .msi) sur les clients Windows 8 et Windows 7 afin qu’ils puissent
s’inscrire avec l’authentification unique fluide. Téléchargez le package .msi.
Pour plus d’informations, consultez Configurer les appareils joints à Azure AD Hybride.
Personnalisation
Si votre organisation a personnalisé vos pages de connexion AD FS pour afficher des informations plus
pertinentes pour l’organisation, envisagez de faire des personnalisations similaires pour la page de connexion
Azure AD.
S’il est possible d’apporter des personnalisations similaires, il faut s’attendre à certaines modifications visuelles
après la conversion. Vous pouvez fournir des informations sur les modifications attendues dans vos
communications aux utilisateurs.

NOTE
La personnalisation d’organisation est disponible seulement si vous avez acheté une licence Premium ou De base pour Azure
Active Directory, ou si vous disposez d’une licence Office 365.

Planification du déploiement et du support


Effectuez les tâches décrites dans cette section pour planifier le déploiement et le support.
Planifier la fenêtre de maintenance
Même si le processus de conversion de domaine est relativement rapide, Azure AD peut continuer à envoyer des
demandes d’authentification à vos serveurs AD FS pendant jusqu’à 4 heures après la fin de la conversion. Pendant
cet intervalle de quatre heures, et en fonction des différents caches du côté service, Azure AD peut ne pas accepter
ces authentifications. Les utilisateurs peuvent alors recevoir une erreur. L’utilisateur peut néanmoins toujours
s’authentifier auprès d’AD FS, mais Azure AD n’accepte plus le jeton émis de l’utilisateur, car cette approbation de
la fédération est maintenant supprimée.
Seuls les utilisateurs qui accèdent aux services via un navigateur web pendant cette période postérieure à la
conversion avant que le cache côté service soit effacé sont affectés. Les clients hérités (Exchange ActiveSync,
Outlook 2010/2013) ne sont normalement 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 cette mise en
cache effacée. 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.

IMPORTANT
N’arrêtez pas votre environnement AD FS et ne supprimez l’approbation de partie de confiance d’Office 365 avant d’avoir
vérifié que tous les utilisateurs réussissent à s’authentifier avec l’authentification cloud.

Plan de restauration
Si vous rencontrez un problème majeur que vous ne pouvez pas résoudre rapidement, vous pouvez décider de
revenir à la solution de fédération. Il est important de planifier ce qu’il faut si votre déploiement ne se passe pas
comme prévu. Si la conversion du domaine ou des utilisateurs échoue pendant le déploiement, ou si vous devez
revenir à la fédération, vous devez comprendre comment limiter les dégâts d’une panne et réduire l’effet sur vos
utilisateurs.
Pour annuler
Pour planifier l’annulation, consultez la documentation de conception et de déploiement de la fédération pour
connaître les détails spécifiques à votre déploiement. Le processus doit inclure ces tâches :
Conversion des domaines managés en domaines fédérés avec l’applet de commande Convert-
MSOLDomainToFederated.
Si nécessaire, configuration de règles de revendication supplémentaires.
Planifier les communications
Une partie importante de la planification du déploiement et du support est de veiller à ce que vos utilisateurs
finaux soient informés de façon proactive des modifications à venir. Les utilisateurs doivent savoir à l’avance ce
qu’ils peuvent subir et ce qui est attendu d’eux.
Une fois que la synchronisation de hachage de mot de passe et l’authentification unique fluide sont déployées,
l’expérience de connexion des utilisateurs pour l’accès à Office 365 et aux autres ressources authentifiées via Azure
AD change. Les utilisateurs qui sont en dehors du réseau voient seulement la page de connexion Azure AD. Ces
utilisateurs ne sont pas redirigés vers la page basée sur des formulaires qui est présentée par les serveurs proxy
d’applications web externes.
Incluez les éléments suivants dans votre stratégie de communication :
Avertissez les utilisateurs des fonctionnalités à venir et publiées en utilisant :
L’e-mail et d’autres canaux de communication internes.
Des visuels, comme des affiches.
Des communications de la part de la direction, directes ou autres.
Déterminez qui va personnaliser les communications, et qui va les envoyer et quand.

Implémenter votre solution


Vous avez planifié votre solution. Vous pouvez maintenant l’implémenter. L’implémentation implique les
composants suivants :
Activation de la synchronisation de hachage de mot de passe.
Préparation pour l’authentification unique fluide.
Changement de la méthode de connexion pour la synchronisation de hachage de mot de passe et activation de
l’authentification unique fluide.
Étape 1 : Activer la synchronisation de hachage de mot de passe
La première étape de l’implémentation de cette solution consiste à activer la synchronisation de hachage de mot de
passe avec l’Assistant Azure AD Connect. La synchronisation de hachage de mot de passe est une fonctionnalité
facultative que vous pouvez activer dans les environnements qui utilisent la fédération. Cela n’a aucun effet sur le
flux d’authentification. Dans ce cas, Azure AD Connect démarre la synchronisation des hachages de mot de passe
sans affecter les utilisateurs qui se connectent en utilisant la fédération.
Pour cette raison, nous vous recommandons d’effectuer cette étape en amont, en préparation de la modification de
la méthode de connexion de votre domaine. Ensuite, vous avez suffisamment de temps pour vérifier que la
synchronisation de hachage de mot de passe fonctionne correctement.
Pour activer la synchronisation de hachage de mot de passe :
1. Sur le serveur Azure AD Connect, ouvrez l’Assistant Azure AD Connect, puis sélectionnez Configurer.
2. Sélectionnez Personnaliser les options de synchronisation, puis cliquez sur Suivant.
3. Dans la page Connexion à Azure AD, entrez le nom d’utilisateur et le mot de passe d’un compte
d’administrateur général.
4. Dans la page Connexion de vos annuaires, cliquez sur Suivant.
5. Dans la page Filtrage par domaine ou unité d’organisation, cliquez sur Suivant.
6. Dans la page Fonctionnalités facultatives, sélectionnez Synchronisation de mot de passe, puis cliquez
sur Suivant.

7. Sélectionnez Suivant dans les pages restantes. Dans la dernière page, sélectionnez Configurer.
8. Azure AD Connect commence la synchronisation des hachages de mot de passe lors de la synchronisation
suivante.
Une fois la synchronisation de hachage de mot de passe activée, les hachages de mot de passe de tous les
utilisateurs dans le périmètre de synchronisation d’Azure AD Connect sont réeffectués et sont écrits dans Azure
AD. En fonction du nombre d’utilisateurs, cette opération peut prendre de quelques minutes à plusieurs heures.
Pour la planification, vous pouvez estimer qu’environ 20 000 utilisateurs sont traités en 1 heure.
Pour vérifier que la synchronisation de hachage de mot de passe fonctionne correctement, utilisez la tâche
Résolution des problèmes de l’Assistant Azure AD Connect :
1. Ouvrez une nouvelle session Windows PowerShell sur votre serveur Azure AD Connect avec l’option Exécuter
en tant qu’administrateur.
2. Exécutez Set-ExecutionPolicy RemoteSigned ou Set-ExecutionPolicy Unrestricted .
3. Lancez l’Assistant Azure AD Connect.
4. Accédez à la page Tâches supplémentaires, sélectionnez Résoudre les problèmes, puis sélectionnez
Suivant.
5. Dans la page Résolution des problèmes, cliquez sur Lancer pour ouvrir le menu de dépannage dans
PowerShell.
6. Dans le menu principal, sélectionnez Résoudre les problèmes de synchronisation de hachage de mot de
passe.
7. Dans le sous-menu, sélectionnez La synchronisation du hachage de mot de passe ne fonctionne pas du
tout.
Pour résoudre les problèmes, consultez Résoudre les problèmes de synchronisation du hachage de mot de passe
avec Azure AD Connect Sync.
Étape 2 : Préparer pour l’authentification unique fluide
Pour que vos appareils utilisent l’authentification unique fluide, vous devez ajouter une URL Azure AD aux
paramètres de zone intranet des utilisateurs via une stratégie de groupe dans Active Directory.
Par défaut, les navigateurs web déterminent automatiquement la zone appropriée, Internet ou intranet, à partir
d’une URL. Par exemple, http://contoso/ est mappée à la zone intranet, tandis que http://intranet.contoso.com
est mappée à la zone Internet (car l’URL contient un point). Les navigateurs envoient des tickets Kerberos à un
point de terminaison cloud, comme l’URL Azure AD, seulement si vous ajoutez explicitement l’URL à la zone
intranet du navigateur.
Effectuez les étapes pour déployer les modifications nécessaires sur vos appareils.

IMPORTANT
Ce changement ne modifie pas la façon dont vos utilisateurs se connectent à Azure AD. Cependant, il est important
d’appliquer cette configuration à tous vos appareils avant de continuer. Les utilisateurs qui se connectent sur des appareils qui
n’ont pas reçu cette configuration doivent simplement entrer un nom d’utilisateur et un mot de passe pour se connecter à
Azure AD.

Étape 3 : Changer la méthode de connexion pour la synchronisation de hachage de mot de passe et activer
l’authentification unique fluide
Vous avez deux options pour changer la méthode de connexion pour la synchronisation de hachage de mot de
passe et l’activation de l’authentification unique fluide.
Option A : Passer de la fédération à la synchronisation de hachage de mot de passe avec Azure AD Connect
Utilisez cette méthode si vous avez initialement configuré votre environnement AD FS avec Azure AD Connect.
Vous ne pouvez pas utiliser cette méthode si vous n’avez pas initialement configuré votre environnement AD FS
avec Azure AD Connect.
Changez d’abord la méthode de connexion :
1. Sur le serveur Azure AD Connect, ouvrez l’Assistant Azure AD Connect.
2. Sélectionnez Modifier la connexion utilisateur, puis sélectionnez Suivant.

3. Dans la page Connexion à Azure AD, entrez le nom d’utilisateur et le mot de passe d’un compte
d’administrateur général.
4. Dans la page Connexion utilisateur, sélectionnez le bouton Synchronisation de hachage de mot de
passe. Veillez à cocher la case Ne pas convertir les comptes utilisateur. L’option est dépréciée.
Sélectionnez Activer l’authentification unique, puis sélectionnez Suivant.
NOTE
À compter d’Azure AD Connect version 1.1.880.0, la case Authentification unique fluide est cochée par défaut.

IMPORTANT
Vous pouvez ignorer les avertissements indiquant que la conversion des utilisateurs et la synchronisation de hachage
de mot de passe complète sont des étapes obligatoires pour le passage de la fédération à l’authentification cloud.
Notez que ces étapes ne sont plus nécessaires. Si vous voyez toujours ces avertissements, vérifiez que vous exécutez
la version la plus récente d’Azure AD Connect ainsi que la dernière version de ce guide. Pour plus d’informations,
consultez la section Mettre à jour Azure AD Connect.

5. Dans la page Activer l’authentification unique, entrez les informations d’identification du compte
d’administrateur de domaine, puis sélectionnez Suivant.

NOTE
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.
Les informations d’identification du compte d’administrateur de domaine ne sont pas stockées dans Azure AD
Connect ni dans Azure AD. Les informations d’identification du compte d’administrateur de domaine sont utilisées
seulement pour activer la fonctionnalité. Les informations d’identification sont supprimées quand le processus se
termine avec succès.
1. Un compte d’ordinateur nommé AZUREADSSOACC (qui représente Azure AD) est créé dans votre instance Active
Directory locale.
2. La clé de déchiffrement Kerberos du compte d’ordinateur est partagée de façon sécurisée avec Azure AD.
3. Deux noms de principal du service Kerberos sont créés pour représenter les deux URL utilisées lors de la connexion
à Azure AD.

6. Dans la page Prêt à configurer, vérifiez que la case Démarrez le processus de synchronisation une fois
la configuration terminée est cochée. Ensuite, sélectionnez Configurer.

IMPORTANT
À ce stade, tous vos domaines fédérés passent à l’authentification managée. La synchronisation du hachage de mot
de passe est la nouvelle méthode d’authentification.

7. Dans le portail Azure AD, sélectionnez Azure Active Directory > Azure AD Connect.
8. Vérifiez ces paramètres :
Fédération est défini sur Désactivé.
Authentification unique fluide est défini sur Activé.
Synchronisation de mot de passe est défini sur Activé.
Accédez à Tests et étapes suivantes.

IMPORTANT
Ignorez la section Option B : Passer de la fédération à la synchronisation de hachage de mot de passe avec Azure
AD Connect et PowerShell. Les étapes décrites dans cette section ne s’appliquent pas si vous avez choisi l’option A pour
changer la méthode de connexion en synchronisation de hachage de mot de passe et pour activer l’authentification unique
fluide.

Option B : Passer de la fédération à la synchronisation de hachage de mot de passe avec Azure AD Connect et PowerShell
Utilisez cette option si vous n’avez pas initialement configuré vos domaines fédérés avec Azure AD Connect. Au
cours de ce processus, vous activez l’authentification unique fluide et vous faites passer vos domaines de fédérés en
managés.
1. Sur le serveur Azure AD Connect, ouvrez l’Assistant Azure AD Connect.
2. Sélectionnez Modifier la connexion utilisateur, puis sélectionnez Suivant.
3. Dans la page Connexion à Azure AD, entrez le nom d’utilisateur et le mot de passe pour un compte
d’administrateur général.
4. Dans la page Connexion utilisateur, sélectionnez le bouton Synchronisation de hachage de mot de
passe. Sélectionnez Activer l’authentification unique, puis sélectionnez Suivant.
Avant l’activation de la synchronisation de hachage de mot de passe :
Après l’activation de la synchronisation de hachage de mot de passe :

NOTE
À compter d’Azure AD Connect version 1.1.880.0, la case Authentification unique fluide est cochée par défaut.

5. Dans la page Activer l’authentification unique, entrez les informations d’identification d’un compte
d’administrateur de domaine, puis sélectionnez Suivant.
NOTE
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.
Les informations d’identification du compte d’administrateur de domaine ne sont pas stockées dans Azure AD
Connect ni dans Azure AD. Les informations d’identification du compte d’administrateur de domaine sont utilisées
seulement pour activer la fonctionnalité. Les informations d’identification sont supprimées quand le processus se
termine avec succès.
1. Un compte d’ordinateur nommé AZUREADSSOACC (qui représente Azure AD) est créé dans votre instance Active
Directory locale.
2. La clé de déchiffrement Kerberos du compte d’ordinateur est partagée de façon sécurisée avec Azure AD.
3. Deux noms de principal du service Kerberos sont créés pour représenter les deux URL utilisées lors de la connexion
à Azure AD.

6. Dans la page Prêt à configurer, vérifiez que la case Démarrez le processus de synchronisation une fois
la configuration terminée est cochée. Ensuite, sélectionnez Configurer.

Quand vous sélectionnez le bouton Configurer, l’authentification unique fluide est configurée comme
indiqué dans l’étape précédente. La configuration de synchronisation de hachage de mot de passe n’est pas
modifiée, car elle a été activée précédemment.

IMPORTANT
Aucune modification n’est apportée à la façon dont les utilisateurs se connectent pour l’instant.

7. Dans le portail Azure AD, vérifiez ces paramètres :


Fédération est défini sur Activé.
Authentification unique fluide est défini sur Activé.
Synchronisation de mot de passe est défini sur Activé.
Convertir les domaines fédérés en domaines managés
À ce stade, la fédération est toujours activée et opérationnelle pour vos domaines. Pour poursuivre le déploiement,
chaque domaine fédéré doit être converti en domaine managé pour forcer l’authentification utilisateur via la
synchronisation de hachage de mot de passe.

IMPORTANT
Vous n’êtes pas obligé de convertir tous les domaines en même temps. Vous pouvez choisir de démarrer avec un domaine de
test sur votre locataire de production ou de démarrer avec votre domaine qui a le plus petit nombre d’utilisateurs.

Effectuez la conversion en utilisant le module PowerShell Azure AD :


1. Dans PowerShell, connectez-vous au portail Azure en utilisant un compte d’administrateur général.
2. Pour convertir le premier domaine, exécutez la commande suivante :

Set-MsolDomainAuthentication -Authentication Managed -DomainName <domain name>

3. Dans le portail Azure AD, sélectionnez Azure Active Directory > Azure AD Connect.
4. Vérifiez que le domaine a été converti en domaine managé en exécutant la commande suivante :

Get-MsolDomain -DomainName <domain name>

Tests et étapes suivantes


Effectuez les tâches suivantes pour vérifier la synchronisation de hachage de mot de passe et terminer le processus
de conversion.
Tester l’authentification avec la synchronisation de hachage de mot de passe
Quand votre locataire utilisait l’identité fédérée, les utilisateurs étaient redirigés de la page de connexion d’Azure
AD vers votre environnement AD FS. Maintenant que le locataire est configuré pour utiliser la synchronisation de
hachage de mot de passe au lieu de l’authentification fédérée, les utilisateurs ne sont pas redirigés vers AD FS. Au
lieu de cela, ils se connectent directement sur la page de connexion d’Azure AD.
Pour tester la synchronisation de hachage de mot de passe :
1. Ouvrez Internet Explorer en mode InPrivate, afin que l’authentification unique fluide ne vous connecte pas
automatiquement.
2. Accédez à la page de connexion d’Office 365 (https://portal.office.com).
3. Entrez un UPN d’utilisateur, puis sélectionnez Suivant. Veillez à entrer l’UPN d’un utilisateur hybride qui a
été synchronisé à partir de votre instance d’Active Directory locale et qui a déjà utilisé l’authentification
fédérée. Une page sur laquelle vous entrez le nom d’utilisateur et le mot de passe apparaît :
4. Après avoir entré le mot de passe et sélectionné Se connecter, vous êtes redirigé vers le portail Office 365.

Tester l’authentification unique fluide


1. Connectez-vous à un ordinateur joint au domaine, connecté au réseau d’entreprise.
2. Dans Internet Explorer ou dans Chrome, accédez à une des URL suivantes (remplacez « contoso » par votre
domaine) :
https://myapps.microsoft.com/contoso.com
https://myapps.microsoft.com/contoso.onmicrosoft.com
L’utilisateur est redirigé brièvement à la page de connexion d’Azure AD, qui affiche le message « Tentative
de connexion en cours ». L’utilisateur n’est pas invité à entrer un nom d’utilisateur ou un mot de passe.

3. L’utilisateur est redirigé et connecté avec succès au panneau d’accès :

NOTE
L’authentification unique fluide fonctionne sur les services Office 365 qui prennent en charge l’indication du domaine
(par exemple, myapps.microsoft.com/contoso.com). Actuellement, le portail Office 365 (portal.office.com) ne prend en
charge les indications de domaine. Les utilisateurs doivent entrer un UPN. Une fois qu’un UPN est entré,
l’authentification unique fluide récupère le ticket Kerberos pour le compte de l’utilisateur. L’utilisateur est connecté
sans devoir entrer un mot de passe.

TIP
Envisagez de déployer la jonction Azure AD Hybride sur Windows 10 pour une expérience d’authentification unique
améliorée.

Supprimer l’approbation de partie de confiance


Après avoir vérifié le bon fonctionnement de l’authentification de tous les utilisateurs et clients via Azure AD, vous
pouvez supprimer sans danger l’approbation de partie de confiance d’Office 365.
Si vous n’utilisez pas AD FS à d’autres fins (c’est-à-dire pour d’autres approbations de partie de confiance), vous
pouvez à ce stade mettre AD FS hors service sans problème.
Restauration
Si vous découvrez un problème majeur et que vous ne pouvez pas le résoudre rapidement, vous pouvez choisir de
revenir à la solution de fédération.
Consultez la documentation de conception et de déploiement de la fédération pour connaître les détails spécifiques
à votre déploiement. Le processus doit impliquer ces tâches :
Convertir les domaines managés à l’authentification fédérée avec l’applet de commande Convert-
MSOLDomainToFederated.
Si nécessaire, configurez des règles de revendication supplémentaires.
Synchroniser les mises à jour de userPrincipalName
Historiquement, les mises à jour de l’attribut UserPrincipalName, qui utilise le service de synchronisation à partir
de l’environnement local, sont bloquées sauf si les deux conditions suivantes sont remplies :
L’utilisateur est dans un domaine d’identité (non fédérée) managée.
Aucune licence n’a été affectée à l’utilisateur.
Pour savoir comment vérifier ou activer cette fonctionnalité, consultez Synchroniser les mises à jour de
userPrincipalName.
Résolution de problèmes
Votre équipe de support doit comprendre comment résoudre les problèmes d’authentification qui surviennent
pendant ou après le passage de l’authentification fédérée à l’authentification managée. Utilisez la documentation de
dépannage suivante pour aider votre équipe de support à se familiariser avec les procédures de dépannage
courantes, et les mesures à prendre pour isoler et résoudre le problème.
Résoudre les problèmes de synchronisation de hachage de mot de passe d’Azure Active Directory
Résoudre les problèmes d’authentification unique fluide Azure Active Directory

Substituer la clé de déchiffrement Kerberos pour l’authentification


unique fluide
Il est important de changer fréquemment la clé de déchiffrement Kerberos du compte d’ordinateur
AZUREADSSOACC (qui représente Azure AD ). Le compte d’ordinateur AZUREADSSOACC est créé dans votre
forêt Active Directory locale. Nous vous recommandons fortement de changer la clé de déchiffrement Kerberos au
moins tous les 30 jours, pour vous aligner sur la façon dont les membres du domaine Active Directory soumettent
des changements de mot de passe. Comme aucun appareil n’est associé à l’objet de compte d’ordinateur
AZUREADSSOACC, vous devez effectuer ce changement de clé manuellement.
Lancez le remplacement de la clé de déchiffrement Kerberos de l’authentification unique fluide sur le serveur local
qui exécute Azure AD Connect.
Pour plus d’informations, consultez Comment puis-je substituer la clé de déchiffrement Kerberos du compte
d’ordinateur AZUREADSSOACC ?.

Étapes suivantes
Découvrez plus d’informations sur les principes de conception d’Azure AD Connect.
Choisir l’authentification appropriée.
Découvrez plus d’informations sur les topologies prises en charge.
Migrer de la fédération à l’authentification directe
pour Azure Active Directory
17/09/2019 • 47 minutes to read • Edit Online

Cet article décrit comment faire passer les domaines de votre organisation d’AD FS (Active Directory Federation
Services) à l’authentification directe.
Vous pouvez télécharger cet article.

Prérequis pour la migration vers l’authentification directe


Les prérequis suivants sont nécessaires pour migrer de l’utilisation d’AD FS vers l’utilisation de l’authentification
directe.
Mettre à jour Azure AD Connect
Pour pouvoir effectuer les étapes nécessaires pour migrer vers l’utilisation de l’authentification directe, vous devez
disposer d’Azure Active Directory Connect (Azure AD Connect) 1.1.819.0 ou ultérieur. Dans Azure AD Connect
1.1.819.0, la façon dont conversion de la connexion est effectuée change considérablement. Le temps total
nécessaire pour depuis AD FS vers l’authentification cloud dans cette version est réduit d’une durée potentielle de
plusieurs heures à quelques minutes.

IMPORTANT
Vous pouvez lire dans des documentations, des outils et des blogs obsolètes que la conversion de l’utilisateur est nécessaire
quand vous convertissez des domaines de l’identité fédérée à l’identité managée. La conversion des utilisateurs n’est plus
nécessaire. Microsoft s’emploie à mettre à jour la documentation et les outils afin de refléter ce changement.

Pour mettre à jour Azure AD Connect, suivez les étapes de Azure AD Connect : Mettre à niveau vers la version la
plus récente.
Planifier le numéro et le positionnement de l’agent d’authentification
Pour bénéficier de l’authentification directe, vous devez déployer des agents légers sur le serveur Azure AD
Connect et sur vos serveurs locaux qui exécutent Windows Server. Pour réduire la latence, installez les agents aussi
près que possible de vos contrôleurs de domaine Active Directory.
Pour la plupart des clients, deux ou trois agents d’authentification suffisent à offrir la haute disponibilité et la
capacité nécessaire. Un locataire peut avoir un maximum de 12 agents inscrits. Le premier agent est toujours
installé sur le serveur Azure AD Connect lui-même. Pour en savoir plus sur les limitations de l’agent et sur les
options de déploiement des agents, consultez Authentification directe Azure AD : Limitations actuelles.
Planifier la méthode de migration
Vous pouvez choisir entre deux méthodes pour migrer de la gestion fédérée des identités vers l’authentification
directe et l’authentification unique fluide. La méthode utilisée dépend de la configuration initiale de votre instance
AD FS.
Azure AD Connect. Si vous avez configuré à l’origine AD FS avec Azure AD Connect, vous devez passer à
l’authentification directe en utilisant l’Assistant Azure AD Connect.
Azure AD Connect exécute automatiquement l’applet de commande Set-MsolDomainAuthentication
quand vous changez la méthode de connexion des utilisateurs. Azure AD Connect annule automatiquement
la fédération de tous les domaines fédérés vérifiés dans votre locataire Azure AD.

NOTE
Actuellement, si vous avez utilisé à l’origine Azure AD Connect pour configurer AD FS, vous ne pouvez pas éviter
l’annulation de la fédération de tous les domaines de votre locataire quand vous passez à l’authentification directe
pour la connexion des utilisateurs.

Azure AD Connect avec PowerShell. Vous pouvez utiliser cette méthode seulement si vous n’avez pas
configuré à l’origine AD FS avec Azure AD Connect. Pour cette option, vous devez toujours changer la
méthode d’authentification des utilisateurs via l’Assistant Azure AD Connect. La principale différence avec
cette option est que l’Assistant n’exécute pas automatiquement l’applet de commande Set-
MsolDomainAuthentication. Avec cette option, vous avez un contrôle total sur les domaines qui sont
convertis et dans quel ordre.
Pour savoir quelle méthode utiliser, effectuez les étapes des sections suivantes.
Vérifier les paramètres de connexion utilisateur définis actuellement
1. Connectez-vous au portail Azure en utilisant un compte d’administrateur général.
2. Dans la section Connexion utilisateur, vérifiez les paramètres suivants :
Fédération est défini sur Activé.
Authentification unique fluide est défini sur Désactivé.
Authentification directe est défini sur Désactivé.

Vérifier la configuration de la fédération


1. Sur votre serveur Azure AD Connect, ouvrez Azure AD Connect. Sélectionnez Configurer.
2. Dans la page Tâches supplémentaires, sélectionnez Afficher la configuration actuelle, puis
sélectionnez Suivant.
3. Dans la page Vérification de votre solutionn faites défiler jusqu’à Services Active Directory
Federation Services (ADFS ) .
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. Vous pouvez convertir vos domaines de l’identité
fédérée en identité managée en utilisant l’option Modifier la connexion utilisateur d’Azure AD
Connect. Pour plus d’informations sur le processus, consultez la section Option A : Configurer
l’authentification directe à l’aide d’Azure AD Connect.
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. Pour plus d’informations sur ce processus,
consultez la section Option B : Passer de la fédération à l’authentification directe avec Azure AD
Connect et PowerShell.
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 :

Get-MsolDomainFederationSettings -DomainName YourDomain.extention | fl *

Exemple :

Get-MsolDomainFederationSettings -DomainName Contoso.com | fl *

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, SupportsMfa et PromptLoginBehavior.
Pour plus d’informations, voir les articles suivants :
AD FS prompt=login parameter support
Set-MsolDomainAuthentication
NOTE
Si SupportsMfa est défini sur True, cela signifie que vous utilisez une solution d’authentification multifacteur locale pour
injecter un deuxième facteur dans le flux d’authentification des utilisateurs. Cette configuration ne fonctionne plus pour les
scénarios d’authentification d’Azure AD.
Au lieu de cela, utilisez le service cloud Azure Multi-Factor Authentication pour la même fonction. Évaluez soigneusement vos
besoins d’authentification multifacteur avant de continuer. Avant de convertir vos domaines, veillez à bien comprendre
comment utiliser Azure Multi-Factor Authentication, les implications en matière de gestion des licences et le processus
d’inscription des utilisateurs.

Sauvegarder les paramètres de fédération


Même si aucune modification n’est apportée aux autres parties de confiance de votre batterie AD FS pendant le
processus, nous vous recommandons de disposer d’une sauvegarde de votre batterie de serveurs AD FS valide et
actuelle, à partir de laquelle vous pouvez faire une restauration. Vous pouvez créer une sauvegarde valide actuelle
avec l’outil de restauration rapide d’AD FS gratuit de Microsoft. Vous pouvez utiliser l’outil pour sauvegarder AD
FS, et pour restaurer une batterie de serveurs existante ou pour en créer une.
Si vous choisissez de ne pas utiliser l’outil de restauration rapide d’AD FS, exportez au moins les approbations de
partie de confiance de la plateforme d’identité Microsoft Office 365 et toutes les règles de revendication
personnalisées associées que vous avez ajoutées. Vous pouvez exporter l’approbation de partie de confiance et les
règles de revendication associées en utilisant l’exemple PowerShell suivant :

(Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-


RelyingPartyTrust.xml"

Considérations relatives au déploiement et utilisation d’AD FS


Cette section décrit les considérations relatives au déploiement et des détails sur l’utilisation d’AD FS.
Utilisation actuelle d’AD FS
Avant de passer de l’identité fédérée à l’identité managée, examinez attentivement votre utilisation actuelle d’AD
FS pour Azure AD, Office 365 et autres applications (approbations de partie de confiance). En particulier,
considérez les scénarios décrits dans le tableau suivant :

SI ALORS

Vous prévoyez d’utiliser AD FS avec d’autres applications Après avoir converti vos domaines, vous utiliserez AD FS et
(autres qu’Azure AD et Office 365). Azure AD. Considérez l’expérience utilisateur. Dans certains
scénarios, les utilisateurs doivent peut-être s’authentifier deux
fois : une fois auprès d’Azure AD (où un utilisateur bénéficie
d’un accès avec authentification unique à d’autres applications,
comme Office 365), et une deuxième fois dans les applications
encore liées à AD FS comme approbation de partie de
confiance.

Votre instance d’AD FS est très personnalisée et s’appuie sur Avant de continuer, vous devez vérifier qu’Azure AD peut
des paramètres de personnalisation spécifiques du fichier répondre à vos spécifications de personnalisation actuelles.
onload.js (par exemple si vous avez modifié l’expérience de Pour plus d’informations et des conseils, consultez les sections
connexion afin que les utilisateurs utilisent seulement un relatives à la personnalisation d’AD FS.
format SamAccountName pour leur nom d’utilisateur au lieu
d’un nom d’utilisateur principal (UPN), ou si votre organisation
a fortement personnalisé l’expérience de connexion). Le fichier
onload.js ne peut pas être dupliqué dans Azure AD.
SI ALORS

Vous utilisez AD FS pour bloquer des versions antérieures des Vous pouvez remplacer les contrôles d’AD FS qui bloquent les
clients d’authentification. versions antérieures des clients d’authentification en utilisant
une combinaison de contrôles d’accès conditionnel et de règles
d’accès de client Exchange Online.

Vous obligez les utilisateurs à effectuer une authentification Dans un domaine d’identité managée, vous ne pouvez pas
multifacteur via une solution de serveur d’authentification injecter une demande d’authentification multifacteur via la
multifacteur locale quand les utilisateurs s’authentifient auprès solution d’authentification multifacteur locale dans le flux
d’AD FS. d’authentification. Vous pouvez cependant utiliser le service
Azure Multi-Factor Authentication pour l’authentification
multifacteur une fois que le domaine est converti.

Si vos utilisateurs n’utilisent pas actuellement Azure Multi-


Factor Authentication, une étape ponctuelle d’inscription des
utilisateurs est nécessaire. Vous devez préparer et
communiquer l’inscription planifiée à vos utilisateurs.

Vous utilisez actuellement des stratégies de contrôle d’accès Vous pouvez envisager de remplacer les stratégies par des
(règles AuthZ) dans AD FS pour contrôler l’accès à Office 365. stratégies d’accès conditionnel et des règles d’accès du client
Exchange Online d’Azure AD équivalentes.

Personnalisations courantes d’AD FS


Cette section décrit les personnalisations courantes d’AD FS.
Revendication InsideCorporateNetwork
AD FS émet la revendication InsideCorporateNetwork si l’utilisateur qui s’authentifie se trouve dans le réseau
d’entreprise. Cette revendication est ensuite passée à Azure AD. La revendication est utilisée pour contourner
l’authentification multifacteur en fonction de l’emplacement réseau de l’utilisateur. Pour savoir comment déterminer
si cette fonctionnalité est actuellement disponible dans AD FS, consultez Adresses IP de confiance pour les
utilisateurs fédérés.
La revendication InsideCorporateNetwork n’est plus disponible une fois que vos domaines sont convertis à
l’authentification directe. Vous pouvez utiliser des emplacements nommés dans Azure AD pour remplacer cette
fonctionnalité.
Une fois que vous avez configuré des emplacements nommés, vous devez mettre à jour toutes les stratégies
d’accès conditionnel configurées de façon à inclure ou à exclure les valeurs Tous les emplacements approuvés
ou Adresses IP approuvées MFA pour refléter les emplacements nommés nouvellement créés.
Pour plus d’informations sur la condition Emplacement dans l’accès conditionnel, consultez Emplacements
d’accès conditionnel Azure Active Directory.
Appareils joints à Azure AD Hybride
Quand vous joignez un appareil à Azure AD, vous pouvez créer des règles d’accès conditionnel qui imposent que
les appareils répondent à vos standards d’accès pour la sécurité et la conformité. De même, les utilisateurs peuvent
se connecter à un appareil en utilisant un compte professionnel ou scolaire d’une organisation au lieu d’un compte
personnel. Quand vous utilisez des appareils joints à Azure AD Hybride, vous pouvez joindre à Azure AD vos
appareils joints à un domaine Active Directory. Votre environnement fédéré peut avoir été configuré pour utiliser
cette fonctionnalité.
Pour garantir le bon fonctionnement de la jonction hybride pour les appareils joints au domaine une fois vos
domaines convertis à l’authentification directe, pour les clients Windows 10, vous devez utiliser Azure AD Connect
pour synchroniser les comptes d’ordinateur Active Directory avec Azure AD.
Pour les comptes d’ordinateur Windows 8 et Windows 7, la jointure hybride utilise l’authentification unique fluide
pour inscrire l’ordinateur dans Azure AD. Vous n’avez pas à synchroniser les comptes d’ordinateur Windows 8 et
Windows 7 comme vous le faites pour les appareils Windows 10. Cependant, vous devez déployer un fichier
workplacejoin.exe mis à jour (via un package .msi) sur les clients Windows 8 et Windows 7 afin qu’ils puissent
s’inscrire avec l’authentification unique fluide. Téléchargez le package .msi.
Pour plus d’informations, consultez Configurer les appareils joints à Azure AD Hybride.
Personnalisation
Si votre organisation a personnalisé vos pages de connexion AD FS pour afficher des informations plus
pertinentes pour l’organisation, envisagez de faire des personnalisations similaires pour la page de connexion
Azure AD.
S’il est possible d’apporter des personnalisations similaires, il faut s’attendre à certaines modifications visuelles
après la conversion. Vous pouvez fournir des informations sur les modifications attendues dans vos
communications aux utilisateurs.

NOTE
La personnalisation d’organisation est disponible seulement si vous avez acheté une licence Premium ou De base pour Azure
Active Directory, ou si vous disposez d’une licence Office 365.

Planifier le verrouillage intelligent


Le verrouillage intelligent d’Azure AD protège contre les attaques des mots de passe par force brute. Le
verrouillage intelligent empêche le verrouillage d’un compte Active Directory local quand l’authentification directe
est utilisée et qu’une stratégie de groupe de verrouillage de compte est définie dans Active Directory.
Pour plus d’informations, consultez Verrouillage intelligent Azure Active Directory.

Planification du déploiement et du support


Effectuez les tâches décrites dans cette section pour planifier le déploiement et le support.
Planifier la fenêtre de maintenance
Même si le processus de conversion de domaine est relativement rapide, Azure AD peut continuer à envoyer des
demandes d’authentification à vos serveurs AD FS pendant jusqu’à 4 heures après la fin de la conversion. Pendant
cet intervalle de quatre heures, et en fonction des différents caches du côté service, Azure AD peut ne pas accepter
ces authentifications. Les utilisateurs peuvent alors recevoir une erreur. L’utilisateur peut néanmoins toujours
s’authentifier auprès d’AD FS, mais Azure AD n’accepte plus le jeton émis de l’utilisateur, car cette approbation de
la fédération est maintenant supprimée.
Seuls les utilisateurs qui accèdent aux services via un navigateur web pendant cette période postérieure à la
conversion avant que le cache côté service soit effacé sont affectés. Les clients hérités (Exchange ActiveSync,
Outlook 2010/2013) ne sont normalement 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 cette mise en
cache effacée. 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.
IMPORTANT
N’arrêtez pas votre environnement AD FS et ne supprimez l’approbation de partie de confiance d’Office 365 avant d’avoir
vérifié que tous les utilisateurs réussissent à s’authentifier avec l’authentification cloud.

Plan de restauration
Si vous rencontrez un problème majeur que vous ne pouvez pas résoudre rapidement, vous pouvez décider de
revenir à la solution de fédération. Il est important de planifier ce qu’il faut si votre déploiement ne se passe pas
comme prévu. Si la conversion du domaine ou des utilisateurs échoue pendant le déploiement, ou si vous devez
revenir à la fédération, vous devez comprendre comment limiter les dégâts d’une panne et réduire l’effet sur vos
utilisateurs.
Pour annuler
Pour planifier l’annulation, consultez la documentation de conception et de déploiement de la fédération pour
connaître les détails spécifiques à votre déploiement. Le processus doit inclure ces tâches :
Conversion des domaines managés en domaines fédérés avec l’applet de commande Convert-
MSOLDomainToFederated.
Si nécessaire, configuration de règles de revendication supplémentaires.
Planifier les communications
Une partie importante de la planification du déploiement et du support est de veiller à ce que vos utilisateurs
finaux soient informés de façon proactive des modifications à venir. Les utilisateurs doivent savoir à l’avance ce
qu’ils peuvent subir et ce qui est attendu d’eux.
Une fois que l’authentification directe et l’authentification unique fluide sont déployées, l’expérience de connexion
des utilisateurs pour l’accès à Office 365 et aux autres ressources authentifiées via Azure AD change. Les
utilisateurs qui sont en dehors du réseau voient seulement la page de connexion Azure AD. Ces utilisateurs ne sont
pas redirigés vers la page basée sur des formulaires qui est présentée par les serveurs proxy d’applications web
externes.
Incluez les éléments suivants dans votre stratégie de communication :
Avertissez les utilisateurs des fonctionnalités à venir et publiées en utilisant :
L’e-mail et d’autres canaux de communication internes.
Des visuels, comme des affiches.
Des communications de la part de la direction, directes ou autres.
Déterminez qui va personnaliser les communications, et qui va les envoyer et quand.

Implémenter votre solution


Vous avez planifié votre solution. Vous pouvez maintenant l’implémenter. L’implémentation implique les
composants suivants :
Préparation pour l’authentification unique fluide.
Changement de la méthode de connexion pour l’authentification directe et activation de l’authentification
unique fluide.
Étape 1 : Préparer pour l’authentification unique fluide
Pour que vos appareils utilisent l’authentification unique fluide, vous devez ajouter une URL Azure AD aux
paramètres de zone intranet des utilisateurs via une stratégie de groupe dans Active Directory.
Par défaut, les navigateurs web déterminent automatiquement la zone appropriée, Internet ou intranet, à partir
d’une URL. Par exemple, http://contoso/ est mappée à la zone intranet, tandis que http://intranet.contoso.com
est mappée à la zone Internet (car l’URL contient un point). Les navigateurs envoient des tickets Kerberos à un
point