Prérequis pour la synchronisation cloud Azure AD Connect

Cet article fournit des conseils sur la façon de choisir et d’utiliser la synchronisation cloud Azure Active Directory (Azure AD) Connect en tant que solution d’identité.

Conditions requises de l’agent de provisionnement cloud

Vous avez besoin des éléments suivants pour utiliser la synchronisation cloud Azure AD Connect :

  • Les informations d’identification Administrateur de domaine ou Administrateur d’entreprise pour créer le compte de service managé de groupe (gMSA) Azure AD Connect Cloud Sync pour exécuter le service agent.
  • Un compte d’administrateur d’identité hybride pour votre locataire Azure AD qui n’est pas un utilisateur invité.
  • Un serveur local pour l’agent de provisionnement avec Windows 2016 ou ultérieur. Ce serveur doit être un serveur de niveau 0 basé sur le modèle de niveau d’administration Active Directory. L’installation de l’agent sur un contrôleur de domaine est prise en charge.
  • La haute disponibilité fait référence à la capacité de la synchronisation cloud Azure AD Connect à fonctionner en continu sans défaillance pendant une longue période. Si plusieurs agents actifs sont installés et en cours d’exécution, la synchronisation cloud Azure AD Connect peut continuer à fonctionner même en cas d’échec d’un agent. Microsoft recommande d’avoir trois agents actifs installés à des fins de haute disponibilité.
  • Des configurations de pare-feu locales.

Group Managed Service Accounts

Un compte de service managé de groupe est un compte de domaine managé qui fournit la gestion automatique des mots de passe, la gestion simplifiée du nom de principal du service (SPN), la possibilité de déléguer la gestion à d’autres administrateurs et cette fonctionnalité s’étend sur plusieurs serveurs. Azure AD Connect Cloud Sync prend en charge et utilise un gMSA pour l’exécution de l’agent. Vous serez invité à fournir des informations d’identification d’administration lors de l’installation, afin de créer ce compte. Le compte s’affiche sous la forme (domain\provAgentgMSA$). Pour plus d’informations sur un gMSA, consultez Comptes de service managés de groupe

Prérequis pour gMSA :

  1. Le schéma Active Directory dans la forêt du domaine gMSA doit être mis à jour vers Windows Server 2012 ou version ultérieure.
  2. Les modules RSAT PowerShell sur un contrôleur de domaine
  3. Au moins un contrôleur de domaine dans le domaine doit exécuter Windows Server 2012 ou version ultérieure.
  4. Un serveur joint à un domaine sur lequel l’agent est en cours d’installation doit être configuré avec Windows Server 2016 ou version ultérieure.

Compte gMSA personnalisé

Si vous créez un compte gMSA personnalisé, vous devez vous assurer que le compte dispose des autorisations suivantes.

Type Nom Accès S'applique à
Allow Compte gMSA Lire toutes les propriétés Objets appareil descendants
Allow Compte gMSA Lire toutes les propriétés Objets InetOrgPerson descendants
Allow Compte gMSA Lire toutes les propriétés Objets ordinateur descendants
Allow Compte gMSA Lire toutes les propriétés Objets foreignSecurityPrincipal descendants
Allow Compte gMSA Contrôle total Objets groupe descendants
Allow Compte gMSA Lire toutes les propriétés Objets utilisateur descendants
Allow Compte gMSA Lire toutes les propriétés Objets contact descendants
Allow Compte gMSA Supprimer des objets utilisateur Cet objet et tous les objets descendants

Pour connaître les étapes de la mise à niveau d’un agent existant afin d’utiliser un compte gMSA, consultez Comptes de service managés de groupe.

Créer un compte gMSA avec PowerShell

Vous pouvez utiliser le script PowerShell suivant pour créer un compte gMSA personnalisé. Vous pouvez ensuite utiliser les applets de commande gMSA de synchronisation cloud pour appliquer des autorisations plus précises.

# Filename:    1_SetupgMSA.ps1
# Description: Creates and installs a custom gMSA account for use with Azure AD Connect cloud sync.
#
# DISCLAIMER:
# Copyright (c) Microsoft Corporation. All rights reserved. This 
# script is made available to you without any express, implied or 
# statutory warranty, not even the implied warranty of 
# merchantability or fitness for a particular purpose, or the 
# warranty of title or non-infringement. The entire risk of the 
# use or the results from the use of this script remains with you.
#
#
#
#
# Declare variables
$Name = 'provAPP1gMSA'
$Description = "Azure AD Cloud Sync service account for APP1 server"
$Server = "APP1.contoso.com"
$Principal = Get-ADGroup 'Domain Computers'

# Create service account in Active Directory
New-ADServiceAccount -Name $Name `
-Description $Description `
-DNSHostName $Server `
-ManagedPasswordIntervalInDays 30 `
-PrincipalsAllowedToRetrieveManagedPassword $Principal `
-Enabled $True `
-PassThru

# Install the new service account on Azure AD Cloud Sync server
Install-ADServiceAccount -Identity $Name

Pour plus d’informations sur l’utilisation des applets de commande ci-dessus, consultez Prise en main des comptes de service administrés de groupe.

Dans le Centre d’administration Azure Active Directory

  1. Créez un compte d’administrateur d’identité hybride « 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 d’identité hybride 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 annuaire dans Azure Active Directory

Exécutez l’outil IdFix afin de préparer les attributs d’annuaire pour la synchronisation.

Dans votre environnement local

  1. Identifiez un serveur hôte joint à un domaine exécutant Windows Server 2016 ou ultérieur, avec au minimum 4 Go de RAM et .NET 4.7.1 + Runtime.

  2. La stratégie d’exécution de PowerShell sur le serveur local doit être définie sur Undefined ou sur RemoteSigned.

  3. S’il existe un pare-feu entre vos serveurs et Azure AD, consultez la configuration requise pour le pare-feu et le proxy ci-dessous.

Notes

L’installation de l’agent de provisionnement cloud sur Windows Server Core n’est pas prise en charge.

Autres conditions requises

Exigences relatives à TLS

Notes

Le protocole TLS (Transport Layer Security) est un protocole qui fournit des communications sécurisées. La modification des paramètres TLS affecte l’ensemble de la forêt. Pour plus d’informations, consultez Mise à jour pour activer TLS 1.1 et TLS 1.2 en tant que protocoles sécurisés par défaut dans WinHTTP sur Windows.

Le protocole TLS 1.2 doit être activé sur le serveur Windows qui hébergera l’agent de provisionnement cloud Azure AD Connect avant son installation.

Pour activer TLS 1.2, procédez comme suit.

  1. Définissez les clés de Registre suivantes :

    [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
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
    
  2. Redémarrez le serveur.

Configuration requise pour le pare-feu et le proxy

S’il existe un pare-feu entre vos serveurs et Azure AD, configurez les éléments suivants :

  • Assurez-vous que les agents peuvent effectuer des requêtes sortantes sur 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 TLS/SSL.
    443 Gère toutes les communications sortantes avec le service.
    8080 (facultatif) Les agents signalent leur état toutes les 10 minutes sur le port 8080, si le port 443 n’est pas disponible. Cet état est affiché sur le portail Azure AD.
  • 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 vous permet de spécifier des suffixes sûrs, ajoutez des connexions :

URL Utilisation
*.msappproxy.net
*.servicebus.windows.net
L’agent utilise ces URL pour communiquer avec le service cloud Azure AD.
*.microsoftonline.com
*.microsoft.com
*.msappproxy.com
*.windowsazure.com
L’agent utilise ces URL pour communiquer avec le service cloud Azure AD.
mscrl.microsoft.com:80
crl.microsoft.com:80
ocsp.msocsp.com:80
www.microsoft.com:80
Azure utilise ces URL pour vérifier les certificats.
login.windows.net
L’agent utilise ces URL lors du processus d’inscription.

Configuration NTLM requise

Vous ne devez pas activer NTLM sur le serveur Windows Server qui exécute l’agent de provisionnement Azure AD Connect et s’il est activé, vous devez le désactiver.

Limitations connues

Les limitations connues sont les suivantes :

Synchronisation d’écart

  • Le filtre d’étendue du groupe pour la synchronisation delta ne prend pas en charge plus de 50 000 membres.
  • Lorsque vous supprimez un groupe utilisé dans le cadre d’un filtre d’étendue de groupe, les utilisateurs qui sont membres du groupe ne sont pas supprimés.
  • Lorsque vous renommez l’unité d’organisation ou le groupe qui se trouve dans l’étendue, la synchronisation delta ne supprime pas les utilisateurs.

Journaux de provisionnement

  • Les journaux d’approvisionnement ne font pas clairement la différence entre les opérations de création et de mise à jour. Vous pouvez voir une opération de création pour une mise à jour et une opération de mise à jour pour une création.

Renommer le groupe ou renommer l’unité d’organisation

  • Si vous renommez un groupe ou une unité d’organisation dans AD dans le cadre d’une configuration donnée, le travail de synchronisation cloud ne pourra pas reconnaître le changement de nom dans AD. Le travail ne sera pas mis en quarantaine et restera sain.

Filtre d’étendue

Quand vous utilisez le filtre d’étendue des unités d’organisation

  • Vous pouvez uniquement synchroniser jusqu’à 59 unités d’organisation ou groupes de sécurité distincts pour une configuration donnée.
  • Les unités d’organisation imbriquées sont prises en charge : cela signifie que vous pouvez synchroniser une unité d’organisation contenant 130 unités d’organisation imbriquées, mais que vous ne pouvez pas synchroniser 60 unités d’organisation distinctes dans la même configuration.

Synchronisation de hachage de mot de passe

  • L’utilisation de la synchronisation de hachage de mot de passe avec InetOrgPerson n’est pas prise en charge.

Étapes suivantes